From randy at psg.com Wed Jul 1 00:36:34 2015 From: randy at psg.com (Randy Bush) Date: Wed, 01 Jul 2015 09:36:34 +0900 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <20150630223319.GH95870@Vurt.local> References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> <20150630223319.GH95870@Vurt.local> Message-ID: > - equipment might not support the RTR protocol to validate > announcements against the cache validator alcalu, cisco, juniper do > - Legal obstacles in obtaining the anchors from all RIRs arin has been pwned by the tea party and is best ignored. that they do not protect their members is their choice. they're a bottom up policy organization, right. bottom of the barrel. > - when not using the RTR protocol but generating prefix-list > filters based on RPKI data, the devices might not support > sufficient entries. because the rpki generated acls are bigger and heavier than those in the irr. and they have trans-fats. > I'll count "not using brocade" as a valid method. you use brocade at your border? how's that working out for you? :) randy From larrysheldon at cox.net Wed Jul 1 00:37:16 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 30 Jun 2015 19:37:16 -0500 Subject: Sacramento Outage. Message-ID: <5593363C.9040806@cox.net> Is it odd that there is no mention of this even here? http://www.wavebroadband.com/resources/outage/service.txt -- sed quis custodiet ipsos custodes? (Juvenal) From mehmet at akcin.net Wed Jul 1 00:43:44 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 30 Jun 2015 17:43:44 -0700 Subject: Sacramento Outage. In-Reply-To: <5593363C.9040806@cox.net> References: <5593363C.9040806@cox.net> Message-ID: <2082311F-8588-4D39-AE5F-D5AD309BCCED@akcin.net> There has been mention to this in outages.org list Mehmet > On Jun 30, 2015, at 17:37, Larry Sheldon wrote: > > > Is it odd that there is no mention of this even here? > > http://www.wavebroadband.com/resources/outage/service.txt > -- > sed quis custodiet ipsos custodes? (Juvenal) From job at instituut.net Wed Jul 1 00:44:29 2015 From: job at instituut.net (Job Snijders) Date: Wed, 1 Jul 2015 02:44:29 +0200 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> <20150630223319.GH95870@Vurt.local> Message-ID: <20150701004429.GM95870@Vurt.local> On Wed, Jul 01, 2015 at 09:36:34AM +0900, Randy Bush wrote: > > - when not using the RTR protocol but generating prefix-list > > filters based on RPKI data, the devices might not support > > sufficient entries. > > because the rpki generated acls are bigger and heavier than those in > the irr. and they have trans-fats. I don't consider RPKI generated ACLs a 1 to 1 replacement for IRR based filters. They might be used as supplement to each other. Kind regards, Job From randy at psg.com Wed Jul 1 00:51:46 2015 From: randy at psg.com (Randy Bush) Date: Wed, 01 Jul 2015 09:51:46 +0900 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <20150701004429.GM95870@Vurt.local> References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> <20150630223319.GH95870@Vurt.local> <20150701004429.GM95870@Vurt.local> Message-ID: >>> - when not using the RTR protocol but generating prefix-list >>> filters based on RPKI data, the devices might not support >>> sufficient entries. >> >> because the rpki generated acls are bigger and heavier than those in >> the irr. and they have trans-fats. > > I don't consider RPKI generated ACLs a 1 to 1 replacement for IRR based > filters. They might be used as supplement to each other. the major user puts the rpki-generated pseudo-irr in front of the others in peval(0) order. same number of resulting acls. hence i do not understand your "the devices might not support sufficient entries." randy From frnkblk at iname.com Wed Jul 1 03:12:05 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Tue, 30 Jun 2015 22:12:05 -0500 Subject: leap second outage Message-ID: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> We experienced our first leap second outage -- our SHE (super head end) is using (old) Motorola encoders and we lost those video channels. They restarted all those encoders to restore service. Frank From netfortius at gmail.com Wed Jul 1 03:30:17 2015 From: netfortius at gmail.com (Stefan) Date: Tue, 30 Jun 2015 22:30:17 -0500 Subject: leap second outage In-Reply-To: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> Message-ID: This was supposed to have happened @midnight UTC, right? Meaning that we are past that event. Under which scenarios should people be concerned about midnight local time? Lots of confusing messages flying all over... On Jun 30, 2015 10:13 PM, wrote: > We experienced our first leap second outage -- our SHE (super head end) is > using (old) Motorola encoders and we lost those video channels. They > restarted all those encoders to restore service. > > Frank > > From dovid at telecurve.com Wed Jul 1 03:32:57 2015 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 1 Jul 2015 03:32:57 +0000 Subject: leap second outage Message-ID: <1403982207-1435721578-cardhu_decombobulator_blackberry.rim.net-897464758-@b11.c3.bise6.blackberry> I read that and that at midnight local time since that's when you have the extra second. I know a large carrier in Israel is down. Waiting for conf. If it's leep second related. ------Original Message------ From: Stefan Sender: NANOG To: frnkblk at iname.com Cc: nanog at nanog.org Subject: Re: leap second outage Sent: Jun 30, 2015 23:30 This was supposed to have happened @midnight UTC, right? Meaning that we are past that event. Under which scenarios should people be concerned about midnight local time? Lots of confusing messages flying all over... On Jun 30, 2015 10:13 PM, wrote: > We experienced our first leap second outage -- our SHE (super head end) is > using (old) Motorola encoders and we lost those video channels. They > restarted all those encoders to restore service. > > Frank > > Regards, Dovid From josh at imaginenetworksllc.com Wed Jul 1 03:32:57 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 30 Jun 2015 23:32:57 -0400 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> Message-ID: That is my understanding as well. The event was about 3.5 hours ago. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Jun 30, 2015 at 11:30 PM, Stefan wrote: > This was supposed to have happened @midnight UTC, right? Meaning that we > are past that event. Under which scenarios should people be concerned about > midnight local time? Lots of confusing messages flying all over... > On Jun 30, 2015 10:13 PM, wrote: > > > We experienced our first leap second outage -- our SHE (super head end) > is > > using (old) Motorola encoders and we lost those video channels. They > > restarted all those encoders to restore service. > > > > Frank > > > > > From dovid at telecurve.com Wed Jul 1 03:39:53 2015 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 1 Jul 2015 03:39:53 +0000 Subject: leap second outage In-Reply-To: References: <1403982207-1435721578-cardhu_decombobulator_blackberry.rim.net-897464758-@b11.c3.bise6.blackberry> Message-ID: <596353565-1435721994-cardhu_decombobulator_blackberry.rim.net-1631072466-@b11.c3.bise6.blackberry> No. Some one leaked some routes: https://mobile.twitter.com/Axcelx/status/616058414746202113 Regards, Dovid -----Original Message----- From: Justin Paine Date: Tue, 30 Jun 2015 20:37:06 To: Cc: Stefan; NANOG; ; Subject: Re: leap second outage Any confirmation if the AWS outage was leap second-related? ____________ Justin Paine Head of Trust & Safety CloudFlare Inc. PGP KeyID: 57B6 0114 DE0B 314D On Tue, Jun 30, 2015 at 8:32 PM, Dovid Bender wrote: > I read that and that at midnight local time since that's when you have the extra second. I know a large carrier in Israel is down. Waiting for conf. If it's leep second related. > > ------Original Message------ > From: Stefan > Sender: NANOG > To: frnkblk at iname.com > Cc: nanog at nanog.org > Subject: Re: leap second outage > Sent: Jun 30, 2015 23:30 > > This was supposed to have happened @midnight UTC, right? Meaning that we > are past that event. Under which scenarios should people be concerned about > midnight local time? Lots of confusing messages flying all over... > On Jun 30, 2015 10:13 PM, wrote: > >> We experienced our first leap second outage -- our SHE (super head end) is >> using (old) Motorola encoders and we lost those video channels. They >> restarted all those encoders to restore service. >> >> Frank >> >> > > Regards, > > Dovid From nsuan at nonexiste.net Wed Jul 1 03:42:13 2015 From: nsuan at nonexiste.net (Nicholas Suan) Date: Tue, 30 Jun 2015 23:42:13 -0400 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> Message-ID: Correct, the leap second gets inserted at midnight UTC. "Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date." ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat On Tue, Jun 30, 2015 at 11:30 PM, Stefan wrote: > This was supposed to have happened @midnight UTC, right? Meaning that we > are past that event. Under which scenarios should people be concerned about > midnight local time? Lots of confusing messages flying all over... > On Jun 30, 2015 10:13 PM, wrote: > >> We experienced our first leap second outage -- our SHE (super head end) is >> using (old) Motorola encoders and we lost those video channels. They >> restarted all those encoders to restore service. >> >> Frank >> >> From jbfixurpc at gmail.com Wed Jul 1 04:14:46 2015 From: jbfixurpc at gmail.com (Joe) Date: Tue, 30 Jun 2015 23:14:46 -0500 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> Message-ID: A leap sec causing issues. For about 40 years now, there have been these leap seconds to no real issue. All of these are "go-forwards" and even MS AD (I believe) treat them as a little bump (nothing to see here move along). So unless you have really a tight VPN (non-standard conforming) I'd hope that nothing has happend, and if it did chances are it's etheir coincidence or intentional. I certainly hope I am around to collect on the https://en.wikipedia.org/wiki/Year_2038_problem for retirement. I think we've all seen the "big to do" regarding Y2K to know better Maybe I am wrong, but... Just my 2?s -Joe On Tue, Jun 30, 2015 at 10:42 PM, Nicholas Suan wrote: > Correct, the leap second gets inserted at midnight UTC. > > "Leap seconds can be introduced in UTC at the end of the months of December > > or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every > six months, either to announce a time step in UTC or to confirm that there > will be no time step at the next possible date." > > ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat > > On Tue, Jun 30, 2015 at 11:30 PM, Stefan wrote: >> This was supposed to have happened @midnight UTC, right? Meaning that we >> are past that event. Under which scenarios should people be concerned about >> midnight local time? Lots of confusing messages flying all over... >> On Jun 30, 2015 10:13 PM, wrote: >> >>> We experienced our first leap second outage -- our SHE (super head end) is >>> using (old) Motorola encoders and we lost those video channels. They >>> restarted all those encoders to restore service. >>> >>> Frank >>> >>> -- -Joe 920-530-3631 From stenn at ntp.org Wed Jul 1 04:47:15 2015 From: stenn at ntp.org (Harlan Stenn) Date: Wed, 01 Jul 2015 04:47:15 +0000 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> Message-ID: Joe writes: > A leap sec causing issues. For about 40 years now, there have been > these leap seconds to no real issue. All of these are "go-forwards" No, they're all "go-backwards" events. That's no big deal to things that don't care about monotonic time, or to folks who aren't in violation of something if their timestamps are off by a second. What I'm about to say may not be as stupid as it sounds: The problems here aren't problems for cases where it's not a problem. It is a problem where it *is* a problem. It's a case where one person's signal is another person's noise. H From jfmezei_nanog at vaxination.ca Wed Jul 1 05:08:07 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 01 Jul 2015 01:08:07 -0400 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> Message-ID: <559375B7.4010908@vaxination.ca> On 15-07-01 00:47, Harlan Stenn wrote: > What I'm about to say may not be as stupid as it sounds: The problems > here aren't problems for cases where it's not a problem. It is a > problem where it *is* a problem. In fairness, systems should be used to NTP making adjustments to the system clock of a second or less. However, in systems that expect tightly synchronized clocks, they would want all the nodes to make the NTP adjustement at the same time. From swmike at swm.pp.se Wed Jul 1 05:38:49 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 1 Jul 2015 07:38:49 +0200 (CEST) Subject: leap second outage In-Reply-To: <559375B7.4010908@vaxination.ca> References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> <559375B7.4010908@vaxination.ca> Message-ID: On Wed, 1 Jul 2015, Jean-Francois Mezei wrote: > However, in systems that expect tightly synchronized clocks, they would > want all the nodes to make the NTP adjustement at the same time. This is both an operating system and application problem. http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time This is similar to the jiffycounter wrapping, since this doesn't happen that often, it's not commonly tested for. Good way is to start the jiffy counter so it wraps after 10 minutes of uptime. That way you'll run into any bugs quickly. Either we should abolish the leap second or we should make leap second adjustments (back and forth) on a monthly basis to exercise the code. This is a hard sell though... -- Mikael Abrahamsson email: swmike at swm.pp.se From stenn at ntp.org Wed Jul 1 05:59:43 2015 From: stenn at ntp.org (Harlan Stenn) Date: Wed, 01 Jul 2015 05:59:43 +0000 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> <559375B7.4010908@vaxination.ca> Message-ID: Mikael Abrahamsson writes: > This is similar to the jiffycounter wrapping, since this doesn't happen > that often, it's not commonly tested for. Good way is to start the jiffy > counter so it wraps after 10 minutes of uptime. That way you'll run into > any bugs quickly. Either we should abolish the leap second or we should > make leap second adjustments (back and forth) on a monthly basis to > exercise the code. > > This is a hard sell though... and it's perversely interesting. It would even be tolerable when the difference between UTC and UT1 is such that the insertions and deletions maintain the +/- .9 s difference. There would even be enough time to warn folks about this. H From mark.tinka at seacom.mu Wed Jul 1 06:21:47 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jul 2015 08:21:47 +0200 Subject: Route leak in Bangladesh In-Reply-To: References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> Message-ID: <559386FB.6040201@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 30/Jun/15 16:53, Sandra Murphy wrote: > > > > That sort of AS_PATH filtering would not have helped in this case. The AS originated the routes, it did not propagate an upstream route. > > So an AS_PATH filter to just its own AS would have passed these routes. > > You would need origin validation on your outbound routes. Job suggested prefix filters on outbound routes. (If you are doing prefix filters on your inbound customer links, it might be excessive caution to also prefix filter customers prefixes on outbound links? Or is it: you can never be too careful, belt-and-suspenders, measure twice, etc?) Assuming you're running the same hardware/software across your backbone, correct prefix filters on inbound sessions to downstreams should be just fine. If those break, it's likely whatever broke them would also break them on egress to your upstreams and peers. The problem with egress prefix filters to upstreams and peers is that it's simply not scalable. Assuming you have a uniform routing policy where neighbors are all treated as eBGP sessions, then there is no real difference between upstreams, peers and other customers. Imagine having to build outbound prefix filters across your entire backbone for a uniform eBGP routing policy. Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVk4b7AAoJEGcZuYTeKm+GjPkP/1vEnL7mh0alWw+p6xCScUyH NxTYOYg1eBYUWQnGIWc+UTfZzKyr/LYbNyBF2Msf1aeNBOEb6kIY2geHUIGhOAZv DYIzggbvwWvd3X92aV76m3Nm8+z6nkDxnhYWgfefcXMofNTgHhQNKgsFp0efdDhA Mru60Cwi87apBLwY9wKYGqDtIgncKjLj92GfggimD7iwidvHZBXpKLIvPBE8sg9p aA/P9QqV2ZpVwoTtZy1Kb7B0FBogQFhPJX9RbWQUm0WwCuqMc8C7SibQMoF6hN0k rTuex7F4iPxTdvAcex/rRzIrQnDArIrMGkdOq3liQ8RG5d93Rara4NA9BgT6+ja/ idQ88lXjlBwzEEBh6k44Kg9Q686K503PK+hR8WrvETfojN8C4uD4WhUuqh3m2EPW UwJiZ8YD8oWQhLYpjdq/Rl7ozwu2ogi/ko69XuImi7f8OWscHD6QURoC0hONgLqF Rq7UgNcnOekUbTA+eP7ANFwKXNO+o9tomZ1tpmZqhNF5LLvazQFETcpEO2huQiON 2apxUiLWp3o8qCYKlvfUvREeF7fXaosgjXviWkjbdZc0v6hNjpd+M2uFPTz9CDgx PF9R+MzCu9C+gcfZRv4veY/ZFMxNxTNhOxppx69uyTG9+XCRXb5evjoV3VZPi/Qx RPUZQ1Ekzl0gAE7D4US6 =VZEA -----END PGP SIGNATURE----- From mark.tinka at seacom.mu Wed Jul 1 06:22:35 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jul 2015 08:22:35 +0200 Subject: Route leak in Bangladesh In-Reply-To: <5592B003.7030706@foobar.org> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <559299D5.4010700@seacom.mu> <5592B003.7030706@foobar.org> Message-ID: <5593872B.70004@seacom.mu> On 30/Jun/15 17:04, Nick Hilliard wrote: > plus: > > - fully automate ingress prefix management > - use maxprefixes with manual reenable on all ebgp sessions Yes, good point - forgot about that one; default max-prefix for all eBGP sessions. Mark. From mark.tinka at seacom.mu Wed Jul 1 06:25:06 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jul 2015 08:25:06 +0200 Subject: Route leak in Bangladesh In-Reply-To: <20150630150929.GZ95870@Vurt.local> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> Message-ID: <559387C2.8020603@seacom.mu> On 30/Jun/15 17:09, Job Snijders wrote: > > If you are a network providing transit to the leak originator mentioned > in the above paragraph, I believe a prefix based filter could have made > a big difference. And therein lies the secret sauce. Given that we've had an incident like this twice in the past month, I'm seriously concerned about the network operations of "top-tier" providers. Mark. From mark.tinka at seacom.mu Wed Jul 1 06:29:00 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jul 2015 08:29:00 +0200 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <20150701000240.1d2872ed@envy.fud.no> References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> Message-ID: <559388AC.80502@seacom.mu> On 1/Jul/15 00:02, Tore Anderson wrote: > > You're not mentioning RPKI here. Any particular reason why not? > > If I understand correctly, in today's leak the origin AS was > changed/reset, so RPKI ought to have saved the day. (At least Grzegorz' > day, considering that 33 of AS43996's prefixes are covered by ROAs.) It certainly would have. BGPmon was awash with alarms about Origin Validation violations for our prefixes that were originated by the offending network yesterday. If HE implemented Origin Validation, they'd have dropped these routes assuming that was their policy. Mark. From colinj at gt86car.org.uk Wed Jul 1 06:44:13 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 1 Jul 2015 07:44:13 +0100 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> <559375B7.4010908@vaxination.ca> Message-ID: <0D469B5F-51D5-455D-9113-8C91B20AAC5C@gt86car.org.uk> oracle linux did this Jul 1 02:01:29 oraclelinux ntpd[600]: 0.0.0.0 061c 0c clock_step -1.006445 s Jul 1 02:01:29 oraclelinux ntpd[600]: 0.0.0.0 0615 05 clock_sync Jul 1 02:01:29 oraclelinux systemd: Time has been changed Jul 1 02:01:30 oraclelinux ntpd[600]: 0.0.0.0 c618 08 no_sys_peer all seemed fine after this sophus utm did this 2015:07:01-00:59:59 cloudsophosvm kernel: [653957.707421] Clock: inserting leap second 23:59:60 UTC all seemed fine after this Colin From bygg at cafax.se Wed Jul 1 11:53:32 2015 From: bygg at cafax.se (Johnny Eriksson) Date: Wed, 1 Jul 2015 11:53:32 WET DST Subject: leap second outage In-Reply-To: Your message of Wed, 1 Jul 2015 07:38:49 +0200 (CEST) Message-ID: Mikael Abrahamsson wrote: > This is similar to the jiffycounter wrapping, since this doesn't happen > that often, it's not commonly tested for. Good way is to start the jiffy > counter so it wraps after 10 minutes of uptime. That way you'll run into > any bugs quickly. Either we should abolish the leap second or we should > make leap second adjustments (back and forth) on a monthly basis to > exercise the code. You could do this, move back on even-numbered months and forward on odd. Any real adjustment could be done via inhibiting the monthly change... > This is a hard sell though... 'fraid so. > Mikael Abrahamsson email: swmike at swm.pp.se --Johnny From frnkblk at iname.com Wed Jul 1 12:05:05 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Wed, 1 Jul 2015 07:05:05 -0500 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> Message-ID: <001b01d0b3f6$2c8d9f70$85a8de50$@iname.com> Yes, happened at 7 pm Central (0:oo UTC). From: Stefan [mailto:netfortius at gmail.com] Sent: Tuesday, June 30, 2015 10:30 PM To: frnkblk at iname.com Cc: nanog at nanog.org Subject: Re: leap second outage This was supposed to have happened @midnight UTC, right? Meaning that we are past that event. Under which scenarios should people be concerned about midnight local time? Lots of confusing messages flying all over... On Jun 30, 2015 10:13 PM, > wrote: We experienced our first leap second outage -- our SHE (super head end) is using (old) Motorola encoders and we lost those video channels. They restarted all those encoders to restore service. Frank From mysidia at gmail.com Wed Jul 1 12:42:34 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 1 Jul 2015 07:42:34 -0500 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> <559375B7.4010908@vaxination.ca> Message-ID: On Wed, Jul 1, 2015 at 12:38 AM, Mikael Abrahamsson wrote: > quickly. Either we should abolish the leap second or we should make leap > second adjustments (back and forth) on a monthly basis to exercise the code. See.... maybe there should some day be building codes for commercially marketed software that provide minimum independent formal testing to be done by licensed independent testers, including leap seconds and such. ^_^ The leap second issues are possibly rare and intermittent, therefore, having a few per month is not necessarily giving adequate exposure to code paths that may go wrong during an insert/del event. There's never been a negative leap second, only insertions, but how deletions are implemented might expose new bugs, since there hasn't been one before, And you can only have one leap per 24 hours, positive or minus, pick one. & Shouldn't this kind of 'exercise' be done during the QA process before releasing new system software, rather than mucking with clock accuracy? There is a recent article with some Leap Second 'stress testing' code: https://access.redhat.com/articles/199563 Readily available test methods are available, there ought to be little legitimate excuse for anyone writing serious software that has long-running processes or threads not to include evaluation for possible leap second issues and other possible clock-related issues such as clock stepping, DST, and Year 2038 in their standard smoke tests.... > -- > Mikael Abrahamsson email: swmike at swm.pp.se -- -JH From brooks at firestormnetworks.net Wed Jul 1 00:43:11 2015 From: brooks at firestormnetworks.net (Brooks Bridges) Date: Tue, 30 Jun 2015 17:43:11 -0700 Subject: Sacramento Outage. In-Reply-To: <5593363C.9040806@cox.net> References: <5593363C.9040806@cox.net> Message-ID: <5593379F.30707@firestormnetworks.net> I suspect most people here also sub the outages lists https://puck.nether.net/pipermail/outages/2015-June/007904.html Brooks Bridges On 6/30/2015 5:37 PM, Larry Sheldon wrote: > > Is it odd that there is no mention of this even here? > > http://www.wavebroadband.com/resources/outage/service.txt From duga95 at gmail.com Wed Jul 1 00:44:57 2015 From: duga95 at gmail.com (Duga) Date: Tue, 30 Jun 2015 19:44:57 -0500 Subject: Sacramento Outage. In-Reply-To: <5593363C.9040806@cox.net> References: <5593363C.9040806@cox.net> Message-ID: <73E23519-8F84-4B38-B4B0-44EC680EB5BA@gmail.com> Was surprised too. http://www.usatoday.com/story/tech/2015/06/30/california-internet-outage/29521335/ > On 30 Jun 2015, at 19:37, Larry Sheldon wrote: > > > Is it odd that there is no mention of this even here? > > http://www.wavebroadband.com/resources/outage/service.txt > -- > sed quis custodiet ipsos custodes? (Juvenal) From guilherme.ganascim at persistelecom.com.br Wed Jul 1 01:08:28 2015 From: guilherme.ganascim at persistelecom.com.br (Guilherme Ganascim) Date: Tue, 30 Jun 2015 22:08:28 -0300 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> Message-ID: <49E63237-24DA-4C22-B2D5-F79B983EA27F@persistelecom.com.br> I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 and other versions. Configured NTP Client in all of them. Anyone else had this problem? > On Jun 19, 2015, at 19:30, Baldur Norddahl wrote: > > On 19 June 2015 at 23:58, Harlan Stenn wrote: > >> Bad idea. >> >> When restarting ntpd your clocks will likely be off by a second, which >> will cause a backward step, which will force the problem you claim to be >> avoiding. >> > > If you are afraid that your routers will crash due to the leapsecond, then > it would help to disable the thing that you think will crash them. Even if > the router crashes when you enable it later on. Because then you can have > one router crash at a time and have it happen in a service window where you > are ready for it. Instead of having all routers in your whole network crash > at exactly the same time. > > Regards, > > Baldur From justin at cloudflare.com Wed Jul 1 03:37:06 2015 From: justin at cloudflare.com (Justin Paine) Date: Tue, 30 Jun 2015 20:37:06 -0700 Subject: leap second outage In-Reply-To: <1403982207-1435721578-cardhu_decombobulator_blackberry.rim.net-897464758-@b11.c3.bise6.blackberry> References: <1403982207-1435721578-cardhu_decombobulator_blackberry.rim.net-897464758-@b11.c3.bise6.blackberry> Message-ID: Any confirmation if the AWS outage was leap second-related? ____________ Justin Paine Head of Trust & Safety CloudFlare Inc. PGP KeyID: 57B6 0114 DE0B 314D On Tue, Jun 30, 2015 at 8:32 PM, Dovid Bender wrote: > I read that and that at midnight local time since that's when you have the extra second. I know a large carrier in Israel is down. Waiting for conf. If it's leep second related. > > ------Original Message------ > From: Stefan > Sender: NANOG > To: frnkblk at iname.com > Cc: nanog at nanog.org > Subject: Re: leap second outage > Sent: Jun 30, 2015 23:30 > > This was supposed to have happened @midnight UTC, right? Meaning that we > are past that event. Under which scenarios should people be concerned about > midnight local time? Lots of confusing messages flying all over... > On Jun 30, 2015 10:13 PM, wrote: > >> We experienced our first leap second outage -- our SHE (super head end) is >> using (old) Motorola encoders and we lost those video channels. They >> restarted all those encoders to restore service. >> >> Frank >> >> > > Regards, > > Dovid From nanog at ics-il.net Wed Jul 1 13:17:41 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 Jul 2015 08:17:41 -0500 (CDT) Subject: REMINDER: LEAP SECOND In-Reply-To: <49E63237-24DA-4C22-B2D5-F79B983EA27F@persistelecom.com.br> Message-ID: <1972931982.3896.1435756636670.JavaMail.mhammett@ThunderFuck> It looks to have only affected the CCR line and only those running the NTP and not the SNTP package. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Guilherme Ganascim" To: nanog at nanog.org Sent: Tuesday, June 30, 2015 8:08:28 PM Subject: Re: REMINDER: LEAP SECOND I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 and other versions. Configured NTP Client in all of them. Anyone else had this problem? > On Jun 19, 2015, at 19:30, Baldur Norddahl wrote: > > On 19 June 2015 at 23:58, Harlan Stenn wrote: > >> Bad idea. >> >> When restarting ntpd your clocks will likely be off by a second, which >> will cause a backward step, which will force the problem you claim to be >> avoiding. >> > > If you are afraid that your routers will crash due to the leapsecond, then > it would help to disable the thing that you think will crash them. Even if > the router crashes when you enable it later on. Because then you can have > one router crash at a time and have it happen in a service window where you > are ready for it. Instead of having all routers in your whole network crash > at exactly the same time. > > Regards, > > Baldur From rubensk at gmail.com Wed Jul 1 13:24:38 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 1 Jul 2015 10:24:38 -0300 Subject: REMINDER: LEAP SECOND In-Reply-To: <1972931982.3896.1435756636670.JavaMail.mhammett@ThunderFuck> References: <49E63237-24DA-4C22-B2D5-F79B983EA27F@persistelecom.com.br> <1972931982.3896.1435756636670.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, Jul 1, 2015 at 10:17 AM, Mike Hammett wrote: > It looks to have only affected the CCR line and only those running the NTP > and not the SNTP package. > > That's Mikrotik's position, but reports of some users contradict their version (both in the need for NTP and for only affecting CCR line), although the NTP package is clearly a contributing factor. Rubens From jared at puck.Nether.net Wed Jul 1 14:12:55 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Wed, 1 Jul 2015 10:12:55 -0400 Subject: Route leak in Bangladesh In-Reply-To: <559387C2.8020603@seacom.mu> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> Message-ID: <20150701141254.GA31989@puck.nether.net> On Wed, Jul 01, 2015 at 08:25:06AM +0200, Mark Tinka wrote: > > > On 30/Jun/15 17:09, Job Snijders wrote: > > > > If you are a network providing transit to the leak originator mentioned > > in the above paragraph, I believe a prefix based filter could have made > > a big difference. > > And therein lies the secret sauce. > > Given that we've had an incident like this twice in the past month, I'm > seriously concerned about the network operations of "top-tier" providers. I'll say we certainly try hard to mitigate these issues. It's hard because while platitudes on this list don't cause IOS devices to not send a full routing table by default (for example). I would like to see others participate in the dialog with vendors so we don't seem to be quite an outlier with "wow, you have really large configs". The vendors haven't quite kept pace with the increase in density proportional to the number of configuration lines and it sure feels like we are the only people pushing them to improve. This combined with the number of devices that are doing kinky routing to 'optmize' a network make it more likely that something will cause damage. rfc1925 2.(9)a applies. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From frnog at shrd.fr Wed Jul 1 14:15:39 2015 From: frnog at shrd.fr (Michel Luczak) Date: Wed, 1 Jul 2015 16:15:39 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: <49E63237-24DA-4C22-B2D5-F79B983EA27F@persistelecom.com.br> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <49E63237-24DA-4C22-B2D5-F79B983EA27F@persistelecom.com.br> Message-ID: > I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 and other versions. > > Configured NTP Client in all of them. > > Anyone else had this problem? Apparently 6.27 was the safe version to have (no issues on our CRS and CCR routers). Regards, Michel From rubensk at gmail.com Wed Jul 1 14:25:54 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 1 Jul 2015 11:25:54 -0300 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <49E63237-24DA-4C22-B2D5-F79B983EA27F@persistelecom.com.br> Message-ID: On Wed, Jul 1, 2015 at 11:15 AM, Michel Luczak wrote: > > I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, > 6.5 and other versions. > > > > Configured NTP Client in all of them. > > > > Anyone else had this problem? > > Apparently 6.27 was the safe version to have (no issues on our CRS and CCR > routers). > > > Not quite. Reported crashes included 6.27, so it's possible that some other mitigating factor helped not to crash (like using SNTP instead of NTP, although there seems to be people with crashes using SNTP or no SNTP/NTP at all). Variations also include whether hardware watchdog was able to reboot the box or it just froze (including frontal display not responding). Rubens From cma at cmadams.net Wed Jul 1 14:39:09 2015 From: cma at cmadams.net (Chris Adams) Date: Wed, 1 Jul 2015 09:39:09 -0500 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <49E63237-24DA-4C22-B2D5-F79B983EA27F@persistelecom.com.br> Message-ID: <20150701143909.GA21302@cmadams.net> Once upon a time, Rubens Kuhl said: > Not quite. Reported crashes included 6.27, so it's possible that some other > mitigating factor helped not to crash (like using SNTP instead of NTP, > although there seems to be people with crashes using SNTP or no SNTP/NTP at > all). These are running Linux kernels, right? Anybody know which version? I know the last couple of leap seconds hit (different) bugs in the Linux kernel. The 2012 bug was timer related and confused some user-space applications, but the 2008 bug could cause a kernel deadlock (which this sounds like). -- Chris Adams From mark.tinka at seacom.mu Wed Jul 1 14:51:30 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jul 2015 16:51:30 +0200 Subject: Route leak in Bangladesh In-Reply-To: <20150701141254.GA31989@puck.nether.net> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> Message-ID: <5593FE72.8060203@seacom.mu> On 1/Jul/15 16:12, Jared Mauch wrote: > > I would like to see others participate in the dialog with vendors > so we don't seem to be quite an outlier with "wow, you have really > large configs". The vendors haven't quite kept pace with the increase > in density proportional to the number of configuration lines and > it sure feels like we are the only people pushing them to improve. I'm happy to help beat up the vendors (it's a favorite pass time of mine), but I'll be honest, we don't particularly have this problem in our network because - well, besides being a reasonably young operation - we do the opposite where we request customers to provide their prefix data, and we upload that into the network, together with strict AS_PATH lists (and max-prefix to boot). I found RPSL complicated a few years ago, and sort of put that on the back-burner. I have looked at it less in recent times because I'm putting quite a bit of work into RPKI (vendor implementation issues have been slowing me down, though, but we're looking better compared to just twelve months ago). So perhaps if there are other operators on this list using RPSL to build reasonably large configuration files that are testing the limits of router code, I echo Jared's plea to beat up your vendors and make this a priority, before we all get taken offline for the 3rd time in one year by the next boo-boo. And for anyone running Brocade, extra points if we can get them to implement RPKI as well :-)... Mark. From nick at foobar.org Wed Jul 1 14:52:41 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 1 Jul 2015 15:52:41 +0100 Subject: Route leak in Bangladesh In-Reply-To: <20150701141254.GA31989@puck.nether.net> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> Message-ID: <5593FEB9.5090101@foobar.org> On 01/07/2015 15:12, Jared Mauch wrote: > I would like to see others participate in the dialog with vendors > so we don't seem to be quite an outlier with "wow, you have really > large configs". The vendors haven't quite kept pace with the increase > in density proportional to the number of configuration lines and > it sure feels like we are the only people pushing them to improve. This is a strange sort of thing really. There's no reason that a compiled prefix list of 250k entries should take up much RAM in a trie structure; there's no reason that a competently written parser shouldn't be able to handle 20 megs of prefix lists / sets in a trivial amount of time and there's no reason that writing a 20 meg configuration file should take long to write to disk / flash / etc. BIRD handles this in ultraquick time. Even recent versions of Quagga can now suck + parse 10 megs of prefix filters in a second or two and write them out in less. But Junos / IOS / XR puke horribly. What gives? Nick From nick at foobar.org Wed Jul 1 14:54:16 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 1 Jul 2015 15:54:16 +0100 Subject: Route leak in Bangladesh In-Reply-To: <5593FE72.8060203@seacom.mu> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FE72.8060203@seacom.mu> Message-ID: <5593FF18.3040903@foobar.org> On 01/07/2015 15:51, Mark Tinka wrote: > I found RPSL complicated a few years ago, and sort of put that on the > back-burner. you probably want to ignore more rpsl constructs and depend solely on as-sets, aut-nums and route/route6 objects. RPSL is not going to live up to your expectations. Nick From mark.tinka at seacom.mu Wed Jul 1 14:57:21 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jul 2015 16:57:21 +0200 Subject: Route leak in Bangladesh In-Reply-To: <5593FEB9.5090101@foobar.org> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FEB9.5090101@foobar.org> Message-ID: <5593FFD1.1000008@seacom.mu> On 1/Jul/15 16:52, Nick Hilliard wrote: > This is a strange sort of thing really. There's no reason that a compiled > prefix list of 250k entries should take up much RAM in a trie structure; > there's no reason that a competently written parser shouldn't be able to > handle 20 megs of prefix lists / sets in a trivial amount of time and > there's no reason that writing a 20 meg configuration file should take long > to write to disk / flash / etc. > > BIRD handles this in ultraquick time. Even recent versions of Quagga can > now suck + parse 10 megs of prefix filters in a second or two and write > them out in less. > > But Junos / IOS / XR puke horribly. What gives? Nick, I think the concerns are two-fold: 1. The time it takes to process the trie. 2. How much physical space there is to support the configuration. Remember some high-end Cisco routers only have 2MB of NVRAM. This could get tested with a large prefix-list configuration. Junos may not have much of a space issue since the configuration is stored on the compact flash or HDD. Trie compilation or process will be very OS-dependent, and how the vendor has chosen to optimize that operation. Mark. From mark.tinka at seacom.mu Wed Jul 1 15:02:13 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jul 2015 17:02:13 +0200 Subject: Route leak in Bangladesh In-Reply-To: <5593FF18.3040903@foobar.org> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FE72.8060203@seacom.mu> <5593FF18.3040903@foobar.org> Message-ID: <559400F5.60401@seacom.mu> On 1/Jul/15 16:54, Nick Hilliard wrote: > you probably want to ignore more rpsl constructs and depend solely on > as-sets, aut-nums and route/route6 objects. RPSL is not going to live up > to your expectations. Honestly, I'm ambivalent about using the IRR data for prefix-list generation (even without RPSL), also because of how much junk there is in there, and also how redundant some of it really is, e.g., someone creating a /32 (IPv4) route object and yet we only accept up to a /24 (IPv4) on the actual eBGP session, e.t.c. What I'm more focused is how we can continue to scale our current system, which is much more strict, focuses on deploying customer aggregates + le 24 & le 128, instead of enumerating all possible de-aggregates that have been registered in the IRR (helps keep the configuration file small and manageable, without sacrificing reachability). And then see how we can add RPKI into the mix to make things even simpler, if at all. Mark. From jared at puck.Nether.net Wed Jul 1 15:03:36 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Wed, 1 Jul 2015 11:03:36 -0400 Subject: Route leak in Bangladesh In-Reply-To: <5593FF18.3040903@foobar.org> References: <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FE72.8060203@seacom.mu> <5593FF18.3040903@foobar.org> Message-ID: <20150701150336.GC6380@puck.nether.net> On Wed, Jul 01, 2015 at 03:54:16PM +0100, Nick Hilliard wrote: > On 01/07/2015 15:51, Mark Tinka wrote: > > I found RPSL complicated a few years ago, and sort of put that on the > > back-burner. > > you probably want to ignore more rpsl constructs and depend solely on > as-sets, aut-nums and route/route6 objects. RPSL is not going to live up > to your expectations. Yes, like any technology there are lots of knobs that one could use but are not recommended. You just need these few objects and life will be simple. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nick at foobar.org Wed Jul 1 15:04:47 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 1 Jul 2015 16:04:47 +0100 Subject: Route leak in Bangladesh In-Reply-To: <5593FFD1.1000008@seacom.mu> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FEB9.5090101@foobar.org> <5593FFD1.1000008@seacom.mu> Message-ID: <5594018F.2080300@foobar.org> On 01/07/2015 15:57, Mark Tinka wrote: > Remember some high-end Cisco routers only have 2MB of NVRAM. This could > get tested with a large prefix-list configuration. Junos may not have > much of a space issue since the configuration is stored on the compact > flash or HDD. Not at all. Even C6500 could store startup-config on external CF which could be 2G. > Trie compilation or process will be very OS-dependent, and how the > vendor has chosen to optimize that operation. Naah, trie compilation is simple, particularly with a line oriented configuration like IOS (one of the worse offenders). Once the config is syntax-checked, a regexp will split it out trivially and the binary form of the data can be compiled. Even on Junos, that sort of config will be handled by lex/yacc, which is highly optimised. Insertion / deletion of data in a patricia trie is ridiculously fast and there are a couple of bsd licensed implementations out there. Nick From mark.tinka at seacom.mu Wed Jul 1 15:08:36 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jul 2015 17:08:36 +0200 Subject: Route leak in Bangladesh In-Reply-To: <5594018F.2080300@foobar.org> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FEB9.5090101@foobar.org> <5593FFD1.1000008@seacom.mu> <5594018F.2080300@foobar.org> Message-ID: <55940274.3050608@seacom.mu> On 1/Jul/15 17:04, Nick Hilliard wrote: > Naah, trie compilation is simple, particularly with a line oriented > configuration like IOS (one of the worse offenders). Once the config is > syntax-checked, a regexp will split it out trivially and the binary form of > the data can be compiled. Even on Junos, that sort of config will be > handled by lex/yacc, which is highly optimised. > > Insertion / deletion of data in a patricia trie is ridiculously fast and > there are a couple of bsd licensed implementations out there. My experience around this was mostly when Cisco began introducing Turbo ACL's. There seemed to be a few problems around that time, but it was such a long time ago that I barely remember the details. That said, I'm not quite sure if there are specific issues Jared and others are facing around this in their networks. From my side, none that we have witnessed. But then again, our configurations are significantly smaller because we do not take data from the IRR. Mark. From nick at foobar.org Wed Jul 1 15:11:13 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 1 Jul 2015 16:11:13 +0100 Subject: Route leak in Bangladesh In-Reply-To: <559400F5.60401@seacom.mu> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FE72.8060203@seacom.mu> <5593FF18.3040903@foobar.org> <559400F5.60401@seacom.mu> Message-ID: <55940311.9060401@foobar.org> On 01/07/2015 16:02, Mark Tinka wrote: > Honestly, I'm ambivalent about using the IRR data for prefix-list > generation (even without RPSL), also because of how much junk there is > in there, and also how redundant some of it really is, e.g., someone > creating a /32 (IPv4) route object and yet we only accept up to a /24 > (IPv4) on the actual eBGP session, e.t.c. We went through this a couple of years ago at INEX and ended up with a provisioning system which allows the operator to only allow specific IRRDB source: entries, customisable per customer. You're right that it would be foolish to accept any IRRDB source because a lot of them are complete trash. Otherwise, it works incredibly well for us and has stopped innumerable prefix leaks and other silly misconfigs. The source code is available on github.com/inex. Lots of IXPs use it in production. Nick From nanog at ics-il.net Wed Jul 1 15:53:42 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 Jul 2015 10:53:42 -0500 (CDT) Subject: Route leak in Bangladesh In-Reply-To: <55940311.9060401@foobar.org> Message-ID: <626766182.4821.1435766050053.JavaMail.mhammett@ThunderFuck> That they do. Thanks for a great system, BTW! ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Nick Hilliard" To: "Mark Tinka" , "Jared Mauch" Cc: "North American Network Operators' Group" Sent: Wednesday, July 1, 2015 10:11:13 AM Subject: Re: Route leak in Bangladesh On 01/07/2015 16:02, Mark Tinka wrote: > Honestly, I'm ambivalent about using the IRR data for prefix-list > generation (even without RPSL), also because of how much junk there is > in there, and also how redundant some of it really is, e.g., someone > creating a /32 (IPv4) route object and yet we only accept up to a /24 > (IPv4) on the actual eBGP session, e.t.c. We went through this a couple of years ago at INEX and ended up with a provisioning system which allows the operator to only allow specific IRRDB source: entries, customisable per customer. You're right that it would be foolish to accept any IRRDB source because a lot of them are complete trash. Otherwise, it works incredibly well for us and has stopped innumerable prefix leaks and other silly misconfigs. The source code is available on github.com/inex. Lots of IXPs use it in production. Nick From jabley at hopcount.ca Wed Jul 1 16:03:16 2015 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 01 Jul 2015 12:03:16 -0400 Subject: Route leak in Bangladesh In-Reply-To: <20150701150336.GC6380@puck.nether.net> References: <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FE72.8060203@seacom.mu> <5593FF18.3040903@foobar.org> <20150701150336.GC6380@puck.nether.net> Message-ID: <7EC6EFE3-2C79-4E7C-899B-FA207975F4FE@hopcount.ca> On 1 Jul 2015, at 11:03, Jared Mauch wrote: > On Wed, Jul 01, 2015 at 03:54:16PM +0100, Nick Hilliard wrote: >> On 01/07/2015 15:51, Mark Tinka wrote: >>> I found RPSL complicated a few years ago, and sort of put that on >>> the >>> back-burner. >> >> you probably want to ignore more rpsl constructs and depend solely on >> as-sets, aut-nums and route/route6 objects. RPSL is not going to >> live up >> to your expectations. > > Yes, like any technology there are lots of knobs that one could > use but are not recommended. > > You just need these few objects and life will be simple. ... as long as the people responsible for maintaining those as-sets don't get confused and include lots of other inappropriate as-sets by reference, right? The idea of configuring this stuff from the IRR is great in terms of distributing the ops cycles in the right places, but it doesn't help with verifying that the end result isn't insane, as I think you and Mike have described on this list over the past couple of days. Joe From nick at foobar.org Wed Jul 1 16:08:01 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 1 Jul 2015 17:08:01 +0100 Subject: Route leak in Bangladesh In-Reply-To: <7EC6EFE3-2C79-4E7C-899B-FA207975F4FE@hopcount.ca> References: <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FE72.8060203@seacom.mu> <5593FF18.3040903@foobar.org> <20150701150336.GC6380@puck.nether.net> <7EC6EFE3-2C79-4E7C-899B-FA207975F4FE@hopcount.ca> Message-ID: <55941061.4040804@foobar.org> On 01/07/2015 17:03, Joe Abley wrote: > The idea of configuring this stuff from the IRR is great in terms of > distributing the ops cycles in the right places, but it doesn't help with > verifying that the end result isn't insane, as I think you and Mike have > described on this list over the past couple of days. that doesn't invalidate it as being part of a critical mechanism for filtering ebgp. Implemented well, it will catch 99% of problems. maxprefixes with no autorecover catches 75% of the rest. Between these two mechanisms, that's pretty good. Nick From kenneth.mcrae at me.com Wed Jul 1 16:15:04 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Wed, 01 Jul 2015 16:15:04 +0000 (GMT) Subject: =?utf-8?B?UmU6IEdSRSBwZXJmb3JtYW5jZSBvdmVyIHRoZSBJbnRlcm5ldCAtIEREb1Mg?= =?utf-8?B?Y2xvdWQgbWl0aWdhdGlvbg==?= Message-ID: <32fa170d-ed9b-413c-bb83-a8b1bbc30d85@me.com> How stable can GRE transports and BGP?sessions be when under load? ? I typically protect the BGP session by policing all traffic being delivered to the remote end except for BGP. ?Using this posture, my BGP session over GRE are stable; even under attack. Kenneth? On Jun 30, 2015, at 01:37 PM, Dennis B wrote: Roland, Agreed, Ramy's scenario was not truly spot on, but his question still remains. Perf implications when cloud security providers time to detect/mitigate is X minutes. How stable can GRE transports and BGP sessions be when under load? In my technical opinion, this is a valid argument, which deems wide opinion. Specifically, use-cases about how to apply defense in depth logically in the DC vs Hybrid vs Pure Cloud. Good topic, already some back-chatter personal opinions from Nanog lurkers! Regards, Dennis B. On Tue, Jun 30, 2015 at 2:45 PM, Roland Dobbins wrote: On 1 Jul 2015, at 1:37, Dennis B wrote: Would you like to learn more? lol I'm quite conversant with all these considerations, thanks. OP asserted that BGP sessions for diversion into any cloud DDoS mitigation service ran from the endpoint network through GRE tunnels to the cloud-based mitigation provider. I was explaining that in most cloud mitigation scenarios, GRE tunnels are used for re-injection of 'clean' traffic to the endpoint networks. ----------------------------------- Roland Dobbins From bill at herrin.us Wed Jul 1 16:42:25 2015 From: bill at herrin.us (William Herrin) Date: Wed, 1 Jul 2015 12:42:25 -0400 Subject: in-cabinet PDU safety regs? Message-ID: Hi Folks, Do you know of any regulations, standards or publications covering the safe installation and use of the little 1U and 2U PDUs in rack cabinets? My google fu is failing me. All I've found is OSHA 1926.403(i)(1)(i) (https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_id=10704) and I'm not 100% sure it applies. Thanks in advance, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From nanog at ics-il.net Wed Jul 1 16:43:38 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 Jul 2015 11:43:38 -0500 (CDT) Subject: REMINDER: LEAP SECOND In-Reply-To: <20150701143909.GA21302@cmadams.net> Message-ID: <1167688244.5050.1435769040800.JavaMail.mhammett@ThunderFuck> v5 is 2.4, v6 3.3.5 ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Chris Adams" To: nanog at nanog.org Sent: Wednesday, July 1, 2015 9:39:09 AM Subject: Re: REMINDER: LEAP SECOND Once upon a time, Rubens Kuhl said: > Not quite. Reported crashes included 6.27, so it's possible that some other > mitigating factor helped not to crash (like using SNTP instead of NTP, > although there seems to be people with crashes using SNTP or no SNTP/NTP at > all). These are running Linux kernels, right? Anybody know which version? I know the last couple of leap seconds hit (different) bugs in the Linux kernel. The 2012 bug was timer related and confused some user-space applications, but the 2008 bug could cause a kernel deadlock (which this sounds like). -- Chris Adams From jra at baylink.com Wed Jul 1 16:45:36 2015 From: jra at baylink.com (Jay Ashworth) Date: Wed, 1 Jul 2015 12:45:36 -0400 (EDT) Subject: Leap Second Folo/After Action Message-ID: <9878140.24.1435769136887.JavaMail.root@benjamin.baylink.com> Here's LWN's piece on the then-upcoming event from last week, presumably with comments trailing into today. http://lwn.net/Articles/648313/ How'd it go for everyone? Did the world end? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From kmedcalf at dessus.com Wed Jul 1 17:02:19 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 01 Jul 2015 13:02:19 -0400 Subject: [outages] CenturyLink fiber cut between Modesto, CA and San Jose, CA this AM.. Start time 4:26AM PST In-Reply-To: <2n0sm18jcrfslnekos5i25bg.1435697808781@email.android.com> Message-ID: Have they asked No-Such-Agency? No-Such-Agency typically taps communication lines by "back-hoe accident" of some sort on the path they are interested in tapping. That way they can install a tap "over yonder" while the victim telecom is attempting to repair the original damage. I guess this time is taking longer than expected so they FBI has been recruited to prevent the victim from completing repairs to quickly. Then again, maybe my tinfoil hat is too tight. > -----Original Message----- > From: Outages [mailto:outages-bounces at outages.org] On Behalf Of Hugo > Slabbert via Outages > Sent: Tuesday, 30 June, 2015 16:57 > To: Peter Kranz via Outages; Peter Kranz > Subject: Re: [outages] CenturyLink fiber cut between Modesto, CA and San > Jose, CA this AM.. Start time 4:26AM PST > > Related? > > http://arstechnica.com/tech-policy/2015/06/fbi-baffled-over-wave-of- > nighttime-fiber-optic-cable-vandalism/ > > -- > Hugo > > > > ---- Peter Kranz via Outages wrote ---- > > > This appears to be part of a larger act of intentional sabotage: > > "We have just been advised that crews have been removed from the area > while > law enforcement investigates the damage, which was caused by vandalism. > Three enclosures were damaged impacting three different carriers. There is > no time given for when they will be allowed to begin work again, > subsequently, there is still no ETR. > " > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages From surfer at mauigateway.com Wed Jul 1 17:55:29 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 1 Jul 2015 10:55:29 -0700 Subject: Leap Second Folo/After Action Message-ID: <20150701105529.1DAE530A@m0005298.ppops.net> --- jra at baylink.com wrote: From: Jay Ashworth Here's LWN's piece on the then-upcoming event from last week, presumably with comments trailing into today. http://lwn.net/Articles/648313/ How'd it go for everyone? Did the world end? ----------------------------------------------- Not one single problem. Yay! :-) scott From goemon at anime.net Wed Jul 1 18:07:42 2015 From: goemon at anime.net (goemon at anime.net) Date: Wed, 1 Jul 2015 11:07:42 -0700 (PDT) Subject: Leap Second Folo/After Action In-Reply-To: <9878140.24.1435769136887.JavaMail.root@benjamin.baylink.com> References: <9878140.24.1435769136887.JavaMail.root@benjamin.baylink.com> Message-ID: supposedly vulnerable devices sailed through without a peep. -Dan On Wed, 1 Jul 2015, Jay Ashworth wrote: > Here's LWN's piece on the then-upcoming event from last week, presumably > with comments trailing into today. > > http://lwn.net/Articles/648313/ > > How'd it go for everyone? Did the world end? > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > From cma at cmadams.net Wed Jul 1 18:17:06 2015 From: cma at cmadams.net (Chris Adams) Date: Wed, 1 Jul 2015 13:17:06 -0500 Subject: REMINDER: LEAP SECOND In-Reply-To: <1167688244.5050.1435769040800.JavaMail.mhammett@ThunderFuck> References: <20150701143909.GA21302@cmadams.net> <1167688244.5050.1435769040800.JavaMail.mhammett@ThunderFuck> Message-ID: <20150701181706.GB21302@cmadams.net> Once upon a time, Mike Hammett said: > v5 is 2.4, v6 3.3.5 Don't know why a 3.3.5 kernel would have deadlocked; don't think there are any known issues that would cause that, unless there are Mikrotik specific patches that caused the problem. I believe the bug from the 2008 leap second was present in kernels in 2.4 up through 2.6.26 (although Red Hat at least patched it in their older version long-term support kernels). -- Chris Adams From nanog at ics-il.net Wed Jul 1 18:19:31 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 Jul 2015 13:19:31 -0500 (CDT) Subject: REMINDER: LEAP SECOND In-Reply-To: <20150701181706.GB21302@cmadams.net> Message-ID: <1361420135.311.1435774786254.JavaMail.mhammett@ThunderFuck> The only v6 ones that are sure to have had the problem are based on tilera chips and one of two NTP packages available. *shrugs* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Chris Adams" To: nanog at nanog.org Sent: Wednesday, July 1, 2015 1:17:06 PM Subject: Re: REMINDER: LEAP SECOND Once upon a time, Mike Hammett said: > v5 is 2.4, v6 3.3.5 Don't know why a 3.3.5 kernel would have deadlocked; don't think there are any known issues that would cause that, unless there are Mikrotik specific patches that caused the problem. I believe the bug from the 2008 leap second was present in kernels in 2.4 up through 2.6.26 (although Red Hat at least patched it in their older version long-term support kernels). -- Chris Adams From rubensk at gmail.com Wed Jul 1 18:20:30 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 1 Jul 2015 15:20:30 -0300 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150701181706.GB21302@cmadams.net> References: <20150701143909.GA21302@cmadams.net> <1167688244.5050.1435769040800.JavaMail.mhammett@ThunderFuck> <20150701181706.GB21302@cmadams.net> Message-ID: On Wed, Jul 1, 2015 at 3:17 PM, Chris Adams wrote: > Once upon a time, Mike Hammett said: > > v5 is 2.4, v6 3.3.5 > > Don't know why a 3.3.5 kernel would have deadlocked; don't think there > are any known issues that would cause that, unless there are Mikrotik > specific patches that caused the problem. > > I believe the bug from the 2008 leap second was present in kernels in > 2.4 up through 2.6.26 (although Red Hat at least patched it in their > older version long-term support kernels). > 3.3 was listed as buggy in this regard as well. Rubens From mark.tinka at seacom.mu Wed Jul 1 18:23:44 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 1 Jul 2015 20:23:44 +0200 Subject: Route leak in Bangladesh In-Reply-To: <55940311.9060401@foobar.org> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FE72.8060203@seacom.mu> <5593FF18.3040903@foobar.org> <559400F5.60401@seacom.mu> <55940311.9060401@foobar.org> Message-ID: <55943030.5040907@seacom.mu> On 1/Jul/15 17:11, Nick Hilliard wrote: > > The source code is available on github.com/inex. Lots of IXPs use it in > production. Thanks, Nick. I'll have a bit of a sniff... Mark. From ispcolohost at gmail.com Wed Jul 1 15:19:45 2015 From: ispcolohost at gmail.com (David H) Date: Wed, 1 Jul 2015 11:19:45 -0400 Subject: Inexpensive software bgp router that supports route tags? Message-ID: Hi all, I was wondering if anyone can recommend a software (preferable), or hardware-based router with an API, that supports BGP with tags on advertised routes? I want to use it for a RTBH feed and having it in software would make certain things easier to automate. I tried Quagga/Zebra but it doesn't support tags. I see Mikrotik hardware routers have an API, but I can't tell if the API supports adding BGP networks, so I need to investigate that further. I can go hardware if I have to, with some ssh/expect scripts, but thought there may be other options that are easier. Thanks, David From ian.w.smith at gmail.com Wed Jul 1 17:05:56 2015 From: ian.w.smith at gmail.com (Ian Smith) Date: Wed, 01 Jul 2015 17:05:56 +0000 Subject: in-cabinet PDU safety regs? In-Reply-To: References: Message-ID: If you are in the US, NFPA 70 article 645 may, or may not, apply. http://www.powercabling.com/documents/NEC645.pdf On Wed, Jul 1, 2015, 12:44 William Herrin wrote: > Hi Folks, > > Do you know of any regulations, standards or publications covering the > safe installation and use of the little 1U and 2U PDUs in rack > cabinets? My google fu is failing me. All I've found is OSHA > 1926.403(i)(1)(i) > ( > https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_id=10704 > ) > and I'm not 100% sure it applies. > > Thanks in advance, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From faisal at snappytelecom.net Wed Jul 1 18:36:30 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 1 Jul 2015 18:36:30 +0000 (GMT) Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: References: Message-ID: <1500451465.830397.1435775790301.JavaMail.zimbra@snappytelecom.net> FYI, Mikrotik is software (ROS) you can run it on an x86 platform (physical or virtual machine). Not sure about the API and BGP, but they have extensive support for scripting. Additionally check the Mikrotik Forums for other user developed API/Interfaces... Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "David H" > To: nanog at nanog.org > Sent: Wednesday, July 1, 2015 11:19:45 AM > Subject: Inexpensive software bgp router that supports route tags? > > Hi all, I was wondering if anyone can recommend a software (preferable), or > hardware-based router with an API, that supports BGP with tags on > advertised routes? I want to use it for a RTBH feed and having it in > software would make certain things easier to automate. I tried > Quagga/Zebra but it doesn't support tags. I see Mikrotik hardware routers > have an API, but I can't tell if the API supports adding BGP networks, so I > need to investigate that further. I can go hardware if I have to, with > some ssh/expect scripts, but thought there may be other options that are > easier. > > Thanks, > > David > From hvgeekwtrvl at gmail.com Wed Jul 1 18:37:50 2015 From: hvgeekwtrvl at gmail.com (james machado) Date: Wed, 1 Jul 2015 11:37:50 -0700 Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: References: Message-ID: David, check out exabgp https://github.com/Exa-Networks/exabgp james On Wed, Jul 1, 2015 at 8:19 AM, David H wrote: > Hi all, I was wondering if anyone can recommend a software (preferable), or > hardware-based router with an API, that supports BGP with tags on > advertised routes? I want to use it for a RTBH feed and having it in > software would make certain things easier to automate. I tried > Quagga/Zebra but it doesn't support tags. I see Mikrotik hardware routers > have an API, but I can't tell if the API supports adding BGP networks, so I > need to investigate that further. I can go hardware if I have to, with > some ssh/expect scripts, but thought there may be other options that are > easier. > > Thanks, > > David From harbor235 at gmail.com Wed Jul 1 18:39:23 2015 From: harbor235 at gmail.com (harbor235) Date: Wed, 1 Jul 2015 14:39:23 -0400 Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: References: Message-ID: Quagga supports BGP communities, Mike On Wed, Jul 1, 2015 at 11:19 AM, David H wrote: > Hi all, I was wondering if anyone can recommend a software (preferable), or > hardware-based router with an API, that supports BGP with tags on > advertised routes? I want to use it for a RTBH feed and having it in > software would make certain things easier to automate. I tried > Quagga/Zebra but it doesn't support tags. I see Mikrotik hardware routers > have an API, but I can't tell if the API supports adding BGP networks, so I > need to investigate that further. I can go hardware if I have to, with > some ssh/expect scripts, but thought there may be other options that are > easier. > > Thanks, > > David > From pavel.odintsov at gmail.com Wed Jul 1 18:45:30 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 1 Jul 2015 21:45:30 +0300 Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: References: Message-ID: My voice for awesome ExaBGP too! On Wednesday, July 1, 2015, harbor235 wrote: > Quagga supports BGP communities, > > > > Mike > > On Wed, Jul 1, 2015 at 11:19 AM, David H > wrote: > > > Hi all, I was wondering if anyone can recommend a software (preferable), > or > > hardware-based router with an API, that supports BGP with tags on > > advertised routes? I want to use it for a RTBH feed and having it in > > software would make certain things easier to automate. I tried > > Quagga/Zebra but it doesn't support tags. I see Mikrotik hardware > routers > > have an API, but I can't tell if the API supports adding BGP networks, > so I > > need to investigate that further. I can go hardware if I have to, with > > some ssh/expect scripts, but thought there may be other options that are > > easier. > > > > Thanks, > > > > David > > > -- Sincerely yours, Pavel Odintsov From infinityape at gmail.com Wed Jul 1 19:37:52 2015 From: infinityape at gmail.com (Dennis B) Date: Wed, 1 Jul 2015 15:37:52 -0400 Subject: GRE performance over the Internet - DDoS cloud mitigation In-Reply-To: <32fa170d-ed9b-413c-bb83-a8b1bbc30d85@me.com> References: <32fa170d-ed9b-413c-bb83-a8b1bbc30d85@me.com> Message-ID: Kenneth, That would also be my recommendation to this scenario. The only caveat would be to consider the risk in the service-policy dropping legit traffic because the policy. Often times, the PPS rates of a DDoS attack fill's the policy queue up with malicious packets, sending the legit packets into a 'blackhole' or whatever mechanism you use to discard. Rate-limiters / QoS / Service-policies are good for some use cases but not for others, I am confident we all agree. In this case, "buying" time by implementing some initiate tactics to maintain stability is well worth the risk of being hard down. While the mean-time to detect, alert, start blocking, and stop the attack is being completed by the Cloud Provider. >From our perspective, we're talking 1 min averages with 5 min stop time for L3/L4 attacks. Even if these situations were apparent, they'd be short lived. Ramy, Does this answer your question or give you some ideas? It was pointed out to me that this thread started June 8th, didn't see any other replies. DB On Wed, Jul 1, 2015 at 12:15 PM, Kenneth McRae wrote: > How stable can GRE transports and BGP sessions be when under load? > > > I typically protect the BGP session by policing all traffic being > delivered to the remote end except for BGP. Using this posture, my BGP > session over GRE are stable; even under attack. > > Kenneth > > On Jun 30, 2015, at 01:37 PM, Dennis B wrote: > > Roland, > > Agreed, Ramy's scenario was not truly spot on, but his question still > remains. Perf implications when cloud security providers time to > detect/mitigate is X minutes. How stable can GRE transports and BGP > sessions be when under load? > > In my technical opinion, this is a valid argument, which deems wide > opinion. Specifically, use-cases about how to apply defense in depth > logically in the DC vs Hybrid vs Pure Cloud. > > Good topic, already some back-chatter personal opinions from Nanog lurkers! > > Regards, > > Dennis B. > > > On Tue, Jun 30, 2015 at 2:45 PM, Roland Dobbins > wrote: > > > On 1 Jul 2015, at 1:37, Dennis B wrote: > > > Would you like to learn more? lol > > > > I'm quite conversant with all these considerations, thanks. > > > OP asserted that BGP sessions for diversion into any cloud DDoS mitigation > > service ran from the endpoint network through GRE tunnels to the > > cloud-based mitigation provider. I was explaining that in most cloud > > mitigation scenarios, GRE tunnels are used for re-injection of 'clean' > > traffic to the endpoint networks. > > > ----------------------------------- > > Roland Dobbins > > > From nanog at ics-il.net Wed Jul 1 19:38:59 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 Jul 2015 14:38:59 -0500 (CDT) Subject: REMINDER: LEAP SECOND In-Reply-To: Message-ID: <745592747.419.1435779547224.JavaMail.mhammett@ThunderFuck> http://forum.mikrotik.com/viewtopic.php?f=2&t=98138#p488731 ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Rubens Kuhl" To: "Nanog" Sent: Wednesday, July 1, 2015 1:20:30 PM Subject: Re: REMINDER: LEAP SECOND On Wed, Jul 1, 2015 at 3:17 PM, Chris Adams wrote: > Once upon a time, Mike Hammett said: > > v5 is 2.4, v6 3.3.5 > > Don't know why a 3.3.5 kernel would have deadlocked; don't think there > are any known issues that would cause that, unless there are Mikrotik > specific patches that caused the problem. > > I believe the bug from the 2008 leap second was present in kernels in > 2.4 up through 2.6.26 (although Red Hat at least patched it in their > older version long-term support kernels). > 3.3 was listed as buggy in this regard as well. Rubens From job at instituut.net Wed Jul 1 19:41:06 2015 From: job at instituut.net (Job Snijders) Date: Wed, 1 Jul 2015 21:41:06 +0200 Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: References: Message-ID: <20150701194106.GP95870@Vurt.local> On Wed, Jul 01, 2015 at 11:19:45AM -0400, David H wrote: > I was wondering if anyone can recommend a software (preferable), or > hardware-based router with an API, that supports BGP with tags on > advertised routes? I want to use it for a RTBH feed [ ... ] Did you look at BIRD? It is one of the most beautiful open source BGP speakers: http://bird.network.cz/ BIRD does not have anything like an restful API, but you can just generate the config file and reload it on the fly to accomplish the same. Can you elaborate on what you mean with 'tags'? Could you use BGP communities instead? Kind regards, Job From ispcolohost at gmail.com Wed Jul 1 19:42:46 2015 From: ispcolohost at gmail.com (David H) Date: Wed, 1 Jul 2015 15:42:46 -0400 Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: References: Message-ID: Thanks all; I'll check out ExaBGP and the software version of Mikrotik; didn't realize it wasn't tied to hardware. On Wed, Jul 1, 2015 at 11:19 AM, David H wrote: > Hi all, I was wondering if anyone can recommend a software (preferable), > or hardware-based router with an API, that supports BGP with tags on > advertised routes? I want to use it for a RTBH feed and having it in > software would make certain things easier to automate. I tried > Quagga/Zebra but it doesn't support tags. I see Mikrotik hardware routers > have an API, but I can't tell if the API supports adding BGP networks, so I > need to investigate that further. I can go hardware if I have to, with > some ssh/expect scripts, but thought there may be other options that are > easier. > > Thanks, > > David > From ispcolohost at gmail.com Wed Jul 1 19:47:29 2015 From: ispcolohost at gmail.com (David H) Date: Wed, 1 Jul 2015 15:47:29 -0400 Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: <20150701194106.GP95870@Vurt.local> References: <20150701194106.GP95870@Vurt.local> Message-ID: Sorry I wasn't clear on that. Traditionally on a hardware, e.g. cisco/brocade, router performing the RTBH role, I'd add blackhole routes by way of static routes with a particular tag; one tag for block this source, one tag for block this destination. Redistribute static would let route maps operate against those tags to turn into bgp communities being applied to the announcements, and then the real routers can do what they need to do. When I tried out Quagga/Zebra as an alternative, it doesn't work this way, so while it was nice that it could pick up static routes from the OS, or have them added manually just like a hardware router, there was no concept of the route tag getting to Zebra for it to do the rest of the work on the BGP side. I'll check out Bird too; thanks. On Wed, Jul 1, 2015 at 3:41 PM, Job Snijders wrote: > On Wed, Jul 01, 2015 at 11:19:45AM -0400, David H wrote: > > I was wondering if anyone can recommend a software (preferable), or > > hardware-based router with an API, that supports BGP with tags on > > advertised routes? I want to use it for a RTBH feed [ ... ] > > Did you look at BIRD? It is one of the most beautiful open source BGP > speakers: http://bird.network.cz/ > > BIRD does not have anything like an restful API, but you can just > generate the config file and reload it on the fly to accomplish the > same. > > Can you elaborate on what you mean with 'tags'? Could you use BGP > communities instead? > > Kind regards, > > Job > From dwhite at olp.net Wed Jul 1 20:51:30 2015 From: dwhite at olp.net (Dan White) Date: Wed, 1 Jul 2015 15:51:30 -0500 Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: References: <20150701194106.GP95870@Vurt.local> Message-ID: <20150701205130.GO3923@dan.olp.net> On 07/01/15?15:47?-0400, David H wrote: >Sorry I wasn't clear on that. Traditionally on a hardware, e.g. >cisco/brocade, router performing the RTBH role, I'd add blackhole routes by >way of static routes with a particular tag; one tag for block this source, >one tag for block this destination. Redistribute static would let route >maps operate against those tags to turn into bgp communities being applied >to the announcements, and then the real routers can do what they need to >do. When I tried out Quagga/Zebra as an alternative, it doesn't work this >way, so while it was nice that it could pick up static routes from the OS, >or have them added manually just like a hardware router, there was no >concept of the route tag getting to Zebra for it to do the rest of the work >on the BGP side. We're using Quagga to inject blackhole routes upstream, which can match routes on the OS's metric value: # IPv4 blackhole ~$ ip route add 203.0.113.42/32 dev lo metric 666 ! route-map map_bad_routes permit 10 match metric 666 set community xxxxx:yyy ... ! -- Dan White From frnkblk at iname.com Wed Jul 1 20:52:09 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Wed, 1 Jul 2015 15:52:09 -0500 Subject: leap second outage In-Reply-To: <001b01d0b3f6$2c8d9f70$85a8de50$@iname.com> References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> <001b01d0b3f6$2c8d9f70$85a8de50$@iname.com> Message-ID: <002c01d0b43f$cdffd820$69ff8860$@iname.com> And just 12.5% of them required TLC. =) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of frnkblk at iname.com Sent: Wednesday, July 01, 2015 7:05 AM To: 'Stefan' Cc: nanog at nanog.org Subject: RE: leap second outage Yes, happened at 7 pm Central (0:oo UTC). From: Stefan [mailto:netfortius at gmail.com] Sent: Tuesday, June 30, 2015 10:30 PM To: frnkblk at iname.com Cc: nanog at nanog.org Subject: Re: leap second outage This was supposed to have happened @midnight UTC, right? Meaning that we are past that event. Under which scenarios should people be concerned about midnight local time? Lots of confusing messages flying all over... On Jun 30, 2015 10:13 PM, > wrote: We experienced our first leap second outage -- our SHE (super head end) is using (old) Motorola encoders and we lost those video channels. They restarted all those encoders to restore service. Frank From raphael.timothy at gmail.com Wed Jul 1 23:11:52 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Thu, 2 Jul 2015 07:11:52 +0800 Subject: leap second outage In-Reply-To: References: <1403982207-1435721578-cardhu_decombobulator_blackberry.rim.net-897464758-@b11.c3.bise6.blackberry> Message-ID: <02AE85D5-ECD1-4E75-8D5D-B6F987BB2C62@gmail.com> No, it was a route leak by a colo provider (Axcelx) downstream. Regards, Tim Raphael > On 1 Jul 2015, at 11:37 am, Justin Paine via NANOG wrote: > > Any confirmation if the AWS outage was leap second-related? > > ____________ > Justin Paine > Head of Trust & Safety > CloudFlare Inc. > PGP KeyID: 57B6 0114 DE0B 314D > > >> On Tue, Jun 30, 2015 at 8:32 PM, Dovid Bender wrote: >> I read that and that at midnight local time since that's when you have the extra second. I know a large carrier in Israel is down. Waiting for conf. If it's leep second related. >> >> ------Original Message------ >> From: Stefan >> Sender: NANOG >> To: frnkblk at iname.com >> Cc: nanog at nanog.org >> Subject: Re: leap second outage >> Sent: Jun 30, 2015 23:30 >> >> This was supposed to have happened @midnight UTC, right? Meaning that we >> are past that event. Under which scenarios should people be concerned about >> midnight local time? Lots of confusing messages flying all over... >>> On Jun 30, 2015 10:13 PM, wrote: >>> >>> We experienced our first leap second outage -- our SHE (super head end) is >>> using (old) Motorola encoders and we lost those video channels. They >>> restarted all those encoders to restore service. >>> >>> Frank >> >> Regards, >> >> Dovid From stenn at ntp.org Thu Jul 2 00:41:09 2015 From: stenn at ntp.org (Harlan Stenn) Date: Thu, 02 Jul 2015 00:41:09 +0000 Subject: leap second outage In-Reply-To: References: <001a01d0b3ab$b6da3e40$248ebac0$@iname.com> <559375B7.4010908@vaxination.ca> Message-ID: Jimmy Hess writes: > On Wed, Jul 1, 2015 at 12:38 AM, Mikael Abrahamsson wrote: > > quickly. Either we should abolish the leap second or we should make leap > > second adjustments (back and forth) on a monthly basis to exercise the code > . > > See.... maybe there should some day be building codes for > commercially marketed software that provide minimum independent > formal testing to be done by licensed independent testers, including > leap seconds and such. ^_^ And NTF's Certification and Compliance programs are going to do this. At least as soon as NTF has the resources to get this moving. > The leap second issues are possibly rare and intermittent, therefore, > having a few per month is not necessarily giving adequate exposure > to code paths that may go wrong during an insert/del event. If they happened every 6 month's time that would be often enough, but the earth hasn't slowed down that much yet. There will be enough times that we could insert or delete one every month and still have |UT-UT1| be under .9 seconds. If it was announced that "starting in 6 months' time we'll be inserting or deleting a leap second every month or so that would give folks enough time to prep for it, and I'm pretty confident that the leap-second would soon become a non-event. > There's never been a negative leap second, only insertions, but how > deletions are implemented might expose new bugs, since there hasn't > been one before, And you can only have one leap per 24 hours, > positive or minus, pick one. Yup. > & Shouldn't this kind of 'exercise' be done during the QA process > before releasing new system software, rather than mucking with clock > accuracy? leap second handling is a "mechanism" question. Which one to choose is a "policy" question. IMO, a vendor should provide adequate mechanism. The customer should get to choose policy. > There is a recent article with some Leap Second 'stress testing' code: > https://access.redhat.com/articles/199563 > > > Readily available test methods are available, there ought to be > little legitimate excuse for anyone writing serious software that has > long-running processes or threads not to include evaluation for > possible leap second issues and other possible clock-related issues > such as clock stepping, DST, and Year 2038 in their standard smoke > tests.... Yes. And even so, testing these things takes time and equipment. -- Harlan Stenn http://networktimefoundation.org - be a member! From stenn at ntp.org Thu Jul 2 00:43:43 2015 From: stenn at ntp.org (Harlan Stenn) Date: Thu, 02 Jul 2015 00:43:43 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <1972931982.3896.1435756636670.JavaMail.mhammett@ThunderFuck> References: <1972931982.3896.1435756636670.JavaMail.mhammett@ThunderFuck> Message-ID: Mike Hammett writes: > It looks to have only affected the CCR line and only those running the > NTP and not the SNTP package. Any idea what version of NTP or what their configuration looked like? H From nanog at ics-il.net Thu Jul 2 01:07:28 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 Jul 2015 20:07:28 -0500 (CDT) Subject: REMINDER: LEAP SECOND In-Reply-To: Message-ID: <1335798475.1063.1435799287513.JavaMail.mhammett@ThunderFuck> No, I'm surprised we know the kernels. They're a pretty closed company. All we can do is enter IPs for the client side and turn it on\off server side. Well, and broadcast\multicast\manycast. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Harlan Stenn" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Wednesday, July 1, 2015 7:43:43 PM Subject: Re: REMINDER: LEAP SECOND Mike Hammett writes: > It looks to have only affected the CCR line and only those running the > NTP and not the SNTP package. Any idea what version of NTP or what their configuration looked like? H From israel.lugo at lugosys.com Thu Jul 2 03:23:03 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 02 Jul 2015 04:23:03 +0100 Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: References: <20150701194106.GP95870@Vurt.local> Message-ID: <5594AE97.5090308@lugosys.com> +1 for BIRD. Basically, what you want is to have several different static (blackhole) routes, and be able to differenciate them at BGP level, for marking with communities, etc. Correct? This is easy with BIRD. Just use separate instances of the "static" protocol, and filter using "proto" to distinguish between them. E.g.: protocol static default_sink { # sink all local prefixes by default, to avoid loops # (low localpref, let other routes override us) import filter { preference = 1; accept; }; route 192.0.2.0/24 blackhole; } protocol static forbidden { # these guys looked at me the wrong way route 198.51.100.0/24 blackhole; } protocol static temp_block { # DDOS mitigation, etc route 203.0.113.17/32 blackhole; } protocol bgp customer1 { export filter { if proto = "default_sink" then reject; if proto = "temp_block" then set_tempblock_community(); if proto = "forbidden" then do_other_stuff(); } # ... } On 07/01/2015 08:47 PM, David H wrote: > Sorry I wasn't clear on that. Traditionally on a hardware, e.g. > cisco/brocade, router performing the RTBH role, I'd add blackhole routes by > way of static routes with a particular tag; one tag for block this source, > one tag for block this destination. Redistribute static would let route > maps operate against those tags to turn into bgp communities being applied > to the announcements, and then the real routers can do what they need to > do. When I tried out Quagga/Zebra as an alternative, it doesn't work this > way, so while it was nice that it could pick up static routes from the OS, > or have them added manually just like a hardware router, there was no > concept of the route tag getting to Zebra for it to do the rest of the work > on the BGP side. > > I'll check out Bird too; thanks. > > On Wed, Jul 1, 2015 at 3:41 PM, Job Snijders wrote: > >> On Wed, Jul 01, 2015 at 11:19:45AM -0400, David H wrote: >>> I was wondering if anyone can recommend a software (preferable), or >>> hardware-based router with an API, that supports BGP with tags on >>> advertised routes? I want to use it for a RTBH feed [ ... ] >> Did you look at BIRD? It is one of the most beautiful open source BGP >> speakers: http://bird.network.cz/ >> >> BIRD does not have anything like an restful API, but you can just >> generate the config file and reload it on the fly to accomplish the >> same. >> >> Can you elaborate on what you mean with 'tags'? Could you use BGP >> communities instead? >> >> Kind regards, >> >> Job >> From israel.lugo at lugosys.com Thu Jul 2 03:30:49 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 02 Jul 2015 04:30:49 +0100 Subject: Inexpensive software bgp router that supports route tags? In-Reply-To: <5594AE97.5090308@lugosys.com> References: <20150701194106.GP95870@Vurt.local> <5594AE97.5090308@lugosys.com> Message-ID: <5594B069.9040905@lugosys.com> On 07/02/2015 04:23 AM, Israel G. Lugo wrote: > protocol static temp_block { > # DDOS mitigation, etc > route 203.0.113.17/32 blackhole; > } Didn't make it clear in my example, but you can obviously have multiple routes in a static instance: protocol static temp_block { route 203.0.113.17/32 blackhole; route 203.0.113.28/32 blackhole; # redirect to honeypot for gathering info route 203.0.113.99/32 via 10.0.0.15; } From swmike at swm.pp.se Thu Jul 2 07:14:38 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 2 Jul 2015 09:14:38 +0200 (CEST) Subject: suggestion for DSCP codepoint for "less than best effort" (scavanger class) traffic Message-ID: Hi, in the IETF transport area there are discussions on DSCP interconnection between networks. It's quite common that operators clear (bleach) the DSCP codepoints when receiving packets from other operators, turning everything into BE (best effort) traffic. Historically CS1 has been proposed as less-than-best-effort (for instance bittorrent traffic), but my opinion is that this is ill suited as I think it's not incrementally deployable. Some networks might use CS1 as something that has higher priority and it would be hard for them to change this incrementally. I have proposed a DSCP codepoint that I believe is incrementally deployable and that is 000010, which I think is deployable because it maps to CS0, PRECEDENCE 0, so any kind of equipment that today takes these bits and imposes it into 802.1p, MPLS TC (former EXP) etc, will just map this to regular BE. If explicitly configured, one can match on 000010 and put this in a different queue, for instance that doesn't have much bandwidth guarantees at all. Since this proposal just comes from my personal experience with equipment in the MPLS/L2/IP world, I'd like to hear wider view/opinion on this and I'll bring it to the TSVWG at the upcoming IETF in Prague July 20-25. It would be great if there could be an operational document as well, giving recommendations on how to configure the above, and it would be great if it could be done with lots of operator input into the matter. ---------- Forwarded message ---------- Date: Thu, 2 Jul 2015 00:32:40 +0000 From: "Black, David" To: "Ruediger.Geib at telekom.de" , "swmike at swm.pp.se" Cc: "tsvwg at ietf.org" Subject: RE: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1 > - work on a scavenger class standard needs to be done in a > separate draft. And here's what that draft might encompass ... Beyond that, I'd support a (hopefully short) draft that - updates RFC 3662 to change the recommended DSCP for the LE PHB from CS1 to 000010, - recognizes and allows for continued use of CS1 where deployed, and - updates other RFCs (e.g., 4592, 5127) accordingly as needed. As Brian pointed out, this would need to be a standards track draft with a downref to RFC 3662 in order to allocate that DSCP. Writing the draft is straightforward by comparison to figuring out whether this is what we should do, as indicated by the other messages in this thread on operator/operational considerations. This item is on the draft tsvwg agenda for Prague as a discussion topic - I plan to bring slides and only write the -00 draft after I've survived that discussion ;-). Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces at ietf.org] On Behalf Of > Ruediger.Geib at telekom.de > Sent: Monday, June 29, 2015 4:51 AM > To: swmike at swm.pp.se > Cc: tsvwg at ietf.org > Subject: Re: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / > CS1 > > Hi Mikael, > > ok, understood, I'm relaxed. > > The relation of Diffserv intercon to scavenger is > > - if there is a scavenger class, how should Diffserv intercon handle it > (will add text about a 000 xx0 DSCP)? Otherwise Diffserv Intercon > says, bleaching may occur for any unexpected DSCP. > > - work on a scavenger class standard needs to be done in a > separate draft. That's WG consensus and Gorry Fairhurst said during > the last meeting: > "Scavenger support document been discussed before, if there is > renewed interest, then we should take it up again. > As an individual contributor, I would be interested. > If you are also interested in this topic, please talk to the > WG chairs." > > - operational issues may be relevant for a bleaching discussion. > A bleaching standard is out of scope of Diffserv Intercon (thats > WG consensus). I think to recall interest in work on bleaching > by others too. > > Then I'm happy to meet you in Prague. > > Regards, > > Ruediger > > -----Urspr?ngliche Nachricht----- > Von: Mikael Abrahamsson [mailto:swmike at swm.pp.se] > Gesendet: Montag, 29. Juni 2015 09:38 > An: Geib, R?diger > Cc: tsvwg at ietf.org > Betreff: Re: AW: AW: AW: [tsvwg] draft diffserv-intercon: Handling of a > scavenger class / CS1 > > On Mon, 29 Jun 2015, Ruediger.Geib at telekom.de wrote: > >> I repeat that I've talked with my RIPE/NANOG colleagues to get >> feedback >> - they came back only with one or two names with whom to discuss QoS >> interconnection. And I never got any useful response (positive or >> negative) from those. > > This is the problem, that's not how to do this, the way to do this is to > announce an idea on the nanog mailing list and see who might be interested. > > As far as I read your document, it has nothing in it about how to > incrementally get an Internet-wide scavenger class operationally deployed over > time. To me it reads more like a document for business VPN Carriers-Carrier > services style interconnect/interworking. It has no operational advice at all > in it on how to deal with DDoS, how to configure access equipment, how to set > up queuing strategies on different kinds of equipment, listing what equipment > might do what, etc. > > I suggested how to actually make this incrementally and widely deployable > across the world, and that is to aim for a 000xxx style scavenger class. > This seems to not work for some reason that is unclear to me, your document > doesn't seem to be operational at all, it doesn't propose something that is > operationally deployable on the wider Internet, so that's why I think we would > need another document for this purpose. If that is not a goal we can agree on, > then there is no need to write one. > > So just to sum up: I'm sure your document is fine for what it intends to do, > it just doesn't answer any of the concerns an IP network engineer/architect > might have about implementing this on an Internet peering link where there is > little or no control over what traffic will pass or what this traffic might do > to the rest of their network. It suggests a way to do something with no > operational analysis or risk mitigation at all. > > The first thing that will pop into any good IP architects head nowadays will > be "oh, what happens to my network when I get 200 gigabits/s of 64 byte > packets marked EF from that 5 million strong DDoS-drone network all across the > world, aimed for my customer base?" > > The answer to that is "I'll bleach DSCP it because that's the only way to > handle it". So in order to get a scavenger class actually deployable, you have > to come up with something that means they can relax the bleaching a little bit > by some operators, but their infrastructure would still treat the traffic the > same. You also have to take into account that a lot of core IP network > equipment can't do DSCP mapping very well. This kind of functionality makes > equipment more expensive and thus less likely to exist widely. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Thu Jul 2 07:25:30 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Jul 2015 09:25:30 +0200 Subject: suggestion for DSCP codepoint for "less than best effort" (scavanger class) traffic In-Reply-To: References: Message-ID: <5594E76A.1000600@seacom.mu> On 2/Jul/15 09:14, Mikael Abrahamsson wrote: > > > It would be great if there could be an operational document as well, > giving recommendations on how to configure the above, and it would be > great if it could be done with lots of operator input into the matter. Given that some networks don't employ QoS, others do but use IPP instead of DSCP, and others have exaggerated QoS policies that adding a new profile could be rocket science, it would be interesting to see how this gets implemented even on the back of a community-agreed spec. I fear it may follow the same fate as PMTUd. My concern would be around making sure it does not end up in that bin. Mark. From hslabbert at stargate.ca Thu Jul 2 15:26:26 2015 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Thu, 2 Jul 2015 08:26:26 -0700 Subject: [outages] CenturyLink fiber cut between Modesto, CA and San Jose, CA this AM.. Start time 4:26AM PST In-Reply-To: References: <2n0sm18jcrfslnekos5i25bg.1435697808781@email.android.com> Message-ID: <20150702152626.GN10437@stargate.ca> >Then again, maybe my tinfoil hat is too tight. Recent history would seem to indicate that, if anything, most of us were skimping a bit on tinfoil. That said, the recent cuts in CA have received a lot of attention and passed into the mainstream media; that seems, imho, a bit too public for the operations of a notoriously clandestine organization. With something this visible, people will want closure (read "someone to blame"). If it is the works of some three-letter agency, you either need a scapegoat that can be sold to the public, or the cuts just magically stop happening without a perpetrator being found. If the former, you need a fall man or someone you don't like and against whom you can amass enough fabricated evidence to convict. The latter is basically conspiracy theory gold, and at this point may start bubbling up into hearings on "securing critical network infrastructure" etc. I guess the alternative is that there is a pre-existing sabotage operation in progress, and a three-letter agency then decides to piggy-back on that and do some taps under the cover that provides ("oh, those dasterdly fiber cutters again!"), but that also would seem pretty risky if the original crew gets busted: "They admit to all of the cuts except that one in SJ. Weird... *shrugs*" At any rate it would seem like idle speculation at this point. IDK; at this point if you need privacy ensured, it's probably best to just assume your "private" lines aren't private and just crypto all the things. -- Hugo On Wed 2015-Jul-01 13:02:19 -0400, Keith Medcalf wrote: > >Have they asked No-Such-Agency? > >No-Such-Agency typically taps communication lines by "back-hoe accident" of some sort on the path they are interested in tapping. That way they can install a tap "over yonder" while the victim telecom is attempting to repair the original damage. I guess this time is taking longer than expected so they FBI has been recruited to prevent the victim from completing repairs to quickly. > >Then again, maybe my tinfoil hat is too tight. > From rafael at gav.ufsc.br Thu Jul 2 16:09:52 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 2 Jul 2015 11:09:52 -0500 Subject: in-cabinet PDU safety regs? In-Reply-To: References: Message-ID: I've referenced article 645 before, but you have to look at anything upstream or downstream of the PDU as well, as the system as a whole needs to be within standards. On Wed, Jul 1, 2015 at 11:42 AM, William Herrin wrote: > Hi Folks, > > Do you know of any regulations, standards or publications covering the > safe installation and use of the little 1U and 2U PDUs in rack > cabinets? My google fu is failing me. All I've found is OSHA > 1926.403(i)(1)(i) > ( > https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_id=10704 > ) > and I'm not 100% sure it applies. > > Thanks in advance, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From amps at djlab.com Thu Jul 2 16:13:21 2015 From: amps at djlab.com (Randy) Date: Thu, 02 Jul 2015 09:13:21 -0700 Subject: ExaBGP and BIRD clue in the =?UTF-8?Q?house=3F?= Message-ID: Really, it's got to be something dead stupid. Hoping to borrow 5 minutes of someone's time. Replies on or off list are fine. I've reduced it to a simple config: BIRD: protocol bgp { description "ExaBGP-local"; local as 12345; allow local as 1; neighbor 10.0.0.2 as 12345; next hop keep; start delay time 5; import all; export all; } EXABGP: group gixlg { hold-time 180; local-as 12345; router-id 10.0.0.2; family { ipv4 unicast; } neighbor 10.0.0.1 { router-id 10.0.0.2; local-address 10.0.0.2; peer-as 12345; description "Bird-local"; group-updates; } static { route 1.2.3.4/32 next-hop 4.3.2.1; } } Everything comes up. But bird has no routes. bird> sh protocols name proto table state since info bgp1 BGP master up 12:06:00 Established bird> show route all bird> -- ~Randy From amps at djlab.com Thu Jul 2 16:40:59 2015 From: amps at djlab.com (Randy) Date: Thu, 02 Jul 2015 09:40:59 -0700 Subject: ExaBGP and BIRD clue in the =?UTF-8?Q?house=3F?= In-Reply-To: References: Message-ID: <560551668f9a1b26c2875a8e59e6ed10@mailbox.fastserv.com> FYI, if the static is moved up within the neighbor definition, it works. So this is an Exa related issue/feature and not a problem with BIRD. I'll move the noise to the Exa list if needed. ~Randy On 07/02/2015 9:13 am, Randy wrote: > Really, it's got to be something dead stupid. Hoping to borrow 5 > minutes of someone's time. Replies on or off list are fine. > > I've reduced it to a simple config: > > BIRD: > protocol bgp { > description "ExaBGP-local"; > local as 12345; > allow local as 1; > neighbor 10.0.0.2 as 12345; > next hop keep; > start delay time 5; > import all; > export all; > } > > EXABGP: > group gixlg { > hold-time 180; > local-as 12345; > router-id 10.0.0.2; > family { > ipv4 unicast; > } > neighbor 10.0.0.1 { > router-id 10.0.0.2; > local-address 10.0.0.2; > peer-as 12345; > description "Bird-local"; > group-updates; > } > static { > route 1.2.3.4/32 next-hop 4.3.2.1; > } > } > > Everything comes up. But bird has no routes. > bird> sh protocols > name proto table state since info > bgp1 BGP master up 12:06:00 Established > > bird> show route all > bird> From owen at delong.com Thu Jul 2 16:44:13 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 2 Jul 2015 09:44:13 -0700 Subject: ExaBGP and BIRD clue in the house? In-Reply-To: <560551668f9a1b26c2875a8e59e6ed10@mailbox.fastserv.com> References: <560551668f9a1b26c2875a8e59e6ed10@mailbox.fastserv.com> Message-ID: Exactly? It?s not an issue, it?s expected behavior. If you move the static up within the neighbor definition, it becomes an Anchor Route and Exa knows you want it announced. If you leave it in the static routes section, then you either need a redistribution policy from static to bgp (not recommended) or you need some other sort of policy that tells exa that you want to announce the route. Owen > On Jul 2, 2015, at 09:40 , Randy wrote: > > FYI, if the static is moved up within the neighbor definition, it works. So this is an Exa related issue/feature and not a problem with BIRD. > > I'll move the noise to the Exa list if needed. > > ~Randy > > On 07/02/2015 9:13 am, Randy wrote: >> Really, it's got to be something dead stupid. Hoping to borrow 5 >> minutes of someone's time. Replies on or off list are fine. >> I've reduced it to a simple config: >> BIRD: >> protocol bgp { >> description "ExaBGP-local"; >> local as 12345; >> allow local as 1; >> neighbor 10.0.0.2 as 12345; >> next hop keep; >> start delay time 5; >> import all; >> export all; >> } >> EXABGP: >> group gixlg { >> hold-time 180; >> local-as 12345; >> router-id 10.0.0.2; >> family { >> ipv4 unicast; >> } >> neighbor 10.0.0.1 { >> router-id 10.0.0.2; >> local-address 10.0.0.2; >> peer-as 12345; >> description "Bird-local"; >> group-updates; >> } >> static { >> route 1.2.3.4/32 next-hop 4.3.2.1; >> } >> } >> Everything comes up. But bird has no routes. >> bird> sh protocols >> name proto table state since info >> bgp1 BGP master up 12:06:00 Established >> bird> show route all >> bird> From amps at djlab.com Thu Jul 2 17:14:38 2015 From: amps at djlab.com (Randy) Date: Thu, 02 Jul 2015 10:14:38 -0700 Subject: ExaBGP and BIRD clue in the =?UTF-8?Q?house=3F?= In-Reply-To: References: <560551668f9a1b26c2875a8e59e6ed10@mailbox.fastserv.com> Message-ID: I think you overestimated exabgp's dead simplicity. After some more testing, I found moving the route higher in the config file (before the neighbor definition rather than inside it), it propagates. So order matters more than anything. You have to define routes either BEFORE or WITHIN neighbors in each group scope. I also do not believe exa supports any sort of routing policy. It's a dumb tool for manually injecting routes and piping updates to external apps. ~Randy On 07/02/2015 9:44 am, Owen DeLong wrote: > Exactly? It?s not an issue, it?s expected behavior. > > If you move the static up within the neighbor definition, it becomes > an Anchor Route and Exa knows you want it announced. > > If you leave it in the static routes section, then you either need a > redistribution policy from static to bgp (not recommended) or you need > some other sort of policy that tells exa that you want to announce the > route. > > Owen > >> On Jul 2, 2015, at 09:40 , Randy wrote: >> >> FYI, if the static is moved up within the neighbor definition, it >> works. So this is an Exa related issue/feature and not a problem >> with BIRD. >> >> I'll move the noise to the Exa list if needed. >> >> ~Randy >> >> On 07/02/2015 9:13 am, Randy wrote: >>> Really, it's got to be something dead stupid. Hoping to borrow 5 >>> minutes of someone's time. Replies on or off list are fine. >>> I've reduced it to a simple config: >>> BIRD: >>> protocol bgp { >>> description "ExaBGP-local"; >>> local as 12345; >>> allow local as 1; >>> neighbor 10.0.0.2 as 12345; >>> next hop keep; >>> start delay time 5; >>> import all; >>> export all; >>> } >>> EXABGP: >>> group gixlg { >>> hold-time 180; >>> local-as 12345; >>> router-id 10.0.0.2; >>> family { >>> ipv4 unicast; >>> } >>> neighbor 10.0.0.1 { >>> router-id 10.0.0.2; >>> local-address 10.0.0.2; >>> peer-as 12345; >>> description "Bird-local"; >>> group-updates; >>> } >>> static { >>> route 1.2.3.4/32 next-hop 4.3.2.1; >>> } >>> } >>> Everything comes up. But bird has no routes. >>> bird> sh protocols >>> name proto table state since info >>> bgp1 BGP master up 12:06:00 Established >>> bird> show route all >>> bird> From amps at djlab.com Thu Jul 2 17:18:32 2015 From: amps at djlab.com (Randy) Date: Thu, 02 Jul 2015 10:18:32 -0700 Subject: ExaBGP and BIRD clue in the =?UTF-8?Q?house=3F?= In-Reply-To: References: <560551668f9a1b26c2875a8e59e6ed10@mailbox.fastserv.com> Message-ID: <811f8b951b84dd960f052ea54cabc784@mailbox.fastserv.com> To demonstrate -- order is everything -- this works: group gixlg { hold-time 180; local-as 12345; router-id 10.0.0.2; family { ipv4 unicast; } static { route 1.2.3.4/32 next-hop 4.3.2.1; } neighbor 10.0.0.1 { router-id 10.0.0.2; local-address 10.0.0.2; peer-as 12345; description "Bird-local"; group-updates; } } This doesn't work: group gixlg { hold-time 180; local-as 12345; router-id 10.0.0.2; family { ipv4 unicast; } neighbor 10.0.0.1 { router-id 10.0.0.2; local-address 10.0.0.2; peer-as 12345; description "Bird-local"; group-updates; } static { route 1.2.3.4/32 next-hop 4.3.2.1; } } On 07/02/2015 9:44 am, Owen DeLong wrote: > Exactly? It?s not an issue, it?s expected behavior. > > If you move the static up within the neighbor definition, it becomes > an Anchor Route and Exa knows you want it announced. > > If you leave it in the static routes section, then you either need a > redistribution policy from static to bgp (not recommended) or you need > some other sort of policy that tells exa that you want to announce the > route. > > Owen > >> On Jul 2, 2015, at 09:40 , Randy wrote: >> >> FYI, if the static is moved up within the neighbor definition, it >> works. So this is an Exa related issue/feature and not a problem >> with BIRD. >> >> I'll move the noise to the Exa list if needed. >> >> ~Randy >> >> On 07/02/2015 9:13 am, Randy wrote: >>> Really, it's got to be something dead stupid. Hoping to borrow 5 >>> minutes of someone's time. Replies on or off list are fine. >>> I've reduced it to a simple config: >>> BIRD: >>> protocol bgp { >>> description "ExaBGP-local"; >>> local as 12345; >>> allow local as 1; >>> neighbor 10.0.0.2 as 12345; >>> next hop keep; >>> start delay time 5; >>> import all; >>> export all; >>> } >>> EXABGP: >>> group gixlg { >>> hold-time 180; >>> local-as 12345; >>> router-id 10.0.0.2; >>> family { >>> ipv4 unicast; >>> } >>> neighbor 10.0.0.1 { >>> router-id 10.0.0.2; >>> local-address 10.0.0.2; >>> peer-as 12345; >>> description "Bird-local"; >>> group-updates; >>> } >>> static { >>> route 1.2.3.4/32 next-hop 4.3.2.1; >>> } >>> } >>> Everything comes up. But bird has no routes. >>> bird> sh protocols >>> name proto table state since info >>> bgp1 BGP master up 12:06:00 Established >>> bird> show route all >>> bird> From hugo at slabnet.com Thu Jul 2 17:48:10 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 2 Jul 2015 10:48:10 -0700 Subject: Route leak in Bangladesh In-Reply-To: <559400F5.60401@seacom.mu> References: <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FE72.8060203@seacom.mu> <5593FF18.3040903@foobar.org> <559400F5.60401@seacom.mu> Message-ID: <20150702174810.GA24396@bamboo.slabnet.com> On Wed 2015-Jul-01 17:02:13 +0200, Mark Tinka wrote: > > >On 1/Jul/15 16:54, Nick Hilliard wrote: >> you probably want to ignore more rpsl constructs and depend solely on >> as-sets, aut-nums and route/route6 objects. RPSL is not going to live up >> to your expectations. > >Honestly, I'm ambivalent about using the IRR data for prefix-list >generation (even without RPSL), also because of how much junk there is >in there, and also how redundant some of it really is, e.g., someone >creating a /32 (IPv4) route object and yet we only accept up to a /24 >(IPv4) on the actual eBGP session, e.t.c. > >What I'm more focused is how we can continue to scale our current >system, which is much more strict, focuses on deploying customer >aggregates + le 24 & le 128, instead of enumerating all possible >de-aggregates that have been registered in the IRR (helps keep the >configuration file small and manageable, without sacrificing >reachability). And then see how we can add RPKI into the mix to make >things even simpler, if at all. Orphaned/crufty data and braindead moves (e.g. someone including a large upstream's AS-SET in their own or something) aside, the deagg issue should be handled by the tools, no? We do automated prefix gen from IRR data, and I know IRRPT will aggregate the route records before spitting out the prefix list. I would have assumed that other tools do the same? Options are available to define your max prefix length and then build your filters off of that, e.g. upto /. You still face issues with people people registering discontiguous blocks (e.g. network has a.b.0.0/22 but creates records for a.b.0.0/23 and a.b.3.0/24, but leaves out a.b.2.0/24), but there isn't much we can do about that without human interaction to verify the actual allocation. Also: >focuses on deploying customer aggregates + le 24 & le 128... Jeebuz; you accept /128s? Perhaps "le 24 & le 48"? > >Mark. -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill at herrin.us Thu Jul 2 18:23:35 2015 From: bill at herrin.us (William Herrin) Date: Thu, 2 Jul 2015 14:23:35 -0400 Subject: [outages] CenturyLink fiber cut between Modesto, CA and San Jose, CA this AM.. Start time 4:26AM PST In-Reply-To: References: <2n0sm18jcrfslnekos5i25bg.1435697808781@email.android.com> Message-ID: On Wed, Jul 1, 2015 at 1:02 PM, Keith Medcalf wrote: > No-Such-Agency typically taps communication lines by > "back-hoe accident" of some sort on the path they are > interested in tapping. Then again, maybe my tinfoil hat is too tight. I'm gonna go with "too tight." My main reason is that there's no need for our three-lettered friends to risk themselves this way. It's far easier to invite specific highly-placed employees of the communications company for a series of meetings in a secure facility, after which the cable is rerouted through an access-controlled room at one of its endpoints. No muss, no fuss. Then too, if they really do have to tap a cable, it's not like they have to break it first. Dig it up mid-span, quietly let out slack from the nearest vaults and nick the cladding on each fiber. Your link gains half a db of loss (which you aren't actively monitoring anyway) and their tap reads your data. http://www.thefoa.org/tech/ref/appln/tap-fiber.html Also, I think it more likely this is one of the angry anti-tech folks in SF. Have you not heard about the tension between old-school residents and the new tech workers who are driving up prices for everything and basically driving everybody else out of town? https://en.wikipedia.org/wiki/Google_bus_protests Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From davidpeahi at gmail.com Thu Jul 2 18:27:51 2015 From: davidpeahi at gmail.com (david peahi) Date: Thu, 2 Jul 2015 11:27:51 -0700 Subject: Internet Slow in Marina Del Rey, California Message-ID: Sluggish Internet via TWC and Sprint 3G/4G in Marina Del Rey area. Any outages reported? Regards, David From bzs at world.std.com Thu Jul 2 18:34:19 2015 From: bzs at world.std.com (Barry Shein) Date: Thu, 2 Jul 2015 14:34:19 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> Message-ID: <21909.33835.693069.844771@world.std.com> UUCP. Someone had to mention it. So I did. And BITNET I guess. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From thomas.mangin at exa-networks.co.uk Thu Jul 2 20:30:51 2015 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Thu, 02 Jul 2015 21:30:51 +0100 Subject: ExaBGP and BIRD clue in the house? In-Reply-To: References: <560551668f9a1b26c2875a8e59e6ed10@mailbox.fastserv.com> Message-ID: <156CC85B-A3FD-40C8-A1A0-E853692643EF@exa-networks.co.uk> Hello Randy, The current configuration parser is currently progressive: what exists when the neighbor is created (or in the neighbor group) is what will be associated (which is not really ideal) hence why I have passed the last three weeks totally rewriting it in view of version 4.0. This is still serious WIP tho. ExaBGP is indeed ?dumb? (outch, it hurts :p) when it comes to route filtering, advanced features are ?left as an exercise for the end user? using the API. I did not see an immediate need to re-invent BIRD which covers this part of the ecosystem more than well. You can find some good examples on how ExaBGP can be used on this site: https://thepacketgeek.com/tag/exabgp/ Many people have released useful tools: https://github.com/YoshiyukiYamauchi/mrtparse https://github.com/dpiekacz/gixlg https://github.com/abh/bgpapi https://github.com/search?utf8=?&q=exabgp returns quite a few more. Obviously if you have any issues/questions, I am more than happy to help ( via the mailing list, G+, Gitter, IRC #exabgp on freenode ) Once the connected program receive an update, it can decide to re-distribute it. Have ?fun?, Thomas http://exa.net.uk/about/contact-us On 2 Jul 2015, at 18:14, Randy wrote: > I think you overestimated exabgp's dead simplicity. > > After some more testing, I found moving the route higher in the config > file (before the neighbor definition rather than inside it), it > propagates. So order matters more than anything. You have to > define routes either BEFORE or WITHIN neighbors in each group scope. > > I also do not believe exa supports any sort of routing policy. It's > a dumb tool for manually injecting routes and piping updates to > external apps. > > ~Randy > > On 07/02/2015 9:44 am, Owen DeLong wrote: >> Exactly? It?s not an issue, it?s expected behavior. >> >> If you move the static up within the neighbor definition, it becomes >> an Anchor Route and Exa knows you want it announced. >> >> If you leave it in the static routes section, then you either need a >> redistribution policy from static to bgp (not recommended) or you >> need >> some other sort of policy that tells exa that you want to announce >> the >> route. >> >> Owen >> >>> On Jul 2, 2015, at 09:40 , Randy wrote: >>> >>> FYI, if the static is moved up within the neighbor definition, it >>> works. So this is an Exa related issue/feature and not a problem >>> with BIRD. >>> >>> I'll move the noise to the Exa list if needed. >>> >>> ~Randy >>> >>> On 07/02/2015 9:13 am, Randy wrote: >>>> Really, it's got to be something dead stupid. Hoping to borrow 5 >>>> minutes of someone's time. Replies on or off list are fine. >>>> I've reduced it to a simple config: >>>> BIRD: >>>> protocol bgp { >>>> description "ExaBGP-local"; >>>> local as 12345; >>>> allow local as 1; >>>> neighbor 10.0.0.2 as 12345; >>>> next hop keep; >>>> start delay time 5; >>>> import all; >>>> export all; >>>> } >>>> EXABGP: >>>> group gixlg { >>>> hold-time 180; >>>> local-as 12345; >>>> router-id 10.0.0.2; >>>> family { >>>> ipv4 unicast; >>>> } >>>> neighbor 10.0.0.1 { >>>> router-id 10.0.0.2; >>>> local-address 10.0.0.2; >>>> peer-as 12345; >>>> description "Bird-local"; >>>> group-updates; >>>> } >>>> static { >>>> route 1.2.3.4/32 next-hop 4.3.2.1; >>>> } >>>> } >>>> Everything comes up. But bird has no routes. >>>> bird> sh protocols >>>> name proto table state since info >>>> bgp1 BGP master up 12:06:00 Established >>>> bird> show route all >>>> bird> From frnkblk at iname.com Fri Jul 3 00:42:52 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Thu, 2 Jul 2015 19:42:52 -0500 Subject: www.att.net back up over IPv6 Message-ID: <002e01d0b529$33738640$9a5a92c0$@iname.com> After being down since early May 2014, www.att.net is now back up over IPv6 since 7:29 pm U.S. Central. Sites that we track that were up but remain down over IPv6 are www.charter.com, www.dnssec.comcast.net, and www.globalcrossing.com. Frank From jra at baylink.com Fri Jul 3 04:40:44 2015 From: jra at baylink.com (Jay Ashworth) Date: Fri, 03 Jul 2015 00:40:44 -0400 Subject: The Internet Is Now Officially Too Big as IP Addresses Run Out - NBC News Message-ID: <43D88E0A-0EC4-4CFD-9DBB-E7CA276DA7BE@baylink.com> John Curran gets a quote; NBC gets the etymology of "IPv4" wrong. Just keep them away from Jim Fleming. http://www.nbcnews.com/news/us-news/internet-now-officially-too-big-ip-addresses-run-out-n386081 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From mark.tinka at seacom.mu Fri Jul 3 06:32:01 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 3 Jul 2015 08:32:01 +0200 Subject: Route leak in Bangladesh In-Reply-To: <20150702174810.GA24396@bamboo.slabnet.com> References: <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> <559387C2.8020603@seacom.mu> <20150701141254.GA31989@puck.nether.net> <5593FE72.8060203@seacom.mu> <5593FF18.3040903@foobar.org> <559400F5.60401@seacom.mu> <20150702174810.GA24396@bamboo.slabnet.com> Message-ID: <55962C61.5090706@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/Jul/15 19:48, Hugo Slabbert wrote: > > > Jeebuz; you accept /128s? Perhaps "le 24 & le 48"? Yes, that was a typo - /48 :-). Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVlixgAAoJEGcZuYTeKm+GLRQP/2HjuqFJW+pzhuH9qSbltl1D hz//dUVzJnGn2dE96lJGa+EcgZ096ax5sjSoNm/Ea9/cXJkauWN+oRp1H1DoNfvL Mp8RRcE9iVaavh5SdEBEEyKeqYHUjvyXmZWbCiVH1rebmTqUN0xHTne6AT3PrwhT rkyK+dN5tBKSrg5WWcsAaYvRLNOL8R93YTA8HjeNXzkp9zk29oPcrlGf2us/jPcq Qp1IIoOLBndeDT8A9rV5ubQNzPUEJJEoHGb5ESsPv8pMt26CaYExG1PPNhhNKyvD kIZTYD0L6lp42Ai5C+Jmv7hpL8ATH8m6dGxwzj47afbwYxbk76QsZKNPz3pFsOVV TDLMK07+aSlIozzQ9I9qFYjNA2jeYCwHcQsedcKCydYdzXMOvVMZW6HL/Ai0gBlf TRkOZMGyzerWk+hVn/YJLqFgfWonnUSTzX0ZWh0duGFEk7pVyvZdGPyJkF9J8UBq yJ38Zj+PvhPj0ZEt3LHShwUbMjcXAZ/4198HvQw+J2yFAAwm/ucHuAGL+Q/2LbWF D8V1EHF3eWBKo9SvvbYS1dNYHKxf8b7vdGgxIZqyMNUZpvjfuuXk3m9DwFQpjOnc //73PLWQtWb1udf1zdXkEQIwwAkF4UjBqgg1rW+CTkvFXXKLgLenVrnE9LbcI9UK QUDfEhw8o4LKTOHyWJah =GT1h -----END PGP SIGNATURE----- From pmsac.nanog at gmail.com Fri Jul 3 09:36:46 2015 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Fri, 3 Jul 2015 10:36:46 +0100 Subject: The Internet Is Now Officially Too Big as IP Addresses Run Out - NBC News In-Reply-To: <43D88E0A-0EC4-4CFD-9DBB-E7CA276DA7BE@baylink.com> References: <43D88E0A-0EC4-4CFD-9DBB-E7CA276DA7BE@baylink.com> Message-ID: On 3 July 2015 at 05:40, Jay Ashworth wrote: > John Curran gets a quote; NBC gets the etymology of "IPv4" wrong. > Statistics/Graphs get misinterpreted; Belgium isn't a country. News at 11. > > Just keep them away from Jim Fleming. > > > http://www.nbcnews.com/news/us-news/internet-now-officially-too-big-ip-addresses-run-out-n386081 > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > From frnkblk at iname.com Fri Jul 3 10:24:29 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Fri, 3 Jul 2015 05:24:29 -0500 Subject: www.att.net back up over IPv6 Message-ID: <002f01d0b57a$739c8720$5ad59560$@iname.com> That was short-lived -- it's now down again as of 2 am (U.S. Central). No AAAA. Frank -----Original Message----- From: Frank Bulk (frnkblk at iname.com) [mailto:frnkblk at iname.com] Sent: Thursday, July 02, 2015 7:43 PM To: nanog at nanog.org Subject: www.att.net back up over IPv6 After being down since early May 2014, www.att.net is now back up over IPv6 since 7:29 pm U.S. Central. Sites that we track that were up but remain down over IPv6 are www.charter.com, www.dnssec.comcast.net, and www.globalcrossing.com. Frank From j at arpa.com Fri Jul 3 17:40:28 2015 From: j at arpa.com (jamie rishaw) Date: Fri, 3 Jul 2015 12:40:28 -0500 Subject: The Internet Is Now Officially Too Big as IP Addresses Run Out - NBC News In-Reply-To: <43D88E0A-0EC4-4CFD-9DBB-E7CA276DA7BE@baylink.com> References: <43D88E0A-0EC4-4CFD-9DBB-E7CA276DA7BE@baylink.com> Message-ID: Oh, God. Flem[bleep], /Really/ ? I thought we all agreed to never mention his name on here again. It just brings a dark, dark vibe... On Thu, Jul 2, 2015 at 11:40 PM, Jay Ashworth wrote: > John Curran gets a quote; NBC gets the etymology of "IPv4" wrong. > > Just keep them away from Jim Fleming. > > > http://www.nbcnews.com/news/us-news/internet-now-officially-too-big-ip-addresses-run-out-n386081 > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > -- // jamie rishaw // Chess is just a game, and real people aren't pieces. You can't assign more value to some of them than to others... Anyone who looks on the world as if it was a game of Chess.. deserves to lose. From cscora at apnic.net Fri Jul 3 18:12:50 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Jul 2015 04:12:50 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201507031812.t63ICogw021801@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 04 Jul, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 550249 Prefixes after maximum aggregation (per Origin AS): 208674 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 268411 Total ASes present in the Internet Routing Table: 50789 Prefixes per ASN: 10.83 Origin-only ASes present in the Internet Routing Table: 36712 Origin ASes announcing only one prefix: 16251 Transit ASes present in the Internet Routing Table: 6315 Transit-only ASes present in the Internet Routing Table: 170 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 39 Max AS path prepend of ASN ( 12486) 32 Prefixes from unregistered ASNs in the Routing Table: 1301 Unregistered ASNs in the Routing Table: 429 Number of 32-bit ASNs allocated by the RIRs: 10078 Number of 32-bit ASNs visible in the Routing Table: 7762 Prefixes from 32-bit ASNs in the Routing Table: 28578 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 430 Number of addresses announced to Internet: 2783922208 Equivalent to 165 /8s, 239 /16s and 72 /24s Percentage of available address space announced: 75.2 Percentage of allocated address space announced: 75.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.4 Total number of prefixes smaller than registry allocations: 184108 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 136211 Total APNIC prefixes after maximum aggregation: 39443 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 142945 Unique aggregates announced from the APNIC address blocks: 57920 APNIC Region origin ASes present in the Internet Routing Table: 5064 APNIC Prefixes per ASN: 28.23 APNIC Region origin ASes announcing only one prefix: 1207 APNIC Region transit ASes present in the Internet Routing Table: 877 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1532 Number of APNIC addresses announced to Internet: 751672000 Equivalent to 44 /8s, 205 /16s and 154 /24s Percentage of available APNIC address space announced: 87.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179696 Total ARIN prefixes after maximum aggregation: 88104 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182248 Unique aggregates announced from the ARIN address blocks: 84956 ARIN Region origin ASes present in the Internet Routing Table: 16607 ARIN Prefixes per ASN: 10.97 ARIN Region origin ASes announcing only one prefix: 6122 ARIN Region transit ASes present in the Internet Routing Table: 1741 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 520 Number of ARIN addresses announced to Internet: 1101810720 Equivalent to 65 /8s, 172 /16s and 76 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 133318 Total RIPE prefixes after maximum aggregation: 66535 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 139867 Unique aggregates announced from the RIPE address blocks: 86823 RIPE Region origin ASes present in the Internet Routing Table: 17973 RIPE Prefixes per ASN: 7.78 RIPE Region origin ASes announcing only one prefix: 8120 RIPE Region transit ASes present in the Internet Routing Table: 2958 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3813 Number of RIPE addresses announced to Internet: 696003072 Equivalent to 41 /8s, 124 /16s and 42 /24s Percentage of available RIPE address space announced: 101.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 60118 Total LACNIC prefixes after maximum aggregation: 11475 LACNIC Deaggregation factor: 5.24 Prefixes being announced from the LACNIC address blocks: 70857 Unique aggregates announced from the LACNIC address blocks: 33085 LACNIC Region origin ASes present in the Internet Routing Table: 2446 LACNIC Prefixes per ASN: 28.97 LACNIC Region origin ASes announcing only one prefix: 610 LACNIC Region transit ASes present in the Internet Routing Table: 508 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1768 Number of LACNIC addresses announced to Internet: 168186432 Equivalent to 10 /8s, 6 /16s and 82 /24s Percentage of available LACNIC address space announced: 100.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12069 Total AfriNIC prefixes after maximum aggregation: 3068 AfriNIC Deaggregation factor: 3.93 Prefixes being announced from the AfriNIC address blocks: 13902 Unique aggregates announced from the AfriNIC address blocks: 5239 AfriNIC Region origin ASes present in the Internet Routing Table: 734 AfriNIC Prefixes per ASN: 18.94 AfriNIC Region origin ASes announcing only one prefix: 192 AfriNIC Region transit ASes present in the Internet Routing Table: 161 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 129 Number of AfriNIC addresses announced to Internet: 65738496 Equivalent to 3 /8s, 235 /16s and 23 /24s Percentage of available AfriNIC address space announced: 65.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2950 11304 937 Korea Telecom 17974 2696 904 78 PT Telekomunikasi Indonesia 7545 2619 336 130 TPG Telecom Limited 4538 2068 4190 71 China Education and Research 4755 2025 423 222 TATA Communications formerly 9829 1765 1353 120 National Internet Backbone 9808 1532 8717 28 Guangdong Mobile Communicatio 9583 1514 119 573 Sify Limited 4808 1460 2240 468 CNCGROUP IP network China169 9498 1361 336 109 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3181 2960 141 Cox Communications Inc. 6389 2758 3688 51 BellSouth.net Inc. 3356 2575 10700 503 Level 3 Communications, Inc. 18566 2059 380 198 MegaPath Corporation 20115 1865 1840 407 Charter Communications 6983 1751 850 244 EarthLink, Inc. 4323 1608 1022 410 tw telecom holdings, inc. 30036 1567 319 446 Mediacom Communications Corp 701 1393 11371 676 MCI Communications Services, 22561 1382 415 257 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 2164 305 366 TELLCOM ILETISIM HIZMETLERI A 20940 2012 788 1457 Akamai International B.V. 6849 1209 355 21 JSC "Ukrtelecom" 13188 1048 97 75 TOV "Bank-Inform" 31148 1048 45 23 Freenet Ltd. 8402 1032 544 15 OJSC "Vimpelcom" 12479 952 869 74 France Telecom Espana SA 6830 912 2694 468 Liberty Global Operations B.V 8551 887 376 53 Bezeq International-Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3265 532 236 Telmex Colombia S.A. 28573 2279 2170 113 NET Servi?os de Comunica??o S 8151 1695 3253 475 Uninet S.A. de C.V. 7303 1630 1007 238 Telecom Argentina S.A. 6147 1387 372 43 Telefonica del Peru S.A.A. 6503 1267 421 56 Axtel, S.A.B. de C.V. 26615 1077 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 951 428 161 COLOMBIA TELECOMUNICACIONES S 11830 892 364 15 Instituto Costarricense de El Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 876 280 26 Link Egypt (Link.NET) 8452 838 958 13 TE-AS 36903 512 258 99 Office National des Postes et 36992 423 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 307 146 12 Vodafone Data 3741 250 857 208 Internet Solutions 29571 238 21 13 Cote d'Ivoire Telecom 36947 193 807 13 Telecom Algeria 15706 174 32 6 Sudatel (Sudan Telecom Co. Lt Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3265 532 236 Telmex Colombia S.A. 22773 3181 2960 141 Cox Communications Inc. 4766 2950 11304 937 Korea Telecom 6389 2758 3688 51 BellSouth.net Inc. 17974 2696 904 78 PT Telekomunikasi Indonesia 7545 2619 336 130 TPG Telecom Limited 3356 2575 10700 503 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2279 2170 113 NET Servi?os de Comunica??o S 34984 2164 305 366 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3181 3040 Cox Communications Inc. 6389 2758 2707 BellSouth.net Inc. 17974 2696 2618 PT Telekomunikasi Indonesia 7545 2619 2489 TPG Telecom Limited 39891 2472 2466 SaudiNet, Saudi Telecom Compa 28573 2279 2166 NET Servi?os de Comunica??o S 3356 2575 2072 Level 3 Communications, Inc. 4766 2950 2013 Korea Telecom 4538 2068 1997 China Education and Research 18566 2059 1861 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:13 /10:36 /11:95 /12:263 /13:506 /14:1003 /15:1725 /16:12937 /17:7278 /18:12362 /19:25560 /20:35988 /21:38779 /22:60280 /23:52141 /24:298259 /25:1100 /26:1144 /27:715 /28:14 /29:12 /30:7 /31:0 /32:15 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2381 3181 Cox Communications Inc. 18566 2005 2059 MegaPath Corporation 6389 1629 2758 BellSouth.net Inc. 34984 1422 2164 TELLCOM ILETISIM HIZMETLERI A 6983 1398 1751 EarthLink, Inc. 30036 1387 1567 Mediacom Communications Corp 10620 1149 3265 Telmex Colombia S.A. 11492 1108 1191 CABLE ONE, INC. 22561 1055 1382 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1502 2:687 4:93 5:1866 6:25 8:1390 11:1 12:1820 13:14 14:1383 15:17 16:2 17:42 18:22 20:48 23:1251 24:1736 27:1987 31:1596 32:38 33:2 34:4 35:3 36:124 37:1960 38:1042 39:6 40:82 41:2700 42:297 43:1364 44:28 45:745 46:2298 47:44 49:908 50:802 52:12 54:77 55:4 56:6 57:42 58:1326 59:724 60:480 61:1747 62:1355 63:1914 64:4452 65:2270 66:4045 67:2074 68:1070 69:3252 70:1023 71:443 72:1971 74:2665 75:334 76:426 77:1272 78:1172 79:801 80:1361 81:1301 82:844 83:722 84:726 85:1374 86:439 87:1062 88:528 89:1898 90:144 91:5996 92:841 93:2269 94:2060 95:2199 96:428 97:347 98:1052 99:53 100:72 101:845 103:7755 104:1781 105:61 106:264 107:1003 108:630 109:2066 110:1145 111:1463 112:843 113:1109 114:843 115:1255 116:1402 117:1064 118:1858 119:1447 120:455 121:1106 122:2122 123:1841 124:1526 125:1622 128:645 129:390 130:407 131:1196 132:508 133:171 134:403 135:94 136:331 137:315 138:923 139:152 140:236 141:450 142:666 143:497 144:551 145:121 146:748 147:585 148:1214 149:420 150:557 151:648 152:519 153:248 154:463 155:871 156:434 157:420 158:352 159:1000 160:396 161:650 162:1947 163:438 164:689 165:691 166:306 167:833 168:1275 169:182 170:1468 171:245 172:274 173:1534 174:718 175:703 176:1396 177:3857 178:2157 179:957 180:1936 181:1582 182:1824 183:627 184:763 185:3789 186:2728 187:1768 188:2051 189:1574 190:7722 191:1002 192:8509 193:5620 194:4177 195:3696 196:1991 197:982 198:5534 199:5496 200:6604 201:3252 202:9515 203:9119 204:4705 205:2842 206:3059 207:2969 208:3982 209:3975 210:3575 211:1888 212:2568 213:2299 214:840 215:73 216:5756 217:1817 218:711 219:469 220:1457 221:791 222:490 223:773 End of report From cidr-report at potaroo.net Fri Jul 3 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jul 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201507032200.t63M00no082916@wattle.apnic.net> This report has been generated at Fri Jul 3 21:18:39 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 26-06-15 559284 304656 27-06-15 559355 304870 28-06-15 559516 304889 29-06-15 559583 305132 30-06-15 559786 307143 01-07-15 563153 305369 02-07-15 559591 305504 03-07-15 558842 305482 AS Summary 51058 Number of ASes in routing system 20318 Number of ASes announcing only one prefix 3268 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120761600 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 03Jul15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 559024 305540 253484 45.3% All ASes AS22773 3184 171 3013 94.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2758 71 2687 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2697 78 2619 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS9394 2918 315 2603 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS39891 2473 32 2441 98.7% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2282 119 2163 94.8% NET Servi?os de Comunica??o S.A.,BR AS3356 2578 791 1787 69.3% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2950 1234 1716 58.2% KIXS-AS-KR Korea Telecom,KR AS10620 3268 1584 1684 51.5% Telmex Colombia S.A.,CO AS6983 1750 247 1503 85.9% ITCDELTA - Earthlink, Inc.,US AS7545 2666 1170 1496 56.1% TPG-INTERNET-AP TPG Telecom Limited,AU AS9808 1551 67 1484 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS20115 1865 481 1384 74.2% CHARTER-NET-HKY-NC - Charter Communications,US AS4755 2022 696 1326 65.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS9498 1360 122 1238 91.0% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1614 412 1202 74.5% TWTC - tw telecom holdings, inc.,US AS7552 1142 59 1083 94.8% VIETEL-AS-AP Viettel Corporation,VN AS22561 1382 325 1057 76.5% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7303 1630 580 1050 64.4% Telecom Argentina S.A.,AR AS18566 2060 1030 1030 50.0% MEGAPATH5-US - MegaPath Corporation,US AS8402 1032 23 1009 97.8% CORBINA-AS OJSC "Vimpelcom",RU AS4808 1511 506 1005 66.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS6849 1206 216 990 82.1% UKRTELNET JSC UKRTELECOM,UA AS8151 1700 724 976 57.4% Uninet S.A. de C.V.,MX AS4538 2086 1163 923 44.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS26615 1077 177 900 83.6% Tim Celular S.A.,BR AS4780 1109 247 862 77.7% SEEDNET Digital United Inc.,TW AS38285 980 128 852 86.9% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS55430 847 66 781 92.2% STARHUBINTERNET-AS-NGNBN Starhub Internet Pte Ltd,SG Total 56697 12917 43780 77.2% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.126.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 64.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 88.135.64.0/20 AS48347 MTW-AS JSC MediaSoft Ekspert,RU 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.218.36.0/22 AS19714 -Reserved AS-,ZZ 91.229.5.0/24 AS56923 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.24.204.0/22 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 103.24.204.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 103.24.205.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 103.24.206.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 103.24.207.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 103.25.144.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.27.212.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.37.188.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.38.152.0/24 AS1828 UNITAS - Unitas Global LLC,US 103.38.154.0/24 AS1828 UNITAS - Unitas Global LLC,US 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.227.4.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.227.184.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.228.8.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.228.84.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.228.224.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.229.152.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.230.12.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.230.16.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.230.68.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.230.124.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.230.140.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.232.104.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.199.200.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.201.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.202.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.203.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.204.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.205.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.206.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.207.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 138.185.112.0/22 AS28066 COOP. MARIANO ACOSTA,AR 138.185.180.0/22 AS28255 WEST INTERNET BANDA LARGA,BR 138.185.184.0/22 AS61893 RM dos Santos Informatica,BR 140.81.0.0/16 AS20053 RELAX-LLC-AS LLC Relax,RU 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 144.1.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 151.216.32.0/24 AS20199 SERVERPARS Rayan Pardaz Khorshid Shargh Ltd.,IR 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 179.60.128.0/20 AS26317 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.40.183.0/24 AS62300 -Reserved AS-,ZZ 185.107.84.0/22 AS60032 CCS SNC CCS,FR 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 188.190.96.0/19 AS19714 -Reserved AS-,ZZ 188.190.103.0/24 AS19714 -Reserved AS-,ZZ 188.190.112.0/24 AS19714 -Reserved AS-,ZZ 188.190.113.0/24 AS19714 -Reserved AS-,ZZ 188.190.114.0/24 AS19714 -Reserved AS-,ZZ 188.190.117.0/24 AS19714 -Reserved AS-,ZZ 188.190.118.0/24 AS19714 -Reserved AS-,ZZ 188.190.119.0/24 AS19714 -Reserved AS-,ZZ 188.190.120.0/24 AS19714 -Reserved AS-,ZZ 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.149.245.0/24 AS53355 CUW-1 - Concordia University Wisconsin,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.105.154.0/24 AS34023 -Reserved AS-,ZZ 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.9.9.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd.,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.103.89.0/24 AS19523 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.193.14.0/23 AS55229 WSHOSTING - White Sands Hosting,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.59.208.0/20 AS26317 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.133.208.0/20 AS17440 PRONET-AP Putrabu Rajasa Galuh, PT,ID 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 3 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jul 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201507032200.t63M017p082936@wattle.apnic.net> BGP Update Report Interval: 25-Jun-15 -to- 02-Jul-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 380679 7.9% 308.5 -- BSNL-NIB National Internet Backbone,IN 2 - AS11139 351030 7.3% 3441.5 -- CWDOM - Cable & Wireless Dominica,DM 3 - AS23752 276685 5.8% 2249.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - AS36947 86995 1.8% 604.1 -- ALGTEL-AS,DZ 5 - AS3709 69609 1.4% 2578.1 -- NET-CITY-SA - City of San Antonio,US 6 - AS54169 65669 1.4% 65669.0 -- MGH-ION-1 - Marin General Hospital,US 7 - AS14287 63873 1.3% 9124.7 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 8 - AS18566 58620 1.2% 175.5 -- MEGAPATH5-US - MegaPath Corporation,US 9 - AS3316 57167 1.2% 1633.3 -- RELARN Association of scientific and educational organizations-computer networks users "RELARN",RU 10 - AS22059 41113 0.9% 20556.5 -- -Reserved AS-,ZZ 11 - AS25438 40155 0.8% 378.8 -- ASN-ICCNET International Computer Company, Ltd.,SA 12 - AS209 39450 0.8% 10.9 -- CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 13 - AS25563 38456 0.8% 12818.7 -- WEBLAND-AS Webland AG,CH 14 - AS38197 36248 0.8% 37.4 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 15 - AS34984 24286 0.5% 38.0 -- TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR 16 - AS59943 22829 0.5% 22829.0 -- RADAR-AS Radar LLC,RU 17 - AS48159 22193 0.5% 63.8 -- TIC-AS Telecommunication Infrastructure Company,IR 18 - AS10620 21456 0.5% 13.6 -- Telmex Colombia S.A.,CO 19 - AS38264 19074 0.4% 68.4 -- WATEEN-IMS-PK-AS-AP National WiMAX/IMS environment,PK 20 - AS9341 18824 0.4% 319.1 -- ICONPLN-ID-AP PT Indonesia Comnets Plus,ID TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54169 65669 1.4% 65669.0 -- MGH-ION-1 - Marin General Hospital,US 2 - AS59943 22829 0.5% 22829.0 -- RADAR-AS Radar LLC,RU 3 - AS22059 41113 0.9% 20556.5 -- -Reserved AS-,ZZ 4 - AS25563 38456 0.8% 12818.7 -- WEBLAND-AS Webland AG,CH 5 - AS393588 9732 0.2% 9732.0 -- MUBEA-FLO - Mubea,US 6 - AS61039 9256 0.2% 9256.0 -- ZMZ OAO ZMZ,RU 7 - AS14287 63873 1.3% 9124.7 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 8 - AS40637 8678 0.2% 8678.0 -- MAILROUTE - MailRoute, Inc.,US 9 - AS10013 6042 0.1% 6042.0 -- FBDC FreeBit Co.,Ltd.,JP 10 - AS21973 5790 0.1% 5790.0 -- XPONET - Xponet,US 11 - AS31357 11188 0.2% 5594.0 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 12 - AS201522 4067 0.1% 4067.0 -- UB330-NET UB330.net d.o.o.,SI 13 - AS11139 351030 7.3% 3441.5 -- CWDOM - Cable & Wireless Dominica,DM 14 - AS51088 3424 0.1% 3424.0 -- A2B A2B IP B.V.,NL 15 - AS19502 3293 0.1% 3293.0 -- CRANEWAREINSIGHT-AS - Craneware Insight, Inc.,US 16 - AS55741 2684 0.1% 2684.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN 17 - AS3709 69609 1.4% 2578.1 -- NET-CITY-SA - City of San Antonio,US 18 - AS40493 2520 0.1% 2520.0 -- FACILITYSOURCEINC - FacilitySource,US 19 - AS39045 2496 0.1% 2496.0 -- GAZTELECOM-AS LLC "Gazprom telecom",RU 20 - AS52233 9930 0.2% 2482.5 -- Columbus Communications Curacao NV,CW TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 137708 2.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 137600 2.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 105.96.0.0/22 83944 1.7% AS36947 -- ALGTEL-AS,DZ 4 - 204.80.242.0/24 65669 1.3% AS54169 -- MGH-ION-1 - Marin General Hospital,US 5 - 185.65.148.0/24 22829 0.5% AS59943 -- RADAR-AS Radar LLC,RU 6 - 64.34.125.0/24 20866 0.4% AS22059 -- -Reserved AS-,ZZ 7 - 76.191.107.0/24 20247 0.4% AS22059 -- -Reserved AS-,ZZ 8 - 208.163.55.0/24 15193 0.3% AS10292 -- CWJ-1 - Cable & Wireless Jamaica,JM 9 - 92.43.216.0/21 12983 0.3% AS25563 -- WEBLAND-AS Webland AG,CH 10 - 185.84.192.0/22 12806 0.3% AS25563 -- WEBLAND-AS Webland AG,CH 11 - 208.73.244.0/22 12781 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 12 - 208.88.232.0/22 12774 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 13 - 208.78.116.0/22 12774 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 14 - 216.162.0.0/20 12774 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 15 - 208.70.20.0/22 12762 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 16 - 178.174.96.0/19 12667 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 17 - 78.140.0.0/18 11185 0.2% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 18 - 192.58.137.0/24 9732 0.2% AS393588 -- MUBEA-FLO - Mubea,US 19 - 203.192.255.0/24 9552 0.2% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd.,IN 20 - 69.73.201.0/24 9374 0.2% AS11139 -- CWDOM - Cable & Wireless Dominica,DM Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jmoore at atcnetworks.net Sat Jul 4 12:09:20 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sat, 4 Jul 2015 12:09:20 +0000 Subject: Dual stack IPv6 for IPv4 depletion Message-ID: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE. Consider the following: An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? Many sites and services would still need legacy IPv4 compatibility. Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. My question is this: What, if any, solutions like this exist? If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be? Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion. Thanks Joshua Moore Network Engineer ATC Broadband 912.632.3161 From cb.list6 at gmail.com Sun Jul 5 02:35:48 2015 From: cb.list6 at gmail.com (Ca By) Date: Sat, 4 Jul 2015 19:35:48 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> References: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> Message-ID: On Saturday, July 4, 2015, Josh Moore wrote: > Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE. > Consider the following: > > An ISP is at 90% IPv4 utilization and would like to deploy dual stack with > the purpose of allowing their subscriber base to continue to grow > regardless of the depletion of the IPv4 space. Current dual stack best > practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If > this is the case, and BOTH are still required, then how does IPv6 help with > the v4 address depletion crisis? Many sites and services would still need > legacy IPv4 compatibility. Sure, CGN technology may be a solution but what > about applications that need direct IPv4 connectivity without NAT? It seems > that there should be a mechanism to enable on-demand and efficient IPv4 > address consumption ONLY when needed. My question is this: What, if any, > solutions like this exist? If no solution exists then what is the next best > thing? What would the overall IPv6 migration strategy and goal be? > > Sorry for the length of this email but these are legitimate concerns and > while I understand the need for IPv6 and the importance of getting there; I > don't understand exactly HOW that can be done considering the immediate > issue: IPv4 depletion. > > > Thanks > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > Yep, dual-stack does not solve problems for eyeball networks. This is why eyeball networks use ds-lite, 464xlat, and map. Each requires some sort of compromise. At the end of the day, we all need to reject 'direct ipv4', it is an invalid requirement that cannot be supported at scale over time. From jmoore at atcnetworks.net Sun Jul 5 03:01:06 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sun, 5 Jul 2015 03:01:06 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net>, Message-ID: But what is the "best compromise" strategy? Dual stack + CGN? Some kind of intelligent 6to4 NAT? Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 On Jul 4, 2015, at 10:35 PM, Ca By > wrote: On Saturday, July 4, 2015, Josh Moore > wrote: Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE. Consider the following: An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? Many sites and services would still need legacy IPv4 compatibility. Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. My question is this: What, if any, solutions like this exist? If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be? Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion. Thanks Joshua Moore Network Engineer ATC Broadband 912.632.3161 Yep, dual-stack does not solve problems for eyeball networks. This is why eyeball networks use ds-lite, 464xlat, and map. Each requires some sort of compromise. At the end of the day, we all need to reject 'direct ipv4', it is an invalid requirement that cannot be supported at scale over time. From johnl at iecc.com Sun Jul 5 03:41:26 2015 From: johnl at iecc.com (John Levine) Date: 5 Jul 2015 03:41:26 -0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Message-ID: <20150705034126.10907.qmail@ary.lan> In article you write: >But what is the "best compromise" strategy? Dual stack + CGN? Some kind of intelligent 6to4 NAT? Depends on the application(s). One that seems to work OK is to dual stack everyone and put them behind a NAT unless they ask to have a private IP. Depending on who your customers are, charge more for a private IP, or if you want to look less obviously venal, say you're offering a discount to customers who move their applications that require end-to-end addressing to IPv6. It is my strong impression that people who think they're 100% IPv6 enabled still often need a little IPv4 (NAT OK) for bootstrapping and the like, so you need to dual stack no matter what you do. If you do charge extra for IPv4, that makes it easier to go buy used IPv4 space on the aftermarket. R's, John From mel at beckman.org Sun Jul 5 06:13:52 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 06:13:52 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150705034126.10907.qmail@ary.lan> References: <20150705034126.10907.qmail@ary.lan> Message-ID: Josh, The price of IPv4 addresses will go up now that supply is seriously constrained. The price increase will push information producers, who generally are the people needing public IPv4 space, over to IPv6, which is plentiful. This will create a class of services that is IPv6-only (e.g., Microsoft DirectAccess), which will encourage IPv4 information consumers to dual-stack. IPv4-only consumers will find themselves in an information ghetto, but one that they can easily get out of by just exerting a little effort. In the worst case scenario, an ISP customer stuck behind an IPv4 Internet connection can simply tunnel to IPv6 via one of the free tunnelbroker services such as HE.net?s tunnelbroker.net. This is a problem that will solve itself in a natural, and capitalist, way. Market pressures will push everyone to IPv6, and nobody need be left behind. I predict some enterprising inventor will create (if they haven?t already) a cheap IPv6 appliance akin to Roku or Apple TV that anyone can just drop onto their network to become IPv6 enabled via a tunnelbroker. In fact, I show just how to do this using a $99 Apple Airport Express in my three-hour online course ?Build your own IPv6 Lab? (http://windowsitpro.com/build-your-own-ipv6-lab-and-become-ipv6-guru-demand). If you don?t have an IPv6 lab yet, you should set one up ASAP. That?s the easiest way to get your head around all IPv6 issues. HE.net also has a very nice certification program that will take you through all the basic tasks of being IPv6 enabled both as an information producer and a consumer. -mel On Jul 4, 2015, at 8:41 PM, John Levine > wrote: In article > you write: But what is the "best compromise" strategy? Dual stack + CGN? Some kind of intelligent 6to4 NAT? Depends on the application(s). One that seems to work OK is to dual stack everyone and put them behind a NAT unless they ask to have a private IP. Depending on who your customers are, charge more for a private IP, or if you want to look less obviously venal, say you're offering a discount to customers who move their applications that require end-to-end addressing to IPv6. It is my strong impression that people who think they're 100% IPv6 enabled still often need a little IPv4 (NAT OK) for bootstrapping and the like, so you need to dual stack no matter what you do. If you do charge extra for IPv4, that makes it easier to go buy used IPv4 space on the aftermarket. R's, John From mel at beckman.org Sun Jul 5 06:25:53 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 06:25:53 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> Message-ID: <1F668CAB-A083-4E06-BC6A-1C50CA0EF715@beckman.org> Josh, Incidentally, you don?t even need to spend $99 on a hardware device. Jeff Carrell of TeachMeIPv6.com has a nice slide deck on building an IPv6 lab using VirtualBox: http://dfw.cisco-users.org/zips/201400305_DFWCUG_IPv6%20-%20Build%20Your%20Own%20Lab%20%28with%20only%20IPv4%20Internet%20access%29.pdf I think building an IPv6 lab is easier, and more practical, using the Airport Express, but I want to illustrate that cost need not be a barrier. -mel On Jul 4, 2015, at 11:13 PM, Mel Beckman > wrote: Josh, The price of IPv4 addresses will go up now that supply is seriously constrained. The price increase will push information producers, who generally are the people needing public IPv4 space, over to IPv6, which is plentiful. This will create a class of services that is IPv6-only (e.g., Microsoft DirectAccess), which will encourage IPv4 information consumers to dual-stack. IPv4-only consumers will find themselves in an information ghetto, but one that they can easily get out of by just exerting a little effort. In the worst case scenario, an ISP customer stuck behind an IPv4 Internet connection can simply tunnel to IPv6 via one of the free tunnelbroker services such as HE.net?s tunnelbroker.net. This is a problem that will solve itself in a natural, and capitalist, way. Market pressures will push everyone to IPv6, and nobody need be left behind. I predict some enterprising inventor will create (if they haven?t already) a cheap IPv6 appliance akin to Roku or Apple TV that anyone can just drop onto their network to become IPv6 enabled via a tunnelbroker. In fact, I show just how to do this using a $99 Apple Airport Express in my three-hour online course ?Build your own IPv6 Lab? (http://windowsitpro.com/build-your-own-ipv6-lab-and-become-ipv6-guru-demand). If you don?t have an IPv6 lab yet, you should set one up ASAP. That?s the easiest way to get your head around all IPv6 issues. HE.net also has a very nice certification program that will take you through all the basic tasks of being IPv6 enabled both as an information producer and a consumer. -mel On Jul 4, 2015, at 8:41 PM, John Levine > wrote: In article > you write: But what is the "best compromise" strategy? Dual stack + CGN? Some kind of intelligent 6to4 NAT? Depends on the application(s). One that seems to work OK is to dual stack everyone and put them behind a NAT unless they ask to have a private IP. Depending on who your customers are, charge more for a private IP, or if you want to look less obviously venal, say you're offering a discount to customers who move their applications that require end-to-end addressing to IPv6. It is my strong impression that people who think they're 100% IPv6 enabled still often need a little IPv4 (NAT OK) for bootstrapping and the like, so you need to dual stack no matter what you do. If you do charge extra for IPv4, that makes it easier to go buy used IPv4 space on the aftermarket. R's, John From Valdis.Kletnieks at vt.edu Sun Jul 5 06:51:20 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 05 Jul 2015 02:51:20 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "05 Jul 2015 03:41:26 -0000." <20150705034126.10907.qmail@ary.lan> References: <20150705034126.10907.qmail@ary.lan> Message-ID: <212314.1436079080@turing-police.cc.vt.edu> On 05 Jul 2015 03:41:26 -0000, "John Levine" said: > Depends on the application(s). One that seems to work OK is to dual > stack everyone and put them behind a NAT unless they ask to have a > private IP. Put their IPv4 behind a NAT and a globally routed /56. There, FTFY. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog at jima.us Sun Jul 5 08:06:38 2015 From: nanog at jima.us (Jima) Date: Sun, 05 Jul 2015 02:06:38 -0600 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> Message-ID: <5598E58E.7090600@jima.us> I don't have any skin in the game, but the following devices popped into my head while reading that paragraph: http://www.gogo6.com/gogoware/gogoserver http://www.gogo6.com/gogoware/gogocpe Jima On 2015-07-05 00:13, Mel Beckman wrote: > I predict some enterprising inventor will create (if they haven?t already) a cheap IPv6 appliance akin to Roku or Apple TV that anyone can just drop onto their network to become IPv6 enabled via a tunnelbroker. From baldur.norddahl at gmail.com Sun Jul 5 09:21:33 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 5 Jul 2015 11:21:33 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> References: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> Message-ID: Hi, Currently IPv4 is rather cheap. The first step is to conserve your resources by deploying schemes to effectively use your IPv4 allocation. You have to drop using a /30 for each customer and instead have your customer on a shared subnet. We group our customers up to 60 customers in a /26. I do not believe IPv4 will become expensive for some time. There are simply too many people that made sure they got more than their share of the pool and now they are all trying to sell the excess. Also many companies will realize the need to optimize their IPv4 usage and as soon they do, they will realize they actually posses excess IPv4 that can be sold. This is especially true for the ARIN zone, where you have the most IPv4 address space compared to population size. So the answer for now is that you can continue business as usual. Something that used to be free is now a cost, but it is not very expensive. Of course not deploying IPv6 is a bad idea. It is in your best interest to promote IPv6 so you have that, when IPv4 becomes too expensive. When that time comes, I am betting on one of the Address plus Port schemes. Most promising is MAP. You will have several users sharing an IPv4 address. It will be ok for surfing the web but it will suck for many other things. Therefore you want widespread use of IPv6 by the time you deploy this. If everyone are using IPv6 most of the time, the customers are likely to care less about the limitations of sharing an IPv4 address. Regards, Baldur From wwaites at tardis.ed.ac.uk Sun Jul 5 09:32:27 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sun, 05 Jul 2015 10:32:27 +0100 (BST) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> Message-ID: <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> On Sun, 5 Jul 2015 06:13:52 +0000, Mel Beckman said: > In fact, I show just how to do this using a $99 Apple Airport > Express in my three-hour online course ?Build your own IPv6 Lab? An anectode about this, maybe out of date, maybe not. I was helping my friend who likes Apple things connect to the local community network. He wanted to use an Airport as his home gateway rather than the router that we normally use. Turns out these things can *only* do IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is not exactly a clear path to native IPv6 for your lab this way. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From jmoore at atcnetworks.net Sun Jul 5 10:21:00 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sun, 5 Jul 2015 10:21:00 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> References: <20150705034126.10907.qmail@ary.lan> , <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> Message-ID: <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> Creating this in a test lab is mandatory for a successful migration. Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. Seems that my initial thoughts of dual stack and v4 overloading using private addresses to ensure compatibility is the way to go. Any input on good, possibly application aware, CGN solutions? Maybe even some policy-based DHCP/NAT product? Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 > On Jul 5, 2015, at 5:35 AM, William Waites wrote: > > On Sun, 5 Jul 2015 06:13:52 +0000, Mel Beckman said: > >> In fact, I show just how to do this using a $99 Apple Airport >> Express in my three-hour online course ?Build your own IPv6 Lab? > > An anectode about this, maybe out of date, maybe not. I was helping my > friend who likes Apple things connect to the local community > network. He wanted to use an Airport as his home gateway rather than > the router that we normally use. Turns out these things can *only* do > IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is > not exactly a clear path to native IPv6 for your lab this way. > > -w From jared at puck.nether.net Sun Jul 5 12:24:33 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 5 Jul 2015 08:24:33 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> Message-ID: > On Jul 5, 2015, at 5:32 AM, William Waites wrote: > > On Sun, 5 Jul 2015 06:13:52 +0000, Mel Beckman said: > >> In fact, I show just how to do this using a $99 Apple Airport >> Express in my three-hour online course ?Build your own IPv6 Lab? > > An anectode about this, maybe out of date, maybe not. I was helping my > friend who likes Apple things connect to the local community > network. He wanted to use an Airport as his home gateway rather than > the router that we normally use. Turns out these things can *only* do > IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is > not exactly a clear path to native IPv6 for your lab this way. The airport devices/airport express class are not that good of devices as the embedded software doesn?t handle a lot of traffic or long uptime well. Most devices that are over 3 years old likely are not suitable for IPv6 testing aside from understanding what is broken. Keep in mind that software on a CPE device may be 6 months out of date by the time it comes out of a container stateside. Expecting people to use tunnels, etc doesn?t really scale properly. I do wish that I could get static IPv6 prefixes along with my static IPv4 at home, but having IPv6 at all took precedence. - Jared From mel at beckman.org Sun Jul 5 13:55:20 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 13:55:20 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> References: <20150705034126.10907.qmail@ary.lan> , <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk>, <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> Message-ID: > > Josh Moore wrote: > > Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. William Waites wrote: > I was helping my > friend who likes Apple things connect to the local community > network. He wanted to use an Airport as his home gateway rather than > the router that we normally use. Turns out these things can *only* do > IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is > not exactly a clear path to native IPv6 for your lab this way. Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. So you are in a maze of non-twisty paths, all alike :) From jmoore at atcnetworks.net Sun Jul 5 13:57:43 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sun, 5 Jul 2015 13:57:43 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> , <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk>, <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net>, Message-ID: <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> We are the ISP and I have a /32 :) I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >> >> Josh Moore wrote: >> >> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. > > No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. > > William Waites wrote: >> I was helping my >> friend who likes Apple things connect to the local community >> network. He wanted to use an Airport as his home gateway rather than >> the router that we normally use. Turns out these things can *only* do >> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >> not exactly a clear path to native IPv6 for your lab this way. > > Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. > > So you are in a maze of non-twisty paths, all alike :) From mel at beckman.org Sun Jul 5 14:05:53 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 14:05:53 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk>, Message-ID: Jared, Tunneling gets customers onto IPv6 with little trouble. I've deployed hundred of Apple Airports in this capacity and they have no problem with speeds of 200Mbps and more, and they rarely have downtime. The firmware is auto-updating and is kept very current by Apple. The one feature they don't support well is IPv6 DNS, since Airport has no DHCPv6 support. But an IPv4 name server works fine since the customers have an IPv4 link already. -mel > On Jul 5, 2015, at 5:24 AM, Jared Mauch wrote: > > >> On Jul 5, 2015, at 5:32 AM, William Waites wrote: >> >> On Sun, 5 Jul 2015 06:13:52 +0000, Mel Beckman said: >> >>> In fact, I show just how to do this using a $99 Apple Airport >>> Express in my three-hour online course ?Build your own IPv6 Lab? >> >> An anectode about this, maybe out of date, maybe not. I was helping my >> friend who likes Apple things connect to the local community >> network. He wanted to use an Airport as his home gateway rather than >> the router that we normally use. Turns out these things can *only* do >> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >> not exactly a clear path to native IPv6 for your lab this way. > > The airport devices/airport express class are not that good of devices > as the embedded software doesn?t handle a lot of traffic or long uptime > well. > > Most devices that are over 3 years old likely are not suitable for > IPv6 testing aside from understanding what is broken. Keep in mind > that software on a CPE device may be 6 months out of date by the time > it comes out of a container stateside. > > Expecting people to use tunnels, etc doesn?t really scale properly. > > I do wish that I could get static IPv6 prefixes along with my > static IPv4 at home, but having IPv6 at all took precedence. > > - Jared From mel at beckman.org Sun Jul 5 14:12:37 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 14:12:37 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> References: <20150705034126.10907.qmail@ary.lan> , <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk>, <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net>, , <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> Message-ID: Josh, Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. -mel via cell > On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: > > We are the ISP and I have a /32 :) > > I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > > On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: > >>> >>> Josh Moore wrote: >>> >>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >> >> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >> >> William Waites wrote: >>> I was helping my >>> friend who likes Apple things connect to the local community >>> network. He wanted to use an Airport as his home gateway rather than >>> the router that we normally use. Turns out these things can *only* do >>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>> not exactly a clear path to native IPv6 for your lab this way. >> >> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >> >> So you are in a maze of non-twisty paths, all alike :) From jmoore at atcnetworks.net Sun Jul 5 14:25:37 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sun, 5 Jul 2015 14:25:37 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> , <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk>, <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net>, , <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net>, Message-ID: <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> So the question is: where do you perform the NAT and how can it be redundant? Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 > On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: > > Josh, > > Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. > > -mel via cell > >> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >> >> We are the ISP and I have a /32 :) >> >> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >> >>>> >>>> Josh Moore wrote: >>>> >>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>> >>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>> >>> William Waites wrote: >>>> I was helping my >>>> friend who likes Apple things connect to the local community >>>> network. He wanted to use an Airport as his home gateway rather than >>>> the router that we normally use. Turns out these things can *only* do >>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>> not exactly a clear path to native IPv6 for your lab this way. >>> >>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>> >>> So you are in a maze of non-twisty paths, all alike :) From nanog at ics-il.net Sun Jul 5 14:34:16 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 5 Jul 2015 09:34:16 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Message-ID: <599500055.150.1436106852275.JavaMail.mhammett@ThunderFuck> I believe he (at least someone) was looking for recommendations to CGN type devices. Many can do NAT, but looking for something a bit more intelligent. Your standard residential user may not understand, but would also be unwilling to pay any difference. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mel Beckman" To: "Josh Moore" Cc: johnl at iecc.com, nanog at nanog.org Sent: Sunday, July 5, 2015 9:12:37 AM Subject: Re: Dual stack IPv6 for IPv4 depletion Josh, Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. -mel via cell > On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: > > We are the ISP and I have a /32 :) > > I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > > On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: > >>> >>> Josh Moore wrote: >>> >>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >> >> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >> >> William Waites wrote: >>> I was helping my >>> friend who likes Apple things connect to the local community >>> network. He wanted to use an Airport as his home gateway rather than >>> the router that we normally use. Turns out these things can *only* do >>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>> not exactly a clear path to native IPv6 for your lab this way. >> >> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >> >> So you are in a maze of non-twisty paths, all alike :) From mel at beckman.org Sun Jul 5 14:43:40 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 14:43:40 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> References: <20150705034126.10907.qmail@ary.lan> , <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk>, <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net>, , <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net>, , <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> Message-ID: WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. -mel beckman > On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: > > So the question is: where do you perform the NAT and how can it be redundant? > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >> >> Josh, >> >> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >> >> -mel via cell >> >>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>> >>> We are the ISP and I have a /32 :) >>> >>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>> >>> >>> >>> >>> Thanks, >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 >>> >>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>> >>>>> >>>>> Josh Moore wrote: >>>>> >>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>> >>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>> >>>> William Waites wrote: >>>>> I was helping my >>>>> friend who likes Apple things connect to the local community >>>>> network. He wanted to use an Airport as his home gateway rather than >>>>> the router that we normally use. Turns out these things can *only* do >>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>> not exactly a clear path to native IPv6 for your lab this way. >>>> >>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>> >>>> So you are in a maze of non-twisty paths, all alike :) From mel at beckman.org Sun Jul 5 14:47:14 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 14:47:14 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <599500055.150.1436106852275.JavaMail.mhammett@ThunderFuck> References: , <599500055.150.1436106852275.JavaMail.mhammett@ThunderFuck> Message-ID: That's only an issue if you distribute a public IPv4 address to each customer. If you use private addressing in the core, ordinary NAT works if you're not a carrier-grade provider, and even then it can be practical in many cases. CGN is a solution for providers not willing to migrate to a private core. -mel beckman > On Jul 5, 2015, at 7:35 AM, Mike Hammett wrote: > > I believe he (at least someone) was looking for recommendations to CGN type devices. Many can do NAT, but looking for something a bit more intelligent. Your standard residential user may not understand, but would also be unwilling to pay any difference. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Mel Beckman" > To: "Josh Moore" > Cc: johnl at iecc.com, nanog at nanog.org > Sent: Sunday, July 5, 2015 9:12:37 AM > Subject: Re: Dual stack IPv6 for IPv4 depletion > > Josh, > > Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. > > -mel via cell > >> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >> >> We are the ISP and I have a /32 :) >> >> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >> >>>> >>>> Josh Moore wrote: >>>> >>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>> >>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>> >>> William Waites wrote: >>>> I was helping my >>>> friend who likes Apple things connect to the local community >>>> network. He wanted to use an Airport as his home gateway rather than >>>> the router that we normally use. Turns out these things can *only* do >>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>> not exactly a clear path to native IPv6 for your lab this way. >>> >>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>> >>> So you are in a maze of non-twisty paths, all alike :) > From nanog at ics-il.net Sun Jul 5 14:48:48 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 5 Jul 2015 09:48:48 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Message-ID: <222712908.245.1436107724025.JavaMail.mhammett@ThunderFuck> You must know different WISPs than I know (and I know hundreds). Most WISPs use IPv4 publicly, no IPv6 and don't have any boxes capable of synced NAT tables. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" To: "Josh Moore" Cc: johnl at iecc.com, nanog at nanog.org Sent: Sunday, July 5, 2015 9:43:40 AM Subject: Re: Dual stack IPv6 for IPv4 depletion WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. -mel beckman > On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: > > So the question is: where do you perform the NAT and how can it be redundant? > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >> >> Josh, >> >> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >> >> -mel via cell >> >>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>> >>> We are the ISP and I have a /32 :) >>> >>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>> >>> >>> >>> >>> Thanks, >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 >>> >>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>> >>>>> >>>>> Josh Moore wrote: >>>>> >>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>> >>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>> >>>> William Waites wrote: >>>>> I was helping my >>>>> friend who likes Apple things connect to the local community >>>>> network. He wanted to use an Airport as his home gateway rather than >>>>> the router that we normally use. Turns out these things can *only* do >>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>> not exactly a clear path to native IPv6 for your lab this way. >>>> >>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>> >>>> So you are in a maze of non-twisty paths, all alike :) From nanog at ics-il.net Sun Jul 5 14:51:18 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 5 Jul 2015 09:51:18 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Message-ID: <763103447.258.1436107870418.JavaMail.mhammett@ThunderFuck> Public or private you have the same issues of not putting too many Google requests through the same public v4 address, keeping things at multiple egress points in sync, etc. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" To: "Mike Hammett" Cc: "Nanog" Sent: Sunday, July 5, 2015 9:47:14 AM Subject: Re: Dual stack IPv6 for IPv4 depletion That's only an issue if you distribute a public IPv4 address to each customer. If you use private addressing in the core, ordinary NAT works if you're not a carrier-grade provider, and even then it can be practical in many cases. CGN is a solution for providers not willing to migrate to a private core. -mel beckman > On Jul 5, 2015, at 7:35 AM, Mike Hammett wrote: > > I believe he (at least someone) was looking for recommendations to CGN type devices. Many can do NAT, but looking for something a bit more intelligent. Your standard residential user may not understand, but would also be unwilling to pay any difference. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Mel Beckman" > To: "Josh Moore" > Cc: johnl at iecc.com, nanog at nanog.org > Sent: Sunday, July 5, 2015 9:12:37 AM > Subject: Re: Dual stack IPv6 for IPv4 depletion > > Josh, > > Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. > > -mel via cell > >> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >> >> We are the ISP and I have a /32 :) >> >> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >> >>>> >>>> Josh Moore wrote: >>>> >>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>> >>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>> >>> William Waites wrote: >>>> I was helping my >>>> friend who likes Apple things connect to the local community >>>> network. He wanted to use an Airport as his home gateway rather than >>>> the router that we normally use. Turns out these things can *only* do >>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>> not exactly a clear path to native IPv6 for your lab this way. >>> >>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>> >>> So you are in a maze of non-twisty paths, all alike :) > From jmoore at atcnetworks.net Sun Jul 5 15:11:12 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sun, 5 Jul 2015 15:11:12 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> , <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk>, <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net>, , <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net>, , <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net>, Message-ID: <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 > On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: > > WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. > > -mel beckman > >> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >> >> So the question is: where do you perform the NAT and how can it be redundant? >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>> >>> Josh, >>> >>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>> >>> -mel via cell >>> >>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>> >>>> We are the ISP and I have a /32 :) >>>> >>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Joshua Moore >>>> Network Engineer >>>> ATC Broadband >>>> 912.632.3161 >>>> >>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>> >>>>>> >>>>>> Josh Moore wrote: >>>>>> >>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>> >>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>> >>>>> William Waites wrote: >>>>>> I was helping my >>>>>> friend who likes Apple things connect to the local community >>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>> the router that we normally use. Turns out these things can *only* do >>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>> >>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>> >>>>> So you are in a maze of non-twisty paths, all alike :) From nsuan at nonexiste.net Sun Jul 5 15:17:30 2015 From: nsuan at nonexiste.net (Nicholas Suan) Date: Sun, 5 Jul 2015 11:17:30 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> Message-ID: That's only an issue with airport devices and PPPoE. I can confirm it does native DHCPv6-PD otherwise. On Sun, Jul 5, 2015 at 5:32 AM, William Waites wrote: > On Sun, 5 Jul 2015 06:13:52 +0000, Mel Beckman said: > > > In fact, I show just how to do this using a $99 Apple Airport > > Express in my three-hour online course ?Build your own IPv6 Lab? > > An anectode about this, maybe out of date, maybe not. I was helping my > friend who likes Apple things connect to the local community > network. He wanted to use an Airport as his home gateway rather than > the router that we normally use. Turns out these things can *only* do > IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is > not exactly a clear path to native IPv6 for your lab this way. > > -w From mel at beckman.org Sun Jul 5 15:35:10 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 15:35:10 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <222712908.245.1436107724025.JavaMail.mhammett@ThunderFuck> References: , <222712908.245.1436107724025.JavaMail.mhammett@ThunderFuck> Message-ID: <460E3998-CA5C-4264-B3C0-D57ED17420D3@beckman.org> I guess the WISPs I advise get better advice :) -mel via cell > On Jul 5, 2015, at 7:51 AM, Mike Hammett wrote: > > You must know different WISPs than I know (and I know hundreds). Most WISPs use IPv4 publicly, no IPv6 and don't have any boxes capable of synced NAT tables. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > > ----- Original Message ----- > > From: "Mel Beckman" > To: "Josh Moore" > Cc: johnl at iecc.com, nanog at nanog.org > Sent: Sunday, July 5, 2015 9:43:40 AM > Subject: Re: Dual stack IPv6 for IPv4 depletion > > WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. > > -mel beckman > >> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >> >> So the question is: where do you perform the NAT and how can it be redundant? >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>> >>> Josh, >>> >>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>> >>> -mel via cell >>> >>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>> >>>> We are the ISP and I have a /32 :) >>>> >>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Joshua Moore >>>> Network Engineer >>>> ATC Broadband >>>> 912.632.3161 >>>> >>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>> >>>>>> >>>>>> Josh Moore wrote: >>>>>> >>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>> >>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>> >>>>> William Waites wrote: >>>>>> I was helping my >>>>>> friend who likes Apple things connect to the local community >>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>> the router that we normally use. Turns out these things can *only* do >>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>> >>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>> >>>>> So you are in a maze of non-twisty paths, all alike :) From mel at beckman.org Sun Jul 5 15:52:36 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 15:52:36 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> References: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> Message-ID: Dual-stack doesn't require public IPv4 addresses. Since IPv4 is in short supply, providers must still do what they can to conserve them. This means NAT, with appropriate management to not overload any one IP, or CGN if you want to keep public IPv4 (but no longer unique ones) on CPE. Not every customer needs direct IPv4 connectivity without NAT; those that do must pay for it. If those who have it aren't willing to pay, they must give up their public IPv4 address. That is the most efficient direct IPv4 provisioning concept we have today. Given the history of IPv6 adoption, it's clear that people won't move until they experience pain sticking with IPv4. "On demand" IPv4 isn't currently being done anywhere AFAIK, and since we're abandoning IPv4 it's not likely anyone has that on their priority list. It's not a good policy to go out of your way to make IPv4 users comfortable. IPv4 is going to go away, and the sooner customers get that and go to IPv6, the sooner the pain will stop :) -mel beckman > On Jul 4, 2015, at 6:02 PM, Josh Moore wrote: > > Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE. > Consider the following: > > An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? Many sites and services would still need legacy IPv4 compatibility. Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. My question is this: What, if any, solutions like this exist? If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be? > > Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion. > > > Thanks > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 From jared at puck.nether.net Sun Jul 5 16:22:23 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 5 Jul 2015 12:22:23 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <460E3998-CA5C-4264-B3C0-D57ED17420D3@beckman.org> References: <222712908.245.1436107724025.JavaMail.mhammett@ThunderFuck> <460E3998-CA5C-4264-B3C0-D57ED17420D3@beckman.org> Message-ID: <21385FF4-957C-49A0-B0E0-1BCDFD91FF24@puck.nether.net> > On Jul 5, 2015, at 11:35 AM, Mel Beckman wrote: > > I guess the WISPs I advise get better advice :) I think this is a key item for people to have in mind. We can all follow poor advice and add in new layers of NATs, possibly including certain applications within the NAT cone, or we can deliver DS, or DS-like service via several technologies. There are a lot of devices that can do NAT from roll your own Linux or pfSense style up to commercial solutions that vendors will sell you. (I recall cisco pitching the ASR1K for this years ago). You could even use something like LISP to do these redundancy things within your network. I would treat NAT the same way people treat CDNs which is find the large destinations and encourage people to use IPv6 for those. Looking at the ?top sites? here: http://www.alexa.com/topsites Almost all of them are IPv6 enabled. You can even poke at sites with external tools like this: http://ipv6-test.com/validate.php Frank Bulk also monitors most of the major carrier sites for their IPv6 reliability and stability. He often gets me to contact our IT department to address the issues they have coping with the traffic volumes involved on the IPv6 side for the www.us.ntt.net and www.ntt.net sites. (and yes frank, I got your email and texts yesterday :) ) I would say there is no one right/wrong way to do this, but getting the core of your network IPv6 enabled first then pushing to your edges is a must-do item for the upcoming quarter or two. I was once advised on technical issues where I explained in perfect technical detail the problems and solution path, but the management started talking about the optics of the issue. Take advantage of the NBC, etc coverage to ensure these priorities are taken care of. This may feel like stooping low to some people, but it?s important to get any IPv6 items off your todo list. There is a great ipv6-ops list as well out there where detailed questions can be asked and answered amongst those that are doing similar things. While I dislike what T-Mobile USA has done from a technical side, their success shows that the IPv6 only edge *is* possible. This means we can take away the idea that we *must* have IPv4 for a device to be reachable/considered ?online?. I anxiously await the results of the apple/IPv6/iOS9 changeover and the increased traffic that will occur as a result. I think 2016 will drive the traffic levels to many multiples where they are now and much closer to parity on the global backbones. - Jared From nanog at ics-il.net Sun Jul 5 16:30:08 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 5 Jul 2015 11:30:08 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Message-ID: <2085015272.565.1436113791839.JavaMail.mhammett@ThunderFuck> You don't work with end-users much, do you? The same types that follow Free Press and what not about how their ISP breaks it off in their backside (despite no concrete evidence - see the recent M-Labs, Free Press incident)... they won't take too kindly to being told to pay more for IPv4 to make whatever game work properly. It has to be seamless and it has to be free. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" To: "Josh Moore" Cc: nanog at nanog.org Sent: Sunday, July 5, 2015 10:52:36 AM Subject: Re: Dual stack IPv6 for IPv4 depletion Dual-stack doesn't require public IPv4 addresses. Since IPv4 is in short supply, providers must still do what they can to conserve them. This means NAT, with appropriate management to not overload any one IP, or CGN if you want to keep public IPv4 (but no longer unique ones) on CPE. Not every customer needs direct IPv4 connectivity without NAT; those that do must pay for it. If those who have it aren't willing to pay, they must give up their public IPv4 address. That is the most efficient direct IPv4 provisioning concept we have today. Given the history of IPv6 adoption, it's clear that people won't move until they experience pain sticking with IPv4. "On demand" IPv4 isn't currently being done anywhere AFAIK, and since we're abandoning IPv4 it's not likely anyone has that on their priority list. It's not a good policy to go out of your way to make IPv4 users comfortable. IPv4 is going to go away, and the sooner customers get that and go to IPv6, the sooner the pain will stop :) -mel beckman > On Jul 4, 2015, at 6:02 PM, Josh Moore wrote: > > Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE. > Consider the following: > > An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? Many sites and services would still need legacy IPv4 compatibility. Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. My question is this: What, if any, solutions like this exist? If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be? > > Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion. > > > Thanks > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 From khomyakov.andrey at gmail.com Sun Jul 5 16:45:55 2015 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Sun, 5 Jul 2015 12:45:55 -0400 Subject: Attending NANOG65 question Message-ID: Folks, I'd like to attend NANOG65 (my first NANOG ever), but i can't, for the life of me, figure out how you register for the event. I can't quite locate the registration link on nanog.org. Can someone, please, point me in the right direction? Thanks in advance, --Andrey From mel at beckman.org Sun Jul 5 16:52:52 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 16:52:52 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <2085015272.565.1436113791839.JavaMail.mhammett@ThunderFuck> References: , <2085015272.565.1436113791839.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, They certainly won't like it. But the situation is the same everywhere. It's not like they're being gouged. -mel via cell > On Jul 5, 2015, at 9:30 AM, Mike Hammett wrote: > > You don't work with end-users much, do you? The same types that follow Free Press and what not about how their ISP breaks it off in their backside (despite no concrete evidence - see the recent M-Labs, Free Press incident)... they won't take too kindly to being told to pay more for IPv4 to make whatever game work properly. It has to be seamless and it has to be free. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Mel Beckman" > To: "Josh Moore" > Cc: nanog at nanog.org > Sent: Sunday, July 5, 2015 10:52:36 AM > Subject: Re: Dual stack IPv6 for IPv4 depletion > > Dual-stack doesn't require public IPv4 addresses. Since IPv4 is in short supply, providers must still do what they can to conserve them. This means NAT, with appropriate management to not overload any one IP, or CGN if you want to keep public IPv4 (but no longer unique ones) on CPE. Not every customer needs direct IPv4 connectivity without NAT; those that do must pay for it. If those who have it aren't willing to pay, they must give up their public IPv4 address. > > That is the most efficient direct IPv4 provisioning concept we have today. Given the history of IPv6 adoption, it's clear that people won't move until they experience pain sticking with IPv4. > > "On demand" IPv4 isn't currently being done anywhere AFAIK, and since we're abandoning IPv4 it's not likely anyone has that on their priority list. It's not a good policy to go out of your way to make IPv4 users comfortable. IPv4 is going to go away, and the sooner customers get that and go to IPv6, the sooner the pain will stop :) > > -mel beckman > >> On Jul 4, 2015, at 6:02 PM, Josh Moore wrote: >> >> Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? Many sites and services would still need legacy IPv4 compatibility. Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. My question is this: What, if any, solutions like this exist? If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > From cb.list6 at gmail.com Sun Jul 5 16:57:31 2015 From: cb.list6 at gmail.com (Ca By) Date: Sun, 5 Jul 2015 09:57:31 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <21385FF4-957C-49A0-B0E0-1BCDFD91FF24@puck.nether.net> References: <222712908.245.1436107724025.JavaMail.mhammett@ThunderFuck> <460E3998-CA5C-4264-B3C0-D57ED17420D3@beckman.org> <21385FF4-957C-49A0-B0E0-1BCDFD91FF24@puck.nether.net> Message-ID: On Sunday, July 5, 2015, Jared Mauch wrote: > > > On Jul 5, 2015, at 11:35 AM, Mel Beckman > > wrote: > > > > I guess the WISPs I advise get better advice :) > > I think this is a key item for people to have in mind. We can all follow > poor advice and add in new layers of NATs, possibly including certain > applications within the NAT cone, or we can deliver DS, or DS-like service > via several technologies. > > There are a lot of devices that can do NAT from roll your own Linux or > pfSense style up to commercial solutions that vendors will sell you. (I > recall cisco pitching the ASR1K for this years ago). You could even use > something like LISP to do these redundancy things within your network. > > I would treat NAT the same way people treat CDNs which is find the large > destinations and encourage people to use IPv6 for those. > > Looking at the ?top sites? here: http://www.alexa.com/topsites > > Almost all of them are IPv6 enabled. You can even poke at sites with > external tools like this: > > http://ipv6-test.com/validate.php > > Frank Bulk also monitors most of the major carrier sites for their IPv6 > reliability and stability. He often gets me to contact our IT department > to address the issues they have coping with the traffic volumes involved on > the IPv6 side for the www.us.ntt.net and www.ntt.net sites. (and yes > frank, I got your email and texts yesterday :) ) > > I would say there is no one right/wrong way to do this, but getting the > core of your network IPv6 enabled first then pushing to your edges is a > must-do item for the upcoming quarter or two. > > I was once advised on technical issues where I explained in perfect > technical detail the problems and solution path, but the management started > talking about the optics of the issue. Take advantage of the NBC, etc > coverage to ensure these priorities are taken care of. This may feel like > stooping low to some people, but it?s important to get any IPv6 items off > your todo list. There is a great ipv6-ops list as well out there where > detailed questions can be asked and answered amongst those that are doing > similar things. > > While I dislike what T-Mobile USA has done from a technical side, their > success shows that the IPv6 only edge *is* possible. This means we can > take away the idea that we *must* have IPv4 for a device to be > reachable/considered ?online?. > > I anxiously await the results of the apple/IPv6/iOS9 changeover and the > increased traffic that will occur as a result. I think 2016 will drive the > traffic levels to many multiples where they are now and much closer to > parity on the global backbones. > > - Jared I like the sentiment of what Apple has done. It is a move in the right direction. I don't think apple's move will materially change traffic levels. IPv6 traffic levels will move when when iPhones can be deployed as ipv6-only with parity to ipv4-only. Time will tell. But, it is also telling that android and windows phone are live in the hands of ipv6-only customers and there is no plan for that with Apple. CB From mehmet at akcin.net Sun Jul 5 16:58:49 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 5 Jul 2015 09:58:49 -0700 Subject: Attending NANOG65 question In-Reply-To: References: Message-ID: Looks like registration for this event is not open yet. There is still a lot of time. See you in Montreal Mehmet > On Jul 5, 2015, at 09:45, Andrey Khomyakov wrote: > > Folks, > I'd like to attend NANOG65 (my first NANOG ever), but i can't, for the life > of me, figure out how you register for the event. I can't quite locate the > registration link on nanog.org. > Can someone, please, point me in the right direction? > > Thanks in advance, > > --Andrey From mike.lyon at gmail.com Sun Jul 5 16:59:51 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Sun, 5 Jul 2015 09:59:51 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <2085015272.565.1436113791839.JavaMail.mhammett@ThunderFuck> Message-ID: I dont think my customers would see it that way. They would say, "we'll just go with ATT or Comcast instead." Poof, there goes that MRR! -The other WISP Mike On Jul 5, 2015 9:54 AM, "Mel Beckman" wrote: > Mike, > > They certainly won't like it. But the situation is the same everywhere. > It's not like they're being gouged. > > -mel via cell > > > On Jul 5, 2015, at 9:30 AM, Mike Hammett wrote: > > > > You don't work with end-users much, do you? The same types that follow > Free Press and what not about how their ISP breaks it off in their backside > (despite no concrete evidence - see the recent M-Labs, Free Press > incident)... they won't take too kindly to being told to pay more for IPv4 > to make whatever game work properly. It has to be seamless and it has to be > free. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > > > > > Midwest Internet Exchange > > http://www.midwest-ix.com > > > > > > ----- Original Message ----- > > > > From: "Mel Beckman" > > To: "Josh Moore" > > Cc: nanog at nanog.org > > Sent: Sunday, July 5, 2015 10:52:36 AM > > Subject: Re: Dual stack IPv6 for IPv4 depletion > > > > Dual-stack doesn't require public IPv4 addresses. Since IPv4 is in short > supply, providers must still do what they can to conserve them. This means > NAT, with appropriate management to not overload any one IP, or CGN if you > want to keep public IPv4 (but no longer unique ones) on CPE. Not every > customer needs direct IPv4 connectivity without NAT; those that do must pay > for it. If those who have it aren't willing to pay, they must give up their > public IPv4 address. > > > > That is the most efficient direct IPv4 provisioning concept we have > today. Given the history of IPv6 adoption, it's clear that people won't > move until they experience pain sticking with IPv4. > > > > "On demand" IPv4 isn't currently being done anywhere AFAIK, and since > we're abandoning IPv4 it's not likely anyone has that on their priority > list. It's not a good policy to go out of your way to make IPv4 users > comfortable. IPv4 is going to go away, and the sooner customers get that > and go to IPv6, the sooner the pain will stop :) > > > > -mel beckman > > > >> On Jul 4, 2015, at 6:02 PM, Josh Moore wrote: > >> > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the > CPE. > >> Consider the following: > >> > >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack > with the purpose of allowing their subscriber base to continue to grow > regardless of the depletion of the IPv4 space. Current dual stack best > practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If > this is the case, and BOTH are still required, then how does IPv6 help with > the v4 address depletion crisis? Many sites and services would still need > legacy IPv4 compatibility. Sure, CGN technology may be a solution but what > about applications that need direct IPv4 connectivity without NAT? It seems > that there should be a mechanism to enable on-demand and efficient IPv4 > address consumption ONLY when needed. My question is this: What, if any, > solutions like this exist? If no solution exists then what is the next best > thing? What would the overall IPv6 migration strategy and goal be? > >> > >> Sorry for the length of this email but these are legitimate concerns > and while I understand the need for IPv6 and the importance of getting > there; I don't understand exactly HOW that can be done considering the > immediate issue: IPv4 depletion. > >> > >> > >> Thanks > >> > >> Joshua Moore > >> Network Engineer > >> ATC Broadband > >> 912.632.3161 > > > From owen at delong.com Sun Jul 5 17:26:28 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Jul 2015 10:26:28 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <212314.1436079080@turing-police.cc.vt.edu> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> Message-ID: <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> > On Jul 4, 2015, at 23:51 , Valdis.Kletnieks at vt.edu wrote: > > On 05 Jul 2015 03:41:26 -0000, "John Levine" said: > >> Depends on the application(s). One that seems to work OK is to dual >> stack everyone and put them behind a NAT unless they ask to have a >> private IP. > > Put their IPv4 behind a NAT and a globally routed /56. > > There, FTFY. :) Or better yet globally routed /48. /56 is still a bad idea. Owen From Valdis.Kletnieks at vt.edu Sun Jul 5 17:27:18 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 05 Jul 2015 13:27:18 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Sun, 05 Jul 2015 09:59:51 -0700." References: <2085015272.565.1436113791839.JavaMail.mhammett@ThunderFuck> Message-ID: <254155.1436117238@turing-police.cc.vt.edu> On Sun, 05 Jul 2015 09:59:51 -0700, Mike Lyon said: > I dont think my customers would see it that way. They would say, "we'll > just go with ATT or Comcast instead." Poof, there goes that MRR! Well, that *is* one way to reduce your dependence on IPv4. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From owen at delong.com Sun Jul 5 17:29:21 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Jul 2015 10:29:21 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> Message-ID: <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. Load balancing a single session across multiple NATs isn?t really possible. Owne > On Jul 5, 2015, at 08:11 , Josh Moore wrote: > > Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. > > So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >> >> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >> >> -mel beckman >> >>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>> >>> So the question is: where do you perform the NAT and how can it be redundant? >>> >>> >>> >>> >>> Thanks, >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 >>> >>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>> >>>> Josh, >>>> >>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>> >>>> -mel via cell >>>> >>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>> >>>>> We are the ISP and I have a /32 :) >>>>> >>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Joshua Moore >>>>> Network Engineer >>>>> ATC Broadband >>>>> 912.632.3161 >>>>> >>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>> >>>>>>> >>>>>>> Josh Moore wrote: >>>>>>> >>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>> >>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>> >>>>>> William Waites wrote: >>>>>>> I was helping my >>>>>>> friend who likes Apple things connect to the local community >>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>> >>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>> >>>>>> So you are in a maze of non-twisty paths, all alike :) From nanog at ics-il.net Sun Jul 5 17:43:41 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 5 Jul 2015 12:43:41 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> Message-ID: <1860297447.645.1436118198554.JavaMail.mhammett@ThunderFuck> NAT at the POP seems much more feasible, then. Wherever your chokepoint is in network redundancy, do the NAT there. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Owen DeLong" To: "Josh Moore" Cc: johnl at iecc.com, nanog at nanog.org Sent: Sunday, July 5, 2015 12:29:21 PM Subject: Re: Dual stack IPv6 for IPv4 depletion If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. Load balancing a single session across multiple NATs isn?t really possible. Owne > On Jul 5, 2015, at 08:11 , Josh Moore wrote: > > Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. > > So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >> >> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >> >> -mel beckman >> >>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>> >>> So the question is: where do you perform the NAT and how can it be redundant? >>> >>> >>> >>> >>> Thanks, >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 >>> >>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>> >>>> Josh, >>>> >>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>> >>>> -mel via cell >>>> >>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>> >>>>> We are the ISP and I have a /32 :) >>>>> >>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Joshua Moore >>>>> Network Engineer >>>>> ATC Broadband >>>>> 912.632.3161 >>>>> >>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>> >>>>>>> >>>>>>> Josh Moore wrote: >>>>>>> >>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>> >>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>> >>>>>> William Waites wrote: >>>>>>> I was helping my >>>>>>> friend who likes Apple things connect to the local community >>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>> >>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>> >>>>>> So you are in a maze of non-twisty paths, all alike :) From jmoore at atcnetworks.net Sun Jul 5 18:25:26 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sun, 5 Jul 2015 18:25:26 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net>, <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> Message-ID: <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> So basically what you are telling me is that the NAT gateway needs to be centrally aggregated. Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 > On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: > > If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. > > Load balancing a single session across multiple NATs isn?t really possible. > > Owne > >> On Jul 5, 2015, at 08:11 , Josh Moore wrote: >> >> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. >> >> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >>> >>> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >>> >>> -mel beckman >>> >>>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>>> >>>> So the question is: where do you perform the NAT and how can it be redundant? >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Joshua Moore >>>> Network Engineer >>>> ATC Broadband >>>> 912.632.3161 >>>> >>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>>> >>>>> Josh, >>>>> >>>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>>> >>>>> -mel via cell >>>>> >>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>>> >>>>>> We are the ISP and I have a /32 :) >>>>>> >>>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Joshua Moore >>>>>> Network Engineer >>>>>> ATC Broadband >>>>>> 912.632.3161 >>>>>> >>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>>> >>>>>>>> >>>>>>>> Josh Moore wrote: >>>>>>>> >>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>>> >>>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>>> >>>>>>> William Waites wrote: >>>>>>>> I was helping my >>>>>>>> friend who likes Apple things connect to the local community >>>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>>> >>>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>>> >>>>>>> So you are in a maze of non-twisty paths, all alike :) > From wwaites at tardis.ed.ac.uk Sun Jul 5 18:39:17 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sun, 05 Jul 2015 19:39:17 +0100 (BST) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> References: <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> Message-ID: <20150705.193917.2106593748626683967.wwaites@tardis.ed.ac.uk> On Sun, 5 Jul 2015 18:25:26 +0000, Josh Moore said: > So basically what you are telling me is that the NAT gateway > needs to be centrally aggregated. If you must do NAT it should be as close to the edge as possible. Today that's usually at the CPE. Maybe tomorrow that's one hop upstream at the distribution router. That way the core remains clean and doesn't accumulate state or have to deal with asymmetries. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From owen at delong.com Sun Jul 5 18:46:52 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Jul 2015 11:46:52 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> Message-ID: <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> Not necessarily. But what I am telling you is that whatever goes out NAT gateway A has to come back in through NAT gateway A. You can build whatever topology you want on either side of that and nothing says B has to be any where near A. Owen > On Jul 5, 2015, at 11:25 , Josh Moore wrote: > > So basically what you are telling me is that the NAT gateway needs to be centrally aggregated. > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: >> >> If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. >> >> Load balancing a single session across multiple NATs isn?t really possible. >> >> Owne >> >>> On Jul 5, 2015, at 08:11 , Josh Moore wrote: >>> >>> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. >>> >>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. >>> >>> >>> >>> >>> Thanks, >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 >>> >>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >>>> >>>> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >>>> >>>> -mel beckman >>>> >>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>>>> >>>>> So the question is: where do you perform the NAT and how can it be redundant? >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Joshua Moore >>>>> Network Engineer >>>>> ATC Broadband >>>>> 912.632.3161 >>>>> >>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>>>> >>>>>> Josh, >>>>>> >>>>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>>>> >>>>>> -mel via cell >>>>>> >>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>>>> >>>>>>> We are the ISP and I have a /32 :) >>>>>>> >>>>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Joshua Moore >>>>>>> Network Engineer >>>>>>> ATC Broadband >>>>>>> 912.632.3161 >>>>>>> >>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>>>> >>>>>>>>> >>>>>>>>> Josh Moore wrote: >>>>>>>>> >>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>>>> >>>>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>>>> >>>>>>>> William Waites wrote: >>>>>>>>> I was helping my >>>>>>>>> friend who likes Apple things connect to the local community >>>>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>>>> >>>>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>>>> >>>>>>>> So you are in a maze of non-twisty paths, all alike :) >> From jmoore at atcnetworks.net Sun Jul 5 18:49:22 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sun, 5 Jul 2015 18:49:22 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net>, <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> Message-ID: <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net> The point I am concerned about is a central point of failure. Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 > On Jul 5, 2015, at 2:46 PM, Owen DeLong wrote: > > Not necessarily. But what I am telling you is that whatever goes out NAT gateway A has to come back in through NAT gateway A. > > You can build whatever topology you want on either side of that and nothing says B has to be any where near A. > > Owen > >> On Jul 5, 2015, at 11:25 , Josh Moore wrote: >> >> So basically what you are telling me is that the NAT gateway needs to be centrally aggregated. >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >>> On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: >>> >>> If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. >>> >>> Load balancing a single session across multiple NATs isn?t really possible. >>> >>> Owne >>> >>>> On Jul 5, 2015, at 08:11 , Josh Moore wrote: >>>> >>>> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. >>>> >>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Joshua Moore >>>> Network Engineer >>>> ATC Broadband >>>> 912.632.3161 >>>> >>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >>>>> >>>>> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >>>>> >>>>> -mel beckman >>>>> >>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>>>>> >>>>>> So the question is: where do you perform the NAT and how can it be redundant? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Joshua Moore >>>>>> Network Engineer >>>>>> ATC Broadband >>>>>> 912.632.3161 >>>>>> >>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>>>>> >>>>>>> Josh, >>>>>>> >>>>>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>>>>> >>>>>>> -mel via cell >>>>>>> >>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>>>>> >>>>>>>> We are the ISP and I have a /32 :) >>>>>>>> >>>>>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Joshua Moore >>>>>>>> Network Engineer >>>>>>>> ATC Broadband >>>>>>>> 912.632.3161 >>>>>>>> >>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>>>>> >>>>>>>>>> >>>>>>>>>> Josh Moore wrote: >>>>>>>>>> >>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>>>>> >>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>>>>> >>>>>>>>> William Waites wrote: >>>>>>>>>> I was helping my >>>>>>>>>> friend who likes Apple things connect to the local community >>>>>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>>>>> >>>>>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>>>>> >>>>>>>>> So you are in a maze of non-twisty paths, all alike :) >>> > From owen at delong.com Sun Jul 5 19:09:54 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Jul 2015 12:09:54 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net> Message-ID: <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com> A NAT box is a central point of failure for which the only cure is to not do NAT. You can get clustered NAT boxes (Juniper, for example), but that just makes a bigger central point of failure. Owen > On Jul 5, 2015, at 11:49 , Josh Moore wrote: > > The point I am concerned about is a central point of failure. > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Jul 5, 2015, at 2:46 PM, Owen DeLong wrote: >> >> Not necessarily. But what I am telling you is that whatever goes out NAT gateway A has to come back in through NAT gateway A. >> >> You can build whatever topology you want on either side of that and nothing says B has to be any where near A. >> >> Owen >> >>> On Jul 5, 2015, at 11:25 , Josh Moore wrote: >>> >>> So basically what you are telling me is that the NAT gateway needs to be centrally aggregated. >>> >>> >>> >>> >>> Thanks, >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 >>> >>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: >>>> >>>> If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. >>>> >>>> Load balancing a single session across multiple NATs isn?t really possible. >>>> >>>> Owne >>>> >>>>> On Jul 5, 2015, at 08:11 , Josh Moore wrote: >>>>> >>>>> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. >>>>> >>>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Joshua Moore >>>>> Network Engineer >>>>> ATC Broadband >>>>> 912.632.3161 >>>>> >>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >>>>>> >>>>>> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >>>>>> >>>>>> -mel beckman >>>>>> >>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>>>>>> >>>>>>> So the question is: where do you perform the NAT and how can it be redundant? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Joshua Moore >>>>>>> Network Engineer >>>>>>> ATC Broadband >>>>>>> 912.632.3161 >>>>>>> >>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>>>>>> >>>>>>>> Josh, >>>>>>>> >>>>>>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>>>>>> >>>>>>>> -mel via cell >>>>>>>> >>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>>>>>> >>>>>>>>> We are the ISP and I have a /32 :) >>>>>>>>> >>>>>>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Joshua Moore >>>>>>>>> Network Engineer >>>>>>>>> ATC Broadband >>>>>>>>> 912.632.3161 >>>>>>>>> >>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Josh Moore wrote: >>>>>>>>>>> >>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>>>>>> >>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>>>>>> >>>>>>>>>> William Waites wrote: >>>>>>>>>>> I was helping my >>>>>>>>>>> friend who likes Apple things connect to the local community >>>>>>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>>>>>> >>>>>>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>>>>>> >>>>>>>>>> So you are in a maze of non-twisty paths, all alike :) >>>> >> From baldur.norddahl at gmail.com Sun Jul 5 19:25:26 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 5 Jul 2015 21:25:26 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net> <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com> Message-ID: MAP solves that by splitting NAT into a part that can be done without state (route a port range to a customer) and the actual NAT which is then done on the CPE. It is also the only NAT solution that scales. Regards, Baldur On 5 July 2015 at 21:09, Owen DeLong wrote: > A NAT box is a central point of failure for which the only cure is to not > do NAT. > > You can get clustered NAT boxes (Juniper, for example), but that just > makes a bigger central point of failure. > > Owen > > > On Jul 5, 2015, at 11:49 , Josh Moore wrote: > > > > The point I am concerned about is a central point of failure. > > > > > > > > > > Thanks, > > > > Joshua Moore > > Network Engineer > > ATC Broadband > > 912.632.3161 > > > >> On Jul 5, 2015, at 2:46 PM, Owen DeLong wrote: > >> > >> Not necessarily. But what I am telling you is that whatever goes out > NAT gateway A has to come back in through NAT gateway A. > >> > >> You can build whatever topology you want on either side of that and > nothing says B has to be any where near A. > >> > >> Owen > >> > >>> On Jul 5, 2015, at 11:25 , Josh Moore wrote: > >>> > >>> So basically what you are telling me is that the NAT gateway needs to > be centrally aggregated. > >>> > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Joshua Moore > >>> Network Engineer > >>> ATC Broadband > >>> 912.632.3161 > >>> > >>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: > >>>> > >>>> If you want to keep that, then you?ll need a public backbone network > that joins all of your NATs and you?ll need to have your NATs use unique > exterior address pools. > >>>> > >>>> Load balancing a single session across multiple NATs isn?t really > possible. > >>>> > >>>> Owne > >>>> > >>>>> On Jul 5, 2015, at 08:11 , Josh Moore > wrote: > >>>>> > >>>>> Performing the NAT on the border routers is not a problem. The > problem comes into play where the connectivity is not symmetric. Multiple > entry/exit points to the Internet and some are load balanced. We'd like to > keep that architecture too as it allows for very good protection in an > internet link failure scenario and provides BGP best path connectivity. > >>>>> > >>>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP > A may come in ISP B simultaneously. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Joshua Moore > >>>>> Network Engineer > >>>>> ATC Broadband > >>>>> 912.632.3161 > >>>>> > >>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: > >>>>>> > >>>>>> WISPs have been good at solving this, as they are often deploying > greenfield networks. They use private IPv4 internally and NAT IPv4 at > multiple exit points. IPv6 is seamlessly redundant, since customers all > receive global /64s; BGP handles failover. If you home multiple upstream > providers on a single NAT gateway hardware stack, redundancy is also > seamless, since your NAT tables are synced across redundant stack members. > If you have separate stacks, or even sites, IPv4 can fail over to an > alternate NAT Border gateway but will lose session contexts, unless you go > to the trouble of syncing the gateways. Most WISPs don't. > >>>>>> > >>>>>> -mel beckman > >>>>>> > >>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore > wrote: > >>>>>>> > >>>>>>> So the question is: where do you perform the NAT and how can it be > redundant? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Joshua Moore > >>>>>>> Network Engineer > >>>>>>> ATC Broadband > >>>>>>> 912.632.3161 > >>>>>>> > >>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: > >>>>>>>> > >>>>>>>> Josh, > >>>>>>>> > >>>>>>>> Your job is simple, then. Deliver dual-stack to your customers > and if they want IPv6 they need only get an IPv6-enabled firewall. Unless > you're also an IT consultant to your customers, your job is done. If you > already supply the CPE firewall, then you need only turn on IPv6 for > customers who request it. With the right kind of CPE, you can run MPLS or > EoIP and deliver public IPv4 /32s to customers willing to pay for them. > Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. > >>>>>>>> > >>>>>>>> -mel via cell > >>>>>>>> > >>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore > wrote: > >>>>>>>>> > >>>>>>>>> We are the ISP and I have a /32 :) > >>>>>>>>> > >>>>>>>>> I'm simply looking at the best strategy for migrating my > subscribers off v4 from the perspective of solving the address utilization > crisis while still providing compatibility for those one-off sites and > services that are still on v4. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> Joshua Moore > >>>>>>>>> Network Engineer > >>>>>>>>> ATC Broadband > >>>>>>>>> 912.632.3161 > >>>>>>>>> > >>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Josh Moore wrote: > >>>>>>>>>>> > >>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as > they do not give the benefit of true end to end IPv6 connectivity in the > sense of every device has a one to one global address mapping. > >>>>>>>>>> > >>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping > for every device. From a testing perspective, a tunnelbroker works just as > if you had a second IPv6-only ISP. If you're fortunate enough to have a > dual-stack ISP already, you can forgo tunneling altogether and just use an > IPv6-capable border firewall. > >>>>>>>>>> > >>>>>>>>>> William Waites wrote: > >>>>>>>>>>> I was helping my > >>>>>>>>>>> friend who likes Apple things connect to the local community > >>>>>>>>>>> network. He wanted to use an Airport as his home gateway > rather than > >>>>>>>>>>> the router that we normally use. Turns out these things can > *only* do > >>>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So > there is > >>>>>>>>>>> not exactly a clear path to native IPv6 for your lab this way. > >>>>>>>>>> > >>>>>>>>>> Nobody is recommending the Apple router as a border firewall. > It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If > your ISP can't deliver IPv6, tunneling is the clear path to building a lab. > If you have a dual-stack ISP already, the clear path is to use an > IPv6-capable border firewall. > >>>>>>>>>> > >>>>>>>>>> So you are in a maze of non-twisty paths, all alike :) > >>>> > >> > > From jmoore at atcnetworks.net Sun Jul 5 19:37:48 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sun, 5 Jul 2015 19:37:48 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net>, <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com> Message-ID: I was hoping to find a solution that maybe utilized some kind of session sync or something of that matter allowing for multiple entry and exit points (asymmetric routing). Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 > On Jul 5, 2015, at 3:10 PM, Owen DeLong wrote: > > A NAT box is a central point of failure for which the only cure is to not do NAT. > > You can get clustered NAT boxes (Juniper, for example), but that just makes a bigger central point of failure. > > Owen > >> On Jul 5, 2015, at 11:49 , Josh Moore wrote: >> >> The point I am concerned about is a central point of failure. >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >>> On Jul 5, 2015, at 2:46 PM, Owen DeLong wrote: >>> >>> Not necessarily. But what I am telling you is that whatever goes out NAT gateway A has to come back in through NAT gateway A. >>> >>> You can build whatever topology you want on either side of that and nothing says B has to be any where near A. >>> >>> Owen >>> >>>> On Jul 5, 2015, at 11:25 , Josh Moore wrote: >>>> >>>> So basically what you are telling me is that the NAT gateway needs to be centrally aggregated. >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Joshua Moore >>>> Network Engineer >>>> ATC Broadband >>>> 912.632.3161 >>>> >>>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: >>>>> >>>>> If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. >>>>> >>>>> Load balancing a single session across multiple NATs isn?t really possible. >>>>> >>>>> Owne >>>>> >>>>>> On Jul 5, 2015, at 08:11 , Josh Moore wrote: >>>>>> >>>>>> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. >>>>>> >>>>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Joshua Moore >>>>>> Network Engineer >>>>>> ATC Broadband >>>>>> 912.632.3161 >>>>>> >>>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >>>>>>> >>>>>>> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >>>>>>> >>>>>>> -mel beckman >>>>>>> >>>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>>>>>>> >>>>>>>> So the question is: where do you perform the NAT and how can it be redundant? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Joshua Moore >>>>>>>> Network Engineer >>>>>>>> ATC Broadband >>>>>>>> 912.632.3161 >>>>>>>> >>>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>>>>>>> >>>>>>>>> Josh, >>>>>>>>> >>>>>>>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>>>>>>> >>>>>>>>> -mel via cell >>>>>>>>> >>>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>>>>>>> >>>>>>>>>> We are the ISP and I have a /32 :) >>>>>>>>>> >>>>>>>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Joshua Moore >>>>>>>>>> Network Engineer >>>>>>>>>> ATC Broadband >>>>>>>>>> 912.632.3161 >>>>>>>>>> >>>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Josh Moore wrote: >>>>>>>>>>>> >>>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>>>>>>> >>>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>>>>>>> >>>>>>>>>>> William Waites wrote: >>>>>>>>>>>> I was helping my >>>>>>>>>>>> friend who likes Apple things connect to the local community >>>>>>>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>>>>>>> >>>>>>>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>>>>>>> >>>>>>>>>>> So you are in a maze of non-twisty paths, all alike :) > From mel at beckman.org Sun Jul 5 19:51:12 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 19:51:12 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net>, <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com> Message-ID: I always say that eliminating a single point of failure depends on how big the point is :) -mel beckman > On Jul 5, 2015, at 12:10 PM, Owen DeLong wrote: > > A NAT box is a central point of failure for which the only cure is to not do NAT. > > You can get clustered NAT boxes (Juniper, for example), but that just makes a bigger central point of failure. > > Owen > >> On Jul 5, 2015, at 11:49 , Josh Moore wrote: >> >> The point I am concerned about is a central point of failure. >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >>> On Jul 5, 2015, at 2:46 PM, Owen DeLong wrote: >>> >>> Not necessarily. But what I am telling you is that whatever goes out NAT gateway A has to come back in through NAT gateway A. >>> >>> You can build whatever topology you want on either side of that and nothing says B has to be any where near A. >>> >>> Owen >>> >>>> On Jul 5, 2015, at 11:25 , Josh Moore wrote: >>>> >>>> So basically what you are telling me is that the NAT gateway needs to be centrally aggregated. >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Joshua Moore >>>> Network Engineer >>>> ATC Broadband >>>> 912.632.3161 >>>> >>>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: >>>>> >>>>> If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. >>>>> >>>>> Load balancing a single session across multiple NATs isn?t really possible. >>>>> >>>>> Owne >>>>> >>>>>> On Jul 5, 2015, at 08:11 , Josh Moore wrote: >>>>>> >>>>>> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. >>>>>> >>>>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Joshua Moore >>>>>> Network Engineer >>>>>> ATC Broadband >>>>>> 912.632.3161 >>>>>> >>>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >>>>>>> >>>>>>> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >>>>>>> >>>>>>> -mel beckman >>>>>>> >>>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>>>>>>> >>>>>>>> So the question is: where do you perform the NAT and how can it be redundant? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Joshua Moore >>>>>>>> Network Engineer >>>>>>>> ATC Broadband >>>>>>>> 912.632.3161 >>>>>>>> >>>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>>>>>>> >>>>>>>>> Josh, >>>>>>>>> >>>>>>>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>>>>>>> >>>>>>>>> -mel via cell >>>>>>>>> >>>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>>>>>>> >>>>>>>>>> We are the ISP and I have a /32 :) >>>>>>>>>> >>>>>>>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Joshua Moore >>>>>>>>>> Network Engineer >>>>>>>>>> ATC Broadband >>>>>>>>>> 912.632.3161 >>>>>>>>>> >>>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Josh Moore wrote: >>>>>>>>>>>> >>>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>>>>>>> >>>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>>>>>>> >>>>>>>>>>> William Waites wrote: >>>>>>>>>>>> I was helping my >>>>>>>>>>>> friend who likes Apple things connect to the local community >>>>>>>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>>>>>>> >>>>>>>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>>>>>>> >>>>>>>>>>> So you are in a maze of non-twisty paths, all alike :) >>>>> >>> > From cb.list6 at gmail.com Sun Jul 5 19:55:05 2015 From: cb.list6 at gmail.com (Ca By) Date: Sun, 5 Jul 2015 12:55:05 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net> <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com> Message-ID: On Sunday, July 5, 2015, Baldur Norddahl wrote: > MAP solves that by splitting NAT into a part that can be done without state > (route a port range to a customer) and the actual NAT which is then done on > the CPE. > > But you need special cpe, not sure that is in the op biz case > It is also the only NAT solution that scales. > > Yet, there is no real world scaled deployment of it.... I'd be careful about making broad statements at what scales for a given set of constraints. CB > Regards, > > Baldur > > > On 5 July 2015 at 21:09, Owen DeLong > > wrote: > > > A NAT box is a central point of failure for which the only cure is to not > > do NAT. > > > > You can get clustered NAT boxes (Juniper, for example), but that just > > makes a bigger central point of failure. > > > > Owen > > > > > On Jul 5, 2015, at 11:49 , Josh Moore > wrote: > > > > > > The point I am concerned about is a central point of failure. > > > > > > > > > > > > > > > Thanks, > > > > > > Joshua Moore > > > Network Engineer > > > ATC Broadband > > > 912.632.3161 > > > > > >> On Jul 5, 2015, at 2:46 PM, Owen DeLong > wrote: > > >> > > >> Not necessarily. But what I am telling you is that whatever goes out > > NAT gateway A has to come back in through NAT gateway A. > > >> > > >> You can build whatever topology you want on either side of that and > > nothing says B has to be any where near A. > > >> > > >> Owen > > >> > > >>> On Jul 5, 2015, at 11:25 , Josh Moore > wrote: > > >>> > > >>> So basically what you are telling me is that the NAT gateway needs to > > be centrally aggregated. > > >>> > > >>> > > >>> > > >>> > > >>> Thanks, > > >>> > > >>> Joshua Moore > > >>> Network Engineer > > >>> ATC Broadband > > >>> 912.632.3161 > > >>> > > >>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong > wrote: > > >>>> > > >>>> If you want to keep that, then you?ll need a public backbone network > > that joins all of your NATs and you?ll need to have your NATs use unique > > exterior address pools. > > >>>> > > >>>> Load balancing a single session across multiple NATs isn?t really > > possible. > > >>>> > > >>>> Owne > > >>>> > > >>>>> On Jul 5, 2015, at 08:11 , Josh Moore > > > wrote: > > >>>>> > > >>>>> Performing the NAT on the border routers is not a problem. The > > problem comes into play where the connectivity is not symmetric. Multiple > > entry/exit points to the Internet and some are load balanced. We'd like > to > > keep that architecture too as it allows for very good protection in an > > internet link failure scenario and provides BGP best path connectivity. > > >>>>> > > >>>>> So traffic cones in ISP A might leave ISP B or traffic coming in > ISP > > A may come in ISP B simultaneously. > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Thanks, > > >>>>> > > >>>>> Joshua Moore > > >>>>> Network Engineer > > >>>>> ATC Broadband > > >>>>> 912.632.3161 > > >>>>> > > >>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman > wrote: > > >>>>>> > > >>>>>> WISPs have been good at solving this, as they are often deploying > > greenfield networks. They use private IPv4 internally and NAT IPv4 at > > multiple exit points. IPv6 is seamlessly redundant, since customers all > > receive global /64s; BGP handles failover. If you home multiple upstream > > providers on a single NAT gateway hardware stack, redundancy is also > > seamless, since your NAT tables are synced across redundant stack > members. > > If you have separate stacks, or even sites, IPv4 can fail over to an > > alternate NAT Border gateway but will lose session contexts, unless you > go > > to the trouble of syncing the gateways. Most WISPs don't. > > >>>>>> > > >>>>>> -mel beckman > > >>>>>> > > >>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore > > > wrote: > > >>>>>>> > > >>>>>>> So the question is: where do you perform the NAT and how can it > be > > redundant? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> > > >>>>>>> Joshua Moore > > >>>>>>> Network Engineer > > >>>>>>> ATC Broadband > > >>>>>>> 912.632.3161 > > >>>>>>> > > >>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman > wrote: > > >>>>>>>> > > >>>>>>>> Josh, > > >>>>>>>> > > >>>>>>>> Your job is simple, then. Deliver dual-stack to your customers > > and if they want IPv6 they need only get an IPv6-enabled firewall. Unless > > you're also an IT consultant to your customers, your job is done. If you > > already supply the CPE firewall, then you need only turn on IPv6 for > > customers who request it. With the right kind of CPE, you can run MPLS or > > EoIP and deliver public IPv4 /32s to customers willing to pay for them. > > Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. > > >>>>>>>> > > >>>>>>>> -mel via cell > > >>>>>>>> > > >>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore > > > wrote: > > >>>>>>>>> > > >>>>>>>>> We are the ISP and I have a /32 :) > > >>>>>>>>> > > >>>>>>>>> I'm simply looking at the best strategy for migrating my > > subscribers off v4 from the perspective of solving the address > utilization > > crisis while still providing compatibility for those one-off sites and > > services that are still on v4. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Thanks, > > >>>>>>>>> > > >>>>>>>>> Joshua Moore > > >>>>>>>>> Network Engineer > > >>>>>>>>> ATC Broadband > > >>>>>>>>> 912.632.3161 > > >>>>>>>>> > > >>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman > wrote: > > >>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Josh Moore wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as > > they do not give the benefit of true end to end IPv6 connectivity in the > > sense of every device has a one to one global address mapping. > > >>>>>>>>>> > > >>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping > > for every device. From a testing perspective, a tunnelbroker works just > as > > if you had a second IPv6-only ISP. If you're fortunate enough to have a > > dual-stack ISP already, you can forgo tunneling altogether and just use > an > > IPv6-capable border firewall. > > >>>>>>>>>> > > >>>>>>>>>> William Waites wrote: > > >>>>>>>>>>> I was helping my > > >>>>>>>>>>> friend who likes Apple things connect to the local community > > >>>>>>>>>>> network. He wanted to use an Airport as his home gateway > > rather than > > >>>>>>>>>>> the router that we normally use. Turns out these things can > > *only* do > > >>>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So > > there is > > >>>>>>>>>>> not exactly a clear path to native IPv6 for your lab this > way. > > >>>>>>>>>> > > >>>>>>>>>> Nobody is recommending the Apple router as a border firewall. > > It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If > > your ISP can't deliver IPv6, tunneling is the clear path to building a > lab. > > If you have a dual-stack ISP already, the clear path is to use an > > IPv6-capable border firewall. > > >>>>>>>>>> > > >>>>>>>>>> So you are in a maze of non-twisty paths, all alike :) > > >>>> > > >> > > > > > From mel at beckman.org Sun Jul 5 19:55:17 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 19:55:17 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net>, <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com>, Message-ID: <96DBE341-4C88-4139-AA4E-01117340EE45@beckman.org> Many firewalls will do state sync across an HA link. This works fine as long as you use BGP to ensure internet routing of your IPv4 to all gateways. But then the HA link is the single point of failure. I think the best you can hope for is that the importance of IPv4 NAT will diminish over time. One day it will be just a memory, like SNA :) -mel beckman > On Jul 5, 2015, at 12:37 PM, Josh Moore wrote: > > I was hoping to find a solution that maybe utilized some kind of session sync or something of that matter allowing for multiple entry and exit points (asymmetric routing). > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Jul 5, 2015, at 3:10 PM, Owen DeLong wrote: >> >> A NAT box is a central point of failure for which the only cure is to not do NAT. >> >> You can get clustered NAT boxes (Juniper, for example), but that just makes a bigger central point of failure. >> >> Owen >> >>> On Jul 5, 2015, at 11:49 , Josh Moore wrote: >>> >>> The point I am concerned about is a central point of failure. >>> >>> >>> >>> >>> Thanks, >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 >>> >>>> On Jul 5, 2015, at 2:46 PM, Owen DeLong wrote: >>>> >>>> Not necessarily. But what I am telling you is that whatever goes out NAT gateway A has to come back in through NAT gateway A. >>>> >>>> You can build whatever topology you want on either side of that and nothing says B has to be any where near A. >>>> >>>> Owen >>>> >>>>> On Jul 5, 2015, at 11:25 , Josh Moore wrote: >>>>> >>>>> So basically what you are telling me is that the NAT gateway needs to be centrally aggregated. >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Joshua Moore >>>>> Network Engineer >>>>> ATC Broadband >>>>> 912.632.3161 >>>>> >>>>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: >>>>>> >>>>>> If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. >>>>>> >>>>>> Load balancing a single session across multiple NATs isn?t really possible. >>>>>> >>>>>> Owne >>>>>> >>>>>>> On Jul 5, 2015, at 08:11 , Josh Moore wrote: >>>>>>> >>>>>>> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. >>>>>>> >>>>>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Joshua Moore >>>>>>> Network Engineer >>>>>>> ATC Broadband >>>>>>> 912.632.3161 >>>>>>> >>>>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >>>>>>>> >>>>>>>> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >>>>>>>> >>>>>>>> -mel beckman >>>>>>>> >>>>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>>>>>>>> >>>>>>>>> So the question is: where do you perform the NAT and how can it be redundant? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Joshua Moore >>>>>>>>> Network Engineer >>>>>>>>> ATC Broadband >>>>>>>>> 912.632.3161 >>>>>>>>> >>>>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>>>>>>>> >>>>>>>>>> Josh, >>>>>>>>>> >>>>>>>>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>>>>>>>> >>>>>>>>>> -mel via cell >>>>>>>>>> >>>>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>>>>>>>> >>>>>>>>>>> We are the ISP and I have a /32 :) >>>>>>>>>>> >>>>>>>>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Joshua Moore >>>>>>>>>>> Network Engineer >>>>>>>>>>> ATC Broadband >>>>>>>>>>> 912.632.3161 >>>>>>>>>>> >>>>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Josh Moore wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>>>>>>>> >>>>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>>>>>>>> >>>>>>>>>>>> William Waites wrote: >>>>>>>>>>>>> I was helping my >>>>>>>>>>>>> friend who likes Apple things connect to the local community >>>>>>>>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>>>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>>>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>>>>>>>> >>>>>>>>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>>>>>>>> >>>>>>>>>>>> So you are in a maze of non-twisty paths, all alike :) >> From admin at coldnorthadmin.com Sun Jul 5 20:01:42 2015 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Sun, 05 Jul 2015 16:01:42 -0400 Subject: Attending NANOG65 question In-Reply-To: References: Message-ID: <55998D26.2010802@coldnorthadmin.com> I can confirm that. I had a few questions about attending NANOG65 as a student (also my first!) and they are still working on the registration process for this year On 7/5/2015 12:58 PM, Mehmet Akcin wrote: > Looks like registration for this event is not open yet. There is still a lot of time. See you in Montreal > > Mehmet > >> On Jul 5, 2015, at 09:45, Andrey Khomyakov wrote: >> >> Folks, >> I'd like to attend NANOG65 (my first NANOG ever), but i can't, for the life >> of me, figure out how you register for the event. I can't quite locate the >> registration link on nanog.org. >> Can someone, please, point me in the right direction? >> >> Thanks in advance, >> >> --Andrey From jmoore at atcnetworks.net Sun Jul 5 20:17:22 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Sun, 5 Jul 2015 20:17:22 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <96DBE341-4C88-4139-AA4E-01117340EE45@beckman.org> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net>, <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com>, , <96DBE341-4C88-4139-AA4E-01117340EE45@beckman.org> Message-ID: <2EEBB463-23FA-443C-9DD2-C35716B62AD4@atcnetworks.net> Theoretically it should be possible with this on MPLS enabled devices. The "HA link" could then ride on top of the MPLS core redundancy alongside public outside NAT traffic and inside private traffic. The good thing is that most of my customer access (DSL, cable, T1) is designed with established distribution points. Implementing sectional CGN at those points would be a good first step. We need to just get the policy side of things worked out on how we are going to automate the provisioning internally. Thanks for all the input. Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 > On Jul 5, 2015, at 3:55 PM, Mel Beckman wrote: > > Many firewalls will do state sync across an HA link. This works fine as long as you use BGP to ensure internet routing of your IPv4 to all gateways. But then the HA link is the single point of failure. I think the best you can hope for is that the importance of IPv4 NAT will diminish over time. One day it will be just a memory, like SNA :) > > -mel beckman > >> On Jul 5, 2015, at 12:37 PM, Josh Moore wrote: >> >> I was hoping to find a solution that maybe utilized some kind of session sync or something of that matter allowing for multiple entry and exit points (asymmetric routing). >> >> >> >> >> Thanks, >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 >> >>> On Jul 5, 2015, at 3:10 PM, Owen DeLong wrote: >>> >>> A NAT box is a central point of failure for which the only cure is to not do NAT. >>> >>> You can get clustered NAT boxes (Juniper, for example), but that just makes a bigger central point of failure. >>> >>> Owen >>> >>>> On Jul 5, 2015, at 11:49 , Josh Moore wrote: >>>> >>>> The point I am concerned about is a central point of failure. >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Joshua Moore >>>> Network Engineer >>>> ATC Broadband >>>> 912.632.3161 >>>> >>>>> On Jul 5, 2015, at 2:46 PM, Owen DeLong wrote: >>>>> >>>>> Not necessarily. But what I am telling you is that whatever goes out NAT gateway A has to come back in through NAT gateway A. >>>>> >>>>> You can build whatever topology you want on either side of that and nothing says B has to be any where near A. >>>>> >>>>> Owen >>>>> >>>>>> On Jul 5, 2015, at 11:25 , Josh Moore wrote: >>>>>> >>>>>> So basically what you are telling me is that the NAT gateway needs to be centrally aggregated. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Joshua Moore >>>>>> Network Engineer >>>>>> ATC Broadband >>>>>> 912.632.3161 >>>>>> >>>>>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: >>>>>>> >>>>>>> If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. >>>>>>> >>>>>>> Load balancing a single session across multiple NATs isn?t really possible. >>>>>>> >>>>>>> Owne >>>>>>> >>>>>>>> On Jul 5, 2015, at 08:11 , Josh Moore wrote: >>>>>>>> >>>>>>>> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. >>>>>>>> >>>>>>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Joshua Moore >>>>>>>> Network Engineer >>>>>>>> ATC Broadband >>>>>>>> 912.632.3161 >>>>>>>> >>>>>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >>>>>>>>> >>>>>>>>> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >>>>>>>>> >>>>>>>>> -mel beckman >>>>>>>>> >>>>>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>>>>>>>>> >>>>>>>>>> So the question is: where do you perform the NAT and how can it be redundant? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Joshua Moore >>>>>>>>>> Network Engineer >>>>>>>>>> ATC Broadband >>>>>>>>>> 912.632.3161 >>>>>>>>>> >>>>>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>>>>>>>>> >>>>>>>>>>> Josh, >>>>>>>>>>> >>>>>>>>>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>>>>>>>>> >>>>>>>>>>> -mel via cell >>>>>>>>>>> >>>>>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>>>>>>>>> >>>>>>>>>>>> We are the ISP and I have a /32 :) >>>>>>>>>>>> >>>>>>>>>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Joshua Moore >>>>>>>>>>>> Network Engineer >>>>>>>>>>>> ATC Broadband >>>>>>>>>>>> 912.632.3161 >>>>>>>>>>>> >>>>>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Josh Moore wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>>>>>>>>> >>>>>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>>>>>>>>> >>>>>>>>>>>>> William Waites wrote: >>>>>>>>>>>>>> I was helping my >>>>>>>>>>>>>> friend who likes Apple things connect to the local community >>>>>>>>>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>>>>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>>>>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>>>>>>>>> >>>>>>>>>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>>>>>>>>> >>>>>>>>>>>>> So you are in a maze of non-twisty paths, all alike :) >>> From randy at psg.com Sun Jul 5 20:22:06 2015 From: randy at psg.com (Randy Bush) Date: Mon, 06 Jul 2015 05:22:06 +0900 Subject: Attending NANOG65 question In-Reply-To: <55998D26.2010802@coldnorthadmin.com> References: <55998D26.2010802@coldnorthadmin.com> Message-ID: folk needing complex or difficult visas need long lead time. and they tend to need the registration and letter of invitation. in this case, canada is not all that much easier to get in to than the states. ietf is also working on improving this issue. randy From jared at puck.nether.net Sun Jul 5 20:59:16 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 5 Jul 2015 16:59:16 -0400 Subject: Attending NANOG65 question In-Reply-To: References: <55998D26.2010802@coldnorthadmin.com> Message-ID: <95D1DED6-6990-4914-8981-3A7D543E6136@puck.nether.net> > On Jul 5, 2015, at 4:22 PM, Randy Bush wrote: > > folk needing complex or difficult visas need long lead time. and they > tend to need the registration and letter of invitation. in this case, > canada is not all that much easier to get in to than the states. ietf > is also working on improving this issue. > > randy One of my frustrations with the NANOG website is it?s very PC oriented in how to navigate around it. The links are small and sometimes a bit obtuse, much like the posters on the list. There?s generally not a big ?register here? link, nor is the agenda featured prominently during the conference on the page. OTOH, RIPE seems to have this done well. I visit the site, it shows me the agenda for $today() and the outcome is easy to interpret regardless of the device in-use. I can still (attempt to) register for NANOG64 if you navigate to the right part of the site, but there?s no clear ?Registration will be open X? date. There seems to be no reason why I couldn?t pay now for the meeting, unless the transition from AMSL is still ongoing. - Jared From feldman at twincreeks.net Sun Jul 5 21:12:26 2015 From: feldman at twincreeks.net (Steve Feldman) Date: Sun, 5 Jul 2015 14:12:26 -0700 Subject: Attending NANOG65 question In-Reply-To: <95D1DED6-6990-4914-8981-3A7D543E6136@puck.nether.net> References: <55998D26.2010802@coldnorthadmin.com> <95D1DED6-6990-4914-8981-3A7D543E6136@puck.nether.net> Message-ID: <0F7DD65B-4189-4D1E-B024-FB36850BD54E@twincreeks.net> > On Jul 5, 2015, at 1:59 PM, Jared Mauch wrote: > ... > There seems to be no reason why I couldn?t pay now for the meeting, unless the transition from AMSL is still ongoing. And that is indeed the case. They are using a new registration system vendor this time, and the integration is taking a bit longer than planned. From what I've seen though, it will be a marked improvement over the previous system for both attendees and NANOG staff. I'm sure there will be an official announcement when registration is open. Steve From matthew at matthew.at Sun Jul 5 23:23:46 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 05 Jul 2015 16:23:46 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> References: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> Message-ID: <5599BC82.1070403@matthew.at> On 7/4/2015 5:09 AM, Josh Moore wrote: > Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE. > Consider the following: > > An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. Admirable goal. > Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. That's what "dual stack" means, yes. > If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? Well, you dual-stacked your subscribers about 5-8 years ago, and about 3-5 years ago we're basically done moving all content they might wish to access to IPv6 as well. So about a year ago, you've been able to offer an IPv6-only product that actually works just fine... and you charge extra for IPv4 (which most people don't want/need at this point) > Many sites and services would still need legacy IPv4 compatibility. Well,... because you and every other ISP dual-stacked over 5 years ago, and the transition is just about done, I wouldn't call it "many" at this point. > Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? By now, there aren't any such applications in wide use. A few legacy things that couldn't be updated, sure, and for those you can still offer IPv4 addresses and access to the few people willing to pay extra for that. > It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. That's not needed, because with everyone on IPv6, there's more than enough IPv4 space available for you... and if you need to buy some, it is almost worthless, so the prices are near zero. > My question is this: What, if any, solutions like this exist? Nobody bothered to build sharing strategies because it was clear that it wouldn't be needed as IPv6 deployment ramped up over the last decade. > If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be? Just continue the dual-stack approach for those who need it, as you've been doing for 5+ years. For the rest, IPv4 is historic. > > Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion. Fortunately, the recent ARIN announcement is of no real concern, because you and everyone else moved to a nearly 100% IPv6 Internet years ago. Matthew Kaufman From mel at beckman.org Sun Jul 5 23:33:09 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 5 Jul 2015 23:33:09 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <5599BC82.1070403@matthew.at> References: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net>, <5599BC82.1070403@matthew.at> Message-ID: Matthew, You can be part of the solution or part of the sarcasm. -mel via cell > On Jul 5, 2015, at 4:25 PM, Matthew Kaufman wrote: > >> On 7/4/2015 5:09 AM, Josh Moore wrote: >> Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. > > Admirable goal. > >> Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. > > That's what "dual stack" means, yes. > >> If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? > > Well, you dual-stacked your subscribers about 5-8 years ago, and about 3-5 years ago we're basically done moving all content they might wish to access to IPv6 as well. So about a year ago, you've been able to offer an IPv6-only product that actually works just fine... and you charge extra for IPv4 (which most people don't want/need at this point) > >> Many sites and services would still need legacy IPv4 compatibility. > > Well,... because you and every other ISP dual-stacked over 5 years ago, and the transition is just about done, I wouldn't call it "many" at this point. > >> Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? > > By now, there aren't any such applications in wide use. A few legacy things that couldn't be updated, sure, and for those you can still offer IPv4 addresses and access to the few people willing to pay extra for that. > >> It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. > > That's not needed, because with everyone on IPv6, there's more than enough IPv4 space available for you... and if you need to buy some, it is almost worthless, so the prices are near zero. > >> My question is this: What, if any, solutions like this exist? > > Nobody bothered to build sharing strategies because it was clear that it wouldn't be needed as IPv6 deployment ramped up over the last decade. > >> If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be? > > Just continue the dual-stack approach for those who need it, as you've been doing for 5+ years. For the rest, IPv4 is historic. > >> >> Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion. > > Fortunately, the recent ARIN announcement is of no real concern, because you and everyone else moved to a nearly 100% IPv6 Internet years ago. > > Matthew Kaufman > From nellermann at broadaspect.com Mon Jul 6 02:10:41 2015 From: nellermann at broadaspect.com (Nick Ellermann) Date: Mon, 6 Jul 2015 02:10:41 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <96DBE341-4C88-4139-AA4E-01117340EE45@beckman.org> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net>, <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com>, , <96DBE341-4C88-4139-AA4E-01117340EE45@beckman.org> Message-ID: <7A14A481-1948-4E1B-971C-D8A79A9F7A5D@broadaspect.com> For a small site using a Fortigate such as a 60d, you can use equal cost load balancing very well. We use this all the time to keep a customer's backup ISP active with VPN connection back to the data center. I wouldn't want to support VOIP in the config, but works really great for VPNs and general internet access for end users. Nick Ellermann ~Sent from my iPhone~ On Jul 5, 2015, at 2:59 PM, Mel Beckman wrote: Many firewalls will do state sync across an HA link. This works fine as long as you use BGP to ensure internet routing of your IPv4 to all gateways. But then the HA link is the single point of failure. I think the best you can hope for is that the importance of IPv4 NAT will diminish over time. One day it will be just a memory, like SNA :) -mel beckman > On Jul 5, 2015, at 12:37 PM, Josh Moore wrote: > > I was hoping to find a solution that maybe utilized some kind of session sync or something of that matter allowing for multiple entry and exit points (asymmetric routing). > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Jul 5, 2015, at 3:10 PM, Owen DeLong wrote: >> >> A NAT box is a central point of failure for which the only cure is to not do NAT. >> >> You can get clustered NAT boxes (Juniper, for example), but that just makes a bigger central point of failure. >> >> Owen >> >>> On Jul 5, 2015, at 11:49 , Josh Moore wrote: >>> >>> The point I am concerned about is a central point of failure. >>> >>> >>> >>> >>> Thanks, >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 >>> >>>> On Jul 5, 2015, at 2:46 PM, Owen DeLong wrote: >>>> >>>> Not necessarily. But what I am telling you is that whatever goes out NAT gateway A has to come back in through NAT gateway A. >>>> >>>> You can build whatever topology you want on either side of that and nothing says B has to be any where near A. >>>> >>>> Owen >>>> >>>>> On Jul 5, 2015, at 11:25 , Josh Moore wrote: >>>>> >>>>> So basically what you are telling me is that the NAT gateway needs to be centrally aggregated. >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Joshua Moore >>>>> Network Engineer >>>>> ATC Broadband >>>>> 912.632.3161 >>>>> >>>>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong wrote: >>>>>> >>>>>> If you want to keep that, then you?ll need a public backbone network that joins all of your NATs and you?ll need to have your NATs use unique exterior address pools. >>>>>> >>>>>> Load balancing a single session across multiple NATs isn?t really possible. >>>>>> >>>>>> Owne >>>>>> >>>>>>> On Jul 5, 2015, at 08:11 , Josh Moore wrote: >>>>>>> >>>>>>> Performing the NAT on the border routers is not a problem. The problem comes into play where the connectivity is not symmetric. Multiple entry/exit points to the Internet and some are load balanced. We'd like to keep that architecture too as it allows for very good protection in an internet link failure scenario and provides BGP best path connectivity. >>>>>>> >>>>>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may come in ISP B simultaneously. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Joshua Moore >>>>>>> Network Engineer >>>>>>> ATC Broadband >>>>>>> 912.632.3161 >>>>>>> >>>>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman wrote: >>>>>>>> >>>>>>>> WISPs have been good at solving this, as they are often deploying greenfield networks. They use private IPv4 internally and NAT IPv4 at multiple exit points. IPv6 is seamlessly redundant, since customers all receive global /64s; BGP handles failover. If you home multiple upstream providers on a single NAT gateway hardware stack, redundancy is also seamless, since your NAT tables are synced across redundant stack members. If you have separate stacks, or even sites, IPv4 can fail over to an alternate NAT Border gateway but will lose session contexts, unless you go to the trouble of syncing the gateways. Most WISPs don't. >>>>>>>> >>>>>>>> -mel beckman >>>>>>>> >>>>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore wrote: >>>>>>>>> >>>>>>>>> So the question is: where do you perform the NAT and how can it be redundant? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Joshua Moore >>>>>>>>> Network Engineer >>>>>>>>> ATC Broadband >>>>>>>>> 912.632.3161 >>>>>>>>> >>>>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman wrote: >>>>>>>>>> >>>>>>>>>> Josh, >>>>>>>>>> >>>>>>>>>> Your job is simple, then. Deliver dual-stack to your customers and if they want IPv6 they need only get an IPv6-enabled firewall. Unless you're also an IT consultant to your customers, your job is done. If you already supply the CPE firewall, then you need only turn on IPv6 for customers who request it. With the right kind of CPE, you can run MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay for them. Otherwise it's private IPv4 and NAT as usual for IPv4 traffic. >>>>>>>>>> >>>>>>>>>> -mel via cell >>>>>>>>>> >>>>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore wrote: >>>>>>>>>>> >>>>>>>>>>> We are the ISP and I have a /32 :) >>>>>>>>>>> >>>>>>>>>>> I'm simply looking at the best strategy for migrating my subscribers off v4 from the perspective of solving the address utilization crisis while still providing compatibility for those one-off sites and services that are still on v4. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Joshua Moore >>>>>>>>>>> Network Engineer >>>>>>>>>>> ATC Broadband >>>>>>>>>>> 912.632.3161 >>>>>>>>>>> >>>>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman wrote: >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Josh Moore wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. >>>>>>>>>>>> >>>>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping for every device. From a testing perspective, a tunnelbroker works just as if you had a second IPv6-only ISP. If you're fortunate enough to have a dual-stack ISP already, you can forgo tunneling altogether and just use an IPv6-capable border firewall. >>>>>>>>>>>> >>>>>>>>>>>> William Waites wrote: >>>>>>>>>>>>> I was helping my >>>>>>>>>>>>> friend who likes Apple things connect to the local community >>>>>>>>>>>>> network. He wanted to use an Airport as his home gateway rather than >>>>>>>>>>>>> the router that we normally use. Turns out these things can *only* do >>>>>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >>>>>>>>>>>>> not exactly a clear path to native IPv6 for your lab this way. >>>>>>>>>>>> >>>>>>>>>>>> Nobody is recommending the Apple router as a border firewall. It's terrible for that. But it's a ready-to-go tunnelbroker gateway. If your ISP can't deliver IPv6, tunneling is the clear path to building a lab. If you have a dual-stack ISP already, the clear path is to use an IPv6-capable border firewall. >>>>>>>>>>>> >>>>>>>>>>>> So you are in a maze of non-twisty paths, all alike :) >> From sander at steffann.nl Mon Jul 6 12:50:46 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 6 Jul 2015 14:50:46 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> <5C7F49B5-B5D8-4F50-9B22-A5590253BFE3@atcnetworks.net> <2FF7B7F3-9AE0-4809-9C86-A0055CD304B9@atcnetworks.net> <90D7F766-0A66-47F0-885A-848D6159A53B@atcnetworks.net> <6952A7F8-7899-4626-9097-9869E5E0BA62@delong.com> <9D9406E1-1C9B-4D1F-A211-583412E520FF@atcnetworks.net> <338311C0-7CDF-42C6-8FAF-B67F26134F7F@delong.com> <7E87953A-C6B4-40F0-A723-9E9E21DC9B80@atcnetworks.net> <152FF1D8-3CA7-41F0-A8E7-0AC57D28B710@delong.com> Message-ID: <062FE7ED-FCE7-4FCA-8EF1-8AD9AF223CAA@steffann.nl> Hi, > I was hoping to find a solution that maybe utilized some kind of session sync or something of that matter [...] And the session sync is then the weakest link. I have seen a cluster of Nexus switches crash in sync when saving the configuration (which was synced). True redundancy is only when the elements can operate independently of each other, and the syncing makes them dependent and vulnerable. Cheers, Sander From Lee at asgard.org Mon Jul 6 13:26:27 2015 From: Lee at asgard.org (Lee Howard) Date: Mon, 06 Jul 2015 09:26:27 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> References: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net> Message-ID: Some thoughts. . . ?Native dual-stack? is ?native IPv4 and native IPv6.? ?Dual-stack? might be native, or might by ?native IPv6 plus IPv4 address sharing.? Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are operational deployments of all three, in the order given. You need them close enough to your customers that traffic will return over the same path. You can?t share state among a cluster of boxes, but that?s not the end of the world; a device failure sometimes causes loss of state. MAP is the hot new thing all the cool kids are doing. Look to your router and load balancer vendors for devices that do these. CGN is the only one that doesn?t require updates to the home gateway. The more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. Think about how you?ll position it to customers. It?s difficult to change a customer?s service mid-contract. At some point, a customer is no longer profitable: if NAT costs and service calls add up, you may be better off buying addresses or losing the customer. You may need to buy some IPv4 addresses to give you time; contact a broker. You may be surprised how hard it is to root IPv4 out of the system. Don?t buy anything you can?t manage over IPv6, including servers and applications. Sorry, vendor, I can?t buy your cluster, I don?t have the IPv4 address space to provision it. Lee On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" wrote: >Traditional dual stack deployments implement both IPv4 and IPv6 to the >CPE. >Consider the following: > >An ISP is at 90% IPv4 utilization and would like to deploy dual stack >with the purpose of allowing their subscriber base to continue to grow >regardless of the depletion of the IPv4 space. Current dual stack best >practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >this is the case, and BOTH are still required, then how does IPv6 help >with the v4 address depletion crisis? Many sites and services would still >need legacy IPv4 compatibility. Sure, CGN technology may be a solution >but what about applications that need direct IPv4 connectivity without >NAT? It seems that there should be a mechanism to enable on-demand and >efficient IPv4 address consumption ONLY when needed. My question is this: >What, if any, solutions like this exist? If no solution exists then what >is the next best thing? What would the overall IPv6 migration strategy >and goal be? > >Sorry for the length of this email but these are legitimate concerns and >while I understand the need for IPv6 and the importance of getting there; >I don't understand exactly HOW that can be done considering the immediate >issue: IPv4 depletion. > > >Thanks > >Joshua Moore >Network Engineer >ATC Broadband >912.632.3161 From mel at beckman.org Mon Jul 6 13:44:18 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 6 Jul 2015 13:44:18 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6CC42ADB-2942-4466-87C9-E246EB08CBE1@atcnetworks.net>, Message-ID: <713042D3-496A-4A2E-9CFD-B8FB9EAD0C74@beckman.org> And let's all complain to the MPLS working group to get IPv6 support finished up! -mel beckman > On Jul 6, 2015, at 6:27 AM, Lee Howard wrote: > > Some thoughts. . . > > ?Native dual-stack? is ?native IPv4 and native IPv6.? > > ?Dual-stack? might be native, or might by ?native IPv6 plus IPv4 address > sharing.? > > Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are > operational deployments of all three, in the order given. You need them > close enough to your customers that traffic will return over the same > path. You can?t share state among a cluster of boxes, but that?s not the > end of the world; a device failure sometimes causes loss of state. MAP is > the hot new thing all the cool kids are doing. > > Look to your router and load balancer vendors for devices that do these. > CGN is the only one that doesn?t require updates to the home gateway. The > more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. > > Think about how you?ll position it to customers. It?s difficult to change > a customer?s service mid-contract. At some point, a customer is no longer > profitable: if NAT costs and service calls add up, you may be better off > buying addresses or losing the customer. You may need to buy some IPv4 > addresses to give you time; contact a broker. > > You may be surprised how hard it is to root IPv4 out of the system. Don?t > buy anything you can?t manage over IPv6, including servers and > applications. Sorry, vendor, I can?t buy your cluster, I don?t have the > IPv4 address space to provision it. > > Lee > > On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" > wrote: > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the >> CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack >> with the purpose of allowing their subscriber base to continue to grow >> regardless of the depletion of the IPv4 space. Current dual stack best >> practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >> this is the case, and BOTH are still required, then how does IPv6 help >> with the v4 address depletion crisis? Many sites and services would still >> need legacy IPv4 compatibility. Sure, CGN technology may be a solution >> but what about applications that need direct IPv4 connectivity without >> NAT? It seems that there should be a mechanism to enable on-demand and >> efficient IPv4 address consumption ONLY when needed. My question is this: >> What, if any, solutions like this exist? If no solution exists then what >> is the next best thing? What would the overall IPv6 migration strategy >> and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and >> while I understand the need for IPv6 and the importance of getting there; >> I don't understand exactly HOW that can be done considering the immediate >> issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > > From mel at beckman.org Mon Jul 6 14:49:20 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 6 Jul 2015 14:49:20 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> Message-ID: <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes. -mel via cell On Jul 6, 2015, at 7:15 AM, andrew > wrote: Pardon my ignorance - what do you see missing in MPLS in regards to support for IP6? -------- Original message -------- From: Mel Beckman > Date: 07/06/2015 9:44 AM (GMT-05:00) To: Lee Howard > Cc: Josh Moore >, nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion And let's all complain to the MPLS working group to get IPv6 support finished up! -mel beckman > On Jul 6, 2015, at 6:27 AM, Lee Howard > wrote: > > Some thoughts. . . > > ^3Native dual-stack^2 is ^3native IPv4 and native IPv6.^2 > > ^3Dual-stack^2 might be native, or might by ^3native IPv6 plus IPv4 address > sharing.^2 > > Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are > operational deployments of all three, in the order given. You need them > close enough to your customers that traffic will return over the same > path. You can^1t share state among a cluster of boxes, but that^1s not the > end of the world; a device failure sometimes causes loss of state. MAP is > the hot new thing all the cool kids are doing. > > Look to your router and load balancer vendors for devices that do these. > CGN is the only one that doesn^1t require updates to the home gateway. The > more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. > > Think about how you^1ll position it to customers. It^1s difficult to change > a customer^1s service mid-contract. At some point, a customer is no longer > profitable: if NAT costs and service calls add up, you may be better off > buying addresses or losing the customer. You may need to buy some IPv4 > addresses to give you time; contact a broker. > > You may be surprised how hard it is to root IPv4 out of the system. Don^1t > buy anything you can^1t manage over IPv6, including servers and > applications. Sorry, vendor, I can^1t buy your cluster, I don^1t have the > IPv4 address space to provision it. > > Lee > > On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" > on behalf of jmoore at atcnetworks.net> wrote: > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the >> CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack >> with the purpose of allowing their subscriber base to continue to grow >> regardless of the depletion of the IPv4 space. Current dual stack best >> practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >> this is the case, and BOTH are still required, then how does IPv6 help >> with the v4 address depletion crisis? Many sites and services would still >> need legacy IPv4 compatibility. Sure, CGN technology may be a solution >> but what about applications that need direct IPv4 connectivity without >> NAT? It seems that there should be a mechanism to enable on-demand and >> efficient IPv4 address consumption ONLY when needed. My question is this: >> What, if any, solutions like this exist? If no solution exists then what >> is the next best thing? What would the overall IPv6 migration strategy >> and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and >> while I understand the need for IPv6 and the importance of getting there; >> I don't understand exactly HOW that can be done considering the immediate >> issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > > From jmoore at atcnetworks.net Mon Jul 6 15:41:19 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Mon, 6 Jul 2015 15:41:19 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> Message-ID: You can still carry the v6 NLRIs in MP-BGP though right? Joshua Moore Network Engineer ATC Broadband 912.632.3161 - O | 912.218.3720 - M From: Mel Beckman [mailto:mel at beckman.org] Sent: Monday, July 06, 2015 10:49 AM To: andrew Cc: Lee Howard; Josh Moore; nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes. -mel via cell On Jul 6, 2015, at 7:15 AM, andrew > wrote: Pardon my ignorance - what do you see missing in MPLS in regards to support for IP6? -------- Original message -------- From: Mel Beckman > Date: 07/06/2015 9:44 AM (GMT-05:00) To: Lee Howard > Cc: Josh Moore >, nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion And let's all complain to the MPLS working group to get IPv6 support finished up! -mel beckman > On Jul 6, 2015, at 6:27 AM, Lee Howard > wrote: > > Some thoughts. . . > > ?Native dual-stack? is ?native IPv4 and native IPv6.? > > ?Dual-stack? might be native, or might by ?native IPv6 plus IPv4 address > sharing.? > > Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are > operational deployments of all three, in the order given. You need them > close enough to your customers that traffic will return over the same > path. You can?t share state among a cluster of boxes, but that?s not the > end of the world; a device failure sometimes causes loss of state. MAP is > the hot new thing all the cool kids are doing. > > Look to your router and load balancer vendors for devices that do these. > CGN is the only one that doesn?t require updates to the home gateway. The > more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. > > Think about how you?ll position it to customers. It?s difficult to change > a customer?s service mid-contract. At some point, a customer is no longer > profitable: if NAT costs and service calls add up, you may be better off > buying addresses or losing the customer. You may need to buy some IPv4 > addresses to give you time; contact a broker. > > You may be surprised how hard it is to root IPv4 out of the system. Don?t > buy anything you can?t manage over IPv6, including servers and > applications. Sorry, vendor, I can?t buy your cluster, I don?t have the > IPv4 address space to provision it. > > Lee > > On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" > on behalf of jmoore at atcnetworks.net> wrote: > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the >> CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack >> with the purpose of allowing their subscriber base to continue to grow >> regardless of the depletion of the IPv4 space. Current dual stack best >> practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >> this is the case, and BOTH are still required, then how does IPv6 help >> with the v4 address depletion crisis? Many sites and services would still >> need legacy IPv4 compatibility. Sure, CGN technology may be a solution >> but what about applications that need direct IPv4 connectivity without >> NAT? It seems that there should be a mechanism to enable on-demand and >> efficient IPv4 address consumption ONLY when needed. My question is this: >> What, if any, solutions like this exist? If no solution exists then what >> is the next best thing? What would the overall IPv6 migration strategy >> and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and >> while I understand the need for IPv6 and the importance of getting there; >> I don't understand exactly HOW that can be done considering the immediate >> issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > > From andrew at ethernaut.io Mon Jul 6 14:15:30 2015 From: andrew at ethernaut.io (andrew) Date: Mon, 06 Jul 2015 10:15:30 -0400 Subject: Dual stack IPv6 for IPv4 depletion Message-ID: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> Pardon my ignorance - what do you see missing in MPLS in regards to support for IP6?-------- Original message -------- From: Mel Beckman Date: 07/06/2015 9:44 AM (GMT-05:00) To: Lee Howard Cc: Josh Moore , nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion And let's all complain to the MPLS working group to get IPv6 support finished up! -mel beckman > On Jul 6, 2015, at 6:27 AM, Lee Howard wrote: > > Some thoughts. . . > > ?Native dual-stack? is ?native IPv4 and native IPv6.? > > ?Dual-stack? might be native, or might by ?native IPv6 plus IPv4 address > sharing.? > > Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are > operational deployments of all three, in the order given. You need them > close enough to your customers that traffic will return over the same > path. You can?t share state among a cluster of boxes, but that?s not the > end of the world; a device failure sometimes causes loss of state. MAP is > the hot new thing all the cool kids are doing. > > Look to your router and load balancer vendors for devices that do these. > CGN is the only one that doesn?t require updates to the home gateway. The > more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. > > Think about how you?ll position it to customers. It?s difficult to change > a customer?s service mid-contract. At some point, a customer is no longer > profitable: if NAT costs and service calls add up, you may be better off > buying addresses or losing the customer. You may need to buy some IPv4 > addresses to give you time; contact a broker. > > You may be surprised how hard it is to root IPv4 out of the system. Don?t > buy anything you can?t manage over IPv6, including servers and > applications. Sorry, vendor, I can?t buy your cluster, I don?t have the > IPv4 address space to provision it. > > Lee > > On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" > wrote: > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the >> CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack >> with the purpose of allowing their subscriber base to continue to grow >> regardless of the depletion of the IPv4 space. Current dual stack best >> practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >> this is the case, and BOTH are still required, then how does IPv6 help >> with the v4 address depletion crisis? Many sites and services would still >> need legacy IPv4 compatibility. Sure, CGN technology may be a solution >> but what about applications that need direct IPv4 connectivity without >> NAT? It seems that there should be a mechanism to enable on-demand and >> efficient IPv4 address consumption ONLY when needed. My question is this: >> What, if any, solutions like this exist? If no solution exists then what >> is the next best thing? What would the overall IPv6 migration strategy >> and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and >> while I understand the need for IPv6 and the importance of getting there; >> I don't understand exactly HOW that can be done considering the immediate >> issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > > From andrew at ethernaut.io Mon Jul 6 15:02:37 2015 From: andrew at ethernaut.io (andrew) Date: Mon, 06 Jul 2015 11:02:37 -0400 Subject: Dual stack IPv6 for IPv4 depletion Message-ID: <88wk954sd9k0s643hcggu9m0.1436194957146@email.android.com> Ah, thanks. ?I was considering this from a CE only perspective. -andrew-------- Original message -------- From: Mel Beckman Date: 07/06/2015 10:49 AM (GMT-05:00) To: andrew Cc: Lee Howard , Josh Moore , nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure ?because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes.? -mel via cell On Jul 6, 2015, at 7:15 AM, andrew wrote: Pardon my ignorance - what do you see missing in MPLS in regards to support for IP6? -------- Original message -------- From: Mel Beckman Date: 07/06/2015 9:44 AM (GMT-05:00) To: Lee Howard Cc: Josh Moore , nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion And let's all complain to the MPLS working group to get IPv6 support finished up! -mel beckman > On Jul 6, 2015, at 6:27 AM, Lee Howard wrote: > > Some thoughts. . . > > ?Native dual-stack? is ?native IPv4 and native IPv6.? > > ?Dual-stack? might be native, or might by ?native IPv6 plus IPv4 address > sharing.? > > Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are > operational deployments of all three, in the order given. You need them > close enough to your customers that traffic will return over the same > path. You can?t share state among a cluster of boxes, but that?s not the > end of the world; a device failure sometimes causes loss of state. MAP is > the hot new thing all the cool kids are doing. > > Look to your router and load balancer vendors for devices that do these. > CGN is the only one that doesn?t require updates to the home gateway. The > more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. > > Think about how you?ll position it to customers. It?s difficult to change > a customer?s service mid-contract. At some point, a customer is no longer > profitable: if NAT costs and service calls add up, you may be better off > buying addresses or losing the customer. You may need to buy some IPv4 > addresses to give you time; contact a broker. > > You may be surprised how hard it is to root IPv4 out of the system. Don?t > buy anything you can?t manage over IPv6, including servers and > applications. Sorry, vendor, I can?t buy your cluster, I don?t have the > IPv4 address space to provision it. > > Lee > > On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" > wrote: > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the >> CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack >> with the purpose of allowing their subscriber base to continue to grow >> regardless of the depletion of the IPv4 space. Current dual stack best >> practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >> this is the case, and BOTH are still required, then how does IPv6 help >> with the v4 address depletion crisis? Many sites and services would still >> need legacy IPv4 compatibility. Sure, CGN technology may be a solution >> but what about applications that need direct IPv4 connectivity without >> NAT? It seems that there should be a mechanism to enable on-demand and >> efficient IPv4 address consumption ONLY when needed. My question is this: >> What, if any, solutions like this exist? If no solution exists then what >> is the next best thing? What would the overall IPv6 migration strategy >> and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and >> while I understand the need for IPv6 and the importance of getting there; >> I don't understand exactly HOW that can be done considering the immediate >> issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > > From mel at beckman.org Mon Jul 6 15:58:59 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 6 Jul 2015 15:58:59 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org>, Message-ID: Yes. But the MPLS nodes must all connect via IPv4. -mel via cell On Jul 6, 2015, at 8:41 AM, Josh Moore > wrote: You can still carry the v6 NLRIs in MP-BGP though right? Joshua Moore Network Engineer ATC Broadband 912.632.3161 - O | 912.218.3720 - M From: Mel Beckman [mailto:mel at beckman.org] Sent: Monday, July 06, 2015 10:49 AM To: andrew Cc: Lee Howard; Josh Moore; nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes. -mel via cell On Jul 6, 2015, at 7:15 AM, andrew > wrote: Pardon my ignorance - what do you see missing in MPLS in regards to support for IP6? -------- Original message -------- From: Mel Beckman > Date: 07/06/2015 9:44 AM (GMT-05:00) To: Lee Howard > Cc: Josh Moore >, nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion And let's all complain to the MPLS working group to get IPv6 support finished up! -mel beckman > On Jul 6, 2015, at 6:27 AM, Lee Howard > wrote: > > Some thoughts. . . > > ^3Native dual-stack^2 is ^3native IPv4 and native IPv6.^2 > > ^3Dual-stack^2 might be native, or might by ^3native IPv6 plus IPv4 address > sharing.^2 > > Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are > operational deployments of all three, in the order given. You need them > close enough to your customers that traffic will return over the same > path. You can^1t share state among a cluster of boxes, but that^1s not the > end of the world; a device failure sometimes causes loss of state. MAP is > the hot new thing all the cool kids are doing. > > Look to your router and load balancer vendors for devices that do these. > CGN is the only one that doesn^1t require updates to the home gateway. The > more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. > > Think about how you^1ll position it to customers. It^1s difficult to change > a customer^1s service mid-contract. At some point, a customer is no longer > profitable: if NAT costs and service calls add up, you may be better off > buying addresses or losing the customer. You may need to buy some IPv4 > addresses to give you time; contact a broker. > > You may be surprised how hard it is to root IPv4 out of the system. Don^1t > buy anything you can^1t manage over IPv6, including servers and > applications. Sorry, vendor, I can^1t buy your cluster, I don^1t have the > IPv4 address space to provision it. > > Lee > > On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" > on behalf of jmoore at atcnetworks.net> wrote: > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the >> CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack >> with the purpose of allowing their subscriber base to continue to grow >> regardless of the depletion of the IPv4 space. Current dual stack best >> practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >> this is the case, and BOTH are still required, then how does IPv6 help >> with the v4 address depletion crisis? Many sites and services would still >> need legacy IPv4 compatibility. Sure, CGN technology may be a solution >> but what about applications that need direct IPv4 connectivity without >> NAT? It seems that there should be a mechanism to enable on-demand and >> efficient IPv4 address consumption ONLY when needed. My question is this: >> What, if any, solutions like this exist? If no solution exists then what >> is the next best thing? What would the overall IPv6 migration strategy >> and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and >> while I understand the need for IPv6 and the importance of getting there; >> I don't understand exactly HOW that can be done considering the immediate >> issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > > From jra at baylink.com Mon Jul 6 17:53:37 2015 From: jra at baylink.com (Jay Ashworth) Date: Mon, 6 Jul 2015 13:53:37 -0400 (EDT) Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <20150702000306.GA26227@vortex.com> Message-ID: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> >From Lauren, a new "feature" in Windows 10 I think this community probably wants to know about, to the extent you don't already. I *knew* I didn't like W10. :-) Cheers, -- jra ----- Forwarded Message ----- > From: "PRIVACY Forum mailing list" > To: privacy-list at vortex.com > Sent: Wednesday, July 1, 2015 8:03:06 PM > Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends > Windows 10 will share your Wi-Fi key with your friends' friends > > http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ > > In an attempt to address the security hole it has created, Microsoft > offers a kludge of a workaround: you must add _optout to the SSID (the > name of your network) to prevent it from working with Wi-Fi Sense. (So > if you want to opt out of Google Maps and Wi-Fi Sense at the same > time, > you must change your SSID of, say, myhouse to myhouse_optout_nomap. > Technology is great.) Microsoft enables Windows 10's Wi-Fi Sense by > default, and access to password-protected networks are shared with > contacts unless the user remembers to uncheck a box when they first > connect. Choosing to switch it off may make it a lot less useful, but > would make for a more secure IT environment. > > - - - > > --Lauren-- > Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren > Founder: > - Network Neutrality Squad: http://www.nnsquad.org > - PRIVACY Forum: http://www.vortex.com/privacy-info > Co-Founder: People For Internet Responsibility: > http://www.pfir.org/pfir-info > Member: ACM Committee on Computers and Public Policy > Lauren's Blog: http://lauren.vortex.com > Google+: http://google.com/+LaurenWeinstein > Twitter: http://twitter.com/laurenweinstein > Tel: +1 (818) 225-2800 / Skype: vortex.com > _______________________________________________ > privacy mailing list > http://lists.vortex.com/mailman/listinfo/privacy -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From rgolodner at infratection.com Mon Jul 6 18:16:15 2015 From: rgolodner at infratection.com (Richard Golodner) Date: Mon, 06 Jul 2015 13:16:15 -0500 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> Message-ID: <559AC5EF.80900@infratection.com> There is a reason why my family loves open source. My kid is learning Linux and she doesn't even know it. Mommy has an Android... On 07/06/2015 12:53 PM, Jay Ashworth wrote: > >From Lauren, a new "feature" in Windows 10 I think this community probably > wants to know about, to the extent you don't already. > > I *knew* I didn't like W10. :-) > > Cheers, > -- jra > > ----- Forwarded Message ----- >> From: "PRIVACY Forum mailing list" >> To: privacy-list at vortex.com >> Sent: Wednesday, July 1, 2015 8:03:06 PM >> Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends >> Windows 10 will share your Wi-Fi key with your friends' friends >> >> http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ >> >> In an attempt to address the security hole it has created, Microsoft >> offers a kludge of a workaround: you must add _optout to the SSID (the >> name of your network) to prevent it from working with Wi-Fi Sense. (So >> if you want to opt out of Google Maps and Wi-Fi Sense at the same >> time, >> you must change your SSID of, say, myhouse to myhouse_optout_nomap. >> Technology is great.) Microsoft enables Windows 10's Wi-Fi Sense by >> default, and access to password-protected networks are shared with >> contacts unless the user remembers to uncheck a box when they first >> connect. Choosing to switch it off may make it a lot less useful, but >> would make for a more secure IT environment. >> >> - - - >> >> --Lauren-- >> Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren >> Founder: >> - Network Neutrality Squad: http://www.nnsquad.org >> - PRIVACY Forum: http://www.vortex.com/privacy-info >> Co-Founder: People For Internet Responsibility: >> http://www.pfir.org/pfir-info >> Member: ACM Committee on Computers and Public Policy >> Lauren's Blog: http://lauren.vortex.com >> Google+: http://google.com/+LaurenWeinstein >> Twitter: http://twitter.com/laurenweinstein >> Tel: +1 (818) 225-2800 / Skype: vortex.com >> _______________________________________________ >> privacy mailing list >> http://lists.vortex.com/mailman/listinfo/privacy From dan at drakontas.org Mon Jul 6 18:29:53 2015 From: dan at drakontas.org (Daniel C. Eckert) Date: Mon, 6 Jul 2015 11:29:53 -0700 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <559AC5EF.80900@infratection.com> References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> Message-ID: This isn't really an open source issue -- anybody can make foolish product design decisions regardless of licensing model. This is more about a vendor producing a feature that deliberately and shortsightedly creates a slew of problems impacting almost all existing networks anywhere. It's highly convenient feature for a specific, limited use case (home users hosting a party with a bunch of people that they don't want to have to worry about how to give them a network password). However, gat ignores all of the other security and user impact issues. Can you imagine how the user experience will change when you change your SSID to include the _optout tag and then try to verbally tell someone what the new SSID is? Bonus points for dealing with users in a context where you've had the same SSID for years. On Jul 6, 2015 11:17 AM, "Richard Golodner" wrote: > There is a reason why my family loves open source. My kid is learning > Linux and she doesn't even know it. Mommy has an Android... > > On 07/06/2015 12:53 PM, Jay Ashworth wrote: > >> >From Lauren, a new "feature" in Windows 10 I think this community >> probably >> wants to know about, to the extent you don't already. >> >> I *knew* I didn't like W10. :-) >> >> Cheers, >> -- jra >> >> ----- Forwarded Message ----- >> >>> From: "PRIVACY Forum mailing list" >>> To: privacy-list at vortex.com >>> Sent: Wednesday, July 1, 2015 8:03:06 PM >>> Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with >>> your friends' friends >>> Windows 10 will share your Wi-Fi key with your friends' friends >>> >>> http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ >>> >>> In an attempt to address the security hole it has created, Microsoft >>> offers a kludge of a workaround: you must add _optout to the SSID (the >>> name of your network) to prevent it from working with Wi-Fi Sense. (So >>> if you want to opt out of Google Maps and Wi-Fi Sense at the same >>> time, >>> you must change your SSID of, say, myhouse to myhouse_optout_nomap. >>> Technology is great.) Microsoft enables Windows 10's Wi-Fi Sense by >>> default, and access to password-protected networks are shared with >>> contacts unless the user remembers to uncheck a box when they first >>> connect. Choosing to switch it off may make it a lot less useful, but >>> would make for a more secure IT environment. >>> >>> - - - >>> >>> --Lauren-- >>> Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren >>> Founder: >>> - Network Neutrality Squad: http://www.nnsquad.org >>> - PRIVACY Forum: http://www.vortex.com/privacy-info >>> Co-Founder: People For Internet Responsibility: >>> http://www.pfir.org/pfir-info >>> Member: ACM Committee on Computers and Public Policy >>> Lauren's Blog: http://lauren.vortex.com >>> Google+: http://google.com/+LaurenWeinstein >>> Twitter: http://twitter.com/laurenweinstein >>> Tel: +1 (818) 225-2800 / Skype: vortex.com >>> _______________________________________________ >>> privacy mailing list >>> http://lists.vortex.com/mailman/listinfo/privacy >>> >> > From javier at kjsl.org Mon Jul 6 18:38:37 2015 From: javier at kjsl.org (Javier Henderson) Date: Mon, 6 Jul 2015 14:38:37 -0400 Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> Message-ID: <797ADAA3-0E54-4B4F-9DD3-39374B840613@kjsl.org> > On Jul 6, 2015, at 2:29 PM, Daniel C. Eckert wrote: > > This isn't really an open source issue -- anybody can make foolish product > design decisions regardless of licensing model. This is more about a vendor > producing a feature that deliberately and shortsightedly creates a slew of > problems impacting almost all existing networks anywhere. It's highly > convenient feature for a specific, limited use case (home users hosting a > party with a bunch of people that they don't want to have to worry about > how to give them a network password). However, gat ignores all of the other > security and user impact issues. Can you imagine how the user experience > will change when you change your SSID to include the _optout tag and then > try to verbally tell someone what the new SSID is? Bonus points for dealing > with users in a context where you've had the same SSID for years. Bonus-bonus points for throwing in language barriers. Triple-bonus points if your SSID is called ?Underscore? -jav From nanog at stefan-neufeind.de Mon Jul 6 18:39:54 2015 From: nanog at stefan-neufeind.de (Stefan Neufeind) Date: Mon, 6 Jul 2015 20:39:54 +0200 Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> Message-ID: <559ACB7A.1000203@stefan-neufeind.de> Time to teach home-routers WPA Enterprise auth? Then at least you know whom to blame :-) and just one user to disconnect instead of everybody who previously had the key. Well, but if "friends" were to share your wifi-key through other ways the end-result would be the same. Just hand your key to "clueful" people. I think the point here is that we might assume people have a lot of good friends who don't know what they are doing (have things like this enabled by default)? Hmm ... yeah might be :-( Kind regards, Stefan Am 06.07.2015 um 20:29 schrieb Daniel C. Eckert: > This isn't really an open source issue -- anybody can make foolish product > design decisions regardless of licensing model. This is more about a vendor > producing a feature that deliberately and shortsightedly creates a slew of > problems impacting almost all existing networks anywhere. It's highly > convenient feature for a specific, limited use case (home users hosting a > party with a bunch of people that they don't want to have to worry about > how to give them a network password). However, gat ignores all of the other > security and user impact issues. Can you imagine how the user experience > will change when you change your SSID to include the _optout tag and then > try to verbally tell someone what the new SSID is? Bonus points for dealing > with users in a context where you've had the same SSID for years. > On Jul 6, 2015 11:17 AM, "Richard Golodner" > wrote: > >> There is a reason why my family loves open source. My kid is learning >> Linux and she doesn't even know it. Mommy has an Android... >> >> On 07/06/2015 12:53 PM, Jay Ashworth wrote: >> >>> >From Lauren, a new "feature" in Windows 10 I think this community >>> probably >>> wants to know about, to the extent you don't already. >>> >>> I *knew* I didn't like W10. :-) >>> >>> Cheers, >>> -- jra >>> >>> ----- Forwarded Message ----- >>> >>>> From: "PRIVACY Forum mailing list" >>>> To: privacy-list at vortex.com >>>> Sent: Wednesday, July 1, 2015 8:03:06 PM >>>> Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with >>>> your friends' friends >>>> Windows 10 will share your Wi-Fi key with your friends' friends >>>> >>>> http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ [...] From dave.taht at gmail.com Mon Jul 6 18:41:15 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 6 Jul 2015 11:41:15 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> References: <20150705034126.10907.qmail@ary.lan> <20150705.103227.2241541355662183955.wwaites@tardis.ed.ac.uk> <002EE633-F368-49C2-9BEA-CCC2608D57AC@atcnetworks.net> Message-ID: OpenWrt has added support for many ipv6 and ipv4 methods as of their chaos calmer release, so you can experiment with any of thousands of home routers with: 6to4, 6in4, 6rd, dslite, hnetd, and dhcpv6 today. As for 4inX methods, well, the code exists in many cases, but there is still work to be done to make it easier to use, and bugs to find, and squash. http://wiki.openwrt.org/doc/uci/network On Sun, Jul 5, 2015 at 3:21 AM, Josh Moore wrote: > Creating this in a test lab is mandatory for a successful migration. Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do not give the benefit of true end to end IPv6 connectivity in the sense of every device has a one to one global address mapping. > > Seems that my initial thoughts of dual stack and v4 overloading using private addresses to ensure compatibility is the way to go. Any input on good, possibly application aware, CGN solutions? Maybe even some policy-based DHCP/NAT product? > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Jul 5, 2015, at 5:35 AM, William Waites wrote: >> >> On Sun, 5 Jul 2015 06:13:52 +0000, Mel Beckman said: >> >>> In fact, I show just how to do this using a $99 Apple Airport >>> Express in my three-hour online course ?Build your own IPv6 Lab? >> >> An anectode about this, maybe out of date, maybe not. I was helping my >> friend who likes Apple things connect to the local community >> network. He wanted to use an Airport as his home gateway rather than >> the router that we normally use. Turns out these things can *only* do >> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is >> not exactly a clear path to native IPv6 for your lab this way. >> >> -w -- Dave T?ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From Valdis.Kletnieks at vt.edu Mon Jul 6 18:47:55 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 06 Jul 2015 14:47:55 -0400 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: Your message of "Mon, 06 Jul 2015 11:29:53 -0700." References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> Message-ID: <22240.1436208475@turing-police.cc.vt.edu> On Mon, 06 Jul 2015 11:29:53 -0700, "Daniel C. Eckert" said: > try to verbally tell someone what the new SSID is? Bonus points for dealing > with users in a context where you've had the same SSID for years. Bonus points for telling 40,000 users what the new campus SSID is.... Was Microsoft *trying* to make sure they weren't welcome in enterprise environments? ObNANOG: How does this interact with Comcast/Xfinity's wireless hotspot thing, where it *used* to be that customers could get on anyplace, but now it's "customers and anybody they happen to know?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From me at anuragbhatia.com Mon Jul 6 19:13:31 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 7 Jul 2015 00:43:31 +0530 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <22240.1436208475@turing-police.cc.vt.edu> References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> <22240.1436208475@turing-police.cc.vt.edu> Message-ID: Yeah that's scary! I have seen similar feature across multiple apps on Android and iOS. To deal with them I do mac filtering along with WPA + separate guest network where I can share password. On Tue, Jul 7, 2015 at 12:17 AM, wrote: > On Mon, 06 Jul 2015 11:29:53 -0700, "Daniel C. Eckert" said: > > > try to verbally tell someone what the new SSID is? Bonus points for > dealing > > with users in a context where you've had the same SSID for years. > > Bonus points for telling 40,000 users what the new campus SSID is.... > > Was Microsoft *trying* to make sure they weren't welcome in enterprise > environments? > > ObNANOG: How does this interact with Comcast/Xfinity's wireless hotspot > thing, where it *used* to be that customers could get on anyplace, but now > it's "customers and anybody they happen to know?" > -- Anurag Bhatia anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From dgamble at wavebroadband.com Mon Jul 6 18:17:01 2015 From: dgamble at wavebroadband.com (Dan Gamble) Date: Mon, 6 Jul 2015 18:17:01 +0000 Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> References: <20150702000306.GA26227@vortex.com> <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> Message-ID: <6F7029331BB71447931580A3317A7F9B0144F45C35@WDEXCHANGE102.headquarters.wavebroadband.gbl> It gives it to one degree of friends on . So those friends can't share it again. I'm still changing my networks to EAP, though. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Ashworth Sent: Monday, July 06, 2015 10:54 AM To: NANOG Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends From Lauren, a new "feature" in Windows 10 I think this community probably wants to know about, to the extent you don't already. I *knew* I didn't like W10. :-) Cheers, -- jra ----- Forwarded Message ----- > From: "PRIVACY Forum mailing list" > To: privacy-list at vortex.com > Sent: Wednesday, July 1, 2015 8:03:06 PM > Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with > your friends' friends Windows 10 will share your Wi-Fi key with your > friends' friends > > http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ > > In an attempt to address the security hole it has created, Microsoft > offers a kludge of a workaround: you must add _optout to the SSID (the > name of your network) to prevent it from working with Wi-Fi Sense. (So > if you want to opt out of Google Maps and Wi-Fi Sense at the same > time, you must change your SSID of, say, myhouse to > myhouse_optout_nomap. > Technology is great.) Microsoft enables Windows 10's Wi-Fi Sense by > default, and access to password-protected networks are shared with > contacts unless the user remembers to uncheck a box when they first > connect. Choosing to switch it off may make it a lot less useful, but > would make for a more secure IT environment. > > - - - > > --Lauren-- > Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren > Founder: > - Network Neutrality Squad: http://www.nnsquad.org > - PRIVACY Forum: http://www.vortex.com/privacy-info > Co-Founder: People For Internet Responsibility: > http://www.pfir.org/pfir-info > Member: ACM Committee on Computers and Public Policy Lauren's Blog: > http://lauren.vortex.com > Google+: http://google.com/+LaurenWeinstein > Twitter: http://twitter.com/laurenweinstein > Tel: +1 (818) 225-2800 / Skype: vortex.com > _______________________________________________ > privacy mailing list > http://lists.vortex.com/mailman/listinfo/privacy -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From Andrew.Bosch at elca.org Mon Jul 6 18:22:47 2015 From: Andrew.Bosch at elca.org (Andrew Bosch) Date: Mon, 6 Jul 2015 18:22:47 +0000 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <559AC5EF.80900@infratection.com> References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> Message-ID: <7345C57ED1355540BCD12A082E317F3001478A45DD@ELCACB38.ad.elca.org> Does that happen with 802.1x logins, too? Andrew > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Richard > Golodner > Sent: Monday, July 06, 2015 1:16 PM > To: nanog at nanog.org > Subject: Re: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with > your friends' friends > > There is a reason why my family loves open source. My kid is learning > Linux and she doesn't even know it. Mommy has an Android... > > On 07/06/2015 12:53 PM, Jay Ashworth wrote: > > >From Lauren, a new "feature" in Windows 10 I think this community > probably > > wants to know about, to the extent you don't already. > > > > I *knew* I didn't like W10. :-) > > > > Cheers, > > -- jra > > > > ----- Forwarded Message ----- > >> From: "PRIVACY Forum mailing list" > >> To: privacy-list at vortex.com > >> Sent: Wednesday, July 1, 2015 8:03:06 PM > >> Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your > friends' friends > >> Windows 10 will share your Wi-Fi key with your friends' friends > >> > >> http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ > >> > >> In an attempt to address the security hole it has created, Microsoft > >> offers a kludge of a workaround: you must add _optout to the SSID (the > >> name of your network) to prevent it from working with Wi-Fi Sense. (So > >> if you want to opt out of Google Maps and Wi-Fi Sense at the same > >> time, > >> you must change your SSID of, say, myhouse to myhouse_optout_nomap. > >> Technology is great.) Microsoft enables Windows 10's Wi-Fi Sense by > >> default, and access to password-protected networks are shared with > >> contacts unless the user remembers to uncheck a box when they first > >> connect. Choosing to switch it off may make it a lot less useful, but > >> would make for a more secure IT environment. > >> > >> - - - > >> > >> --Lauren-- > >> Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren > >> Founder: > >> - Network Neutrality Squad: http://www.nnsquad.org > >> - PRIVACY Forum: http://www.vortex.com/privacy-info > >> Co-Founder: People For Internet Responsibility: > >> http://www.pfir.org/pfir-info > >> Member: ACM Committee on Computers and Public Policy > >> Lauren's Blog: http://lauren.vortex.com > >> Google+: http://google.com/+LaurenWeinstein > >> Twitter: http://twitter.com/laurenweinstein > >> Tel: +1 (818) 225-2800 / Skype: vortex.com > >> _______________________________________________ > >> privacy mailing list > >> http://lists.vortex.com/mailman/listinfo/privacy From hugo at slabnet.com Mon Jul 6 20:17:10 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 6 Jul 2015 13:17:10 -0700 Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <6F7029331BB71447931580A3317A7F9B0144F45C35@WDEXCHANGE102.headquarters.wavebroadband.gbl> References: <20150702000306.GA26227@vortex.com> <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <6F7029331BB71447931580A3317A7F9B0144F45C35@WDEXCHANGE102.headquarters.wavebroadband.gbl> Message-ID: <20150706201710.GH24396@bamboo.slabnet.com> On Mon 2015-Jul-06 18:17:01 +0000, Dan Gamble wrote: >It gives it to one degree of friends on . So those friends can't share it again. > >I'm still changing my networks to EAP, though. We've been had! This is all just a giant ploy by Microsoft to push EAP adoption on WLANs! Expect to see some turn-key RADIUS solution from Microsoft in Windows 10. Marketing headline: "Prevent unauthorized access to your corporate WLANs! For the low price of $OH-MY-GOD-YOU-MUST-BE-JOKING!, get Windows Systems Center WLAN Defender today!" Those sly devils... ;) -- Hugo hugo at slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From hugo at slabnet.com Mon Jul 6 20:18:14 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 6 Jul 2015 13:18:14 -0700 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <7345C57ED1355540BCD12A082E317F3001478A45DD@ELCACB38.ad.elca.org> References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> <7345C57ED1355540BCD12A082E317F3001478A45DD@ELCACB38.ad.elca.org> Message-ID: <20150706201814.GI24396@bamboo.slabnet.com> On Mon 2015-Jul-06 18:22:47 +0000, Andrew Bosch wrote: >Does that happen with 802.1x logins, too? No. >Andrew -- Hugo hugo at slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From owen at delong.com Mon Jul 6 20:28:00 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jul 2015 13:28:00 -0700 Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> Message-ID: <021BF0FB-9D59-4D3E-9010-7657907CCC77@delong.com> Yes and no. It?s not about licensing, but it is about the fundamental difference between open and closed development models. When you make a stupid product design decision in a vacuum (closed model), and only the people drinking the same kool-aid ever see your decision on a source code level, it?s a lot easier to ship that bad decision out into widespread use. Further, the people now afflicted with your bad decision are beholden to you in order to get a fix for the problem(s) it has created. OTOH, when you try to do something stupid like this in the open source world, there are far to many eyeballs looking at what gets submitted for it to last long. Anyone and everyone can contribute a fix. Any victim has access to everything they need in order to fix it themselves. Owen > On Jul 6, 2015, at 11:29 AM, Daniel C. Eckert wrote: > > This isn't really an open source issue -- anybody can make foolish product > design decisions regardless of licensing model. This is more about a vendor > producing a feature that deliberately and shortsightedly creates a slew of > problems impacting almost all existing networks anywhere. It's highly > convenient feature for a specific, limited use case (home users hosting a > party with a bunch of people that they don't want to have to worry about > how to give them a network password). However, gat ignores all of the other > security and user impact issues. Can you imagine how the user experience > will change when you change your SSID to include the _optout tag and then > try to verbally tell someone what the new SSID is? Bonus points for dealing > with users in a context where you've had the same SSID for years. > On Jul 6, 2015 11:17 AM, "Richard Golodner" > wrote: > >> There is a reason why my family loves open source. My kid is learning >> Linux and she doesn't even know it. Mommy has an Android... >> >> On 07/06/2015 12:53 PM, Jay Ashworth wrote: >> >>>> From Lauren, a new "feature" in Windows 10 I think this community >>> probably >>> wants to know about, to the extent you don't already. >>> >>> I *knew* I didn't like W10. :-) >>> >>> Cheers, >>> -- jra >>> >>> ----- Forwarded Message ----- >>> >>>> From: "PRIVACY Forum mailing list" >>>> To: privacy-list at vortex.com >>>> Sent: Wednesday, July 1, 2015 8:03:06 PM >>>> Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with >>>> your friends' friends >>>> Windows 10 will share your Wi-Fi key with your friends' friends >>>> >>>> http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ >>>> >>>> In an attempt to address the security hole it has created, Microsoft >>>> offers a kludge of a workaround: you must add _optout to the SSID (the >>>> name of your network) to prevent it from working with Wi-Fi Sense. (So >>>> if you want to opt out of Google Maps and Wi-Fi Sense at the same >>>> time, >>>> you must change your SSID of, say, myhouse to myhouse_optout_nomap. >>>> Technology is great.) Microsoft enables Windows 10's Wi-Fi Sense by >>>> default, and access to password-protected networks are shared with >>>> contacts unless the user remembers to uncheck a box when they first >>>> connect. Choosing to switch it off may make it a lot less useful, but >>>> would make for a more secure IT environment. >>>> >>>> - - - >>>> >>>> --Lauren-- >>>> Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren >>>> Founder: >>>> - Network Neutrality Squad: http://www.nnsquad.org >>>> - PRIVACY Forum: http://www.vortex.com/privacy-info >>>> Co-Founder: People For Internet Responsibility: >>>> http://www.pfir.org/pfir-info >>>> Member: ACM Committee on Computers and Public Policy >>>> Lauren's Blog: http://lauren.vortex.com >>>> Google+: http://google.com/+LaurenWeinstein >>>> Twitter: http://twitter.com/laurenweinstein >>>> Tel: +1 (818) 225-2800 / Skype: vortex.com >>>> _______________________________________________ >>>> privacy mailing list >>>> http://lists.vortex.com/mailman/listinfo/privacy >>>> >>> >> From rdrake at direcpath.com Mon Jul 6 21:15:30 2015 From: rdrake at direcpath.com (rdrake) Date: Mon, 6 Jul 2015 17:15:30 -0400 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <559AC5EF.80900@infratection.com> References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> Message-ID: <559AEFF2.6050400@direcpath.com> On 07/06/2015 02:16 PM, Richard Golodner wrote: > Mommy has an Android... Android shares your wifi password with Google. Including the password of everyone's wifi you've ever logged into. http://www.computerworld.com/article/2474851/android-google-knows-nearly-every-wi-fi-password-in-the-world.html From rgolodner at infratection.com Mon Jul 6 21:34:01 2015 From: rgolodner at infratection.com (Richard Golodner) Date: Mon, 06 Jul 2015 16:34:01 -0500 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <559AEFF2.6050400@direcpath.com> References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> <559AC5EF.80900@infratection.com> <559AEFF2.6050400@direcpath.com> Message-ID: <559AF449.1040409@infratection.com> I long for the days of a good old fashion, bar, that made calls and received them. The smart phones are "smarter" than I am, but that is not much of a challenege either! On 07/06/2015 04:15 PM, rdrake wrote: > On 07/06/2015 02:16 PM, Richard Golodner wrote: >> Mommy has an Android... > Android shares your wifi password with Google. Including the password > of everyone's wifi you've ever logged into. > > http://www.computerworld.com/article/2474851/android-google-knows-nearly-every-wi-fi-password-in-the-world.html > > > > > From octalnanog at alvarezp.org Tue Jul 7 01:29:20 2015 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Mon, 06 Jul 2015 18:29:20 -0700 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends In-Reply-To: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> References: <2499202.14.1436205217670.JavaMail.root@benjamin.baylink.com> Message-ID: <559B2B70.1000601@alvarezp.org> Terrible idea. These are the kind of features that should be opt in, and Microsoft could have done that instead. Does the 802.11 beacon support TLV data, like setting some opt-out flag without changing the SSID? (Even if the the flag name hasn't been yet agreed on?) Would this be a bad idea? Best regards. On 06/07/15 10:53, Jay Ashworth wrote: > From Lauren, a new "feature" in Windows 10 I think this community probably > wants to know about, to the extent you don't already. > > I *knew* I didn't like W10. :-) > > Cheers, > -- jra > > ----- Forwarded Message ----- >> From: "PRIVACY Forum mailing list" >> To: privacy-list at vortex.com >> Sent: Wednesday, July 1, 2015 8:03:06 PM >> Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends >> Windows 10 will share your Wi-Fi key with your friends' friends >> >> http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ >> >> In an attempt to address the security hole it has created, Microsoft >> offers a kludge of a workaround: you must add _optout to the SSID (the >> name of your network) to prevent it from working with Wi-Fi Sense. (So >> if you want to opt out of Google Maps and Wi-Fi Sense at the same >> time, >> you must change your SSID of, say, myhouse to myhouse_optout_nomap. >> Technology is great.) Microsoft enables Windows 10's Wi-Fi Sense by >> default, and access to password-protected networks are shared with >> contacts unless the user remembers to uncheck a box when they first >> connect. Choosing to switch it off may make it a lot less useful, but >> would make for a more secure IT environment. >> >> - - - >> >> --Lauren-- >> Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren >> Founder: >> - Network Neutrality Squad: http://www.nnsquad.org >> - PRIVACY Forum: http://www.vortex.com/privacy-info >> Co-Founder: People For Internet Responsibility: >> http://www.pfir.org/pfir-info >> Member: ACM Committee on Computers and Public Policy >> Lauren's Blog: http://lauren.vortex.com >> Google+: http://google.com/+LaurenWeinstein >> Twitter: http://twitter.com/laurenweinstein >> Tel: +1 (818) 225-2800 / Skype: vortex.com >> _______________________________________________ >> privacy mailing list >> http://lists.vortex.com/mailman/listinfo/privacy > From jgreco at ns.sol.net Tue Jul 7 02:12:55 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 6 Jul 2015 21:12:55 -0500 (CDT) Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: <559B2B70.1000601@alvarezp.org> Message-ID: <201507070212.t672Ctm0060588@aurora.sol.net> > Terrible idea. These are the kind of features that should be opt in, and > Microsoft could have done that instead. It *is* an option. When you're setting up Windows 10, it asks you two screens of configuration questions, but most people will hit the "Use express settings" option and just blow past the choice. I don't know, most of the express settings seem to be craptacular to me, so I always go through all the "defaults" and usually find myself flipping many/most of them. But that's probably because I am not in search of automated Cortana and Bing magic page prediction goodness that auto- matically shares my name, location, and advertising ID with every random website that it possibly can (hyperbole?? maybe??) http://winaero.com/blog/windows-10-build-10074-features-a-reworked-setup-experience/ Anyways, if you look on the first page of "Customize settings", yes there's an option for "Automatically connect to networks shared by my contacts" and it CAN be turned off, but it defaults to on. I didn't spend a lot of time trying to figure out exactly how that'd work. I don't really want my "contacts" or any other data being sent to Microsoft's servers. I have my own servers that I'm reasonably happy with. I have an uneasy feeling that if set I'd find it to be slurping a lot of data over to Microsoft's servers and I guess I would not be shocked to find that 50 of my best friends on NANOG are suddenly (and unexpectedly) populating WiFi passwords at me. I suppose I could be wrong, but it's amazing how many LinkedIn invites I get from people I've never heard of, who seem to only have a mailing list in common, etc. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From sean at donelan.com Tue Jul 7 03:03:29 2015 From: sean at donelan.com (Sean Donelan) Date: Mon, 6 Jul 2015 23:03:29 -0400 (EDT) Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: <201507070212.t672Ctm0060588@aurora.sol.net> References: <201507070212.t672Ctm0060588@aurora.sol.net> Message-ID: On Mon, 6 Jul 2015, Joe Greco wrote: > Anyways, if you look on the first page of "Customize settings", yes > there's an option for "Automatically connect to networks shared by my > contacts" and it CAN be turned off, but it defaults to on. Defaults matter. Every configuration parameter has a default setting, whether intentional or not. From baconzombie at gmail.com Tue Jul 7 08:36:43 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Tue, 7 Jul 2015 10:36:43 +0200 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: References: <201507070212.t672Ctm0060588@aurora.sol.net> Message-ID: This is on by default in the beta like all the reporting in MS. Will probably be either a prompt in the RTM version. On 7 Jul 2015 05:05, "Sean Donelan" wrote: > On Mon, 6 Jul 2015, Joe Greco wrote: > >> Anyways, if you look on the first page of "Customize settings", yes >> there's an option for "Automatically connect to networks shared by my >> contacts" and it CAN be turned off, but it defaults to on. >> > > Defaults matter. Every configuration parameter has a default setting, > whether intentional or not. > > From jgreco at ns.sol.net Tue Jul 7 09:41:47 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 7 Jul 2015 04:41:47 -0500 (CDT) Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: Message-ID: <201507070941.t679flJd068865@aurora.sol.net> "Sean Donelan" writes: > On Mon, 6 Jul 2015, Joe Greco wrote: > > Anyways, if you look on the first page of "Customize settings", yes > > there's an option for "Automatically connect to networks shared by my > > contacts" and it CAN be turned off, but it defaults to on. > > Defaults matter. Every configuration parameter has a default setting, > whether intentional or not. Well of course defaults matter. We work in an industry where the defaults supplied by most tech companies for the average user are quite depressing to me. People want easy and many don't bother to understand or (even worse) care about privacy. Just look at web advertising and tracking. As bad as that is on the general Internet, even I was a bit shocked to find yesterday while training NoScript on a new VM that a certain wireless carrier's customer portal was reaching out to maybe as many as twenty different ad and tracking networks, including Bing, Yahoo, and Google, in order for you to log in and pay your bill. http://www.sol.net/tmp/nanog/mytmobile-login.jpg This stuff is frickin' pervasive. The default is "track the hell out of everyone" and "share everything you can." I remember first seeing the Windows 10 "share networks to contacts" and trying to imagine that it meant anything other than wifi access creds. That's part of the problem. They don't even tell you what the words are actually saying, or why it matters one way or another. For those on this list, that may not be a problem, but my 80 year old mom isn't going to have a clue. Bacon Zombie writes: > This is on by default in the beta like all the reporting in MS. > > Will probably be either a prompt in the RTM version. Sure. A prompt that defaults to on, on a screen that most people probably bypass, because the new thing is to make tech easy, and bogging them down with a bunch of questions that only computer geeks and privacy wonks and network gearheads care about (or even understand) is anti-user. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mawatari at jpix.ad.jp Tue Jul 7 13:26:49 2015 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Tue, 07 Jul 2015 22:26:49 +0900 Subject: JANOG36 English info available Message-ID: <20150707222648.E9DF.8FE1F57E@jpix.ad.jp> Hi all, JANOG 36 meeting will be held in Kitakyushu city, Japan next week. The timetable and program abstracts are available on the following site now. https://www.janog.gr.jp/en/index.php?JANOG36_Meeting%2FJANOG36_Program_Contents You can register at: https://regist.e-side.co.jp/product_info.php?products_id=515&language=en Deadline for conference: 8th July 2015 JST 12:00 (Soon!) (Banquet registration already closed, sorry) Masataka on behalf of JANOG Internationalization team (JANOG i18n) -- Japan Internet Exchange MAWATARI Masataka From Valdis.Kletnieks at vt.edu Tue Jul 7 18:31:55 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Jul 2015 14:31:55 -0400 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: Your message of "Mon, 06 Jul 2015 21:12:55 -0500." <201507070212.t672Ctm0060588@aurora.sol.net> References: <201507070212.t672Ctm0060588@aurora.sol.net> Message-ID: <8513.1436293915@turing-police.cc.vt.edu> On Mon, 06 Jul 2015 21:12:55 -0500, Joe Greco said: > http://winaero.com/blog/windows-10-build-10074-features-a-reworked-setup-experience/ > > Anyways, if you look on the first page of "Customize settings", yes > there's an option for "Automatically connect to networks shared by my > contacts" and it CAN be turned off, but it defaults to on. There's a subtle but important difference between that and "Allow this device to send sharing info to contacts"..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jgreco at ns.sol.net Tue Jul 7 18:59:02 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 7 Jul 2015 13:59:02 -0500 (CDT) Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: <8513.1436293915@turing-police.cc.vt.edu> Message-ID: <201507071859.t67Ix2aJ073468@aurora.sol.net> > On Mon, 06 Jul 2015 21:12:55 -0500, Joe Greco said: > > > http://winaero.com/blog/windows-10-build-10074-features-a-reworked-setup-experience/ > > > > Anyways, if you look on the first page of "Customize settings", yes > > there's an option for "Automatically connect to networks shared by my > > contacts" and it CAN be turned off, but it defaults to on. > > There's a subtle but important difference between that and "Allow this > device to send sharing info to contacts"..... Is there? The problem is that the text that's presented there is so vague as to what it means that it is completely worthless to try to infer anything from it. Without going and researching it further, which may or may not be feasible for some poor soul deploying the damn thing since it is quite possible it is their only computer, it is unclear whether it might mean any one of a dozen or more things. I could easily believe that setting this option could automagically sign you up for SSID password sharing with your contacts. Especially the first time I saw it, I had no idea what it meant other than that it was likely something that was probably in the bad to evil range, because, well, that's the point, it doesn't actually SAY what it is you're committing to. The stuff later on (which is referenced in The Register article that was initially quoted) may help make it a little clearer, but again, there's a lot of bad, and you get to answer that first question without knowing what the context is. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From betty at nanog.org Tue Jul 7 19:16:58 2015 From: betty at nanog.org (Betty Burke ) Date: Tue, 7 Jul 2015 15:16:58 -0400 Subject: [NANOG-announce] 2015 Postel Scholarship Announcement Message-ID: Colleagues, On behalf of the North American Network Operators' Group (NANOG) and the American Registry for Internet Numbers (ARIN), I would like to take this opportunity to draw your attention to the 2015 Postel Network Operator's Scholarship. The Postel Network Operator's Scholarship targets personnel from developing countries who are actively involved in Internet development, in any of the following roles: - Engineers (Network Builders) - Operational and Infrastructure Support Personnel - Educators and Trainers This is not a postgraduate fellowship or academic scholarship. Individuals may nominate themselves for the Scholarship via email or online form. The Scholarship will be awarded annually to a recipient selected by a committee comprising representatives from the NANOG Board of Directors and the ARIN Board of Trustees. The selection committee will "whimsically" select the annual recipient exclusively in response to the question: "What Would Jon Do?" if he were asked to select a recipient. The successful applicant will be provided with transportation to and from the NANOG and ARIN joint meeting October 5-9, 2015, in Montreal, Quebec Canada, and a reasonable (local host standard) allowance for food and accommodation. In addition, all fees for participation in both meetings' events will be waived. The final grant size is determined according to final costs and available funding. The chosen recipient will be advised at least 2 months prior to the fall meeting date. Applications from qualified individuals are now being accepted. The deadline for application is July 31, and the awardees will be informed by August 10, 2015. Please read full information about the scholarship at: http://www.nanog.org/scholarships/postel.php To apply, please complete the web-based application form that is linked from that page. Optionally, you may submit your application in PLAIN ASCII in the BODY of the message, not as an attachment nor as a Word document, PDF, or any other form, to PostelNOS at nanog.org. Please be sure to include the following: - Full name and contact info - Your brief biography, including current and recent jobs held - A description of why you need and deserve this Scholarship to attend the NANOG and ARIN meetings - A description of how you plan to leverage your attendance at the meetings in your work - A brief abstract of a presentation you would give at the NANOG and/or ARIN meetings, if selected as a Scholarship winner Kind regards, Betty Burke on behalf of the Postel Scholarship Selection Committee ------------------------------------------------ Betty J. Burke NANOG Executive Director 2864 Carpenter Rd., Ste 100 Ann Arbor, MI 48108 +1 866-902-1336 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From octalnanog at alvarezp.org Tue Jul 7 19:30:36 2015 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Tue, 07 Jul 2015 12:30:36 -0700 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: <201507070212.t672Ctm0060588@aurora.sol.net> References: <201507070212.t672Ctm0060588@aurora.sol.net> Message-ID: <559C28DC.4000905@alvarezp.org> On 06/07/15 19:12, Joe Greco wrote: >> Terrible idea. These are the kind of features that should be opt in, and >> Microsoft could have done that instead. > > It *is* an option. Opt-in and opt-out are two models of having an option. Also I meant being opt-out for the network administrator regarding the availability of the _optout suffix. Instead it should have been opt-in by the use of some _share suffix. > Anyways, if you look on the first page of "Customize settings", yes > there's an option for "Automatically connect to networks shared by my > contacts" and it CAN be turned off, but it defaults to on. That's an option for the users, not for the network administrator. As a network administrator (at home, at work, whatever) I have some trust for my users but not necessarily for the friends of my users. The decision should be up to the network administrator, not the user. The way it's implemented, user inaction makes him/her violate network usage policy. Best regards. Octavio. From brfree at adobe.com Tue Jul 7 21:14:57 2015 From: brfree at adobe.com (Brian Free) Date: Tue, 7 Jul 2015 21:14:57 +0000 Subject: IPv4 STLS Message-ID: Looking at acquiring some additional IPv4 address space. Anyone have suggestions or recommendations on brokers you've worked with, and is ARIN's STLS a good option? Thanks in advance for your input. -- Brian Free From bmanning at karoshi.com Tue Jul 7 21:21:02 2015 From: bmanning at karoshi.com (manning) Date: Tue, 7 Jul 2015 14:21:02 -0700 Subject: IPv4 STLS In-Reply-To: References: Message-ID: <44AE8883-1CFC-41AA-BE2D-92190C06323C@karoshi.com> STLS is the place to start. There are other places, some of whom might be a better fit for your needs/capabilities. manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 7July2015Tuesday, at 14:14, Brian Free wrote: > Looking at acquiring some additional IPv4 address space. Anyone have suggestions or recommendations on brokers you've worked with, and is ARIN's STLS a good option? Thanks in advance for your input. > -- > Brian Free From jgreco at ns.sol.net Tue Jul 7 21:39:01 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 7 Jul 2015 16:39:01 -0500 (CDT) Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: <559C28DC.4000905@alvarezp.org> Message-ID: <201507072139.t67Ld1ZL075222@aurora.sol.net> > On 06/07/15 19:12, Joe Greco wrote: > >> Terrible idea. These are the kind of features that should be opt in, and > >> Microsoft could have done that instead. > > > > It *is* an option. > > Opt-in and opt-out are two models of having an option. > > Also I meant being opt-out for the network administrator regarding the > availability of the _optout suffix. Instead it should have been opt-in > by the use of some _share suffix. No, it should have been opt-in by the use of some standards-track mechanism. Substituting less-screwed for more-screwed is still just screwed at the end of the day. > > Anyways, if you look on the first page of "Customize settings", yes > > there's an option for "Automatically connect to networks shared by my > > contacts" and it CAN be turned off, but it defaults to on. > > That's an option for the users, not for the network administrator. That's unclear. It is likely settable as policy at some level. I'm not going to defend Microsoft since I think it is total crap, but I am not going to be totally unfair about it. > As a network administrator (at home, at work, whatever) I have some > trust for my users but not necessarily for the friends of my users. The > decision should be up to the network administrator, not the user. > > The way it's implemented, user inaction makes him/her violate network > usage policy. Unclear at best. The way it is implemented, the user has the potential to go either way. A network might not want the user to have the choice, clearly, but there is certainly a subset of users who will opt out of the feature and I cannot see how those would be in violation of any sane network usage policy. It's certainly a mess in any case. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mark.tinka at seacom.mu Wed Jul 8 04:50:27 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 Jul 2015 06:50:27 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> Message-ID: <559CAC13.80803@seacom.mu> On 6/Jul/15 16:49, Mel Beckman wrote: > MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes. Not true - Cisco have it in IOS XR since 5.3.0. Juniper expect to start shipping it later in 15. Mark. From pelzi at pelzi.net Wed Jul 8 13:46:52 2015 From: pelzi at pelzi.net (Jussi Peltola) Date: Wed, 8 Jul 2015 16:46:52 +0300 Subject: World's Fastest =?utf-8?Q?Internet?= =?utf-8?B?4oSi?= in Canadaland In-Reply-To: <20150626215603.87EE331651DC@rock.dv.isc.org> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <20150626215603.87EE331651DC@rock.dv.isc.org> Message-ID: <20150708134652.GH6354@pokute.pelzi.net> On Sat, Jun 27, 2015 at 07:56:03AM +1000, Mark Andrews wrote: > You don't think about the size of power lines coming into a house > as they are overkill for just about anything you will do in the > house. > > You don't think about the size of water pipes coming into a house > as they are overkill for just about anything you will do in the > house. Very occasionally you will want to connect directly to the > mains (filling a pool) but otherwise the pipe is more that sufficient. Water pipes are sized by pressure drop. You do not want your shower to have fluctuating water pressure if the washer is on while you're there. If you hook up a hose that is the same size as your water main, you can get quite a lot of water at an unacceptable pressure drop, but this may erode the pipe long-term and certainly makes it impossible to shower while you're doing it. Power cables are sized by voltage drop. If the power company sized the wires like they are usually done in houses (just big enough to not overheat and no more) your lights would dim every time you turn any appliance on and you would find it unacceptable. But you could get more power without the cable catching fire if you replaced the main breaker with a bigger one, just watch out for undervoltage and an upset power company. For some reason, it seems some people have problems grasping the idea of having an uncongested path to the Internet even though some of your devices are downloading updates and someone in your family is watching netflix. I wonder if these people leave the tap dripping overnight into a bucket so they can shower while not using more than a few liters per hour? Who would possibly ever need more? And I assume they need to store city gas in a bag to light up their cooker, too. And Tesla's home battery must be the greatest thing since sliced bread. Who would possibly need more than 1-2kW of power per person? Jussi From marshall.eubanks at gmail.com Wed Jul 8 14:06:47 2015 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Wed, 8 Jul 2015 10:06:47 -0400 Subject: United Airlines is Down (!) due to network connectivity problems Message-ID: http://www.reuters.com/article/2015/07/08/us-ual-flights-idUSKCN0PI1IX20150708 At least, that's what I just heard on the radio. I know no other details. Regards Marshall Eubanks From nanog at ics-il.net Wed Jul 8 14:12:33 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 8 Jul 2015 09:12:33 -0500 (CDT) Subject: =?utf-8?Q?Re:_World's_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: <20150708134652.GH6354@pokute.pelzi.net> Message-ID: <39307674.7369.1436364779948.JavaMail.mhammett@ThunderFuck> You also pay those utilities for usage. You don't do that for Internet. Well, most don't. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jussi Peltola" To: nanog at nanog.org Sent: Wednesday, July 8, 2015 8:46:52 AM Subject: Re: Re: World's Fastest Internet? in Canadaland On Sat, Jun 27, 2015 at 07:56:03AM +1000, Mark Andrews wrote: > You don't think about the size of power lines coming into a house > as they are overkill for just about anything you will do in the > house. > > You don't think about the size of water pipes coming into a house > as they are overkill for just about anything you will do in the > house. Very occasionally you will want to connect directly to the > mains (filling a pool) but otherwise the pipe is more that sufficient. Water pipes are sized by pressure drop. You do not want your shower to have fluctuating water pressure if the washer is on while you're there. If you hook up a hose that is the same size as your water main, you can get quite a lot of water at an unacceptable pressure drop, but this may erode the pipe long-term and certainly makes it impossible to shower while you're doing it. Power cables are sized by voltage drop. If the power company sized the wires like they are usually done in houses (just big enough to not overheat and no more) your lights would dim every time you turn any appliance on and you would find it unacceptable. But you could get more power without the cable catching fire if you replaced the main breaker with a bigger one, just watch out for undervoltage and an upset power company. For some reason, it seems some people have problems grasping the idea of having an uncongested path to the Internet even though some of your devices are downloading updates and someone in your family is watching netflix. I wonder if these people leave the tap dripping overnight into a bucket so they can shower while not using more than a few liters per hour? Who would possibly ever need more? And I assume they need to store city gas in a bag to light up their cooker, too. And Tesla's home battery must be the greatest thing since sliced bread. Who would possibly need more than 1-2kW of power per person? Jussi From ramy.ihashish at gmail.com Wed Jul 8 14:26:31 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Wed, 8 Jul 2015 16:26:31 +0200 Subject: NANOG Digest, Vol 90, Issue 1 In-Reply-To: References: Message-ID: Hello Dennis, I am very happy because somebody is on the same page. > Message: 20 > Date: Tue, 30 Jun 2015 14:37:55 -0400 > From: Dennis B > To: Roland Dobbins > Cc: nanog at nanog.org > Subject: Re: GRE performance over the Internet - DDoS cloud mitigation > Message-ID: > < > CAPr+j8J4vs2y8C6AB3FWGhrVF-GLt02inzvxsPs86m2-ChN6eg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Depends on what performance considerations you are trying to address, > technically. > > The question is how can we guarantee the GRE/BGP performance (control > traffic) during the time between detection and mitigation? > > Exactly > GRE decapsulation? > IE: Hardware vs Software? > Software. > Routing of the Protocol over the internet? > IE: If the inbound path is saturated, what is the availability of the GRE > tunnel? > Yes. > User-experience with GRE packet overhead? > IE: TCP Fragmentation causing PMTUD messages for reassembly? > > Not the main concern right now, however I would like to hear from you in this ponit as well. > I've worked at Prolexic for 7 years and now Akamai for 1.4 yrs, post > acquisition. > > We are contacting AKamai for the solution by the way, and we are contacting the Prolexic's founders acquired company defense.net (now F5) as well :) > Immediately, I can think of mul > tiple scenarios' (3) that come to mind on > how to solve any one of these categories. > > Would you like to learn more? lol > > Sure I would love to :) Message: 23 > Date: Tue, 30 Jun 2015 16:32:54 -0400 > From: Dennis B > To: Roland Dobbins > Cc: nanog at nanog.org > Subject: Re: GRE performance over the Internet - DDoS cloud mitigation > Message-ID: > < > CAPr+j8LC7h_LLU+j5kwQcvxwLd8Pd+jwP5W7f62Ph2i7g6ZsTg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Roland, > > Agreed, Ramy's scenario was not truly spot on, but his question still > remains. Perf implications when cloud security providers time to > detect/mitigate is X minutes. How stable can GRE transports and BGP > sessions be when under load? > > This is the question. > In my technical opinion, this is a valid argument, which deems wide > opinion. Specifically, use-cases about how to apply defense in depth > logically in the DC vs Hybrid vs Pure Cloud. > > Our defense model will be your so called "in depth logically in the DC", however, we are protecting our NW infrastructure, and we are trying to reach a wholesale agreement in order to protect our customer accordingly. One more thing to elaborate, we have our own DDoS mitigation equipment, and it is located in the edge of the network nearest to the high capacity Internet circuits to minimize the local transit cost. I hope it is clear now. Thanks, Ramy From patrick at ianai.net Wed Jul 8 14:51:56 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 8 Jul 2015 10:51:56 -0400 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: References: Message-ID: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> Lifted as of 0920 EDT. -- TTFN, patrick > On Jul 08, 2015, at 10:06 , Marshall Eubanks wrote: > > http://www.reuters.com/article/2015/07/08/us-ual-flights-idUSKCN0PI1IX20150708 > > At least, that's what I just heard on the radio. I know no other details. > > Regards > Marshall Eubanks From mel at beckman.org Wed Jul 8 15:21:51 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 8 Jul 2015 15:21:51 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559CAC13.80803@seacom.mu> References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org>, <559CAC13.80803@seacom.mu> Message-ID: <7C13F72A-4282-47B1-BB59-6E95B8EE7378@beckman.org> That's good to hear! -mel beckman > On Jul 7, 2015, at 9:50 PM, Mark Tinka wrote: > > > >> On 6/Jul/15 16:49, Mel Beckman wrote: >> MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes. > > Not true - Cisco have it in IOS XR since 5.3.0. > > Juniper expect to start shipping it later in 15. > > Mark. From rdobbins at arbor.net Wed Jul 8 15:26:22 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 08 Jul 2015 22:26:22 +0700 Subject: NANOG Digest, Vol 90, Issue 1 In-Reply-To: References: Message-ID: <56B9AB8A-C47E-4C52-87EF-C482AC008DF7@arbor.net> On 8 Jul 2015, at 21:26, Ramy Hashish wrote: > I am very happy because somebody is on the same page. This is not what you were asking about in your original post on this topic - you were talking about BGP sessions inside GRE tunnels, which is not how most (any?) DDoS mitigation services operate, to my knowledge. GRE is used over the Internet for many different applications, including post-DDoS-mitigation re-injection of legitimate traffic onwards to the server/services under protection. Hardware-based GRE processing is required on both ends for anything other than trivial speeds; in general, the day of software-based Internet routers is long gone, and any organization still running software-based routers on their transit/peering edge is at risk. DDoS mitigation providers using GRE for re-injection should set the MTU on their mitigation center diversion interfaces to 1476, and MSS-clamping on those same interfaces to 1436, as a matter of course. This is not a new model; it has been extant for many years. There are a variety of overlay and transit-focused DDoS mitigation service providers who utilize this model. In your original post on this topic, you also made the assertion that these issues had not been addressed by DDoS mitigation service operators; that assertion is incorrect. ----------------------------------- Roland Dobbins From ghankins at mindspring.com Wed Jul 8 15:32:41 2015 From: ghankins at mindspring.com (Greg Hankins) Date: Wed, 8 Jul 2015 11:32:41 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559CAC13.80803@seacom.mu> References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> Message-ID: <20150708153241.GA8895@mindspring.com> We added LDP IPv6 support in SR OS 13.0.R1 for Alcatel-Lucent 7x50 platforms earlier this year. Regards, Greg -- Greg Hankins -----Original Message----- Date: Wed, 8 Jul 2015 06:50:27 +0200 From: Mark Tinka To: Mel Beckman , andrew Cc: Josh Moore , "nanog at nanog.org" Subject: Re: Dual stack IPv6 for IPv4 depletion On 6/Jul/15 16:49, Mel Beckman wrote: > MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes. Not true - Cisco have it in IOS XR since 5.3.0. Juniper expect to start shipping it later in 15. Mark. From mel at beckman.org Wed Jul 8 15:59:26 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 8 Jul 2015 15:59:26 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150708153241.GA8895@mindspring.com> References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu>,<20150708153241.GA8895@mindspring.com> Message-ID: Greg, After investigating what a previous poster said about Cisco and Juniper, I'm getting the feeling that not all major impediments to running MPLS over IPv6-only networks have been addressed. Your comment mentions LDP IPv6 support. Do you now handle all the major gaps identified the the IETF MPLS IPv6 Gap Analysis (RFC7439) from this last January? https://tools.ietf.org/html/rfc7439#section-3 It seems like their are still gaps in the MPLS spec itself before IPv6 has parity with IPv4 in MPLS. -mel beckman > On Jul 8, 2015, at 8:33 AM, Greg Hankins wrote: > > We added LDP IPv6 support in SR OS 13.0.R1 for Alcatel-Lucent 7x50 platforms > earlier this year. > > Regards, > Greg > > -- > Greg Hankins > > -----Original Message----- > Date: Wed, 8 Jul 2015 06:50:27 +0200 > From: Mark Tinka > To: Mel Beckman , andrew > Cc: Josh Moore , > "nanog at nanog.org" > Subject: Re: Dual stack IPv6 for IPv4 depletion > > > >> On 6/Jul/15 16:49, Mel Beckman wrote: >> MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes. > > Not true - Cisco have it in IOS XR since 5.3.0. > > Juniper expect to start shipping it later in 15. > > Mark. From rdobbins at arbor.net Wed Jul 8 16:00:46 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 08 Jul 2015 23:00:46 +0700 Subject: NANOG Digest, Vol 90, Issue 1 In-Reply-To: <56B9AB8A-C47E-4C52-87EF-C482AC008DF7@arbor.net> References: <56B9AB8A-C47E-4C52-87EF-C482AC008DF7@arbor.net> Message-ID: <4699E142-FD73-4D23-B3A4-0702B3621210@arbor.net> On 8 Jul 2015, at 22:26, Roland Dobbins wrote: > Hardware-based GRE processing is required on both ends for anything > other than trivial speeds; in general, the day of software-based > Internet routers is long gone, and any organization still running > software-based routers on their transit/peering edges at risk. To clarify, I'm referring to GRE processing on routers; hardware processing is pretty much a requirement on routers. Other types of devices can often handle GRE at significantly higher rates than software-based routers. ----------------------------------- Roland Dobbins From mhuff at ox.com Wed Jul 8 16:26:26 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 8 Jul 2015 16:26:26 +0000 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> Message-ID: Hmmm, Wall Street Journal and NYSE both down?. WSJ has a static page up? DDOS ??? > On Jul 8, 2015, at 10:51 AM, Patrick W. Gilmore wrote: > > > Lifted as of 0920 EDT. > > > > -- > TTFN, > patrick > >> On Jul 08, 2015, at 10:06 , Marshall Eubanks wrote: >> >> http://www.reuters.com/article/2015/07/08/us-ual-flights-idUSKCN0PI1IX20150708 >> >> At least, that's what I just heard on the radio. I know no other details. >> >> Regards >> Marshall Eubanks > From fergdawgster at mykolab.com Wed Jul 8 16:36:42 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 8 Jul 2015 09:36:42 -0700 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> Message-ID: <559D519A.6080904@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All completely coincidental networking issues, not related to anything malicious. - - ferg On 7/8/2015 9:26 AM, Matthew Huff wrote: > Hmmm, > > Wall Street Journal and NYSE both down?. > > WSJ has a static page up? > > DDOS ??? > > > >> On Jul 8, 2015, at 10:51 AM, Patrick W. Gilmore >> wrote: >> >> >> Lifted as of 0920 EDT. >> >> >> >> >> - -- >> TTFN, patrick >> >>> On Jul 08, 2015, at 10:06 , Marshall Eubanks >>> wrote: >>> >>> http://www.reuters.com/article/2015/07/08/us-ual-flights-idUSKCN0PI1 IX20150708 >>> >>> >>> At least, that's what I just heard on the radio. I know no other details . >>> >>> Regards Marshall Eubanks >> > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWdUZoACgkQKJasdVTchbK1vAD/Q9gFlefUn9rIzlaRUMHvU0Ku Nmv6PSUUUD9f5LRLxX0BAMvXl4G5YE/ZTiz9sB5i/x5BRgmVG9XxzY5nZd/0zNtj =Hpoz -----END PGP SIGNATURE----- From jco at direwolf.com Wed Jul 8 16:40:35 2015 From: jco at direwolf.com (John Orthoefer) Date: Wed, 8 Jul 2015 12:40:35 -0400 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <559D519A.6080904@mykolab.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> Message-ID: <7B4277DC-145C-47EE-B683-8B9784822A9D@direwolf.com> And now trading has been halted at the NYSE. http://www.npr.org/sections/thetwo-way/2015/07/08/421153353/trading-halted-on-new-york-stock-exchange Again undisclosed technical issue > On Jul 8, 2015, at 12:36 PM, Paul Ferguson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > All completely coincidental networking issues, not related to anything > malicious. > > - - ferg > From mhuff at ox.com Wed Jul 8 16:50:29 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 8 Jul 2015 16:50:29 +0000 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <559D519A.6080904@mykolab.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> Message-ID: Once is happenstance Twice is coincidence Three times is enemy action? Serious, could all be just everyone having a bad day. On the other hand, the WSJ has to deal with DOS/DDOS all the time, and usually if the NYSE has issues, it?s normally on a Monday. > On Jul 8, 2015, at 12:36 PM, Paul Ferguson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > All completely coincidental networking issues, not related to anything > malicious. > > - - ferg > > > On 7/8/2015 9:26 AM, Matthew Huff wrote: > >> Hmmm, >> >> Wall Street Journal and NYSE both down?. >> >> WSJ has a static page up? >> >> DDOS ??? >> >> >> >>> On Jul 8, 2015, at 10:51 AM, Patrick W. Gilmore >>> wrote: >>> >>> >>> Lifted as of 0920 EDT. >>> >>> rounded-due-to-computer-issues/?intcmp=latestnews> >>> >>> >>> > - -- >>> TTFN, patrick >>> >>>> On Jul 08, 2015, at 10:06 , Marshall Eubanks >>>> wrote: >>>> >>>> http://www.reuters.com/article/2015/07/08/us-ual-flights-idUSKCN0PI1 > IX20150708 >>>> >>>> >>>> > At least, that's what I just heard on the radio. I know no other details > . >>>> >>>> Regards Marshall Eubanks >>> >> > > > - -- > Paul Ferguson > PGP Public Key ID: 0x54DC85B2 > Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EAREIAAYFAlWdUZoACgkQKJasdVTchbK1vAD/Q9gFlefUn9rIzlaRUMHvU0Ku > Nmv6PSUUUD9f5LRLxX0BAMvXl4G5YE/ZTiz9sB5i/x5BRgmVG9XxzY5nZd/0zNtj > =Hpoz > -----END PGP SIGNATURE----- From Mark.Mayfield at cityofroseville.com Wed Jul 8 16:58:24 2015 From: Mark.Mayfield at cityofroseville.com (Mark Mayfield) Date: Wed, 8 Jul 2015 16:58:24 +0000 Subject: Possible Sudden Uptick in ASA DOS? Message-ID: Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. Another pair running the same code had the primary crash and fail in the same time window. So, three crashes in 4 hours in our environment. Open a TAC case on one of these for post-mortem analysis, and they interpreted the crash dump to point at a DOS bug first published in Oct. The very interesting thing; on the phone the TAC engineer said this was "the 10th one of these I've dealt with this morning". Here's the bug they reference: https://tools.cisco.com/bugsearch/bug/CSCul36176/?reffering_site=dumpcr Anyone else have observations to add on this? Mark Mayfield City of Roseville - AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098 Office From fergdawgster at mykolab.com Wed Jul 8 17:06:06 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 8 Jul 2015 10:06:06 -0700 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <559D519A.6080904@mykolab.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> Message-ID: <559D587E.5080900@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 NYSE: "The issue we are experiencing is an internal technical issue and is not the result of a cyber breach." https://twitter.com/NYSE/status/618818929906085888 United Air statement CNBC: ?An issue with a router degraded network connectivity for various applications. We fixed the router." https://twitter.com/barronstechblog/status/618816643821633536 - - ferg On 7/8/2015 9:36 AM, Paul Ferguson wrote: > All completely coincidental networking issues, not related to > anything malicious. > > - ferg > > > On 7/8/2015 9:26 AM, Matthew Huff wrote: > >> Hmmm, > >> Wall Street Journal and NYSE both down?. > >> WSJ has a static page up? > >> DDOS ??? > > > >>> On Jul 8, 2015, at 10:51 AM, Patrick W. Gilmore >>> wrote: >>> >>> >>> Lifted as of 0920 EDT. >>> >>> >>> rounded-due-to-computer-issues/?intcmp=latestnews> >>> >>> >>> > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWdWH4ACgkQKJasdVTchbJ5igEAvN+3RUYSzrk1NBimcLe72CfB 9fPw1FfS6kApm0DvZTsA/Aj5h/qw75oNEeVwJhj/TI8txcjMhIuzQS1NG9Iboj3K =fcv/ -----END PGP SIGNATURE----- From hugo at slabnet.com Wed Jul 8 17:11:02 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 8 Jul 2015 10:11:02 -0700 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: Message-ID: <20150708171102.GL24396@bamboo.slabnet.com> On Wed 2015-Jul-08 16:58:24 +0000, Mark Mayfield wrote: >Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. > >Another pair running the same code had the primary crash and fail in the same time window. > >So, three crashes in 4 hours in our environment. > >Open a TAC case on one of these for post-mortem analysis, and they interpreted the crash dump to point at a DOS bug first published in Oct. > >The very interesting thing; on the phone the TAC engineer said this was "the 10th one of these I've dealt with this morning". > >Here's the bug they reference: >https://tools.cisco.com/bugsearch/bug/CSCul36176/?reffering_site=dumpcr > >Anyone else have observations to add on this? Not sure about ASA-specific DoS and the bug you're pointing at, but we saw some NTP reflection this morning. Then there's the WSJ, NYSE, and UAL from this morning as well. Rough day on the internets? > >Mark Mayfield >City of Roseville - AS 54371 >Network Systems Engineer > >2660 Civic Center Drive >Roseville, MN 55113 >651-792-7098 Office > -- Hugo hugo at slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From rdrake at direcpath.com Wed Jul 8 17:13:40 2015 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 8 Jul 2015 13:13:40 -0400 Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: <201507072139.t67Ld1ZL075222@aurora.sol.net> References: <201507072139.t67Ld1ZL075222@aurora.sol.net> Message-ID: <559D5A44.8040409@direcpath.com> On 7/7/2015 5:39 PM, Joe Greco wrote: > Unclear at best. The way it is implemented, the user has the potential > to go either way. A network might not want the user to have the > choice, clearly, but there is certainly a subset of users who will opt > out of the feature and I cannot see how those would be in violation of > any sane network usage policy. It's certainly a mess in any case. Now that windows mobile and desktop versions are converging, I doubt there is a way to really tell if a device is a PC or a phone or a tablet. Some network administrators banned mobile phones from wifi connections because of Google's password storage violating their security policy. Now administrators don't even get that knob. We could fix it in a couple of ways (or, they could fix it.. depending on who pushes around money and if anyone cares enough to bother): 1. Wifi sends password policy during handshaking. If you save passwords you aren't allowed to connect here (or, you aren't allowed to backup/share this password) but we will allow the user to connect. This can be transparent to the user and handled by the OS.* 2. The client device sends "I am configured to backup/share passwords" to the wifi. This allows the AP to either deny the user outright, or redirect them to a page explaining what is wrong or whatever. This might be accomplished via DHCP option if we want to keep it all in software. * The fact that we need an IEEE level fix for a security problem created by Google and then propagated by Microsoft is just pathetic. These are two companies that should know better than to do this. > > ... JG From mel at beckman.org Wed Jul 8 17:15:20 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 8 Jul 2015 17:15:20 +0000 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <559D587E.5080900@mykolab.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com>,<559D587E.5080900@mykolab.com> Message-ID: It's important to not form an opinion too early, especially anyone involved with forensic analysis of these systems. This is a classic fault in amateur investigation: an early opinion will lead you into confirmation bias, irrationally accepting data agreeing with your opinions and rejecting that disproving it. -mel beckman > On Jul 8, 2015, at 10:07 AM, Paul Ferguson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > NYSE: "The issue we are experiencing is an internal technical issue > and is not the result of a cyber breach." > > https://twitter.com/NYSE/status/618818929906085888 > > United Air statement CNBC: ?An issue with a router degraded network > connectivity for various applications. We fixed the router." > > https://twitter.com/barronstechblog/status/618816643821633536 > > - - ferg > >> On 7/8/2015 9:36 AM, Paul Ferguson wrote: >> >> All completely coincidental networking issues, not related to >> anything malicious. >> >> - ferg >> >> >>> On 7/8/2015 9:26 AM, Matthew Huff wrote: >>> >>> Hmmm, >> >>> Wall Street Journal and NYSE both down?. >> >>> WSJ has a static page up? >> >>> DDOS ??? >> >> >> >>>> On Jul 8, 2015, at 10:51 AM, Patrick W. Gilmore >>>> wrote: >>>> >>>> >>>> Lifted as of 0920 EDT. >>>> >>>> g >> >>>> > rounded-due-to-computer-issues/?intcmp=latestnews> >>>> >>>> >>>> >> > > - -- > Paul Ferguson > PGP Public Key ID: 0x54DC85B2 > Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 > > - -- > Paul Ferguson > PGP Public Key ID: 0x54DC85B2 > Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EAREIAAYFAlWdWH4ACgkQKJasdVTchbJ5igEAvN+3RUYSzrk1NBimcLe72CfB > 9fPw1FfS6kApm0DvZTsA/Aj5h/qw75oNEeVwJhj/TI8txcjMhIuzQS1NG9Iboj3K > =fcv/ > -----END PGP SIGNATURE----- From frnog at shrd.fr Wed Jul 8 17:15:49 2015 From: frnog at shrd.fr (Michel Luczak) Date: Wed, 8 Jul 2015 19:15:49 +0200 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: Message-ID: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> > On 08 Jul 2015, at 18:58, Mark Mayfield wrote: > > Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. Not sure it?s related but I?ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. Regards, Michel From rdobbins at arbor.net Wed Jul 8 17:17:34 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 09 Jul 2015 00:17:34 +0700 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: Message-ID: <6BB7E84B-E5C7-40F2-AD90-6075E491819D@arbor.net> On 8 Jul 2015, at 23:58, Mark Mayfield wrote: > Come in this morning to find one failover pair of ASA's had the > primary crash and failover, then a couple hours later, the secondary > crash and failover, back to the primary. See this preso: ----------------------------------- Roland Dobbins From fergdawgster at mykolab.com Wed Jul 8 17:18:47 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 8 Jul 2015 10:18:47 -0700 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> Message-ID: <559D5B77.7010402@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Given that the Internet is held together with paper clips, bailing twine, and bubblegum, I'd prefer to take theses organizations' initial word for the fact that there is nothing obviously malicious in these outages. The mainstream press, on the other hand, seems to want it to be a hack or data breach or... something other than a "glitch". :-) - - ferg On 7/8/2015 10:15 AM, Mel Beckman wrote: > It's important to not form an opinion too early, especially anyone > involved with forensic analysis of these systems. This is a > classic fault in amateur investigation: an early opinion will lead > you into confirmation bias, irrationally accepting data agreeing > with your opinions and rejecting that disproving it. > > -mel beckman > >> On Jul 8, 2015, at 10:07 AM, Paul Ferguson >> wrote: >> > NYSE: "The issue we are experiencing is an internal technical issue > and is not the result of a cyber breach." > > https://twitter.com/NYSE/status/618818929906085888 > > United Air statement CNBC: ?An issue with a router degraded network > connectivity for various applications. We fixed the router." > > https://twitter.com/barronstechblog/status/618816643821633536 > > - ferg > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWdW3cACgkQKJasdVTchbLr/wD/aBNnLFv+MU+QI1ja7dd9LiSN Zkum4lSIutxFn1NmaYoBAIgO/Ig7FxD4vRzQK8bUturn4YGw9FXMT+EzVTKhIbVG =/yYp -----END PGP SIGNATURE----- From mhuff at ox.com Wed Jul 8 17:42:52 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 8 Jul 2015 17:42:52 +0000 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <559D5B77.7010402@mykolab.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> Message-ID: <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> Given that the technical resources at the NYSE are significant and the lengthy duration of the outage, I believe this is more serious than is being reported. OTOH, the fact that the market is now mostly decentralized and instruments are multiply listed, the impact of the NYSE is much less serious than it used to be. > On Jul 8, 2015, at 1:18 PM, Paul Ferguson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Given that the Internet is held together with paper clips, bailing > twine, and bubblegum, I'd prefer to take theses organizations' initial > word for the fact that there is nothing obviously malicious in these > outages. > > The mainstream press, on the other hand, seems to want it to be a hack > or data breach or... something other than a "glitch". :-) > > - - ferg > > > On 7/8/2015 10:15 AM, Mel Beckman wrote: > >> It's important to not form an opinion too early, especially anyone >> involved with forensic analysis of these systems. This is a >> classic fault in amateur investigation: an early opinion will lead >> you into confirmation bias, irrationally accepting data agreeing >> with your opinions and rejecting that disproving it. >> >> -mel beckman >> >>> On Jul 8, 2015, at 10:07 AM, Paul Ferguson >>> wrote: >>> >> NYSE: "The issue we are experiencing is an internal technical issue >> and is not the result of a cyber breach." >> >> https://twitter.com/NYSE/status/618818929906085888 >> >> United Air statement CNBC: ?An issue with a router degraded network >> connectivity for various applications. We fixed the router." >> >> https://twitter.com/barronstechblog/status/618816643821633536 >> >> - ferg >> > > > - -- > Paul Ferguson > PGP Public Key ID: 0x54DC85B2 > Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EAREIAAYFAlWdW3cACgkQKJasdVTchbLr/wD/aBNnLFv+MU+QI1ja7dd9LiSN > Zkum4lSIutxFn1NmaYoBAIgO/Ig7FxD4vRzQK8bUturn4YGw9FXMT+EzVTKhIbVG > =/yYp > -----END PGP SIGNATURE----- From Mark.Mayfield at cityofroseville.com Wed Jul 8 17:43:46 2015 From: Mark.Mayfield at cityofroseville.com (Mark Mayfield) Date: Wed, 8 Jul 2015 17:43:46 +0000 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <6BB7E84B-E5C7-40F2-AD90-6075E491819D@arbor.net> References: <6BB7E84B-E5C7-40F2-AD90-6075E491819D@arbor.net> Message-ID: Thank you sir. I read your presentation quite some time ago, probably one of the first times you posted to the list. It has definitely informed many of my design processes; particularly with regard to server publishing, and been a major part of my supporting documentation in arguments with others at my organization over the last few years. Of course, these particular ASA implementations are for law enforcement applications, so we are mandated to implement in ways that auditors from the state and federal agencies approve of. However, this makes me consider the need to more aggressively ACL inbound traffic at the router level before these particular firewalls, which I can do, and may help mitigate such events, so thank you for the reminder! Mark Mayfield City of Roseville - AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098????? Office -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Wednesday, July 08, 2015 12:18 To: nanog at nanog.org Subject: Re: Possible Sudden Uptick in ASA DOS? On 8 Jul 2015, at 23:58, Mark Mayfield wrote: > Come in this morning to find one failover pair of ASA's had the > primary crash and failover, then a couple hours later, the secondary > crash and failover, back to the primary. See this preso: ----------------------------------- Roland Dobbins From Kirill.Klimakhin at COREBTS.com Wed Jul 8 17:45:55 2015 From: Kirill.Klimakhin at COREBTS.com (Klimakhin, Kirill) Date: Wed, 8 Jul 2015 17:45:55 +0000 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: Message-ID: This is pretty scary when you take into account that the NYSE is still down. Kirill Klimakhin Principal Consultant 120 Seventh Street Suite 202 Garden City, NY 11530 (C) 631-707-3303 (F) 631-982-0174 Kirill.Klimakhin at corebts.com www.corebts.com -----Original Message----- From: NANOG [mailto:nanog-bounces+kirill.klimakhin=corebts.com at nanog.org] On Behalf Of Mark Mayfield Sent: Wednesday, July 08, 2015 12:58 PM To: nanog at nanog.org Subject: Possible Sudden Uptick in ASA DOS? Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. Another pair running the same code had the primary crash and fail in the same time window. So, three crashes in 4 hours in our environment. Open a TAC case on one of these for post-mortem analysis, and they interpreted the crash dump to point at a DOS bug first published in Oct. The very interesting thing; on the phone the TAC engineer said this was "the 10th one of these I've dealt with this morning". Here's the bug they reference: https://tools.cisco.com/bugsearch/bug/CSCul36176/?reffering_site=dumpcr Anyone else have observations to add on this? Mark Mayfield City of Roseville - AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098 Office ________________________________ Important Notice: This email message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Core BTS. Core BTS specifically disclaims liability for any damage caused by any virus transmitted by this email. From shane at ronan-online.com Wed Jul 8 17:46:19 2015 From: shane at ronan-online.com (Shane Ronan) Date: Wed, 8 Jul 2015 13:46:19 -0400 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> Message-ID: I think you are over estimating the technical resources at NYSE. On Jul 8, 2015 1:44 PM, "Matthew Huff" wrote: > Given that the technical resources at the NYSE are significant and the > lengthy duration of the outage, I believe this is more serious than is > being reported. OTOH, the fact that the market is now mostly decentralized > and instruments are multiply listed, the impact of the NYSE is much less > serious than it used to be. > > > > On Jul 8, 2015, at 1:18 PM, Paul Ferguson > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Given that the Internet is held together with paper clips, bailing > > twine, and bubblegum, I'd prefer to take theses organizations' initial > > word for the fact that there is nothing obviously malicious in these > > outages. > > > > The mainstream press, on the other hand, seems to want it to be a hack > > or data breach or... something other than a "glitch". :-) > > > > - - ferg > > > > > > On 7/8/2015 10:15 AM, Mel Beckman wrote: > > > >> It's important to not form an opinion too early, especially anyone > >> involved with forensic analysis of these systems. This is a > >> classic fault in amateur investigation: an early opinion will lead > >> you into confirmation bias, irrationally accepting data agreeing > >> with your opinions and rejecting that disproving it. > >> > >> -mel beckman > >> > >>> On Jul 8, 2015, at 10:07 AM, Paul Ferguson > >>> wrote: > >>> > >> NYSE: "The issue we are experiencing is an internal technical issue > >> and is not the result of a cyber breach." > >> > >> https://twitter.com/NYSE/status/618818929906085888 > >> > >> United Air statement CNBC: ?An issue with a router degraded network > >> connectivity for various applications. We fixed the router." > >> > >> https://twitter.com/barronstechblog/status/618816643821633536 > >> > >> - ferg > >> > > > > > > - -- > > Paul Ferguson > > PGP Public Key ID: 0x54DC85B2 > > Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2 > > > > iF4EAREIAAYFAlWdW3cACgkQKJasdVTchbLr/wD/aBNnLFv+MU+QI1ja7dd9LiSN > > Zkum4lSIutxFn1NmaYoBAIgO/Ig7FxD4vRzQK8bUturn4YGw9FXMT+EzVTKhIbVG > > =/yYp > > -----END PGP SIGNATURE----- > > From Valdis.Kletnieks at vt.edu Wed Jul 8 17:55:43 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 08 Jul 2015 13:55:43 -0400 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: Your message of "Wed, 08 Jul 2015 17:42:52 -0000." <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> Message-ID: <10601.1436378143@turing-police.cc.vt.edu> On Wed, 08 Jul 2015 17:42:52 -0000, Matthew Huff said: > Given that the technical resources at the NYSE are significant and the > lengthy duration of the outage, I believe this is more serious than is being > reported. My personal, totally zero-info suspicion: Some chuckleheaded NOC banana-eater made a typo, and discovered an entirely new class of wondrous BGP-wedgie style "We know how we got here, but how do we get back?" network misbehaviors.... (Such things have happened before - like the med school a few years ago that extended their ethernet spanning tree one hop too far, and discovered that merely removing the one hop too far wasn't sufficient to let it come back up...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From dciccaro at cisco.com Wed Jul 8 18:01:56 2015 From: dciccaro at cisco.com (Dario Ciccarone) Date: Wed, 08 Jul 2015 14:01:56 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: Message-ID: <559D6594.4040106@cisco.com> NANOG members: Hi there. This is Dario Ciccarone from the Cisco PSIRT - the Product Security Incident Response Team. This is to acknowledge we're aware of this issue, and we're working with all the appropriate parties. Indeed, it seems the culprit is Cisco bug ID CSCul36176 - which was released as part of the Cisco Security Advisory "Multiple Vulnerabilities in Cisco ASA Software ", which was published on October 8th, 2014. The full advisory is available at the following URL: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141008-asa As I said, the Cisco PSIRT is working with the Cisco Technical Assistance Center on this matter, and we're analyzing the available information. The advisory will be updated to reflect the fact we're seeing active exploitation of this issue. NANOG members are welcome to contact us at psirt at cisco.com if they have any additional questions or concerns, or any information relevant to this issue. Thanks, Dario On 7/8/15 12:58 PM, Mark Mayfield wrote: > Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. > > Another pair running the same code had the primary crash and fail in the same time window. > > So, three crashes in 4 hours in our environment. > > Open a TAC case on one of these for post-mortem analysis, and they interpreted the crash dump to point at a DOS bug first published in Oct. > > The very interesting thing; on the phone the TAC engineer said this was "the 10th one of these I've dealt with this morning". > > Here's the bug they reference: > https://tools.cisco.com/bugsearch/bug/CSCul36176/?reffering_site=dumpcr > > Anyone else have observations to add on this? > > Mark Mayfield > City of Roseville - AS 54371 > Network Systems Engineer > > 2660 Civic Center Drive > Roseville, MN 55113 > 651-792-7098 Office > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From mhuff at ox.com Wed Jul 8 18:02:19 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 8 Jul 2015 18:02:19 +0000 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> Message-ID: I did say significant?not brilliant :) Still, it?s possible that Valdis is correct, something got changed that wasn?t easy to undo. Might be a combination of network/software changes that will require significant overnight downtime. On Jul 8, 2015, at 1:46 PM, Shane Ronan > wrote: I think you are over estimating the technical resources at NYSE. On Jul 8, 2015 1:44 PM, "Matthew Huff" > wrote: Given that the technical resources at the NYSE are significant and the lengthy duration of the outage, I believe this is more serious than is being reported. OTOH, the fact that the market is now mostly decentralized and instruments are multiply listed, the impact of the NYSE is much less serious than it used to be. > On Jul 8, 2015, at 1:18 PM, Paul Ferguson > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Given that the Internet is held together with paper clips, bailing > twine, and bubblegum, I'd prefer to take theses organizations' initial > word for the fact that there is nothing obviously malicious in these > outages. > > The mainstream press, on the other hand, seems to want it to be a hack > or data breach or... something other than a "glitch". :-) > > - - ferg > > > On 7/8/2015 10:15 AM, Mel Beckman wrote: > >> It's important to not form an opinion too early, especially anyone >> involved with forensic analysis of these systems. This is a >> classic fault in amateur investigation: an early opinion will lead >> you into confirmation bias, irrationally accepting data agreeing >> with your opinions and rejecting that disproving it. >> >> -mel beckman >> >>> On Jul 8, 2015, at 10:07 AM, Paul Ferguson >>> > wrote: >>> >> NYSE: "The issue we are experiencing is an internal technical issue >> and is not the result of a cyber breach." >> >> https://twitter.com/NYSE/status/618818929906085888 >> >> United Air statement CNBC: ?An issue with a router degraded network >> connectivity for various applications. We fixed the router." >> >> https://twitter.com/barronstechblog/status/618816643821633536 >> >> - ferg >> > > > - -- > Paul Ferguson > PGP Public Key ID: 0x54DC85B2 > Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EAREIAAYFAlWdW3cACgkQKJasdVTchbLr/wD/aBNnLFv+MU+QI1ja7dd9LiSN > Zkum4lSIutxFn1NmaYoBAIgO/Ig7FxD4vRzQK8bUturn4YGw9FXMT+EzVTKhIbVG > =/yYp > -----END PGP SIGNATURE----- From twilliam at rackspace.com Wed Jul 8 18:22:37 2015 From: twilliam at rackspace.com (Todd Williams) Date: Wed, 8 Jul 2015 13:22:37 -0500 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: Message-ID: <20150708182237.GF27272@twilliams> We call all relax. The Commander-in-Chief of the USA has declared this to be a technical glitch, and not a security breach or attack. -- Todd Williams Network Engineer Tactical Network Operations Rackspace Hosting On Wed, Jul 08, 2015 at 05:45:55PM +0000, Klimakhin, Kirill wrote: > This is pretty scary when you take into account that the NYSE is still down. > > > > Kirill Klimakhin > Principal Consultant > 120 Seventh Street > Suite 202 > Garden City, NY 11530 > (C) 631-707-3303 > (F) 631-982-0174 > Kirill.Klimakhin at corebts.com > www.corebts.com > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+kirill.klimakhin=corebts.com at nanog.org] On Behalf Of Mark Mayfield > Sent: Wednesday, July 08, 2015 12:58 PM > To: nanog at nanog.org > Subject: Possible Sudden Uptick in ASA DOS? > > Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. > > Another pair running the same code had the primary crash and fail in the same time window. > > So, three crashes in 4 hours in our environment. > > Open a TAC case on one of these for post-mortem analysis, and they interpreted the crash dump to point at a DOS bug first published in Oct. > > The very interesting thing; on the phone the TAC engineer said this was "the 10th one of these I've dealt with this morning". > > Here's the bug they reference: > https://tools.cisco.com/bugsearch/bug/CSCul36176/?reffering_site=dumpcr > > Anyone else have observations to add on this? > > Mark Mayfield > City of Roseville - AS 54371 > Network Systems Engineer > > 2660 Civic Center Drive > Roseville, MN 55113 > 651-792-7098 Office > > > ________________________________ > Important Notice: This email message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Core BTS. Core BTS specifically disclaims liability for any damage caused by any virus transmitted by this email. > From rbf+nanog at panix.com Wed Jul 8 18:33:21 2015 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 8 Jul 2015 13:33:21 -0500 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <10601.1436378143@turing-police.cc.vt.edu> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> <10601.1436378143@turing-police.cc.vt.edu> Message-ID: <20150708183321.GA21478@panix.com> On Wed, Jul 08, 2015 at 01:55:43PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Wed, 08 Jul 2015 17:42:52 -0000, Matthew Huff said: > > Given that the technical resources at the NYSE are significant and > > the lengthy duration of the outage, I believe this is more serious > > than is being reported. > > My personal, totally zero-info suspicion: > > Some chuckleheaded NOC banana-eater made a typo, and discovered an > entirely new class of wondrous BGP-wedgie style "We know how we got > here, but how do we get back?" network misbehaviors.... We don't know how long the underlying problem lasted, and how much of the continued outage time is dealing with the logistics of restarting trading mid-day. Completely stopping and then restarting trading mid-day is likely not a quick process even if the underlying technical issue is immediately resolved. > (Such things have happened before - like the med school a few years ago that > extended their ethernet spanning tree one hop too far, and discovered that > merely removing the one hop too far wasn't sufficient to let it come back up...) No, but picking a bridge in the center, giving it priority sufficient for it to become root, and then configuring timers[1] that would support a much larger than default diameter, possibly followed by some reboots, probably would have. >From what has been publicly stated, they likely took a much longer and more complicated path to service restoration than was strictly necessary. (I have no non-public information on that event. There may be good reasons, technical or otherwise, why that wasn't the chosen solution.) -- Brett [1] You only have to configure them on the root; non-root bridges use what root sends out, not what they ahve configured. From maxtul at netassist.ua Wed Jul 8 18:44:39 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 08 Jul 2015 21:44:39 +0300 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> Message-ID: <559D6F97.9060309@netassist.ua> I noticed there are days when different nets has no links with each other became faultly. It magically happens. We usually stop all our planned works this days. On 08.07.15 19:50, Matthew Huff wrote: > Once is happenstance > Twice is coincidence > Three times is enemy action? > > Serious, could all be just everyone having a bad day. On the other hand, the WSJ has to deal with DOS/DDOS all the time, and usually if the NYSE has issues, it?s normally on a Monday. > > > >> On Jul 8, 2015, at 12:36 PM, Paul Ferguson wrote: >> > All completely coincidental networking issues, not related to anything > malicious. > > - ferg > > > On 7/8/2015 9:26 AM, Matthew Huff wrote: > >>>> Hmmm, >>>> >>>> Wall Street Journal and NYSE both down?. >>>> >>>> WSJ has a static page up? >>>> >>>> DDOS ??? >>>> >>>> >>>> >>>>> On Jul 8, 2015, at 10:51 AM, Patrick W. Gilmore >>>>> wrote: >>>>> >>>>> >>>>> Lifted as of 0920 EDT. >>>>> >>>>> rounded-due-to-computer-issues/?intcmp=latestnews> >>>>> >>>>> >>>>> > From mark.tinka at seacom.mu Wed Jul 8 18:47:37 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 Jul 2015 20:47:37 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> Message-ID: <559D7049.2010102@seacom.mu> On 8/Jul/15 17:59, Mel Beckman wrote: > Greg, > > After investigating what a previous poster said about Cisco and Juniper, I'm getting the feeling that not all major impediments to running MPLS over IPv6-only networks have been addressed. > > Your comment mentions LDP IPv6 support. Do you now handle all the major gaps identified the the IETF MPLS IPv6 Gap Analysis (RFC7439) from this last January? > > https://tools.ietf.org/html/rfc7439#section-3 > > It seems like their are still gaps in the MPLS spec itself before IPv6 has parity with IPv4 in MPLS. The LDPv6 support is just the control plane portion to get labels assigned to IPv6 addresses. This should get you basic forwarding of encapsulation and forwarding of IPv6 traffic in MPLS. The immediate use-case would be removal of IPv6 BGP routing in the core, if that is your thing. Otherwise, yes, there are still a bunch of MPLS gaps that need to be fixed for those additional services to run natively over an IPv6-only network. Baby steps... Mark. From jra at baylink.com Wed Jul 8 18:56:27 2015 From: jra at baylink.com (Jay Ashworth) Date: Wed, 08 Jul 2015 14:56:27 -0400 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <559D5B77.7010402@mykolab.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> Message-ID: <3D6FF3DA-722A-4710-8B83-2EEA3DD53A94@baylink.com> UA, WSJ /and/ NYSE all in the same day? Once is an accident; twice is a coincidence... Three times is enemy action. On July 8, 2015 1:18:47 PM EDT, Paul Ferguson wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >Given that the Internet is held together with paper clips, bailing >twine, and bubblegum, I'd prefer to take theses organizations' initial >word for the fact that there is nothing obviously malicious in these >outages. > >The mainstream press, on the other hand, seems to want it to be a hack >or data breach or... something other than a "glitch". :-) > >- - ferg > > >On 7/8/2015 10:15 AM, Mel Beckman wrote: > >> It's important to not form an opinion too early, especially anyone >> involved with forensic analysis of these systems. This is a >> classic fault in amateur investigation: an early opinion will lead >> you into confirmation bias, irrationally accepting data agreeing >> with your opinions and rejecting that disproving it. >> >> -mel beckman >> >>> On Jul 8, 2015, at 10:07 AM, Paul Ferguson >>> wrote: >>> >> NYSE: "The issue we are experiencing is an internal technical issue >> and is not the result of a cyber breach." >> >> https://twitter.com/NYSE/status/618818929906085888 >> >> United Air statement CNBC: ?An issue with a router degraded network >> connectivity for various applications. We fixed the router." >> >> https://twitter.com/barronstechblog/status/618816643821633536 >> >> - ferg >> > > >- -- >Paul Ferguson >PGP Public Key ID: 0x54DC85B2 >Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2 > >iF4EAREIAAYFAlWdW3cACgkQKJasdVTchbLr/wD/aBNnLFv+MU+QI1ja7dd9LiSN >Zkum4lSIutxFn1NmaYoBAIgO/Ig7FxD4vRzQK8bUturn4YGw9FXMT+EzVTKhIbVG >=/yYp >-----END PGP SIGNATURE----- -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From mhuff at ox.com Wed Jul 8 19:02:01 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 8 Jul 2015 19:02:01 +0000 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <20150708183321.GA21478@panix.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> <10601.1436378143@turing-police.cc.vt.edu> <20150708183321.GA21478@panix.com> Message-ID: <5B17ED50-A8E5-464F-A889-FE2C35035147@ox.com> Traders on the floor are being told that it?s a software glitch from new software that was rolled out Tuesday night. Nothing official has been said. The only thing I know for sure is that if the NYSE was hacked, they wouldn?t tell anyone the details for a long time, if ever. The impact of the NYSE being down is much less significant than it used to be since most stocks are multiple-listed on other exchanges. The lack of information through official channels is unusual though. In previous situations, there has been at least a little hand-holding. So far, nada. In fact, other than financial service provider?s emails, there has been no emails so far today from the NYSE, including the announcement of resumption of service. According the the NYSE web page, trading will resume at 3:05pm EST today with primary specialist, and 3:10 for everyone. > On Jul 8, 2015, at 2:33 PM, Brett Frankenberger wrote: > > On Wed, Jul 08, 2015 at 01:55:43PM -0400, Valdis.Kletnieks at vt.edu wrote: >> On Wed, 08 Jul 2015 17:42:52 -0000, Matthew Huff said: > >>> Given that the technical resources at the NYSE are significant and >>> the lengthy duration of the outage, I believe this is more serious >>> than is being reported. >> >> My personal, totally zero-info suspicion: >> >> Some chuckleheaded NOC banana-eater made a typo, and discovered an >> entirely new class of wondrous BGP-wedgie style "We know how we got >> here, but how do we get back?" network misbehaviors.... > > We don't know how long the underlying problem lasted, and how much of > the continued outage time is dealing with the logistics of restarting > trading mid-day. Completely stopping and then restarting trading > mid-day is likely not a quick process even if the underlying technical > issue is immediately resolved. > >> (Such things have happened before - like the med school a few years ago that >> extended their ethernet spanning tree one hop too far, and discovered that >> merely removing the one hop too far wasn't sufficient to let it come back up...) > > No, but picking a bridge in the center, giving it priority sufficient > for it to become root, and then configuring timers[1] that would > support a much larger than default diameter, possibly followed by some > reboots, probably would have. > > From what has been publicly stated, they likely took a much longer and > more complicated path to service restoration than was strictly > necessary. (I have no non-public information on that event. There may > be good reasons, technical or otherwise, why that wasn't the chosen > solution.) > > -- Brett > > [1] You only have to configure them on the root; non-root bridges use > what root sends out, not what they ahve configured. From rdobbins at arbor.net Wed Jul 8 19:24:32 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 09 Jul 2015 02:24:32 +0700 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: <6BB7E84B-E5C7-40F2-AD90-6075E491819D@arbor.net> Message-ID: <4C18B149-940C-4DE0-932E-8848C61E631D@arbor.net> On 9 Jul 2015, at 0:43, Mark Mayfield wrote: > However, this makes me consider the need to more aggressively ACL > inbound traffic at the router level before these particular firewalls, > which I can do, and may help mitigate such events, Spot-on - reduce the state-surface as much as possible. > so thank you for the reminder! Sorry for the repeat, but glad the preso was helpful! ;> ----------------------------------- Roland Dobbins From patrick at ianai.net Wed Jul 8 19:31:06 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 8 Jul 2015 15:31:06 -0400 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <3D6FF3DA-722A-4710-8B83-2EEA3DD53A94@baylink.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <3D6FF3DA-722A-4710-8B83-2EEA3DD53A94@baylink.com> Message-ID: <3DE44648-03EB-454B-9E6B-CC9AA2E2D4EE@ianai.net> I?m with Ferg-dog. I can?t tell you the number of times someone (yes, including me) has designed, purchased, and installed a system with multiple backups, failovers, redundancies, etc., and some vital piece fails in a weird way which sends the whole thing into a tailspin. Taking UA as an example, since we have the most information (FSVO ?most?), namely it was a ?bad router?. Let?s assume they had multiple routers configured with VRRP, BGP, OSPF, and an alphabet soup of other ways to detect and route-around failures. Now further assume one of those routers has a software or hardware bug which doesn?t take the router out of service, but leaves it up, replying to pings, answer SNMP polls, speaking BGP or OSPF, sending VRRP hellos, etc., etc. - but also eats half of all packets going _through_ the router. That can happen, I?ve seen it first hand. All those redundant systems do nothing, since the ?bad router? is doing everything a good router would do. The systems designed to catch such problems all think things are fine, but they are not. Is it an attack? No, it?s bad luck. Now some will claim - and perhaps rightfully - that UA should have systems which monitor for exactly this type of failure as well. Perhaps they should have, or perhaps the problem was nothing like what I explained. Either way, the point still stands that a company can have had multiple redundancies in place, but still experienced a failure mode which caused exactly the problem described. At this point, we move on to: ?All three simultaneously?!? NO WAY!!? To which I would point out they were not simultaneous. UA was back up before NYSE went down. But even if they were simultaneous, sometimes stuff happens. The human mind is very good at seeing connections, even when there are none. Absent other evidence, I?m going to believe the companies? public statements that this was not a hack. Perhaps I am being naive, but as I said, absent other evidence, it is a perfectly plausible explanation. -- TTFN, patrick > On Jul 08, 2015, at 14:56 , Jay Ashworth wrote: > > UA, WSJ /and/ NYSE all in the same day? > > Once is an accident; twice is a coincidence... > > Three times is enemy action. > > On July 8, 2015 1:18:47 PM EDT, Paul Ferguson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Given that the Internet is held together with paper clips, bailing >> twine, and bubblegum, I'd prefer to take theses organizations' initial >> word for the fact that there is nothing obviously malicious in these >> outages. >> >> The mainstream press, on the other hand, seems to want it to be a hack >> or data breach or... something other than a "glitch". :-) >> >> - - ferg >> >> >> On 7/8/2015 10:15 AM, Mel Beckman wrote: >> >>> It's important to not form an opinion too early, especially anyone >>> involved with forensic analysis of these systems. This is a >>> classic fault in amateur investigation: an early opinion will lead >>> you into confirmation bias, irrationally accepting data agreeing >>> with your opinions and rejecting that disproving it. >>> >>> -mel beckman >>> >>>> On Jul 8, 2015, at 10:07 AM, Paul Ferguson >>>> wrote: >>>> >>> NYSE: "The issue we are experiencing is an internal technical issue >>> and is not the result of a cyber breach." >>> >>> https://twitter.com/NYSE/status/618818929906085888 >>> >>> United Air statement CNBC: ?An issue with a router degraded network >>> connectivity for various applications. We fixed the router." >>> >>> https://twitter.com/barronstechblog/status/618816643821633536 >>> >>> - ferg >>> >> >> >> - -- >> Paul Ferguson >> PGP Public Key ID: 0x54DC85B2 >> Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iF4EAREIAAYFAlWdW3cACgkQKJasdVTchbLr/wD/aBNnLFv+MU+QI1ja7dd9LiSN >> Zkum4lSIutxFn1NmaYoBAIgO/Ig7FxD4vRzQK8bUturn4YGw9FXMT+EzVTKhIbVG >> =/yYp >> -----END PGP SIGNATURE----- > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From owen at delong.com Wed Jul 8 19:32:15 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jul 2015 12:32:15 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559D7049.2010102@seacom.mu> References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> <559D7049.2010102@seacom.mu> Message-ID: I think the ?THING? that people are starting to worry about is how to deploy a network when you can?t get IPv4 space for it at a reasonable price. Owen > On Jul 8, 2015, at 11:47 , Mark Tinka wrote: > > > > On 8/Jul/15 17:59, Mel Beckman wrote: >> Greg, >> >> After investigating what a previous poster said about Cisco and Juniper, I'm getting the feeling that not all major impediments to running MPLS over IPv6-only networks have been addressed. >> >> Your comment mentions LDP IPv6 support. Do you now handle all the major gaps identified the the IETF MPLS IPv6 Gap Analysis (RFC7439) from this last January? >> >> https://tools.ietf.org/html/rfc7439#section-3 >> >> It seems like their are still gaps in the MPLS spec itself before IPv6 has parity with IPv4 in MPLS. > > The LDPv6 support is just the control plane portion to get labels > assigned to IPv6 addresses. This should get you basic forwarding of > encapsulation and forwarding of IPv6 traffic in MPLS. The immediate > use-case would be removal of IPv6 BGP routing in the core, if that is > your thing. > > Otherwise, yes, there are still a bunch of MPLS gaps that need to be > fixed for those additional services to run natively over an IPv6-only > network. Baby steps... > > Mark. From mel at beckman.org Wed Jul 8 19:37:53 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 8 Jul 2015 19:37:53 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> <559D7049.2010102@seacom.mu>, Message-ID: <95889F21-A4D6-4A6F-8B88-4DF40BBA7414@beckman.org> Owen, Paying for IPv4 space definitely raises the capital requirements for any new provider startup. It's not so bad right now, when deals are plentiful in the $10k to $20k range for /24s. But when a /24 hits $100K, bootstrapping a new ISP will be impossible. -mel beckman > On Jul 8, 2015, at 12:32 PM, Owen DeLong wrote: > > I think the ?THING? that people are starting to worry about is how to deploy a network when you can?t get IPv4 space for it at a reasonable price. > > Owen > >> On Jul 8, 2015, at 11:47 , Mark Tinka wrote: >> >> >> >>> On 8/Jul/15 17:59, Mel Beckman wrote: >>> Greg, >>> >>> After investigating what a previous poster said about Cisco and Juniper, I'm getting the feeling that not all major impediments to running MPLS over IPv6-only networks have been addressed. >>> >>> Your comment mentions LDP IPv6 support. Do you now handle all the major gaps identified the the IETF MPLS IPv6 Gap Analysis (RFC7439) from this last January? >>> >>> https://tools.ietf.org/html/rfc7439#section-3 >>> >>> It seems like their are still gaps in the MPLS spec itself before IPv6 has parity with IPv4 in MPLS. >> >> The LDPv6 support is just the control plane portion to get labels >> assigned to IPv6 addresses. This should get you basic forwarding of >> encapsulation and forwarding of IPv6 traffic in MPLS. The immediate >> use-case would be removal of IPv6 BGP routing in the core, if that is >> your thing. >> >> Otherwise, yes, there are still a bunch of MPLS gaps that need to be >> fixed for those additional services to run natively over an IPv6-only >> network. Baby steps... >> >> Mark. > From jmoore at atcnetworks.net Wed Jul 8 19:38:15 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Wed, 8 Jul 2015 19:38:15 +0000 Subject: Debian RWHOIS Message-ID: Hello guys, What do you use for ARIN resource assignments? I am looking to setup a Debian-based RWHOIS server but don't see much information on it. Joshua Moore Network Engineer ATC Broadband 912.632.3161 - O | 912.218.3720 - M From dwhite at olp.net Wed Jul 8 19:52:44 2015 From: dwhite at olp.net (Dan White) Date: Wed, 8 Jul 2015 14:52:44 -0500 Subject: Debian RWHOIS In-Reply-To: References: Message-ID: <20150708195244.GK3901@dan.olp.net> On 07/08/15?19:38?+0000, Josh Moore wrote: >Hello guys, >What do you use for ARIN resource assignments? I am looking to setup a >Debian-based RWHOIS server but don't see much information on it. As of a couple of years ago when I looked around, there were no recent packaged versions of rwhoisd for Debian. We run a compiled version. -- Dan White From cryptographrix at gmail.com Wed Jul 8 19:53:47 2015 From: cryptographrix at gmail.com (Cryptographrix) Date: Wed, 08 Jul 2015 19:53:47 +0000 Subject: How to build an IPv6-only internal network? Message-ID: Hypothetically, I want to build an internal network that runs just IPv6 and apply stateless ACLs at redundant external connections. How do users access the current v4 address space? From josh at imaginenetworksllc.com Wed Jul 8 19:56:26 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 8 Jul 2015 15:56:26 -0400 Subject: Debian RWHOIS In-Reply-To: <20150708195244.GK3901@dan.olp.net> References: <20150708195244.GK3901@dan.olp.net> Message-ID: I think this is what you're asking for: http://projects.arin.net/rwhois Should be a ./configure && make && make install #per this http://projects.arin.net/rwhois/docs/installation.html Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jul 8, 2015 at 3:52 PM, Dan White wrote: > On 07/08/15 19:38 +0000, Josh Moore wrote: > >> Hello guys, >> > > What do you use for ARIN resource assignments? I am looking to setup a >> Debian-based RWHOIS server but don't see much information on it. >> > > As of a couple of years ago when I looked around, there were no recent > packaged versions of rwhoisd for Debian. We run a compiled version. > > -- > Dan White > From chris.dye at paragon.net Wed Jul 8 19:56:52 2015 From: chris.dye at paragon.net (Christopher Dye) Date: Wed, 8 Jul 2015 19:56:52 +0000 Subject: Debian RWHOIS In-Reply-To: <20150708195244.GK3901@dan.olp.net> References: <20150708195244.GK3901@dan.olp.net> Message-ID: <637d5522a64d4b4698352bea86be2a23@psg-ex2-msp7700.msp.paragon.lcl> I'd recommend you use the official RWHOIS project from ARIN. http://projects.arin.net/rwhois/ It will run after compilation on Debian. Christopher Dye Paragon Solutions Group, Inc.???? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dan White Sent: Wednesday, July 08, 2015 2:53 PM To: Josh Moore Cc: nanog at nanog.org Subject: Re: Debian RWHOIS On 07/08/15?19:38?+0000, Josh Moore wrote: >Hello guys, >What do you use for ARIN resource assignments? I am looking to setup a >Debian-based RWHOIS server but don't see much information on it. As of a couple of years ago when I looked around, there were no recent packaged versions of rwhoisd for Debian. We run a compiled version. -- Dan White -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5669 bytes Desc: not available URL: From jmoore at atcnetworks.net Wed Jul 8 19:58:39 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Wed, 8 Jul 2015 19:58:39 +0000 Subject: Debian RWHOIS In-Reply-To: <637d5522a64d4b4698352bea86be2a23@psg-ex2-msp7700.msp.paragon.lcl> References: <20150708195244.GK3901@dan.olp.net> <637d5522a64d4b4698352bea86be2a23@psg-ex2-msp7700.msp.paragon.lcl> Message-ID: I'm looking more for specific use case examples from the real world. How do you interact with the RWHOIS? Do you use RWHOIS or Email SWIP or RESTful? Joshua Moore Network Engineer ATC Broadband 912.632.3161 - O | 912.218.3720 - M -----Original Message----- From: Christopher Dye [mailto:chris.dye at paragon.net] Sent: Wednesday, July 08, 2015 3:57 PM To: Dan White; Josh Moore Cc: nanog at nanog.org Subject: RE: Debian RWHOIS I'd recommend you use the official RWHOIS project from ARIN. http://projects.arin.net/rwhois/ It will run after compilation on Debian. Christopher Dye Paragon Solutions Group, Inc.???? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dan White Sent: Wednesday, July 08, 2015 2:53 PM To: Josh Moore Cc: nanog at nanog.org Subject: Re: Debian RWHOIS On 07/08/15?19:38?+0000, Josh Moore wrote: >Hello guys, >What do you use for ARIN resource assignments? I am looking to setup a >Debian-based RWHOIS server but don't see much information on it. As of a couple of years ago when I looked around, there were no recent packaged versions of rwhoisd for Debian. We run a compiled version. -- Dan White From shawnl at up.net Wed Jul 8 20:03:49 2015 From: shawnl at up.net (Shawn L) Date: Wed, 8 Jul 2015 16:03:49 -0400 (EDT) Subject: Debian RWHOIS In-Reply-To: References: <20150708195244.GK3901@dan.olp.net> Message-ID: <1436385829.81623806@upnet.mymailsrvr.com> We ran it for a while, then gave up and just updated the info on Arin. -----Original Message----- From: "Josh Luthman" Sent: Wednesday, July 8, 2015 3:56pm To: "Dan White" Cc: "Josh Moore" , "nanog at nanog.org" Subject: Re: Debian RWHOIS I think this is what you're asking for: http://projects.arin.net/rwhois Should be a ./configure && make && make install #per this http://projects.arin.net/rwhois/docs/installation.html Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jul 8, 2015 at 3:52 PM, Dan White wrote: > On 07/08/15 19:38 +0000, Josh Moore wrote: > >> Hello guys, >> > > What do you use for ARIN resource assignments? I am looking to setup a >> Debian-based RWHOIS server but don't see much information on it. >> > > As of a couple of years ago when I looked around, there were no recent > packaged versions of rwhoisd for Debian. We run a compiled version. > > -- > Dan White > From nanog at ics-il.net Wed Jul 8 20:10:55 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 8 Jul 2015 15:10:55 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <95889F21-A4D6-4A6F-8B88-4DF40BBA7414@beckman.org> Message-ID: <2088594836.7773.1436386250464.JavaMail.mhammett@ThunderFuck> Tell a start-up ISP it'll be $10k - $25k for PI IPs and they'll laugh in your face. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" To: "Owen DeLong" Cc: nanog at nanog.org Sent: Wednesday, July 8, 2015 2:37:53 PM Subject: Re: Dual stack IPv6 for IPv4 depletion Owen, Paying for IPv4 space definitely raises the capital requirements for any new provider startup. It's not so bad right now, when deals are plentiful in the $10k to $20k range for /24s. But when a /24 hits $100K, bootstrapping a new ISP will be impossible. -mel beckman > On Jul 8, 2015, at 12:32 PM, Owen DeLong wrote: > > I think the ?THING? that people are starting to worry about is how to deploy a network when you can?t get IPv4 space for it at a reasonable price. > > Owen > >> On Jul 8, 2015, at 11:47 , Mark Tinka wrote: >> >> >> >>> On 8/Jul/15 17:59, Mel Beckman wrote: >>> Greg, >>> >>> After investigating what a previous poster said about Cisco and Juniper, I'm getting the feeling that not all major impediments to running MPLS over IPv6-only networks have been addressed. >>> >>> Your comment mentions LDP IPv6 support. Do you now handle all the major gaps identified the the IETF MPLS IPv6 Gap Analysis (RFC7439) from this last January? >>> >>> https://tools.ietf.org/html/rfc7439#section-3 >>> >>> It seems like their are still gaps in the MPLS spec itself before IPv6 has parity with IPv4 in MPLS. >> >> The LDPv6 support is just the control plane portion to get labels >> assigned to IPv6 addresses. This should get you basic forwarding of >> encapsulation and forwarding of IPv6 traffic in MPLS. The immediate >> use-case would be removal of IPv6 BGP routing in the core, if that is >> your thing. >> >> Otherwise, yes, there are still a bunch of MPLS gaps that need to be >> fixed for those additional services to run natively over an IPv6-only >> network. Baby steps... >> >> Mark. > From jfmezei_nanog at vaxination.ca Wed Jul 8 20:13:31 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 08 Jul 2015 16:13:31 -0400 Subject: Canada'a broadband technoogies Message-ID: <559D846B.8070308@vaxination.ca> The CRTC is embarking on a multi year study/consultation of what to do with our lagging broadband deployment. Just yesterday, the government bragged about a multi milliuon subsidy to give a community 3mbps service. Can't help but to participate ... So I would like some feedback/sanity checks on a few issues. There is of course a large disconnect between marketed speeds and actual capacity and delivered speeds. 1- Satellite internet I am aware of latest generation satellites that provide focused antennas allowing re-use of the same spectrum for different regions. What sort of bandwidth is realistic for service to customers ? Australia's original NBN has 12mbps service planned for those in remote regions via satellite. Is this realistic ? Or is 3mbps really the max that can reliably be expected ? In terms of latency, would the special routers that "proxy" the TCP acks at both ends of the satellite link be commonplace now ? Still custom jobs ? or do modern TCP stacks now deal effectively with very high latency such that streaming data via satellite no longer requires special equipment to use bandwidth effectively ? For other protocols such as UDP etc, is latency an issue to be concerned with ? 2- Underwater fibre. There has been a project to string fibre from Tokyo to London via the canadian arctic. http://arcticfibre.com/ One aspect of this project are landings are various island that have canadian communities (which rely exclusively on satellite for telephone/data). While dumping fibre underwater is common, landing it in arctic areas is less common (think ice pack movement scraping bottom of shores). The folks on web site say they had done research on this. Are there examples where this was done succcesfully ? Or is this still something that is new and untested ? 3- Permafrost Ok, not an issue in USA, but wondering if there is knowledge of string long fibre cables on land that is permafrost (think Dawson City to Inuvik, roughly 700km). Has Russia or other nordic countries done this ? or are microwave link at regular intervals still the only/best way with vew structures built on the unstable ground ? I'd appreciate any insight/opinions on what is realistic and what is pipe dream. From fred at cisco.com Wed Jul 8 20:23:58 2015 From: fred at cisco.com (Fred Baker (fred)) Date: Wed, 8 Jul 2015 20:23:58 +0000 Subject: How to build an IPv6-only internal network? In-Reply-To: References: Message-ID: > On Jul 8, 2015, at 12:53 PM, Cryptographrix wrote: > > Hypothetically, I want to build an internal network that runs just IPv6 and > apply stateless ACLs at redundant external connections. > > How do users access the current v4 address space? There are two short answers: (1) they don't (2) they use NAT64 (RFC 6146/6147) translation https://tools.ietf.org/html/rfc6052 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=41849 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6052) https://tools.ietf.org/html/rfc6146 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=107954 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6146) https://tools.ietf.org/html/rfc6147 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=75103 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6147) https://tools.ietf.org/html/rfc6877 6877 464XLAT: Combination of Stateful and Stateless Translation. M. Mawatari, M. Kawashima, C. Byrne. April 2013. (Format: TXT=31382 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6877) With NAT64, a translator advertises a 96 bit prefix into the IPv6-only network as defined in RFC 6052, and attracts traffic destined to an address within it (which has an IPv4 address jammed into the last 32 bits) to the translator. The DNS translator, when asked for a AAAA record, either has one or doesn't; if it doesn't have one, it concocts a AAAA record from said prefix and the IPv4 address and returns that. The translator extracts the IPv4 address from the destination address, and does a stateful mapping of the IPv6 source address similar to present NAT44 solutions. There are several products on the market. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bmanning at karoshi.com Wed Jul 8 21:11:17 2015 From: bmanning at karoshi.com (manning) Date: Wed, 8 Jul 2015 14:11:17 -0700 Subject: How to build an IPv6-only internal network? In-Reply-To: References: Message-ID: <4C592F25-4C68-4338-9B8C-9CE4018CF7EA@karoshi.com> Over the years, I?ve had pretty good success with the IVI package. RFC 6219 lays out how it works and some folks experiences with v6-only networks. manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 8July2015Wednesday, at 12:53, Cryptographrix wrote: > Hypothetically, I want to build an internal network that runs just IPv6 and > apply stateless ACLs at redundant external connections. > > How do users access the current v4 address space? From geoffk at geoffk.org Wed Jul 8 21:31:59 2015 From: geoffk at geoffk.org (Geoffrey Keating) Date: 08 Jul 2015 14:31:59 -0700 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <3D6FF3DA-722A-4710-8B83-2EEA3DD53A94@baylink.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <3D6FF3DA-722A-4710-8B83-2EEA3DD53A94@baylink.com> Message-ID: Jay Ashworth writes: > UA, WSJ /and/ NYSE all in the same day? > > Once is an accident; twice is a coincidence... > > Three times is enemy action. Or common factors. In this case, I think it's probably enough to point out it's the first Tuesday of the fiscal year. For a 24x7 organization, early Tuesday morning is a good time to do updates; you have support staff available for the rest of the week if anything goes wrong, you can do final planning, checks, and preparation during the day Monday, and it's usually one of the lowest usage times. From dovid at telecurve.com Wed Jul 8 21:40:42 2015 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 8 Jul 2015 17:40:42 -0400 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <5B17ED50-A8E5-464F-A889-FE2C35035147@ox.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> <10601.1436378143@turing-police.cc.vt.edu> <20150708183321.GA21478@panix.com> <5B17ED50-A8E5-464F-A889-FE2C35035147@ox.com> Message-ID: Other than for an emergency repair who roles out a software update in middle of the week? We test, test and then test some more and only then roll out on weekends. Our maintenance window is 00:00 - 01:00 Sunday mornings for sw updates etc. On Wed, Jul 8, 2015 at 3:02 PM, Matthew Huff wrote: > Traders on the floor are being told that it?s a software glitch from new > software that was rolled out Tuesday night. Nothing official has been > said. The only thing I know for sure is that if the NYSE was hacked, they > wouldn?t tell anyone the details for a long time, if ever. > > The impact of the NYSE being down is much less significant than it used to > be since most stocks are multiple-listed on other exchanges. > > The lack of information through official channels is unusual though. In > previous situations, there has been at least a little hand-holding. So far, > nada. In fact, other than financial service provider?s emails, there has > been no emails so far today from the NYSE, including the announcement of > resumption of service. According the the NYSE web page, trading will resume > at 3:05pm EST today with primary specialist, and 3:10 for everyone. > > > > > > On Jul 8, 2015, at 2:33 PM, Brett Frankenberger > wrote: > > > > On Wed, Jul 08, 2015 at 01:55:43PM -0400, Valdis.Kletnieks at vt.edu wrote: > >> On Wed, 08 Jul 2015 17:42:52 -0000, Matthew Huff said: > > > >>> Given that the technical resources at the NYSE are significant and > >>> the lengthy duration of the outage, I believe this is more serious > >>> than is being reported. > >> > >> My personal, totally zero-info suspicion: > >> > >> Some chuckleheaded NOC banana-eater made a typo, and discovered an > >> entirely new class of wondrous BGP-wedgie style "We know how we got > >> here, but how do we get back?" network misbehaviors.... > > > > We don't know how long the underlying problem lasted, and how much of > > the continued outage time is dealing with the logistics of restarting > > trading mid-day. Completely stopping and then restarting trading > > mid-day is likely not a quick process even if the underlying technical > > issue is immediately resolved. > > > >> (Such things have happened before - like the med school a few years ago > that > >> extended their ethernet spanning tree one hop too far, and discovered > that > >> merely removing the one hop too far wasn't sufficient to let it come > back up...) > > > > No, but picking a bridge in the center, giving it priority sufficient > > for it to become root, and then configuring timers[1] that would > > support a much larger than default diameter, possibly followed by some > > reboots, probably would have. > > > > From what has been publicly stated, they likely took a much longer and > > more complicated path to service restoration than was strictly > > necessary. (I have no non-public information on that event. There may > > be good reasons, technical or otherwise, why that wasn't the chosen > > solution.) > > > > -- Brett > > > > [1] You only have to configure them on the root; non-root bridges use > > what root sends out, not what they ahve configured. > > From sean76 at gmail.com Wed Jul 8 21:41:42 2015 From: sean76 at gmail.com (Sean) Date: Wed, 8 Jul 2015 16:41:42 -0500 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <3DE44648-03EB-454B-9E6B-CC9AA2E2D4EE@ianai.net> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <3D6FF3DA-722A-4710-8B83-2EEA3DD53A94@baylink.com> <3DE44648-03EB-454B-9E6B-CC9AA2E2D4EE@ianai.net> Message-ID: I've been in UA's datacenter and while I'm no expert on their setup I can say with some confidence that it's most likely NOT related to anything else going on. I don't want to violate any NDA I may or may not have signed but I think I can safely say its all one big private network. Whatever's happening on the internet or with NYSE has got nothing to do with what is more than likely in this case a big fat BGP clusterfudge like most of these things are. I don't have any inside info or anything just a slightly more educated guess. On Wed, Jul 8, 2015 at 2:31 PM, Patrick W. Gilmore wrote: > I?m with Ferg-dog. > > I can?t tell you the number of times someone (yes, including me) has > designed, purchased, and installed a system with multiple backups, > failovers, redundancies, etc., and some vital piece fails in a weird way > which sends the whole thing into a tailspin. > > Taking UA as an example, since we have the most information (FSVO ?most?), > namely it was a ?bad router?. Let?s assume they had multiple routers > configured with VRRP, BGP, OSPF, and an alphabet soup of other ways to > detect and route-around failures. Now further assume one of those routers > has a software or hardware bug which doesn?t take the router out of > service, but leaves it up, replying to pings, answer SNMP polls, speaking > BGP or OSPF, sending VRRP hellos, etc., etc. - but also eats half of all > packets going _through_ the router. That can happen, I?ve seen it first > hand. > > All those redundant systems do nothing, since the ?bad router? is doing > everything a good router would do. The systems designed to catch such > problems all think things are fine, but they are not. Is it an attack? No, > it?s bad luck. > > Now some will claim - and perhaps rightfully - that UA should have systems > which monitor for exactly this type of failure as well. Perhaps they should > have, or perhaps the problem was nothing like what I explained. Either way, > the point still stands that a company can have had multiple redundancies in > place, but still experienced a failure mode which caused exactly the > problem described. > > > At this point, we move on to: ?All three simultaneously?!? NO WAY!!? To > which I would point out they were not simultaneous. UA was back up before > NYSE went down. But even if they were simultaneous, sometimes stuff > happens. The human mind is very good at seeing connections, even when there > are none. Absent other evidence, I?m going to believe the companies? public > statements that this was not a hack. Perhaps I am being naive, but as I > said, absent other evidence, it is a perfectly plausible explanation. > > -- > TTFN, > patrick > > > > On Jul 08, 2015, at 14:56 , Jay Ashworth wrote: > > > > UA, WSJ /and/ NYSE all in the same day? > > > > Once is an accident; twice is a coincidence... > > > > Three times is enemy action. > > > > On July 8, 2015 1:18:47 PM EDT, Paul Ferguson > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> Given that the Internet is held together with paper clips, bailing > >> twine, and bubblegum, I'd prefer to take theses organizations' initial > >> word for the fact that there is nothing obviously malicious in these > >> outages. > >> > >> The mainstream press, on the other hand, seems to want it to be a hack > >> or data breach or... something other than a "glitch". :-) > >> > >> - - ferg > >> > >> > >> On 7/8/2015 10:15 AM, Mel Beckman wrote: > >> > >>> It's important to not form an opinion too early, especially anyone > >>> involved with forensic analysis of these systems. This is a > >>> classic fault in amateur investigation: an early opinion will lead > >>> you into confirmation bias, irrationally accepting data agreeing > >>> with your opinions and rejecting that disproving it. > >>> > >>> -mel beckman > >>> > >>>> On Jul 8, 2015, at 10:07 AM, Paul Ferguson > >>>> wrote: > >>>> > >>> NYSE: "The issue we are experiencing is an internal technical issue > >>> and is not the result of a cyber breach." > >>> > >>> https://twitter.com/NYSE/status/618818929906085888 > >>> > >>> United Air statement CNBC: ?An issue with a router degraded network > >>> connectivity for various applications. We fixed the router." > >>> > >>> https://twitter.com/barronstechblog/status/618816643821633536 > >>> > >>> - ferg > >>> > >> > >> > >> - -- > >> Paul Ferguson > >> PGP Public Key ID: 0x54DC85B2 > >> Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v2 > >> > >> iF4EAREIAAYFAlWdW3cACgkQKJasdVTchbLr/wD/aBNnLFv+MU+QI1ja7dd9LiSN > >> Zkum4lSIutxFn1NmaYoBAIgO/Ig7FxD4vRzQK8bUturn4YGw9FXMT+EzVTKhIbVG > >> =/yYp > >> -----END PGP SIGNATURE----- > > > > -- > > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > From keiths at neilltech.com Wed Jul 8 21:44:59 2015 From: keiths at neilltech.com (Keith Stokes) Date: Wed, 8 Jul 2015 21:44:59 +0000 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> <10601.1436378143@turing-police.cc.vt.edu> <20150708183321.GA21478@panix.com> <5B17ED50-A8E5-464F-A889-FE2C35035147@ox.com> Message-ID: <853F604B-55A2-4519-9D73-1C64BD2C0981@neilltech.com> Who roles out software in the middle of the week and not on weekends? People who have more business on the weekends than the week, such as retail. On Jul 8, 2015, at 4:40 PM, Dovid Bender > wrote: Other than for an emergency repair who roles out a software update in middle of the week? We test, test and then test some more and only then roll out on weekends. Our maintenance window is 00:00 - 01:00 Sunday mornings for sw updates etc. On Wed, Jul 8, 2015 at 3:02 PM, Matthew Huff > wrote: Traders on the floor are being told that it?s a software glitch from new software that was rolled out Tuesday night. Nothing official has been said. The only thing I know for sure is that if the NYSE was hacked, they wouldn?t tell anyone the details for a long time, if ever. The impact of the NYSE being down is much less significant than it used to be since most stocks are multiple-listed on other exchanges. The lack of information through official channels is unusual though. In previous situations, there has been at least a little hand-holding. So far, nada. In fact, other than financial service provider?s emails, there has been no emails so far today from the NYSE, including the announcement of resumption of service. According the the NYSE web page, trading will resume at 3:05pm EST today with primary specialist, and 3:10 for everyone. On Jul 8, 2015, at 2:33 PM, Brett Frankenberger > wrote: On Wed, Jul 08, 2015 at 01:55:43PM -0400, Valdis.Kletnieks at vt.edu wrote: On Wed, 08 Jul 2015 17:42:52 -0000, Matthew Huff said: Given that the technical resources at the NYSE are significant and the lengthy duration of the outage, I believe this is more serious than is being reported. My personal, totally zero-info suspicion: Some chuckleheaded NOC banana-eater made a typo, and discovered an entirely new class of wondrous BGP-wedgie style "We know how we got here, but how do we get back?" network misbehaviors.... We don't know how long the underlying problem lasted, and how much of the continued outage time is dealing with the logistics of restarting trading mid-day. Completely stopping and then restarting trading mid-day is likely not a quick process even if the underlying technical issue is immediately resolved. (Such things have happened before - like the med school a few years ago that extended their ethernet spanning tree one hop too far, and discovered that merely removing the one hop too far wasn't sufficient to let it come back up...) No, but picking a bridge in the center, giving it priority sufficient for it to become root, and then configuring timers[1] that would support a much larger than default diameter, possibly followed by some reboots, probably would have. From what has been publicly stated, they likely took a much longer and more complicated path to service restoration than was strictly necessary. (I have no non-public information on that event. There may be good reasons, technical or otherwise, why that wasn't the chosen solution.) -- Brett [1] You only have to configure them on the root; non-root bridges use what root sends out, not what they ahve configured. --- Keith Stokes From dovid at telecurve.com Wed Jul 8 21:49:27 2015 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 8 Jul 2015 17:49:27 -0400 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <853F604B-55A2-4519-9D73-1C64BD2C0981@neilltech.com> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> <10601.1436378143@turing-police.cc.vt.edu> <20150708183321.GA21478@panix.com> <5B17ED50-A8E5-464F-A889-FE2C35035147@ox.com> <853F604B-55A2-4519-9D73-1C64BD2C0981@neilltech.com> Message-ID: Well that's a given. I am talking about organizations like the NYSE or MaBell, On Wed, Jul 8, 2015 at 5:44 PM, Keith Stokes wrote: > Who roles out software in the middle of the week and not on weekends? > People who have more business on the weekends than the week, such as > retail. > > On Jul 8, 2015, at 4:40 PM, Dovid Bender wrote: > > Other than for an emergency repair who roles out a software update in > middle of the week? We test, test and then test some more and only then > roll out on weekends. Our maintenance window is 00:00 - 01:00 Sunday > mornings for sw updates etc. > > > On Wed, Jul 8, 2015 at 3:02 PM, Matthew Huff wrote: > > Traders on the floor are being told that it?s a software glitch from new > software that was rolled out Tuesday night. Nothing official has been > said. The only thing I know for sure is that if the NYSE was hacked, they > wouldn?t tell anyone the details for a long time, if ever. > > The impact of the NYSE being down is much less significant than it used to > be since most stocks are multiple-listed on other exchanges. > > The lack of information through official channels is unusual though. In > previous situations, there has been at least a little hand-holding. So far, > nada. In fact, other than financial service provider?s emails, there has > been no emails so far today from the NYSE, including the announcement of > resumption of service. According the the NYSE web page, trading will resume > at 3:05pm EST today with primary specialist, and 3:10 for everyone. > > > > > On Jul 8, 2015, at 2:33 PM, Brett Frankenberger > > wrote: > > > On Wed, Jul 08, 2015 at 01:55:43PM -0400, Valdis.Kletnieks at vt.edu wrote: > > On Wed, 08 Jul 2015 17:42:52 -0000, Matthew Huff said: > > > Given that the technical resources at the NYSE are significant and > the lengthy duration of the outage, I believe this is more serious > than is being reported. > > > My personal, totally zero-info suspicion: > > Some chuckleheaded NOC banana-eater made a typo, and discovered an > entirely new class of wondrous BGP-wedgie style "We know how we got > here, but how do we get back?" network misbehaviors.... > > > We don't know how long the underlying problem lasted, and how much of > the continued outage time is dealing with the logistics of restarting > trading mid-day. Completely stopping and then restarting trading > mid-day is likely not a quick process even if the underlying technical > issue is immediately resolved. > > (Such things have happened before - like the med school a few years ago > > that > > extended their ethernet spanning tree one hop too far, and discovered > > that > > merely removing the one hop too far wasn't sufficient to let it come > > back up...) > > > No, but picking a bridge in the center, giving it priority sufficient > for it to become root, and then configuring timers[1] that would > support a much larger than default diameter, possibly followed by some > reboots, probably would have. > > From what has been publicly stated, they likely took a much longer and > more complicated path to service restoration than was strictly > necessary. (I have no non-public information on that event. There may > be good reasons, technical or otherwise, why that wasn't the chosen > solution.) > > -- Brett > > [1] You only have to configure them on the root; non-root bridges use > what root sends out, not what they ahve configured. > > > > > > --- > > Keith Stokes > > > > > From jwalter at weebly.com Wed Jul 8 22:12:47 2015 From: jwalter at weebly.com (Jeff Walter) Date: Wed, 8 Jul 2015 15:12:47 -0700 Subject: Debian RWHOIS In-Reply-To: <1436385829.81623806@upnet.mymailsrvr.com> References: <20150708195244.GK3901@dan.olp.net> <1436385829.81623806@upnet.mymailsrvr.com> Message-ID: Few years back I wrote an RWHOIS daemon for HE and because of that got put in touch with Mark Kosters, one of the RWHOIS RFC authors. Without mincing words he basically told me RWHOIS was dead. Honestly, unless you have a specific reason to use RWHOIS (privatizing records as allowed by ARIN policy) your best bet is to programmatically update the info on ARIN using their API. I wouldn't even both emailing SWIP updates if you want to go the route of automatic updates since I would guess that system will be retired in favor of the RESTful API. Jeff Walter On Wed, Jul 8, 2015 at 1:03 PM, Shawn L wrote: > > We ran it for a while, then gave up and just updated the info on Arin. > > > -----Original Message----- > From: "Josh Luthman" > Sent: Wednesday, July 8, 2015 3:56pm > To: "Dan White" > Cc: "Josh Moore" , "nanog at nanog.org" < > nanog at nanog.org> > Subject: Re: Debian RWHOIS > > > > I think this is what you're asking for: > > http://projects.arin.net/rwhois > > Should be a ./configure && make && make install #per this > http://projects.arin.net/rwhois/docs/installation.html > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Wed, Jul 8, 2015 at 3:52 PM, Dan White wrote: > > > On 07/08/15 19:38 +0000, Josh Moore wrote: > > > >> Hello guys, > >> > > > > What do you use for ARIN resource assignments? I am looking to setup a > >> Debian-based RWHOIS server but don't see much information on it. > >> > > > > As of a couple of years ago when I looked around, there were no recent > > packaged versions of rwhoisd for Debian. We run a compiled version. > > > > -- > > Dan White > > > From contact at nullivex.com Wed Jul 8 22:18:27 2015 From: contact at nullivex.com (Bryan Tong) Date: Wed, 8 Jul 2015 16:18:27 -0600 Subject: Debian RWHOIS In-Reply-To: References: <20150708195244.GK3901@dan.olp.net> <1436385829.81623806@upnet.mymailsrvr.com> Message-ID: If you know anyone with some basic coding experience. Check this out. https://www.npmjs.com/package/rwhois It works far easier than the ARIN provided daemons and we have been successful using it with ARIN. Thanks On Wed, Jul 8, 2015 at 4:12 PM, Jeff Walter wrote: > Few years back I wrote an RWHOIS daemon for HE and because of that got put > in touch with Mark Kosters, one of the RWHOIS RFC authors. Without mincing > words he basically told me RWHOIS was dead. Honestly, unless you have a > specific reason to use RWHOIS (privatizing records as allowed by ARIN > policy) your best bet is to programmatically update the info on ARIN using > their API. I wouldn't even both emailing SWIP updates if you want to go the > route of automatic updates since I would guess that system will be retired > in favor of the RESTful API. > > Jeff Walter > > On Wed, Jul 8, 2015 at 1:03 PM, Shawn L wrote: > > > > > We ran it for a while, then gave up and just updated the info on Arin. > > > > > > -----Original Message----- > > From: "Josh Luthman" > > Sent: Wednesday, July 8, 2015 3:56pm > > To: "Dan White" > > Cc: "Josh Moore" , "nanog at nanog.org" < > > nanog at nanog.org> > > Subject: Re: Debian RWHOIS > > > > > > > > I think this is what you're asking for: > > > > http://projects.arin.net/rwhois > > > > Should be a ./configure && make && make install #per this > > http://projects.arin.net/rwhois/docs/installation.html > > > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Wed, Jul 8, 2015 at 3:52 PM, Dan White wrote: > > > > > On 07/08/15 19:38 +0000, Josh Moore wrote: > > > > > >> Hello guys, > > >> > > > > > > What do you use for ARIN resource assignments? I am looking to setup a > > >> Debian-based RWHOIS server but don't see much information on it. > > >> > > > > > > As of a couple of years ago when I looked around, there were no recent > > > packaged versions of rwhoisd for Debian. We run a compiled version. > > > > > > -- > > > Dan White > > > > > > -- eSited LLC (701) 390-9638 From bholloway at pavlovmedia.com Wed Jul 8 22:23:44 2015 From: bholloway at pavlovmedia.com (Bryan Holloway) Date: Wed, 8 Jul 2015 22:23:44 +0000 Subject: Debian RWHOIS In-Reply-To: References: <20150708195244.GK3901@dan.olp.net> <1436385829.81623806@upnet.mymailsrvr.com> Message-ID: I concur ... Mark told me the same at the ARIN/NANOG OTR in San Diego last year. The RESTful API is the way to go. On 7/8/15, 5:12 PM, "NANOG on behalf of Jeff Walter" wrote: >Few years back I wrote an RWHOIS daemon for HE and because of that got put >in touch with Mark Kosters, one of the RWHOIS RFC authors. Without mincing >words he basically told me RWHOIS was dead. Honestly, unless you have a >specific reason to use RWHOIS (privatizing records as allowed by ARIN >policy) your best bet is to programmatically update the info on ARIN using >their API. I wouldn't even both emailing SWIP updates if you want to go >the >route of automatic updates since I would guess that system will be retired >in favor of the RESTful API. > >Jeff Walter > >On Wed, Jul 8, 2015 at 1:03 PM, Shawn L wrote: > >> >> We ran it for a while, then gave up and just updated the info on Arin. >> >> >> -----Original Message----- >> From: "Josh Luthman" >> Sent: Wednesday, July 8, 2015 3:56pm >> To: "Dan White" >> Cc: "Josh Moore" , "nanog at nanog.org" < >> nanog at nanog.org> >> Subject: Re: Debian RWHOIS >> >> >> >> I think this is what you're asking for: >> >> http://projects.arin.net/rwhois >> >> Should be a ./configure && make && make install #per this >> http://projects.arin.net/rwhois/docs/installation.html >> >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> On Wed, Jul 8, 2015 at 3:52 PM, Dan White wrote: >> >> > On 07/08/15 19:38 +0000, Josh Moore wrote: >> > >> >> Hello guys, >> >> >> > >> > What do you use for ARIN resource assignments? I am looking to setup a >> >> Debian-based RWHOIS server but don't see much information on it. >> >> >> > >> > As of a couple of years ago when I looked around, there were no recent >> > packaged versions of rwhoisd for Debian. We run a compiled version. >> > >> > -- >> > Dan White >> > >> From landonstewart at gmail.com Wed Jul 8 22:31:52 2015 From: landonstewart at gmail.com (Landon Stewart) Date: Wed, 8 Jul 2015 15:31:52 -0700 Subject: Debian RWHOIS In-Reply-To: References: <20150708195244.GK3901@dan.olp.net> <1436385829.81623806@upnet.mymailsrvr.com> Message-ID: On Jul 8, 2015, at 3:12 PM, Jeff Walter wrote: > > Without mincing words he basically told me RWHOIS was dead. Someone please tell Spamhaus. Landon Stewart landonstewart at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 909 bytes Desc: Message signed with OpenPGP using GPGMail URL: From contact at nullivex.com Wed Jul 8 22:40:57 2015 From: contact at nullivex.com (Bryan Tong) Date: Wed, 8 Jul 2015 16:40:57 -0600 Subject: Debian RWHOIS In-Reply-To: References: <20150708195244.GK3901@dan.olp.net> <1436385829.81623806@upnet.mymailsrvr.com> Message-ID: And let ARIN know while you're at it. Ive heard similar ideas from them but have heard no path of upgrade on justification. On Wed, Jul 8, 2015 at 4:31 PM, Landon Stewart wrote: > On Jul 8, 2015, at 3:12 PM, Jeff Walter wrote: > > > > Without mincing words he basically told me RWHOIS was dead. > > Someone please tell Spamhaus. > > Landon Stewart > landonstewart at gmail.com > > > > -- eSited LLC (701) 390-9638 From israel.lugo at lugosys.com Wed Jul 8 23:45:08 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 09 Jul 2015 00:45:08 +0100 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> Message-ID: <559DB604.8060901@lugosys.com> On 07/05/2015 06:26 PM, Owen DeLong wrote: >> On Jul 4, 2015, at 23:51 , Valdis.Kletnieks at vt.edu wrote: >> >> Put their IPv4 behind a NAT and a globally routed /56. >> >> There, FTFY. :) > Or better yet globally routed /48. > > /56 is still a bad idea. > > Owen I've read this many times and am aware it's the standard recommendation. Makes perfect sense for the customer side, as it would be hard for him to subnet properly otherwise. Doesn't seem to make sense at all for the ISP side, though. Standard allocation /32. Giving out /48s. Even if we leave out proper subnet organization and allocate fully densely, that's at most 65,536 subnets. Not a very large ISP. You can say "get more blocks", or "get larger blocks". Sure, let's give each ISP a /24. That lets them have up to 16M customers (and that's still subnetting densely, which sucks rather a lot). Doesn't leave that many allocation blocks for the RIRs to hand out, though. People usually look at IPv6 and focus on the vast numbers of individual addresses. Naysayers usually get shot down with some quote mentioning the number of atoms in the universe or some such. Personally, I think that's a red herring; the real problem is subnets. At this rate I believe subnets will become the scarce resource sooner or later. Sure, in the LAN side we'll never have to worry about address scarcity. But what's the point of having addresses to spare, if it just means you've got to start worrying about subnet scarcity? If the goal was never having to worry about counting anymore, I propose that 128 bits is far too little. Should've gone a full 256 and be done with it. Regards, Israel G. Lugo P.S.: I'm 100% for IPv6 and $dayjob has been fully dual stacked for 10 years now. From marka at isc.org Wed Jul 8 23:59:18 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Jul 2015 09:59:18 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Thu, 09 Jul 2015 00:45:08 +0100." <559DB604.8060901@lugosys.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> Message-ID: <20150708235918.B41A53286089@rock.dv.isc.org> In message <559DB604.8060901 at lugosys.com>, "Israel G. Lugo" writes: > > On 07/05/2015 06:26 PM, Owen DeLong wrote: > >> On Jul 4, 2015, at 23:51 , Valdis.Kletnieks at vt.edu wrote: > >> > >> Put their IPv4 behind a NAT and a globally routed /56. > >> > >> There, FTFY. :) > > Or better yet globally routed /48. > > > > /56 is still a bad idea. > > > > Owen > I've read this many times and am aware it's the standard recommendation. > Makes perfect sense for the customer side, as it would be hard for him > to subnet properly otherwise. > > Doesn't seem to make sense at all for the ISP side, though. Standard > allocation /32. Giving out /48s. Even if we leave out proper subnet > organization and allocate fully densely, that's at most 65,536 subnets. > Not a very large ISP. /32 is not the standard allocation. It is the *minimum* allocation for a ISP. ISPs are expected to ask for *more* addresses to meet their actual requirements. > You can say "get more blocks", or "get larger blocks". Sure, let's give > each ISP a /24. That lets them have up to 16M customers (and that's > still subnetting densely, which sucks rather a lot). Doesn't leave that > many allocation blocks for the RIRs to hand out, though. Which in part is why the minimum is a /32. > People usually look at IPv6 and focus on the vast numbers of individual > addresses. Naysayers usually get shot down with some quote mentioning > the number of atoms in the universe or some such. Personally, I think > that's a red herring; the real problem is subnets. At this rate I > believe subnets will become the scarce resource sooner or later. No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the 1/8th of the total IPv6 space currently in use. That is 35 trillion sites and if we use that up we can look at using a different default size in the next 1/8th. > Sure, in the LAN side we'll never have to worry about address scarcity. > But what's the point of having addresses to spare, if it just means > you've got to start worrying about subnet scarcity? If the goal was > never having to worry about counting anymore, I propose that 128 bits is > far too little. Should've gone a full 256 and be done with it. > > Regards, > Israel G. Lugo > > P.S.: I'm 100% for IPv6 and $dayjob has been fully dual stacked for 10 > years now. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jfbeam at gmail.com Thu Jul 9 00:05:36 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 08 Jul 2015 20:05:36 -0400 Subject: Debian RWHOIS In-Reply-To: References: <20150708195244.GK3901@dan.olp.net> <1436385829.81623806@upnet.mymailsrvr.com> Message-ID: On Wed, 08 Jul 2015 18:12:47 -0400, Jeff Walter wrote: > he basically told me RWHOIS was dead It is most certainly NOT dead. It is, and always has been, a very small userbase. SWIP has always been a pain in the ass. Modern web-ized methods are more acceptable, but still an ugly mess. But, that said, so are all the (r)whois implementations. In eons long past, I ran an rwhois server. It was almost infinitely easier to convert our address management database (text file) into rwhois zone data. And since the only reason to do any of this crap was for address requests -- once or twice a year, the reduction in man hours dealing with SWIP was greatly rewarded. From mhuff at ox.com Thu Jul 9 00:14:43 2015 From: mhuff at ox.com (Matthew Huff) Date: Thu, 9 Jul 2015 00:14:43 +0000 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <8BC6702C-79AD-4775-B140-CED5239D9DAD@ox.com> <10601.1436378143@turing-police.cc.vt.edu> <20150708183321.GA21478@panix.com> <5B17ED50-A8E5-464F-A889-FE2C35035147@ox.com> <853F604B-55A2-4519-9D73-1C64BD2C0981@neilltech.com>, Message-ID: <9E81B5F9-9AEA-4041-A633-3B1A35FD5F48@ox.com> I've been working at a trading firm for the last 18 years. Most of the Market traditionally rolls out changes out over the weekends, making every Monday an adventure. It's unusual that they would roll out anything during the week, but they could have had something that failed and had to be undone last weekend, they rolled it out last night because they thought they had it fixed. They may have had a reason why they needed it out in a hurry. The summer is a big time for changes because it's so less busy.. We usually roll out changes on Thursday nights since Friday's are the least busy. Summer Friday's are completely dead. This puts NYSE in a double bad light. First the glitch and second the market traded close to normal without the NYSE. On Jul 8, 2015, at 5:49 PM, Dovid Bender > wrote: Well that's a given. I am talking about organizations like the NYSE or MaBell, On Wed, Jul 8, 2015 at 5:44 PM, Keith Stokes > wrote: Who roles out software in the middle of the week and not on weekends? People who have more business on the weekends than the week, such as retail. On Jul 8, 2015, at 4:40 PM, Dovid Bender > wrote: Other than for an emergency repair who roles out a software update in middle of the week? We test, test and then test some more and only then roll out on weekends. Our maintenance window is 00:00 - 01:00 Sunday mornings for sw updates etc. On Wed, Jul 8, 2015 at 3:02 PM, Matthew Huff > wrote: Traders on the floor are being told that it's a software glitch from new software that was rolled out Tuesday night. Nothing official has been said. The only thing I know for sure is that if the NYSE was hacked, they wouldn't tell anyone the details for a long time, if ever. The impact of the NYSE being down is much less significant than it used to be since most stocks are multiple-listed on other exchanges. The lack of information through official channels is unusual though. In previous situations, there has been at least a little hand-holding. So far, nada. In fact, other than financial service provider's emails, there has been no emails so far today from the NYSE, including the announcement of resumption of service. According the the NYSE web page, trading will resume at 3:05pm EST today with primary specialist, and 3:10 for everyone. On Jul 8, 2015, at 2:33 PM, Brett Frankenberger > wrote: On Wed, Jul 08, 2015 at 01:55:43PM -0400, Valdis.Kletnieks at vt.edu wrote: On Wed, 08 Jul 2015 17:42:52 -0000, Matthew Huff said: Given that the technical resources at the NYSE are significant and the lengthy duration of the outage, I believe this is more serious than is being reported. My personal, totally zero-info suspicion: Some chuckleheaded NOC banana-eater made a typo, and discovered an entirely new class of wondrous BGP-wedgie style "We know how we got here, but how do we get back?" network misbehaviors.... We don't know how long the underlying problem lasted, and how much of the continued outage time is dealing with the logistics of restarting trading mid-day. Completely stopping and then restarting trading mid-day is likely not a quick process even if the underlying technical issue is immediately resolved. (Such things have happened before - like the med school a few years ago that extended their ethernet spanning tree one hop too far, and discovered that merely removing the one hop too far wasn't sufficient to let it come back up...) No, but picking a bridge in the center, giving it priority sufficient for it to become root, and then configuring timers[1] that would support a much larger than default diameter, possibly followed by some reboots, probably would have. >From what has been publicly stated, they likely took a much longer and more complicated path to service restoration than was strictly necessary. (I have no non-public information on that event. There may be good reasons, technical or otherwise, why that wasn't the chosen solution.) -- Brett [1] You only have to configure them on the root; non-root bridges use what root sends out, not what they ahve configured. --- Keith Stokes From bholloway at pavlovmedia.com Thu Jul 9 00:18:31 2015 From: bholloway at pavlovmedia.com (Bryan Holloway) Date: Thu, 9 Jul 2015 00:18:31 +0000 Subject: Debian RWHOIS In-Reply-To: References: <20150708195244.GK3901@dan.olp.net> <1436385829.81623806@upnet.mymailsrvr.com> Message-ID: On 7/8/15, 7:05 PM, "NANOG on behalf of Ricky Beam" wrote: >On Wed, 08 Jul 2015 18:12:47 -0400, Jeff Walter >wrote: >> he basically told me RWHOIS was dead > >It is most certainly NOT dead. It is, and always has been, a very small >userbase. SWIP has always been a pain in the ass. Modern web-ized methods > >are more acceptable, but still an ugly mess. But, that said, so are all >the (r)whois implementations. > >In eons long past, I ran an rwhois server. It was almost infinitely >easier >to convert our address management database (text file) into rwhois zone >data. And since the only reason to do any of this crap was for address >requests -- once or twice a year, the reduction in man hours dealing with > >SWIP was greatly rewarded. ?Dead? is probably not the right word. Perhaps ?obsolete? is better. Do people still use it? Yes. I installed and ran it in the early aughts when that was ARIN?s requirement for requesting IP blocks when we outgrew those given to us by UUnet. It was a giant pain in the butt importing all of our data into it, but we did, down to the customer /29s, and I patiently waited for ARIN to query it to meet our obligations. Finally, one day, I saw a query. One query. (One ping only.) And it worked, and we got our /19. So is rwhois dead? Perhaps not. Is it something I would invest any time or effort into? No. From jgreco at ns.sol.net Thu Jul 9 00:32:00 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 8 Jul 2015 19:32:00 -0500 (CDT) Subject: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with In-Reply-To: <559D5A44.8040409@direcpath.com> Message-ID: <201507090032.t690W0WC095961@aurora.sol.net> > On 7/7/2015 5:39 PM, Joe Greco wrote: > > Unclear at best. The way it is implemented, the user has the potential > > to go either way. A network might not want the user to have the > > choice, clearly, but there is certainly a subset of users who will opt > > out of the feature and I cannot see how those would be in violation of > > any sane network usage policy. It's certainly a mess in any case. > > Now that windows mobile and desktop versions are converging, I doubt > there is a way to really tell if a device is a PC or a phone or a > tablet. Some network administrators banned mobile phones from wifi > connections because of Google's password storage violating their > security policy. > > Now administrators don't even get that knob. > > We could fix it in a couple of ways (or, they could fix it.. depending > on who pushes around money and if anyone cares enough to bother): > > 1. Wifi sends password policy during handshaking. If you save > passwords you aren't allowed to connect here (or, you aren't allowed to > backup/share this password) but we will allow the user to connect. This > can be transparent to the user and handled by the OS.* > 2. The client device sends "I am configured to backup/share passwords" > to the wifi. This allows the AP to either deny the user outright, or > redirect them to a page explaining what is wrong or whatever. This > might be accomplished via DHCP option if we want to keep it all in software. > > * The fact that we need an IEEE level fix for a security problem created > by Google and then propagated by Microsoft is just pathetic. These are > two companies that should know better than to do this. Yes, I agree. It makes me wonder how much of this is new-feature-ism promoted by a management that is looking at the(ir) big picture, then having people without sufficient technical depth "do that new feature." Or are they really drinking their own koolaid and thinking that everything is in "the cloud" today and so there aren't local security concerns? I best go before I delve into the truly cynical. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From nanog at ics-il.net Thu Jul 9 00:39:57 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 8 Jul 2015 19:39:57 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559DB604.8060901@lugosys.com> Message-ID: <1668220345.8132.1436402430612.JavaMail.mhammett@ThunderFuck> When do we run out of MAC addresses? ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Israel G. Lugo" To: "Owen DeLong" , "NANOG" Sent: Wednesday, July 8, 2015 6:45:08 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On 07/05/2015 06:26 PM, Owen DeLong wrote: >> On Jul 4, 2015, at 23:51 , Valdis.Kletnieks at vt.edu wrote: >> >> Put their IPv4 behind a NAT and a globally routed /56. >> >> There, FTFY. :) > Or better yet globally routed /48. > > /56 is still a bad idea. > > Owen I've read this many times and am aware it's the standard recommendation. Makes perfect sense for the customer side, as it would be hard for him to subnet properly otherwise. Doesn't seem to make sense at all for the ISP side, though. Standard allocation /32. Giving out /48s. Even if we leave out proper subnet organization and allocate fully densely, that's at most 65,536 subnets. Not a very large ISP. You can say "get more blocks", or "get larger blocks". Sure, let's give each ISP a /24. That lets them have up to 16M customers (and that's still subnetting densely, which sucks rather a lot). Doesn't leave that many allocation blocks for the RIRs to hand out, though. People usually look at IPv6 and focus on the vast numbers of individual addresses. Naysayers usually get shot down with some quote mentioning the number of atoms in the universe or some such. Personally, I think that's a red herring; the real problem is subnets. At this rate I believe subnets will become the scarce resource sooner or later. Sure, in the LAN side we'll never have to worry about address scarcity. But what's the point of having addresses to spare, if it just means you've got to start worrying about subnet scarcity? If the goal was never having to worry about counting anymore, I propose that 128 bits is far too little. Should've gone a full 256 and be done with it. Regards, Israel G. Lugo P.S.: I'm 100% for IPv6 and $dayjob has been fully dual stacked for 10 years now. From israel.lugo at lugosys.com Thu Jul 9 00:45:50 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 09 Jul 2015 01:45:50 +0100 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150708235918.B41A53286089@rock.dv.isc.org> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> Message-ID: <559DC43E.5020005@lugosys.com> On 07/09/2015 12:59 AM, Mark Andrews wrote: > In message <559DB604.8060901 at lugosys.com>, "Israel G. Lugo" writes: >> Doesn't seem to make sense at all for the ISP side, though. Standard >> allocation /32. Giving out /48s. Even if we leave out proper subnet >> organization and allocate fully densely, that's at most 65,536 subnets. >> Not a very large ISP. > /32 is not the standard allocation. It is the *minimum* allocation > for a ISP. ISPs are expected to ask for *more* addresses to meet their > actual requirements. Thank you for pointing that out. When speaking of /32 I was referring specifically to RIPE policy, with which I am more familiar: "Initial allocation size" for a LIR is /32, extensive to a /29 with minimal bureaucracy. Perhaps I should have said "default allocation". I understand ISPs should ask for more addresses; however, even e.g. a /24 (8x /32) seems to me like it could be "roomier". >> People usually look at IPv6 and focus on the vast numbers of individual >> addresses. Naysayers usually get shot down with some quote mentioning >> the number of atoms in the universe or some such. Personally, I think >> that's a red herring; the real problem is subnets. At this rate I >> believe subnets will become the scarce resource sooner or later. > No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the > 1/8th of the total IPv6 space currently in use. That is 35 trillion sites > and if we use that up we can look at using a different default size in the > next 1/8th. Yes, if we look at end sites individually. My hypothesis is that these astronomic numbers are in fact misleading. There isn't, after all, one single ISP-Of-The-World, with The-One-Big-Router. We must divide the addresses by ISPs/LIRs, and so on. Several bits in the prefix must be used for subaddressing. A larger ISP will probably want to further subdivide its addressing by region, and so on. With subdivisions comes "waste". Which is something we don't need to worry about at the LAN level, but it would be nice to have that level of comfort at the subaddressing level as well. Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: - I reserve 1 bit for future allocation schemes, leaving me a /33; - 2 bits for network type (infrastructure, residential, business, LTE): /35 - 3 bits for geographic region, state, whatever: /38 - 5 bits for PoP, or city: /43 This leaves me 5 bits for end sites: no joy. Granted, this is just a silly example, and I don't have to divide my address space like this. In fact, I really can't, unless I want to have more than 32 customers per city. But I don't think it's a very far-fetched example. Perhaps I'm missing something obvious here, but it seems to me that it would've been nice to have these kinds of possibilities, and more. It seems counterintuitive, especially given the "IPv6 way of thinking" which is normally encouraged: "stop counting beans, this isn't IPv4". Regards, Israel G. Lugo From nanog at ics-il.net Thu Jul 9 00:57:29 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 8 Jul 2015 19:57:29 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559DC43E.5020005@lugosys.com> Message-ID: <1809162078.8261.1436403479285.JavaMail.mhammett@ThunderFuck> Isn't /56 the standard end-user allocation? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Israel G. Lugo" To: "Mark Andrews" Cc: "NANOG" Sent: Wednesday, July 8, 2015 7:45:50 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On 07/09/2015 12:59 AM, Mark Andrews wrote: > In message <559DB604.8060901 at lugosys.com>, "Israel G. Lugo" writes: >> Doesn't seem to make sense at all for the ISP side, though. Standard >> allocation /32. Giving out /48s. Even if we leave out proper subnet >> organization and allocate fully densely, that's at most 65,536 subnets. >> Not a very large ISP. > /32 is not the standard allocation. It is the *minimum* allocation > for a ISP. ISPs are expected to ask for *more* addresses to meet their > actual requirements. Thank you for pointing that out. When speaking of /32 I was referring specifically to RIPE policy, with which I am more familiar: "Initial allocation size" for a LIR is /32, extensive to a /29 with minimal bureaucracy. Perhaps I should have said "default allocation". I understand ISPs should ask for more addresses; however, even e.g. a /24 (8x /32) seems to me like it could be "roomier". >> People usually look at IPv6 and focus on the vast numbers of individual >> addresses. Naysayers usually get shot down with some quote mentioning >> the number of atoms in the universe or some such. Personally, I think >> that's a red herring; the real problem is subnets. At this rate I >> believe subnets will become the scarce resource sooner or later. > No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the > 1/8th of the total IPv6 space currently in use. That is 35 trillion sites > and if we use that up we can look at using a different default size in the > next 1/8th. Yes, if we look at end sites individually. My hypothesis is that these astronomic numbers are in fact misleading. There isn't, after all, one single ISP-Of-The-World, with The-One-Big-Router. We must divide the addresses by ISPs/LIRs, and so on. Several bits in the prefix must be used for subaddressing. A larger ISP will probably want to further subdivide its addressing by region, and so on. With subdivisions comes "waste". Which is something we don't need to worry about at the LAN level, but it would be nice to have that level of comfort at the subaddressing level as well. Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: - I reserve 1 bit for future allocation schemes, leaving me a /33; - 2 bits for network type (infrastructure, residential, business, LTE): /35 - 3 bits for geographic region, state, whatever: /38 - 5 bits for PoP, or city: /43 This leaves me 5 bits for end sites: no joy. Granted, this is just a silly example, and I don't have to divide my address space like this. In fact, I really can't, unless I want to have more than 32 customers per city. But I don't think it's a very far-fetched example. Perhaps I'm missing something obvious here, but it seems to me that it would've been nice to have these kinds of possibilities, and more. It seems counterintuitive, especially given the "IPv6 way of thinking" which is normally encouraged: "stop counting beans, this isn't IPv4". Regards, Israel G. Lugo From mel at beckman.org Thu Jul 9 01:11:05 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 01:11:05 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1809162078.8261.1436403479285.JavaMail.mhammett@ThunderFuck> References: <559DC43E.5020005@lugosys.com>, <1809162078.8261.1436403479285.JavaMail.mhammett@ThunderFuck> Message-ID: <4955BB91-03A4-4821-8F6E-5D7A017DBDFE@beckman.org> Yes. The v6 allocation standards are simple, but can alarming to old-schoolers who have not really thought through the math. A customer gets a /56, which gives them 256 /64 subnets for their own internal use. That accommodates all except the largest customers, and those have the option of getting a /32, which gives them 4.2 billion /64s. ISPs each get a /32 by default, which supports 16.7 million /56 customers. And, of course, the /32 ISP allocation accommodates 4.2 billion ISPs. I don't see the fear. These are just integers, after all. Nothing is really "going to waste". -mel beckman > On Jul 8, 2015, at 5:58 PM, Mike Hammett wrote: > > Isn't /56 the standard end-user allocation? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Israel G. Lugo" > To: "Mark Andrews" > Cc: "NANOG" > Sent: Wednesday, July 8, 2015 7:45:50 PM > Subject: Re: Dual stack IPv6 for IPv4 depletion > > >>> On 07/09/2015 12:59 AM, Mark Andrews wrote: >>> In message <559DB604.8060901 at lugosys.com>, "Israel G. Lugo" writes: >>> Doesn't seem to make sense at all for the ISP side, though. Standard >>> allocation /32. Giving out /48s. Even if we leave out proper subnet >>> organization and allocate fully densely, that's at most 65,536 subnets. >>> Not a very large ISP. >> /32 is not the standard allocation. It is the *minimum* allocation >> for a ISP. ISPs are expected to ask for *more* addresses to meet their >> actual requirements. > > Thank you for pointing that out. When speaking of /32 I was referring > specifically to RIPE policy, with which I am more familiar: "Initial > allocation size" for a LIR is /32, extensive to a /29 with minimal > bureaucracy. Perhaps I should have said "default allocation". > > I understand ISPs should ask for more addresses; however, even e.g. a > /24 (8x /32) seems to me like it could be "roomier". > > >>> People usually look at IPv6 and focus on the vast numbers of individual >>> addresses. Naysayers usually get shot down with some quote mentioning >>> the number of atoms in the universe or some such. Personally, I think >>> that's a red herring; the real problem is subnets. At this rate I >>> believe subnets will become the scarce resource sooner or later. >> No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the >> 1/8th of the total IPv6 space currently in use. That is 35 trillion sites >> and if we use that up we can look at using a different default size in the >> next 1/8th. > Yes, if we look at end sites individually. My hypothesis is that these > astronomic numbers are in fact misleading. There isn't, after all, one > single ISP-Of-The-World, with The-One-Big-Router. > > We must divide the addresses by ISPs/LIRs, and so on. Several bits in > the prefix must be used for subaddressing. A larger ISP will probably > want to further subdivide its addressing by region, and so on. With > subdivisions comes "waste". Which is something we don't need to worry > about at the LAN level, but it would be nice to have that level of > comfort at the subaddressing level as well. > > Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: > > - I reserve 1 bit for future allocation schemes, leaving me a /33; > - 2 bits for network type (infrastructure, residential, business, LTE): /35 > - 3 bits for geographic region, state, whatever: /38 > - 5 bits for PoP, or city: /43 > > This leaves me 5 bits for end sites: no joy. > > Granted, this is just a silly example, and I don't have to divide my > address space like this. In fact, I really can't, unless I want to have > more than 32 customers per city. But I don't think it's a very > far-fetched example. > > Perhaps I'm missing something obvious here, but it seems to me that it > would've been nice to have these kinds of possibilities, and more. It > seems counterintuitive, especially given the "IPv6 way of thinking" > which is normally encouraged: "stop counting beans, this isn't IPv4". > > Regards, > Israel G. Lugo > From owen at delong.com Thu Jul 9 01:15:30 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jul 2015 18:15:30 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559DA57B.90000@lugosys.org> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DA57B.90000@lugosys.org> Message-ID: <6A197A55-9A04-44C4-A84E-2264FC93775B@delong.com> > On Jul 8, 2015, at 15:34 , Israel G. Lugo wrote: > > > On 07/05/2015 06:26 PM, Owen DeLong wrote: >>> On Jul 4, 2015, at 23:51 , Valdis.Kletnieks at vt.edu wrote: >>> >>> Put their IPv4 behind a NAT and a globally routed /56. >>> >>> There, FTFY. :) >> Or better yet globally routed /48. >> >> /56 is still a bad idea. >> >> Owen > I've read this many times and am aware it's the standard recommendation. > Makes perfect sense for the customer side, as it would be hard for him > to subnet properly otherwise. > > Doesn't seem to make sense at all for the ISP side, though. Standard > allocation /32. Giving out /48s. Even if we leave out proper subnet > organization and allocate fully densely, that's at most 65,536 subnets. > Not a very large ISP. If you?re trying to build a decent sized ISP in a /32, you?re doing it wrong. /32 is not the ?standard size? ? It?s the MINIMUM size. > > You can say "get more blocks", or "get larger blocks". Sure, let's give > each ISP a /24. That lets them have up to 16M customers (and that's > still subnetting densely, which sucks rather a lot). Doesn't leave that > many allocation blocks for the RIRs to hand out, though. If you really think we have 16.7 Million ISPs on the planet, I think you badly miscounted. In fact, if you think we have 1 million ISPs that have more than 1 million customers, I?d say you?ve badly miscounted something. What am I missing? In terms of ISPs that need to support 16M customers, let?s assume everyone on the planet has 32 ISP subscriptions of some form or another. (work, home, tablet, phone, dongle, whatever? I?m pretty sure 32 is generous). Let?s assume EVERYONE on the planet is connected. That?s 7 Billion * 32 = 224 Billion total customers. Now let?s sparse-allocate 24s at the rate of 4 million customers per /24. 224,000,000,000 / 4,000,000 = 56,000 We need a total of 56,000 /24s to cover the total population. That still leaves us with 16,721,216 /24s. We barely made a dent in the number of /24s. Please explain to me again where the problem is with handing out /48s? > People usually look at IPv6 and focus on the vast numbers of individual > addresses. Naysayers usually get shot down with some quote mentioning > the number of atoms in the universe or some such. Personally, I think > that's a red herring; the real problem is subnets. At this rate I > believe subnets will become the scarce resource sooner or later. I?ve done the math on the prefix side. See above? Clearly you haven?t. > Sure, in the LAN side we'll never have to worry about address scarcity. > But what's the point of having addresses to spare, if it just means > you've got to start worrying about subnet scarcity? If the goal was > never having to worry about counting anymore, I propose that 128 bits is > far too little. Should've gone a full 256 and be done with it. Respectfully, I think that the math above shows that you are not correct in this assertion. Owen From nanog at ics-il.net Thu Jul 9 01:19:52 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 8 Jul 2015 20:19:52 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <4955BB91-03A4-4821-8F6E-5D7A017DBDFE@beckman.org> Message-ID: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> /56 even seems a bit excessive for a residential user, but *shrugs* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" To: "Mike Hammett" Cc: "NANOG" Sent: Wednesday, July 8, 2015 8:11:05 PM Subject: Re: Dual stack IPv6 for IPv4 depletion Yes. The v6 allocation standards are simple, but can alarming to old-schoolers who have not really thought through the math. A customer gets a /56, which gives them 256 /64 subnets for their own internal use. That accommodates all except the largest customers, and those have the option of getting a /32, which gives them 4.2 billion /64s. ISPs each get a /32 by default, which supports 16.7 million /56 customers. And, of course, the /32 ISP allocation accommodates 4.2 billion ISPs. I don't see the fear. These are just integers, after all. Nothing is really "going to waste". -mel beckman > On Jul 8, 2015, at 5:58 PM, Mike Hammett wrote: > > Isn't /56 the standard end-user allocation? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Israel G. Lugo" > To: "Mark Andrews" > Cc: "NANOG" > Sent: Wednesday, July 8, 2015 7:45:50 PM > Subject: Re: Dual stack IPv6 for IPv4 depletion > > >>> On 07/09/2015 12:59 AM, Mark Andrews wrote: >>> In message <559DB604.8060901 at lugosys.com>, "Israel G. Lugo" writes: >>> Doesn't seem to make sense at all for the ISP side, though. Standard >>> allocation /32. Giving out /48s. Even if we leave out proper subnet >>> organization and allocate fully densely, that's at most 65,536 subnets. >>> Not a very large ISP. >> /32 is not the standard allocation. It is the *minimum* allocation >> for a ISP. ISPs are expected to ask for *more* addresses to meet their >> actual requirements. > > Thank you for pointing that out. When speaking of /32 I was referring > specifically to RIPE policy, with which I am more familiar: "Initial > allocation size" for a LIR is /32, extensive to a /29 with minimal > bureaucracy. Perhaps I should have said "default allocation". > > I understand ISPs should ask for more addresses; however, even e.g. a > /24 (8x /32) seems to me like it could be "roomier". > > >>> People usually look at IPv6 and focus on the vast numbers of individual >>> addresses. Naysayers usually get shot down with some quote mentioning >>> the number of atoms in the universe or some such. Personally, I think >>> that's a red herring; the real problem is subnets. At this rate I >>> believe subnets will become the scarce resource sooner or later. >> No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the >> 1/8th of the total IPv6 space currently in use. That is 35 trillion sites >> and if we use that up we can look at using a different default size in the >> next 1/8th. > Yes, if we look at end sites individually. My hypothesis is that these > astronomic numbers are in fact misleading. There isn't, after all, one > single ISP-Of-The-World, with The-One-Big-Router. > > We must divide the addresses by ISPs/LIRs, and so on. Several bits in > the prefix must be used for subaddressing. A larger ISP will probably > want to further subdivide its addressing by region, and so on. With > subdivisions comes "waste". Which is something we don't need to worry > about at the LAN level, but it would be nice to have that level of > comfort at the subaddressing level as well. > > Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: > > - I reserve 1 bit for future allocation schemes, leaving me a /33; > - 2 bits for network type (infrastructure, residential, business, LTE): /35 > - 3 bits for geographic region, state, whatever: /38 > - 5 bits for PoP, or city: /43 > > This leaves me 5 bits for end sites: no joy. > > Granted, this is just a silly example, and I don't have to divide my > address space like this. In fact, I really can't, unless I want to have > more than 32 customers per city. But I don't think it's a very > far-fetched example. > > Perhaps I'm missing something obvious here, but it seems to me that it > would've been nice to have these kinds of possibilities, and more. It > seems counterintuitive, especially given the "IPv6 way of thinking" > which is normally encouraged: "stop counting beans, this isn't IPv4". > > Regards, > Israel G. Lugo > From owen at delong.com Thu Jul 9 01:31:56 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jul 2015 18:31:56 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559DC43E.5020005@lugosys.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com> Message-ID: <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com> > > Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: > > - I reserve 1 bit for future allocation schemes, leaving me a /33; > - 2 bits for network type (infrastructure, residential, business, LTE): /35 > - 3 bits for geographic region, state, whatever: /38 > - 5 bits for PoP, or city: /43 > > This leaves me 5 bits for end sites: no joy. Here?s the problem? You started at the wrong end and worked in the wrong direction in your planning. Let?s say you?re a national ISP. Let?s say you want to support 4 levels of aggregation. Let?s say that at the lowest level (POP/City) you serve 50,000 end-sites in your largest POP/City. (16 bits) Let?s say you plan to max out at 32 POPs/Cities per region (your number from above) (5 bits) Let?s say you plan to divide the country into 8 regions (3 bits) Let?s say for some reason you want to break your aggregation along the lines of service class (infrastructure, residential, business) as your top level division (rarely a good idea, but I?ll go with it for now) and that you have 4 service classes (2 bits) Further, let?s say you decide to set aside half your address space for ?future allocation schemes?. Each POP needs a /32. We can combine the Region/POP number into an 8-bit field ? You need a /24 per Region. You need 3 additional bits for your higher level sub-divisions. Let?s round to a nibble boundary and give you a /20. With that /20, you can support up to 67 Million end sites in your first plan still leaving 3/4 of your address space fallow. (That?s at /48 per end-site, by the way). Now, let?s consider: 7 Billion People, each of which represents 32 different end-sites ? 224 billion end-sites world wide. 224,000,000,000 / 67,000,000 = 3,344 (rounded up) total ISPs requiring /20s to serve every possible end-site on the planet. There are 1,048,576 /20s total, so after allocating all the ISPs in the world /20s, we still have 1,045,232 remaining. Let?s assume that every end-site goes with dual-address multi-homing (an IPv6 prefix from each provider). We are now left with only 1,041,888 /20s remaining. You still haven?t put a dent in it. Even if we divide by 8 and just consider the current /3 being allocated as global unicast, you still have 130,236 free /20s left. > Granted, this is just a silly example, and I don't have to divide my > address space like this. In fact, I really can't, unless I want to have > more than 32 customers per city. But I don't think it's a very > far-fetched example. It?s not? It?s a great example of how not to plan your address space in IPv6. However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don?t make a dent in the IPv6 free pool. Everyone wins. > Perhaps I'm missing something obvious here, but it seems to me that it > would've been nice to have these kinds of possibilities, and more. It > seems counterintuitive, especially given the "IPv6 way of thinking" > which is normally encouraged: "stop counting beans, this isn't IPv4?. The problem is that you not only stopped counting beans, you stopped counting bean piles and you lost track of just how big the pile that you are making smaller piles from really is. I hope that this will show you a better way. Owen From owen at delong.com Thu Jul 9 01:32:13 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jul 2015 18:32:13 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1809162078.8261.1436403479285.JavaMail.mhammett@ThunderFuck> References: <1809162078.8261.1436403479285.JavaMail.mhammett@ThunderFuck> Message-ID: <456CDEEB-88E0-4ED8-99A6-179494E73283@delong.com> Only if you are trying to prevent IPv6 from reaching its full potential. Owen > On Jul 8, 2015, at 17:57 , Mike Hammett wrote: > > Isn't /56 the standard end-user allocation? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Israel G. Lugo" > To: "Mark Andrews" > Cc: "NANOG" > Sent: Wednesday, July 8, 2015 7:45:50 PM > Subject: Re: Dual stack IPv6 for IPv4 depletion > > > On 07/09/2015 12:59 AM, Mark Andrews wrote: >> In message <559DB604.8060901 at lugosys.com>, "Israel G. Lugo" writes: >>> Doesn't seem to make sense at all for the ISP side, though. Standard >>> allocation /32. Giving out /48s. Even if we leave out proper subnet >>> organization and allocate fully densely, that's at most 65,536 subnets. >>> Not a very large ISP. >> /32 is not the standard allocation. It is the *minimum* allocation >> for a ISP. ISPs are expected to ask for *more* addresses to meet their >> actual requirements. > > Thank you for pointing that out. When speaking of /32 I was referring > specifically to RIPE policy, with which I am more familiar: "Initial > allocation size" for a LIR is /32, extensive to a /29 with minimal > bureaucracy. Perhaps I should have said "default allocation". > > I understand ISPs should ask for more addresses; however, even e.g. a > /24 (8x /32) seems to me like it could be "roomier". > > >>> People usually look at IPv6 and focus on the vast numbers of individual >>> addresses. Naysayers usually get shot down with some quote mentioning >>> the number of atoms in the universe or some such. Personally, I think >>> that's a red herring; the real problem is subnets. At this rate I >>> believe subnets will become the scarce resource sooner or later. >> No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the >> 1/8th of the total IPv6 space currently in use. That is 35 trillion sites >> and if we use that up we can look at using a different default size in the >> next 1/8th. > Yes, if we look at end sites individually. My hypothesis is that these > astronomic numbers are in fact misleading. There isn't, after all, one > single ISP-Of-The-World, with The-One-Big-Router. > > We must divide the addresses by ISPs/LIRs, and so on. Several bits in > the prefix must be used for subaddressing. A larger ISP will probably > want to further subdivide its addressing by region, and so on. With > subdivisions comes "waste". Which is something we don't need to worry > about at the LAN level, but it would be nice to have that level of > comfort at the subaddressing level as well. > > Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: > > - I reserve 1 bit for future allocation schemes, leaving me a /33; > - 2 bits for network type (infrastructure, residential, business, LTE): /35 > - 3 bits for geographic region, state, whatever: /38 > - 5 bits for PoP, or city: /43 > > This leaves me 5 bits for end sites: no joy. > > Granted, this is just a silly example, and I don't have to divide my > address space like this. In fact, I really can't, unless I want to have > more than 32 customers per city. But I don't think it's a very > far-fetched example. > > Perhaps I'm missing something obvious here, but it seems to me that it > would've been nice to have these kinds of possibilities, and more. It > seems counterintuitive, especially given the "IPv6 way of thinking" > which is normally encouraged: "stop counting beans, this isn't IPv4". > > Regards, > Israel G. Lugo From kauer at biplane.com.au Thu Jul 9 01:36:41 2015 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 09 Jul 2015 11:36:41 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1809162078.8261.1436403479285.JavaMail.mhammett@ThunderFuck> References: <1809162078.8261.1436403479285.JavaMail.mhammett@ThunderFuck> Message-ID: <1436405801.27450.42.camel@karl> On Wed, 2015-07-08 at 19:57 -0500, Mike Hammett wrote: > Isn't /56 the standard end-user allocation? No - it's just a common one. And a bad one. /48s for all opens up a whole different world of end-user reachability, routability and flexibility that a mere /56 does not. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From israel.lugo at lugosys.com Thu Jul 9 01:37:52 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 09 Jul 2015 02:37:52 +0100 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <6A197A55-9A04-44C4-A84E-2264FC93775B@delong.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DA57B.90000@lugosys.org> <6A197A55-9A04-44C4-A84E-2264FC93775B@delong.com> Message-ID: <559DD070.3090906@lugosys.com> On 07/09/2015 02:15 AM, Owen DeLong wrote: > If you?re trying to build a decent sized ISP in a /32, you?re doing it > wrong. /32 is not the ?standard size? ? It?s the MINIMUM size. I've addressed this and most of what you said in my earlier reply to Mike Hammet (00:57:29 UTC). I was going to reply in more detail here but I see you've replied to the other email now as well. I'll just say that I am aware of the math, and I'm not trying to "disprove IPv6" -- nor am I making the typical argument that we will run out of IPv6 addresses. From matthew at matthew.at Thu Jul 9 01:38:49 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 8 Jul 2015 18:38:49 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> References: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> Message-ID: What's excessive is >32 bits for a subnet. No reason subnets should have been as big as they are. Bad for local forwarding decisions, waste of bits, etc. Nobody has a physical subnet technology that works for more than a few thousand hosts anyway. Matthew Kaufman (Sent from my iPhone) > On Jul 8, 2015, at 6:19 PM, Mike Hammett wrote: > > /56 even seems a bit excessive for a residential user, but *shrugs* > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Mel Beckman" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Wednesday, July 8, 2015 8:11:05 PM > Subject: Re: Dual stack IPv6 for IPv4 depletion > > Yes. The v6 allocation standards are simple, but can alarming to old-schoolers who have not really thought through the math. > > A customer gets a /56, which gives them 256 /64 subnets for their own internal use. That accommodates all except the largest customers, and those have the option of getting a /32, which gives them 4.2 billion /64s. > > ISPs each get a /32 by default, which supports 16.7 million /56 customers. And, of course, the /32 ISP allocation accommodates 4.2 billion ISPs. > > I don't see the fear. These are just integers, after all. Nothing is really "going to waste". > > -mel beckman > >> On Jul 8, 2015, at 5:58 PM, Mike Hammett wrote: >> >> Isn't /56 the standard end-user allocation? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> >> ----- Original Message ----- >> >> From: "Israel G. Lugo" >> To: "Mark Andrews" >> Cc: "NANOG" >> Sent: Wednesday, July 8, 2015 7:45:50 PM >> Subject: Re: Dual stack IPv6 for IPv4 depletion >> >> >>>> On 07/09/2015 12:59 AM, Mark Andrews wrote: >>>> In message <559DB604.8060901 at lugosys.com>, "Israel G. Lugo" writes: >>>> Doesn't seem to make sense at all for the ISP side, though. Standard >>>> allocation /32. Giving out /48s. Even if we leave out proper subnet >>>> organization and allocate fully densely, that's at most 65,536 subnets. >>>> Not a very large ISP. >>> /32 is not the standard allocation. It is the *minimum* allocation >>> for a ISP. ISPs are expected to ask for *more* addresses to meet their >>> actual requirements. >> >> Thank you for pointing that out. When speaking of /32 I was referring >> specifically to RIPE policy, with which I am more familiar: "Initial >> allocation size" for a LIR is /32, extensive to a /29 with minimal >> bureaucracy. Perhaps I should have said "default allocation". >> >> I understand ISPs should ask for more addresses; however, even e.g. a >> /24 (8x /32) seems to me like it could be "roomier". >> >> >>>> People usually look at IPv6 and focus on the vast numbers of individual >>>> addresses. Naysayers usually get shot down with some quote mentioning >>>> the number of atoms in the universe or some such. Personally, I think >>>> that's a red herring; the real problem is subnets. At this rate I >>>> believe subnets will become the scarce resource sooner or later. >>> No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the >>> 1/8th of the total IPv6 space currently in use. That is 35 trillion sites >>> and if we use that up we can look at using a different default size in the >>> next 1/8th. >> Yes, if we look at end sites individually. My hypothesis is that these >> astronomic numbers are in fact misleading. There isn't, after all, one >> single ISP-Of-The-World, with The-One-Big-Router. >> >> We must divide the addresses by ISPs/LIRs, and so on. Several bits in >> the prefix must be used for subaddressing. A larger ISP will probably >> want to further subdivide its addressing by region, and so on. With >> subdivisions comes "waste". Which is something we don't need to worry >> about at the LAN level, but it would be nice to have that level of >> comfort at the subaddressing level as well. >> >> Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: >> >> - I reserve 1 bit for future allocation schemes, leaving me a /33; >> - 2 bits for network type (infrastructure, residential, business, LTE): /35 >> - 3 bits for geographic region, state, whatever: /38 >> - 5 bits for PoP, or city: /43 >> >> This leaves me 5 bits for end sites: no joy. >> >> Granted, this is just a silly example, and I don't have to divide my >> address space like this. In fact, I really can't, unless I want to have >> more than 32 customers per city. But I don't think it's a very >> far-fetched example. >> >> Perhaps I'm missing something obvious here, but it seems to me that it >> would've been nice to have these kinds of possibilities, and more. It >> seems counterintuitive, especially given the "IPv6 way of thinking" >> which is normally encouraged: "stop counting beans, this isn't IPv4". >> >> Regards, >> Israel G. Lugo > From marka at isc.org Thu Jul 9 01:38:53 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Jul 2015 11:38:53 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Thu, 09 Jul 2015 01:45:50 +0100." <559DC43E.5020005@lugosys.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com> Message-ID: <20150709013853.66B853286FBC@rock.dv.isc.org> In message <559DC43E.5020005 at lugosys.com>, "Israel G. Lugo" writes: > > On 07/09/2015 12:59 AM, Mark Andrews wrote: > > In message <559DB604.8060901 at lugosys.com>, "Israel G. Lugo" writes: > >> Doesn't seem to make sense at all for the ISP side, though. Standard > >> allocation /32. Giving out /48s. Even if we leave out proper subnet > >> organization and allocate fully densely, that's at most 65,536 subnets. > >> Not a very large ISP. > > /32 is not the standard allocation. It is the *minimum* allocation > > for a ISP. ISPs are expected to ask for *more* addresses to meet their > > actual requirements. > > Thank you for pointing that out. When speaking of /32 I was referring > specifically to RIPE policy, with which I am more familiar: "Initial > allocation size" for a LIR is /32, extensive to a /29 with minimal > bureaucracy. Perhaps I should have said "default allocation". > > I understand ISPs should ask for more addresses; however, even e.g. a > /24 (8x /32) seems to me like it could be "roomier". > > > >> People usually look at IPv6 and focus on the vast numbers of individual > >> addresses. Naysayers usually get shot down with some quote mentioning > >> the number of atoms in the universe or some such. Personally, I think > >> that's a red herring; the real problem is subnets. At this rate I > >> believe subnets will become the scarce resource sooner or later. > > No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of t > he > > 1/8th of the total IPv6 space currently in use. That is 35 trillion sites > > and if we use that up we can look at using a different default size in the > > next 1/8th. > Yes, if we look at end sites individually. My hypothesis is that these > astronomic numbers are in fact misleading. There isn't, after all, one > single ISP-Of-The-World, with The-One-Big-Router. > > We must divide the addresses by ISPs/LIRs, and so on. Several bits in > the prefix must be used for subaddressing. A larger ISP will probably > want to further subdivide its addressing by region, and so on. With > subdivisions comes "waste". Which is something we don't need to worry > about at the LAN level, but it would be nice to have that level of > comfort at the subaddressing level as well. > > Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: > > - I reserve 1 bit for future allocation schemes, leaving me a /33; > - 2 bits for network type (infrastructure, residential, business, LTE): /35 > - 3 bits for geographic region, state, whatever: /38 > - 5 bits for PoP, or city: /43 > > This leaves me 5 bits for end sites: no joy. > > Granted, this is just a silly example, and I don't have to divide my > address space like this. In fact, I really can't, unless I want to have > more than 32 customers per city. But I don't think it's a very > far-fetched example. A single /48 has enough space/subnets cover the entire infrastructure of 99.9999% of ISPs even using /64's for p2p links rather than taking one /64 and subdividing that for all of the p2p links. Treat the ISP as a business customer of itself when allocating address space for itself. A single /48 or one /48 per site. > Perhaps I'm missing something obvious here, but it seems to me that it > would've been nice to have these kinds of possibilities, and more. It > seems counterintuitive, especially given the "IPv6 way of thinking" > which is normally encouraged: "stop counting beans, this isn't IPv4". The thinking is that ISP's are experts and can deal with managing complex allocation policy. They can also deal with multiple more specific routes etc. They already cope with this in IPv4. > Regards, > Israel G. Lugo -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mel at beckman.org Thu Jul 9 01:46:51 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 01:46:51 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com>, <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com> Message-ID: <05E8D728-9A7E-4C3C-B97F-276EF3CBCEB9@beckman.org> Israel, A better question is why bit-map your allocation plan at all? That seems ill advised, since you must arbitrarily allocate huge swaths of ip space equally between category classes when it's rarely efficient to do so. For example, two bits for network infrastructure because infrastructure addresses are likely far fewer than any customer class. Similarly three bits for geographic region on the /38 boundary illogically assumes all geographic regions are the same size. There isn't a good routing reason for a bitwise address structure, since nobody routes that way. The only other rationale I can think of is human mnemonic value, but 128-bit addresses are not very amenable to such mnemonics (::DEAD:BEEF not withstanding :) -mel beckman > On Jul 8, 2015, at 6:32 PM, Owen DeLong wrote: > > >> >> Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: >> >> - I reserve 1 bit for future allocation schemes, leaving me a /33; >> - 2 bits for network type (infrastructure, residential, business, LTE): /35 >> - 3 bits for geographic region, state, whatever: /38 >> - 5 bits for PoP, or city: /43 >> >> This leaves me 5 bits for end sites: no joy. > > Here?s the problem? You started at the wrong end and worked in the wrong direction in your planning. > > Let?s say you?re a national ISP. Let?s say you want to support 4 levels of aggregation. > Let?s say that at the lowest level (POP/City) you serve 50,000 end-sites in your largest POP/City. (16 bits) > Let?s say you plan to max out at 32 POPs/Cities per region (your number from above) (5 bits) > Let?s say you plan to divide the country into 8 regions (3 bits) > Let?s say for some reason you want to break your aggregation along the lines of service class (infrastructure, residential, business) > as your top level division (rarely a good idea, but I?ll go with it for now) and that you have 4 service classes (2 bits) > Further, let?s say you decide to set aside half your address space for ?future allocation schemes?. > > Each POP needs a /32. > We can combine the Region/POP number into an 8-bit field ? You need a /24 per Region. > You need 3 additional bits for your higher level sub-divisions. Let?s round to a nibble boundary and give you a /20. > > With that /20, you can support up to 67 Million end sites in your first plan still leaving 3/4 of your address space fallow. > > (That?s at /48 per end-site, by the way). > > Now, let?s consider: 7 Billion People, each of which represents 32 different end-sites ? 224 billion end-sites world wide. > 224,000,000,000 / 67,000,000 = 3,344 (rounded up) total ISPs requiring /20s to serve every possible end-site on the > planet. > > > There are 1,048,576 /20s total, so after allocating all the ISPs in the world /20s, we still have 1,045,232 remaining. > > Let?s assume that every end-site goes with dual-address multi-homing (an IPv6 prefix from each provider). > > We are now left with only 1,041,888 /20s remaining. You still haven?t put a dent in it. > > Even if we divide by 8 and just consider the current /3 being allocated as global unicast, you still have 130,236 free /20s > left. > >> Granted, this is just a silly example, and I don't have to divide my >> address space like this. In fact, I really can't, unless I want to have >> more than 32 customers per city. But I don't think it's a very >> far-fetched example. > > It?s not? It?s a great example of how not to plan your address space in IPv6. > > However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don?t make a dent in the IPv6 free pool. Everyone wins. > >> Perhaps I'm missing something obvious here, but it seems to me that it >> would've been nice to have these kinds of possibilities, and more. It >> seems counterintuitive, especially given the "IPv6 way of thinking" >> which is normally encouraged: "stop counting beans, this isn't IPv4?. > > The problem is that you not only stopped counting beans, you stopped counting bean piles and you lost track of just how big the pile that you are making smaller piles from really is. > > I hope that this will show you a better way. > > Owen > From mel at beckman.org Thu Jul 9 01:51:32 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 01:51:32 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck>, Message-ID: <167BD0CF-B01E-4D6F-849B-BADFB9190323@beckman.org> Matthew, This is where we have to excise our IPv4 "fear of waste" reflex. A /64 subnet, for example, doesn't waste anything material -- these are just integers, after all. If the number of integers was scarce, as they are with IPv4, then yes, we must conserve. But IPv6 is well thought out and it's design carefully considered practical IP allocation requirements before deciding on 128 bit addresses. It's enough. Really. -mel beckman > On Jul 8, 2015, at 6:46 PM, Matthew Kaufman wrote: > > What's excessive is >32 bits for a subnet. > > No reason subnets should have been as big as they are. Bad for local forwarding decisions, waste of bits, etc. > > Nobody has a physical subnet technology that works for more than a few thousand hosts anyway. > > Matthew Kaufman > > (Sent from my iPhone) > >> On Jul 8, 2015, at 6:19 PM, Mike Hammett wrote: >> >> /56 even seems a bit excessive for a residential user, but *shrugs* >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> >> ----- Original Message ----- >> >> From: "Mel Beckman" >> To: "Mike Hammett" >> Cc: "NANOG" >> Sent: Wednesday, July 8, 2015 8:11:05 PM >> Subject: Re: Dual stack IPv6 for IPv4 depletion >> >> Yes. The v6 allocation standards are simple, but can alarming to old-schoolers who have not really thought through the math. >> >> A customer gets a /56, which gives them 256 /64 subnets for their own internal use. That accommodates all except the largest customers, and those have the option of getting a /32, which gives them 4.2 billion /64s. >> >> ISPs each get a /32 by default, which supports 16.7 million /56 customers. And, of course, the /32 ISP allocation accommodates 4.2 billion ISPs. >> >> I don't see the fear. These are just integers, after all. Nothing is really "going to waste". >> >> -mel beckman >> >>> On Jul 8, 2015, at 5:58 PM, Mike Hammett wrote: >>> >>> Isn't /56 the standard end-user allocation? >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> Midwest Internet Exchange >>> http://www.midwest-ix.com >>> >>> >>> ----- Original Message ----- >>> >>> From: "Israel G. Lugo" >>> To: "Mark Andrews" >>> Cc: "NANOG" >>> Sent: Wednesday, July 8, 2015 7:45:50 PM >>> Subject: Re: Dual stack IPv6 for IPv4 depletion >>> >>> >>>>> On 07/09/2015 12:59 AM, Mark Andrews wrote: >>>>> In message <559DB604.8060901 at lugosys.com>, "Israel G. Lugo" writes: >>>>> Doesn't seem to make sense at all for the ISP side, though. Standard >>>>> allocation /32. Giving out /48s. Even if we leave out proper subnet >>>>> organization and allocate fully densely, that's at most 65,536 subnets. >>>>> Not a very large ISP. >>>> /32 is not the standard allocation. It is the *minimum* allocation >>>> for a ISP. ISPs are expected to ask for *more* addresses to meet their >>>> actual requirements. >>> >>> Thank you for pointing that out. When speaking of /32 I was referring >>> specifically to RIPE policy, with which I am more familiar: "Initial >>> allocation size" for a LIR is /32, extensive to a /29 with minimal >>> bureaucracy. Perhaps I should have said "default allocation". >>> >>> I understand ISPs should ask for more addresses; however, even e.g. a >>> /24 (8x /32) seems to me like it could be "roomier". >>> >>> >>>>> People usually look at IPv6 and focus on the vast numbers of individual >>>>> addresses. Naysayers usually get shot down with some quote mentioning >>>>> the number of atoms in the universe or some such. Personally, I think >>>>> that's a red herring; the real problem is subnets. At this rate I >>>>> believe subnets will become the scarce resource sooner or later. >>>> No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the >>>> 1/8th of the total IPv6 space currently in use. That is 35 trillion sites >>>> and if we use that up we can look at using a different default size in the >>>> next 1/8th. >>> Yes, if we look at end sites individually. My hypothesis is that these >>> astronomic numbers are in fact misleading. There isn't, after all, one >>> single ISP-Of-The-World, with The-One-Big-Router. >>> >>> We must divide the addresses by ISPs/LIRs, and so on. Several bits in >>> the prefix must be used for subaddressing. A larger ISP will probably >>> want to further subdivide its addressing by region, and so on. With >>> subdivisions comes "waste". Which is something we don't need to worry >>> about at the LAN level, but it would be nice to have that level of >>> comfort at the subaddressing level as well. >>> >>> Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: >>> >>> - I reserve 1 bit for future allocation schemes, leaving me a /33; >>> - 2 bits for network type (infrastructure, residential, business, LTE): /35 >>> - 3 bits for geographic region, state, whatever: /38 >>> - 5 bits for PoP, or city: /43 >>> >>> This leaves me 5 bits for end sites: no joy. >>> >>> Granted, this is just a silly example, and I don't have to divide my >>> address space like this. In fact, I really can't, unless I want to have >>> more than 32 customers per city. But I don't think it's a very >>> far-fetched example. >>> >>> Perhaps I'm missing something obvious here, but it seems to me that it >>> would've been nice to have these kinds of possibilities, and more. It >>> seems counterintuitive, especially given the "IPv6 way of thinking" >>> which is normally encouraged: "stop counting beans, this isn't IPv4". >>> >>> Regards, >>> Israel G. Lugo >> From Timothy.Creswick at vorboss.com Wed Jul 8 19:40:02 2015 From: Timothy.Creswick at vorboss.com (Timothy Creswick) Date: Wed, 8 Jul 2015 20:40:02 +0100 Subject: United Airlines is Down (!) due to network connectivity problems In-Reply-To: <3DE44648-03EB-454B-9E6B-CC9AA2E2D4EE@ianai.net> References: <5D7F5DF9-D8C5-424E-8BF4-77C5C69AD5EC@ianai.net> <559D519A.6080904@mykolab.com> <559D587E.5080900@mykolab.com> <559D5B77.7010402@mykolab.com> <3D6FF3DA-722A-4710-8B83-2EEA3DD53A94@baylink.com> <3DE44648-03EB-454B-9E6B-CC9AA2E2D4EE@ianai.net> Message-ID: <6D526C4EE4FA2745AD0D768DC25211F008724BBB048A@MBOX-CLUSTER.hosted.vorboss.net> > > Once is an accident; twice is a coincidence... > > > > Three times is enemy action. https://en.wikipedia.org/wiki/Poisson_clumping T From skull at bofhland.org Wed Jul 8 22:58:19 2015 From: skull at bofhland.org (Emanuele Balla) Date: Thu, 09 Jul 2015 00:58:19 +0200 Subject: Debian RWHOIS In-Reply-To: References: <20150708195244.GK3901@dan.olp.net> <1436385829.81623806@upnet.mymailsrvr.com> Message-ID: <559DAB0B.60108@bofhland.org> On 09/07/15 00:31, Landon Stewart wrote: > On Jul 8, 2015, at 3:12 PM, Jeff Walter wrote: >> >> Without mincing words he basically told me RWHOIS was dead. > > Someone please tell Spamhaus. Not sure why they should care. As long as proper info about the assignee are provided, who cares if the info comes from ARIN's or your whois server? From israel.lugo at lugosys.com Thu Jul 9 01:57:43 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 09 Jul 2015 02:57:43 +0100 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150709013853.66B853286FBC@rock.dv.isc.org> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com> <20150709013853.66B853286FBC@rock.dv.isc.org> Message-ID: <559DD517.8010904@lugosys.com> On 07/09/2015 02:38 AM, Mark Andrews wrote: > A single /48 has enough space/subnets cover the entire infrastructure > of 99.9999% of ISPs even using /64's for p2p links rather than taking > one /64 and subdividing that for all of the p2p links. Treat the ISP > as a business customer of itself when allocating address space for > itself. A single /48 or one /48 per site. A single /48 is more than enough for infrastructure, yes. It was a 5-minute example. Bitmapping the allocations can't be done right now in IPv4 (technically it can, but there's not enough to go around). One of the good things about IPv6 is supposed to be not having to worry about address waste. You're never going to fill up even a single /64 with current technology (you'll run out of MAC addresses first). Taking the infrastructure example above: sure, a /48 is a waste. Who cares? So is a /64 for my home network. Again, who cares? There are enough addresses. As someone said here, they're just integers. My whole point is: why not allow some room for more flexible allocations? Compatibility was already broken by changing address length. > The thinking is that ISP's are experts and can deal with managing > complex allocation policy. They can also deal with multiple more > specific routes etc. They already cope with this in IPv4. Uh... okay? From fergdawgster at mykolab.com Thu Jul 9 01:58:44 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 8 Jul 2015 18:58:44 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <167BD0CF-B01E-4D6F-849B-BADFB9190323@beckman.org> References: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> <167BD0CF-B01E-4D6F-849B-BADFB9190323@beckman.org> Message-ID: <559DD554.3030705@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/8/2015 6:51 PM, Mel Beckman wrote: > This is where we have to excise our IPv4 "fear of waste" reflex. Excise or exercise? I am partially serious. - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWd1VQACgkQKJasdVTchbLULwEAjnnJgH153ewFHb5ZONrUivCS LOjg+GByXK/dzeFIgDIBANc9hmFO+2Kd/vxK47ZVvgNuzy3cqTJYxrV6zYZ8IODi =OzVs -----END PGP SIGNATURE----- From nanog at ics-il.net Thu Jul 9 02:03:52 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 8 Jul 2015 21:03:52 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1436405801.27450.42.camel@karl> Message-ID: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> I wasn't aware that residential users had (intentionally) multiple layers of routing within the home. I'm also not sure what address length has to do with routability, other than networks filtering prefix lengths. If that's an issue, that customer is covered by the ISP's larger allocation, or they get their own PI space if they're BGPing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Karl Auer" To: nanog at nanog.org Sent: Wednesday, July 8, 2015 8:36:41 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, 2015-07-08 at 19:57 -0500, Mike Hammett wrote: > Isn't /56 the standard end-user allocation? No - it's just a common one. And a bad one. /48s for all opens up a whole different world of end-user reachability, routability and flexibility that a mere /56 does not. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From mel at beckman.org Thu Jul 9 02:06:27 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 02:06:27 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559DD554.3030705@mykolab.com> References: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> <167BD0CF-B01E-4D6F-849B-BADFB9190323@beckman.org>, <559DD554.3030705@mykolab.com> Message-ID: excise verb 1. To excise is defined as to cut out surgically. When a tumor is surgically cut out, this is an example of excise. Exercise wouldn't work. That would mean "repeatedly employ the fear". Exorcise (as in The Exorcist) might serve, except the IPv4 "fear of waste" is not a demon. It's a good thing. -mel beckman On Jul 8, 2015, at 6:59 PM, Paul Ferguson > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/8/2015 6:51 PM, Mel Beckman wrote: This is where we have to excise our IPv4 "fear of waste" reflex. Excise or exercise? I am partially serious. - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWd1VQACgkQKJasdVTchbLULwEAjnnJgH153ewFHb5ZONrUivCS LOjg+GByXK/dzeFIgDIBANc9hmFO+2Kd/vxK47ZVvgNuzy3cqTJYxrV6zYZ8IODi =OzVs -----END PGP SIGNATURE----- From Valdis.Kletnieks at vt.edu Thu Jul 9 02:13:24 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 08 Jul 2015 22:13:24 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Wed, 08 Jul 2015 20:19:52 -0500." <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> References: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> Message-ID: <7579.1436408004@turing-police.cc.vt.edu> On Wed, 08 Jul 2015 20:19:52 -0500, Mike Hammett said: > /56 even seems a bit excessive for a residential user, but *shrugs* It goes pretty quick when each WNDR3800 running CeroWRT will chew through 4 bits worth of subnets just by powering on, and even more if you start doing any VLAN stuff.... and then you put a second one at the far end of the house for better coverage and it asks for its own PD space from your main one..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From tqr2813d376cjozqap1l at tutanota.com Thu Jul 9 02:14:53 2015 From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com) Date: Thu, 9 Jul 2015 02:14:53 +0000 (UTC) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> References: <<1436405801.27450.42.camel@karl>> <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> Message-ID: 9. Jul 2015 02:03 by nanog at ics-il.net: > I wasn't aware that residential users had (intentionally) multiple layers > of routing within the home. > ?Some (newer?) wireless routers have an option to create a seperate network for a guests (own IPv4 /24, own SSID, firewall between the two IPv4 /24s, ...). In the IPv6 world they'd probably designate a /64 for each network From israel.lugo at lugosys.com Thu Jul 9 02:22:21 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 09 Jul 2015 03:22:21 +0100 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com> <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com> Message-ID: <559DDADD.7000606@lugosys.com> On 07/09/2015 02:31 AM, Owen DeLong wrote: > Here?s the problem? You started at the wrong end and worked in the wrong direction in your planning. > > [...get larger allocation...] > > We are now left with only 1,041,888 /20s remaining. You still haven?t put a dent in it. I am aware of the math, and how it can fit. I will concede that a /20 is sufficient. Note, however, the difference in orders of magnitude for typical allocations. I realize in ARIN side you've got e.g. Comcast with multiple /20s, but in RIPE that is not so common. My home ISP has 3x /32s. As I said, default ISP/LIR allocation here is from /32 to /29. Yes, shorter prefixes can be justified and obtained, but it's not the norm. > It?s not? It?s a great example of how not to plan your address space in IPv6. > > However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don?t make a dent in the IPv6 free pool. Everyone wins. You basically just said "get a larger allocation"... Which was my point all along. /32 is not enough, and even /24 could be made much roomier. Speaking of IPv6's full potential: we're considering 32 subscriptions per client. I've read people thinking of things like IPv6-aware soda cans. Refrigerators. Wearables. Cars and their internal components... You could have the on-board computer talking to the suspension via IPv6, and reporting back to the manufacturer or whatnot. Personally, I'm not particularly fond of the whole "refrigerators ordering milk bottles" craze, but hey, it may very well become a thing. And other stuff we haven't thought of yet. My point is: we're changing to a brand new protocol, and only now beginning to scratch its full potential. Yes, everything seems very big right now. Yes, 128 bits can be enough. Even 64 bits could be more than enough. But why limit ourselves? Someone decided (corretly) that 64 would be too limiting. Please don't fall into the usual "you've got more addresses than atoms"... I've heard that, and am not disputing it. I'm not just talking about individual addresses (or /48's). What I am proposing here, as food for thought, is: what if we had e.g. 192 bits, or 256? For one, we could have much sparser allocations. Heck, we could even go as far as having a bit for each day of the month. What would this be good for? I don't know. Perhaps someone may come up with a use for it. From israel.lugo at lugosys.com Thu Jul 9 02:26:49 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 09 Jul 2015 03:26:49 +0100 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <05E8D728-9A7E-4C3C-B97F-276EF3CBCEB9@beckman.org> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com>, <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com> <05E8D728-9A7E-4C3C-B97F-276EF3CBCEB9@beckman.org> Message-ID: <559DDBE9.2060401@lugosys.com> I'm sorry Mel, I only now saw your email. I'll quote from my reply to Owen, for the motivation behind my question: > Speaking of IPv6's full potential: we're considering 32 subscriptions > per client. I've read people thinking of things like IPv6-aware soda > cans. Refrigerators. Wearables. Cars and their internal components... > You could have the on-board computer talking to the suspension via IPv6, > and reporting back to the manufacturer or whatnot. > > Personally, I'm not particularly fond of the whole "refrigerators > ordering milk bottles" craze, but hey, it may very well become a thing. > And other stuff we haven't thought of yet. > > My point is: we're changing to a brand new protocol, and only now > beginning to scratch its full potential. Yes, everything seems very big > right now. Yes, 128 bits can be enough. Even 64 bits could be more than > enough. But why limit ourselves? Someone decided (corretly) that 64 > would be too limiting. > > Please don't fall into the usual "you've got more addresses than > atoms"... I've heard that, and am not disputing it. I'm not just talking > about individual addresses (or /48's). > > What I am proposing here, as food for thought, is: what if we had e.g. > 192 bits, or 256? For one, we could have much sparser allocations. Heck, > we could even go as far as having a bit for each day of the month. What > would this be good for? I don't know. Perhaps someone may come up with a > use for it. > Regards, Israel On 07/09/2015 02:46 AM, Mel Beckman wrote: > Israel, > > A better question is why bit-map your allocation plan at all? That seems ill advised, since you must arbitrarily allocate huge swaths of ip space equally between category classes when it's rarely efficient to do so. For example, two bits for network infrastructure because infrastructure addresses are likely far fewer than any customer class. Similarly three bits for geographic region on the /38 boundary illogically assumes all geographic regions are the same size. > > There isn't a good routing reason for a bitwise address structure, since nobody routes that way. The only other rationale I can think of is human mnemonic value, but 128-bit addresses are not very amenable to such mnemonics (::DEAD:BEEF not withstanding :) > > -mel beckman > >> On Jul 8, 2015, at 6:32 PM, Owen DeLong wrote: >> >> >>> Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: >>> >>> - I reserve 1 bit for future allocation schemes, leaving me a /33; >>> - 2 bits for network type (infrastructure, residential, business, LTE): /35 >>> - 3 bits for geographic region, state, whatever: /38 >>> - 5 bits for PoP, or city: /43 >>> >>> This leaves me 5 bits for end sites: no joy. >> Here?s the problem? You started at the wrong end and worked in the wrong direction in your planning. >> >> Let?s say you?re a national ISP. Let?s say you want to support 4 levels of aggregation. >> Let?s say that at the lowest level (POP/City) you serve 50,000 end-sites in your largest POP/City. (16 bits) >> Let?s say you plan to max out at 32 POPs/Cities per region (your number from above) (5 bits) >> Let?s say you plan to divide the country into 8 regions (3 bits) >> Let?s say for some reason you want to break your aggregation along the lines of service class (infrastructure, residential, business) >> as your top level division (rarely a good idea, but I?ll go with it for now) and that you have 4 service classes (2 bits) >> Further, let?s say you decide to set aside half your address space for ?future allocation schemes?. >> >> Each POP needs a /32. >> We can combine the Region/POP number into an 8-bit field ? You need a /24 per Region. >> You need 3 additional bits for your higher level sub-divisions. Let?s round to a nibble boundary and give you a /20. >> >> With that /20, you can support up to 67 Million end sites in your first plan still leaving 3/4 of your address space fallow. >> >> (That?s at /48 per end-site, by the way). >> >> Now, let?s consider: 7 Billion People, each of which represents 32 different end-sites ? 224 billion end-sites world wide. >> 224,000,000,000 / 67,000,000 = 3,344 (rounded up) total ISPs requiring /20s to serve every possible end-site on the >> planet. >> >> >> There are 1,048,576 /20s total, so after allocating all the ISPs in the world /20s, we still have 1,045,232 remaining. >> >> Let?s assume that every end-site goes with dual-address multi-homing (an IPv6 prefix from each provider). >> >> We are now left with only 1,041,888 /20s remaining. You still haven?t put a dent in it. >> >> Even if we divide by 8 and just consider the current /3 being allocated as global unicast, you still have 130,236 free /20s >> left. >> >>> Granted, this is just a silly example, and I don't have to divide my >>> address space like this. In fact, I really can't, unless I want to have >>> more than 32 customers per city. But I don't think it's a very >>> far-fetched example. >> It?s not? It?s a great example of how not to plan your address space in IPv6. >> >> However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don?t make a dent in the IPv6 free pool. Everyone wins. >> >>> Perhaps I'm missing something obvious here, but it seems to me that it >>> would've been nice to have these kinds of possibilities, and more. It >>> seems counterintuitive, especially given the "IPv6 way of thinking" >>> which is normally encouraged: "stop counting beans, this isn't IPv4?. >> The problem is that you not only stopped counting beans, you stopped counting bean piles and you lost track of just how big the pile that you are making smaller piles from really is. >> >> I hope that this will show you a better way. >> >> Owen >> From mel at beckman.org Thu Jul 9 02:32:35 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 02:32:35 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559DDADD.7000606@lugosys.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com> <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com>, <559DDADD.7000606@lugosys.com> Message-ID: Israel, You have to draw the limbs somewhere. Why not 512 bits? 1024? The IETF engineers that thought about this long and hard and discussed the topic we've just had, and a thousands of other topics, decided on 128. I'm inclined to give them the benefit of the doubt. :) -mel via cell > On Jul 8, 2015, at 7:23 PM, Israel G. Lugo wrote: > > > >> On 07/09/2015 02:31 AM, Owen DeLong wrote: >> Here?s the problem? You started at the wrong end and worked in the wrong direction in your planning. >> >> [...get larger allocation...] >> >> We are now left with only 1,041,888 /20s remaining. You still haven?t put a dent in it. > > I am aware of the math, and how it can fit. I will concede that a /20 is > sufficient. > > Note, however, the difference in orders of magnitude for typical > allocations. I realize in ARIN side you've got e.g. Comcast with > multiple /20s, but in RIPE that is not so common. My home ISP has 3x > /32s. As I said, default ISP/LIR allocation here is from /32 to /29. > Yes, shorter prefixes can be justified and obtained, but it's not the norm. > > >> It?s not? It?s a great example of how not to plan your address space in IPv6. >> >> However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don?t make a dent in the IPv6 free pool. Everyone wins. > > You basically just said "get a larger allocation"... Which was my point > all along. /32 is not enough, and even /24 could be made much roomier. > > Speaking of IPv6's full potential: we're considering 32 subscriptions > per client. I've read people thinking of things like IPv6-aware soda > cans. Refrigerators. Wearables. Cars and their internal components... > You could have the on-board computer talking to the suspension via IPv6, > and reporting back to the manufacturer or whatnot. > > Personally, I'm not particularly fond of the whole "refrigerators > ordering milk bottles" craze, but hey, it may very well become a thing. > And other stuff we haven't thought of yet. > > My point is: we're changing to a brand new protocol, and only now > beginning to scratch its full potential. Yes, everything seems very big > right now. Yes, 128 bits can be enough. Even 64 bits could be more than > enough. But why limit ourselves? Someone decided (corretly) that 64 > would be too limiting. > > Please don't fall into the usual "you've got more addresses than > atoms"... I've heard that, and am not disputing it. I'm not just talking > about individual addresses (or /48's). > > What I am proposing here, as food for thought, is: what if we had e.g. > 192 bits, or 256? For one, we could have much sparser allocations. Heck, > we could even go as far as having a bit for each day of the month. What > would this be good for? I don't know. Perhaps someone may come up with a > use for it. > From mel at beckman.org Thu Jul 9 02:34:58 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 02:34:58 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559DDBE9.2060401@lugosys.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com>, <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com> <05E8D728-9A7E-4C3C-B97F-276EF3CBCEB9@beckman.org>, <559DDBE9.2060401@lugosys.com> Message-ID: <72494BCB-6AFF-4471-92A3-A6034B5F2F69@beckman.org> None of those applications benefit from address mapping. They can be done with IPv6 as it stands today. This is where the atoms argument you don't want us to make comes in :) -mel via cell > On Jul 8, 2015, at 7:27 PM, Israel G. Lugo wrote: > > I'm sorry Mel, I only now saw your email. > > I'll quote from my reply to Owen, for the motivation behind my question: > >> Speaking of IPv6's full potential: we're considering 32 subscriptions >> per client. I've read people thinking of things like IPv6-aware soda >> cans. Refrigerators. Wearables. Cars and their internal components... >> You could have the on-board computer talking to the suspension via IPv6, >> and reporting back to the manufacturer or whatnot. >> >> Personally, I'm not particularly fond of the whole "refrigerators >> ordering milk bottles" craze, but hey, it may very well become a thing. >> And other stuff we haven't thought of yet. >> >> My point is: we're changing to a brand new protocol, and only now >> beginning to scratch its full potential. Yes, everything seems very big >> right now. Yes, 128 bits can be enough. Even 64 bits could be more than >> enough. But why limit ourselves? Someone decided (corretly) that 64 >> would be too limiting. >> >> Please don't fall into the usual "you've got more addresses than >> atoms"... I've heard that, and am not disputing it. I'm not just talking >> about individual addresses (or /48's). >> >> What I am proposing here, as food for thought, is: what if we had e.g. >> 192 bits, or 256? For one, we could have much sparser allocations. Heck, >> we could even go as far as having a bit for each day of the month. What >> would this be good for? I don't know. Perhaps someone may come up with a >> use for it. > > Regards, > Israel > > > >> On 07/09/2015 02:46 AM, Mel Beckman wrote: >> Israel, >> >> A better question is why bit-map your allocation plan at all? That seems ill advised, since you must arbitrarily allocate huge swaths of ip space equally between category classes when it's rarely efficient to do so. For example, two bits for network infrastructure because infrastructure addresses are likely far fewer than any customer class. Similarly three bits for geographic region on the /38 boundary illogically assumes all geographic regions are the same size. >> >> There isn't a good routing reason for a bitwise address structure, since nobody routes that way. The only other rationale I can think of is human mnemonic value, but 128-bit addresses are not very amenable to such mnemonics (::DEAD:BEEF not withstanding :) >> >> -mel beckman >> >>> On Jul 8, 2015, at 6:32 PM, Owen DeLong wrote: >>> >>> >>>> Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: >>>> >>>> - I reserve 1 bit for future allocation schemes, leaving me a /33; >>>> - 2 bits for network type (infrastructure, residential, business, LTE): /35 >>>> - 3 bits for geographic region, state, whatever: /38 >>>> - 5 bits for PoP, or city: /43 >>>> >>>> This leaves me 5 bits for end sites: no joy. >>> Here?s the problem? You started at the wrong end and worked in the wrong direction in your planning. >>> >>> Let?s say you?re a national ISP. Let?s say you want to support 4 levels of aggregation. >>> Let?s say that at the lowest level (POP/City) you serve 50,000 end-sites in your largest POP/City. (16 bits) >>> Let?s say you plan to max out at 32 POPs/Cities per region (your number from above) (5 bits) >>> Let?s say you plan to divide the country into 8 regions (3 bits) >>> Let?s say for some reason you want to break your aggregation along the lines of service class (infrastructure, residential, business) >>> as your top level division (rarely a good idea, but I?ll go with it for now) and that you have 4 service classes (2 bits) >>> Further, let?s say you decide to set aside half your address space for ?future allocation schemes?. >>> >>> Each POP needs a /32. >>> We can combine the Region/POP number into an 8-bit field ? You need a /24 per Region. >>> You need 3 additional bits for your higher level sub-divisions. Let?s round to a nibble boundary and give you a /20. >>> >>> With that /20, you can support up to 67 Million end sites in your first plan still leaving 3/4 of your address space fallow. >>> >>> (That?s at /48 per end-site, by the way). >>> >>> Now, let?s consider: 7 Billion People, each of which represents 32 different end-sites ? 224 billion end-sites world wide. >>> 224,000,000,000 / 67,000,000 = 3,344 (rounded up) total ISPs requiring /20s to serve every possible end-site on the >>> planet. >>> >>> >>> There are 1,048,576 /20s total, so after allocating all the ISPs in the world /20s, we still have 1,045,232 remaining. >>> >>> Let?s assume that every end-site goes with dual-address multi-homing (an IPv6 prefix from each provider). >>> >>> We are now left with only 1,041,888 /20s remaining. You still haven?t put a dent in it. >>> >>> Even if we divide by 8 and just consider the current /3 being allocated as global unicast, you still have 130,236 free /20s >>> left. >>> >>>> Granted, this is just a silly example, and I don't have to divide my >>>> address space like this. In fact, I really can't, unless I want to have >>>> more than 32 customers per city. But I don't think it's a very >>>> far-fetched example. >>> It?s not? It?s a great example of how not to plan your address space in IPv6. >>> >>> However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don?t make a dent in the IPv6 free pool. Everyone wins. >>> >>>> Perhaps I'm missing something obvious here, but it seems to me that it >>>> would've been nice to have these kinds of possibilities, and more. It >>>> seems counterintuitive, especially given the "IPv6 way of thinking" >>>> which is normally encouraged: "stop counting beans, this isn't IPv4?. >>> The problem is that you not only stopped counting beans, you stopped counting bean piles and you lost track of just how big the pile that you are making smaller piles from really is. >>> >>> I hope that this will show you a better way. >>> >>> Owen > From mel at beckman.org Thu Jul 9 02:35:20 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 02:35:20 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com> <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com>, <559DDADD.7000606@lugosys.com>, Message-ID: Draw the lines -mel via cell > On Jul 8, 2015, at 7:33 PM, Mel Beckman wrote: > > Israel, > > You have to draw the limbs somewhere. Why not 512 bits? 1024? The IETF engineers that thought about this long and hard and discussed the topic we've just had, and a thousands of other topics, decided on 128. I'm inclined to give them the benefit of the doubt. :) > > -mel via cell > >> On Jul 8, 2015, at 7:23 PM, Israel G. Lugo wrote: >> >> >> >>> On 07/09/2015 02:31 AM, Owen DeLong wrote: >>> Here?s the problem? You started at the wrong end and worked in the wrong direction in your planning. >>> >>> [...get larger allocation...] >>> >>> We are now left with only 1,041,888 /20s remaining. You still haven?t put a dent in it. >> >> I am aware of the math, and how it can fit. I will concede that a /20 is >> sufficient. >> >> Note, however, the difference in orders of magnitude for typical >> allocations. I realize in ARIN side you've got e.g. Comcast with >> multiple /20s, but in RIPE that is not so common. My home ISP has 3x >> /32s. As I said, default ISP/LIR allocation here is from /32 to /29. >> Yes, shorter prefixes can be justified and obtained, but it's not the norm. >> >> >>> It?s not? It?s a great example of how not to plan your address space in IPv6. >>> >>> However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don?t make a dent in the IPv6 free pool. Everyone wins. >> >> You basically just said "get a larger allocation"... Which was my point >> all along. /32 is not enough, and even /24 could be made much roomier. >> >> Speaking of IPv6's full potential: we're considering 32 subscriptions >> per client. I've read people thinking of things like IPv6-aware soda >> cans. Refrigerators. Wearables. Cars and their internal components... >> You could have the on-board computer talking to the suspension via IPv6, >> and reporting back to the manufacturer or whatnot. >> >> Personally, I'm not particularly fond of the whole "refrigerators >> ordering milk bottles" craze, but hey, it may very well become a thing. >> And other stuff we haven't thought of yet. >> >> My point is: we're changing to a brand new protocol, and only now >> beginning to scratch its full potential. Yes, everything seems very big >> right now. Yes, 128 bits can be enough. Even 64 bits could be more than >> enough. But why limit ourselves? Someone decided (corretly) that 64 >> would be too limiting. >> >> Please don't fall into the usual "you've got more addresses than >> atoms"... I've heard that, and am not disputing it. I'm not just talking >> about individual addresses (or /48's). >> >> What I am proposing here, as food for thought, is: what if we had e.g. >> 192 bits, or 256? For one, we could have much sparser allocations. Heck, >> we could even go as far as having a bit for each day of the month. What >> would this be good for? I don't know. Perhaps someone may come up with a >> use for it. >> From kauer at biplane.com.au Thu Jul 9 02:49:17 2015 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 09 Jul 2015 12:49:17 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> References: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> Message-ID: <1436410157.27450.66.camel@karl> On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote: > I wasn't aware that residential users had (intentionally) multiple > layers of routing within the home. You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE. What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples. Multiple layers of routing might not be what is now in the home, but it doesn't take that much imagination to envision a future where there are hundreds, or even thousands of separate networks in the average home, some permanent, some ephemeral, and quite possibly all requiring end-to-end connectivity into the wider Internet. Taking into account just a few current technologies (virtual machines, car networks, personal networks, guest networks, entertainment systems) and fast-forwarding just a few years it's easy to imagine tens of subnets being needed - so it's not much of a leap to hundreds. And if we can already dimly see a future where hundreds might be needed, history tells us that there will probably be applications that need thousands. Unless of course we decide now that we don't WANT that. Then we should make it hard for it to happen by applying entirely arbitrary brakes like "/48 sounds too big to me, let's make it 1/256th of that." Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From fergdawgster at mykolab.com Thu Jul 9 02:59:44 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 8 Jul 2015 19:59:44 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1436410157.27450.66.camel@karl> References: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> <1436410157.27450.66.camel@karl> Message-ID: <559DE3A0.2050403@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/8/2015 7:49 PM, Karl Auer wrote: > On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote: >> I wasn't aware that residential users had (intentionally) >> multiple layers of routing within the home. > > You, we, all of us have to stop using the present to limit the > future. What IS should not be used to define what SHOULD BE. > Thank you, Karl, for that. > Unless of course we decide now that we don't WANT that. Then we > should make it hard for it to happen by applying entirely arbitrary > brakes like "/48 sounds too big to me, let's make it 1/256th of > that." > Pop history: "640k should been enough for anyone..." http://archive.wired.com/politics/law/news/1997/01/1484 - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWd46AACgkQKJasdVTchbJlmAD+Mhv0aFvbyIN+wONv2Zyr042/ tixT8If2oJxWJ9Y7+uwBANKmA2OS7xe+IzNcQLP6tgc6/iV55Alg/FZ/azeHq/ZS =MU5e -----END PGP SIGNATURE----- From dave.taht at gmail.com Thu Jul 9 03:48:26 2015 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 8 Jul 2015 20:48:26 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1436410157.27450.66.camel@karl> References: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> <1436410157.27450.66.camel@karl> Message-ID: On Wed, Jul 8, 2015 at 7:49 PM, Karl Auer wrote: > On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote: >> I wasn't aware that residential users had (intentionally) multiple >> layers of routing within the home. No, what they often have is multiple layers of nat. I was at a hotel once that had plugged in 12 APs, serially, wan, to lan, to wan, to lan, to wan ports... because the Internet is a series of tubes, right? > You, we, all of us have to stop using the present to limit the future. > What IS should not be used to define what SHOULD BE. > > What people NOW HAVE in their homes should not be used to dictate to > them what they CAN HAVE in their homes, which is what you do when you > provide them only with non-globally-routable address space (IPv4 NAT), > or too few subnets (IPv6 /56) to name just two examples. > > Multiple layers of routing might not be what is now in the home, but it > doesn't take that much imagination to envision a future where there are > hundreds, or even thousands of separate networks in the average home, > some permanent, some ephemeral, and quite possibly all requiring > end-to-end connectivity into the wider Internet. Taking into account > just a few current technologies (virtual machines, car networks, > personal networks, guest networks, entertainment systems) and > fast-forwarding just a few years it's easy to imagine tens of subnets > being needed - so it's not much of a leap to hundreds. And if we can > already dimly see a future where hundreds might be needed, history tells > us that there will probably be applications that need thousands. > > Unless of course we decide now that we don't WANT that. Then we should > make it hard for it to happen by applying entirely arbitrary brakes like > "/48 sounds too big to me, let's make it 1/256th of that." In my case I have completely abandoned much of the debris of ipv4 and ipv6 - using self assigned /128s and a mesh routing protocol everywhere, giving up on multicast as we knew it, and all I need is one /64 to route my (almost entirely wireless) world. Somehow I doubt this will become a common option for others, but it sure is easier than navigating the slew of standards, configuring centralized services, and casting and configuring limited and highly dynamic ipv6 subnets around. > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 > > -- Dave T?ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From jfbeam at gmail.com Thu Jul 9 04:10:36 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 00:10:36 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> References: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, 08 Jul 2015 21:19:52 -0400, Mike Hammett wrote: > /56 even seems a bit excessive for a residential user, but *shrugs* That's why some hand out a /60, but only if you ask for it. Otherwise, you get only a single /64. Of course, HE will give you a /48 at the click of the mouse. From jfbeam at gmail.com Thu Jul 9 04:40:36 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 00:40:36 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <7579.1436408004@turing-police.cc.vt.edu> References: <1329877493.3.1436404823201.JavaMail.mhammett@ThunderFuck> <7579.1436408004@turing-police.cc.vt.edu> Message-ID: On Wed, 08 Jul 2015 22:13:24 -0400, wrote: > On Wed, 08 Jul 2015 20:19:52 -0500, Mike Hammett said: >> /56 even seems a bit excessive for a residential user, but *shrugs* > > It goes pretty quick when each WNDR3800 running CeroWRT will chew through > 4 bits worth of subnets just by powering on, and even more if you start > doing any VLAN stuff.... and then you put a second one at the far end > of the house for better coverage and it asks for its own PD space from > your main one..... If everyone wants their networks hobbled by shitty software routing, sure. There are plenty who stack their "wireless extension" LAN-WAN (creating double NAT) because they simply don't know jack about networking. There are over 100 million "home networks" in the country that are literally 100% out-of-the-box defaults. It comes out of the box, the color coded cables are connected to the color coded ports according to the Ikea pictorial diagram. And it better Just Work(tm), because they will never understand to configure any part of it -- doubly so for the *networking*. We are years (DECADES) from a multi-network default. Hell, it's been 20 years and IPv6 is still not more a foot off the ground. (plus, it's been rewritten a dozen times.) From jfbeam at gmail.com Thu Jul 9 04:45:36 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 00:45:36 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com> <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com> <559DDADD.7000606@lugosys.com> Message-ID: On Wed, 08 Jul 2015 22:32:35 -0400, Mel Beckman wrote: > You have to draw the limbs somewhere. Why not 512 bits? 1024? The IETF > engineers that thought about this long and hard and discussed the topic > we've just had, and a thousands of other topics, decided on 128. I'm > inclined to give them the benefit of the doubt. :) Actually, it was *64*, but SLAAC's use of MAC would've left only 16 bits. Adding it on meant a 112bit network. Round up and we get 128! From jfbeam at gmail.com Thu Jul 9 04:55:36 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 00:55:36 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1436410157.27450.66.camel@karl> References: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> <1436410157.27450.66.camel@karl> Message-ID: On Wed, 08 Jul 2015 22:49:17 -0400, Karl Auer wrote: > You, we, all of us have to stop using the present to limit the future. > What IS should not be used to define what SHOULD BE. > > What people NOW HAVE in their homes should not be used to dictate to > them what they CAN HAVE in their homes, which is what you do when you > provide them only with non-globally-routable address space (IPv4 NAT), > or too few subnets (IPv6 /56) to name just two examples. Talking about IPv6, we aren't carving a limit in granite. 99.99999% of home networks currently have no need for multiple networks, and thus, don't ask for anything more; they get a single /64 prefix. If tomorrow they need more, set the hint to 60 and they get a /60. Need more, ask for 56... CURRENTLY, providers have their DHCP server(s) set to a limit of 56. But that's simply a number in a config file; it can be changed as easily as it was set the first time. (source pool size and other infrastructure aside.) It's just like the escalation of speeds: as the need for it rises, it becomes available. (in general, at least) From marka at isc.org Thu Jul 9 05:16:52 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Jul 2015 15:16:52 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Thu, 09 Jul 2015 00:55:36 -0400." References: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> <1436410157.27450.66.camel@karl> Message-ID: <20150709051652.8C755328E767@rock.dv.isc.org> In message , "Ricky Beam" writes: > On Wed, 08 Jul 2015 22:49:17 -0400, Karl Auer wrote: > > You, we, all of us have to stop using the present to limit the future. > > What IS should not be used to define what SHOULD BE. > > > > What people NOW HAVE in their homes should not be used to dictate to > > them what they CAN HAVE in their homes, which is what you do when you > > provide them only with non-globally-routable address space (IPv4 NAT), > > or too few subnets (IPv6 /56) to name just two examples. > > Talking about IPv6, we aren't carving a limit in granite. 99.99999% of > home networks currently have no need for multiple networks, and thus, > don't ask for anything more; they get a single /64 prefix. If tomorrow > they need more, set the hint to 60 and they get a /60. Need more, ask for > 56... CURRENTLY, providers have their DHCP server(s) set to a limit of 56. > But that's simply a number in a config file; it can be changed as easily > as it was set the first time. (source pool size and other infrastructure > aside.) It's just like the escalation of speeds: as the need for it rises, > it becomes available. (in general, at least) I already have 3 /64's hanging off a WNDR3700 (one for each of the wireless networks and one for the wired). If I turn on the second ssid's for each radio that would be 5. As for a customer getting a ISP's to increase the /56 PD to a /52 or a /48 I just don't see that happening. It will either require custom configuration for the customer or going back to the RIR and asking for a bigger allocation based on moving from /56 to /52 or /48 for all customers. You then have to manage the transition. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From baldur.norddahl at gmail.com Thu Jul 9 06:16:15 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Jul 2015 08:16:15 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150709051652.8C755328E767@rock.dv.isc.org> References: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> <1436410157.27450.66.camel@karl> <20150709051652.8C755328E767@rock.dv.isc.org> Message-ID: Hi, With RIPE you can get a /29 with no justification, so if you have any less it is because you did not bother logging in to ripe.net and hit the get more button. ARIN gives you the option to make a network scheme based on nibbles but RIPE does not, so do not go there. Why try to allocate by the bit at all? We all use internal routing protocols instead of static routing. The only concern is to avoid an excess amount of internal routes in your IGP. You do that by using an allocation size per site, so your local routers can do route aggregation before redistributing the routes. We have an allocation size of /42 per site. A site can have and usually have multiple /42 allocated. This size was chosen because we allocate a /26 of IPv4 per site (=6 bits per allocation or blocks of 64). We are a residual ISP and it is expected that each customer needs one /32 IPv4 and one /48 IPv6 prefix. Our allocation of /32 IPv4 and /48 IPv6 is approximately the same utilization. In fact we made an algorithm that can convert your IPv4 /32 to your IPv6 /48, so we avoid tracking two allocations per user. Our smallest access routers can handle about 30k routes. But long before we hit that, I expect we would add another layer of aggregation. The case of using a bit based allocation scheme is so you can avoid that database (or spreadsheet) keeping track of your allocations. But I found that you need that either way or you will go crazy. The ability to look at an allocation and say hmm digit 10 is between 8 and f, so that must be somewhere in [insert big city here]... well it does just not seem that useful. Check our reverse DNS if you want to know. Regards, Baldur From seth.mos at dds.nl Thu Jul 9 07:42:43 2015 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 09 Jul 2015 09:42:43 +0200 Subject: Dual stack IPv6 for IPv4 depletion Message-ID: Residential users just buy another router for wifi coverage at the local wall mart. They have no clue about anything internet. That is why isp CPE devices should always perform dhcp-pd on their own to provide a prefix to the downstream devices so those have globally routed ipv6 too. For that to work you need concepts like route aggregation in the form of a /48 for the CPE so it can hand out a /56 to the customer bought CPE. Seth -------- Oorspronkelijk bericht -------- Van: Mike Hammett Datum: 09-07-2015 04:03 (GMT+01:00) Aan: nanog at nanog.org Onderwerp: Re: Dual stack IPv6 for IPv4 depletion I wasn't aware that residential users had (intentionally) multiple layers of routing within the home. I'm also not sure what address length has to do with routability, other than networks filtering prefix lengths. If that's an issue, that customer is covered by the ISP's larger allocation, or they get their own PI space if they're BGPing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Karl Auer" To: nanog at nanog.org Sent: Wednesday, July 8, 2015 8:36:41 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, 2015-07-08 at 19:57 -0500, Mike Hammett wrote: > Isn't /56 the standard end-user allocation? No - it's just a common one. And a bad one. /48s for all opens up a whole different world of end-user reachability, routability and flexibility that a mere /56 does not. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From owen at delong.com Thu Jul 9 08:17:19 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 01:17:19 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559DDADD.7000606@lugosys.com> References: <20150705034126.10907.qmail@ary.lan> <212314.1436079080@turing-police.cc.vt.edu> <89ACFD61-0E68-4E6E-9D30-0530B23B24A8@delong.com> <559DB604.8060901@lugosys.com> <20150708235918.B41A53286089@rock.dv.isc.org> <559DC43E.5020005@lugosys.com> <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com> <559DDADD.7000606@lugosys.com> Message-ID: <65560D19-16EE-4C39-9DED-8A8B74446E9C@delong.com> > On Jul 8, 2015, at 19:22 , Israel G. Lugo wrote: > > > > On 07/09/2015 02:31 AM, Owen DeLong wrote: >> Here?s the problem? You started at the wrong end and worked in the wrong direction in your planning. >> >> [...get larger allocation...] >> >> We are now left with only 1,041,888 /20s remaining. You still haven?t put a dent in it. > > I am aware of the math, and how it can fit. I will concede that a /20 is > sufficient. > > Note, however, the difference in orders of magnitude for typical > allocations. I realize in ARIN side you've got e.g. Comcast with > multiple /20s, but in RIPE that is not so common. My home ISP has 3x > /32s. As I said, default ISP/LIR allocation here is from /32 to /29. > Yes, shorter prefixes can be justified and obtained, but it's not the norm. Poor allocation practice and/or policy in RIPE is something that should be solved through education and policy change where needed. The fact that such is apparently commonplace in RIPE is probably an artifact of the RIPE region having deployed IPv6 a bit ahead of much of the world. In part, it?s probably cultural artifact. In any case, since there?s still a lot of networks that haven?t really deployed IPv6, let?s stop teaching bad ways to do things and focus on doing better going forward. > > >> It?s not? It?s a great example of how not to plan your address space in IPv6. >> >> However, if we repeat the same exercise in the correct direction, not only does each of your end-sites get a /48, you get the /20 you need in order to properly deploy your network. You get lots of space left over, and we still don?t make a dent in the IPv6 free pool. Everyone wins. > > You basically just said "get a larger allocation"... Which was my point > all along. /32 is not enough, and even /24 could be made much roomier. Sure? And if you need larger allocations, they should be very easy to get. I haven?t yet built anything that needed more than a /24. However, I have now obtained 3 /24s from ARIN for 3 different networks and not had significant difficulty with any of the 3. > Speaking of IPv6's full potential: we're considering 32 subscriptions > per client. I've read people thinking of things like IPv6-aware soda > cans. Refrigerators. Wearables. Cars and their internal components... > You could have the on-board computer talking to the suspension via IPv6, > and reporting back to the manufacturer or whatnot. Yes, but each of those wouldn?t require its own subscription/network. Most of those things would aggregate into one or more of your wireless networks. By subscriptions, I was literally talking about different ISP connections. 32 is massive overkill? Very few people today have more than 5. Each cellular device is essentially one since there?s no real local aggregation available. However, everything on the wired and wireless networks in your home would probably share a single attachment. Your car might be its own attachment or might use one or more of your cellular attachments. Your soda cans, refrigerators, wearables, etc. would most likely use one of your fixed or mobile attachments. > Personally, I'm not particularly fond of the whole "refrigerators > ordering milk bottles" craze, but hey, it may very well become a thing. > And other stuff we haven't thought of yet. What I think will become more common than refrigerators ordering things is refrigerators providing inventory management capabilities (including load cells in the shelves that work with positional RFID sensors so that you not only know that you have 3 bottles of milk in the fridge, but can tell where in the fridge and how much in each bottle). Zap a QR-Code for a recipe with your cell phone, and the fridge checks in with the cabinets and sends back a list of what you need to buy vs. what you already have in inventory. > My point is: we're changing to a brand new protocol, and only now > beginning to scratch its full potential. Yes, everything seems very big > right now. Yes, 128 bits can be enough. Even 64 bits could be more than > enough. But why limit ourselves? Someone decided (corretly) that 64 > would be too limiting. The additional consumptions you?re talking about all fit within the model I described. You?re either expanding the number of things in the house that are hosts or you?re expanding the number of hosts attached to one of the mobile attach points. I used 32 attach points per person on the planet with the full population of planet earth to be deliberately conservative in the potential number of ISP connections required. > Please don't fall into the usual "you've got more addresses than > atoms"... I've heard that, and am not disputing it. I'm not just talking > about individual addresses (or /48's). I don?t think I did. Nor did I talk about individual /48s. > What I am proposing here, as food for thought, is: what if we had e.g. > 192 bits, or 256? For one, we could have much sparser allocations. Heck, > we could even go as far as having a bit for each day of the month. What > would this be good for? I don't know. Perhaps someone may come up with a > use for it. Given that prefix length is baked into the protocol and very hard to change, I?m not eager to abandon what progress has been made deploying IPv6 to go chasing a larger bit field any time soon. If you think you?ve got something that will convince everyone to rewrite all their software again, go for it, but I?m skeptical as to the potential success of such an endeavor. However, if you do, I have just one request? Please add a 64-bit field to the packet header for ?routing destination identifier? so we can do something more intelligent than LISP without encapsulation. Owen From owen at delong.com Thu Jul 9 08:23:32 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 01:23:32 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> <1436410157.27450.66.camel@karl> Message-ID: > On Jul 8, 2015, at 21:55 , Ricky Beam wrote: > > On Wed, 08 Jul 2015 22:49:17 -0400, Karl Auer wrote: >> You, we, all of us have to stop using the present to limit the future. >> What IS should not be used to define what SHOULD BE. >> >> What people NOW HAVE in their homes should not be used to dictate to >> them what they CAN HAVE in their homes, which is what you do when you >> provide them only with non-globally-routable address space (IPv4 NAT), >> or too few subnets (IPv6 /56) to name just two examples. > > Talking about IPv6, we aren't carving a limit in granite. 99.99999% of home networks currently have no need for multiple networks, and thus, don't ask for anything more; they get a single /64 prefix. If tomorrow they need more, set the hint to 60 and they get a /60. Need more, ask for 56... CURRENTLY, providers have their DHCP server(s) set to a limit of 56. But that's simply a number in a config file; it can be changed as easily as it was set the first time. (source pool size and other infrastructure aside.) It's just like the escalation of speeds: as the need for it rises, it becomes available. (in general, at least) But we are carving a limit in stone without realizing it. Changing the network to give out larger prefixes is easy. However, developers consistently develop to the lowest common denominator. Don?t believe me? Try to use any of a variety of mobile apps to control a non-NAT device in your home from your cell phone when you?re not in the same broadcast domain as the device you want to control. The developers have assumed that: 1. Every household is behind NAT 2. Every household is a single broadcast domain 3. There?s never any need to talk to a device that isn?t within the same broadcast domain as the handset. 4. Nobody would ever want to use their cell phone to control their $PRODUCT without putting it on the wifi network and the $PRODUCT wired network interface will always be bridged to the wifi on the same subnet, right? Given how baked in these bad assumptions have become, I shudder at the thought of how long after ISPs start issuing /48s it will take before we start to see useful products designed with that expectation in mind. Owen From mel at beckman.org Thu Jul 9 10:30:10 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 10:30:10 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> <1436410157.27450.66.camel@karl>, Message-ID: <285584CA-A9F5-4E41-83BE-DD15E1C739CD@beckman.org> Using one-byte buffers, one hopes. :) -mel via cell > On Jul 8, 2015, at 8:49 PM, Dave Taht wrote: > >> On Wed, Jul 8, 2015 at 7:49 PM, Karl Auer wrote: >>> On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote: >>> I wasn't aware that residential users had (intentionally) multiple >>> layers of routing within the home. > > No, what they often have is multiple layers of nat. I was at a hotel > once that had plugged in 12 APs, serially, wan, to lan, to wan, to > lan, to wan ports... because the Internet is a series of tubes, right? > >> You, we, all of us have to stop using the present to limit the future. >> What IS should not be used to define what SHOULD BE. >> >> What people NOW HAVE in their homes should not be used to dictate to >> them what they CAN HAVE in their homes, which is what you do when you >> provide them only with non-globally-routable address space (IPv4 NAT), >> or too few subnets (IPv6 /56) to name just two examples. >> >> Multiple layers of routing might not be what is now in the home, but it >> doesn't take that much imagination to envision a future where there are >> hundreds, or even thousands of separate networks in the average home, >> some permanent, some ephemeral, and quite possibly all requiring >> end-to-end connectivity into the wider Internet. Taking into account >> just a few current technologies (virtual machines, car networks, >> personal networks, guest networks, entertainment systems) and >> fast-forwarding just a few years it's easy to imagine tens of subnets >> being needed - so it's not much of a leap to hundreds. And if we can >> already dimly see a future where hundreds might be needed, history tells >> us that there will probably be applications that need thousands. >> >> Unless of course we decide now that we don't WANT that. Then we should >> make it hard for it to happen by applying entirely arbitrary brakes like >> "/48 sounds too big to me, let's make it 1/256th of that." > > In my case I have completely abandoned much of the debris of ipv4 and > ipv6 - using self assigned /128s and a mesh routing protocol > everywhere, giving up on multicast as we knew it, and all I need is > one /64 to route my (almost entirely wireless) world. > > Somehow I doubt this will become a common option for others, but it > sure is easier than navigating the slew of standards, configuring > centralized services, and casting and configuring limited and highly > dynamic ipv6 subnets around. > > >> Regards, K. >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Karl Auer (kauer at biplane.com.au) >> http://www.biplane.com.au/kauer >> http://twitter.com/kauer389 >> >> GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 >> Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 > > > > -- > Dave T?ht > worldwide bufferbloat report: > http://www.dslreports.com/speedtest/results/bufferbloat > And: > What will it take to vastly improve wifi for everyone? > https://plus.google.com/u/0/explore/makewififast From dot at dotat.at Thu Jul 9 11:17:17 2015 From: dot at dotat.at (Tony Finch) Date: Thu, 9 Jul 2015 12:17:17 +0100 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <938290885.112.1436407455754.JavaMail.mhammett@ThunderFuck> <1436410157.27450.66.camel@karl> Message-ID: Ricky Beam wrote: > > Talking about IPv6, we aren't carving a limit in granite. 99.99999% of home > networks currently have no need for multiple networks, and thus, don't ask for > anything more; they get a single /64 prefix. Personal-area networks already exist. Phone/watch/laptop etc. Virtual machines are common, e.g. for running multiple different operating systems on your computer. And automotive networks need connectivity. There are often separate VLANs for VOIP and IP TV and smart meters. Separate wifi networks tuned for low-latency synchronized audio. So it's very common to have multiple networks in a home with multiple layers of routing. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Rockall: South or southeast 5 or 6, increasing 6 or 7 later. Moderate, occasionally rough. Rain, fog patches. Moderate, occasionally very poor. From mark.tinka at seacom.mu Thu Jul 9 11:25:36 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 9 Jul 2015 13:25:36 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> <559D7049.2010102@seacom.mu> Message-ID: <559E5A30.7030508@seacom.mu> On 8/Jul/15 21:32, Owen DeLong wrote: > I think the ?THING? that people are starting to worry about is how to deploy a network when you can?t get IPv4 space for it at a reasonable price. I suppose the issue will become "more real" when you can't get any IPv4 space period. Mark. From jared at puck.nether.net Thu Jul 9 11:27:16 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Jul 2015 07:27:16 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> Message-ID: <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> Really just people not patching their software after warnings more than six months ago: July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. Jared Mauch > On Jul 8, 2015, at 1:15 PM, Michel Luczak wrote: > > >> On 08 Jul 2015, at 18:58, Mark Mayfield wrote: >> >> Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. > > Not sure it?s related but I?ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. > > Regards, Michel From mark.tinka at seacom.mu Thu Jul 9 11:30:33 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 9 Jul 2015 13:30:33 +0200 Subject: How to build an IPv6-only internal network? In-Reply-To: References: Message-ID: <559E5B59.3060904@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 8/Jul/15 22:23, Fred Baker (fred) wrote: > > (2) they use NAT64 (RFC 6146/6147) translation The only issue with NAT64 is that you still need some IPv4 space. If you can't get any anymore, despite all the millions of $$ in your bank, then we'll see massively overlayed NAT, and perhaps service providers selling "Quadruple Overlay NAT as a Service" :-\. Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVnltZAAoJEGcZuYTeKm+GtyIP/3Eo9pPRW2dRYt67s2xx2fMI 2Oia8efH3ZEBrFOgSHBsBmmxeewP+CGcmosQ8uSFSXCKLLKDCl996wVPu9dmKTGO WORwzoy8EmUeuAKLsxd/CGHes1ExUijfFBf27hz0CA+qmRcINdh45RhQKLUb2EWs iNj6yF8OSRe9tZAk+caNbLJA5EDpq7XAYGIBv3z4wtW/Dr+DGbUJMsrTjzVEEFCS N81cXQep4risY58JLBmBlY7RuiK9xRqTtmwlK0KQeEPF05NK8xo5Nxi02fjF7TSF ZsMvHaLKFWtjwC5L+MJwVswgOEKaleFyi1QsICdEQnXdW6MObA/COdnI3VIOgJ1c bhjBmTN8PuXc3zrV+iIBctg241it7NPbf+dlRzQ5xm+pn6M3AymoLk+i6xpj/NSx D3nIpGmuZSiXs+PkpYXYU4C9SKib6sKOLX9/Nu5fo4oY4t/mJtpon439NAFpxPAI I5fEYFpXdIRop6KelT3b91auqwjVNUbqZxq9HbF7Sq/PJ0xkT0ivsKem/6xBdsNK dQeo8sqkmo97pQ+6qLjaGEw3C0XT1y8skXq0Y1hZZvGHvouVWgqLg+xwthu2qKfi JOLk7GWIkYj9gwMYUmKXFmOayjBCh/fWPXLxiVpSDss23asIARFRfSvG4XhjVUfI JplyKrXhqK4MTxK3wLz4 =1mCX -----END PGP SIGNATURE----- From colinj at gt86car.org.uk Thu Jul 9 11:44:49 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 9 Jul 2015 12:44:49 +0100 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> Message-ID: Hi Jared, thanks for update do you know provider/source ip of the source of the attack ? Colin > On 9 Jul 2015, at 12:27, Jared Mauch wrote: > > Really just people not patching their software after warnings more than six months ago: > > July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. > > Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. > > Jared Mauch > >> On Jul 8, 2015, at 1:15 PM, Michel Luczak wrote: >> >> >>> On 08 Jul 2015, at 18:58, Mark Mayfield wrote: >>> >>> Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. >> >> Not sure it?s related but I?ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. >> >> Regards, Michel From baldur.norddahl at gmail.com Thu Jul 9 12:53:14 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Jul 2015 14:53:14 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559E5A30.7030508@seacom.mu> References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> <559D7049.2010102@seacom.mu> <559E5A30.7030508@seacom.mu> Message-ID: On 9 July 2015 at 13:25, Mark Tinka wrote: > > I suppose the issue will become "more real" when you can't get any IPv4 > space period. > > Mark. > That will never happen. If you offer me $1000 per IPv4, then I will happily terminate some user contracts and sell their IP space to you... In fact it will never become even that expensive. With a marked price of $10 I am buying IP space for customers as needed and I will include free space in the contracts. If the price went to $100 I would tell all users that they need to pay monthly rent for their IP or alternative, the user would have to accept carrier NAT in some form. And then I would proceed to buy a new house for the money I make by selling address space. There is a ton of address space that is inefficient used. We will be able to buy excess from companies that "create" space by optimizing their existing space. There is a reason we have not seen any rise in the price even after multiple years with depletion in large parts of the world. Regards, Baldur From mark.tinka at seacom.mu Thu Jul 9 13:02:13 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 9 Jul 2015 15:02:13 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> <559D7049.2010102@seacom.mu> <559E5A30.7030508@seacom.mu> Message-ID: <559E70D5.4000008@seacom.mu> On 9/Jul/15 14:53, Baldur Norddahl wrote: > > That will never happen. If you offer me $1000 per IPv4, then I will happily > terminate some user contracts and sell their IP space to you... > > In fact it will never become even that expensive. With a marked price of > $10 I am buying IP space for customers as needed and I will include free > space in the contracts. If the price went to $100 I would tell all users > that they need to pay monthly rent for their IP or alternative, the user > would have to accept carrier NAT in some form. And then I would proceed to > buy a new house for the money I make by selling address space. > > There is a ton of address space that is inefficient used. We will be able > to buy excess from companies that "create" space by optimizing their > existing space. There is a reason we have not seen any rise in the price > even after multiple years with depletion in large parts of the world. In this particular case, I'm not concerned about the next ten years. Predicting what happens between now and then could have a fair degree of accuracy. I'm more concerned about what happens beyond that. I'm not sure I can accurately (even with large error margins) predict what happens then. All that said, I'm not trying to paint myself into that kind of corner. It is 2015, after all... Just don't tell my competitors... Mark. From nanog at ics-il.net Thu Jul 9 13:02:40 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 9 Jul 2015 08:02:40 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1436410157.27450.66.camel@karl> Message-ID: <469550651.308.1436446985586.JavaMail.mhammett@ThunderFuck> Sounds like someone's getting caught up in the hype of a few buzzwords. I can't imagine where more than a couple bits of separately isolated networks in a home would be required. Most of those things you mentioned have no need to be isolated and are just being used to support a decision that was already made than evidence that lead to a decision. I'm not advocating anyone do anything other than what best practices dictate, just that whomever came up with best practices got a little caught up in the moment. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Karl Auer" To: nanog at nanog.org Sent: Wednesday, July 8, 2015 9:49:17 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote: > I wasn't aware that residential users had (intentionally) multiple > layers of routing within the home. You, we, all of us have to stop using the present to limit the future. What IS should not be used to define what SHOULD BE. What people NOW HAVE in their homes should not be used to dictate to them what they CAN HAVE in their homes, which is what you do when you provide them only with non-globally-routable address space (IPv4 NAT), or too few subnets (IPv6 /56) to name just two examples. Multiple layers of routing might not be what is now in the home, but it doesn't take that much imagination to envision a future where there are hundreds, or even thousands of separate networks in the average home, some permanent, some ephemeral, and quite possibly all requiring end-to-end connectivity into the wider Internet. Taking into account just a few current technologies (virtual machines, car networks, personal networks, guest networks, entertainment systems) and fast-forwarding just a few years it's easy to imagine tens of subnets being needed - so it's not much of a leap to hundreds. And if we can already dimly see a future where hundreds might be needed, history tells us that there will probably be applications that need thousands. Unless of course we decide now that we don't WANT that. Then we should make it hard for it to happen by applying entirely arbitrary brakes like "/48 sounds too big to me, let's make it 1/256th of that." Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From nanog at ics-il.net Thu Jul 9 13:04:00 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 9 Jul 2015 08:04:00 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Message-ID: <1814626977.313.1436447066595.JavaMail.mhammett@ThunderFuck> Don't confuse someone's poor design with design goals. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Dave Taht" To: "Karl Auer" Cc: "NANOG" Sent: Wednesday, July 8, 2015 10:48:26 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, Jul 8, 2015 at 7:49 PM, Karl Auer wrote: > On Wed, 2015-07-08 at 21:03 -0500, Mike Hammett wrote: >> I wasn't aware that residential users had (intentionally) multiple >> layers of routing within the home. No, what they often have is multiple layers of nat. I was at a hotel once that had plugged in 12 APs, serially, wan, to lan, to wan, to lan, to wan ports... because the Internet is a series of tubes, right? > You, we, all of us have to stop using the present to limit the future. > What IS should not be used to define what SHOULD BE. > > What people NOW HAVE in their homes should not be used to dictate to > them what they CAN HAVE in their homes, which is what you do when you > provide them only with non-globally-routable address space (IPv4 NAT), > or too few subnets (IPv6 /56) to name just two examples. > > Multiple layers of routing might not be what is now in the home, but it > doesn't take that much imagination to envision a future where there are > hundreds, or even thousands of separate networks in the average home, > some permanent, some ephemeral, and quite possibly all requiring > end-to-end connectivity into the wider Internet. Taking into account > just a few current technologies (virtual machines, car networks, > personal networks, guest networks, entertainment systems) and > fast-forwarding just a few years it's easy to imagine tens of subnets > being needed - so it's not much of a leap to hundreds. And if we can > already dimly see a future where hundreds might be needed, history tells > us that there will probably be applications that need thousands. > > Unless of course we decide now that we don't WANT that. Then we should > make it hard for it to happen by applying entirely arbitrary brakes like > "/48 sounds too big to me, let's make it 1/256th of that." In my case I have completely abandoned much of the debris of ipv4 and ipv6 - using self assigned /128s and a mesh routing protocol everywhere, giving up on multicast as we knew it, and all I need is one /64 to route my (almost entirely wireless) world. Somehow I doubt this will become a common option for others, but it sure is easier than navigating the slew of standards, configuring centralized services, and casting and configuring limited and highly dynamic ipv6 subnets around. > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 > > -- Dave T?ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From frederik at kriewitz.eu Thu Jul 9 13:07:56 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Thu, 9 Jul 2015 15:07:56 +0200 Subject: Telia <> Globalcrossing ASH peering issue Message-ID: Hello, is someone from GBLX/Level 3/Telia around? It looks like there's a problem with one of your peerings/LAGs. The problem exists since 00:36 UTC working path: traceroute from 71.80.34.222 to 151.248.24.61 (151.248.24.61), 30 hops max, 40 byte packets 1 192.168.30.1 (192.168.30.1) 0.416 ms 0.917 ms 1.085 ms 2 192.168.1.2 (192.168.1.2) 0.620 ms 0.520 ms 0.468 ms 3 71-80-34-193.static.kgpt.tn.charter.com (71.80.34.193) 1.342 ms 1.538 ms 2.180 ms 4 71-80-34-152.static.kgpt.tn.charter.com (71.80.34.152) 1.835 ms 2.001 ms 2.061 ms 5 dtr02lncytn-tge-0-6-1-2.lncy.tn.charter.com (96.34.68.84) 1.774 ms 1.787 ms 1.860 ms 6 crr02kgpttn-tge-0-7-0-4.kgpt.tn.charter.com (96.34.69.27) 5.485 ms crr02kgpttn-tge-0-7-0-6.kgpt.tn.charter.com (96.34.71.100) 5.222 ms crr02kgpttn-tge-0- -0-5.kgpt.tn.charter.com (96.34.69.29) 5.257 ms 7 crr12spbgsc-bue-100.spbg.sc.charter.com (96.34.93.200) 11.958 ms 11.962 ms 11.988 ms 8 bbr01spbgsc-bue-4.spbg.sc.charter.com (96.34.2.50) 11.864 ms 12.505 ms 14.984 ms 9 cha-b1-link.telia.net (62.115.12.125) 11.356 ms 11.370 ms 11.391 ms 10 ash-bb3-link.telia.net (80.91.252.100) 19.172 ms 19.211 ms 19.210 ms 11 ash-b1-link.telia.net (62.115.113.207) 19.439 ms 21.042 ms 20.627 ms 12 globalcrossing-ic-150675-ash-bb1.c.telia.net (213.248.90.122) 19.593 ms 19.223 ms 19.291 ms 13 lag9.csr1.dca3.gblx.net (67.16.146.25) 28.340 ms 19.095 ms 19.117 ms 14 ae3.scr4.wdc2.gblx.net (67.16.166.229) 19.894 ms 19.936 ms 19.929 ms 15 xe10-1-0-10g.scr4.lon3.gblx.net (67.16.166.81) 94.114 ms 94.124 ms 94.428 ms 16 lag2.ar9.lon3.gblx.net (67.17.106.149) 95.592 ms 93.098 ms 93.086 ms 17 avanti-hylas-2-cyprus-ltd.ethernet23-1.ar9.lon3.gblx.net (159.63.52.6) 95.534 ms 92.612 ms 92.568 ms 18 88.210.183.37 (88.210.183.37) 168.082 ms 181.644 ms 181.669 ms 19 88.210.186.77 (88.210.186.77) 169.436 ms 168.871 ms 168.895 ms 20 static-151-248-24-61.nynex.de (151.248.24.61) 169.285 ms 169.200 ms 169.151 ms Broken path to a neighboring IP using another interconnect: traceroute from 71.80.34.222 to 151.248.24.62 (151.248.24.62), 30 hops max, 40 byte packets 1 192.168.30.1 (192.168.30.1) 0.409 ms 0.903 ms 1.073 ms 2 192.168.1.2 (192.168.1.2) 0.488 ms 0.581 ms 0.529 ms 3 71-80-34-193.static.kgpt.tn.charter.com (71.80.34.193) 1.512 ms 2.005 ms 2.305 ms 4 71-80-34-152.static.kgpt.tn.charter.com (71.80.34.152) 2.807 ms 2.753 ms 3.027 ms 5 dtr02lncytn-tge-0-6-1-2.lncy.tn.charter.com (96.34.68.84) 1.809 ms 1.814 ms 1.815 ms 6 crr02kgpttn-tge-0-7-0-4.kgpt.tn.charter.com (96.34.69.27) 5.551 ms crr02kgpttn-tge-0-7-0-6.kgpt.tn.charter.com (96.34.71.100) 4.802 ms 4.837 ms 7 crr12spbgsc-bue-100.spbg.sc.charter.com (96.34.93.200) 10.341 ms 10.681 ms 10.593 ms 8 bbr01spbgsc-bue-4.spbg.sc.charter.com (96.34.2.50) 16.036 ms 10.018 ms 10.780 ms 9 cha-b1-link.telia.net (213.248.86.173) 21.081 ms 21.124 ms 21.121 ms 10 ash-bb4-link.telia.net (213.155.132.178) 19.049 ms 19.051 ms 19.041 ms 11 ash-b1-link.telia.net (213.155.130.73) 19.414 ms 19.434 ms 19.545 ms 12 globalcrossing-ic-130167-ash-bb1.c.telia.net (213.248.84.154) 19.239 ms 19.182 ms 19.279 ms 13 * 14 * 15 * 16 * 17 * 18 * 19 * 20 * 21 * 22 * 23 * 24 * 25 * 26 * 27 * 28 * 29 * From jared at puck.nether.net Thu Jul 9 13:08:19 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Jul 2015 09:08:19 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> Message-ID: <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> My guess is a researcher. We saw the same issue in the past with a Cisco microcode bug and people doing ping record route. When it went across a LC with a very specific set of software it would crash. If you crashed just upgrade your code, don't hide behind blocking an IP as people now know what to send/do. It won't be long. Jared Mauch > On Jul 9, 2015, at 7:44 AM, Colin Johnston wrote: > > Hi Jared, > thanks for update > > do you know provider/source ip of the source of the attack ? > > Colin > >> On 9 Jul 2015, at 12:27, Jared Mauch wrote: >> >> Really just people not patching their software after warnings more than six months ago: >> >> July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. >> >> Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. >> >> Jared Mauch >> >>> On Jul 8, 2015, at 1:15 PM, Michel Luczak wrote: >>> >>> >>>> On 08 Jul 2015, at 18:58, Mark Mayfield wrote: >>>> >>>> Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. >>> >>> Not sure it?s related but I?ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. >>> >>> Regards, Michel From nanog at ics-il.net Thu Jul 9 13:11:51 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 9 Jul 2015 08:11:51 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Message-ID: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Tony Finch" To: "Ricky Beam" Cc: nanog at nanog.org Sent: Thursday, July 9, 2015 6:17:17 AM Subject: Re: Dual stack IPv6 for IPv4 depletion Ricky Beam wrote: > > Talking about IPv6, we aren't carving a limit in granite. 99.99999% of home > networks currently have no need for multiple networks, and thus, don't ask for > anything more; they get a single /64 prefix. Personal-area networks already exist. Phone/watch/laptop etc. Virtual machines are common, e.g. for running multiple different operating systems on your computer. And automotive networks need connectivity. There are often separate VLANs for VOIP and IP TV and smart meters. Separate wifi networks tuned for low-latency synchronized audio. So it's very common to have multiple networks in a home with multiple layers of routing. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Rockall: South or southeast 5 or 6, increasing 6 or 7 later. Moderate, occasionally rough. Rain, fog patches. Moderate, occasionally very poor. From colinj at gt86car.org.uk Thu Jul 9 14:09:35 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 9 Jul 2015 15:09:35 +0100 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> Message-ID: <639EAECF-BAA3-495F-B8DF-A979940BBDF0@gt86car.org.uk> you would think a researcher would stop once he realised effect being caused ? Colin > On 9 Jul 2015, at 14:08, Jared Mauch wrote: > > My guess is a researcher. > > We saw the same issue in the past with a Cisco microcode bug and people doing ping record route. When it went across a LC with a very specific set of software it would crash. > > If you crashed just upgrade your code, don't hide behind blocking an IP as people now know what to send/do. It won't be long. > > Jared Mauch > >> On Jul 9, 2015, at 7:44 AM, Colin Johnston wrote: >> >> Hi Jared, >> thanks for update >> >> do you know provider/source ip of the source of the attack ? >> >> Colin >> >>> On 9 Jul 2015, at 12:27, Jared Mauch wrote: >>> >>> Really just people not patching their software after warnings more than six months ago: >>> >>> July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. >>> >>> Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. >>> >>> Jared Mauch >>> >>>> On Jul 8, 2015, at 1:15 PM, Michel Luczak wrote: >>>> >>>> >>>>> On 08 Jul 2015, at 18:58, Mark Mayfield wrote: >>>>> >>>>> Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. >>>> >>>> Not sure it?s related but I?ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. >>>> >>>> Regards, Michel From jared at puck.nether.net Thu Jul 9 14:11:56 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Jul 2015 10:11:56 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <639EAECF-BAA3-495F-B8DF-A979940BBDF0@gt86car.org.uk> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> <639EAECF-BAA3-495F-B8DF-A979940BBDF0@gt86car.org.uk> Message-ID: <885835D7-05E3-4012-8421-8D3974015B80@puck.nether.net> I?m sure they did. It could also have been any number of other things. I?m just guessing. It could have been someone trying to scan their enterprise too and went a bit rogue. Not everyone reads NANOG believe it or not :) Either way, if you haven?t upgraded for a 9 month old security advisory, shame on you. I don?t care what your change management process looks like, it?s bordering on network malpractice IMHO. - Jared > On Jul 9, 2015, at 10:09 AM, Colin Johnston wrote: > > you would think a researcher would stop once he realised effect being caused ? > > Colin > >> On 9 Jul 2015, at 14:08, Jared Mauch wrote: >> >> My guess is a researcher. >> >> We saw the same issue in the past with a Cisco microcode bug and people doing ping record route. When it went across a LC with a very specific set of software it would crash. >> >> If you crashed just upgrade your code, don't hide behind blocking an IP as people now know what to send/do. It won't be long. >> >> Jared Mauch >> >>> On Jul 9, 2015, at 7:44 AM, Colin Johnston wrote: >>> >>> Hi Jared, >>> thanks for update >>> >>> do you know provider/source ip of the source of the attack ? >>> >>> Colin >>> >>>> On 9 Jul 2015, at 12:27, Jared Mauch wrote: >>>> >>>> Really just people not patching their software after warnings more than six months ago: >>>> >>>> July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. >>>> >>>> Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. >>>> >>>> Jared Mauch >>>> >>>>> On Jul 8, 2015, at 1:15 PM, Michel Luczak wrote: >>>>> >>>>> >>>>>> On 08 Jul 2015, at 18:58, Mark Mayfield wrote: >>>>>> >>>>>> Come in this morning to find one failover pair of ASA's had the primary crash and failover, then a couple hours later, the secondary crash and failover, back to the primary. >>>>> >>>>> Not sure it?s related but I?ve read reports on FRNoG of ASAs crashing as well, seems related to a late leap second related issue. >>>>> >>>>> Regards, Michel From morrowc.lists at gmail.com Thu Jul 9 14:15:08 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Jul 2015 10:15:08 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <639EAECF-BAA3-495F-B8DF-A979940BBDF0@gt86car.org.uk> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> <639EAECF-BAA3-495F-B8DF-A979940BBDF0@gt86car.org.uk> Message-ID: On Thu, Jul 9, 2015 at 10:09 AM, Colin Johnston wrote: > you would think a researcher would stop once he realised effect being caused ? how would he/she know? From mel at beckman.org Thu Jul 9 14:16:24 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 14:16:24 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> <559D7049.2010102@seacom.mu> <559E5A30.7030508@seacom.mu>, Message-ID: <520BD11E-5E8A-4DA9-9B5A-3A016E3ED58A@beckman.org> Yes, the reason is that we'd never had ARIN turn down a request due to space exhaustion before. In 12 months we'll see the prices will go up significantly. Don't underestimate the demand, which is easily measured via ARIN space allocation reports. That demand rate has very little flexibility, and the businesses asking for /21 and above are willing to pay for the space. It's not the "two guys and a router" startups asking for a mere /23 or /24. These are generally pre-existing businesses or well-funded startups. -mel beckman > On Jul 9, 2015, at 5:53 AM, Baldur Norddahl wrote: > > There is a reason we have not seen any rise in the price > even after multiple years with depletion in large parts of the world. From chk at pobox.com Thu Jul 9 14:46:41 2015 From: chk at pobox.com (Harald Koch) Date: Thu, 9 Jul 2015 10:46:41 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> Message-ID: On 9 July 2015 at 09:11, Mike Hammett wrote: > I think you're confusing very common for a tech guy and very common for > the common man. I have a dozen or two v4 subnets in my house. Then again, I > also run my ISP out of my house, so I have a ton of stuff going on. I can't > even think of a handful of other people that would have more than one. > My son (who is not a tech guy but is a gamer) has four subnets in his (rented) house already: private LAN, guest network, home control network, and a separate LAN for the tenant downstairs who is sharing their broadband connection. And he's just getting started. The "common man" is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need. -- Harald From jared at puck.nether.net Thu Jul 9 14:53:13 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Jul 2015 10:53:13 -0400 Subject: Hotels/Airports with IPv6 Message-ID: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> It?s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. I?m wondering what people who deploy captive portals are doing with these things? https://tools.ietf.org/html/draft-wkumari-dhc-capport seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn?t work well what works for IPv6. Thanks, - Jared From mel at beckman.org Thu Jul 9 15:04:43 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Jul 2015 15:04:43 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: I working on a large airport WiFi deployment right now. IPv6 is "allowed for in the future" but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. -mel beckman > On Jul 9, 2015, at 7:53 AM, Jared Mauch wrote: > > It?s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. > > I?m wondering what people who deploy captive portals are doing with these things? > > https://tools.ietf.org/html/draft-wkumari-dhc-capport > > seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn?t work well what works for IPv6. > > Thanks, > > - Jared From admin at marcoteixeira.com Thu Jul 9 15:08:53 2015 From: admin at marcoteixeira.com (Marco Teixeira) Date: Thu, 9 Jul 2015 16:08:53 +0100 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> Message-ID: Probably because he got good advise from his father :) On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch wrote: > On 9 July 2015 at 09:11, Mike Hammett wrote: > > > I think you're confusing very common for a tech guy and very common for > > the common man. I have a dozen or two v4 subnets in my house. Then > again, I > > also run my ISP out of my house, so I have a ton of stuff going on. I > can't > > even think of a handful of other people that would have more than one. > > > > My son (who is not a tech guy but is a gamer) has four subnets in his > (rented) house already: private LAN, guest network, home control network, > and a separate LAN for the tenant downstairs who is sharing their broadband > connection. And he's just getting started. > > The "common man" is becoming much more sophisticated in their networking > requirements, and they need this stuff to just work. Please don't place > artificially small limits just because you can't see a need. > > -- > Harald > From bruce.curtis at ndsu.edu Thu Jul 9 15:16:17 2015 From: bruce.curtis at ndsu.edu (Bruce Curtis) Date: Thu, 9 Jul 2015 15:16:17 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: <5AA6677D-58C1-4D34-93F4-D6E563F15BCB@ndsu.edu> On Jul 9, 2015, at 9:53 AM, Jared Mauch wrote: > It?s my understanding that many captive portals have trouble with IPv6 traffic and this is a blocker for places. > > I?m wondering what people who deploy captive portals are doing with these things? > > https://tools.ietf.org/html/draft-wkumari-dhc-capport > > seems to be trying to document the method to signal to clients how to authenticate. I was having horrible luck with Boingo yesterday at RDU airport with their captive portal and deauthenticating me so just went to cellular data, so wondering if IPv4 doesn?t work well what works for IPv6. > > Thanks, > > - Jared We use the HotSpot feature on a Mikrotik box as a captive portal. It does not re-direct IPv6 web traffic but it does redirect all IPv4 DNS traffic to a DNS resolver that only answers with A records. Once a device has been authenticated IPv4 DNS traffic goes to a DNS server that will answer with AAAA records also. --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From oliver.oboyle at gmail.com Thu Jul 9 15:19:58 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 9 Jul 2015 11:19:58 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either. On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: > I working on a large airport WiFi deployment right now. IPv6 is "allowed > for in the future" but not configured in the short term. With less than > 10,000 ephemeral users, we don't expect users to demand IPv6 until most > mobile devices and apps come ready to use IPv6 by default. > > -mel beckman > > > On Jul 9, 2015, at 7:53 AM, Jared Mauch wrote: > > > > It?s my understanding that many captive portals have trouble with IPv6 > traffic and this is a blocker for places. > > > > I?m wondering what people who deploy captive portals are doing with > these things? > > > > https://tools.ietf.org/html/draft-wkumari-dhc-capport > > > > seems to be trying to document the method to signal to clients how to > authenticate. I was having horrible luck with Boingo yesterday at RDU > airport with their captive portal and deauthenticating me so just went to > cellular data, so wondering if IPv4 doesn?t work well what works for IPv6. > > > > Thanks, > > > > - Jared > -- :o@> From dmburgess at linktechs.net Thu Jul 9 15:33:25 2015 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 9 Jul 2015 15:33:25 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: Most hotels etc, are perfectly happy doing NAT. Dennis Burgess, CTO, Link Technologies, Inc. dennis at linktechs.net ? 314-735-0270 ? www.linktechs.net -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Oliver O'Boyle Sent: Thursday, July 09, 2015 10:20 AM To: Mel Beckman Cc: North American Network Operators' Group Subject: Re: Hotels/Airports with IPv6 We manage 65+ hotels in Canada and the topic of IPv6 for guest internet connectivity has never been brought up, except by me. It's not a discussion our vendors or the hotel brands have opened either. On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: > I working on a large airport WiFi deployment right now. IPv6 is > "allowed for in the future" but not configured in the short term. With > less than > 10,000 ephemeral users, we don't expect users to demand IPv6 until > most mobile devices and apps come ready to use IPv6 by default. > > -mel beckman > > > On Jul 9, 2015, at 7:53 AM, Jared Mauch wrote: > > > > It?s my understanding that many captive portals have trouble with > > IPv6 > traffic and this is a blocker for places. > > > > I?m wondering what people who deploy captive portals are doing with > these things? > > > > https://tools.ietf.org/html/draft-wkumari-dhc-capport > > > > seems to be trying to document the method to signal to clients how > > to > authenticate. I was having horrible luck with Boingo yesterday at RDU > airport with their captive portal and deauthenticating me so just went > to cellular data, so wondering if IPv4 doesn?t work well what works for IPv6. > > > > Thanks, > > > > - Jared > -- :o@> From cb.list6 at gmail.com Thu Jul 9 15:35:55 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 9 Jul 2015 08:35:55 -0700 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: On Thursday, July 9, 2015, Mel Beckman wrote: > I working on a large airport WiFi deployment right now. IPv6 is "allowed > for in the future" but not configured in the short term. With less than > 10,000 ephemeral users, we don't expect users to demand IPv6 until most > mobile devices and apps come ready to use IPv6 by default. > > 1. Users will never demand ipv6. They demand google and facebook. So that road goes nowhere 2. What data do you have that most devices and apps are not default-on / ready for ipv6. My guess is most devices carried by airport users will accept and use ipv6 address, and most used destinations (google, fb, netflix, wikipedia, ....) use ipv6 CB > -mel beckman > > > On Jul 9, 2015, at 7:53 AM, Jared Mauch > wrote: > > > > It?s my understanding that many captive portals have trouble with IPv6 > traffic and this is a blocker for places. > > > > I?m wondering what people who deploy captive portals are doing with > these things? > > > > https://tools.ietf.org/html/draft-wkumari-dhc-capport > > > > seems to be trying to document the method to signal to clients how to > authenticate. I was having horrible luck with Boingo yesterday at RDU > airport with their captive portal and deauthenticating me so just went to > cellular data, so wondering if IPv4 doesn?t work well what works for IPv6. > > > > Thanks, > > > > - Jared > From oliver.oboyle at gmail.com Thu Jul 9 15:37:06 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 9 Jul 2015 11:37:06 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: Yep, because most don't even know what NAT is! On Thu, Jul 9, 2015 at 11:33 AM, Dennis Burgess wrote: > Most hotels etc, are perfectly happy doing NAT. > > Dennis Burgess, CTO, Link Technologies, Inc. > dennis at linktechs.net ? 314-735-0270 ? www.linktechs.net > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Oliver O'Boyle > Sent: Thursday, July 09, 2015 10:20 AM > To: Mel Beckman > Cc: North American Network Operators' Group > Subject: Re: Hotels/Airports with IPv6 > > We manage 65+ hotels in Canada and the topic of IPv6 for guest internet > connectivity has never been brought up, except by me. It's not a discussion > our vendors or the hotel brands have opened either. > > On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: > > > I working on a large airport WiFi deployment right now. IPv6 is > > "allowed for in the future" but not configured in the short term. With > > less than > > 10,000 ephemeral users, we don't expect users to demand IPv6 until > > most mobile devices and apps come ready to use IPv6 by default. > > > > -mel beckman > > > > > On Jul 9, 2015, at 7:53 AM, Jared Mauch wrote: > > > > > > It?s my understanding that many captive portals have trouble with > > > IPv6 > > traffic and this is a blocker for places. > > > > > > I?m wondering what people who deploy captive portals are doing with > > these things? > > > > > > https://tools.ietf.org/html/draft-wkumari-dhc-capport > > > > > > seems to be trying to document the method to signal to clients how > > > to > > authenticate. I was having horrible luck with Boingo yesterday at RDU > > airport with their captive portal and deauthenticating me so just went > > to cellular data, so wondering if IPv4 doesn?t work well what works for > IPv6. > > > > > > Thanks, > > > > > > - Jared > > > > > > -- > :o@> > -- :o@> From mhuff at ox.com Thu Jul 9 15:42:51 2015 From: mhuff at ox.com (Matthew Huff) Date: Thu, 9 Jul 2015 15:42:51 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> Message-ID: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? With /56 you are giving each residential customer: 256 subnets x 18,446,744,073,709,551,616 hosts per subnet. I would expect at least 95.0% of residential customers are using 1 subnet, and 99.9% are using less than 4. I can understand people complaining when some ISPs were deciding to only give out a /64, but even with new ideas, new protocols and new applications, do people really think residential customers will need more than 256 subnets? When such a magical new system is developed, and people start to want it, can't ISPs start new /48 delegations? Since DHCP-PD and their infrastructure will already be setup for /56, it may not be easy, but it shouldn't be that difficult. I know the saying "build it and they will come....", but seriously.... I'd rather ISPs stop discussing deploying IPv6, and start doing it... Verizon: "The upgrades will start in 2013 and the first phase will include Verizon FiOS customers who have a dynamic IP address.". I'm still waiting...(at least I have a 6in4 tunnel with he.net). ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marco Teixeira Sent: Thursday, July 9, 2015 11:09 AM To: Harald Koch Cc: NANOG list Subject: Re: Dual stack IPv6 for IPv4 depletion Probably because he got good advise from his father :) On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch wrote: > On 9 July 2015 at 09:11, Mike Hammett wrote: > > > I think you're confusing very common for a tech guy and very common for > > the common man. I have a dozen or two v4 subnets in my house. Then > again, I > > also run my ISP out of my house, so I have a ton of stuff going on. I > can't > > even think of a handful of other people that would have more than one. > > > > My son (who is not a tech guy but is a gamer) has four subnets in his > (rented) house already: private LAN, guest network, home control network, > and a separate LAN for the tenant downstairs who is sharing their broadband > connection. And he's just getting started. > > The "common man" is becoming much more sophisticated in their networking > requirements, and they need this stuff to just work. Please don't place > artificially small limits just because you can't see a need. > > -- > Harald > From chk at pobox.com Thu Jul 9 16:01:11 2015 From: chk at pobox.com (Harald Koch) Date: Thu, 9 Jul 2015 12:01:11 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> Message-ID: On 9 July 2015 at 11:42, Matthew Huff wrote: > What am I missing? Is it just the splitting on the sextet boundary that is > an issue, or do people think people really need 64k subnets per household? > One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not "here's a subnet for the car", it's "here's a /56 for the car to break into smaller pieces as required". A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for "the car network" to make the routing and security easier to manage, and leave room for expansion (or for my guests...) One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the remaining space left to do something different. -- Harald From dave.taht at gmail.com Thu Jul 9 16:08:03 2015 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 9 Jul 2015 09:08:03 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> Message-ID: On Thu, Jul 9, 2015 at 9:01 AM, Harald Koch wrote: > On 9 July 2015 at 11:42, Matthew Huff wrote: > >> What am I missing? Is it just the splitting on the sextet boundary that is >> an issue, or do people think people really need 64k subnets per household? It is wasting that /64 on each separate media, lan type, or security model. >> > > One thing you're missing is that some of these new-fangled uses for IP > networking will want to do their own subnetting. It's not "here's a subnet > for the car", it's "here's a /56 for the car to break into smaller pieces > as required". > > A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if > you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) > levels. I have four vehicles, so I'd want to carve out a /52 for "the car > network" to make the routing and security easier to manage, and leave room > for expansion (or for my guests...) > > One more consideration for you: we're currently allocating all IPv6 > addresses out of 2000::/3. That's 1/8th of the space available. If we > discover we've messed up with this sparse address allocation idea, we have > 7/8ths of the remaining space left to do something different. And the colonists of Alpha Centauri will curse our shortsightedness. > -- > Harald -- Dave T?ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From owen at delong.com Thu Jul 9 16:08:41 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 09:08:41 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> <559D7049.2010102@seacom.mu> <559E5A30.7030508@seacom.mu> Message-ID: > On Jul 9, 2015, at 05:53 , Baldur Norddahl wrote: > > On 9 July 2015 at 13:25, Mark Tinka wrote: > >> >> I suppose the issue will become "more real" when you can't get any IPv4 >> space period. >> >> Mark. >> > > > That will never happen. If you offer me $1000 per IPv4, then I will happily > terminate some user contracts and sell their IP space to you? Eventually, you run out of user contracts to terminate. > In fact it will never become even that expensive. With a marked price of > $10 I am buying IP space for customers as needed and I will include free > space in the contracts. If the price went to $100 I would tell all users > that they need to pay monthly rent for their IP or alternative, the user > would have to accept carrier NAT in some form. And then I would proceed to > buy a new house for the money I make by selling address space. Sure, but aren?t your customers going to start demanding IPv6 instead of that at some point? Aren?t they going to start insisting on a service that doesn?t charge per address? > There is a ton of address space that is inefficient used. We will be able > to buy excess from companies that "create" space by optimizing their > existing space. There is a reason we have not seen any rise in the price > even after multiple years with depletion in large parts of the world. Yes? It?s called ?soft landing?? ARIN will be the first region to deplete without significant austerity policies for newcomers to get address space. Owen From mhuff at ox.com Thu Jul 9 16:16:32 2015 From: mhuff at ox.com (Matthew Huff) Date: Thu, 9 Jul 2015 16:16:32 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> Message-ID: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> When I see a car that needs a /56 subnet then I?ll take your use case seriously. Otherwise, it?s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work using jetpacks. We have prefix delegation already via DHCP-PD, but some in the IPv6 world don?t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don?t let the prefect be the enemy of the good. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 From: Harald Koch [mailto:chk at pobox.com] Sent: Thursday, July 9, 2015 12:01 PM To: Matthew Huff Cc: Marco Teixeira; NANOG list Subject: Re: Dual stack IPv6 for IPv4 depletion On 9 July 2015 at 11:42, Matthew Huff > wrote: What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not "here's a subnet for the car", it's "here's a /56 for the car to break into smaller pieces as required". A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for "the car network" to make the routing and security easier to manage, and leave room for expansion (or for my guests...) One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the remaining space left to do something different. -- Harald From owen at delong.com Thu Jul 9 16:27:59 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 09:27:59 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> Message-ID: <52521324-330E-4AE9-B97D-F2D2852A3F97@delong.com> My parents are non-technical. Other than a little help connecting her airport to the cable modem, I had nothing to do with the design and implementation of their networks. They have at least 7 distinct subnets in their house that I know of. Some of them are routed together. Some of them are isolated. I suspect my parents don?t even realize what a subnet is or how a router connects them. It is unlikely, IMHO, that said topology will likely get flattened in the future. I expect, rather, that it will grow both vertical and horizontal. I think that?s about as common person as it gets. So I?m not talking about the 15-30 subnets in my house, depending on the day, nor the subnets outside of my house used to support the networking in my house (point to point circuits and the like). I?m well aware that the common person does not have an ASN for their home and the average home thinks BGP is probably an airport code. Owen > On Jul 9, 2015, at 06:11 , Mike Hammett wrote: > > I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Tony Finch" > To: "Ricky Beam" > Cc: nanog at nanog.org > Sent: Thursday, July 9, 2015 6:17:17 AM > Subject: Re: Dual stack IPv6 for IPv4 depletion > > Ricky Beam wrote: >> >> Talking about IPv6, we aren't carving a limit in granite. 99.99999% of home >> networks currently have no need for multiple networks, and thus, don't ask for >> anything more; they get a single /64 prefix. > > Personal-area networks already exist. Phone/watch/laptop etc. > > Virtual machines are common, e.g. for running multiple different operating > systems on your computer. > > And automotive networks need connectivity. > > There are often separate VLANs for VOIP and IP TV and smart meters. > > Separate wifi networks tuned for low-latency synchronized audio. > > So it's very common to have multiple networks in a home with multiple > layers of routing. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Shannon, Rockall: South or southeast 5 or 6, increasing 6 or 7 later. > Moderate, occasionally rough. Rain, fog patches. Moderate, occasionally very > poor. From owen at delong.com Thu Jul 9 16:35:56 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 09:35:56 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> Message-ID: <62F58572-FA6C-4CB1-89EE-5C52B428D93F@delong.com> > On Jul 9, 2015, at 08:42 , Matthew Huff wrote: > > What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? > It?s the need for a large enough bitfield to do more flexible things with auto-delegation in a dynamic self-organizing topology. 8 is 2x2x2 and there?s really no other way you can break it down. (2x4, 4x2, 2x2x2 is it.) 16 is 2x2x2x2 and allows many more possible topologies (4x4, 2x4x2, 2x2x4, 2x8, 8x2, etc.) > With /56 you are giving each residential customer: > > 256 subnets x 18,446,744,073,709,551,616 hosts per subnet. The host count is irrelevant to the discussion. > > I would expect at least 95.0% of residential customers are using 1 subnet, and 99.9% are using less than 4. I can understand people complaining when some ISPs were deciding to only give out a /64, but even with new ideas, new protocols and new applications, do people really think residential customers will need more than 256 subnets? When such a magical new system is developed, and people start to want it, can't ISPs start new /48 delegations? Since DHCP-PD and their infrastructure will already be setup for /56, it may not be easy, but it shouldn't be that difficult. I would expect that basing decisions about limits on tomorrows network on the inadequacy of today?s solutions is unlikely to yield good results. Further, I?m not so sure you are right in your belief. I suspect that there are many more networks in most households that you are not counting. Sure, those networks are currently usually disjoint, but do you really think it will always be that way in the future? Every phone is a router. Ever tablet is a router. Cars are becoming routers and in some cases, collections of routers. Set top boxes are becoming routers. Utility meters are becoming routers. Laptops and desktops are capable of being routers. > I know the saying "build it and they will come....", but seriously.... > > I'd rather ISPs stop discussing deploying IPv6, and start doing it? I?m all for that, but do you have a valid reason not to give out /48s per end site? Just because /56 might be enough doesn?t cut it? I?m asking if you can point to any tangible benefit obtained from handing out /56s instead? Is there any problem solved, labor saved, or any other benefit whatsoever to giving out /56s instead of /48s? If not, then let?s hand out /48s until we discover one. Owen From dot at dotat.at Thu Jul 9 16:38:46 2015 From: dot at dotat.at (Tony Finch) Date: Thu, 9 Jul 2015 17:38:46 +0100 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> Message-ID: Matthew Huff wrote: > When I see a car that needs a /56 subnet then I?ll take your use case > seriously. Cars need partitions between their automotive network, their entertainment network, and their passenger wifi. Tony. -- f.anthony.n.finch http://dotat.at/ Southeast Fitzroy: Northeasterly becoming cyclonic 5 to 7, occasionally gale 8 at first. Moderate or rough. Fair. Moderate or good. From SNaslund at medline.com Thu Jul 9 16:51:40 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 16:51:40 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C70974FA@MUNPRDMBXA1.medline.com> It seems like there might be several incorrect assumptions here leading to over thinking the issue. 1. Over a long period of time, will the size or number of subnets be significantly different than today. Even today a bunch of our assumptions on why subnets are created the way they are might be obsolete or close to it. For example, broadcast domain size becomes less of an issue as broadcasts are used less (presumably by better targeted multicast and smarter protocols) and device performance increases. Maybe networks get smart enough to reorganize themselves and their subnets to optimize performance or maybe there will not be the need to do so. 2. Am I wrong or are we making some bad assumptions about "routability" of subnets? It seems like we might be too concerned about the minimum routable sized subnet when in reality that is just a policy decision open to change over time. Also, the routing I do inside my home does not need to be routable to the Internet at large. Summarization can occur in my home and at the service provider level. 3. If a couple of users required an inordinate amount of subnets, why not assign them an additional netblock? In the V4 world Fortune 500 global networks are not treated the same as your grandma's cell phone. It's nice to have the comfort of doing it with V6 but no real compelling reason not to have more than one type of customer assignment. Why not size things for the usual use case and add another allocation as needed? Seems really wasteful to do anything else. The NICs don't give a global carriers the same assignments they give a simple dual homed user why should you think all of your sub-assignments would be identical? 4. This is not the last time in history that you might get to reorganize your address space so don't try to plan for crazy edge cases. Given the widespread use of DHCP (or any other automatic addressing technology) in the V6 world it is archaic to think that an address change will be a big inconvenience. If my device receives an address and auto updates DNS records then I really do not care what that address is. Feel free to reorganize the network whenever you want. 5. The car example does not work because I am assuming you don't drive in your home. You probably roam all around the area and will be getting dynamic assignments from whomever the provider is. Do you statically address your iPhone when it is on the 3G/4G/LTE network? Steven Naslund Chicago IL >>>Subject: Re: Dual stack IPv6 for IPv4 depletion >>>On 9 July 2015 at 11:42, Matthew Huff > wrote: >>>What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? >>>One thing you're missing is that some of these new-fangled uses for IP networking will want to do their own subnetting. It's not "here's a subnet for the car", it's "here's a /56 for the car to break into smaller pieces as >>>required". >>A /56 isn't 256 subnets, it's 8 levels of subnetting (or 2 levels, if you're human and want to subnet at nibble boundaries). A /48 is 16 (or 4) levels. I have four vehicles, so I'd want to carve out a /52 for "the car network" to >>make the routing and security easier to manage, and leave room for expansion (or for my guests...) >>One more consideration for you: we're currently allocating all IPv6 addresses out of 2000::/3. That's 1/8th of the space available. If we discover we've messed up with this sparse address allocation idea, we have 7/8ths of the >>remaining space left to do something different. From owen at delong.com Thu Jul 9 16:51:56 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 09:51:56 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> Message-ID: > On Jul 9, 2015, at 09:16 , Matthew Huff wrote: > > When I see a car that needs a /56 subnet then I?ll take your use case seriously. Otherwise, it?s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work using jetpacks. When I see a reason not to give out /48s, I might start taking your argument seriously. > We have prefix delegation already via DHCP-PD, but some in the IPv6 world don?t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. Clearly the quality of IPv6 in embedded devices needs to improve. There?s clearly work being done on LWIP IPv6, but I don?t think it?s ready for prime time yet. (LWIP is one of the most popular embedded IP stacks. You?ll find it in a wide range of devices, including, but not limited to the ESP8266). > Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don?t let the prefect be the enemy of the good. /48s for end sites are NOT new? They have been part of the IPv6 design criteria from about the same time 128-bit addresses were decided. It is these silly IPv4-think notions of /56 and /60 that are new changes to the protocol. The good news is that it?s very easy to deploy /48s and if it turns out we were wrong, virtually everyone currently advocating /48s will happily help you get more restrictive allocation policies when 2000::/3 runs out. (assuming any of us are still alive when that happens). Owen From mhuff at ox.com Thu Jul 9 16:53:36 2015 From: mhuff at ox.com (Matthew Huff) Date: Thu, 9 Jul 2015 16:53:36 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <62F58572-FA6C-4CB1-89EE-5C52B428D93F@delong.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <62F58572-FA6C-4CB1-89EE-5C52B428D93F@delong.com> Message-ID: <53343611e26f464f943e6886321f51fb@pur-vm-exch13n1.ox.com> Sure, they may be 100,000+ networks like that in non-technical households. Maybe. I doubt it, but still that would be like 0.01%. Many consumer systems have trouble with L3 hops (mDNS/Bonjour, etc...). First thing tech support will suggest it to put them on the same network. People have been taught this. My experience is that most people that even have a second network, it's their AP that sets up a Guest network, and even then, it doesn't route between the networks (that's sort of the whole idea). If an ISP wants to give out a /48, great for them. If they want to give out only a /56, I say that's fine. What's more important to me is that they implement IPv6. Arguing about prefix size and SLAAC vs DHCP rather than just go ahead and implement things, to me is just silly. When IP was first deployed, we didn't have DHCP (bootp was still in it's infancy), no mDNS, etc...Lots of things grew up after the fact. I agree that we can't foresee what will happen in the future, but that to me just proves my point. Worrying about the ability to create complex topologies in home networks that may or may not ever be needed or wanted just seems absurd to me. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, July 9, 2015 12:36 PM To: Matthew Huff Cc: Marco Teixeira; Harald Koch; NANOG list Subject: Re: Dual stack IPv6 for IPv4 depletion > On Jul 9, 2015, at 08:42 , Matthew Huff wrote: > > What am I missing? Is it just the splitting on the sextet boundary that is an issue, or do people think people really need 64k subnets per household? > It's the need for a large enough bitfield to do more flexible things with auto-delegation in a dynamic self-organizing topology. 8 is 2x2x2 and there's really no other way you can break it down. (2x4, 4x2, 2x2x2 is it.) 16 is 2x2x2x2 and allows many more possible topologies (4x4, 2x4x2, 2x2x4, 2x8, 8x2, etc.) > With /56 you are giving each residential customer: > > 256 subnets x 18,446,744,073,709,551,616 hosts per subnet. The host count is irrelevant to the discussion. > > I would expect at least 95.0% of residential customers are using 1 subnet, and 99.9% are using less than 4. I can understand people complaining when some ISPs were deciding to only give out a /64, but even with new ideas, new protocols and new applications, do people really think residential customers will need more than 256 subnets? When such a magical new system is developed, and people start to want it, can't ISPs start new /48 delegations? Since DHCP-PD and their infrastructure will already be setup for /56, it may not be easy, but it shouldn't be that difficult. I would expect that basing decisions about limits on tomorrows network on the inadequacy of today's solutions is unlikely to yield good results. Further, I'm not so sure you are right in your belief. I suspect that there are many more networks in most households that you are not counting. Sure, those networks are currently usually disjoint, but do you really think it will always be that way in the future? Every phone is a router. Ever tablet is a router. Cars are becoming routers and in some cases, collections of routers. Set top boxes are becoming routers. Utility meters are becoming routers. Laptops and desktops are capable of being routers. > I know the saying "build it and they will come....", but seriously.... > > I'd rather ISPs stop discussing deploying IPv6, and start doing it. I'm all for that, but do you have a valid reason not to give out /48s per end site? Just because /56 might be enough doesn't cut it. I'm asking if you can point to any tangible benefit obtained from handing out /56s instead? Is there any problem solved, labor saved, or any other benefit whatsoever to giving out /56s instead of /48s? If not, then let's hand out /48s until we discover one. Owen From baldur.norddahl at gmail.com Thu Jul 9 17:13:43 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Jul 2015 19:13:43 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> <559D7049.2010102@seacom.mu> <559E5A30.7030508@seacom.mu> Message-ID: Den 09/07/2015 18.08 skrev "Owen DeLong" : > > That will never happen. If you offer me $1000 per IPv4, then I will happily > > terminate some user contracts and sell their IP space to you? > > Eventually, you run out of user contracts to terminate. At $1000 per contract I do not care. I will retire and be happy. Seriously ISPs are often valued by number of active contracts. A typical value might be $100 to $200. The value of an IPv4 address can not go any higher than this because at that point you can buy another company just to get the addresses. > > > In fact it will never become even that expensive. With a marked price of > > $10 I am buying IP space for customers as needed and I will include free > > space in the contracts. If the price went to $100 I would tell all users > > that they need to pay monthly rent for their IP or alternative, the user > > would have to accept carrier NAT in some form. And then I would proceed to > > buy a new house for the money I make by selling address space. > > Sure, but aren?t your customers going to start demanding IPv6 instead of that at some point? My customers have been demanding IPv6 for some time already. > > Aren?t they going to start insisting on a service that doesn?t charge per address? They will have their free IPv6 and will care less about a non shared IPv4. This will cause the valuation of IPv4 to crash at some point because the demand will disappear. > > > There is a ton of address space that is inefficient used. We will be able > > to buy excess from companies that "create" space by optimizing their > > existing space. There is a reason we have not seen any rise in the price > > even after multiple years with depletion in large parts of the world. > > Yes? It?s called ?soft landing?? ARIN will be the first region to deplete without significant > austerity policies for newcomers to get address space. RIPE gives you 1k addresses. This is not enough even for two guys and a router. But yes it is a nice token. The big companies have now gone without new space for a while. Just a few months ago I bought 2k addresses at $6 per address. I do not observe any rising tendency in IPv4 pricing. Regards Baldur From saper at saper.info Thu Jul 9 17:38:58 2015 From: saper at saper.info (Marcin Cieslak) Date: Thu, 9 Jul 2015 17:38:58 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: On Thu, 9 Jul 2015, Ca By wrote: > On Thursday, July 9, 2015, Mel Beckman wrote: > > > I working on a large airport WiFi deployment right now. IPv6 is "allowed > > for in the future" but not configured in the short term. With less than > > 10,000 ephemeral users, we don't expect users to demand IPv6 until most > > mobile devices and apps come ready to use IPv6 by default. > > > > > 1. Users will never demand ipv6. They demand google and facebook. So that > road goes nowhere I wonder if the front desk ever understood and forwarded my complaints about filtered ports (like 22) and other issues with NAT and firewalls. How do we know what customers "demand" if they don't bother reporting or are unable to produce a sophisticated report going beyond "it does not work for me"? What if Microsoft releases a portable IPv6-only game console one day? ~Marcin From jacques.latour at cira.ca Thu Jul 9 17:45:18 2015 From: jacques.latour at cira.ca (Jacques Latour) Date: Thu, 9 Jul 2015 17:45:18 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: Just turn IPv6 on when you can. > We manage 65+ hotels in Canada and the topic of IPv6 for guest internet > connectivity has never been brought up, except by me. It's not a discussion our > vendors or the hotel brands have opened either. I would argue customers never asked an IPv4 connection either, they asked for an Internet connection. The Internet is IPv4 and IPv6. > > I working on a large airport WiFi deployment right now. IPv6 is > > "allowed for in the future" but not configured in the short term. With > > less than > > 10,000 ephemeral users, we don't expect users to demand IPv6 until > > most mobile devices and apps come ready to use IPv6 by default. End users will never demand IPv6, turn it on :-) From oliver.oboyle at gmail.com Thu Jul 9 18:03:05 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 9 Jul 2015 14:03:05 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: Absolutely agree. It's not their job to even know to ask for a specific protocol version in the first place. Their experience should be as seamless and consistent as possible at all times. What we should be be concerned about is that the hospitality industry is so far behind the game on technology. Hotels and restaurants will be some of the last to drop IPv4 unless they don't realize they're doing it in the first place. On Thu, Jul 9, 2015 at 1:45 PM, Jacques Latour wrote: > Just turn IPv6 on when you can. > > > We manage 65+ hotels in Canada and the topic of IPv6 for guest internet > > connectivity has never been brought up, except by me. It's not a > discussion our > > vendors or the hotel brands have opened either. > > I would argue customers never asked an IPv4 connection either, they asked > for an Internet connection. The Internet is IPv4 and IPv6. > > > > I working on a large airport WiFi deployment right now. IPv6 is > > > "allowed for in the future" but not configured in the short term. With > > > less than > > > 10,000 ephemeral users, we don't expect users to demand IPv6 until > > > most mobile devices and apps come ready to use IPv6 by default. > > End users will never demand IPv6, turn it on :-) > > > -- :o@> From SNaslund at medline.com Thu Jul 9 19:24:02 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 19:24:02 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment. When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device. The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP. Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a "full table" view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two). The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that "accounting and their server are on one VLAN and engineering and their server are on another VLAN" and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the "Internet of things" we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks. In the future it would seem that systems would create their own little networks ad-hoc as needed for the best efficiency. I know this is not all out there today but planning address allocation 10 years down the road might be an exercise in futility. I would suggest plan for today and build it so you can easily change it when your prediction invariably prove wrong or short-sighted. Steven Naslund Chicago IL >> On Jul 9, 2015, at 09:16 , Matthew Huff wrote: >> >> When I see a car that needs a /56 subnet then I?ll take your use case seriously. Otherwise, it?s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work >>using jetpacks. >When I see a reason not to give out /48s, I might start taking your argument seriously. >> We have prefix delegation already via DHCP-PD, but some in the IPv6 world don?t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. Clearly the quality of IPv6 in embedded devices needs to improve. There?s clearly work being done on LWIP IPv6, but I don?t think it?s ready for prime time yet. (LWIP is one of the most popular embedded IP stacks. You?ll find it in a wide range of devices, including, but not limited to the ESP8266). >> Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don?t let the prefect be the enemy of the good. /48s for end sites are NOT new? They have been part of the IPv6 design criteria from about the same time 128-bit addresses were decided. It is these silly IPv4-think notions of /56 and /60 that are new changes to the protocol. The good news is that it?s very easy to deploy /48s and if it turns out we were wrong, virtually everyone currently advocating /48s will happily help you get more restrictive allocation policies when 2000::/3 runs out. (assuming any of us are still alive when that happens). Owen From applebaumt at ochin.org Thu Jul 9 19:38:08 2015 From: applebaumt at ochin.org (Tyler Applebaum) Date: Thu, 9 Jul 2015 19:38:08 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> Message-ID: <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve Sent: Thursday, July 09, 2015 12:24 PM To: nanog at nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment. When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device. The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP. Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a "full table" view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two). The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that "accounting and their server are on one VLAN and engineering and their server are on another VLAN" and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the "Internet of things" we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks. In the future it would seem that systems would create their own little networks ad-hoc as needed for the best efficiency. I know this is not all out there today but planning address allocation 10 years down the road might be an exercise in futility. I would suggest plan for today and build it so you can easily change it when your prediction invariably prove wrong or short-sighted. Steven Naslund Chicago IL >> On Jul 9, 2015, at 09:16 , Matthew Huff wrote: >> >> When I see a car that needs a /56 subnet then I?ll take your use case seriously. Otherwise, it?s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work >>using jetpacks. >When I see a reason not to give out /48s, I might start taking your argument seriously. >> We have prefix delegation already via DHCP-PD, but some in the IPv6 world don?t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. Clearly the quality of IPv6 in embedded devices needs to improve. There?s clearly work being done on LWIP IPv6, but I don?t think it?s ready for prime time yet. (LWIP is one of the most popular embedded IP stacks. You?ll find it in a wide range of devices, including, but not limited to the ESP8266). >> Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don?t let the prefect be the enemy of the good. /48s for end sites are NOT new? They have been part of the IPv6 design criteria from about the same time 128-bit addresses were decided. It is these silly IPv4-think notions of /56 and /60 that are new changes to the protocol. The good news is that it?s very easy to deploy /48s and if it turns out we were wrong, virtually everyone currently advocating /48s will happily help you get more restrictive allocation policies when 2000::/3 runs out. (assuming any of us are still alive when that happens). Owen Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. From jared at puck.nether.net Thu Jul 9 19:43:17 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Jul 2015 15:43:17 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> Message-ID: > On Jul 9, 2015, at 3:38 PM, Tyler Applebaum wrote: > > Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation. I would generally say yes. For example, if you are a wireless access point you may have an internal SSID and a Guest SSID on the same radio and hence same physical ethernet cable. - Jared From mhuff at ox.com Thu Jul 9 19:45:58 2015 From: mhuff at ox.com (Matthew Huff) Date: Thu, 9 Jul 2015 19:45:58 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> Message-ID: I've seen VLAN/subnet security used frequently in the financial world, even to the point of having full firewalls between vlans/subnets. Mostly for regulator purposes (Chinese firewall and all that). It's also common to allow outbound requests or redirect to different proxies based on source addresses within a corporate network. In residential networks, it's mostly used for guest networks that can route out to the internet, but not to other local devices. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tyler Applebaum Sent: Thursday, July 9, 2015 3:38 PM To: Naslund, Steve Cc: nanog at nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve Sent: Thursday, July 09, 2015 12:24 PM To: nanog at nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment. When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device. The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP. Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a "full table" view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two). The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that "accounting and their server are on one VLAN and engineering and their server are on another VLAN" and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the "Internet of things" we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks. In the future it would seem that systems would create their own little networks ad-hoc as needed for the best efficiency. I know this is not all out there today but planning address allocation 10 years down the road might be an exercise in futility. I would suggest plan for today and build it so you can easily change it when your prediction invariably prove wrong or short-sighted. Steven Naslund Chicago IL >> On Jul 9, 2015, at 09:16 , Matthew Huff wrote: >> >> When I see a car that needs a /56 subnet then I?ll take your use case seriously. Otherwise, it?s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work >>using jetpacks. >When I see a reason not to give out /48s, I might start taking your argument seriously. >> We have prefix delegation already via DHCP-PD, but some in the IPv6 world don?t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. Clearly the quality of IPv6 in embedded devices needs to improve. There?s clearly work being done on LWIP IPv6, but I don?t think it?s ready for prime time yet. (LWIP is one of the most popular embedded IP stacks. You?ll find it in a wide range of devices, including, but not limited to the ESP8266). >> Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don?t let the prefect be the enemy of the good. /48s for end sites are NOT new? They have been part of the IPv6 design criteria from about the same time 128-bit addresses were decided. It is these silly IPv4-think notions of /56 and /60 that are new changes to the protocol. The good news is that it?s very easy to deploy /48s and if it turns out we were wrong, virtually everyone currently advocating /48s will happily help you get more restrictive allocation policies when 2000::/3 runs out. (assuming any of us are still alive when that happens). Owen Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. From jared at puck.Nether.net Thu Jul 9 19:55:09 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 9 Jul 2015 15:55:09 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <469550651.308.1436446985586.JavaMail.mhammett@ThunderFuck> References: <1436410157.27450.66.camel@karl> <469550651.308.1436446985586.JavaMail.mhammett@ThunderFuck> Message-ID: <20150709195509.GA13865@puck.nether.net> On Thu, Jul 09, 2015 at 08:02:40AM -0500, Mike Hammett wrote: > Sounds like someone's getting caught up in the hype of a few buzzwords. I can't imagine where more than a couple bits of separately isolated networks in a home would be required. Most of those things you mentioned have no need to be isolated and are just being used to support a decision that was already made than evidence that lead to a decision. > > I'm not advocating anyone do anything other than what best practices dictate, just that whomever came up with best practices got a little caught up in the moment. You quickly run into religion here. I run my home as a big broadcast domain, but there's no reason I wouldn't perhaps segment things differently. There are a lot of people who just "extend their wifi" by plugging in a 2nd router with a long cable and don't realize they now have a new layer of nat, they just know the wifi by the $newRouter got better. Should I have a lan party VLAN/SSID? Perhaps, but for ease of use I let my AppleTV be on the same network as my iPhone so I can control them with the Remote app. Otherwise you quickly get into kinky broadcast relay or similar issues with multicast groups :) - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From SNaslund at medline.com Thu Jul 9 20:00:35 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 20:00:35 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> Message-ID: <9578293AE169674F9A048B2BC9A081B401C70978BF@MUNPRDMBXA1.medline.com> Yes, and that is a problem. Usually because it is not granular enough and there are a lot of ways to get onto another VLAN (physical access and packet trickery). It is a pretty weak form of security policy. Now, if we assume that VLAN based security is weak and that most homes do not generate enough broadcast traffic to be an issue, what exactly is the reason that a residential customer needs a lot of VLANs? Answer, they probably don't. A lot of residential users have a CPE device that does wireless, routing, and DHCP assignments all in one. No need to create a guest VLAN on that type of device. You simply assign an ACL that keeps the guest from reaching any internal IP. Why would your refrigerator (or car, toaster, TV, whatever) need to be on a separate subnet when the whole point is to create a network where all of your stuff communicates? Us engineers need to make sure we don't generalize that a lot of residential users do to their networks what we do to ours. We MIGHT have a reason for several subnets to simulate different stuff. I am still waiting for a valid example of a residential situation where VLANs are a useful addition. Oh, and don't even try the QoS argument. I will tell you that LLDP identification of the device and applying QoS policy based on the identification is much more effective and transparent to the end user. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tyler Applebaum >Sent: Thursday, July 9, 2015 3:38 PM >To: Naslund, Steve >Cc: nanog at nanog.org >Subject: RE: Dual stack IPv6 for IPv4 depletion > >Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation. From owen at delong.com Thu Jul 9 20:05:03 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 13:05:03 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> Message-ID: <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> In short, much of what you say below has been discussed before and with the general conclusion ?geography != topology and no, geographic allocation would not improve summarization?. I?m not saying that assignments need to be static, but I am saying that we need to put the default size somewhere that doesn?t inhibit future development and close off options at the application level. That?s why I?m arguing for a default /48. Owen > On Jul 9, 2015, at 12:24 , Naslund, Steve wrote: > > Seems to me that the problem might be thinking that the allocation toward the customer is a static thing. I think it is limiting to think that was going forward. Our industry created DHCP so we didn't have to deal with statically configured users who did not want to deal with IP addressing. Seems to me that a natural progression is to hand a network block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE device cannot be created that will request more addresses when it needs them and dynamically receive a larger assignment. > > When you think about it long term our network infrastructure is pretty archaic in that we have to do paperwork to get an block assignment from the regional numbering authority and then manually chop that up. I would expect that model to die over time and become more of a hierarchy whereby addresses are dynamically assigned top to bottom. Seems like the numbering authority could be a lot more effective if a network could tell them about its utilization and have additional addresses assignments happen automatically. The converse would be true as well, a network could reconfigure to free underutilized blocks on its own. If a customer CPE needs more addresses it will request them. If you add a pop to your network it should automatically get an allocation from an upstream device. > > The only reason why anyone cares what their address is results from the fact that our name to address mapping via DNS is so slow to update. The end user does not care what addresses they get as long as everyone can reach what they need to. Your customers would not care about renumbering pain if there wasn't any. Today they could care less if it is V4 or V6 as long as everyone can see each other. My dad gets V6 on his cell phone and he can't even spell IP. > > Another inefficient legacy is the assignment of address space on a service provider basis when geographic assignment would allow for better summarization. If that happened you could create a better model where less routers need to carry a "full table" view of the Internet. As long as I know how to get around my area and to regional routers that can reach out globally, that is all we need. Now you would not have the limitation that a wide variety of routers need to carry every route and the /64 routing limitation goes away. Today our routing is very much all or nothing. Either use defaults or get a whole table via are probably the two most common options (yeah, I know there are others but those are the main two). > > The ideas on the reasons for building VLANs is pretty out of date too. It drives me nuts when I see the usual books giving you the usual example that "accounting and their server are on one VLAN and engineering and their server are on another VLAN" and that this is for performance and security reasons. Some of the biggest vendors in the business use examples like this (yes, Cisco, I'm looking at you) and it just does not work that way in the real world. Who gets to what server is most often decided by the server (AD membership or group policy of some type). If the accounting and engineering department are both going to a cloud service VLAN separation is pretty moot. In a world where my refrigerator wants to talk to the power company and send a shopping list to my car, VLAN based security is not really a solution. In the "Internet of things" we keep hearing about, everything is talking to everything. Security is highly dependent in that world on a device defending itself and not relying on a VLAN boundary. From what I am seeing out there today, there are usually far too many VLANs and too much layer three going on in most large networks. > > In the future it would seem that systems would create their own little networks ad-hoc as needed for the best efficiency. I know this is not all out there today but planning address allocation 10 years down the road might be an exercise in futility. I would suggest plan for today and build it so you can easily change it when your prediction invariably prove wrong or short-sighted. > > Steven Naslund > Chicago IL > > > >>> On Jul 9, 2015, at 09:16 , Matthew Huff wrote: >>> >>> When I see a car that needs a /56 subnet then I?ll take your use case seriously. Otherwise, it?s just plain laughable. Yes, I could theorize a use case for this, but then I could theorize that someday everyone will get to work >>using jetpacks. > >> When I see a reason not to give out /48s, I might start taking your argument seriously. > >>> We have prefix delegation already via DHCP-PD, but some in the IPv6 world don?t even want to support DHCP, how does SLAAC do prefix delegation, or am I missing something else? I assume each car is going to be running as RA? Given quality of implementations of IPv6 in embedded devices so far, I found that pretty ludicrous. > > Clearly the quality of IPv6 in embedded devices needs to improve. There?s clearly work being done on LWIP IPv6, but I don?t think it?s ready for prime time yet. (LWIP is one of the most popular embedded IP stacks. You?ll find it in a wide range of devices, including, but not limited to the ESP8266). > >>> Seriously, the IPv6 world needs to get a clue. Creating new protocols and solutions at this point in the game is only making it more difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get going.. instead it seems everyone is musing about theoretical world where users need 64k networks. I understand the idea of not wanting to not think things through, but IPv6 is how many years old, and we are still arguing about these things? Don?t let the prefect be the enemy of the good. > > /48s for end sites are NOT new? They have been part of the IPv6 design criteria from about the same time 128-bit addresses were decided. It is these silly IPv4-think notions of /56 and /60 that are new changes to the protocol. > > The good news is that it?s very easy to deploy /48s and if it turns out we were wrong, virtually everyone currently advocating /48s will happily help you get more restrictive allocation policies when 2000::/3 runs out. (assuming any of us are still alive when that happens). > > > Owen > From SNaslund at medline.com Thu Jul 9 20:05:18 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 20:05:18 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> Message-ID: <9578293AE169674F9A048B2BC9A081B401C70978D7@MUNPRDMBXA1.medline.com> I don't have a problem with that use case IF there is a real firewall between VLANs. I was mostly referring to residential networks however. As far as guest access, a lot of today's CPE does that with its internal firewall creating an ACL for anyone on the guest network. The VLAN barrier is not really needed there and there are lots of techniques for dodging a VLAN barrier anyway. Steven Naslund Chicago IL >I've seen VLAN/subnet security used frequently in the financial world, even to the point of having full firewalls between vlans/subnets. Mostly for regulator purposes (Chinese firewall and all that). It's also common to allow >outbound requests or redirect to different proxies based on source addresses within a corporate network. > >In residential networks, it's mostly used for guest networks that can route out to the internet, but not to other local devices. >---- >Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 >aim: matthewbhuff??????? | Fax:?? 914-694-5669 From SNaslund at medline.com Thu Jul 9 20:07:31 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 20:07:31 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> In short, I'm saying that you should set your default so it is easily changed on the fly and then it won't matter if you are wrong. Steven Naslund Chicago IL >In short, much of what you say below has been discussed before and with the general conclusion ?geography != topology and no, geographic allocation would not improve summarization?. > >I?m not saying that assignments need to be static, but I am saying that we need to put the default size somewhere that doesn?t inhibit future development and close off options at the application level. > >That?s why I?m arguing for a default /48. > >Owen From SNaslund at medline.com Thu Jul 9 20:14:53 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 20:14:53 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150709195509.GA13865@puck.nether.net> References: <1436410157.27450.66.camel@karl> <469550651.308.1436446985586.JavaMail.mhammett@ThunderFuck> <20150709195509.GA13865@puck.nether.net> Message-ID: <9578293AE169674F9A048B2BC9A081B401C709791B@MUNPRDMBXA1.medline.com> > You quickly run into religion here. > > I run my home as a big broadcast domain, but there's no reason I wouldn't perhaps segment things differently. There are a lot of people who just "extend their wifi" by plugging in a 2nd router with a long cable and don't >realize they now have a new layer of nat, they just know the wifi by the $newRouter got better. > More VLANs (or no VLANs) won't help with multiple layers of NAT but we are talking here about IPV6 allocations so NAT on the home CPE should not be an issue. > Should I have a lan party VLAN/SSID? I would say that additional SSID ?= VLAN and would suggest that your LAN party try to use wired connections for better performance. If you don't want to reveal your wifi password by all means set up another SSID but it does not need to necessarily be in a different VLAN. >Perhaps, but for ease of use I let my AppleTV be on the same network as my iPhone so I can control them with the Remote app. Otherwise you quickly get into kinky broadcast relay or similar >issues with multicast groups :) > > -Jared Isn't the whole idea of this "Internet of Things" is that everything communicates to everything. Assuming that is the goal, what does VLANing do for you? Steven Naslund Chicago IL From rcarpen at network1.net Thu Jul 9 20:17:31 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 9 Jul 2015 16:17:31 -0400 (EDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> Message-ID: <455475603.484380.1436473051597.JavaMail.zimbra@network1.net> ----- On Jul 9, 2015, at 4:07 PM, Naslund, Steve SNaslund at medline.com wrote: > In short, I'm saying that you should set your default so it is easily changed on > the fly and then it won't matter if you are wrong. Absolutely. Also, since it won't matter if we are wrong, let's use /48 as the default, since it is much easier to deal with and is much less likely to be a case of "oops, too small" than /56 or, particularly, /60 or longer. -Randy From owen at delong.com Thu Jul 9 20:20:02 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 13:20:02 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> Message-ID: <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> And I?m saying you?re ignoring an important part of reality. Whatever ISPs default to deploying now will become the standard to which application developers develop. Changing the ISP later is easy. Changing the applications is hard. Let?s not bake unnecessary limitations into applications by assuming that tomorrow?s networks in homes will necessarily be as simple as today?s. Owen > On Jul 9, 2015, at 13:07 , Naslund, Steve wrote: > > In short, I'm saying that you should set your default so it is easily changed on the fly and then it won't matter if you are wrong. > > Steven Naslund > Chicago IL > > >> In short, much of what you say below has been discussed before and with the general conclusion ?geography != topology and no, geographic allocation would not improve summarization?. >> >> I?m not saying that assignments need to be static, but I am saying that we need to put the default size somewhere that doesn?t inhibit future development and close off options at the application level. >> >> That?s why I?m arguing for a default /48. >> >> Owen > > From bmanning at karoshi.com Thu Jul 9 20:34:49 2015 From: bmanning at karoshi.com (manning) Date: Thu, 9 Jul 2015 13:34:49 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559E70D5.4000008@seacom.mu> References: <6by3wom3ve8xr78yh2jas9qu.1436192130047@email.android.com> <019C59F6-1FA0-4CBC-9AD2-38268157F75F@beckman.org> <559CAC13.80803@seacom.mu> <20150708153241.GA8895@mindspring.com> <559D7049.2010102@seacom.mu> <559E5A30.7030508@seacom.mu> <559E70D5.4000008@seacom.mu> Message-ID: <5A21C2D9-1B01-4F8D-B8A2-A241330B5DF7@karoshi.com> one word. RFC 1918. Here is an perpetual well of IPv4, packed down, overflowing. manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 9July2015Thursday, at 6:02, Mark Tinka wrote: > > > On 9/Jul/15 14:53, Baldur Norddahl wrote: >> >> That will never happen. If you offer me $1000 per IPv4, then I will happily >> terminate some user contracts and sell their IP space to you... >> >> In fact it will never become even that expensive. With a marked price of >> $10 I am buying IP space for customers as needed and I will include free >> space in the contracts. If the price went to $100 I would tell all users >> that they need to pay monthly rent for their IP or alternative, the user >> would have to accept carrier NAT in some form. And then I would proceed to >> buy a new house for the money I make by selling address space. >> >> There is a ton of address space that is inefficient used. We will be able >> to buy excess from companies that "create" space by optimizing their >> existing space. There is a reason we have not seen any rise in the price >> even after multiple years with depletion in large parts of the world. > > In this particular case, I'm not concerned about the next ten years. > Predicting what happens between now and then could have a fair degree of > accuracy. > > I'm more concerned about what happens beyond that. I'm not sure I can > accurately (even with large error margins) predict what happens then. > > All that said, I'm not trying to paint myself into that kind of corner. > It is 2015, after all... Just don't tell my competitors... > > Mark. From SNaslund at medline.com Thu Jul 9 20:56:07 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 20:56:07 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> Huh, since when does ANY application care about what size address allocation you have? A V6 address is a 128 bit address period. Any IPv6 aware application will handle addresses as a 128 bit variable. Does any application running on IPv4 care if you have a /28 or a /29? In fact the application should not even be aware of what the net mask is because that is an OS function to handle the IP stack. This argument makes no sense at all since every application will be able to handle any allocation size since it is not even aware what that is. Any IPv6 compatible OS will not care either because they would be able to handle any number of masked bits. No app developer has ever been tied into the size of a subnet since CIDR was invented. Steven Naslund Chicago IL >Subject: Re: Dual stack IPv6 for IPv4 depletion > >And I?m saying you?re ignoring an important part of reality. > >Whatever ISPs default to deploying now will become the standard to which application developers develop. > >Changing the ISP later is easy. > >Changing the applications is hard. > >Let?s not bake unnecessary limitations into applications by assuming that tomorrow?s networks in homes will necessarily be as simple as today?s. > >Owen From cabo at tzi.org Thu Jul 9 21:01:57 2015 From: cabo at tzi.org (Carsten Bormann) Date: Thu, 09 Jul 2015 23:01:57 +0200 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: <559EE145.9050707@tzi.org> Oliver O'Boyle wrote: > It's not their job to even know to ask for a specific > protocol version in the first place No. They should just ask, with the best geek intonation, whether "this place still is stuck with 32-bit Internet". Gr??e, Carsten From rcarpen at network1.net Thu Jul 9 21:04:06 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 9 Jul 2015 17:04:06 -0400 (EDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> References: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> Message-ID: <135928119.484524.1436475846555.JavaMail.zimbra@network1.net> ----- On Jul 9, 2015, at 4:56 PM, Naslund, Steve SNaslund at medline.com wrote: > Huh, since when does ANY application care about what size address allocation you > have? A V6 address is a 128 bit address period. Any IPv6 aware application > will handle addresses as a 128 bit variable. The DHCPv6-PD server application on your router(s) might care. > Does any application running on IPv4 care if you have a /28 or a /29? In fact > the application should not even be aware of what the net mask is because that > is an OS function to handle the IP stack. This argument makes no sense at all > since every application will be able to handle any allocation size since it is > not even aware what that is. Any IPv6 compatible OS will not care either > because they would be able to handle any number of masked bits. No app > developer has ever been tied into the size of a subnet since CIDR was invented. For an application that doesn't do anything with IP addresses (allocating, etc.), it shouldn't matter, but that does not mean that there aren't applications for which it does. -Randy From oliver.oboyle at gmail.com Thu Jul 9 21:09:11 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 9 Jul 2015 17:09:11 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: <559EE145.9050707@tzi.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <559EE145.9050707@tzi.org> Message-ID: Unfortunately, the hotel staff wouldn't be able to answer that question. But they might give them free internet in exchange and hope the guest doesn't ask any more questions! On Thu, Jul 9, 2015 at 5:01 PM, Carsten Bormann wrote: > Oliver O'Boyle wrote: > > It's not their job to even know to ask for a specific > > protocol version in the first place > > No. They should just ask, with the best geek intonation, whether "this > place still is stuck with 32-bit Internet". > > Gr??e, Carsten > -- :o@> From owen at delong.com Thu Jul 9 21:19:20 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 14:19:20 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> Message-ID: Sigh? Home gateways are an application in this context. How the firmware gets written in those things will be affected. Further, applications do care about things like ?Can I assume that every home is reachable in its entirety via a packet to ff02::?? which is, for example, already baked into many products as the current mDNS default scope. SSDPv6 also seems to default to ff02:: scoping. Whether or not applications come into existence that can take advantage of diverse topology in the home will depend entirely on whether or not we make diverse topology possible going forward. /56 will enable some development in this area, but it will hinder several potential areas of exploration. /48 is a reasonable end-site boundary. It allows enough flexibility for dynamic topologies while still leaving enough prefix space to have lots of extra room for sparse allocations and everything else. So, instead of focusing on the narrowest possible definition of ?application? by todays terms, try opening your mind just a little bit and recognize that anything that requires software and interacts with the network in any way is a better definition of application in this context. Owen > On Jul 9, 2015, at 13:56 , Naslund, Steve wrote: > > Huh, since when does ANY application care about what size address allocation you have? A V6 address is a 128 bit address period. Any IPv6 aware application will handle addresses as a 128 bit variable. > > Does any application running on IPv4 care if you have a /28 or a /29? In fact the application should not even be aware of what the net mask is because that is an OS function to handle the IP stack. This argument makes no sense at all since every application will be able to handle any allocation size since it is not even aware what that is. Any IPv6 compatible OS will not care either because they would be able to handle any number of masked bits. No app developer has ever been tied into the size of a subnet since CIDR was invented. > > Steven Naslund > Chicago IL > > >> Subject: Re: Dual stack IPv6 for IPv4 depletion >> >> And I?m saying you?re ignoring an important part of reality. >> >> Whatever ISPs default to deploying now will become the standard to which application developers develop. >> >> Changing the ISP later is easy. >> >> Changing the applications is hard. >> >> Let?s not bake unnecessary limitations into applications by assuming that tomorrow?s networks in homes will necessarily be as simple as today?s. >> >> Owen > From jfbeam at gmail.com Thu Jul 9 21:35:38 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 17:35:38 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> Message-ID: On Thu, 09 Jul 2015 07:27:16 -0400, Jared Mauch wrote: > Really just people not patching their software after warnings more than > six months ago: A lot goes into "updates". Not the least of which is *knowing* about the issue. Then getting the patched code, then lab testing, then regulatory approval(s), then maintenance window(s)... > Cisco has released free software updates that address these > vulnerabilities. Workarounds that mitigate some of these vulnerabilities > are available. "Free" if you have a support contract. (the clause 3 "contact TAC" method is all too often a serious pain in the ass.) --Ricky From jared at puck.nether.net Thu Jul 9 21:39:16 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Jul 2015 17:39:16 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> Message-ID: <572F4E63-FDC1-4F1E-80B9-EC253EDB9E71@puck.nether.net> > On Jul 9, 2015, at 5:35 PM, Ricky Beam wrote: > > On Thu, 09 Jul 2015 07:27:16 -0400, Jared Mauch wrote: >> Really just people not patching their software after warnings more than six months ago: > > A lot goes into "updates". Not the least of which is *knowing* about the issue. Then getting the patched code, then lab testing, then regulatory approval(s), then maintenance window(s)? Not my first rodeo. Once again, it?s been since October 2014. If you failed to pay your credit card bill from October 2014 you can?t expect it to work either. > >> Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. > > "Free" if you have a support contract. (the clause 3 "contact TAC" method is all too often a serious pain in the ass.) I?ve never had issues getting them to open a case for this hardware. You can either operate responsibly or not. I wouldn?t be surprised if the situation gets worse. Either way, upgrade/patch/silo as necessary. - Jared From jfbeam at gmail.com Thu Jul 9 21:50:38 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 17:50:38 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, 09 Jul 2015 11:08:53 -0400, Marco Teixeira wrote: > On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch wrote: >> The "common man" is becoming much more sophisticated in their networking >> requirements, and they need this stuff to just work. Please don't place >> artificially small limits just because you can't see a need. > > Probably because he got good advise from his father :) Indeed. Either someone else set it up, or he took the time to learn how to set it up himself. (kudos if the latter) THIS definitely makes him parsecs from the "common man" (there being 7billion people in the world, and all.) Will a dozen networks be common (ie. out-of-the-box default) tomorrow? (NO) Next year? (NO) A decade from now? (maybe, and IPv6 deployment *might* be up to 20% by then) From A.L.M.Buxey at lboro.ac.uk Thu Jul 9 21:49:59 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Thu, 9 Jul 2015 22:49:59 +0100 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <559EE145.9050707@tzi.org> Message-ID: >No. They should just ask, with the best >geek intonation, whether "this >place still is stuck with 32-bit Internet" I'm sure they'd gladly report that their Internet is 24 mbit and not just 32 bit ;) alan From SNaslund at medline.com Thu Jul 9 21:51:41 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 21:51:41 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> So, why not demand that firmware accepts ANY mask length just like VLSM v4. I don't see what possible difference it will make if it is a /56 or /48 and I don't think you should make ANY assumption based on either of those being correct for any particular application. An assumption you make today is only applicable to your network not mine, it has no certainty of permanence at all. If one of my software engineers came to me and asked I would tell them they need to handle all possible mask lengths...period. Even if they are not in common use today, if its legal under the v6 spec then you should expect to support it. Not engineering for change is how we end up with software that won't handle a 2xxx year or a leap second. If a vendor decides to code something like the ff02:: scoping into their systems in a way that can't easily change then it is at their own risk. Would it be very difficult to change that depending on the DHCP-PD response you got? Why do you want to be the guy to make the bad assumption instead of them? That's what you are doing in the /56 vs /48 argument is it not? A little early in the IPv6 game to be making permanent rules on allocation sizes for future generations and hard coding them don't you think? All of statements you make regarding "enable some development" and "reasonable end-site boundary" are the network equivalents of the "no one will need more that 640k of RAM" and "32 bits will be more addresses than we ever need" As far as opening up my mind a bit how about opening your mind and demanding that IPv6 compatibility means accepting ALL possible allocation lengths. Steven Naslund Chicago IL >Sigh? > >Home gateways are an application in this context. How the firmware gets written in those things will be affected. > >Further, applications do care about things like ?Can I assume that every home is reachable in its entirety via a packet to ff02::?? which is, for example, already baked into many products as the current mDNS default scope. > >SSDPv6 also seems to default to ff02:: scoping. > >Whether or not applications come into existence that can take advantage of diverse topology in the home will depend entirely on whether or not we make diverse topology possible going forward. > >/56 will enable some development in this area, but it will hinder several potential areas of exploration. > >/48 is a reasonable end-site boundary. It allows enough flexibility for dynamic topologies while still leaving enough prefix space to have lots of extra room for sparse allocations and everything else. > >So, instead of focusing on the narrowest possible definition of ?application? by todays terms, try opening your mind just a little bit and recognize that anything that requires software and interacts with the network in any way is a >better definition of application in this context. > >Owen From nick at foobar.org Thu Jul 9 21:51:56 2015 From: nick at foobar.org (Nick Hilliard) Date: Thu, 09 Jul 2015 22:51:56 +0100 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> Message-ID: <559EECFC.9050407@foobar.org> On 09/07/2015 22:35, Ricky Beam wrote: > "Free" if you have a support contract. No, free-as-in-beer. You register a guest CCO account, email tac at cisco.com, provide the device serial number (or output of "show hardware") and the bugid + Cisco PSIRT URL reference. Cisco TAC will then provide you with a download link with fixed software, at no cost to you. It's not a pain in the ass - it works fine. Nick From SNaslund at medline.com Thu Jul 9 21:58:56 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 21:58:56 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <135928119.484524.1436475846555.JavaMail.zimbra@network1.net> References: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <135928119.484524.1436475846555.JavaMail.zimbra@network1.net> Message-ID: <9578293AE169674F9A048B2BC9A081B401C7097C94@MUNPRDMBXA1.medline.com> >> Huh, since when does ANY application care about what size address >> allocation you have? A V6 address is a 128 bit address period. Any >> IPv6 aware application will handle addresses as a 128 bit variable. >The DHCPv6-PD server application on your router(s) might care. Do you know of a DHCPv6-PD or router code that will accept a /56 and not a /48? If you do, I suggest you open a bug with that vendor and tell them that either is a legal prefix length. >> Does any application running on IPv4 care if you have a /28 or a /29? >> In fact the application should not even be aware of what the net mask >> is because that is an OS function to handle the IP stack. This >> argument makes no sense at all since every application will be able to >> handle any allocation size since it is not even aware what that is. >> Any IPv6 compatible OS will not care either because they would be able >> to handle any number of masked bits. No app developer has ever been tied into the size of a subnet since CIDR was invented. >For an application that doesn't do anything with IP addresses (allocating, etc.), it shouldn't matter, but that does not mean that there aren't applications for which it does. > >-Randy One should demand that application that care about allocation size, routing, etc would not be "IPv6 compatible" if they cannot handle all mask length legal under the protocol specification. The reason there is a v6 standard is to define what is allowable or not, that is what a protocol IS. We do not need to decide by committee to limit those options. Steven Naslund Chicago IL From owen at delong.com Thu Jul 9 22:05:00 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 15:05:00 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> Message-ID: <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> > On Jul 9, 2015, at 14:50 , Ricky Beam wrote: > > On Thu, 09 Jul 2015 11:08:53 -0400, Marco Teixeira wrote: >> On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch wrote: >>> The "common man" is becoming much more sophisticated in their networking >>> requirements, and they need this stuff to just work. Please don't place >>> artificially small limits just because you can't see a need. >> >> Probably because he got good advise from his father :) > > Indeed. Either someone else set it up, or he took the time to learn how to set it up himself. (kudos if the latter) > > THIS definitely makes him parsecs from the "common man" (there being 7billion people in the world, and all.) > > Will a dozen networks be common (ie. out-of-the-box default) tomorrow? (NO) Next year? (NO) A decade from now? (maybe, and IPv6 deployment *might* be up to 20% by then) Look again? IPv6 is already more than 20% of Google traffic in the US. Owen From SNaslund at medline.com Thu Jul 9 22:07:08 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 22:07:08 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B401C7097CCF@MUNPRDMBXA1.medline.com> >> On Thu, Jul 9, 2015 at 3:46 PM, Harald Koch wrote: >> The "common man" is becoming much more sophisticated in their >> networking requirements, and they need this stuff to just work. >> Please don't place artificially small limits just because you can't see a need. >> >> Probably because he got good advise from his father :) Agreed, we need to not add any limits or conventions to the v6 protocol. Why commit to a /48 or /56 if the protocol offers many more options? Just write software to deal with all the possibilities. While the "common man" has become much more sophisticated in network REQUIREMENTS. They have probably become less KNOWLEDGEABLE about what those requirement are because they are getting used to just plugging it in and it works. Used to be that most Internet users knew if that had public/private or dynamic/static addresses because they had to. Today the most likely answer would be "who knows, I plugged in my Apple TV and it just worked" Steven Naslund From owen at delong.com Thu Jul 9 22:07:28 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 15:07:28 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> Message-ID: Because vendor pressure depends on a userbase that knows enough to demand fixes. Simple fact is that if most ISPs deploy degraded services, vendors will code to the lowest common denominator of that degraded service and we?ll all be forced to live within those limitations in the products we receive. This is already evident in the IPv4 world. Even though my TiVO is 100% reachable from the internet, I can?t use any of TiVO?s applications to access it directly, I have to work through their proxy servers that depend on periodic polling from my devices to work because they assume everyone is stuck behind NAT. Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever? Owen > On Jul 9, 2015, at 14:51 , Naslund, Steve wrote: > > So, why not demand that firmware accepts ANY mask length just like VLSM v4. I don't see what possible difference it will make if it is a /56 or /48 and I don't think you should make ANY assumption based on either of those being correct for any particular application. An assumption you make today is only applicable to your network not mine, it has no certainty of permanence at all. If one of my software engineers came to me and asked I would tell them they need to handle all possible mask lengths...period. Even if they are not in common use today, if its legal under the v6 spec then you should expect to support it. Not engineering for change is how we end up with software that won't handle a 2xxx year or a leap second. > > If a vendor decides to code something like the ff02:: scoping into their systems in a way that can't easily change then it is at their own risk. Would it be very difficult to change that depending on the DHCP-PD response you got? Why do you want to be the guy to make the bad assumption instead of them? That's what you are doing in the /56 vs /48 argument is it not? A little early in the IPv6 game to be making permanent rules on allocation sizes for future generations and hard coding them don't you think? > > All of statements you make regarding "enable some development" and "reasonable end-site boundary" are the network equivalents of the "no one will need more that 640k of RAM" and "32 bits will be more addresses than we ever need" > > As far as opening up my mind a bit how about opening your mind and demanding that IPv6 compatibility means accepting ALL possible allocation lengths. > > > Steven Naslund > Chicago IL > >> Sigh? >> >> Home gateways are an application in this context. How the firmware gets written in those things will be affected. >> >> Further, applications do care about things like ?Can I assume that every home is reachable in its entirety via a packet to ff02::?? which is, for example, already baked into many products as the current mDNS default scope. >> >> SSDPv6 also seems to default to ff02:: scoping. >> >> Whether or not applications come into existence that can take advantage of diverse topology in the home will depend entirely on whether or not we make diverse topology possible going forward. >> >> /56 will enable some development in this area, but it will hinder several potential areas of exploration. >> >> /48 is a reasonable end-site boundary. It allows enough flexibility for dynamic topologies while still leaving enough prefix space to have lots of extra room for sparse allocations and everything else. >> >> So, instead of focusing on the narrowest possible definition of ?application? by todays terms, try opening your mind just a little bit and recognize that anything that requires software and interacts with the network in any way is a >better definition of application in this context. >> >> Owen > From SNaslund at medline.com Thu Jul 9 22:23:29 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Jul 2015 22:23:29 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> >Subject: Re: Dual stack IPv6 for IPv4 depletion > >Because vendor pressure depends on a userbase that knows enough to demand fixes. No vendor pressure is dependent on people buying their stuff. Don't send that CPE to your user if it does not meet your standards. If their stuff breaks because of shortsighted coding to bad for them. I am not going to be the guy to build in stupid limitations today to save a few minutes of coding for some lazy hardware vendor. > >Simple fact is that if most ISPs deploy degraded services, vendors will code to the lowest common denominator of that degraded service and we?ll all be forced to live within those limitations in the products we receive. > Why would you think so? Did your IPv4 router not accept a /8 netmask even though there was very little chance you would get one? I know most of my programmers are trained to anticipate all of the possible options for an input. Sometimes this is hard to define but with IPv6 it is clearly in the specification. Would you consider an ISP that hands out /56s to be "degraded"? Most users wouldn't know the difference and if you offered the /48 on request (or even better automatically on depletion of the /56) what would be degraded? >This is already evident in the IPv4 world. Even though my TiVO is 100% reachable from the internet, I can?t use any of TiVO?s applications to access it directly, I have to work through their proxy servers that depend on periodic >polling from my devices to work because they assume everyone is stuck behind NAT. > That would be Tivo's fault wouldn't it. It would be trivially simple for them to know if they were behind a NAT so I am guessing they force you through their proxy for other purposes. Should we re-engineer the way IP works so that Tivo can write crap code? Should we limit all future v6 users today so that crap CPE works now? >Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever? > I never said that there was a valid reason not to use /48s or /56s or whatever prefix you like. What I am saying is don't force that decision on anyone today. IPv6 does not force the use of any particular prefix length for an end user, why should you? Why do we all have to use the same length anyways? >Owen Steven Naslund Chicago IL From jfbeam at gmail.com Thu Jul 9 22:30:38 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 18:30:38 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C70978BF@MUNPRDMBXA1.medline.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> <9578293AE169674F9A048B2BC9A081B401C70978BF@MUNPRDMBXA1.medline.com> Message-ID: On Thu, 09 Jul 2015 16:00:35 -0400, Naslund, Steve wrote: > Now, if we assume that VLAN based security is weak and that most homes > do not generate enough broadcast traffic to be an issue, what exactly is > the reason that a residential customer needs a lot of VLANs? Answer, > they probably don't. > ... I am still waiting for a valid example of a residential situation > where VLANs are a useful addition. Voice, Video, Data, and Guest VLANs. And even that is generally overkill, but does provide a measurable, if marginal, improvement. --Ricky From oliver.oboyle at gmail.com Thu Jul 9 22:38:11 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 9 Jul 2015 18:38:11 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <559EE145.9050707@tzi.org> Message-ID: Unfortunately, there are still some that would report 2mbit via dsl and think that was ahead of their competition (and it might be in some cases...)... On Jul 9, 2015 5:51 PM, "Alan Buxey" wrote: > > >No. They should just ask, with the best >geek intonation, whether "this > >place still is stuck with 32-bit Internet" > > I'm sure they'd gladly report that their Internet is 24 mbit and not just > 32 bit > ;) > > alan From jfbeam at gmail.com Thu Jul 9 22:45:38 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 18:45:38 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> Message-ID: On Thu, 09 Jul 2015 18:05:00 -0400, Owen DeLong wrote: > Look again? IPv6 is already more than 20% of Google traffic in the US. 20% of *1* site's traffic does not equal 20% DEPLOYMENT. (read: 20% of internet DEVICES (CPE) connected by IPv6) From jfbeam at gmail.com Thu Jul 9 22:55:38 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 18:55:38 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> Message-ID: On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve wrote: > That would be Tivo's fault wouldn't it. Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work "over the internet". (It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.) From owen at delong.com Thu Jul 9 23:07:02 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 16:07:02 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> Message-ID: <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> > On Jul 9, 2015, at 15:45 , Ricky Beam wrote: > > On Thu, 09 Jul 2015 18:05:00 -0400, Owen DeLong wrote: >> Look again? IPv6 is already more than 20% of Google traffic in the US. > > 20% of *1* site's traffic does not equal 20% DEPLOYMENT. (read: 20% of internet DEVICES (CPE) connected by IPv6) You are correct? In order for 20% of Google?s traffic to come from IPv6 connected devices, there would generally need to be more than 20% of all devices connected over IPv6. Owen From owen at delong.com Thu Jul 9 23:08:56 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 16:08:56 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <9578293! AE169674F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> Message-ID: > On Jul 9, 2015, at 15:55 , Ricky Beam wrote: > > On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve wrote: >> That would be Tivo's fault wouldn't it. > > Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work "over the internet". > > (It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.) Correct? It _IS_ TiVO?s fault. However, the reality I?m trying to point out is that application developers make assumptions based on the commonly deployed environment that they expect in the world. If we create a limited environment, then that is what they will code to. If we deliver /48s, then they will come up with innovative ways to make use of those deployments. If we deliver /56s, then innovation will be constrained to what can be delivered to /56s, even for sites that have /48s. Owen From marka at isc.org Thu Jul 9 23:27:28 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 10 Jul 2015 09:27:28 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Thu, 09 Jul 2015 22:23:29 +0000." <9578293AE169674F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <9578293AE169674F 9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> Message-ID: <20150709232728.1C51D329B0DB@rock.dv.isc.org> In message <9578293AE169674F9A048B2BC9A081B401C7097D2E at MUNPRDMBXA1.medline.com> , "Naslund, Steve" writes: > > > >Subject: Re: Dual stack IPv6 for IPv4 depletion > > > >Because vendor pressure depends on a userbase that knows enough to > demand fixes. > > No vendor pressure is dependent on people buying their stuff. Don't send > that CPE to your user if it does not meet your standards. If their stuff > breaks because of shortsighted coding to bad for them. I am not going to > be the guy to build in stupid limitations today to save a few minutes of > coding for some lazy hardware vendor. > > > > >Simple fact is that if most ISPs deploy degraded services, vendors will > code to the lowest common denominator of that degraded service and well > all be forced to live within those limitations in the products we receive. > > > > Why would you think so? Did your IPv4 router not accept a /8 netmask > even though there was very little chance you would get one? I know most > of my programmers are trained to anticipate all of the possible options > for an input. Sometimes this is hard to define but with IPv6 it is > clearly in the specification. > > Would you consider an ISP that hands out /56s to be "degraded"? Most > users wouldn't know the difference and if you offered the /48 on request > (or even better automatically on depletion of the /56) what would be > degraded? Because ISP's have a track record of not listening to user requests. Getting IPv6 delivered is a prime example. Some of us have been requesting it from our ISP's for well over a decade now and they are still yet to deliver. Some of us have requested that SUBMIT be enabled on their outgoing mail server for just as long, a simple 1 line fix in the mail server config. No, webmail is not a acceptable alternative. It's likely to take as long to get them to increase the allocation from a /56 to a /48 despite it being a 1 word fix in a config. Getting that one word change will not be as easy as ring up customer support and saying "Can you please increase the number of subnets returned to a prefix delegation request?" and getting "Yes" as the answer. > >This is already evident in the IPv4 world. Even though my TiVO is 100% > reachable from the internet, I cant use any of TiVOs applications to > access it directly, I have to work through their proxy servers that > depend on periodic >polling from my devices to work because they assume > everyone is stuck behind NAT. > > > > That would be Tivo's fault wouldn't it. It would be trivially simple for > them to know if they were behind a NAT so I am guessing they force you > through their proxy for other purposes. Should we re-engineer the way IP > works so that Tivo can write crap code? Should we limit all future v6 > users today so that crap CPE works now? No. It is ISP's and CPE vendors faults for stalling on IPv6 for well over a decade. If we all had IPv6 in the home a decade ago Tivo could have designed for a reachable device rather than one that had to polled due to there being no IPv6 in the home and IPv4 addresses changing all the time due to there not being enouhg of them and ISP's having to juggle them. Tivo added IP support in 2006. Windows XP already had IPv6 support when Tivo shipped their 2nd gen box. A Tivo box is a in-home server. That requires stable addressability which IPv6 (RFC 2460) can deliver, using address blocks assigned from the ISP using PD (RFC 3633). With IPv6 it could register its address in the global DNS using a TSIG (RFC 2845) signed UPDATE (RFC 2136) requests just the way your Mac can do today. All of these RFC's existed when the 2nd Gen Tivo was designed. What didn't exist was ISP's delivering IPv6 to the home customer. What Tivo had to work with was 99.9% of the user base behind a NAT with no address stablility. How would you design your Tivo? > >Can you offer one valid reason not to give residential users /48s? Any > benefit whatsoever? > > > > I never said that there was a valid reason not to use /48s or /56s or > whatever prefix you like. What I am saying is don't force that decision > on anyone today. IPv6 does not force the use of any particular prefix > length for an end user, why should you? Why do we all have to use the > same length anyways? > > >Owen > > > Steven Naslund > Chicago IL -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jfbeam at gmail.com Thu Jul 9 23:28:42 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2015 19:28:42 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <9578293! AE169674F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> Message-ID: On Thu, 09 Jul 2015 19:08:56 -0400, Owen DeLong wrote: > the reality I?m trying to point out is that application developers make > assumptions based > on the commonly deployed environment that they expect in the world. Partially. It's also a matter of the software guys not having any clue what-so-ever w.r.t. networking. In this case, APPLE designed Bonjour to not cross network boundaries. Idiotic, but it allows them to sell "servers" that do the cross-network routing. > If we create a limited environment, then that is what they will code to. They will code to what they understand, what "works for them", and what their users report "works for me". We will always end up with "substandard" quality because they have little (or no) understanding of how networking does it's thing. (And then marketing, and legal will step in and pooh on it even more.) From kauer at biplane.com.au Thu Jul 9 23:32:21 2015 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 10 Jul 2015 09:32:21 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <469550651.308.1436446985586.JavaMail.mhammett@ThunderFuck> References: <469550651.308.1436446985586.JavaMail.mhammett@ThunderFuck> Message-ID: <1436484741.3442.8.camel@karl> On Thu, 2015-07-09 at 08:02 -0500, Mike Hammett wrote: > I can't imagine [...] And that, right there, is the problem. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From nanog at ics-il.net Fri Jul 10 00:06:14 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 9 Jul 2015 19:06:14 -0500 (CDT) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Message-ID: <1147852741.869.1436486796920.JavaMail.mhammett@ThunderFuck> Solutions looking for problems. I get a few subnets (though don't foresee it being likely). Someone here was mentioning dozens or hundreds of subnets for a residential customer. Um, no. If you feel the need to segment private wire and private wireless, okay. Then there's guest... um, and M2M? yeah, that's about it for a single residence. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Harald Koch" To: "Mike Hammett" Cc: "NANOG list" Sent: Thursday, July 9, 2015 9:46:41 AM Subject: Re: Dual stack IPv6 for IPv4 depletion On 9 July 2015 at 09:11, Mike Hammett < nanog at ics-il.net > wrote: I think you're confusing very common for a tech guy and very common for the common man. I have a dozen or two v4 subnets in my house. Then again, I also run my ISP out of my house, so I have a ton of stuff going on. I can't even think of a handful of other people that would have more than one. My son (who is not a tech guy but is a gamer) has four subnets in his (rented) house already: private LAN, guest network, home control network, and a separate LAN for the tenant downstairs who is sharing their broadband connection. And he's just getting started. The "common man" is becoming much more sophisticated in their networking requirements, and they need this stuff to just work. Please don't place artificially small limits just because you can't see a need. -- Harald From matthew at matthew.at Fri Jul 10 01:02:37 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 9 Jul 2015 18:02:37 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> Message-ID: > On Jul 9, 2015, at 4:07 PM, Owen DeLong wrote: > > >> On Jul 9, 2015, at 15:45 , Ricky Beam wrote: >> >> On Thu, 09 Jul 2015 18:05:00 -0400, Owen DeLong wrote: >>> Look again? IPv6 is already more than 20% of Google traffic in the US. >> >> 20% of *1* site's traffic does not equal 20% DEPLOYMENT. (read: 20% of internet DEVICES (CPE) connected by IPv6) > > You are correct? In order for 20% of Google?s traffic to come from IPv6 connected devices, there would generally need to be more than 20% of all devices connected over IPv6. > > Owen > That doesn't follow at all. One guy who has v6 and really loves youtube can account for most of it. Matthew Kaufman (Sent from my iPhone) From marka at isc.org Fri Jul 10 01:15:54 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 10 Jul 2015 11:15:54 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Thu, 09 Jul 2015 18:02:37 -0700." References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> Message-ID: <20150710011554.D714E329CA50@rock.dv.isc.org> In message , Matthew Kaufman w rites: > > > > On Jul 9, 2015, at 4:07 PM, Owen DeLong wrote: > > > > > >> On Jul 9, 2015, at 15:45 , Ricky Beam wrote: > >> > >> On Thu, 09 Jul 2015 18:05:00 -0400, Owen DeLong > wrote: > >>> Look again??? IPv6 is already more than 20% of Google traffic in the US. > >> > >> 20% of *1* site's traffic does not equal 20% DEPLOYMENT. (read: 20% of > internet DEVICES (CPE) connected by IPv6) > > > > You are correct??? In order for 20% of Google???s traffic to come from IPv6 > connected devices, there would generally need to be more than 2 > 0% of all devices connected over IPv6. > > > > Owen > > > > That doesn't follow at all. > > One guy who has v6 and really loves youtube can account for most of it. > > Matthew Kaufman > > (Sent from my iPhone) Doesn't pass the laugh test. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kauer at biplane.com.au Fri Jul 10 01:15:57 2015 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 10 Jul 2015 11:15:57 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1147852741.869.1436486796920.JavaMail.mhammett@ThunderFuck> References: <1147852741.869.1436486796920.JavaMail.mhammett@ThunderFuck> Message-ID: <1436490957.2977.25.camel@karl> On Thu, 2015-07-09 at 19:06 -0500, Mike Hammett wrote: > Solutions looking for problems. I get a few subnets (though don't > foresee it being likely). Someone here was mentioning dozens or > hundreds of subnets for a residential customer. Um, no. Actually I was mentioning thousands. What you personally don't foresee is pretty much irrelevant to what will actually happen - unless you are in a position to make things impossible. If we build a world where only 256 in-home subnets are possible, then future homes will have no more than 256 in-home subnets, no-one will be building systems that need more than 256 subnets, and no doubt you will be saying "see, I told you so". Like pretty much the entire current generation of net techs, your imagination is limited by your past. But there are kids in school right now who do not suffer from the same limitations - and they will build wonders. If we let them. Regards, K. PS: People keep dissing "home users" saying how they are incapable of understanding stuff and installing all these complex networks. Twenty years ago getting online at home took lots of know-how; getting more than one device online in the home took even more. Now you can just buy a $50 bit of kit, plug it in and your desktops, laptops, smartphones, tablets, televisions, digital radios and wireless sound systems just work. With main and guest networks, multiple wifi protocols, and in many cases basic IPv6 as well. There is no reason to think that the complexity of future networks will not be equally well packaged for the home. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From laszlo at heliacal.net Fri Jul 10 01:19:35 2015 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 10 Jul 2015 01:19:35 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <9578293! AE16967 4F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> Message-ID: On Jul 9, 2015, at 11:08 PM, Owen DeLong wrote: > >> On Jul 9, 2015, at 15:55 , Ricky Beam wrote: >> >> On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve wrote: >>> That would be Tivo's fault wouldn't it. >> >> Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work "over the internet". >> >> (It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.) > > Correct? It _IS_ TiVO?s fault. However, the reality I?m trying to point out is that application developers make assumptions based > on the commonly deployed environment that they expect in the world. > > If we create a limited environment, then that is what they will code to. > > If we deliver /48s, then they will come up with innovative ways to make use of those deployments. If we deliver /56s, then innovation will be constrained to what can be delivered to /56s, even for sites that have /48s. > > Owen > I would love to see things go Owen's way.. /48s everywhere, everyone agrees it's a good idea, and we can just assume that it will work. We can move on, this is one less thing to stress about. On the other hand, I do wonder how this will work, even if most people are getting /48s. Perhaps in a few years we'll be past all this, and there will be a well accepted standard way. Maybe it will be RIPng. Maybe some thing that we haven't seen yet. Or maybe there will be 800 ways of doing it, because the protocol spec allows that, and so we should complicate our lives further by requiring everyone to support every possibility of combinations. This is the worst possible outcome because it means unnecessary complexity, more work for everyone involved, and less reliability. If you're writing an application, do you bother supporting /48, /56, RA, DHCP, etc, while also supporting an https polling mechanism for the times when none of that stuff works? We can pretend that it doesn't matter and that software should 'just work' with any network, but that's simply not possible for many applications. I think as an application developer, you're much better off aiming for the least common denominator, accepting the limitations of that, and just moving on. This means polling, reflectors, NAT, proxyarp, etc. Things that you can control, to make your app work. Supporting a bunch of different ways is a waste of everyone's time and just makes your application less reliable and harder to test. Unless your specific application benefits greatly from a more capable network, it's probably not worth even thinking about, as long as you know that you will still have to support the 'bad' ones. A music streaming application can use a hardcoded well known server name to access a centralized service. It can even communicate with other users by using that central server as a database or reflector. It would be 'nice' if it could ask the network for a prefix and use a different address for each peer it talks to, but what's the point in developing that, if you still have to support the other case? A wifi hotspot device would benefit from prefix delegation, but it could of course use NAT or proxying without the cooperation of the network. This is one application where it might be worth supporting all the different combinations, but it means that all those different methods need to be tested, and they can break in different ways, and there's no way to be sure it's right. Choice is good, you can run your own network any way you want, etc, but it's not good when people are making choices just for the sake of being different and incompatible. After all, the point of the internet is to communicate with everyone else, which means we all need to agree on how we will communicate. How can we expect everyone to embrace IPv6 if we can't even provide a straightforward procedure to get connected to it? -Laszlo From jcurran at arin.net Fri Jul 10 01:31:02 2015 From: jcurran at arin.net (John Curran) Date: Fri, 10 Jul 2015 01:31:02 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> Message-ID: <8C616849-E018-4595-969B-54DE785632DC@arin.net> On Jul 9, 2015, at 9:02 PM, Matthew Kaufman > wrote: On Jul 9, 2015, at 4:07 PM, Owen DeLong > wrote: ... You are correct? In order for 20% of Google?s traffic to come from IPv6 connected devices, there would generally need to be more than 20% of all devices connected over IPv6. That doesn't follow at all. One guy who has v6 and really loves youtube can account for most of it. Matthew - That would be the case if the measurements of ?IPv6 users? were based on traffic or packet counts, but Google?s measurements are based on specific pairs of HTTP connection attempts (one IPv4, and one IPv6) and the ratio of those which are IPv6 capable. The measurement methodology is documented in the Google research paper - I?ll also observe that APNIC has been conducting its own research via a different approach but achieved a rather similar measurement results for of IPv6 enabled users in the US - . You can find more details on the approach used here Both techniques indicate more than 20% of the US Internet users are connecting via IPv6. FYI, /John John Curran President and CEO ARIN From chuckchurch at gmail.com Fri Jul 10 01:43:55 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Thu, 9 Jul 2015 21:43:55 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> Message-ID: <011d01d0bab1$e7890a00$b69b1e00$@gmail.com> -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch Sent: Thursday, July 09, 2015 9:08 AM To: Colin Johnston Cc: nanog at nanog.org Subject: Re: Possible Sudden Uptick in ASA DOS? >My guess is a researcher. I wouldn't classify someone sending known malicious traffic towards someone else's network device attempting to crash it as a 'researcher'. Criminal is a better term. Chuck From jared at puck.nether.net Fri Jul 10 01:48:04 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Jul 2015 21:48:04 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <011d01d0bab1$e7890a00$b69b1e00$@gmail.com> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> <011d01d0bab1$e7890a00$b69b1e00$@gmail.com> Message-ID: <0F97853E-BB61-42AC-A2B8-9D970D4AD251@puck.nether.net> > On Jul 9, 2015, at 9:43 PM, Chuck Church wrote: > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch > Sent: Thursday, July 09, 2015 9:08 AM > To: Colin Johnston > Cc: nanog at nanog.org > Subject: Re: Possible Sudden Uptick in ASA DOS? > >> My guess is a researcher. > > > I wouldn't classify someone sending known malicious traffic towards someone else's network device attempting to crash it as a 'researcher'. Criminal is a better term. There are other terms for people who don?t maintain their equipment, it?s usually described as negligent. If my hardware were rebooting, I would be red-faced first about not having done something and not blaming someone outside. I don?t know if it was a researcher or something buggy sending packets or anything else. (I have no unique direct insight). What I do know is the ASAs under my control and purview had no issues. Take the free upgrade and move on folks. - Jared From jcurran at arin.net Fri Jul 10 01:48:06 2015 From: jcurran at arin.net (John Curran) Date: Fri, 10 Jul 2015 01:48:06 +0000 Subject: Also Facebook (was: Re: Dual stack IPv6 for IPv4 depletion) In-Reply-To: <8C616849-E018-4595-969B-54DE785632DC@arin.net> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> <8C616849-E018-4595-969B-54DE785632DC@arin.net> Message-ID: On Jul 9, 2015, at 9:31 PM, John Curran > wrote: ... Both techniques indicate more than 20% of the US Internet users are connecting via IPv6. You might also want to review Paul Saab?s presentation regarding what Facebook actually sees for IPv6 traffic and performance (given in March 2015 at the World IPv6 Congress) - They are seeing 9% of their traffic via IPv6 and doubling each year. This is likely because US mobile providers strong support for IPv6, with more than 80% of mobile devices on a some mobile providers supporting IPv6? (They?ve also observing a significant performance improvement with IPv6 connected users over IPv4 connected, but they admit to still looking into the reason behind the performance lift) FYI, /John John Curran President and CEO ARIN From marka at isc.org Fri Jul 10 02:05:50 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 10 Jul 2015 12:05:50 +1000 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: Your message of "Thu, 09 Jul 2015 21:43:55 -0400." <011d01d0bab1$e7890a00$b69b1e00$@gmail.com> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> <011d01d0bab1$e7890a00$b69b1e00$@gmail.com> Message-ID: <20150710020550.1CCC1329DA88@rock.dv.isc.org> In message <011d01d0bab1$e7890a00$b69b1e00$@gmail.com>, "Chuck Church" writes: > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch > Sent: Thursday, July 09, 2015 9:08 AM > To: Colin Johnston > Cc: nanog at nanog.org > Subject: Re: Possible Sudden Uptick in ASA DOS? > > >My guess is a researcher. > > > I wouldn't classify someone sending known malicious traffic towards > someone else's network device attempting to crash it as a 'researcher'. > Criminal is a better term. > > Chuck At what point does a well formed but bug triggering packet go from "malicious" to "expected"? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Fri Jul 10 02:08:32 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 19:08:32 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <9578293! ! AE169674F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> Message-ID: > On Jul 9, 2015, at 16:28 , Ricky Beam wrote: > > On Thu, 09 Jul 2015 19:08:56 -0400, Owen DeLong wrote: >> the reality I?m trying to point out is that application developers make assumptions based >> on the commonly deployed environment that they expect in the world. > > Partially. It's also a matter of the software guys not having any clue what-so-ever w.r.t. networking. In this case, APPLE designed Bonjour to not cross network boundaries. Idiotic, but it allows them to sell "servers" that do the cross-network routing. Actually it?s not a design problem in IPv6. A simple tweak to the software to send to ff05:: instead of ff02:: or better yet, allow the user to edit the scope in System Preferences is all that is really needed. However, in IPv4, mDNS/Bonjour (and mDNS is uPNP?s fault, not Apple?s to the best of my knowledge) use broadcast packets and that?s a design flaw. However, hard to argue with the choice since multicast, especially cross-router multicast is pretty much busted in any sort of home gateway in IPv4 anyway. >> If we create a limited environment, then that is what they will code to. > > They will code to what they understand, what "works for them", and what their users report "works for me". We will always end up with "substandard" quality because they have little (or no) understanding of how networking does it's thing. > > (And then marketing, and legal will step in and pooh on it even more.) OK? Clearly you are determined to let cynicism and avoidance drive your ideas here. I can?t help that. Hopefully enough others will try to make the internet more useful as we move forward and hand out larger end-site prefixes. Owen From owen at delong.com Fri Jul 10 02:14:17 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jul 2015 19:14:17 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <9578293! ! AE16967 4F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> Message-ID: <18358A9E-88AF-4D61-8EC8-DADF18AE02B6@delong.com> > On Jul 9, 2015, at 18:19 , Laszlo Hanyecz wrote: > > On Jul 9, 2015, at 11:08 PM, Owen DeLong wrote: > >> >>> On Jul 9, 2015, at 15:55 , Ricky Beam wrote: >>> >>> On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve wrote: >>>> That would be Tivo's fault wouldn't it. >>> >>> Partially, even mostly... it's based on Bonjour. That's why the shit doesn't work "over the internet". >>> >>> (It's just http/https, so it will, in fact, work, but their apps aren't designed to work that way. Many 3rd party control apps have no problems.) >> >> Correct? It _IS_ TiVO?s fault. However, the reality I?m trying to point out is that application developers make assumptions based >> on the commonly deployed environment that they expect in the world. >> >> If we create a limited environment, then that is what they will code to. >> >> If we deliver /48s, then they will come up with innovative ways to make use of those deployments. If we deliver /56s, then innovation will be constrained to what can be delivered to /56s, even for sites that have /48s. >> >> Owen >> > > I would love to see things go Owen's way.. /48s everywhere, everyone agrees it's a good idea, and we can just assume that it will work. We can move on, this is one less thing to stress about. > > On the other hand, I do wonder how this will work, even if most people are getting /48s. Perhaps in a few years we'll be past all this, and there will be a well accepted standard way. Maybe it will be RIPng. Maybe some thing that we haven't seen yet. Or maybe there will be 800 ways of doing it, because the protocol spec allows that, and so we should complicate our lives further by requiring everyone to support every possibility of combinations. This is the worst possible outcome because it means unnecessary complexity, more work for everyone involved, and less reliability. > > If you're writing an application, do you bother supporting /48, /56, RA, DHCP, etc, while also supporting an https polling mechanism for the times when none of that stuff works? We can pretend that it doesn't matter and that software should 'just work' with any network, but that's simply not possible for many applications. I think as an application developer, you're much better off aiming for the least common denominator, accepting the limitations of that, and just moving on. This means polling, reflectors, NAT, proxyarp, etc. Things that you can control, to make your app work. Supporting a bunch of different ways is a waste of everyone's time and just makes your application less reliable and harder to test. Unless your specific application benefits greatly from a more capable network, it's probably not worth even thinking about, as long as you know that you will still have to support the 'bad' ones. Which is why I?m arguing that we should try not to implement the bad ones in IPv6. > A music streaming application can use a hardcoded well known server name to access a centralized service. It can even communicate with other users by using that central server as a database or reflector. It would be 'nice' if it could ask the network for a prefix and use a different address for each peer it talks to, but what's the point in developing that, if you still have to support the other case? Will you always have to support that case? Do you really want to say that the current state of IPv4 should drive all development decisions for all future products? > A wifi hotspot device would benefit from prefix delegation, but it could of course use NAT or proxying without the cooperation of the network. This is one application where it might be worth supporting all the different combinations, but it means that all those different methods need to be tested, and they can break in different ways, and there's no way to be sure it's right. > > Choice is good, you can run your own network any way you want, etc, but it's not good when people are making choices just for the sake of being different and incompatible. After all, the point of the internet is to communicate with everyone else, which means we all need to agree on how we will communicate. How can we expect everyone to embrace IPv6 if we can't even provide a straightforward procedure to get connected to it? This is all true. Seems to me DHCP-PD receiving a /48 from upstream is a pretty straightforward approach. Dynamic topologies inside the home still require some development work, but any router ought to be able to accept a /48 and assign /64s to the local-facing port(s) fairly easily. Owen From bmanning at karoshi.com Fri Jul 10 03:42:15 2015 From: bmanning at karoshi.com (manning) Date: Thu, 9 Jul 2015 20:42:15 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C70978BF@MUNPRDMBXA1.medline.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> <9578293AE169674F9A048B2BC9A081B401C70978BF@MUNPRDMBXA1.medline.com> Message-ID: <2480E675-C7BF-4EB5-9D35-165DECB69387@karoshi.com> hum.. let me postulate. my lan, my kids, my guests, the drive-bys, ? the LG stuff, the Apple stuff, the whitebox stuff, appliances ? smart meters, switches, thermostats, toilets, water flow controls, ? Microsoft can talk to the x-box, but i have no desire for them t see/know anything else on the entertainment lan at the house?. manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 9July2015Thursday, at 13:00, Naslund, Steve wrote: > Yes, and that is a problem. Usually because it is not granular enough and there are a lot of ways to get onto another VLAN (physical access and packet trickery). It is a pretty weak form of security policy. > > Now, if we assume that VLAN based security is weak and that most homes do not generate enough broadcast traffic to be an issue, what exactly is the reason that a residential customer needs a lot of VLANs? Answer, they probably don't. A lot of residential users have a CPE device that does wireless, routing, and DHCP assignments all in one. No need to create a guest VLAN on that type of device. You simply assign an ACL that keeps the guest from reaching any internal IP. Why would your refrigerator (or car, toaster, TV, whatever) need to be on a separate subnet when the whole point is to create a network where all of your stuff communicates? > > Us engineers need to make sure we don't generalize that a lot of residential users do to their networks what we do to ours. We MIGHT have a reason for several subnets to simulate different stuff. I am still waiting for a valid example of a residential situation where VLANs are a useful addition. Oh, and don't even try the QoS argument. I will tell you that LLDP identification of the device and applying QoS policy based on the identification is much more effective and transparent to the end user. > > Steven Naslund > Chicago IL > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tyler Applebaum >> Sent: Thursday, July 9, 2015 3:38 PM >> To: Naslund, Steve >> Cc: nanog at nanog.org >> Subject: RE: Dual stack IPv6 for IPv4 depletion >> >> Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation. > From jfbeam at gmail.com Fri Jul 10 04:53:21 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 10 Jul 2015 00:53:21 -0400 Subject: Also Facebook (was: Re: Dual stack IPv6 for IPv4 depletion) In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> <8C616849-E018-4595-969B-54DE785632DC@arin.net> Message-ID: On Thu, 09 Jul 2015 21:48:06 -0400, John Curran wrote: > Both techniques indicate more than 20% of the US Internet users are > connecting via IPv6. Interesting method that's full of holes (and they know it), but it's data nonetheless. Globally, it's still ~4.5%. Within my own pool of providers, I'm ZERO for 5. (I've not pinged TWC-BC lately, 'tho. And no one has gotten back to me that Earthlink has provided TWC with any prefixes, so us Earthlink cable internet customers are still dark.) > (They?ve also observing a significant performance > improvement with IPv6 connected users over IPv4 connected... IPv4 tends to be NAT'd and aggressively proxied. I also wouldn't rule out v6 taking a different path, but that wouldn't explain the magnitude of difference those slides would suggest. (not really readable via youtube) From nsuan at nonexiste.net Fri Jul 10 06:01:05 2015 From: nsuan at nonexiste.net (Nicholas Suan) Date: Fri, 10 Jul 2015 02:01:05 -0400 Subject: Also Facebook (was: Re: Dual stack IPv6 for IPv4 depletion) In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> <8C616849-E018-4595-969B-54DE785632DC@arin.net> Message-ID: You should elaborate on some of these 'holes' then. On Fri, Jul 10, 2015 at 12:53 AM, Ricky Beam wrote: > On Thu, 09 Jul 2015 21:48:06 -0400, John Curran wrote: >> >> Both techniques indicate more than 20% of the US Internet users are >> connecting via IPv6. > > > Interesting method that's full of holes (and they know it), but it's data > nonetheless. > > Globally, it's still ~4.5%. Within my own pool of providers, I'm ZERO for 5. > (I've not pinged TWC-BC lately, 'tho. And no one has gotten back to me that > Earthlink has provided TWC with any prefixes, so us Earthlink cable internet > customers are still dark.) > >> (They?ve also observing a significant performance >> improvement with IPv6 connected users over IPv4 connected... > > > IPv4 tends to be NAT'd and aggressively proxied. I also wouldn't rule out v6 > taking a different path, but that wouldn't explain the magnitude of > difference those slides would suggest. (not really readable via youtube) From jfbeam at gmail.com Fri Jul 10 06:08:21 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 10 Jul 2015 02:08:21 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1436490957.2977.25.camel@karl> References: <1147852741.869.1436486796920.JavaMail.mhammett@ThunderFuck> <1436490957.2977.25.camel@karl> Message-ID: On Thu, 09 Jul 2015 21:15:57 -0400, Karl Auer wrote: > Actually I was mentioning thousands. Dozens, millions, whatever. Pick something and get on with it already. > What you personally don't foresee is pretty much irrelevant to what will > actually happen... And planning for a future that doesn't happen because you're too caught up in *planning* that future is irrelevant, too. > Like pretty much the entire current generation of net techs, your > imagination is limited by your past. But there are kids in school right > now who do not suffer from the same limitations - and they will build > wonders. And in ~15 years when they have a jobs, they can change what we built. (assuming ever let the paint dry long enough to use it.) > PS: People keep dissing "home users" saying how they are incapable of > understanding stuff and installing all these complex networks. Twenty > years ago getting online at home took lots of know-how; getting more > than one device online in the home took even more. Now you can just buy > a $50 bit of kit, plug it in and your desktops, laptops, smartphones, > tablets, televisions, digital radios and wireless sound systems just > work. With main and guest networks, multiple wifi protocols, and in many > cases basic IPv6 as well. There is no reason to think that the > complexity of future networks will not be equally well packaged for the > home. 20 years ago was 1995. It took "some" know how (how to run setup.exe on the floppy you ISP sent you.) Windows 95 made it much easier by having that software in the default OS. Building a network took a bit longer to (a) be wanted/needed and (b) be available and affordable in the home. (few people had more than one computer to network in the first place. Today, you have three of them on your person at any given moment.) Despite the proliferation of the internet and network tech, the average person today knows even less than two decades ago. Because everything "just works". IPv6 will never get there until it, too, "just works". We're still a long way off in the home -- both because providers aren't doing it, and because the CPE tech is lagging. Mobile by contrast, due to necessity and speed of tech turnover, is there already; you have to intentionally check to know you're using IPv6. From colinj at mx5.org.uk Fri Jul 10 06:17:38 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Fri, 10 Jul 2015 07:17:38 +0100 Subject: Fwd: Test-drive the OS X El Capitan public beta References: <955685717.45543931.1436501286550.JavaMail.cboxp@nwk-cboxp-lapp02.apple.com> Message-ID: <1F161E6E-CB57-41F0-AD55-9259FDC7BA22@mx5.org.uk> lots of 6GB downloads this morning :) Colin > Begin forwarded message: > > From: Apple Beta Software Program > Subject: Test-drive the OS X El Capitan public beta > Date: 10 July 2015 05:08:06 BST > To: colinj at mx5.org.uk > > > > The El Capitan public beta is now available from the Apple Beta Software Program. > Test-drive it and let us know what you think. > > > From matthew at matthew.at Fri Jul 10 06:33:25 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 09 Jul 2015 23:33:25 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> Message-ID: <559F6735.7000603@matthew.at> On 7/9/2015 3:07 PM, Owen DeLong wrote: > > Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever? > Sure. To avoid having to go back and deal with ARIN yet again for more IPv6 space. One of the hopeful outcomes of IPv6 adoption was that an ISP could get enough to last "forever" in a single transaction. But "forever" isn't very long at one /48 (or more) per customer. Matthew Kaufman From matthew at matthew.at Fri Jul 10 06:42:57 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 09 Jul 2015 23:42:57 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <8C616849-E018-4595-969B-54DE785632DC@arin.net> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> <8C616849-E018-4595-969B-54DE785632DC@arin.net> Message-ID: <559F6971.9050104@matthew.at> On 7/9/2015 6:31 PM, John Curran wrote: > On Jul 9, 2015, at 9:02 PM, Matthew Kaufman > wrote: >>> On Jul 9, 2015, at 4:07 PM, Owen DeLong >> > wrote: >>> ... >>> You are correct? In order for 20% of Google?s traffic to come from >>> IPv6 connected devices, there would generally need to be more than >>> 20% of all devices connected over IPv6. >> >> That doesn't follow at all. >> >> One guy who has v6 and really loves youtube can account for most of it. > > Matthew - > > That would be the case if the measurements of ?IPv6 users? were based > on traffic or packet > counts, but Google?s measurements are based on specific pairs of HTTP > connection attempts > (one IPv4, and one IPv6) and the ratio of those which are IPv6 > capable. The measurement > methodology is documented in the Google research paper - > Still can be accounted for with *fewer* than "20% of all devices connected over IPv6" (the opposite of Owen's claim). Possibly even far fewer, if many "devices" don't bother to visit Google via HTTP. I do find it interesting that Google (and other's) graphs show much higher IPv6 penetration on weekends - I assume that's because ISP-provided CPE + default OS configs get you better chances of IPv6 than you get using your IT department's machine image plus network infrastructure. Anecdotally: I have yet to work regularly at a facility that has IPv6 connectivity to the outside world from the WiFi networks that serve employee laptops. (Though for several years in the late 2000s I did get IPv6 addresses via RA and routing between floors (but not beyond)). Matthew Kaufman From Valdis.Kletnieks at vt.edu Fri Jul 10 06:53:38 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jul 2015 02:53:38 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Thu, 09 Jul 2015 23:33:25 -0700." <559F6735.7000603@matthew.at> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <559F6735.7000603@matthew.at> Message-ID: <23291.1436511218@turing-police.cc.vt.edu> On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said: > One of the hopeful outcomes of IPv6 adoption was that an ISP could get > enough to last "forever" in a single transaction. But "forever" isn't > very long at one /48 (or more) per customer. How long does it take to blow through a /20 at /48 a customer? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Jul 10 06:59:31 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jul 2015 02:59:31 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Thu, 09 Jul 2015 23:42:57 -0700." <559F6971.9050104@matthew.at> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> <8C616849-E018-4595-969B-54DE785632DC@arin.net> <559F6971.9050104@matthew.at> Message-ID: <23761.1436511571@turing-police.cc.vt.edu> On Thu, 09 Jul 2015 23:42:57 -0700, Matthew Kaufman said: > infrastructure. Anecdotally: I have yet to work regularly at a facility > that has IPv6 connectivity to the outside world from the WiFi networks > that serve employee laptops. Anecdotally, it's been about a decade since I worked someplace that wasn't true. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From A.L.M.Buxey at lboro.ac.uk Fri Jul 10 07:58:37 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Fri, 10 Jul 2015 08:58:37 +0100 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <559EE145.9050707@tzi.org> Message-ID: <5317A52D-42EF-4D17-A8E3-724502A62B73@lboro.ac.uk> 2 mbit is still more than 32 bit ;) alan From jmaimon at ttec.com Fri Jul 10 07:59:21 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 10 Jul 2015 03:59:21 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> Message-ID: <559F7B59.5040101@ttec.com> There has been tomes on this topic. There will continue to be many more. That is because many of you continue in trying to defend the following concept. customer subnet bits == isp customers bits So now, the ISP is supposed to put some effort and gain more bits. Why not the customer? Its inherently suspicious. Because its inherently wrong - for the ISP, and possibly for the address space as well. Indulge me as I wax poetic. I venture to say that proponents want to see everyone else have the service of their own dreams. When broadband rolled to the masses with a single ipv4 address per subscriber, forget about routing, their hearts broke. The new common denominator was a far cry from what their experience was. The division of internet into different classes of netizens a bitter pill to swallow. You are only one budget cut away from joining the ho-poloi. Its quite scary. Hence the determination that no user should ever have to go without enough addresses ever again. A new common denominator, now is the time to get it accepted! It will be like the old days, a class C with every leased line! Forever! And the ISPs? They have enough to get started and they can get more if they put the effort in. So all the rational and logical debate is pointless. Gut feelings, philosophy and emotions are what is at stake and those tend not to respond well to things like logic and reason. Joe Owen DeLong wrote: > And I?m saying you?re ignoring an important part of reality. > > Whatever ISPs default to deploying now will become the standard to which application developers develop. > From mark.tinka at seacom.mu Fri Jul 10 08:04:58 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jul 2015 10:04:58 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <53343611e26f464f943e6886321f51fb@pur-vm-exch13n1.ox.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <62F58572-FA6C-4CB1-89EE-5C52B428D93F@delong.com> <53343611e26f464f943e6886321f51fb@pur-vm-exch13n1.ox.com> Message-ID: <559F7CAA.3060501@seacom.mu> On 9/Jul/15 18:53, Matthew Huff wrote: > > If an ISP wants to give out a /48, great for them. If they want to give out only a /56, I say that's fine. What's more important to me is that they implement IPv6. Arguing about prefix size and SLAAC vs DHCP rather than just go ahead and implement things, to me is just silly. When IP was first deployed, we didn't have DHCP (bootp was still in it's infancy), no mDNS, etc...Lots of things grew up after the fact. I agree that we can't foresee what will happen in the future, but that to me just proves my point. Worrying about the ability to create complex topologies in home networks that may or may not ever be needed or wanted just seems absurd to me. I tend to agree. Let's just go out and do it and choose from what others are doing. Some are doing /48, others are doing /56. Some are doing /64, even though we all know that is not very good for obvious reasons, but... ... let's just get going. Mark. From mark.tinka at seacom.mu Fri Jul 10 08:05:41 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jul 2015 10:05:41 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> Message-ID: <559F7CD5.5040407@seacom.mu> On 9/Jul/15 21:38, Tyler Applebaum wrote: > Do people actually use VLANs for security? It's nice to implement them for organizational purposes and to prevent broadcast propagation. Limitation of broadcast propagation could be viewed as a security feature. Mark. From mark.tinka at seacom.mu Fri Jul 10 08:18:05 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jul 2015 10:18:05 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150709195509.GA13865@puck.nether.net> References: <1436410157.27450.66.camel@karl> <469550651.308.1436446985586.JavaMail.mhammett@ThunderFuck> <20150709195509.GA13865@puck.nether.net> Message-ID: <559F7FBD.3080507@seacom.mu> On 9/Jul/15 21:55, Jared Mauch wrote: > > I run my home as a big broadcast domain, but there's no reason > I wouldn't perhaps segment things differently. There are a lot of people > who just "extend their wifi" by plugging in a 2nd router with a long cable > and don't realize they now have a new layer of nat, they just know > the wifi by the $newRouter got better. > > Should I have a lan party VLAN/SSID? Perhaps, but for ease of use > I let my AppleTV be on the same network as my iPhone so I can control them > with the Remote app. Otherwise you quickly get into kinky broadcast relay > or similar issues with multicast groups :) Same here, single broadcast domain - all other AP's beside the one hooked up to the DSL network in my house run in bridge-mode, however, i.e., just as AP's. Mark. From mark.tinka at seacom.mu Fri Jul 10 08:11:08 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jul 2015 10:11:08 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <25440C4BF31A8E44872003195DEB57BEAD8DB1@omail1.community-health.org> Message-ID: <559F7E1C.20008@seacom.mu> On 9/Jul/15 21:45, Matthew Huff wrote: > I've seen VLAN/subnet security used frequently in the financial world, even to the point of having full firewalls between vlans/subnets. Mostly for regulator purposes (Chinese firewall and all that). It's also common to allow outbound requests or redirect to different proxies based on source addresses within a corporate network. > > In residential networks, it's mostly used for guest networks that can route out to the internet, but not to other local devices. In the AN, you don't want residential neighbors viewing each others' Layer 2 domains. But using different VLAN's for that doesn't scale - so-called Split Horizons (Private VLAN's) are the answer. Mark. From tim at pelican.org Fri Jul 10 08:48:56 2015 From: tim at pelican.org (Tim Franklin) Date: Fri, 10 Jul 2015 09:48:56 +0100 (BST) Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> References: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> Message-ID: <1152328166.21068.1436518136685.JavaMail.zimbra@pelican.org> > And I?m saying you?re ignoring an important part of reality. > > Whatever ISPs default to deploying now will become the standard to which > application developers develop. > > Changing the ISP later is easy. I'm not even convinced of that. Once "/56" (or *any* value) is baked into the processes, hard-coded in systems all over the shop, assumptions made left, right and centre throughout the business, changing it will be hard. Only the tech part of changing the ISP is easy. It's the same reason it's so difficult to get IPv6 moving in some ISPs. Making the kit dance the appropriate jig in (modulo a few Luddite vendors and legacy kit that Just Won't Die) is quite straight-forward. Getting IT to update a field to not force [0-9]{1,3}.[0-9]{1-3}.[0-9]{1,3}.[0-9]{1,3}, or to add a new field, without a revenue stream attached is *hard*. (Yes, it's part of our job as technologists to explain why we should do it anyway. That doesn't stop it being hard.) Regards, Tim. From baldur.norddahl at gmail.com Fri Jul 10 09:26:32 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 10 Jul 2015 11:26:32 +0200 Subject: ISP DHCPv6 and /48 Message-ID: Hello, Let me introduce another first world problem. We use DHCPv4 to assign each user a IPv4 /32 and DHCPv6-PD to assign a IPv6 /128 WAN plus a /48 prefix. All good. However we are an ISP where the customer chooses his own CPE. We just ship a modem/mediaconverter/ONU with one ethernet port. The customer is expected to plug his home router in here. However sometimes we have a customer that wants to buy an extra IPv4 address. We are happy to sell him that. Now he has two (or more) IPv4 addresses. Turns out most of these customers are not configuring the extra IPv4 addresses on a single home router (most CPEs probably can not handle multiple WAN addresses anyway). Instead these people put in a switch and then have multiple devices, each with one IPv4. A typical setup is a home router (CPE) plus a server, or they might have some VPN device forced on them by their employeers or they might simply be sharing the internet connection with the neighbour (we allow that). However we are forbidden to deliver more than one /48. What to do? Currently we will deliver exactly one /48 to one device and just say sorry, you will have to figure out how to get IPv6 on your other devices. The experience is that 100% of the guys then simply do not have any IPv6 on the other devices. Figuring out how to route a slice of that /48 is too much for even most technical minded customers. Would you deliver say /52 prefixes instead but reserve /48, so the DHCP server has the option to deliver up to 16x /52 per customer? Regards, Baldur From marka at isc.org Fri Jul 10 10:09:02 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 10 Jul 2015 20:09:02 +1000 Subject: ISP DHCPv6 and /48 In-Reply-To: Your message of "Fri, 10 Jul 2015 11:26:32 +0200." References: Message-ID: <20150710100902.5292D32ACBDE@rock.dv.isc.org> In message , Baldur Norddahl writes: > Hello, > > Let me introduce another first world problem. We use DHCPv4 to assign each > user a IPv4 /32 and DHCPv6-PD to assign a IPv6 /128 WAN plus a /48 prefix. > All good. > > However we are an ISP where the customer chooses his own CPE. We just ship > a modem/mediaconverter/ONU with one ethernet port. The customer is expected > to plug his home router in here. > > However sometimes we have a customer that wants to buy an extra IPv4 > address. We are happy to sell him that. Now he has two (or more) IPv4 > addresses. Turns out most of these customers are not configuring the extra > IPv4 addresses on a single home router (most CPEs probably can not handle > multiple WAN addresses anyway). Instead these people put in a switch and > then have multiple devices, each with one IPv4. > > A typical setup is a home router (CPE) plus a server, or they might have > some VPN device forced on them by their employeers or they might simply be > sharing the internet connection with the neighbour (we allow that). > > However we are forbidden to deliver more than one /48. What to do? Who is forbidding you? Not the IETF. Not the RIRs. > Currently we will deliver exactly one /48 to one device and just say sorry, > you will have to figure out how to get IPv6 on your other devices. The > experience is that 100% of the guys then simply do not have any IPv6 on the > other devices. Figuring out how to route a slice of that /48 is too much > for even most technical minded customers. > > Would you deliver say /52 prefixes instead but reserve /48, so the DHCP > server has the option to deliver up to 16x /52 per customer? > > Regards, > > Baldur Just have them deploy a IPv6 router and configure it to brigde IPv4. As far as the existing clients are concerned they will just be on a LAN with a /64 out of the /48 and IPv4. A cheap linux / *bsd box will do this. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jcurran at arin.net Fri Jul 10 10:14:16 2015 From: jcurran at arin.net (John Curran) Date: Fri, 10 Jul 2015 10:14:16 +0000 Subject: Also Facebook (was: Re: Dual stack IPv6 for IPv4 depletion) In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> <8C616849-E018-4595-969B-54DE785632DC@arin.net> Message-ID: <3B610D43-D767-4308-A0E5-C995D20D8EDC@arin.net> On Jul 10, 2015, at 2:01 AM, Nicholas Suan > wrote: You should elaborate on some of these 'holes' then. Indeed. If there are ?holes? in the methodology, then they are quite consistent holes, since Google, APNIC, and Akamai are all reporting similar rates in US IPv6 end-user connection ratios (around 20% of connection attempts at present and growing rapidly) It?s possible that there?s some self-selection going on (i.e. that the subset of Internet users reflected in this percentage are disproportionate users of Google, Facebook, and Akamai-served content sites compared to the ?other? Internet end-users), but given the widespread usage of the companies providing the information, there?s a fairly high burden of proof necessary if one is to assert that the metrics are somehow not representative of the US Internet end-user population as a whole. /John John Curran President and CEO ARIN From baldur.norddahl at gmail.com Fri Jul 10 10:34:49 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 10 Jul 2015 12:34:49 +0200 Subject: ISP DHCPv6 and /48 In-Reply-To: <20150710100902.5292D32ACBDE@rock.dv.isc.org> References: <20150710100902.5292D32ACBDE@rock.dv.isc.org> Message-ID: On 10 July 2015 at 12:09, Mark Andrews wrote: > > Who is forbidding you? Not the IETF. Not the RIRs. > RIPE policy requires me to send in justification for review for any allocations larger than a /48. For a $35/month contract? Forget it, not going to happen. Plus it would be rejected. Just have them deploy a IPv6 router and configure it to brigde IPv4. > As far as the existing clients are concerned they will just be on > a LAN with a /64 out of the /48 and IPv4. > > A cheap linux / *bsd box will do this. > My customer support can not instruct users to get a cheap linux box. So what happens instead is that people will say ok, screw IPv6. Is that a problem or not? We designed the system believing this was not an actual problem. We expected people to put in a router in front, and then be able to split up their /48 from there. But reality is that it didn't work out that way. People want to put in a switch in front of multiple routers. That is the setup the common man understands how to configure. In part because it is actually hard to do it any other way if you want one public IPv4 per router and the routers are understood to be the common CPE everyone are buying at the hardware store. It is just sad this is not compatible with the advice we are getting on NANOG to hand out /48. Because we can only do one /48. There is no justification that RIPE would accept to hand out more than a /48 to a residential end user, where the only issue is that the end user does not know how to split up his /48. If we did /56 (or /52) we could assign the full /48 in regards to RIPE but have our DHCPv6 server hand it out in pieces such as a /56 at a time. This would work for the users. But it is not so popular among some people here on NANOG. We would be limiting the user to a /56 if he only has a single CPE. Perhaps the problem is that DHCPv6-PD is not intelligent enough. Yes there is a provision such that the user CPE could give a hint of how much space is want, but no, it doesn't work. The user CPE does not understand this issue either and has no information that could make it the smart place to do the decision. Plus which of the multiple CPEs would be in control? Maybe if the CPEs would go back and ask for more address space, if what they initially got ran out. But DHCPv6-PD does not really have a way to do that. In any case no CPE implements any such thing. Or maybe it is the RIPE policy that is the problem? I am not sure if the problem is any different for the other RIRs. Regards, Baldur From mark.tinka at seacom.mu Fri Jul 10 10:38:21 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 10 Jul 2015 12:38:21 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <9578293! AE169674F9A048B2BC9A081B401C7097D2E@MUNPRDMBXA1.medline.com> Message-ID: <559FA09D.6080409@seacom.mu> On 10/Jul/15 01:08, Owen DeLong wrote: > If we deliver /48s, then they will come up with innovative ways to > make use of those deployments. If we deliver /56s, then innovation > will be constrained to what can be delivered to /56s, even for sites > that have /48s. I'm finding it difficult to wrap my head around the difference coders will need to take between a /48 and /56 when developing software, but maybe I just haven't yet had enough beer this Friday :-\. Mark. From matthew at matthew.at Fri Jul 10 10:57:10 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 10 Jul 2015 03:57:10 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <23291.1436511218@turing-police.cc.vt.edu> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <559F6735.7000603 @matthew.at> <23291.1436511218@turing-police.cc.vt.edu> Message-ID: <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> > On Jul 9, 2015, at 11:53 PM, Valdis.Kletnieks at vt.edu wrote: > > On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said: > >> One of the hopeful outcomes of IPv6 adoption was that an ISP could get >> enough to last "forever" in a single transaction. But "forever" isn't >> very long at one /48 (or more) per customer. > > How long does it take to blow through a /20 at /48 a customer? A while. But the more likely case is that the guy before you asked for and got a /32, because that's the minimum (and already two steps up the fee scale, I might add) You want ISPs to start with /20s? I'll support that over on PPML if you propose it. But I'll also ask for /20 to have a fee category of "small". Matthew Kaufman (Sent from my iPhone) From jj at anexia.at Fri Jul 10 10:59:56 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 10 Jul 2015 10:59:56 +0000 Subject: Level3 routing issue US west coast Message-ID: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> Hi, does anyone else experience issues with the Level3 network at the US west coast? We see lots of broken paths like this: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 231 0.6 0.5 0.2 18.1 1.2 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 231 0.5 9.9 0.3 361.1 40.1 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 230 6.5 7.7 6.3 49.7 5.3 4. win-b4-link.telia.net 0.0% 230 6.6 6.8 6.4 20.2 1.5 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 230 6.6 9.3 6.3 69.1 9.6 6. ae-2-70.edge1.SanJose3.Level3.net 38.4% 230 164.8 165.0 164.5 194.9 2.6 7. ae-2-70.edge1.SanJose3.Level3.net 45.9% 230 164.7 164.8 164.5 174.1 0.9 8. 4.53.208.102 34.3% 230 634.9 310.7 168.5 680.1 199.7 9. TenGE5-4.br01.seo01.pccwbtn.net 34.1% 230 412.0 455.2 304.9 954.6 203.4 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 40.6% 230 323.4 441.4 323.1 822.0 182.1 11. 211.115.201.92 38.4% 230 289.8 412.9 289.6 846.7 185.4 12. 61.250.89.2 35.8% 230 290.6 439.4 290.2 804.3 205.1 13. ??? Trace from NYC is also broken: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. cr-01.0v-00-05.anx32.nyc.us.anexia-it.com 0.0% 30 0.4 4.3 0.4 57.8 13.3 2. nyk-b5-link.telia.net 0.0% 30 0.3 0.4 0.3 0.9 0.1 3. ??? 4. ae-3-80.edge1.SanJose3.Level3.net 17.2% 30 71.7 73.2 71.7 98.7 5.5 5. ae-3-80.edge1.SanJose3.Level3.net 0.0% 30 71.8 71.8 71.7 72.0 0.1 6. 4.53.208.102 31.0% 30 569.6 250.7 70.5 579.3 231.2 7. 63.218.250.73 31.0% 30 672.6 355.5 178.0 672.6 232.1 At 10:24 UTC+2 it was even more broken: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 326 0.4 0.5 0.3 39.7 2.2 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 326 0.5 6.7 0.3 198.1 26.3 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 326 6.6 7.6 6.4 43.6 4.5 4. win-b4-link.telia.net 0.0% 326 6.7 7.4 6.3 43.1 3.2 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 326 6.9 9.2 6.3 73.2 10.1 6. ae-1-60.edge5.LosAngeles1.Level3.net 62.6% 326 164.7 165.5 164.5 176.7 1.5 ae-2-70.edge1.SanJose3.Level3.net 7. ae-1-60.edge5.LosAngeles1.Level3.net 63.1% 326 164.8 165.8 164.6 204.2 3.9 ae-2-70.edge1.SanJose3.Level3.net 8. 205.129.5.70 74.2% 326 799.9 487.2 169.0 799.9 305.7 4.53.208.102 9. TenGE5-4.br01.seo01.pccwbtn.net 77.2% 326 1359. 701.0 308.7 3716. 510.6 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 75.1% 326 960.4 643.0 323.4 960.4 307.6 11. 211.115.201.92 68.9% 326 925.3 674.2 289.8 932.3 296.6 12. 61.250.89.2 72.9% 326 928.5 637.2 291.9 928.5 304.3 13. ??? best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 From oliver.oboyle at gmail.com Fri Jul 10 11:06:51 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Fri, 10 Jul 2015 07:06:51 -0400 Subject: Hotels/Airports with IPv6 Message-ID: 32 bit connection with a 32 bit address will open up an three-dimensional portal under the hotel. They all know this and work around it by selecting a lower connection speed. On July 10, 2015, at 3:59 AM, Alan Buxey wrote: 2 mbit is still more than 32 bit ;) alan From jcurran at istaff.org Fri Jul 10 11:30:11 2015 From: jcurran at istaff.org (John Curran) Date: Fri, 10 Jul 2015 07:30:11 -0400 Subject: ISP DHCPv6 and /48 In-Reply-To: References: <20150710100902.5292D32ACBDE@rock.dv.isc.org> Message-ID: <4ADDCF6E-7D60-404D-8669-ED6B2B7362E4@istaff.org> On Jul 10, 2015, at 6:34 AM, Baldur Norddahl wrote: > > RIPE policy requires me to send in justification for review for any > allocations larger than a /48. For a $35/month contract? Forget it, not > going to happen. Plus it would be rejected > ?. > It is just sad this is not compatible with the advice we are getting on > NANOG to hand out /48. Because we can only do one /48. There is no > justification that RIPE would accept to hand out more than a /48 to a > residential end user, where the only issue is that the end user does not > know how to split up his /48. > > If we did /56 (or /52) we could assign the full /48 in regards to RIPE but > have our DHCPv6 server hand it out in pieces such as a /56 at a time. This > would work for the users. But it is not so popular among some people here > on NANOG. We would be limiting the user to a /56 if he only has a single > CPE. > > ... > Or maybe it is the RIPE policy that is the problem? I am not sure if the > problem is any different for the other RIRs. Baldur - I am not aware of the RIPE practices with respect to IPv6 end-user assignments, but in the ARIN region, ISPs/LIR's make assignments to end users based on similar practices that the community adopted for ARIN?s end-user assignments. To my knowledge, ARIN does not review these ISP IPv6 end-user assignments (except after the fact and in aggregate if an ISP were to come to ARIN seeking an additional IPv6 block due to utilization of the previous.) Differences in policies between the regions is not necessarily any indication of a ?problem?; it can just as easily be an appropriate reflection of different underlying circumstances. /John John Curran President and CEO ARIN From kauer at biplane.com.au Fri Jul 10 12:16:01 2015 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 10 Jul 2015 22:16:01 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1147852741.869.1436486796920.JavaMail.mhammett@ThunderFuck> <1436490957.2977.25.camel@karl> Message-ID: <1436530561.2977.53.camel@karl> On Fri, 2015-07-10 at 02:08 -0400, Ricky Beam wrote: > And planning for a future that doesn't happen because you're too caught up > in *planning* that future is irrelevant, too. Advocating for fewer limits is not "planning". It's the opposite of it. It's about retaining more flexibility - as a matter of principle. > And in ~15 years when they have a jobs, they can change what we built. > (assuming ever let the paint dry long enough to use it.) We've had twenty years to implement IPv6 and golly haven't we done a great job? I suppose we could all hope that our kids will be less hopeless than we have been. Still... I'd prefer to leave them something that is easier to change and improve than the last thing we built. > IPv6 will never get there until it, too, "just works". No - so why do so many people just keep on and on moaning about how IPv6 doesn't "just work", forgetting that once upon a time IPv4 didn't "just work" either? "Getting there" and "just working" are two things that have to be developed together. One doesn't follow the other, they both become true side by side, or neither happens at all. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From jared at puck.Nether.net Fri Jul 10 12:17:01 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 10 Jul 2015 08:17:01 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <20150710020550.1CCC1329DA88@rock.dv.isc.org> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> <011d01d0bab1$e7890a00$b69b1e00$@gmail.com> <20150710020550.1CCC1329DA88@rock.dv.isc.org> Message-ID: <20150710121701.GF13865@puck.nether.net> On Fri, Jul 10, 2015 at 12:05:50PM +1000, Mark Andrews wrote: > > In message <011d01d0bab1$e7890a00$b69b1e00$@gmail.com>, "Chuck Church" writes: > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch > > Sent: Thursday, July 09, 2015 9:08 AM > > To: Colin Johnston > > Cc: nanog at nanog.org > > Subject: Re: Possible Sudden Uptick in ASA DOS? > > > > >My guess is a researcher. > > > > > > I wouldn't classify someone sending known malicious traffic towards > > someone else's network device attempting to crash it as a 'researcher'. > > Criminal is a better term. > > > > Chuck > > At what point does a well formed but bug triggering packet go from > "malicious" to "expected"? Don't know. Lets say it was something else. i've seen well formatted things that crash BIND. When posting to bind-users list it caused people to wonder why I didn't contact the security team first. The ASA is mostly a black box, it could be any number of things from a kernel bug to IPSEC, SSH, etc.. that trigger the issue. I would say malformed packets are common. I saw trafic coming from a specific employee home link ending up corrupted when reaching our SIP server. The result was it would crash as the malformed SIP was improperly parsed. The root cause? The wireless link connecting the employee to a local water tower was taking errors and the UDP checksums still matched with the corruption. http://downloads.asterisk.org/pub/security/AST-2011-009.html Either way see above where i said it's a guess, I have no direct personal knowledge. I'm guessing someone running a honeypot or darknet would have packets from the researcher types. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From joe at breathe-underwater.com Fri Jul 10 12:55:07 2015 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Fri, 10 Jul 2015 05:55:07 -0700 Subject: Level3 routing issue US west coast In-Reply-To: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> Message-ID: <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> Level3 had an issue with one of their core routers in Los Angeles last night(7pm Pacific) and early this morning(1am Pacific). Last update to my trouble ticket had the issue still being reviewed by engineering, but that a core router was dropping packets. > On Jul 10, 2015, at 3:59 AM, J?rgen Jaritsch wrote: > > Hi, > > does anyone else experience issues with the Level3 network at the US west coast? We see lots of broken paths like this: > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 231 0.6 0.5 0.2 18.1 1.2 > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 231 0.5 9.9 0.3 361.1 40.1 > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 230 6.5 7.7 6.3 49.7 5.3 > 4. win-b4-link.telia.net 0.0% 230 6.6 6.8 6.4 20.2 1.5 > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 230 6.6 9.3 6.3 69.1 9.6 > 6. ae-2-70.edge1.SanJose3.Level3.net 38.4% 230 164.8 165.0 164.5 194.9 2.6 > 7. ae-2-70.edge1.SanJose3.Level3.net 45.9% 230 164.7 164.8 164.5 174.1 0.9 > 8. 4.53.208.102 34.3% 230 634.9 310.7 168.5 680.1 199.7 > 9. TenGE5-4.br01.seo01.pccwbtn.net 34.1% 230 412.0 455.2 304.9 954.6 203.4 > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 40.6% 230 323.4 441.4 323.1 822.0 182.1 > 11. 211.115.201.92 38.4% 230 289.8 412.9 289.6 846.7 185.4 > 12. 61.250.89.2 35.8% 230 290.6 439.4 290.2 804.3 205.1 > 13. ??? > > Trace from NYC is also broken: > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. cr-01.0v-00-05.anx32.nyc.us.anexia-it.com 0.0% 30 0.4 4.3 0.4 57.8 13.3 > 2. nyk-b5-link.telia.net 0.0% 30 0.3 0.4 0.3 0.9 0.1 > 3. ??? > 4. ae-3-80.edge1.SanJose3.Level3.net 17.2% 30 71.7 73.2 71.7 98.7 5.5 > 5. ae-3-80.edge1.SanJose3.Level3.net 0.0% 30 71.8 71.8 71.7 72.0 0.1 > 6. 4.53.208.102 31.0% 30 569.6 250.7 70.5 579.3 231.2 > 7. 63.218.250.73 31.0% 30 672.6 355.5 178.0 672.6 232.1 > > > At 10:24 UTC+2 it was even more broken: > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 326 0.4 0.5 0.3 39.7 2.2 > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 326 0.5 6.7 0.3 198.1 26.3 > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 326 6.6 7.6 6.4 43.6 4.5 > 4. win-b4-link.telia.net 0.0% 326 6.7 7.4 6.3 43.1 3.2 > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 326 6.9 9.2 6.3 73.2 10.1 > 6. ae-1-60.edge5.LosAngeles1.Level3.net 62.6% 326 164.7 165.5 164.5 176.7 1.5 > ae-2-70.edge1.SanJose3.Level3.net > 7. ae-1-60.edge5.LosAngeles1.Level3.net 63.1% 326 164.8 165.8 164.6 204.2 3.9 > ae-2-70.edge1.SanJose3.Level3.net > 8. 205.129.5.70 74.2% 326 799.9 487.2 169.0 799.9 305.7 > 4.53.208.102 > 9. TenGE5-4.br01.seo01.pccwbtn.net 77.2% 326 1359. 701.0 308.7 3716. 510.6 > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 75.1% 326 960.4 643.0 323.4 960.4 307.6 > 11. 211.115.201.92 68.9% 326 925.3 674.2 289.8 932.3 296.6 > 12. 61.250.89.2 72.9% 326 928.5 637.2 291.9 928.5 304.3 > 13. ??? > > > best regards > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > From jj at anexia.at Fri Jul 10 13:06:45 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 10 Jul 2015 13:06:45 +0000 Subject: AW: Level3 routing issue US west coast In-Reply-To: <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> Message-ID: Hi Joseph, in the meantime I have ~20 verified paths which are affected and Level3 is simply not competent enough to reroute/drop the affected path ... FYI: my private ticket # is 9446435 ### There is also a new global ticket available: Network Event Detail Network Event Summary: Multiple devices were unreachable in Europe impacting IP services. Event Ticket ID: 9446797 Market Area Affected: Multiple Markets in Europe Ticket Create Date: 7/10/15 11:15:39 AM GMT Impacted For: 12 minutes Event Status: Active Time Since Last Update: 1 hour 39 minutes 7/10/15 11:26:39 AM GMT The IP NOC reported multiple devices were simultaneously unreachable in Europe impacting IP services. The devices recovered without any intervention from Level 3 after an interruption lasting twelve minutes. Due to the possibility of additional impacted, the IP NOC will monitor services until the completion of multiple ongoing events in the region. A final update will be se ### best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Joseph Jenkins Gesendet: Freitag, 10. Juli 2015 14:55 An: nanog at nanog.org Betreff: Re: Level3 routing issue US west coast Level3 had an issue with one of their core routers in Los Angeles last night(7pm Pacific) and early this morning(1am Pacific). Last update to my trouble ticket had the issue still being reviewed by engineering, but that a core router was dropping packets. > On Jul 10, 2015, at 3:59 AM, J?rgen Jaritsch wrote: > > Hi, > > does anyone else experience issues with the Level3 network at the US west coast? We see lots of broken paths like this: > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 231 0.6 0.5 0.2 18.1 1.2 > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 231 0.5 9.9 0.3 361.1 40.1 > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 230 6.5 7.7 6.3 49.7 5.3 > 4. win-b4-link.telia.net 0.0% 230 6.6 6.8 6.4 20.2 1.5 > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 230 6.6 9.3 6.3 69.1 9.6 > 6. ae-2-70.edge1.SanJose3.Level3.net 38.4% 230 164.8 165.0 164.5 194.9 2.6 > 7. ae-2-70.edge1.SanJose3.Level3.net 45.9% 230 164.7 164.8 164.5 174.1 0.9 > 8. 4.53.208.102 34.3% 230 634.9 310.7 168.5 680.1 199.7 > 9. TenGE5-4.br01.seo01.pccwbtn.net 34.1% 230 412.0 455.2 304.9 954.6 203.4 > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 40.6% 230 323.4 441.4 323.1 822.0 182.1 > 11. 211.115.201.92 38.4% 230 289.8 412.9 289.6 846.7 185.4 > 12. 61.250.89.2 35.8% 230 290.6 439.4 290.2 804.3 205.1 > 13. ??? > > Trace from NYC is also broken: > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. cr-01.0v-00-05.anx32.nyc.us.anexia-it.com 0.0% 30 0.4 4.3 0.4 57.8 13.3 > 2. nyk-b5-link.telia.net 0.0% 30 0.3 0.4 0.3 0.9 0.1 > 3. ??? > 4. ae-3-80.edge1.SanJose3.Level3.net 17.2% 30 71.7 73.2 71.7 98.7 5.5 > 5. ae-3-80.edge1.SanJose3.Level3.net 0.0% 30 71.8 71.8 71.7 72.0 0.1 > 6. 4.53.208.102 31.0% 30 569.6 250.7 70.5 579.3 231.2 > 7. 63.218.250.73 31.0% 30 672.6 355.5 178.0 672.6 232.1 > > > At 10:24 UTC+2 it was even more broken: > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 326 0.4 0.5 0.3 39.7 2.2 > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 326 0.5 6.7 0.3 198.1 26.3 > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 326 6.6 7.6 6.4 43.6 4.5 > 4. win-b4-link.telia.net 0.0% 326 6.7 7.4 6.3 43.1 3.2 > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 326 6.9 9.2 6.3 73.2 10.1 > 6. ae-1-60.edge5.LosAngeles1.Level3.net 62.6% 326 164.7 165.5 164.5 176.7 1.5 > ae-2-70.edge1.SanJose3.Level3.net > 7. ae-1-60.edge5.LosAngeles1.Level3.net 63.1% 326 164.8 165.8 164.6 204.2 3.9 > ae-2-70.edge1.SanJose3.Level3.net > 8. 205.129.5.70 74.2% 326 799.9 487.2 169.0 799.9 305.7 > 4.53.208.102 > 9. TenGE5-4.br01.seo01.pccwbtn.net 77.2% 326 1359. 701.0 308.7 3716. 510.6 > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 75.1% 326 960.4 643.0 323.4 960.4 307.6 > 11. 211.115.201.92 68.9% 326 925.3 674.2 289.8 932.3 296.6 > 12. 61.250.89.2 72.9% 326 928.5 637.2 291.9 928.5 304.3 > 13. ??? > > > best regards > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > From jcurran at arin.net Fri Jul 10 13:11:06 2015 From: jcurran at arin.net (John Curran) Date: Fri, 10 Jul 2015 13:11:06 +0000 Subject: Test-drive the OS X El Capitan public beta In-Reply-To: <1F161E6E-CB57-41F0-AD55-9259FDC7BA22@mx5.org.uk> References: <955685717.45543931.1436501286550.JavaMail.cboxp@nwk-cboxp-lapp02.apple.com> <1F161E6E-CB57-41F0-AD55-9259FDC7BA22@mx5.org.uk> Message-ID: On Jul 10, 2015, at 2:17 AM, Colin Johnston > wrote: lots of 6GB downloads this morning :) Colin Begin forwarded message: From: Apple Beta Software Program > Subject: Test-drive the OS X El Capitan public beta Date: 10 July 2015 05:08:06 BST To: colinj at mx5.org.uk The El Capitan public beta is now available from the Apple Beta Software Program. Test-drive it and let us know what you think. Also note that this particular release is also likely to further increase IPv6 traffic loads once out in the mainstream, as it includes some significant changes to Apple?s ?Happy Eyeballs? implementation? (see attached) Current growth in IPv6 traffic doesn?t necessarily include significant iPhone participation, but this will change shortly. FYI, /John John Curran President and CEO ARIN === David Schinazi > Thu, 09 July 2015 22:00 UTC Hi everyone, Today Apple released the first public seeds of iOS 9 and OS X El Capitan. These seeds (and the third developer seeds released yesterday) include an improved version of Happy Eyeballs. Based on our testing, this makes our Happy Eyeballs implementation go from roughly 50/50 IPv4/IPv6 in iOS 8 and Yosemite to ~99% IPv6 in iOS 9 and El Capitan betas. ... From wesley.george at twcable.com Fri Jul 10 13:21:54 2015 From: wesley.george at twcable.com (George, Wes) Date: Fri, 10 Jul 2015 09:21:54 -0400 Subject: ISP DHCPv6 and /48 In-Reply-To: References: <20150710100902.5292D32ACBDE@rock.dv.isc.org> Message-ID: On 7/10/15, 6:34 AM, "NANOG on behalf of Baldur Norddahl" wrote: >Perhaps the problem is that DHCPv6-PD is not intelligent enough. Yes there >is a provision such that the user CPE could give a hint of how much space >is want, but no, it doesn't work. WG] Sorry, [citation needed]. We are using DHCPv6-PD that listens for and responds properly to hints in production for millions of customers. Many of the cheap plastic routers are even smart enough to stand up their own DHCPv6 server so that they can do PD to give out /64s to subtended devices or split out the /56 or /60 that they were given to their WAN, LAN, and Guestnet so that each has its own subnet. Now you may have to specify a list of devices that properly support PD such that you know they will work with this configuration of multiple routers behind a switch, but requiring your customers to use a device that supports your implementation of a feature that they want isn't really that much of an imposition on them. You wouldn't blame the protocol when IPv6 doesn't work for your customers who use a device that doesn't support IPv6, would you? >The user CPE does not understand this >issue either and has no information that could make it the smart place to >do the decision. Plus which of the multiple CPEs would be in control? WG] IETF Homenet WG is currently chewing on the problem of multiple CPEs in an unmanaged environment. It's not an easy problem if you have to design it so that it works automagically no matter how strangely it's connected together. You may want to check it out: http://datatracker.ietf.org/wg/homenet/charter/ > >Maybe if the CPEs would go back and ask for more address space, if what >they initially got ran out. But DHCPv6-PD does not really have a way to do >that. In any case no CPE implements any such thing. WG] also not exactly true. No, most CPE won't do it automatically, but DHCPv6 can do it. Release existing prefix, request new prefix with bigger hint. Depending on DHCP server policy, you might even be able to do it in the opposite order (make before break) since you can have multiple prefixes. My hunch is that on most residential broadband setups, it's not likely to be hitless, and most cheap plastic routers can probably only do it via a reboot after you reconfigure it to ask for more space in the hint, but it's doable. See above recommendation for homenet if you want it to be automatic. Thanks, Wes George Anything below this line has been added by my company?s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From colinj at mx5.org.uk Fri Jul 10 13:27:12 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Fri, 10 Jul 2015 14:27:12 +0100 Subject: Test-drive the OS X El Capitan public beta In-Reply-To: References: <955685717.45543931.1436501286550.JavaMail.cboxp@nwk-cboxp-lapp02.apple.com> <1F161E6E-CB57-41F0-AD55-9259FDC7BA22@mx5.org.uk> Message-ID: <062E3F2E-F075-42F7-9243-42652D7DB7AB@mx5.org.uk> as well hopefully less upgrade traffic once installed as update install images less big as well colin Sent from my iPhone > On 10 Jul 2015, at 14:11, John Curran wrote: > >> On Jul 10, 2015, at 2:17 AM, Colin Johnston wrote: >> >> lots of 6GB downloads this morning :) >> >> Colin >> >> >>> Begin forwarded message: >>> >>> From: Apple Beta Software Program >>> Subject: Test-drive the OS X El Capitan public beta >>> Date: 10 July 2015 05:08:06 BST >>> To: colinj at mx5.org.uk >>> >>> >>> >>> The El Capitan public beta is now available from the Apple Beta Software Program. >>> Test-drive it and let us know what you think. > > Also note that this particular release is also likely to further increase IPv6 traffic loads > once out in the mainstream, as it includes some significant changes to Apple?s ?Happy > Eyeballs? implementation? (see attached) Current growth in IPv6 traffic doesn?t > necessarily include significant iPhone participation, but this will change shortly. > > FYI, > /John > > John Curran > President and CEO > ARIN > > === > >> David Schinazi Thu, 09 July 2015 22:00 UTC >> Hi everyone, >> Today Apple released the first public seeds of iOS 9 and OS X El Capitan. >> These seeds (and the third developer seeds released yesterday) include an improved version of Happy Eyeballs. >> >> Based on our testing, this makes our Happy Eyeballs implementation go from roughly 50/50 IPv4/IPv6 in iOS 8 and Yosemite >> to ~99% IPv6 in iOS 9 and El Capitan betas. >> ... > > From seth.mos at dds.nl Fri Jul 10 13:25:56 2015 From: seth.mos at dds.nl (Seth Mos) Date: Fri, 10 Jul 2015 15:25:56 +0200 Subject: Dual stack IPv6 for IPv4 depletion Message-ID: Meanwhile, I'm sitting here on a patio at a cafe on Samos, Greece. And the free wifi gives me native v6 to my tablet and phone without any intervention. Test-ipv6.com tells me that the score is 10/10 and all the google bits just work. So, surely it "just works". I wish we had it this easy in the Netherlands. There, sales still asks, "what for" (Vodafone fiber). Cheers, Seth Verzonden vanaf Samsung-tablet -------- Oorspronkelijk bericht -------- Van: Karl Auer Datum: 10-07-2015 14:16 (GMT+01:00) Aan: NANOG List Onderwerp: Re: Dual stack IPv6 for IPv4 depletion On Fri, 2015-07-10 at 02:08 -0400, Ricky Beam wrote: > And planning for a future that doesn't happen because you're too caught up > in *planning* that future is irrelevant, too. Advocating for fewer limits is not "planning". It's the opposite of it. It's about retaining more flexibility - as a matter of principle. > And in ~15 years when they have a jobs, they can change what we built. > (assuming ever let the paint dry long enough to use it.) We've had twenty years to implement IPv6 and golly haven't we done a great job? I suppose we could all hope that our kids will be less hopeless than we have been. Still... I'd prefer to leave them something that is easier to change and improve than the last thing we built. > IPv6 will never get there until it, too, "just works". No - so why do so many people just keep on and on moaning about how IPv6 doesn't "just work", forgetting that once upon a time IPv4 didn't "just work" either? "Getting there" and "just working" are two things that have to be developed together. One doesn't follow the other, they both become true side by side, or neither happens at all. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From cb.list6 at gmail.com Fri Jul 10 13:42:09 2015 From: cb.list6 at gmail.com (Ca By) Date: Fri, 10 Jul 2015 06:42:09 -0700 Subject: Level3 routing issue US west coast In-Reply-To: <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> Message-ID: On Friday, July 10, 2015, Joseph Jenkins wrote: > Level3 had an issue with one of their core routers in Los Angeles last > night(7pm Pacific) and early this morning(1am Pacific). Last update to my > trouble ticket had the issue still being reviewed by engineering, but that > a core router was dropping packets. > > I have seen this several times with level3. They confirm packets are dropping and sevice is degraded yet they refuse to take tactical corrective action for hours and hours. Makes me furious. CB > > On Jul 10, 2015, at 3:59 AM, J?rgen Jaritsch > wrote: > > > > Hi, > > > > does anyone else experience issues with the Level3 network at the US > west coast? We see lots of broken paths like this: > > > > Packets > Pings > > Host Loss% Snt Last > Avg Best Wrst StDev > > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 231 0.6 > 0.5 0.2 18.1 1.2 > > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 231 0.5 > 9.9 0.3 361.1 40.1 > > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 230 6.5 > 7.7 6.3 49.7 5.3 > > 4. win-b4-link.telia.net 0.0% 230 6.6 > 6.8 6.4 20.2 1.5 > > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 230 6.6 > 9.3 6.3 69.1 9.6 > > 6. ae-2-70.edge1.SanJose3.Level3.net 38.4% 230 164.8 > 165.0 164.5 194.9 2.6 > > 7. ae-2-70.edge1.SanJose3.Level3.net 45.9% 230 164.7 > 164.8 164.5 174.1 0.9 > > 8. 4.53.208.102 34.3% 230 634.9 > 310.7 168.5 680.1 199.7 > > 9. TenGE5-4.br01.seo01.pccwbtn.net 34.1% 230 412.0 > 455.2 304.9 954.6 203.4 > > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 40.6% 230 323.4 > 441.4 323.1 822.0 182.1 > > 11. 211.115.201.92 38.4% 230 289.8 > 412.9 289.6 846.7 185.4 > > 12. 61.250.89.2 35.8% 230 290.6 > 439.4 290.2 804.3 205.1 > > 13. ??? > > > > Trace from NYC is also broken: > > > > Packets > Pings > > Host Loss% Snt > Last Avg Best Wrst StDev > > 1. cr-01.0v-00-05.anx32.nyc.us.anexia-it.com 0.0% 30 > 0.4 4.3 0.4 57.8 13.3 > > 2. nyk-b5-link.telia.net 0.0% 30 > 0.3 0.4 0.3 0.9 0.1 > > 3. ??? > > 4. ae-3-80.edge1.SanJose3.Level3.net 17.2% 30 > 71.7 73.2 71.7 98.7 5.5 > > 5. ae-3-80.edge1.SanJose3.Level3.net 0.0% 30 > 71.8 71.8 71.7 72.0 0.1 > > 6. 4.53.208.102 31.0% 30 > 569.6 250.7 70.5 579.3 231.2 > > 7. 63.218.250.73 31.0% 30 > 672.6 355.5 178.0 672.6 232.1 > > > > > > At 10:24 UTC+2 it was even more broken: > > > > Packets > Pings > > Host Loss% Snt Last > Avg Best Wrst StDev > > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 326 0.4 > 0.5 0.3 39.7 2.2 > > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 326 0.5 > 6.7 0.3 198.1 26.3 > > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 326 6.6 > 7.6 6.4 43.6 4.5 > > 4. win-b4-link.telia.net 0.0% 326 6.7 > 7.4 6.3 43.1 3.2 > > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 326 6.9 > 9.2 6.3 73.2 10.1 > > 6. ae-1-60.edge5.LosAngeles1.Level3.net 62.6% 326 164.7 > 165.5 164.5 176.7 1.5 > > ae-2-70.edge1.SanJose3.Level3.net > > 7. ae-1-60.edge5.LosAngeles1.Level3.net 63.1% 326 164.8 > 165.8 164.6 204.2 3.9 > > ae-2-70.edge1.SanJose3.Level3.net > > 8. 205.129.5.70 74.2% 326 799.9 > 487.2 169.0 799.9 305.7 > > 4.53.208.102 > > 9. TenGE5-4.br01.seo01.pccwbtn.net 77.2% 326 1359. > 701.0 308.7 3716. 510.6 > > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 75.1% 326 960.4 > 643.0 323.4 960.4 307.6 > > 11. 211.115.201.92 68.9% 326 925.3 > 674.2 289.8 932.3 296.6 > > 12. 61.250.89.2 72.9% 326 928.5 > 637.2 291.9 928.5 304.3 > > 13. ??? > > > > > > best regards > > > > J?rgen Jaritsch > > Head of Network & Infrastructure > > > > ANEXIA Internetdienstleistungs GmbH > > > > Telefon: +43-5-0556-300 > > Telefax: +43-5-0556-500 > > > > E-Mail: jj at anexia.at > > > Web: http://www.anexia.at > > > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > > Gesch?ftsf?hrer: Alexander Windbichler > > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT > U63216601 > > > > From jj at anexia.at Fri Jul 10 13:46:39 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Fri, 10 Jul 2015 13:46:39 +0000 Subject: AW: Level3 routing issue US west coast In-Reply-To: References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> Message-ID: Hi, sitting here and watching the packet loss coming and going :(. It changes every 10-25min. Looks like an massive issue in San Jose - routers out there sometimes have an latency from 5-6 SECONDS ... best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Ca By Gesendet: Freitag, 10. Juli 2015 15:42 An: Joseph Jenkins Cc: nanog at nanog.org Betreff: Re: Level3 routing issue US west coast On Friday, July 10, 2015, Joseph Jenkins wrote: > Level3 had an issue with one of their core routers in Los Angeles last > night(7pm Pacific) and early this morning(1am Pacific). Last update to my > trouble ticket had the issue still being reviewed by engineering, but that > a core router was dropping packets. > > I have seen this several times with level3. They confirm packets are dropping and sevice is degraded yet they refuse to take tactical corrective action for hours and hours. Makes me furious. CB > > On Jul 10, 2015, at 3:59 AM, J?rgen Jaritsch > wrote: > > > > Hi, > > > > does anyone else experience issues with the Level3 network at the US > west coast? We see lots of broken paths like this: > > > > Packets > Pings > > Host Loss% Snt Last > Avg Best Wrst StDev > > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 231 0.6 > 0.5 0.2 18.1 1.2 > > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 231 0.5 > 9.9 0.3 361.1 40.1 > > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 230 6.5 > 7.7 6.3 49.7 5.3 > > 4. win-b4-link.telia.net 0.0% 230 6.6 > 6.8 6.4 20.2 1.5 > > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 230 6.6 > 9.3 6.3 69.1 9.6 > > 6. ae-2-70.edge1.SanJose3.Level3.net 38.4% 230 164.8 > 165.0 164.5 194.9 2.6 > > 7. ae-2-70.edge1.SanJose3.Level3.net 45.9% 230 164.7 > 164.8 164.5 174.1 0.9 > > 8. 4.53.208.102 34.3% 230 634.9 > 310.7 168.5 680.1 199.7 > > 9. TenGE5-4.br01.seo01.pccwbtn.net 34.1% 230 412.0 > 455.2 304.9 954.6 203.4 > > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 40.6% 230 323.4 > 441.4 323.1 822.0 182.1 > > 11. 211.115.201.92 38.4% 230 289.8 > 412.9 289.6 846.7 185.4 > > 12. 61.250.89.2 35.8% 230 290.6 > 439.4 290.2 804.3 205.1 > > 13. ??? > > > > Trace from NYC is also broken: > > > > Packets > Pings > > Host Loss% Snt > Last Avg Best Wrst StDev > > 1. cr-01.0v-00-05.anx32.nyc.us.anexia-it.com 0.0% 30 > 0.4 4.3 0.4 57.8 13.3 > > 2. nyk-b5-link.telia.net 0.0% 30 > 0.3 0.4 0.3 0.9 0.1 > > 3. ??? > > 4. ae-3-80.edge1.SanJose3.Level3.net 17.2% 30 > 71.7 73.2 71.7 98.7 5.5 > > 5. ae-3-80.edge1.SanJose3.Level3.net 0.0% 30 > 71.8 71.8 71.7 72.0 0.1 > > 6. 4.53.208.102 31.0% 30 > 569.6 250.7 70.5 579.3 231.2 > > 7. 63.218.250.73 31.0% 30 > 672.6 355.5 178.0 672.6 232.1 > > > > > > At 10:24 UTC+2 it was even more broken: > > > > Packets > Pings > > Host Loss% Snt Last > Avg Best Wrst StDev > > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 326 0.4 > 0.5 0.3 39.7 2.2 > > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 326 0.5 > 6.7 0.3 198.1 26.3 > > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 326 6.6 > 7.6 6.4 43.6 4.5 > > 4. win-b4-link.telia.net 0.0% 326 6.7 > 7.4 6.3 43.1 3.2 > > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 326 6.9 > 9.2 6.3 73.2 10.1 > > 6. ae-1-60.edge5.LosAngeles1.Level3.net 62.6% 326 164.7 > 165.5 164.5 176.7 1.5 > > ae-2-70.edge1.SanJose3.Level3.net > > 7. ae-1-60.edge5.LosAngeles1.Level3.net 63.1% 326 164.8 > 165.8 164.6 204.2 3.9 > > ae-2-70.edge1.SanJose3.Level3.net > > 8. 205.129.5.70 74.2% 326 799.9 > 487.2 169.0 799.9 305.7 > > 4.53.208.102 > > 9. TenGE5-4.br01.seo01.pccwbtn.net 77.2% 326 1359. > 701.0 308.7 3716. 510.6 > > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 75.1% 326 960.4 > 643.0 323.4 960.4 307.6 > > 11. 211.115.201.92 68.9% 326 925.3 > 674.2 289.8 932.3 296.6 > > 12. 61.250.89.2 72.9% 326 928.5 > 637.2 291.9 928.5 304.3 > > 13. ??? > > > > > > best regards > > > > J?rgen Jaritsch > > Head of Network & Infrastructure > > > > ANEXIA Internetdienstleistungs GmbH > > > > Telefon: +43-5-0556-300 > > Telefax: +43-5-0556-500 > > > > E-Mail: jj at anexia.at > > > Web: http://www.anexia.at > > > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > > Gesch?ftsf?hrer: Alexander Windbichler > > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT > U63216601 > > > > From jj at anexia.at Fri Jul 10 14:54:52 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Fri, 10 Jul 2015 14:54:52 +0000 Subject: AW: Level3 routing issue US west coast References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> Message-ID: <11cd4154ae384babbdd11b5df252ee1f@anx-i-dag02.anx.local> Wow .... Level3 responded to me that they had an issue last night .... but they simply did nothing ... for at least 10 hours they did nothing to fix the issue: ### Event Case ID: 9446216 Location: Los Angeles, CA Impacted For: 10 hours 52 minutes ETR: Unknown Bridge: N/A 08:52 GMT - Event Conclusion Summary Start Time: 07/09 19:48 GMT Stop Time: 07/10 06:40 GMT Root Cause: A packet loss issue in Los Angeles, CA. Fix Action: The packet loss issue resolved before any action was taken. Summary: The IP NOC is currently investigated a packet loss issue in Los Angeles, CA that was impacting IP services. The packet loss issue resolved before any action was taken and the IP NOC deemed services are stable after monitoring was concluded. 07:53 GMT - The IP NOC is currently monitoring services after the packet loss issue resolved before any action was taken. An update will be sent when traffic is deemed stable or if status changes. 06:43 GMT - The IP NOC is currently investigating a packet loss issue in Los Angeles, CA that is impacting IP services. Troubleshooting efforts are ongoing with no estimated time to restore services available at this point. Please be advised that updates for this event will be relayed hourly unless otherwise noted. ### best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: J?rgen Jaritsch Gesendet: Freitag, 10. Juli 2015 15:47 An: 'Ca By'; Joseph Jenkins Cc: nanog at nanog.org Betreff: AW: Level3 routing issue US west coast Hi, sitting here and watching the packet loss coming and going :(. It changes every 10-25min. Looks like an massive issue in San Jose - routers out there sometimes have an latency from 5-6 SECONDS ... best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Ca By Gesendet: Freitag, 10. Juli 2015 15:42 An: Joseph Jenkins Cc: nanog at nanog.org Betreff: Re: Level3 routing issue US west coast On Friday, July 10, 2015, Joseph Jenkins wrote: > Level3 had an issue with one of their core routers in Los Angeles last > night(7pm Pacific) and early this morning(1am Pacific). Last update to my > trouble ticket had the issue still being reviewed by engineering, but that > a core router was dropping packets. > > I have seen this several times with level3. They confirm packets are dropping and sevice is degraded yet they refuse to take tactical corrective action for hours and hours. Makes me furious. CB > > On Jul 10, 2015, at 3:59 AM, J?rgen Jaritsch > wrote: > > > > Hi, > > > > does anyone else experience issues with the Level3 network at the US > west coast? We see lots of broken paths like this: > > > > Packets > Pings > > Host Loss% Snt Last > Avg Best Wrst StDev > > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 231 0.6 > 0.5 0.2 18.1 1.2 > > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 231 0.5 > 9.9 0.3 361.1 40.1 > > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 230 6.5 > 7.7 6.3 49.7 5.3 > > 4. win-b4-link.telia.net 0.0% 230 6.6 > 6.8 6.4 20.2 1.5 > > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 230 6.6 > 9.3 6.3 69.1 9.6 > > 6. ae-2-70.edge1.SanJose3.Level3.net 38.4% 230 164.8 > 165.0 164.5 194.9 2.6 > > 7. ae-2-70.edge1.SanJose3.Level3.net 45.9% 230 164.7 > 164.8 164.5 174.1 0.9 > > 8. 4.53.208.102 34.3% 230 634.9 > 310.7 168.5 680.1 199.7 > > 9. TenGE5-4.br01.seo01.pccwbtn.net 34.1% 230 412.0 > 455.2 304.9 954.6 203.4 > > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 40.6% 230 323.4 > 441.4 323.1 822.0 182.1 > > 11. 211.115.201.92 38.4% 230 289.8 > 412.9 289.6 846.7 185.4 > > 12. 61.250.89.2 35.8% 230 290.6 > 439.4 290.2 804.3 205.1 > > 13. ??? > > > > Trace from NYC is also broken: > > > > Packets > Pings > > Host Loss% Snt > Last Avg Best Wrst StDev > > 1. cr-01.0v-00-05.anx32.nyc.us.anexia-it.com 0.0% 30 > 0.4 4.3 0.4 57.8 13.3 > > 2. nyk-b5-link.telia.net 0.0% 30 > 0.3 0.4 0.3 0.9 0.1 > > 3. ??? > > 4. ae-3-80.edge1.SanJose3.Level3.net 17.2% 30 > 71.7 73.2 71.7 98.7 5.5 > > 5. ae-3-80.edge1.SanJose3.Level3.net 0.0% 30 > 71.8 71.8 71.7 72.0 0.1 > > 6. 4.53.208.102 31.0% 30 > 569.6 250.7 70.5 579.3 231.2 > > 7. 63.218.250.73 31.0% 30 > 672.6 355.5 178.0 672.6 232.1 > > > > > > At 10:24 UTC+2 it was even more broken: > > > > Packets > Pings > > Host Loss% Snt Last > Avg Best Wrst StDev > > 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 326 0.4 > 0.5 0.3 39.7 2.2 > > 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 326 0.5 > 6.7 0.3 198.1 26.3 > > 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 326 6.6 > 7.6 6.4 43.6 4.5 > > 4. win-b4-link.telia.net 0.0% 326 6.7 > 7.4 6.3 43.1 3.2 > > 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 326 6.9 > 9.2 6.3 73.2 10.1 > > 6. ae-1-60.edge5.LosAngeles1.Level3.net 62.6% 326 164.7 > 165.5 164.5 176.7 1.5 > > ae-2-70.edge1.SanJose3.Level3.net > > 7. ae-1-60.edge5.LosAngeles1.Level3.net 63.1% 326 164.8 > 165.8 164.6 204.2 3.9 > > ae-2-70.edge1.SanJose3.Level3.net > > 8. 205.129.5.70 74.2% 326 799.9 > 487.2 169.0 799.9 305.7 > > 4.53.208.102 > > 9. TenGE5-4.br01.seo01.pccwbtn.net 77.2% 326 1359. > 701.0 308.7 3716. 510.6 > > 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 75.1% 326 960.4 > 643.0 323.4 960.4 307.6 > > 11. 211.115.201.92 68.9% 326 925.3 > 674.2 289.8 932.3 296.6 > > 12. 61.250.89.2 72.9% 326 928.5 > 637.2 291.9 928.5 304.3 > > 13. ??? > > > > > > best regards > > > > J?rgen Jaritsch > > Head of Network & Infrastructure > > > > ANEXIA Internetdienstleistungs GmbH > > > > Telefon: +43-5-0556-300 > > Telefax: +43-5-0556-500 > > > > E-Mail: jj at anexia.at > > > Web: http://www.anexia.at > > > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > > Gesch?ftsf?hrer: Alexander Windbichler > > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT > U63216601 > > > > From chuckchurch at gmail.com Fri Jul 10 15:46:41 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Fri, 10 Jul 2015 11:46:41 -0400 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <20150710020550.1CCC1329DA88@rock.dv.isc.org> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <965698F8-6A2C-4246-91EA-F2425A1748D4@puck.nether.net> <011d01d0bab1$e7890a00$b69b1e00$@gmail.com> <20150710020550.1CCC1329DA88@rock.dv.isc.org> Message-ID: <00b201d0bb27$9eea7ab0$dcbf7010$@gmail.com> I would say it depends on the complexity and probability of it happening accidentally. An incorrect letter (language change perhaps) in a URL that crashes a web server might not be malicious. A crafted ESP or ISAKMP packet that was created in a Linux packet tool and 'randomly' hits your VPN I'd say is no accident. I agree with Jared, patch your stuff when the PSIRTs come out. But whether or not you're patched, if you're attacked, that person still is breaking the law. Think about leaving your car somewhere with the door open and keys in ignition. Someone steals it. They're still a criminal, even though you made their 'job' as easy as possible. Chuck -----Original Message----- From: Mark Andrews [mailto:marka at isc.org] Sent: Thursday, July 09, 2015 10:06 PM To: Chuck Church Cc: 'Jared Mauch'; 'Colin Johnston'; nanog at nanog.org Subject: Re: Possible Sudden Uptick in ASA DOS? In message <011d01d0bab1$e7890a00$b69b1e00$@gmail.com>, "Chuck Church" writes: > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch > Sent: Thursday, July 09, 2015 9:08 AM > To: Colin Johnston > Cc: nanog at nanog.org > Subject: Re: Possible Sudden Uptick in ASA DOS? > > >My guess is a researcher. > > > I wouldn't classify someone sending known malicious traffic towards > someone else's network device attempting to crash it as a 'researcher'. > Criminal is a better term. > > Chuck At what point does a well formed but bug triggering packet go from "malicious" to "expected"? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Fri Jul 10 15:54:00 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jul 2015 11:54:00 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: > I working on a large airport WiFi deployment right now. IPv6 is "allowed for in the future" but not configured in the short term. With less than 10,000 ephemeral users, we don't expect users to demand IPv6 until most mobile devices and apps come ready to use IPv6 by default. > 'we don't expect users to demand ipv6' aside from #nanog folks, who 'demands' ipv6? Don't they actually 'demand' "access to content on the internet" ? Since you seem to have a greenfield deployment, why NOT just put v6 in place on day0? retrofitting it is surely going to cost time/materials and probably upgrades to gear that could be avoided by doing it in the initial installation, right? From owen at delong.com Fri Jul 10 16:05:53 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jul 2015 09:05:53 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1147852741.869.1436486796920.JavaMail.mhammett@ThunderFuck> <1436490957.2977.25.camel@karl> Message-ID: <285F7FE1-C39E-4A58-B524-18B8B5369C82@delong.com> > On Jul 9, 2015, at 23:08 , Ricky Beam wrote: > > On Thu, 09 Jul 2015 21:15:57 -0400, Karl Auer wrote: >> Actually I was mentioning thousands. > > Dozens, millions, whatever. Pick something and get on with it already. I don?t know anyone that?s going to get upset with you if you deploy /48s to end sites. Sure, there are lots of /56 advocates out there, but none of them are going to cause grief if you use /48 instead. ALL of the RIRs accept /48 as an end-site assignment without question. We picked /48 a long time ago. I?m not sure why longer prefixes keep coming up. I think it?s IPv4-think on the part of people who can?t get their heads out of the scarcity mentality. >> What you personally don't foresee is pretty much irrelevant to what will >> actually happen... > > And planning for a future that doesn't happen because you're too caught up in *planning* that future is irrelevant, too. I?m fully dual-stacked and have a /48 in my house. Do you? I?ve been implementing IPv6 in various networks for years. I?ve probably dual-stacked more than 100 networks by now. How many have you done? I don?t think any of us advocating /48s are sitting here planning without implementing. >> Like pretty much the entire current generation of net techs, your >> imagination is limited by your past. But there are kids in school right >> now who do not suffer from the same limitations - and they will build >> wonders. > > And in ~15 years when they have a jobs, they can change what we built. (assuming ever let the paint dry long enough to use it.) I tend to think of the internet more like powder-coating. It goes on dry and often comes out half-baked. >> PS: People keep dissing "home users" saying how they are incapable of >> understanding stuff and installing all these complex networks. Twenty >> years ago getting online at home took lots of know-how; getting more >> than one device online in the home took even more. Now you can just buy >> a $50 bit of kit, plug it in and your desktops, laptops, smartphones, >> tablets, televisions, digital radios and wireless sound systems just >> work. With main and guest networks, multiple wifi protocols, and in many >> cases basic IPv6 as well. There is no reason to think that the >> complexity of future networks will not be equally well packaged for the >> home. > > 20 years ago was 1995. It took "some" know how (how to run setup.exe on the floppy you ISP sent you.) Windows 95 made it much easier by having that software in the default OS. Building a network took a bit longer to (a) be wanted/needed and (b) be available and affordable in the home. (few people had more than one computer to network in the first place. Today, you have three of them on your person at any given moment.) > > Despite the proliferation of the internet and network tech, the average person today knows even less than two decades ago. Because everything "just works". IPv6 will never get there until it, too, "just works". We're still a long way off in the home -- both because providers aren't doing it, and because the CPE tech is lagging. Mobile by contrast, due to necessity and speed of tech turnover, is there already; you have to intentionally check to know you're using IPv6. We can agree to disagree? I made good money back then helping home users get their home networks set up because it was too hard for them to do themselves as a side gig. IPv6 is ?just working? for a millions of home users that wouldn?t know it if they (or someone else) didn?t deliberately check. That?s reality today. The number is growing fairly quickly as well. Owen From owen at delong.com Fri Jul 10 16:12:50 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jul 2015 09:12:50 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559F6735.7000603@matthew.at> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <559F673! 5.7000603@matthew.at> Message-ID: <684B52DE-D9C0-4F16-A83D-E2B502FA5B45@delong.com> > On Jul 9, 2015, at 23:33 , Matthew Kaufman wrote: > > On 7/9/2015 3:07 PM, Owen DeLong wrote: >> >> Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever? >> > > Sure. To avoid having to go back and deal with ARIN yet again for more IPv6 space. > > One of the hopeful outcomes of IPv6 adoption was that an ISP could get enough to last "forever" in a single transaction. But "forever" isn't very long at one /48 (or more) per customer. > > Matthew Kaufman I don?t understand how that shortens forever if you ask for the right size block the first time. I?ll be surprised if HE hands out enough /48s to empty their /24 any time short of something approximating forever. It?s been at least 3 years since I got that for them. They?re definitely handing out a /48 per end site with the exception of free end-sites that don?t bother to click the ?give me a /48? checkbox. Getting IPv6 from ARIN is really easy. Getting more IPv6 from ARIN is really easy if you get anywhere near filling up your IPv6 block. MUCH MUCH easier than IPv4. As an example, I bet if they wanted to, Comcast could easily qualify for a /12 under current ARIN policy. The latest figures I could find show them at just over 22.4 million broadband subscribers. Let?s assume they have 40 million just to be conservative. If you packed those in, you could fit them in 3 /24s (actually, about 2.3 /24s technically). A /12 is 4096 /24s. Please tell me again how you can?t hand out /48s per end-site forever with a single ARIN allocation? Owen From owen at delong.com Fri Jul 10 16:23:36 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jul 2015 09:23:36 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <559F7B59.5040101@ttec.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> Message-ID: <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> > On Jul 10, 2015, at 00:59 , Joe Maimon wrote: > > There has been tomes on this topic. There will continue to be many more. > > That is because many of you continue in trying to defend the following concept. > > customer subnet bits == isp customers bits > > So now, the ISP is supposed to put some effort and gain more bits. Why not the customer? > > Its inherently suspicious. Because its inherently wrong - for the ISP, and possibly for the address space as well. > > Indulge me as I wax poetic. > > I venture to say that proponents want to see everyone else have the service of their own dreams. When broadband rolled to the masses with a single ipv4 address per subscriber, forget about routing, their hearts broke. The new common denominator was a far cry from what their experience was. The division of internet into different classes of netizens a bitter pill to swallow. You are only one budget cut away from joining the ho-poloi. Its quite scary. > > Hence the determination that no user should ever have to go without enough addresses ever again. A new common denominator, now is the time to get it accepted! > > It will be like the old days, a class C with every leased line! Forever! I will concur with most of this. > > And the ISPs? > > They have enough to get started and they can get more if they put the effort in. Actually, as has been pointed out earlier by me and Valdis at least, they can get enough to last a good long time up front if they just do a little bit of napkin math before submitting their request. Here?s how it works: JimBob?s ISP and Bait shop serves their customers from 25 distinct wiring centers. They expect to deploy another 50 wiring centers over the next 5 years. Their largest wiring center supports 5,000,000 customers. Representing 5,000,000 requires 23 bits. Rounded up to a multiple of 4 becomes 24 bits. At 24 bits, 5,000,000 is < 75% of the available /48s. So 24 bits is a good number. Representing 75 wiring centers requires another 6 bits. Rounded up to a multiple of 4 becomes 8 bits. At 8 bits, 75 is < 75% of the 256 available numbers, so 8 is a good number. 24 + 8 is 32. 48 - 32 is 16. JimBob?s ISP can apply to ARIN for a /16. Other RIRs are a little different, but still usually not terribly hard to get a large allocation if it can be even remotely justified. > So all the rational and logical debate is pointless. Gut feelings, philosophy and emotions are what is at stake and those tend not to respond well to things like logic and reason. Perhaps. Unfortunately, I think it is more the long-prefix crowd that is going on gut feelings. Unless you can show me how there?s harm to the ISPs from /48s per end site, or any other logic to support the need to retain the concept of second-class netizens, then I think logic is on the side of a more egalitarian internet. Owen From owen at delong.com Fri Jul 10 16:29:17 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jul 2015 09:29:17 -0700 Subject: ISP DHCPv6 and /48 In-Reply-To: References: Message-ID: My solution would be to tell them if they want more than 1 IPv4 /32, they need a router. Then route a prefix of appropriate size to their router. /48 for IPv6 as you are doing, and /n for IPv4. They want 2 addresses, give them a /30. 3-6, /29; 7-14, /28, etc. Seems pretty straight forward to me. Owen > On Jul 10, 2015, at 02:26 , Baldur Norddahl wrote: > > Hello, > > Let me introduce another first world problem. We use DHCPv4 to assign each > user a IPv4 /32 and DHCPv6-PD to assign a IPv6 /128 WAN plus a /48 prefix. > All good. > > However we are an ISP where the customer chooses his own CPE. We just ship > a modem/mediaconverter/ONU with one ethernet port. The customer is expected > to plug his home router in here. > > However sometimes we have a customer that wants to buy an extra IPv4 > address. We are happy to sell him that. Now he has two (or more) IPv4 > addresses. Turns out most of these customers are not configuring the extra > IPv4 addresses on a single home router (most CPEs probably can not handle > multiple WAN addresses anyway). Instead these people put in a switch and > then have multiple devices, each with one IPv4. > > A typical setup is a home router (CPE) plus a server, or they might have > some VPN device forced on them by their employeers or they might simply be > sharing the internet connection with the neighbour (we allow that). > > However we are forbidden to deliver more than one /48. What to do? > > Currently we will deliver exactly one /48 to one device and just say sorry, > you will have to figure out how to get IPv6 on your other devices. The > experience is that 100% of the guys then simply do not have any IPv6 on the > other devices. Figuring out how to route a slice of that /48 is too much > for even most technical minded customers. > > Would you deliver say /52 prefixes instead but reserve /48, so the DHCP > server has the option to deliver up to 16x /52 per customer? > > Regards, > > Baldur From jh at bofh.de Fri Jul 10 15:16:27 2015 From: jh at bofh.de (Jens Hoffmann) Date: Fri, 10 Jul 2015 17:16:27 +0200 Subject: AW: Level3 routing issue US west coast In-Reply-To: <11cd4154ae384babbdd11b5df252ee1f@anx-i-dag02.anx.local> References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> <11cd4154ae384babbdd11b5df252ee1f@anx-i-dag02.anx.local> Message-ID: <005d01d0bb23$6475de00$2d619a00$@bofh.de> Hi, >Wow .... Level3 responded to me that they had an issue last night .... but they simply did nothing ... for at least 10 hours they >did nothing to fix the issue: Any SLA broken? Probably not, that would be a reason to move. Kind regards, Jens From jj at anexia.at Fri Jul 10 16:44:35 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Fri, 10 Jul 2015 16:44:35 +0000 Subject: AW: Level3 routing issue US west coast In-Reply-To: <005d01d0bb23$6475de00$2d619a00$@bofh.de> References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> <11cd4154ae384babbdd11b5df252ee1f@anx-i-dag02.anx.local> <005d01d0bb23$6475de00$2d619a00$@bofh.de> Message-ID: Hi, No SLA broken cause A- and B-End were not directly our circuits ... but it helps a lot to place some new orders ... at other partners :). best regards J?rgen Jaritsch -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Jens Hoffmann Gesendet: Freitag, 10. Juli 2015 17:16 An: nanog at nanog.org Betreff: AW: Level3 routing issue US west coast Hi, >Wow .... Level3 responded to me that they had an issue last night .... but they simply did nothing ... for at least 10 hours they >did nothing to fix the issue: Any SLA broken? Probably not, that would be a reason to move. Kind regards, Jens From owen at delong.com Fri Jul 10 16:52:11 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jul 2015 09:52:11 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <559F673! 5.7000603 @matthew.at> <23291.1436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> Message-ID: <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> > On Jul 10, 2015, at 03:57 , Matthew Kaufman wrote: > > > >> On Jul 9, 2015, at 11:53 PM, Valdis.Kletnieks at vt.edu wrote: >> >> On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said: >> >>> One of the hopeful outcomes of IPv6 adoption was that an ISP could get >>> enough to last "forever" in a single transaction. But "forever" isn't >>> very long at one /48 (or more) per customer. >> >> How long does it take to blow through a /20 at /48 a customer? > > A while. But the more likely case is that the guy before you asked for and got a /32, because that's the minimum (and already two steps up the fee scale, I might add) > > You want ISPs to start with /20s? I'll support that over on PPML if you propose it. But I'll also ask for /20 to have a fee category of "small". > > Matthew Kaufman > > (Sent from my iPhone) According to https://www.arin.net/fees/fee_schedule.html ISP / ALLOCATIONS INITIAL REGISTRATION OR ANNUAL FEES Service Category Initial Registration or Annual Fee (US Dollars) IPv4 Block Size IPv6 Block Size XX-Small $500 /22 or smaller /40 or smaller X-Small $1,000 Larger than /22, up to and including /20 Larger than /40, up to and including /36 Small $2,000 Larger than /20, up to and including /18 Larger than /36, up to and including /32 Medium $4,000 Larger than /18, up to and including /16 Larger than /32, up to and including /28 Large $8,000 Larger than /16, up to and including /14 Larger than /28, up to and including /24 X-Large $16,000 Larger than /14, up to and including /12 Larger than /24, up to and including /20 XX-Large $32,000 Larger than /12 Larger than /20 If your IPv4 ISP fits in a /22 or smaller, you can hand out /48s from a /32 for a very long time. (maximum 1024 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure) If your IPv4 ISP fits in a /20 or smaller, you can hand out /48s from a /32 for a pretty long time. (maximum 4096 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure) If your IPv4 ISP fits in a /18 or smaller, you can hand out /48s from a /32 for quite a while. (maximum 16,384 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure). At IPv6 /18 or smaller, you?re in the same fee category as an IPv6 /32. As you go up, the situation only gets better? If your ISP uses an IPv4 /16, then you have a maximum of 65,536 customers with no allowance for infrastructure. For free, you can get an IPv6 /28. This allows you 16,777,215 /48 end sites with a /48 reserved for your infrastructure. If your ISP uses an IPv4 /14, then you have a maximum of 262,144 customers with no allowance for infrastructure. For free, you can get an IPv6 /24 to support up to 268,435,455 /48 end sites after reserving a /48 for infrastructure. Sure, Matthew is going to point out that my maximum IPv4 customer numbers assume you aren?t doing CGN. That?s true. Let?s assume you get a ratio of 64 customers per address using CGN (the real numbers are more like 8-16 customers per address before stuff starts to degrade badly). 64 * 1024 = 65536 subscribers on a /22, assuming you have no infrastructure, no servers, and no customers that refuse to accept densely packed CGN. At this point, you can still hand out a /48 to every customer for all practical purposes if you have a /32 of IPv6. Yes, the ultra-tiniest of ISPs will have to pay an extra $1,500 per year for their address space. Everybody else will actually probably be able to pay less per year for address space once they can abandon IPv4, even if they give a /48 to every single end-site. Owen From matthew at matthew.at Fri Jul 10 17:01:11 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 10 Jul 2015 10:01:11 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <559F673! 5.70006 03 @matthew.at> <23291.1436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> Message-ID: <79A35ECE-AB01-4A9C-8C21-B20C3537CD30@matthew.at> > On Jul 10, 2015, at 9:52 AM, Owen DeLong wrote: > > >>> On Jul 10, 2015, at 03:57 , Matthew Kaufman wrote: >>> >>> >>> >>> On Jul 9, 2015, at 11:53 PM, Valdis.Kletnieks at vt.edu wrote: >>> >>> On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said: >>> >>>> One of the hopeful outcomes of IPv6 adoption was that an ISP could get >>>> enough to last "forever" in a single transaction. But "forever" isn't >>>> very long at one /48 (or more) per customer. >>> >>> How long does it take to blow through a /20 at /48 a customer? >> >> A while. But the more likely case is that the guy before you asked for and got a /32, because that's the minimum (and already two steps up the fee scale, I might add) >> >> You want ISPs to start with /20s? I'll support that over on PPML if you propose it. But I'll also ask for /20 to have a fee category of "small". >> >> Matthew Kaufman >> >> (Sent from my iPhone) > > According to https://www.arin.net/fees/fee_schedule.html > > ISP / ALLOCATIONS INITIAL REGISTRATION OR ANNUAL FEES > Service Category Initial Registration or Annual Fee > (US Dollars) IPv4 Block Size IPv6 Block Size > XX-Small $500 /22 or smaller /40 or smaller > X-Small $1,000 Larger than /22, up to and including /20 Larger than /40, up to and including /36 > Small $2,000 Larger than /20, up to and including /18 Larger than /36, up to and including /32 > Medium $4,000 Larger than /18, up to and including /16 Larger than /32, up to and including /28 > Large $8,000 Larger than /16, up to and including /14 Larger than /28, up to and including /24 > X-Large $16,000 Larger than /14, up to and including /12 Larger than /24, up to and including /20 > XX-Large $32,000 Larger than /12 Larger than /20 > > > If your IPv4 ISP fits in a /22 or smaller, you can hand out /48s from a /32 for a very long time. > (maximum 1024 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer > end sites after reserving a /48 for your infrastructure) > If your IPv4 ISP fits in a /20 or smaller, you can hand out /48s from a /32 for a pretty long time. > (maximum 4096 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer > end sites after reserving a /48 for your infrastructure) > If your IPv4 ISP fits in a /18 or smaller, you can hand out /48s from a /32 for quite a while. > (maximum 16,384 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer > end sites after reserving a /48 for your infrastructure). > > At IPv6 /18 or smaller, you?re in the same fee category as an IPv6 /32. > > As you go up, the situation only gets better? > > If your ISP uses an IPv4 /16, then you have a maximum of 65,536 customers with no allowance for infrastructure. > For free, you can get an IPv6 /28. This allows you 16,777,215 /48 end sites with a /48 reserved for your infrastructure. > > If your ISP uses an IPv4 /14, then you have a maximum of 262,144 customers with no allowance for infrastructure. > For free, you can get an IPv6 /24 to support up to 268,435,455 /48 end sites after reserving a /48 for infrastructure. > > Sure, Matthew is going to point out that my maximum IPv4 customer numbers assume you aren?t doing CGN. That?s true. > Let?s assume you get a ratio of 64 customers per address using CGN (the real numbers are more like 8-16 customers > per address before stuff starts to degrade badly). > > 64 * 1024 = 65536 subscribers on a /22, assuming you have no infrastructure, no servers, and no customers that > refuse to accept densely packed CGN. At this point, you can still hand out a /48 to every customer for all > practical purposes if you have a /32 of IPv6. > > Yes, the ultra-tiniest of ISPs will have to pay an extra $1,500 per year for their address space. Everybody else will > actually probably be able to pay less per year for address space once they can abandon IPv4, even if they give a /48 > to every single end-site. > > Owen > I use legacy IPv4 space and pay nothing. So IPv6 would be a big jump. Didn't even need to invoke NAT for my argument. But I'll repeat what I said before - want ISPs handing out lots of space? Make the minimum /20 or /24 instead of /32. I'll support that over on the other list if someone proposes it. Matthew Kaufman (Sent from my iPhone) From mel at beckman.org Fri Jul 10 17:35:42 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 10 Jul 2015 17:35:42 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <559F673! 5.7000603 @matthew.at> <23291.1436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at>, <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> Message-ID: This is a side issue, but I'm surprised ARIN is still advertising incorrect information in the table. A small ISP client of mine had just received their first /23 earlier this year, and I convinced them they should deploy IPv6 along with IPv4 in their new PoP. It would cost nothing, I argued, as they could request a /40 and would be in the same xx-small fee category. Money is an issue with small companies, and I was glad to see them agree. However, ARIN refused the request. Here's the dialog: ISP Requests a /40 IPv6 allocation to go along with xx-small /23 IPv4 allocation already issued. ARIN: The minimum size ARIN may allocate to an ISP is a /36, as stated by policy. https://www.arin.net/policy/nrpm.html#six52 Would you like us to proceed reviewing your request for a /36? ISP: From the Annual Fees table I read this: XX-Small $500 ipv6 /40 or smaller. Are you saying that there is no way to get an IPv6 allocation in the xx-small category? ARIN: Yes. The /36 prefix is the smallest size ARIN is permitted to allocate to ISPs according to community-created policy. https://www.arin.net/policy/nrpm.html#six52 ISP: OK thanks for the info. We are going to revisit deployment plans for IPV6 in the near future so can you cancel this IPV6 request for now? Also, ARIN might want to update its fee schedule labeled "ISP / ALLOCATIONS INITIAL REGISTRATION OR ANNUAL FEES", which specifically mentions a /40 allocation to ISPs. That's the source of our confusion on the matter. ARIN: Thank you for your response. I am closing this ticket, per your request. I have seen your feedback about the fee page, and will request it be updated to clarify the smallest block that can be allocated to an ISP. But ARIN still is advertising the /40 option months later! As a result we as a community lost the opportunity to get a new ISP off on the right foot by going dual-stacked. This is not good for IPv6 adoption. Hopefully ARIN reads this and addresses the issue - either correct the table or honor xx-small requests for a /40. -mel beckman On Jul 10, 2015, at 9:53 AM, Owen DeLong > wrote: On Jul 10, 2015, at 03:57 , Matthew Kaufman > wrote: On Jul 9, 2015, at 11:53 PM, Valdis.Kletnieks at vt.edu wrote: On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said: One of the hopeful outcomes of IPv6 adoption was that an ISP could get enough to last "forever" in a single transaction. But "forever" isn't very long at one /48 (or more) per customer. How long does it take to blow through a /20 at /48 a customer? A while. But the more likely case is that the guy before you asked for and got a /32, because that's the minimum (and already two steps up the fee scale, I might add) You want ISPs to start with /20s? I'll support that over on PPML if you propose it. But I'll also ask for /20 to have a fee category of "small". Matthew Kaufman (Sent from my iPhone) According to https://www.arin.net/fees/fee_schedule.html ISP / ALLOCATIONS INITIAL REGISTRATION OR ANNUAL FEES Service Category Initial Registration or Annual Fee (US Dollars) IPv4 Block Size IPv6 Block Size XX-Small $500 /22 or smaller /40 or smaller X-Small $1,000 Larger than /22, up to and including /20 Larger than /40, up to and including /36 Small $2,000 Larger than /20, up to and including /18 Larger than /36, up to and including /32 Medium $4,000 Larger than /18, up to and including /16 Larger than /32, up to and including /28 Large $8,000 Larger than /16, up to and including /14 Larger than /28, up to and including /24 X-Large $16,000 Larger than /14, up to and including /12 Larger than /24, up to and including /20 XX-Large $32,000 Larger than /12 Larger than /20 If your IPv4 ISP fits in a /22 or smaller, you can hand out /48s from a /32 for a very long time. (maximum 1024 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure) If your IPv4 ISP fits in a /20 or smaller, you can hand out /48s from a /32 for a pretty long time. (maximum 4096 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure) If your IPv4 ISP fits in a /18 or smaller, you can hand out /48s from a /32 for quite a while. (maximum 16,384 customer end-sites with no addresses reserved for your own infrastructure, /32 = 65535 customer end sites after reserving a /48 for your infrastructure). At IPv6 /18 or smaller, you're in the same fee category as an IPv6 /32. As you go up, the situation only gets better... If your ISP uses an IPv4 /16, then you have a maximum of 65,536 customers with no allowance for infrastructure. For free, you can get an IPv6 /28. This allows you 16,777,215 /48 end sites with a /48 reserved for your infrastructure. If your ISP uses an IPv4 /14, then you have a maximum of 262,144 customers with no allowance for infrastructure. For free, you can get an IPv6 /24 to support up to 268,435,455 /48 end sites after reserving a /48 for infrastructure. Sure, Matthew is going to point out that my maximum IPv4 customer numbers assume you aren't doing CGN. That's true. Let's assume you get a ratio of 64 customers per address using CGN (the real numbers are more like 8-16 customers per address before stuff starts to degrade badly). 64 * 1024 = 65536 subscribers on a /22, assuming you have no infrastructure, no servers, and no customers that refuse to accept densely packed CGN. At this point, you can still hand out a /48 to every customer for all practical purposes if you have a /32 of IPv6. Yes, the ultra-tiniest of ISPs will have to pay an extra $1,500 per year for their address space. Everybody else will actually probably be able to pay less per year for address space once they can abandon IPv4, even if they give a /48 to every single end-site. Owen From cscora at apnic.net Fri Jul 10 18:12:55 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Jul 2015 04:12:55 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201507101812.t6AICtR8030624@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 11 Jul, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 551197 Prefixes after maximum aggregation (per Origin AS): 208852 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 268761 Total ASes present in the Internet Routing Table: 50862 Prefixes per ASN: 10.84 Origin-only ASes present in the Internet Routing Table: 36703 Origin ASes announcing only one prefix: 16222 Transit ASes present in the Internet Routing Table: 6328 Transit-only ASes present in the Internet Routing Table: 170 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 39 Max AS path prepend of ASN ( 12486) 32 Prefixes from unregistered ASNs in the Routing Table: 1315 Unregistered ASNs in the Routing Table: 430 Number of 32-bit ASNs allocated by the RIRs: 10163 Number of 32-bit ASNs visible in the Routing Table: 7831 Prefixes from 32-bit ASNs in the Routing Table: 28944 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 504 Number of addresses announced to Internet: 2766799648 Equivalent to 164 /8s, 234 /16s and 3 /24s Percentage of available address space announced: 74.7 Percentage of allocated address space announced: 74.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.4 Total number of prefixes smaller than registry allocations: 184446 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 136179 Total APNIC prefixes after maximum aggregation: 39528 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 143088 Unique aggregates announced from the APNIC address blocks: 58021 APNIC Region origin ASes present in the Internet Routing Table: 5059 APNIC Prefixes per ASN: 28.28 APNIC Region origin ASes announcing only one prefix: 1195 APNIC Region transit ASes present in the Internet Routing Table: 875 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1542 Number of APNIC addresses announced to Internet: 750827456 Equivalent to 44 /8s, 192 /16s and 183 /24s Percentage of available APNIC address space announced: 87.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179662 Total ARIN prefixes after maximum aggregation: 88217 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182213 Unique aggregates announced from the ARIN address blocks: 85011 ARIN Region origin ASes present in the Internet Routing Table: 16616 ARIN Prefixes per ASN: 10.97 ARIN Region origin ASes announcing only one prefix: 6112 ARIN Region transit ASes present in the Internet Routing Table: 1743 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 534 Number of ARIN addresses announced to Internet: 1082901024 Equivalent to 64 /8s, 139 /16s and 194 /24s Percentage of available ARIN address space announced: 57.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 133748 Total RIPE prefixes after maximum aggregation: 66563 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 140411 Unique aggregates announced from the RIPE address blocks: 86940 RIPE Region origin ASes present in the Internet Routing Table: 17974 RIPE Prefixes per ASN: 7.81 RIPE Region origin ASes announcing only one prefix: 8110 RIPE Region transit ASes present in the Internet Routing Table: 2968 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3843 Number of RIPE addresses announced to Internet: 697952256 Equivalent to 41 /8s, 153 /16s and 232 /24s Percentage of available RIPE address space announced: 101.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 60282 Total LACNIC prefixes after maximum aggregation: 11422 LACNIC Deaggregation factor: 5.28 Prefixes being announced from the LACNIC address blocks: 71030 Unique aggregates announced from the LACNIC address blocks: 33156 LACNIC Region origin ASes present in the Internet Routing Table: 2445 LACNIC Prefixes per ASN: 29.05 LACNIC Region origin ASes announcing only one prefix: 610 LACNIC Region transit ASes present in the Internet Routing Table: 509 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1782 Number of LACNIC addresses announced to Internet: 168556608 Equivalent to 10 /8s, 11 /16s and 248 /24s Percentage of available LACNIC address space announced: 100.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12121 Total AfriNIC prefixes after maximum aggregation: 3073 AfriNIC Deaggregation factor: 3.94 Prefixes being announced from the AfriNIC address blocks: 13951 Unique aggregates announced from the AfriNIC address blocks: 5235 AfriNIC Region origin ASes present in the Internet Routing Table: 734 AfriNIC Prefixes per ASN: 19.01 AfriNIC Region origin ASes announcing only one prefix: 195 AfriNIC Region transit ASes present in the Internet Routing Table: 162 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 130 Number of AfriNIC addresses announced to Internet: 65769984 Equivalent to 3 /8s, 235 /16s and 146 /24s Percentage of available AfriNIC address space announced: 65.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2947 11304 938 Korea Telecom 17974 2699 904 78 PT Telekomunikasi Indonesia 7545 2634 339 135 TPG Telecom Limited 4538 2022 4190 71 China Education and Research 4755 2016 423 221 TATA Communications formerly 9829 1801 1361 143 National Internet Backbone 9808 1557 8717 28 Guangdong Mobile Communicatio 9583 1515 119 573 Sify Limited 4808 1462 2241 470 CNCGROUP IP network China169 9498 1359 335 107 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3179 2957 136 Cox Communications Inc. 6389 2758 3688 51 BellSouth.net Inc. 3356 2579 10702 511 Level 3 Communications, Inc. 18566 2059 380 198 MegaPath Corporation 20115 1866 1838 406 Charter Communications 6983 1751 850 244 EarthLink, Inc. 4323 1609 1022 412 tw telecom holdings, inc. 30036 1570 320 433 Mediacom Communications Corp 701 1392 11371 676 MCI Communications Services, 22561 1382 415 257 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 2206 305 366 TELLCOM ILETISIM HIZMETLERI A 20940 2030 796 1472 Akamai International B.V. 6849 1209 355 21 JSC "Ukrtelecom" 8551 1104 376 52 Bezeq International-Ltd 8402 1052 544 15 OJSC "Vimpelcom" 31148 1051 46 24 Freenet Ltd. 13188 1041 97 75 TOV "Bank-Inform" 12479 958 933 77 France Telecom Espana SA 6830 913 2694 469 Liberty Global Operations B.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3288 536 197 Telmex Colombia S.A. 28573 2279 2170 113 NET Servi?os de Comunica??o S 8151 1698 3271 477 Uninet S.A. de C.V. 7303 1631 1008 238 Telecom Argentina S.A. 6147 1386 374 30 Telefonica del Peru S.A.A. 6503 1268 421 55 Axtel, S.A.B. de C.V. 26615 1102 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 951 428 161 COLOMBIA TELECOMUNICACIONES S 11830 892 364 15 Instituto Costarricense de El Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 876 280 26 Link Egypt (Link.NET) 8452 835 958 13 TE-AS 36903 512 258 99 Office National des Postes et 36992 439 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 307 146 12 Vodafone Data 3741 250 857 208 Internet Solutions 29571 249 21 13 Cote d'Ivoire Telecom 36947 192 807 13 Telecom Algeria 15706 174 32 6 Sudatel (Sudan Telecom Co. Lt Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3288 536 197 Telmex Colombia S.A. 22773 3179 2957 136 Cox Communications Inc. 4766 2947 11304 938 Korea Telecom 6389 2758 3688 51 BellSouth.net Inc. 17974 2699 904 78 PT Telekomunikasi Indonesia 7545 2634 339 135 TPG Telecom Limited 3356 2579 10702 511 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2279 2170 113 NET Servi?os de Comunica??o S 34984 2206 305 366 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3179 3043 Cox Communications Inc. 6389 2758 2707 BellSouth.net Inc. 17974 2699 2621 PT Telekomunikasi Indonesia 7545 2634 2499 TPG Telecom Limited 39891 2472 2466 SaudiNet, Saudi Telecom Compa 28573 2279 2166 NET Servi?os de Comunica??o S 3356 2579 2068 Level 3 Communications, Inc. 4766 2947 2009 Korea Telecom 4538 2022 1951 China Education and Research 18566 2059 1861 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:95 /12:260 /13:504 /14:1001 /15:1730 /16:12886 /17:7277 /18:12377 /19:25606 /20:36004 /21:38758 /22:60453 /23:52463 /24:298703 /25:1104 /26:1152 /27:709 /28:14 /29:12 /30:7 /31:0 /32:17 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2382 3179 Cox Communications Inc. 18566 2005 2059 MegaPath Corporation 6389 1629 2758 BellSouth.net Inc. 34984 1464 2206 TELLCOM ILETISIM HIZMETLERI A 6983 1398 1751 EarthLink, Inc. 30036 1392 1570 Mediacom Communications Corp 10620 1158 3288 Telmex Colombia S.A. 11492 1114 1198 CABLE ONE, INC. 22561 1055 1382 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1502 2:686 4:93 5:1875 6:25 8:1382 11:1 12:1820 13:14 14:1382 15:17 16:2 17:45 18:22 20:48 23:1252 24:1760 27:1972 31:1612 32:38 33:2 34:4 35:3 36:143 37:1961 38:1034 39:5 40:72 41:2717 42:295 43:1367 44:28 45:779 46:2300 47:45 49:889 50:787 52:12 54:79 55:3 56:6 57:42 58:1331 59:723 60:481 61:1752 62:1361 63:1901 64:4428 65:2259 66:4032 67:2054 68:1075 69:3253 70:1022 71:444 72:1966 74:2640 75:340 76:399 77:1274 78:1193 79:809 80:1354 81:1311 82:846 83:728 84:783 85:1381 86:437 87:1064 88:533 89:1899 90:144 91:6011 92:837 93:2243 94:2077 95:2209 96:434 97:348 98:1053 99:53 100:72 101:845 103:7784 104:1868 105:63 106:264 107:1006 108:628 109:2067 110:1146 111:1447 112:837 113:1103 114:840 115:1253 116:1409 117:1065 118:1869 119:1452 120:454 121:1084 122:2123 123:1844 124:1522 125:1624 128:653 129:391 130:410 131:1197 132:513 133:171 134:405 135:94 136:334 137:315 138:959 139:152 140:237 141:449 142:668 143:502 144:546 145:123 146:744 147:583 148:1215 149:416 150:555 151:652 152:520 153:249 154:464 155:877 156:436 157:419 158:353 159:1002 160:398 161:656 162:1957 163:437 164:692 165:698 166:307 167:833 168:1275 169:183 170:1467 171:245 172:284 173:1544 174:720 175:687 176:1445 177:3811 178:2165 179:945 180:1935 181:1576 182:1830 183:628 184:761 185:3837 186:2805 187:1760 188:2059 189:1614 190:7704 191:1024 192:8473 193:5633 194:4214 195:3697 196:1992 197:986 198:5529 199:5486 200:6598 201:3250 202:9536 203:9129 204:4712 205:2848 206:3037 207:2970 208:3985 209:3937 210:3592 211:1897 212:2580 213:2300 214:851 215:73 216:5746 217:1818 218:714 219:467 220:1453 221:792 222:461 223:789 End of report From mailings at meanie.nl Fri Jul 10 18:31:27 2015 From: mailings at meanie.nl (Paul Hoogsteder) Date: Fri, 10 Jul 2015 20:31:27 +0200 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <559EECFC.9050407@foobar.org> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <559EECFC.9050407@foobar.org> Message-ID: <55A00F7F.9060801@meanie.nl> On 09-07-15 23:51, Nick Hilliard wrote: > On 09/07/2015 22:35, Ricky Beam wrote: >> "Free" if you have a support contract. > No, free-as-in-beer. > > You register a guest CCO account, email tac at cisco.com, provide the device > serial number (or output of "show hardware") and the bugid + Cisco PSIRT > URL reference. Cisco TAC will then provide you with a download link with > fixed software, at no cost to you. It's not a pain in the ass - it works fine. > > Nick > > And while that's the general procedure for almost all Cisco products, there is even an faster way for the ASA: - register a CCO account - in ASDM choose Tools > Check for ASA/ASDM Updates - follow the onscreen instructions Paul. From jcurran at arin.net Fri Jul 10 19:50:37 2015 From: jcurran at arin.net (John Curran) Date: Fri, 10 Jul 2015 19:50:37 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <23291.1436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> Message-ID: On Jul 10, 2015, at 1:35 PM, Mel Beckman > wrote: This is a side issue, but I'm surprised ARIN is still advertising incorrect information in the table. ... Are you saying that there is no way to get an IPv6 allocation in the xx-small category? ARIN: Yes. The /36 prefix is the smallest size ARIN is permitted to allocate to ISPs according to community-created policy. https://www.arin.net/policy/nrpm.html#six52 ... But ARIN still is advertising the /40 option months later! As a result we as a community lost the opportunity to get a new ISP off on the right foot by going dual-stacked. This is not good for IPv6 adoption. Hopefully ARIN reads this and addresses the issue - either correct the table or honor xx-small requests for a /40. Mel - The confusion is very understandable, but both the fee table and the policy are accurate. The fee table includes an XX-Small category which corresponds to those ISPs which have smaller than /20 IPv4 and smaller than a /36 IPv6 total holdings ? the fact that such a category exists does not mean that any particular ISP is being billed in that category (or that a new ISP will necessarily end up in that category); it simply means that ISPs with those total resources are billed accordingly. The constraint that you experienced, i.e. that there is a minimum IPv6 ISP allocation size of /36 is actually not something that the staff can fix; i.e. it?s the result of the community-led policy development process, and if you feel it does need to change to a lower number, you should propose an appropriate change to policy on the ARIN public policy mailing list >. We _are_ in the midst of considering changes to the fee table to lower and realign the IPv6 fees in general (which might be a better solution if the cost is issue) - see for the update provided in April at the ARIN 35 Members meeting, with specific options for community discussion at the ARIN Fall meeting taking place in Montreal this October (adjacent to the NANOG Fall meeting) Thanks! /John John Curran President and CEO ARIN From edtardist at gmail.com Fri Jul 10 19:56:50 2015 From: edtardist at gmail.com (Eddie Tardist) Date: Fri, 10 Jul 2015 16:56:50 -0300 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: <55A00F7F.9060801@meanie.nl> References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <559EECFC.9050407@foobar.org> <55A00F7F.9060801@meanie.nl> Message-ID: On Fri, Jul 10, 2015 at 3:31 PM, Paul Hoogsteder wrote: > On 09-07-15 23:51, Nick Hilliard wrote: > >> On 09/07/2015 22:35, Ricky Beam wrote: >> >>> "Free" if you have a support contract. >>> >> No, free-as-in-beer. >> >> You register a guest CCO account, email tac at cisco.com, provide the device >> serial number (or output of "show hardware") and the bugid + Cisco PSIRT >> URL reference. Cisco TAC will then provide you with a download link with >> fixed software, at no cost to you. It's not a pain in the ass - it works >> fine. >> >> Nick >> >> >> And while that's the general procedure for almost all Cisco products, > there is even an faster way for the ASA: > > - register a CCO account > - in ASDM choose Tools > Check for ASA/ASDM Updates > - follow the onscreen instructions > > Paul. Hello Gentlemen, I had a crashing ASA 5585-S40 yesterday and it is still crashing today. Box is up to date, I have similar setups on LAX and on east coast and I only see the problem on west coast on circuits connected to Level3 traffic. I have a couple tickets still open with Cisco staff. They have added some dataplane protection which minimized the instability, but I dont know if it's a coincidence or effective, since it's not that often but 5585-S40 boxes are still crashing. If anyone got any update on what's going on please share. I have replaced one critical box with a Juniper one but I can't do it for all my sites promptly so. So far what I found is that it's related to protocol 132 (sctp?). I have tried to filter 132 but no success. I can't just filter source address since it's legit, and proto 132 filtered traffic stills reaching the box up the point it leads to the problem (if in fact it's sctp related). It looks like I'm back to 90's since it seems like a single packet attack. I can't see volumetric deviations, I can't see unusual patterns, proto 132 starts showing up and nothing goes wrong, suddenly I get the crash, no matter if it's been a couple minutes with some proto 132 traffic or if the traffic just started this second... the only "coincidence" is proto 132 popping up without any further specific pattern. Weird and keeps happening. From mel at beckman.org Fri Jul 10 20:06:03 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 10 Jul 2015 20:06:03 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <23291.1436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> , Message-ID: John, Thanks for the clarification. I'm happy to abide by the original community decision, but I think it's important that the table be clarified, especially given that the ARIN specialist I worked with agreed that it needs clarification. It's like going to a Starbucks as a homeless person with just pocket change, and ordering the cheapest coffee on the menu, and being told "Oh, that's for off-planet visitors only. It says so on our website under "Terms and Conditions." Can I interest you in this giga-latte at only four times the price?" A simple asterisk, followed by "Not available to residents of Earth", would prevent the confusion, and resulting social awkwardness. [?] -mel ________________________________ From: John Curran Sent: Friday, July 10, 2015 12:50 PM To: Mel Beckman Cc: nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion On Jul 10, 2015, at 1:35 PM, Mel Beckman > wrote: This is a side issue, but I'm surprised ARIN is still advertising incorrect information in the table. ... Are you saying that there is no way to get an IPv6 allocation in the xx-small category? ARIN: Yes. The /36 prefix is the smallest size ARIN is permitted to allocate to ISPs according to community-created policy. https://www.arin.net/policy/nrpm.html#six52 ... But ARIN still is advertising the /40 option months later! As a result we as a community lost the opportunity to get a new ISP off on the right foot by going dual-stacked. This is not good for IPv6 adoption. Hopefully ARIN reads this and addresses the issue - either correct the table or honor xx-small requests for a /40. Mel - The confusion is very understandable, but both the fee table and the policy are accurate. The fee table includes an XX-Small category which corresponds to those ISPs which have smaller than /20 IPv4 and smaller than a /36 IPv6 total holdings ? the fact that such a category exists does not mean that any particular ISP is being billed in that category (or that a new ISP will necessarily end up in that category); it simply means that ISPs with those total resources are billed accordingly. The constraint that you experienced, i.e. that there is a minimum IPv6 ISP allocation size of /36 is actually not something that the staff can fix; i.e. it?s the result of the community-led policy development process, and if you feel it does need to change to a lower number, you should propose an appropriate change to policy on the ARIN public policy mailing list >. We _are_ in the midst of considering changes to the fee table to lower and realign the IPv6 fees in general (which might be a better solution if the cost is issue) - see for the update provided in April at the ARIN 35 Members meeting, with specific options for community discussion at the ARIN Fall meeting taking place in Montreal this October (adjacent to the NANOG Fall meeting) Thanks! /John John Curran President and CEO ARIN From sotnickd-nanog at ddv.com Fri Jul 10 20:08:08 2015 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Fri, 10 Jul 2015 13:08:08 -0700 Subject: Joker.com contact / GLUE help Message-ID: Hi NANOG, Does anyone have any technical contacts at Joker.com? I am going in circles with their support folks trying to update the GLUE records for two of my nameservers and keep running into permissions issues despite the glue records clearly being part of my domain. I need to speak to someone who actually understands what DNS Glue records are, and how to go about updating them. I feel like the joke is on me for choosing Joker.com as their support has been laughable thus far. TIA, David From jcurran at arin.net Fri Jul 10 21:19:17 2015 From: jcurran at arin.net (John Curran) Date: Fri, 10 Jul 2015 21:19:17 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <23291.1436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> Message-ID: <2E7E4335-D8CB-4D3E-8709-372E70C98005@arin.net> On Jul 10, 2015, at 4:06 PM, Mel Beckman > wrote: John, Thanks for the clarification. I'm happy to abide by the original community decision, but I think it's important that the table be clarified, especially given that the ARIN specialist I worked with agreed that it needs clarification. It's like going to a Starbucks as a homeless person with just pocket change, and ordering the cheapest coffee on the menu, and being told "Oh, that's for off-planet visitors only. It says so on our website under "Terms and Conditions." Can I interest you in this giga-latte at only four times the price?" A simple asterisk, followed by "Not available to residents of Earth", would prevent the confusion, and resulting social awkwardness. We made note of the IPv6 policy minimum of /36 in the linked FAQ that accompanies the Fee Table, but I?ll admit it could be clearer (particularly for those obtaining number resources for the first time.) We?ll do an update after the October meeting reflecting the final outcome with respect to the fee table, and will address at that time. Thanks! /John John Curran President and CEO ARIN From marka at isc.org Fri Jul 10 21:41:53 2015 From: marka at isc.org (Mark Andrews) Date: Sat, 11 Jul 2015 07:41:53 +1000 Subject: Hotels/Airports with IPv6 In-Reply-To: Your message of "Fri, 10 Jul 2015 11:54:00 -0400." References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: <20150710214153.3A3DA32B42B9@rock.dv.isc.org> In message , Christopher Morrow writes: > On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: > > I working on a large airport WiFi deployment right now. IPv6 is "allowed = > for in the future" but not configured in the short term. With less than 10,= > 000 ephemeral users, we don't expect users to demand IPv6 until most mobile= > devices and apps come ready to use IPv6 by default. > > > > 'we don't expect users to demand ipv6' > > aside from #nanog folks, who 'demands' ipv6? > > Don't they actually 'demand' "access to content on the internet" ? > > Since you seem to have a greenfield deployment, why NOT just put v6 in > place on day0? retrofitting it is surely going to cost time/materials > and probably upgrades to gear that could be avoided by doing it in the > initial installation, right? +1 and you will most probably see about 50% of the traffic being IPv6 if you do so. There is lots of IPv6 capable equipment out there just waiting to see a RA. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mel at beckman.org Fri Jul 10 21:50:56 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 10 Jul 2015 21:50:56 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <20150710214153.3A3DA32B42B9@rock.dv.isc.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> , <20150710214153.3A3DA32B42B9@rock.dv.isc.org> Message-ID: Limited municipal budgets is all I can say. IPv6 has a cost, and if they can put it off till later then that's often good politics. -mel via cell > On Jul 10, 2015, at 2:42 PM, Mark Andrews wrote: > > > In message > , Christopher Morrow writes: >>> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: >>> I working on a large airport WiFi deployment right now. IPv6 is "allowed = >> for in the future" but not configured in the short term. With less than 10,= >> 000 ephemeral users, we don't expect users to demand IPv6 until most mobile= >> devices and apps come ready to use IPv6 by default. >> >> 'we don't expect users to demand ipv6' >> >> aside from #nanog folks, who 'demands' ipv6? >> >> Don't they actually 'demand' "access to content on the internet" ? >> >> Since you seem to have a greenfield deployment, why NOT just put v6 in >> place on day0? retrofitting it is surely going to cost time/materials >> and probably upgrades to gear that could be avoided by doing it in the >> initial installation, right? > > +1 and you will most probably see about 50% of the traffic being IPv6 if > you do so. There is lots of IPv6 capable equipment out there just waiting > to see a RA. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.Nether.net Fri Jul 10 21:56:58 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 10 Jul 2015 17:56:58 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: <20150710214153.3A3DA32B42B9@rock.dv.isc.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> Message-ID: <20150710215658.GC23237@puck.nether.net> On Sat, Jul 11, 2015 at 07:41:53AM +1000, Mark Andrews wrote: > +1 and you will most probably see about 50% of the traffic being IPv6 if > you do so. There is lots of IPv6 capable equipment out there just waiting > to see a RA. What I noticed when I ran a transparent HTTP proxy at my gateway where it had IPv6 on the outside but the hosts inside did not, a lot of traffic was converted from IPv4 to IPv6 on the exterior. As the internet has been moving to HTTPS/HSTS having DHCP and client-side support of something like draft-wkumari-dhc-capport is going to become more critical as the days go by. While attempting to trigger the captive portal at RDU this week, Boingo redirected a query for google to their HTTPS to the portal and since HSTS was enabled I had no way to proceed from there to the right location to authenticate. There was also some other broken stuff at RDU so I ended up just using cellular data. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From cidr-report at potaroo.net Fri Jul 10 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Jul 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201507102200.t6AM00r1054779@wattle.apnic.net> This report has been generated at Fri Jul 10 21:14:43 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-07-15 558842 305658 04-07-15 559475 305396 05-07-15 559019 305621 06-07-15 559208 305624 07-07-15 559433 306348 08-07-15 560044 306193 09-07-15 560059 306043 10-07-15 560303 305962 AS Summary 51125 Number of ASes in routing system 20307 Number of ASes announcing only one prefix 3288 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120761600 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 10Jul15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 560443 305950 254493 45.4% All ASes AS22773 3182 166 3016 94.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2758 71 2687 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2699 78 2621 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS9394 2919 315 2604 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS39891 2473 33 2440 98.7% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2279 119 2160 94.8% NET Servi?os de Comunica??o S.A.,BR AS3356 2584 777 1807 69.9% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2947 1232 1715 58.2% KIXS-AS-KR Korea Telecom,KR AS10620 3288 1585 1703 51.8% Telmex Colombia S.A.,CO AS7545 2684 1180 1504 56.0% TPG-INTERNET-AP TPG Telecom Limited,AU AS6983 1750 247 1503 85.9% ITCDELTA - Earthlink, Inc.,US AS9808 1557 65 1492 95.8% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS20115 1866 480 1386 74.3% CHARTER-NET-HKY-NC - Charter Communications,US AS4755 2015 702 1313 65.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS9498 1359 121 1238 91.1% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1616 415 1201 74.3% TWTC - tw telecom holdings, inc.,US AS18566 2060 909 1151 55.9% MEGAPATH5-US - MegaPath Corporation,US AS6147 1390 277 1113 80.1% Telefonica del Peru S.A.A.,PE AS7552 1140 59 1081 94.8% VIETEL-AS-AP Viettel Corporation,VN AS22561 1382 324 1058 76.6% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7303 1631 579 1052 64.5% Telecom Argentina S.A.,AR AS8402 1052 23 1029 97.8% CORBINA-AS OJSC "Vimpelcom",RU AS4808 1513 508 1005 66.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS6849 1206 216 990 82.1% UKRTELNET JSC UKRTELECOM,UA AS8151 1700 736 964 56.7% Uninet S.A. de C.V.,MX AS26615 1101 180 921 83.7% Tim Celular S.A.,BR AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 980 128 852 86.9% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 2040 1191 849 41.6% ERX-CERNET-BKB China Education and Research Network Center,CN AS4780 1126 290 836 74.2% SEEDNET Digital United Inc.,TW Total 57296 13089 44207 77.2% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.126.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 43.229.164.0/22 AS18126 CTCX Chubu Telecommunications Company, Inc.,JP 64.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.57.192.0/22 AS33321 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.228.160.0/20 AS7233 YAHOO-US - Yahoo,US 66.228.176.0/21 AS17110 YAHOO-US2 - Yahoo,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 69.24.96.0/20 AS26804 -Reserved AS-,ZZ 72.10.64.0/19 AS19158 -Reserved AS-,ZZ 72.10.66.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 72.10.67.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 72.10.68.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 72.10.69.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 72.10.78.0/23 AS39374 PROGRESSIVETEL - Progressive Rural Telephone Coopreative, Inc,US 72.10.84.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 72.10.86.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 72.10.87.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 72.10.88.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 72.10.89.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 72.10.90.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.229.5.0/24 AS56923 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.11.160.0/24 AS13216 , 103.11.161.0/24 AS13216 , 103.11.162.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.11.163.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.25.144.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.27.212.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.37.188.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.38.152.0/24 AS1828 UNITAS - Unitas Global LLC,US 103.38.154.0/24 AS1828 UNITAS - Unitas Global LLC,US 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.227.4.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.228.8.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.228.84.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.228.224.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.229.152.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.230.124.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.104.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.234.44.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 116.199.200.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.201.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.202.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.203.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.204.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.205.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.206.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.207.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 140.81.0.0/16 AS20053 RELAX-LLC-AS LLC Relax,RU 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 144.1.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 169.239.24.0/22 AS30969 ZOL-AS Zimbabwe OnLine (Private) Ltd.,GB 170.95.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 179.60.128.0/20 AS26317 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 182.236.116.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 182.236.117.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 182.236.118.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 182.236.119.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.40.183.0/24 AS62300 -Reserved AS-,ZZ 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 188.190.103.0/24 AS19714 -Reserved AS-,ZZ 188.190.112.0/24 AS19714 -Reserved AS-,ZZ 188.190.113.0/24 AS19714 -Reserved AS-,ZZ 188.190.114.0/24 AS19714 -Reserved AS-,ZZ 188.190.118.0/24 AS19714 -Reserved AS-,ZZ 188.190.119.0/24 AS19714 -Reserved AS-,ZZ 188.190.120.0/24 AS19714 -Reserved AS-,ZZ 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.175.14.0/23 AS30479 NCSERV-COM - NCServ, LLC.,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.105.154.0/24 AS34023 -Reserved AS-,ZZ 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.9.9.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd.,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.103.89.0/24 AS19523 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.59.208.0/20 AS26317 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 201.182.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.133.208.0/20 AS17440 IDNIC-ID Indonesia Network Information Center,ID 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.160.128.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.103.0.0/16 AS46800 INFOLOGCORP - Information Logistics, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.71.0.0/17 AS46800 INFOLOGCORP - Information Logistics, Inc,US 209.71.37.0/24 AS46946 AEHN-AS - AEHN,US 209.71.38.0/24 AS46946 AEHN-AS - AEHN,US 209.71.39.0/24 AS46946 AEHN-AS - AEHN,US 209.71.40.0/24 AS46946 AEHN-AS - AEHN,US 209.82.160.0/19 AS19158 -Reserved AS-,ZZ 209.82.162.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.82.163.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 209.82.164.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 209.82.166.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.82.167.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.82.173.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 209.82.174.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.82.176.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 209.82.179.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.82.180.0/22 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.82.186.0/23 AS39374 PROGRESSIVETEL - Progressive Rural Telephone Coopreative, Inc,US 209.82.188.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.82.189.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.221.32.0/19 AS19158 -Reserved AS-,ZZ 209.221.32.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.221.33.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.221.34.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.221.35.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.221.36.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.221.37.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 209.221.41.0/24 AS39374 PROGRESSIVETEL - Progressive Rural Telephone Coopreative, Inc,US 209.221.43.0/24 AS39374 PROGRESSIVETEL - Progressive Rural Telephone Coopreative, Inc,US 209.221.45.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 209.221.46.0/24 AS39374 PROGRESSIVETEL - Progressive Rural Telephone Coopreative, Inc,US 209.221.48.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.221.50.0/24 AS39374 PROGRESSIVETEL - Progressive Rural Telephone Coopreative, Inc,US 209.221.54.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 209.221.55.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 209.221.56.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 209.221.57.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 209.221.62.0/23 AS19158 -Reserved AS-,ZZ 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.119.0.0/18 AS19158 -Reserved AS-,ZZ 216.119.0.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 216.119.18.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.19.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.20.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.21.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.22.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.25.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 216.119.26.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 216.119.27.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.28.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.29.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.40.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.41.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.43.0/24 AS39374 PROGRESSIVETEL - Progressive Rural Telephone Coopreative, Inc,US 216.119.46.0/23 AS39374 PROGRESSIVETEL - Progressive Rural Telephone Coopreative, Inc,US 216.119.50.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 216.119.53.0/24 AS15313 PMTL-AS1 - Pembroke Telephone Company, Inc.,US 216.119.55.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.56.0/23 AS39374 PROGRESSIVETEL - Progressive Rural Telephone Coopreative, Inc,US 216.119.58.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.59.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.60.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.119.61.0/24 AS19955 PINELAND-TELEPHONE - Pineland Telephone Cooperative, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 10 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Jul 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201507102200.t6AM02GU054797@wattle.apnic.net> BGP Update Report Interval: 02-Jul-15 -to- 09-Jul-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 220585 5.2% 195.7 -- BSNL-NIB National Internet Backbone,IN 2 - AS23752 203734 4.8% 1434.7 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS14287 149886 3.5% 29977.2 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 4 - AS36947 84544 2.0% 583.1 -- ALGTEL-AS,DZ 5 - AS22773 84077 2.0% 477.7 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 6 - AS54169 70867 1.7% 70867.0 -- MGH-ION-1 - Marin General Hospital,US 7 - AS25438 66939 1.6% 631.5 -- ASN-ICCNET International Computer Company, Ltd.,SA 8 - AS3709 60234 1.4% 2230.9 -- NET-CITY-SA - City of San Antonio,US 9 - AS3316 57914 1.4% 1565.2 -- RELARN Association of scientific and educational organizations-computer networks users "RELARN",RU 10 - AS24699 53074 1.2% 1360.9 -- IVTELECOM-AS OJSC Rostelecom,RU 11 - AS39891 48013 1.1% 38.2 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 12 - AS22059 42261 1.0% 21130.5 -- -Reserved AS-,ZZ 13 - AS13036 39622 0.9% 2476.4 -- TMOBILE-CZ T-Mobile Czech Republic a.s.,CZ 14 - AS25563 36080 0.8% 12026.7 -- WEBLAND-AS Webland AG,CH 15 - AS21669 33901 0.8% 33901.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 16 - AS59943 28826 0.7% 28826.0 -- RADAR-AS Radar LLC,RU 17 - AS263652 25971 0.6% 1527.7 -- CMDNET Internet & Inform?tica Ltda,BR 18 - AS26972 24535 0.6% 1363.1 -- SIRIUS-FIBER - Sirius Fiber, Inc.,US 19 - AS7122 23457 0.6% 32.8 -- MTS-ASN - MTS Allstream Inc.,CA 20 - AS10620 21803 0.5% 12.0 -- Telmex Colombia S.A.,CO TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54169 70867 1.7% 70867.0 -- MGH-ION-1 - Marin General Hospital,US 2 - AS21669 33901 0.8% 33901.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 3 - AS14287 149886 3.5% 29977.2 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 4 - AS59943 28826 0.7% 28826.0 -- RADAR-AS Radar LLC,RU 5 - AS22059 42261 1.0% 21130.5 -- -Reserved AS-,ZZ 6 - AS25563 36080 0.8% 12026.7 -- WEBLAND-AS Webland AG,CH 7 - AS14244 11388 0.3% 11388.0 -- NSIHOSTING-EQX-VA - NSI Hosting,US 8 - AS393588 9603 0.2% 9603.0 -- MUBEA-FLO - Mubea,US 9 - AS40637 9002 0.2% 9002.0 -- MAILROUTE - MailRoute, Inc.,US 10 - AS47680 7133 0.2% 7133.0 -- NHCS EOBO Limited,IE 11 - AS197914 6889 0.2% 6889.0 -- STOCKHO-AS Stockho Hosting SARL,FR 12 - AS29528 6094 0.1% 6094.0 -- ERC-AS ERC - Financial Logistics Ltd.,RU 13 - AS40493 5901 0.1% 5901.0 -- FACILITYSOURCEINC - FacilitySource,US 14 - AS11056 5406 0.1% 5406.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US 15 - AS33659 18455 0.4% 4613.8 -- CMCS - Comcast Cable Communications, Inc.,US 16 - AS7349 13020 0.3% 4340.0 -- WINDSTEAM-HOSTED-SOLUTIONS-1 - Windstream Hosted Solutions, LLC,US 17 - AS33287 12702 0.3% 4234.0 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US 18 - AS6316 6731 0.2% 3365.5 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 19 - AS13036 39622 0.9% 2476.4 -- TMOBILE-CZ T-Mobile Czech Republic a.s.,CZ 20 - AS10013 2474 0.1% 2474.0 -- FBDC FreeBit Co.,Ltd.,JP TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 100045 2.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 99723 2.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 105.96.0.0/22 79141 1.8% AS36947 -- ALGTEL-AS,DZ 4 - 204.80.242.0/24 70867 1.6% AS54169 -- MGH-ION-1 - Marin General Hospital,US 5 - 209.212.8.0/24 33901 0.8% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 6 - 199.204.107.0/24 31142 0.7% AS33287 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US AS33659 -- CMCS - Comcast Cable Communications, Inc.,US 7 - 208.88.232.0/22 29978 0.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 8 - 208.78.116.0/22 29978 0.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 9 - 208.73.244.0/22 29978 0.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 10 - 216.162.0.0/20 29978 0.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 11 - 208.70.20.0/22 29974 0.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 12 - 185.65.148.0/24 28826 0.7% AS59943 -- RADAR-AS Radar LLC,RU 13 - 64.34.125.0/24 21515 0.5% AS22059 -- -Reserved AS-,ZZ 14 - 76.191.107.0/24 20746 0.5% AS22059 -- -Reserved AS-,ZZ 15 - 130.44.210.0/24 14296 0.3% AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 16 - 130.44.194.0/24 13862 0.3% AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 17 - 130.44.10.0/24 13841 0.3% AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 18 - 130.44.192.0/24 13815 0.3% AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 19 - 130.44.204.0/24 13773 0.3% AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 20 - 130.44.1.0/24 13773 0.3% AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From marka at isc.org Fri Jul 10 22:02:58 2015 From: marka at isc.org (Mark Andrews) Date: Sat, 11 Jul 2015 08:02:58 +1000 Subject: Hotels/Airports with IPv6 In-Reply-To: Your message of "Fri, 10 Jul 2015 21:50:56 +0000." References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> , <20150710214153.3A3DA32B42B9@rock.dv.isc.org> Message-ID: <20150710220258.622AD32B47BD@rock.dv.isc.org> In message , Mel Beckman writ es: > Limited municipal budgets is all I can say. IPv6 has a cost, and if they > can put it off till later then that's often good politics. > > -mel via cell IPv4 has a cost as well. May as well just go IPv6-only from day one and not pay the IPv4 tax at all. The cost difference between providing IPv6 + IPv4 or just IPv4 from day 1 should be zero. There should be no re-tooling. You just select products that support both initially. It's not like products that support both are more expensive all other things being equal. Mark > > On Jul 10, 2015, at 2:42 PM, Mark Andrews wrote: > > > > > > In message > > > , Christopher Morrow writes: > >>> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: > >>> I working on a large airport WiFi deployment right now. IPv6 is > "allowed = > >> for in the future" but not configured in the short term. With less > than 10,= > >> 000 ephemeral users, we don't expect users to demand IPv6 until most > mobile= > >> devices and apps come ready to use IPv6 by default. > >> > >> 'we don't expect users to demand ipv6' > >> > >> aside from #nanog folks, who 'demands' ipv6? > >> > >> Don't they actually 'demand' "access to content on the internet" ? > >> > >> Since you seem to have a greenfield deployment, why NOT just put v6 in > >> place on day0? retrofitting it is surely going to cost time/materials > >> and probably upgrades to gear that could be avoided by doing it in the > >> initial installation, right? > > > > +1 and you will most probably see about 50% of the traffic being IPv6 if > > you do so. There is lots of IPv6 capable equipment out there just > waiting > > to see a RA. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mel at beckman.org Fri Jul 10 22:08:15 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 10 Jul 2015 22:08:15 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <20150710220258.622AD32B47BD@rock.dv.isc.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> , <20150710214153.3A3DA32B42B9@rock.dv.isc.org> , <20150710220258.622AD32B47BD@rock.dv.isc.org> Message-ID: There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth the cost, which would have been just a small fraction of the total. The powers that be chose not to incur it now. But we did deploy only IPv6 gear and systems, so it can probably be turned up later for that same incremental cost. -mel via cell > On Jul 10, 2015, at 3:03 PM, Mark Andrews wrote: > > > In message , Mel Beckman writ > es: >> Limited municipal budgets is all I can say. IPv6 has a cost, and if they >> can put it off till later then that's often good politics. >> >> -mel via cell > > IPv4 has a cost as well. May as well just go IPv6-only from day one and > not pay the IPv4 tax at all. > > The cost difference between providing IPv6 + IPv4 or just IPv4 from > day 1 should be zero. There should be no re-tooling. You just > select products that support both initially. It's not like products > that support both are more expensive all other things being equal. > > Mark > >>> On Jul 10, 2015, at 2:42 PM, Mark Andrews wrote: >>> >>> >>> In message >> >>> , Christopher Morrow writes: >>>>> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: >>>>> I working on a large airport WiFi deployment right now. IPv6 is >> "allowed = >>>> for in the future" but not configured in the short term. With less >> than 10,= >>>> 000 ephemeral users, we don't expect users to demand IPv6 until most >> mobile= >>>> devices and apps come ready to use IPv6 by default. >>>> >>>> 'we don't expect users to demand ipv6' >>>> >>>> aside from #nanog folks, who 'demands' ipv6? >>>> >>>> Don't they actually 'demand' "access to content on the internet" ? >>>> >>>> Since you seem to have a greenfield deployment, why NOT just put v6 in >>>> place on day0? retrofitting it is surely going to cost time/materials >>>> and probably upgrades to gear that could be avoided by doing it in the >>>> initial installation, right? >>> >>> +1 and you will most probably see about 50% of the traffic being IPv6 if >>> you do so. There is lots of IPv6 capable equipment out there just >> waiting >>> to see a RA. >>> >>> Mark >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cblecker at gmail.com Fri Jul 10 22:09:16 2015 From: cblecker at gmail.com (Christoph Blecker) Date: Fri, 10 Jul 2015 15:09:16 -0700 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <559EECFC.9050407@foobar.org> <55A00F7F.9060801@meanie.nl> Message-ID: The bug that this crash impacts is in ASA was introduced in 9.1(4.3) and fixed in 9.1(5.1) and later. Are you inside the affected version range? If not, it's not the bug being discussed here. If so, you may wish to upgrade. Cheers, Christoph On 10 July 2015 at 12:56, Eddie Tardist wrote: > On Fri, Jul 10, 2015 at 3:31 PM, Paul Hoogsteder wrote: > >> On 09-07-15 23:51, Nick Hilliard wrote: >> >>> On 09/07/2015 22:35, Ricky Beam wrote: >>> >>>> "Free" if you have a support contract. >>>> >>> No, free-as-in-beer. >>> >>> You register a guest CCO account, email tac at cisco.com, provide the device >>> serial number (or output of "show hardware") and the bugid + Cisco PSIRT >>> URL reference. Cisco TAC will then provide you with a download link with >>> fixed software, at no cost to you. It's not a pain in the ass - it works >>> fine. >>> >>> Nick >>> >>> >>> And while that's the general procedure for almost all Cisco products, >> there is even an faster way for the ASA: >> >> - register a CCO account >> - in ASDM choose Tools > Check for ASA/ASDM Updates >> - follow the onscreen instructions >> >> Paul. > > > Hello Gentlemen, > > I had a crashing ASA 5585-S40 yesterday and it is still crashing today. Box > is up to date, I have similar setups on LAX and on east coast and I only > see the problem on west coast on circuits connected to Level3 traffic. I > have a couple tickets still open with Cisco staff. They have added some > dataplane protection which minimized the instability, but I dont know if > it's a coincidence or effective, since it's not that often but 5585-S40 > boxes are still crashing. > > If anyone got any update on what's going on please share. I have replaced > one critical box with a Juniper one but I can't do it for all my sites > promptly so. > > So far what I found is that it's related to protocol 132 (sctp?). I have > tried to filter 132 but no success. I can't just filter source address > since it's legit, and proto 132 filtered traffic stills reaching the box up > the point it leads to the problem (if in fact it's sctp related). > > It looks like I'm back to 90's since it seems like a single packet attack. > I can't see volumetric deviations, I can't see unusual patterns, proto 132 > starts showing up and nothing goes wrong, suddenly I get the crash, no > matter if it's been a couple minutes with some proto 132 traffic or if the > traffic just started this second... the only "coincidence" is proto 132 > popping up without any further specific pattern. > > Weird and keeps happening. From mel at beckman.org Fri Jul 10 22:10:33 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 10 Jul 2015 22:10:33 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <2E7E4335-D8CB-4D3E-8709-372E70C98005@arin.net> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <23291.1436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> , <2E7E4335-D8CB-4D3E-8709-372E70C98005@arin.net> Message-ID: <569BEA2E-FC22-4133-9A40-11E766991995@beckman.org> Thank you! -mel via cell On Jul 10, 2015, at 2:19 PM, John Curran > wrote: On Jul 10, 2015, at 4:06 PM, Mel Beckman > wrote: John, Thanks for the clarification. I'm happy to abide by the original community decision, but I think it's important that the table be clarified, especially given that the ARIN specialist I worked with agreed that it needs clarification. It's like going to a Starbucks as a homeless person with just pocket change, and ordering the cheapest coffee on the menu, and being told "Oh, that's for off-planet visitors only. It says so on our website under "Terms and Conditions." Can I interest you in this giga-latte at only four times the price?" A simple asterisk, followed by "Not available to residents of Earth", would prevent the confusion, and resulting social awkwardness. We made note of the IPv6 policy minimum of /36 in the linked FAQ that accompanies the Fee Table, but I'll admit it could be clearer (particularly for those obtaining number resources for the first time.) We'll do an update after the October meeting reflecting the final outcome with respect to the fee table, and will address at that time. Thanks! /John John Curran President and CEO ARIN From marka at isc.org Fri Jul 10 22:13:25 2015 From: marka at isc.org (Mark Andrews) Date: Sat, 11 Jul 2015 08:13:25 +1000 Subject: Hotels/Airports with IPv6 In-Reply-To: Your message of "Fri, 10 Jul 2015 17:56:58 -0400." <20150710215658.GC23237@puck.nether.net> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710215658.GC23237@puck.nether.net> Message-ID: <20150710221325.E2F5732B48B7@rock.dv.isc.org> In message <20150710215658.GC23237 at puck.nether.net>, Jared Mauch writes: > On Sat, Jul 11, 2015 at 07:41:53AM +1000, Mark Andrews wrote: > > +1 and you will most probably see about 50% of the traffic being IPv6 if > > you do so. There is lots of IPv6 capable equipment out there just waiting > > to see a RA. > > What I noticed when I ran a transparent HTTP proxy at my gateway > where it had IPv6 on the outside but the hosts inside did not, a lot > of traffic was converted from IPv4 to IPv6 on the exterior. > > As the internet has been moving to HTTPS/HSTS having > DHCP and client-side support of something like > draft-wkumari-dhc-capport is going to become more critical as the days > go by. > > While attempting to trigger the captive portal at RDU this > week, Boingo redirected a query for google to their HTTPS to the > portal and since HSTS was enabled I had no way to proceed from there > to the right location to authenticate. > > There was also some other broken stuff at RDU so I ended up > just using cellular data. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. I just type a random IP address into the browser when this sort of thing happens. Most of my connections are encrypted. Once the landing page comes up and I've clicked through a pointless terms of service they start working. If they intercept the session with their own cert I get lots of error dialogs. I then cancel the connection attempts and go the browser. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From surfer at mauigateway.com Fri Jul 10 22:18:10 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 10 Jul 2015 15:18:10 -0700 Subject: Hotels/Airports with IPv6 Message-ID: <20150710151810.1DAF3640@m0005296.ppops.net> > Limited municipal budgets is all I can say. > IPv6 has a cost, and if they can put it off > till later then that's often good politics. IPv4 has a cost as well. May as well just go IPv6-only from day one and not pay the IPv4 tax at all. The cost difference between providing IPv6 + IPv4 or just IPv4 from day 1 should be zero. There should be no re-tooling. You just select products that support both initially. It's not like products that support both are more expensive all other things being equal. -------------------------------------- You're talking logical sense and from what I have seen, government-oriented managers do not do that. It's politics only. Not technical. Not logical. Not actual save/make money. Put it off until a later date. Period. scott (work [close enough to gov't folks to be painful] has got me feeling cynical today... :-) From shane at ronan-online.com Fri Jul 10 22:25:21 2015 From: shane at ronan-online.com (Shane Ronan) Date: Fri, 10 Jul 2015 18:25:21 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: <20150710221325.E2F5732B48B7@rock.dv.isc.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710215658.GC23237@puck.nether.net> <20150710221325.E2F5732B48B7@rock.dv.isc.org> Message-ID: 1.1.1.1 is usually a good bet On Jul 10, 2015 6:21 PM, "Mark Andrews" wrote: > > In message <20150710215658.GC23237 at puck.nether.net>, Jared Mauch writes: > > On Sat, Jul 11, 2015 at 07:41:53AM +1000, Mark Andrews wrote: > > > +1 and you will most probably see about 50% of the traffic being IPv6 > if > > > you do so. There is lots of IPv6 capable equipment out there just > waiting > > > to see a RA. > > > > What I noticed when I ran a transparent HTTP proxy at my gateway > > where it had IPv6 on the outside but the hosts inside did not, a lot > > of traffic was converted from IPv4 to IPv6 on the exterior. > > > > As the internet has been moving to HTTPS/HSTS having > > DHCP and client-side support of something like > > draft-wkumari-dhc-capport is going to become more critical as the days > > go by. > > > > While attempting to trigger the captive portal at RDU this > > week, Boingo redirected a query for google to their HTTPS to the > > portal and since HSTS was enabled I had no way to proceed from there > > to the right location to authenticate. > > > > There was also some other broken stuff at RDU so I ended up > > just using cellular data. > > > > - Jared > > > > -- > > Jared Mauch | pgp key available via finger from jared at puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > > I just type a random IP address into the browser when this sort of > thing happens. Most of my connections are encrypted. Once the > landing page comes up and I've clicked through a pointless terms > of service they start working. If they intercept the session with > their own cert I get lots of error dialogs. I then cancel the > connection attempts and go the browser. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From marka at isc.org Fri Jul 10 22:27:24 2015 From: marka at isc.org (Mark Andrews) Date: Sat, 11 Jul 2015 08:27:24 +1000 Subject: Hotels/Airports with IPv6 In-Reply-To: Your message of "Fri, 10 Jul 2015 22:08:15 +0000." References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> , <20150710214153.3A3DA32B42B9@rock.dv.isc.org> , <20150710220258.622AD32B47BD@rock.dv.isc.org> Message-ID: <20150710222724.D0E6D32B49CB@rock.dv.isc.org> In message , Mel Beckman writ es: > There is most certainly a cost to IPv6, especially in a large, complex > deployment, where everything requires acceptance testing. And I'm sure > you realize that IPv6 only is not an option. I agree that it would have > been worth the cost, which would have been just a small fraction of the > total. The powers that be chose not to incur it now. But we did deploy > only IPv6 gear and systems, so it can probably be turned up later for > that same incremental cost. > > -mel via cell Since you have IPv6 capable gear your acceptance testing should be including the IPv6 side of it so there are no saving there if you are doing your job correctly. It is hard to go back to the suppliers N years down the track and then say "This gear isn't working for IPv6" and request a return / fix. Turning on IPv6 later will ultimately cost more than doing it from the start. You have to manage the potential disruption. The difference in perception between "teething troubles" and "you may break the service" is huge. If you havn't done proper acceptance testing or missed something there will be replacement costs. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.Nether.net Fri Jul 10 22:32:34 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 10 Jul 2015 18:32:34 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> Message-ID: <20150710223234.GD23237@puck.nether.net> On Fri, Jul 10, 2015 at 10:08:15PM +0000, Mel Beckman wrote: > There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth the cost, which would have been just a small fraction of the total. The powers that be chose not to incur it now. But we did deploy only IPv6 gear and systems, so it can probably be turned up later for that same incremental cost. > I had the luxury that as we deployed IPv6 across the network we rolled it from the 6bone -> core -> edge over a period of a few months. As we shut down the 6bone/3ffe stuff and moved people to gre/ip and native the core was ready. This doesn't mean the edges have IPv6 turned on, but it's usually the flip of a switch. Where possible take your core and IPv6 enable it and then touch the upstreams at the same time/next time you do work there. Assuming you patch devices for the various SIRT/PSIRT type events, most devices will be rebooted once every 6-12 months. this gives you the chance to drop in and enable ipv6 during or after that change/maint window. Rolling out the core really isn't hard, go ahead and do it. There are plenty of people here who will help you with these steps. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From edtardist at gmail.com Fri Jul 10 23:00:19 2015 From: edtardist at gmail.com (Eddie Tardist) Date: Fri, 10 Jul 2015 20:00:19 -0300 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <559EECFC.9050407@foobar.org> <55A00F7F.9060801@meanie.nl> Message-ID: On Fri, Jul 10, 2015 at 7:09 PM, Christoph Blecker wrote: > The bug that this crash impacts is in ASA was introduced in 9.1(4.3) > and fixed in 9.1(5.1) and later. Are you inside the affected version > range? If not, it's not the bug being discussed here. If so, you may > wish to upgrade. > Which is the bug being discussed here? I am still in the dark. No, I am not in the affected range, the only bug I am aware related to proto 132 is back from 2013 and I don't suspect it's the same bug by reading the advisory (however it's the same problem, crashing system). This is why I am blindly looking for clues. Proto 132 is a correlation I made and assumed but not clear at all. If you are talking about any other bug please clarify or point me for further readings, I am still looking for a reaction. Thanks. > Cheers, > Christoph From mel at beckman.org Fri Jul 10 23:48:46 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 10 Jul 2015 23:48:46 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <20150710223234.GD23237@puck.nether.net> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> , <20150710223234.GD23237@puck.nether.net> Message-ID: <3F1FB780-97A6-4946-A8B6-35CAA1ECC7BC@beckman.org> You perhaps haven't worked a large government network deployment before. One doesn't activate features not enumerated in the design. Ever. Because they won't get and can thus introduce security or reliability covered in acceptance testing and could introduce security or reliability problems. These networks have many engineers, months of meetings, and rigorous change control. Turning on IPv6 without authorization would result in termination. -mel via cell > On Jul 10, 2015, at 3:32 PM, Jared Mauch wrote: > >> On Fri, Jul 10, 2015 at 10:08:15PM +0000, Mel Beckman wrote: >> There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth the cost, which would have been just a small fraction of the total. The powers that be chose not to incur it now. But we did deploy only IPv6 gear and systems, so it can probably be turned up later for that same incremental cost. >> > > I had the luxury that as we deployed IPv6 across the network > we rolled it from the 6bone -> core -> edge over a period of a few months. > > As we shut down the 6bone/3ffe stuff and moved people to gre/ip > and native the core was ready. This doesn't mean the edges have IPv6 > turned on, but it's usually the flip of a switch. > > Where possible take your core and IPv6 enable it and then > touch the upstreams at the same time/next time you do work there. > > Assuming you patch devices for the various SIRT/PSIRT type > events, most devices will be rebooted once every 6-12 months. this > gives you the chance to drop in and enable ipv6 during or after that > change/maint window. > > Rolling out the core really isn't hard, go ahead and do it. There > are plenty of people here who will help you with these steps. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. From jared at puck.Nether.net Sat Jul 11 00:02:25 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 10 Jul 2015 20:02:25 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: <3F1FB780-97A6-4946-A8B6-35CAA1ECC7BC@beckman.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> <20150710223234.GD23237@puck.nether.net> <3F1FB780-97A6-4946-A8B6-35CAA1ECC7BC@beckman.org> Message-ID: <20150711000225.GE23237@puck.nether.net> On Fri, Jul 10, 2015 at 11:48:46PM +0000, Mel Beckman wrote: > You perhaps haven't worked a large government network deployment before. One doesn't activate features not enumerated in the design. Ever. Because they won't get and can thus introduce security or reliability covered in acceptance testing and could introduce security or reliability problems. These networks have many engineers, months of meetings, and rigorous change control. Turning on IPv6 without authorization would result in termination. > I did not suggest turning it on without authorization, I discussed the steps I would take to deploy it as devices are touched. I will say that some organizations have draconian ideas of what change management looks like. I would also suggest that a state or federal government (such as the US technically mandates IPv6 already, but as with all things people waiver them) is not what may be in the subject line, with the exception of an airport authority that may perform this. Personally I consider it a bit of technical malpractice to arrive a decade late to the IPv6 game but am sympathetic to those that have been trying hard to do the righ thing despite the environment they are in. Either way, you're also correct that I'm not dealing with a government agency in $dayjob. I also plan to keep it that way, except in the extreme case where I'm given authority to fix said oversights. I've seen parades of people jump from organizations they were prepared to clean up because of oppressive change management processes or work conditions. I'm sure there is a series of dilbert or similar cartoons on this. Then again, I'm pretty sure IPv6 won't cause this to happen: http://static3.businessinsider.com/image/525db76369bedd1029d61f47-1200/august-2009.jpg - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mel at beckman.org Sat Jul 11 00:07:50 2015 From: mel at beckman.org (Mel Beckman) Date: Sat, 11 Jul 2015 00:07:50 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <20150710222724.D0E6D32B49CB@rock.dv.isc.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> , <20150710214153.3A3DA32B42B9@rock.dv.isc.org> , <20150710220258.622AD32B47BD@rock.dv.isc.org> , <20150710222724.D0E6D32B49CB@rock.dv.isc.org> Message-ID: Mark, Few acceptance test regimes cover established feature testing. It's just too expensive. For example, an acceptance test of a firewall installation does not include validating the DPI implementation. Government and enterprise buyers rely on certifications, such as ICSA for firewalls, IPv6Ready for IPv6, and standards compliance, such as IEEE 802.11ac for wireless. Instead, an acceptance test exercises the full system to ensure that it hits predetermined performance benchmarks, meets all the customer's functional requirements, and is secure. If one of the several vendors in such a project unilaterally changes components to enable unspecified protocols or features, testing won't line up with the implementation, and people will be very unhappy with the presumptuous vendor. Having deployed many IPv6 upgrades in legacy networks, I don't see deferring IPv6 as a net higher cost. It would be nice to have now, but, as they say, the customer is always right. -mel via cell > On Jul 10, 2015, at 3:27 PM, Mark Andrews wrote: > > > In message , Mel Beckman writ > es: >> There is most certainly a cost to IPv6, especially in a large, complex >> deployment, where everything requires acceptance testing. And I'm sure >> you realize that IPv6 only is not an option. I agree that it would have >> been worth the cost, which would have been just a small fraction of the >> total. The powers that be chose not to incur it now. But we did deploy >> only IPv6 gear and systems, so it can probably be turned up later for >> that same incremental cost. >> >> -mel via cell > > Since you have IPv6 capable gear your acceptance testing should be > including the IPv6 side of it so there are no saving there if you > are doing your job correctly. It is hard to go back to the suppliers > N years down the track and then say "This gear isn't working for > IPv6" and request a return / fix. > > Turning on IPv6 later will ultimately cost more than doing it from > the start. You have to manage the potential disruption. The > difference in perception between "teething troubles" and "you may > break the service" is huge. If you havn't done proper acceptance > testing or missed something there will be replacement costs. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jfbeam at gmail.com Sat Jul 11 00:08:22 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 10 Jul 2015 20:08:22 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <23291.1436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> Message-ID: On Fri, 10 Jul 2015 16:06:03 -0400, Mel Beckman wrote: > It's like going to a Starbucks as a homeless person with just pocket > change, and ordering the cheapest coffee on the menu, and being told > "Oh, that's for off-planet visitors only. It says so on our website > under "Terms and Conditions." Can I interest you in this giga-latte at > only four times the price?" You are confusing the "price list" with the "menu". Yes, a simple note at the bottom of that table would fix this: Current minimum IPv6 allocation is /36. That schedule doesn't say you can get a /40, only what you will pay if you *HAVE* a /40. (Did ARIN ever hand out /40's? If not, why is in the table?) From fergdawgster at mykolab.com Sat Jul 11 00:14:21 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 10 Jul 2015 17:14:21 -0700 Subject: Possible Sudden Uptick in ASA DOS? In-Reply-To: References: <6F73BBE8-9EE1-425E-8DD2-3BFE5B0D59D4@shrd.fr> <5BD9B971-CA92-43A0-B43E-D0BFB3FEC0D0@puck.nether.net> <559EECFC.9050407@foobar.org> <55A00F7F.9060801@meanie.nl> Message-ID: <55A05FDD.9090100@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/10/2015 4:00 PM, Eddie Tardist wrote: > On Fri, Jul 10, 2015 at 7:09 PM, Christoph Blecker > wrote: > >> The bug that this crash impacts is in ASA was introduced in >> 9.1(4.3) and fixed in 9.1(5.1) and later. Are you inside the >> affected version range? If not, it's not the bug being discussed >> here. If so, you may wish to upgrade. >> > > Which is the bug being discussed here? I am still in the dark. No, > I am not in the affected range, the only bug I am aware related to > proto 132 is back from 2013 and I don't suspect it's the same bug > by reading the advisory (however it's the same problem, crashing > system). This is why I am blindly looking for clues. Proto 132 is > a correlation I made and assumed but not clear at all. If you are > talking about any other bug please clarify or point me for further > readings, I am still looking for a reaction. > Eddi: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cis co-sa-20141008-asa - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWgX90ACgkQKJasdVTchbJwKwEAyG1UjDE1cGB/jrLnzQmiNNvO O/AHM2/D1rXrm8SVoAUBAKl14Wdyz+VgByPhEE+YCvuoWOdX8+7wUk/DfohEBb1k =0DDw -----END PGP SIGNATURE----- From mel at beckman.org Sat Jul 11 00:15:49 2015 From: mel at beckman.org (Mel Beckman) Date: Sat, 11 Jul 2015 00:15:49 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <20150711000225.GE23237@puck.nether.net> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> <20150710223234.GD23237@puck.nether.net> <3F1FB780-97A6-4946-A8B6-35CAA1ECC7BC@beckman.org>, <20150711000225.GE23237@puck.nether.net> Message-ID: Jared, http://static3.businessinsider.com/image/525db76369bedd1029d61f47-1200/august-2009.jpg Perfect! -mel via cell On Jul 10, 2015, at 5:02 PM, Jared Mauch > wrote: On Fri, Jul 10, 2015 at 11:48:46PM +0000, Mel Beckman wrote: You perhaps haven't worked a large government network deployment before. One doesn't activate features not enumerated in the design. Ever. Because they won't get and can thus introduce security or reliability covered in acceptance testing and could introduce security or reliability problems. These networks have many engineers, months of meetings, and rigorous change control. Turning on IPv6 without authorization would result in termination. I did not suggest turning it on without authorization, I discussed the steps I would take to deploy it as devices are touched. I will say that some organizations have draconian ideas of what change management looks like. I would also suggest that a state or federal government (such as the US technically mandates IPv6 already, but as with all things people waiver them) is not what may be in the subject line, with the exception of an airport authority that may perform this. Personally I consider it a bit of technical malpractice to arrive a decade late to the IPv6 game but am sympathetic to those that have been trying hard to do the righ thing despite the environment they are in. Either way, you're also correct that I'm not dealing with a government agency in $dayjob. I also plan to keep it that way, except in the extreme case where I'm given authority to fix said oversights. I've seen parades of people jump from organizations they were prepared to clean up because of oppressive change management processes or work conditions. I'm sure there is a series of dilbert or similar cartoons on this. Then again, I'm pretty sure IPv6 won't cause this to happen: http://static3.businessinsider.com/image/525db76369bedd1029d61f47-1200/august-2009.jpg - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mel at beckman.org Sat Jul 11 00:30:24 2015 From: mel at beckman.org (Mel Beckman) Date: Sat, 11 Jul 2015 00:30:24 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <23291.1436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> , Message-ID: <61320F38-CC57-49ED-BC52-2D3F869C99F6@beckman.org> Ricky, I am always in favor of redundant clarity over technically correct confusion :) -mel beckman > On Jul 10, 2015, at 5:08 PM, Ricky Beam wrote: > >> On Fri, 10 Jul 2015 16:06:03 -0400, Mel Beckman wrote: >> It's like going to a Starbucks as a homeless person with just pocket change, and ordering the cheapest coffee on the menu, and being told "Oh, that's for off-planet visitors only. It says so on our website under "Terms and Conditions." Can I interest you in this giga-latte at only four times the price?" > > You are confusing the "price list" with the "menu". Yes, a simple note at the bottom of that table would fix this: Current minimum IPv6 allocation is /36. That schedule doesn't say you can get a /40, only what you will pay if you *HAVE* a /40. > > (Did ARIN ever hand out /40's? If not, why is in the table?) From jj at anexia.at Sat Jul 11 00:51:41 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Sat, 11 Jul 2015 00:51:41 +0000 Subject: AW: Level3 routing issue US west coast In-Reply-To: References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> <11cd4154ae384babbdd11b5df252ee1f@anx-i-dag02.anx.local> <005d01d0bb23$6475de00$2d619a00$@bofh.de> Message-ID: <89c5d45b68324ee2955ccde223fc7387@anx-i-dag02.anx.local> Level3 is broken again ... Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 178.255.154.17 63.6% 12 0.2 0.2 0.2 0.3 0.0 2. ge-6-14.car2.Prague1.Level3.net 0.0% 12 58.1 123.3 0.4 338.6 117.2 3. ??? 4. 4.53.208.102 90.9% 12 732.2 732.2 732.2 732.2 0.0 5. TenGE0-4-0-16.br02.hkg15.pccwbtn.net 81.8% 12 871.8 867.2 862.6 871.8 6.5 6. TenGE0-4-0-16.br02.hkg15.pccwbtn.net 90.0% 11 860.8 860.8 860.8 860.8 0.0 7. ? 80.0% 11 881.6 877.8 874.0 881.6 5.4 8. ??? Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. er-04.0v-00-03.anx04.vie.at.anexia-it.com 0.0% 9 0.9 2.1 0.4 14.8 4.8 2. cr-04.0v-08-71.anx03.vie.at.anexia-it.com 0.0% 9 8.9 2.2 0.5 8.9 3.5 3. win-b4-link.telia.net 0.0% 8 0.5 0.6 0.5 1.3 0.3 4. level-ic-1573273-wien-b4.c.telia.net 0.0% 8 0.5 0.5 0.5 0.7 0.1 5. ae-4-90.edge1.SanJose3.Level3.net 62.5% 8 160.7 159.6 158.7 160.7 1.0 6. ae-4-90.edge1.SanJose3.Level3.net 50.0% 8 158.7 158.7 158.5 159.0 0.2 7. ??? 8. TenGE1-3.br01.seo01.pccwbtn.net 57.1% 8 870.6 871.0 867.4 875.0 3.8 9. ??? 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 85.7% 8 873.1 873.1 873.1 873.1 0.0 11. ??? 12. 61.250.89.2 80.0% 6 893.1 893.1 893.1 893.1 0.0 13. ??? J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: J?rgen Jaritsch Gesendet: Freitag, 10. Juli 2015 18:45 An: Jens Hoffmann; nanog at nanog.org Betreff: AW: Level3 routing issue US west coast Hi, No SLA broken cause A- and B-End were not directly our circuits ... but it helps a lot to place some new orders ... at other partners :). best regards J?rgen Jaritsch -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Jens Hoffmann Gesendet: Freitag, 10. Juli 2015 17:16 An: nanog at nanog.org Betreff: AW: Level3 routing issue US west coast Hi, >Wow .... Level3 responded to me that they had an issue last night .... but they simply did nothing ... for at least 10 hours they >did nothing to fix the issue: Any SLA broken? Probably not, that would be a reason to move. Kind regards, Jens From jfbeam at gmail.com Sat Jul 11 00:58:22 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 10 Jul 2015 20:58:22 -0400 Subject: Also Facebook (was: Re: Dual stack IPv6 for IPv4 depletion) In-Reply-To: <3B610D43-D767-4308-A0E5-C995D20D8EDC@arin.net> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> <8C616849-E018-4595-969B-54DE785632DC@arin.net> <3B610D43-D767-4308-A0E5-C995D20D8EDC@arin.net> Message-ID: On Fri, 10 Jul 2015 06:14:16 -0400, John Curran wrote: > If there are ?holes? in the methodology, then they are quite consistent > holes... They are mere statistics. They say only what they say without any measured margin of error. For Google, their numbers are collected via javascript embedded in search results. Anything that prevents that JS from running to completion (noscript, error, nagivating away, ...) is a lost count. Anyone not using Google search won't be counted. (that's a non-zero number, btw. But likewise, is difficult to prove.) So, there's ways to be missed in their numbers. OTOH, those being counted could, potentially, be counted more than once depending on how much of the address they correlate. (privacy extensions rotate the address) I don't know how Facebook is collecting stats. But I suspect they have a wider sampling base due simply to the fact almost every web page on the internet has some content pulled from facebook -- eg. comment engine, authentication engine, or "post on facebook" pingback button. How many sites do you visit per day that pull nothing at all from facebook? The only people who can give solid numbers w.r.t. IPv6 usage are the ISPs themselves. And we cannot trust them because it's a marketing statistic, if they release anything at all. (been there, watched marketing/PR ignore my numbers and make up their own.) From morrowc.lists at gmail.com Sat Jul 11 02:04:10 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jul 2015 22:04:10 -0400 Subject: Level3 routing issue US west coast In-Reply-To: <89c5d45b68324ee2955ccde223fc7387@anx-i-dag02.anx.local> References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> <11cd4154ae384babbdd11b5df252ee1f@anx-i-dag02.anx.local> <005d01d0bb23$6475de00$2d619a00$@bofh.de> <89c5d45b68324ee2955ccde223fc7387@anx-i-dag02.anx.local> Message-ID: On Fri, Jul 10, 2015 at 8:51 PM, J?rgen Jaritsch wrote: > Level3 is broken again ... > maybe today they decided to only do L2 routing? :) From jared at puck.Nether.net Sat Jul 11 02:06:05 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 10 Jul 2015 22:06:05 -0400 Subject: Also Facebook (was: Re: Dual stack IPv6 for IPv4 depletion) In-Reply-To: References: <85E1C9AE-80F7-4E8B-B11A-E2159DEA99A0@delong.com> <49B19FFD-336B-46D2-BC41-4FC7BD58B63B@delong.com> <8C616849-E018-4595-969B-54DE785632DC@arin.net> <3B610D43-D767-4308-A0E5-C995D20D8EDC@arin.net> Message-ID: <20150711020605.GF23237@puck.nether.net> On Fri, Jul 10, 2015 at 08:58:22PM -0400, Ricky Beam wrote: > On Fri, 10 Jul 2015 06:14:16 -0400, John Curran wrote: > >If there are ?holes? in the methodology, then they are quite consistent > >holes... > > They are mere statistics. They say only what they say without any measured > margin of error. > > For Google, their numbers are collected via javascript embedded in search > results. Anything that prevents that JS from running to completion > (noscript, error, nagivating away, ...) is a lost count. Anyone not using > Google search won't be counted. (that's a non-zero number, btw. But > likewise, is difficult to prove.) So, there's ways to be missed in their > numbers. OTOH, those being counted could, potentially, be counted more than > once depending on how much of the address they correlate. (privacy > extensions rotate the address) > > I don't know how Facebook is collecting stats. But I suspect they have a > wider sampling base due simply to the fact almost every web page on the > internet has some content pulled from facebook -- eg. comment engine, > authentication engine, or "post on facebook" pingback button. How many sites > do you visit per day that pull nothing at all from facebook? > > The only people who can give solid numbers w.r.t. IPv6 usage are the ISPs > themselves. And we cannot trust them because it's a marketing statistic, if > they release anything at all. (been there, watched marketing/PR ignore my > numbers and make up their own.) Well, I'm a techie mostly. I'll say I currently see 107 ipv4 bits for every 1 ipv6 bit poking at netflow data. My ratios may not be yours, YMMV, sampling error, router bugs, etc. ie: not that great. That being said, we continue to see an uptick and it's nearly all tcp. Depending on whose data you use and how you solve ones regression you can come up with interesting results. If you primarily deal with one country and don't have it, consider looking at both the google and apnic data via this tool: https://www.vyncke.org/ipv6status/project.php I have also noticed my iOS9 public beta device passes the checks at Jasons test-ipv6.com site where it would often prefer ipv4. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From owen at delong.com Sat Jul 11 04:49:06 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jul 2015 21:49:06 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097A32@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com> <23291.1! 436511218@turing-police.cc.vt.edu> <48C9DEBC-B3AD-4CF4-A6B0-317838B25794@matthew.at> <54BB131F-1B64-41A9-B300-F464838EA710@delong.com> Message-ID: <65A5A926-A739-4FAD-9139-46EA9B87BF06@delong.com> > On Jul 10, 2015, at 12:50 , John Curran wrote: > > On Jul 10, 2015, at 1:35 PM, Mel Beckman > wrote: > > This is a side issue, but I'm surprised ARIN is still advertising incorrect information in the table. > ... > Are you saying that there is no way to get an IPv6 allocation in the xx-small category? > ARIN: Yes. The /36 prefix is the smallest size ARIN is permitted to allocate to ISPs according to community-created policy. https://www.arin.net/policy/nrpm.html#six52 > ... > But ARIN still is advertising the /40 option months later! As a result we as a community lost the opportunity to get a new ISP off on the right foot by going dual-stacked. This is not good for IPv6 adoption. Hopefully ARIN reads this and addresses the issue - either correct the table or honor xx-small requests for a /40. > > Mel - > > The confusion is very understandable, but both the fee table and the policy are > accurate. The fee table includes an XX-Small category which corresponds to > those ISPs which have smaller than /20 IPv4 and smaller than a /36 IPv6 total > holdings ? the fact that such a category exists does not mean that any particular > ISP is being billed in that category (or that a new ISP will necessarily end up in > that category); it simply means that ISPs with those total resources are billed > accordingly. John, This is a bit disingenuous. I believe that there should, at least, be an indication on the table that the fee category is not available per policy when that is the case. It is not now nor has it ever been possible for an ISP to get a /40 or less of IPv6. If policy ever changes to make such a silly thing available, then the note could be removed from the table. > The constraint that you experienced, i.e. that there is a minimum IPv6 ISP allocation > size of /36 is actually not something that the staff can fix; i.e. it?s the result of the > community-led policy development process, and if you feel it does need to change > to a lower number, you should propose an appropriate change to policy on the > ARIN public policy mailing list >. What if, instead, we feel that the entire IPv6 fee structure should shift up one row. /36 should be considered XX-Small, /40 should be considered Small, etc. Whether to leave the numbers in place or move them with the prefix lengths is left as an exercise for the staff. I really don?t care which you do. > We _are_ in the midst of considering changes to the fee table to lower and realign > the IPv6 fees in general (which might be a better solution if the cost is issue) - see > > for the update provided in April at the ARIN 35 Members meeting, with specific > options for community discussion at the ARIN Fall meeting taking place in > Montreal this October (adjacent to the NANOG Fall meeting) Indeed? I wish this was moving at a somewhat less glacial pace. Owen From owen at delong.com Sat Jul 11 04:55:53 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jul 2015 21:55:53 -0700 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> Message-ID: How can it be a large, complex deployment if it?s greenfield. In that case, you need to acceptance test the IPv4 just as much as IPv6. The difference is that you don?t have to rerun your acceptance tests 6-months later when you have to implement IPv6 in a rush because you suddenly learned that your major client gets major suckage on IPv4 due to their provider having put them behind the worst CGN on the planet. Owen > On Jul 10, 2015, at 15:08 , Mel Beckman wrote: > > There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth the cost, which would have been just a small fraction of the total. The powers that be chose not to incur it now. But we did deploy only IPv6 gear and systems, so it can probably be turned up later for that same incremental cost. > > -mel via cell > >> On Jul 10, 2015, at 3:03 PM, Mark Andrews wrote: >> >> >> In message , Mel Beckman writ >> es: >>> Limited municipal budgets is all I can say. IPv6 has a cost, and if they >>> can put it off till later then that's often good politics. >>> >>> -mel via cell >> >> IPv4 has a cost as well. May as well just go IPv6-only from day one and >> not pay the IPv4 tax at all. >> >> The cost difference between providing IPv6 + IPv4 or just IPv4 from >> day 1 should be zero. There should be no re-tooling. You just >> select products that support both initially. It's not like products >> that support both are more expensive all other things being equal. >> >> Mark >> >>>> On Jul 10, 2015, at 2:42 PM, Mark Andrews wrote: >>>> >>>> >>>> In message >>> >>>> , Christopher Morrow writes: >>>>>> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: >>>>>> I working on a large airport WiFi deployment right now. IPv6 is >>> "allowed = >>>>> for in the future" but not configured in the short term. With less >>> than 10,= >>>>> 000 ephemeral users, we don't expect users to demand IPv6 until most >>> mobile= >>>>> devices and apps come ready to use IPv6 by default. >>>>> >>>>> 'we don't expect users to demand ipv6' >>>>> >>>>> aside from #nanog folks, who 'demands' ipv6? >>>>> >>>>> Don't they actually 'demand' "access to content on the internet" ? >>>>> >>>>> Since you seem to have a greenfield deployment, why NOT just put v6 in >>>>> place on day0? retrofitting it is surely going to cost time/materials >>>>> and probably upgrades to gear that could be avoided by doing it in the >>>>> initial installation, right? >>>> >>>> +1 and you will most probably see about 50% of the traffic being IPv6 if >>>> you do so. There is lots of IPv6 capable equipment out there just >>> waiting >>>> to see a RA. >>>> >>>> Mark >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mel at beckman.org Sat Jul 11 05:34:03 2015 From: mel at beckman.org (Mel Beckman) Date: Sat, 11 Jul 2015 05:34:03 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> , Message-ID: <29B817E0-B42A-41FB-A3BA-9A49DBB1232E@beckman.org> Owen, I never said it was a greenfield deployment. Someone else tagged it with that term. My understanding of the term "greenfield" WRT wifi is that there are no interfering signals to contend with. I don't know of any U.S. airport that meets that definition. First you have all the wifi of concessionaires, the airlines' passenger clubs and operations, and service organizations for food, fuel, and FAA. You can't control those users, thanks to the FAA's recent decisions restricting wifi regulation to itself. Then comes radar and secondary-use DFS channels that may have to be excluded. Finally you encounter waves of MiFi hotspots which tend to be synchronized with aircraft arrivals and departures. All this existing traffic requires extensive surveys and pre-deployment modeling, plus lab testing for planned applications, such as way-finding. Acceptance testing is straightforward once it's been designed and scripted. You bring in a wifi traffic generator (from a professional test services company) that can simulate 1000 or more wifi clients to impose a known traffic load on the network. You then use sample passenger devices of each type -- smartphone, tablet, and laptop -- as well as various popular OS's to run pre-engineered regression test scripts, recording performance via a wifi sniffer. The sniffer capture then goes through offline analysis to compare actual throughout and response times with the original design metrics. You do this for selected sub areas having typical characteristics, such as a gate, security queue, baggage or dining area, at a time when it's empty. The testing process takes a day or two per airport terminal. Yes, the acceptance test needs to be revised and repeated for deploying IPv6. That is a small cost compared to the already-expended months of deployment planning and rollout. The incremental IPv6 acceptance test cost is in the noise, dwarfed even by the price of conduit. I do agree that there are potential performance gains with IPv6, through avoiding NAT. But those benefits will still be there in a year or two, and will be much larger then than they are today. Moreover, the user population is not growing rapidly, and can easily fit into simple NAT with the airport's existing IPv4 space. -mel > On Jul 10, 2015, at 9:55 PM, Owen DeLong wrote: > > How can it be a large, complex deployment if it?s greenfield. > > In that case, you need to acceptance test the IPv4 just as much as IPv6. > > The difference is that you don?t have to rerun your acceptance tests 6-months later when you have to implement IPv6 in a rush because you suddenly learned that your major client gets major suckage on IPv4 due to their provider having put them behind the worst CGN on the planet. > > Owen > >> On Jul 10, 2015, at 15:08 , Mel Beckman wrote: >> >> There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth the cost, which would have been just a small fraction of the total. The powers that be chose not to incur it now. But we did deploy only IPv6 gear and systems, so it can probably be turned up later for that same incremental cost. >> >> -mel via cell >> >>> On Jul 10, 2015, at 3:03 PM, Mark Andrews wrote: >>> >>> >>> In message , Mel Beckman writ >>> es: >>>> Limited municipal budgets is all I can say. IPv6 has a cost, and if they >>>> can put it off till later then that's often good politics. >>>> >>>> -mel via cell >>> >>> IPv4 has a cost as well. May as well just go IPv6-only from day one and >>> not pay the IPv4 tax at all. >>> >>> The cost difference between providing IPv6 + IPv4 or just IPv4 from >>> day 1 should be zero. There should be no re-tooling. You just >>> select products that support both initially. It's not like products >>> that support both are more expensive all other things being equal. >>> >>> Mark >>> >>>>> On Jul 10, 2015, at 2:42 PM, Mark Andrews wrote: >>>>> >>>>> >>>>> In message >>>> >>>>> , Christopher Morrow writes: >>>>>>> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: >>>>>>> I working on a large airport WiFi deployment right now. IPv6 is >>>> "allowed = >>>>>> for in the future" but not configured in the short term. With less >>>> than 10,= >>>>>> 000 ephemeral users, we don't expect users to demand IPv6 until most >>>> mobile= >>>>>> devices and apps come ready to use IPv6 by default. >>>>>> >>>>>> 'we don't expect users to demand ipv6' >>>>>> >>>>>> aside from #nanog folks, who 'demands' ipv6? >>>>>> >>>>>> Don't they actually 'demand' "access to content on the internet" ? >>>>>> >>>>>> Since you seem to have a greenfield deployment, why NOT just put v6 in >>>>>> place on day0? retrofitting it is surely going to cost time/materials >>>>>> and probably upgrades to gear that could be avoided by doing it in the >>>>>> initial installation, right? >>>>> >>>>> +1 and you will most probably see about 50% of the traffic being IPv6 if >>>>> you do so. There is lots of IPv6 capable equipment out there just >>>> waiting >>>>> to see a RA. >>>>> >>>>> Mark >>>>> -- >>>>> Mark Andrews, ISC >>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From nanog at studio442.com.au Sat Jul 11 05:47:04 2015 From: nanog at studio442.com.au (Julien Goodwin) Date: Sat, 11 Jul 2015 15:47:04 +1000 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710215658.GC23237@puck.nether.net> <20150710221325.E2F5732B48B7@rock.dv.isc.org> Message-ID: <55A0ADD8.6010601@studio442.com.au> On 11/07/15 08:25, Shane Ronan wrote: > 1.1.1.1 is usually a good bet Sadly yes, even though it's valid public IP space Cisco still have it documented as their suggested captive portal address. Despite it (and 1.2.3.0/24) being advertised by $ORK for years at this point on behalf of APNIC. From owen at delong.com Sat Jul 11 05:47:42 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jul 2015 22:47:42 -0700 Subject: Hotels/Airports with IPv6 In-Reply-To: <29B817E0-B42A-41FB-A3BA-9A49DBB1232E@beckman.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> <29B817E0-B42A-41FB-A3BA-9A49DBB1232E@beckman.org> Message-ID: <04193AF2-3B53-4D74-8651-00AD909B8654@delong.com> > On Jul 10, 2015, at 22:34 , Mel Beckman wrote: > > Owen, > > I never said it was a greenfield deployment. Someone else tagged it with that term. > > My understanding of the term "greenfield" WRT wifi is that there are no interfering signals to contend with. I don't know of any U.S. airport that meets that definition. First you have all the wifi of concessionaires, the airlines' passenger clubs and operations, and service organizations for food, fuel, and FAA. You can't control those users, thanks to the FAA's recent decisions restricting wifi regulation to itself. I suppose if you?re going to use that definition, there?s no such thing. However, as a general rule when I talk about a greenfield deployment of a network (of any form), I, and I suspect most people, are referring to a network that is not yet saddled with any legacy deployment issues. E.g. a building that has not yet been designed. A situation where you can start from scratch with a fresh design and specify everything from the ground up, at least in terms of the major design factors in the network. > Acceptance testing is straightforward once it's been designed and scripted. You bring in a wifi traffic generator (from a professional test services company) that can simulate 1000 or more wifi clients to impose a known traffic load on the network. You then use sample passenger devices of each type -- smartphone, tablet, and laptop -- as well as various popular OS's to run pre-engineered regression test scripts, recording performance via a wifi sniffer. The sniffer capture then goes through offline analysis to compare actual throughout and response times with the original design metrics. You do this for selected sub areas having typical characteristics, such as a gate, security queue, baggage or dining area, at a time when it's empty. > > The testing process takes a day or two per airport terminal. Yes, the acceptance test needs to be revised and repeated for deploying IPv6. That is a small cost compared to the already-expended months of deployment planning and rollout. The incremental IPv6 acceptance test cost is in the noise, dwarfed even by the price of conduit. Right, but if you?re starting fresh with a new design, why not design IPv6 in from the start? There?s really no incremental cost to doing so and your long-term savings can be substantial. > I do agree that there are potential performance gains with IPv6, through avoiding NAT. But those benefits will still be there in a year or two, and will be much larger then than they are today. Moreover, the user population is not growing rapidly, and can easily fit into simple NAT with the airport's existing IPv4 space. Let me guess? You?re still running on a computer with 640k of RAM. Owen > > -mel > >> On Jul 10, 2015, at 9:55 PM, Owen DeLong wrote: >> >> How can it be a large, complex deployment if it?s greenfield. >> >> In that case, you need to acceptance test the IPv4 just as much as IPv6. >> >> The difference is that you don?t have to rerun your acceptance tests 6-months later when you have to implement IPv6 in a rush because you suddenly learned that your major client gets major suckage on IPv4 due to their provider having put them behind the worst CGN on the planet. >> >> Owen >> >>> On Jul 10, 2015, at 15:08 , Mel Beckman wrote: >>> >>> There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth the cost, which would have been just a small fraction of the total. The powers that be chose not to incur it now. But we did deploy only IPv6 gear and systems, so it can probably be turned up later for that same incremental cost. >>> >>> -mel via cell >>> >>>> On Jul 10, 2015, at 3:03 PM, Mark Andrews wrote: >>>> >>>> >>>> In message , Mel Beckman writ >>>> es: >>>>> Limited municipal budgets is all I can say. IPv6 has a cost, and if they >>>>> can put it off till later then that's often good politics. >>>>> >>>>> -mel via cell >>>> >>>> IPv4 has a cost as well. May as well just go IPv6-only from day one and >>>> not pay the IPv4 tax at all. >>>> >>>> The cost difference between providing IPv6 + IPv4 or just IPv4 from >>>> day 1 should be zero. There should be no re-tooling. You just >>>> select products that support both initially. It's not like products >>>> that support both are more expensive all other things being equal. >>>> >>>> Mark >>>> >>>>>> On Jul 10, 2015, at 2:42 PM, Mark Andrews wrote: >>>>>> >>>>>> >>>>>> In message >>>>> >>>>>> , Christopher Morrow writes: >>>>>>>> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: >>>>>>>> I working on a large airport WiFi deployment right now. IPv6 is >>>>> "allowed = >>>>>>> for in the future" but not configured in the short term. With less >>>>> than 10,= >>>>>>> 000 ephemeral users, we don't expect users to demand IPv6 until most >>>>> mobile= >>>>>>> devices and apps come ready to use IPv6 by default. >>>>>>> >>>>>>> 'we don't expect users to demand ipv6' >>>>>>> >>>>>>> aside from #nanog folks, who 'demands' ipv6? >>>>>>> >>>>>>> Don't they actually 'demand' "access to content on the internet" ? >>>>>>> >>>>>>> Since you seem to have a greenfield deployment, why NOT just put v6 in >>>>>>> place on day0? retrofitting it is surely going to cost time/materials >>>>>>> and probably upgrades to gear that could be avoided by doing it in the >>>>>>> initial installation, right? >>>>>> >>>>>> +1 and you will most probably see about 50% of the traffic being IPv6 if >>>>>> you do so. There is lots of IPv6 capable equipment out there just >>>>> waiting >>>>>> to see a RA. >>>>>> >>>>>> Mark >>>>>> -- >>>>>> Mark Andrews, ISC >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> From owen at delong.com Sat Jul 11 05:56:00 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jul 2015 22:56:00 -0700 Subject: Hotels/Airports with IPv6 In-Reply-To: <55A0ADD8.6010601@studio442.com.au> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710215658.GC23237@puck.nether.net> <20150710221325.E2F5732B48B7@rock.dv.isc.org> <55A0ADD8.6010601@studio442.com.au> Message-ID: <808E4881-B692-432D-9EB6-352F79D6A336@delong.com> Yes, but TBH, they are advertised as a darkspace collection project, so Cisco?s use is actually somewhat helpful to that activity. It?s unlikely that 1.1.1.0/24 or 1.2.3.0/24 will ever be allocated by APNIC. Owen > On Jul 10, 2015, at 22:47 , Julien Goodwin wrote: > > On 11/07/15 08:25, Shane Ronan wrote: >> 1.1.1.1 is usually a good bet > > Sadly yes, even though it's valid public IP space Cisco still have it documented as their suggested captive portal address. > > Despite it (and 1.2.3.0/24) being advertised by $ORK for years at this point on behalf of APNIC. From mel at beckman.org Sat Jul 11 06:01:40 2015 From: mel at beckman.org (Mel Beckman) Date: Sat, 11 Jul 2015 06:01:40 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <04193AF2-3B53-4D74-8651-00AD909B8654@delong.com> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> <29B817E0-B42A-41FB-A3BA-9A49DBB1232E@beckman.org>, <04193AF2-3B53-4D74-8651-00AD909B8654@delong.com> Message-ID: <5DDD97EB-043D-413D-9BE1-10E95116AC89@beckman.org> Owen, Lol. No, I'm a Mac guy. We think different :) I suppose when an airport is first built, that would be greenfield. But this airport already has a legacy wifi system that we are replacing, incrementally. I agree that a case exists for building in IPv6 from the start, but this deployment already has enough new features, such as 802.11ac and a slew of new applications, that the customer wanted to remove ipv6 as a variable. -mel beckman > On Jul 10, 2015, at 10:47 PM, Owen DeLong wrote: > > >> On Jul 10, 2015, at 22:34 , Mel Beckman wrote: >> >> Owen, >> >> I never said it was a greenfield deployment. Someone else tagged it with that term. >> >> My understanding of the term "greenfield" WRT wifi is that there are no interfering signals to contend with. I don't know of any U.S. airport that meets that definition. First you have all the wifi of concessionaires, the airlines' passenger clubs and operations, and service organizations for food, fuel, and FAA. You can't control those users, thanks to the FAA's recent decisions restricting wifi regulation to itself. > > I suppose if you?re going to use that definition, there?s no such thing. > > However, as a general rule when I talk about a greenfield deployment of a network (of any form), I, and I suspect most people, are referring to a network that is not yet saddled with any legacy deployment issues. E.g. a building that has not yet been designed. A situation where you can start from scratch with a fresh design and specify everything from the ground up, at least in terms of the major design factors in the network. > >> Acceptance testing is straightforward once it's been designed and scripted. You bring in a wifi traffic generator (from a professional test services company) that can simulate 1000 or more wifi clients to impose a known traffic load on the network. You then use sample passenger devices of each type -- smartphone, tablet, and laptop -- as well as various popular OS's to run pre-engineered regression test scripts, recording performance via a wifi sniffer. The sniffer capture then goes through offline analysis to compare actual throughout and response times with the original design metrics. You do this for selected sub areas having typical characteristics, such as a gate, security queue, baggage or dining area, at a time when it's empty. >> >> The testing process takes a day or two per airport terminal. Yes, the acceptance test needs to be revised and repeated for deploying IPv6. That is a small cost compared to the already-expended months of deployment planning and rollout. The incremental IPv6 acceptance test cost is in the noise, dwarfed even by the price of conduit. > > Right, but if you?re starting fresh with a new design, why not design IPv6 in from the start? There?s really no incremental cost to doing so and your long-term savings can be substantial. > >> I do agree that there are potential performance gains with IPv6, through avoiding NAT. But those benefits will still be there in a year or two, and will be much larger then than they are today. Moreover, the user population is not growing rapidly, and can easily fit into simple NAT with the airport's existing IPv4 space. > > Let me guess? You?re still running on a computer with 640k of RAM. > > Owen > >> >> -mel >> >>> On Jul 10, 2015, at 9:55 PM, Owen DeLong wrote: >>> >>> How can it be a large, complex deployment if it?s greenfield. >>> >>> In that case, you need to acceptance test the IPv4 just as much as IPv6. >>> >>> The difference is that you don?t have to rerun your acceptance tests 6-months later when you have to implement IPv6 in a rush because you suddenly learned that your major client gets major suckage on IPv4 due to their provider having put them behind the worst CGN on the planet. >>> >>> Owen >>> >>>> On Jul 10, 2015, at 15:08 , Mel Beckman wrote: >>>> >>>> There is most certainly a cost to IPv6, especially in a large, complex deployment, where everything requires acceptance testing. And I'm sure you realize that IPv6 only is not an option. I agree that it would have been worth the cost, which would have been just a small fraction of the total. The powers that be chose not to incur it now. But we did deploy only IPv6 gear and systems, so it can probably be turned up later for that same incremental cost. >>>> >>>> -mel via cell >>>> >>>>> On Jul 10, 2015, at 3:03 PM, Mark Andrews wrote: >>>>> >>>>> >>>>> In message , Mel Beckman writ >>>>> es: >>>>>> Limited municipal budgets is all I can say. IPv6 has a cost, and if they >>>>>> can put it off till later then that's often good politics. >>>>>> >>>>>> -mel via cell >>>>> >>>>> IPv4 has a cost as well. May as well just go IPv6-only from day one and >>>>> not pay the IPv4 tax at all. >>>>> >>>>> The cost difference between providing IPv6 + IPv4 or just IPv4 from >>>>> day 1 should be zero. There should be no re-tooling. You just >>>>> select products that support both initially. It's not like products >>>>> that support both are more expensive all other things being equal. >>>>> >>>>> Mark >>>>> >>>>>>> On Jul 10, 2015, at 2:42 PM, Mark Andrews wrote: >>>>>>> >>>>>>> >>>>>>> In message >>>>>> >>>>>>> , Christopher Morrow writes: >>>>>>>>> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman wrote: >>>>>>>>> I working on a large airport WiFi deployment right now. IPv6 is >>>>>> "allowed = >>>>>>>> for in the future" but not configured in the short term. With less >>>>>> than 10,= >>>>>>>> 000 ephemeral users, we don't expect users to demand IPv6 until most >>>>>> mobile= >>>>>>>> devices and apps come ready to use IPv6 by default. >>>>>>>> >>>>>>>> 'we don't expect users to demand ipv6' >>>>>>>> >>>>>>>> aside from #nanog folks, who 'demands' ipv6? >>>>>>>> >>>>>>>> Don't they actually 'demand' "access to content on the internet" ? >>>>>>>> >>>>>>>> Since you seem to have a greenfield deployment, why NOT just put v6 in >>>>>>>> place on day0? retrofitting it is surely going to cost time/materials >>>>>>>> and probably upgrades to gear that could be avoided by doing it in the >>>>>>>> initial installation, right? >>>>>>> >>>>>>> +1 and you will most probably see about 50% of the traffic being IPv6 if >>>>>>> you do so. There is lots of IPv6 capable equipment out there just >>>>>> waiting >>>>>>> to see a RA. >>>>>>> >>>>>>> Mark >>>>>>> -- >>>>>>> Mark Andrews, ISC >>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>>>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >>>>> >>>>> -- >>>>> Mark Andrews, ISC >>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From ramy.ihashish at gmail.com Sat Jul 11 08:17:31 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Sat, 11 Jul 2015 11:17:31 +0300 Subject: NANOG Digest, Vol 90, Issue 9 In-Reply-To: References: Message-ID: This is not what you were asking about in your original post on this topic - you were talking about BGP sessions inside GRE tunnels, which is not how most (any?) DDoS mitigation services operate, to my knowledge. GRE is used over the Internet for many different applications, including post-DDoS-mitigation re-injection of legitimate traffic onwards to the server/services under protection. Hardware-based GRE processing is required on both ends for anything other than trivial speeds; in general, the day of software-based Internet routers is long gone, and any organization still running software-based routers on their transit/peering edge is at risk. DDoS mitigation providers using GRE for re-injection should set the MTU on their mitigation center diversion interfaces to 1476, and MSS-clamping on those same interfaces to 1436, as a matter of course. This is not a new model; it has been extant for many years. There are a variety of overlay and transit-focused DDoS mitigation service providers who utilize this model. In your original post on this topic, you also made the assertion that these issues had not been addressed by DDoS mitigation service operators; that assertion is incorrect. Hello Roland, You are still missing the main point, the main question is what Dennis highlighted "Perf implications when cloud security providers time to > detect/mitigate is X minutes. How stable can GRE transports and BGP > sessions be when under load?" I mean, during the X minutes (between detection and mitigation), the scrubbing center will be sending both legitimate and illegitimate traffic to the customer, and here is the exact period I am worried about the GRE control traffic -which will be much more vulnerable to be dropped than the relaxed three minutes of BGP hold time. All of the top 5 DDoS cloud scrubbing centers are using BGP over GRE, and even if the BGP is only used for signalling the victim subnet, the GRE control traffic will still suffer from the congestion during the X time. Thank you for your clarification about the MTU consideration and GRE HW acceleration. Ramy From rdobbins at arbor.net Sat Jul 11 09:45:23 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 11 Jul 2015 16:45:23 +0700 Subject: NANOG Digest, Vol 90, Issue 9 In-Reply-To: References: Message-ID: On 11 Jul 2015, at 15:17, Ramy Hashish wrote: > I mean, during the X minutes (between detection and mitigation), the > scrubbing center will be sending both legitimate and illegitimate > traffic > to the customer Your assumption that there is a delay between diversion and mitigation is not a valid one for any cloud DDoS mitigation service provider of which I'm aware. ----------------------------------- Roland Dobbins From baldur.norddahl at gmail.com Sat Jul 11 10:12:00 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 11 Jul 2015 12:12:00 +0200 Subject: ISP DHCPv6 and /48 In-Reply-To: <4ADDCF6E-7D60-404D-8669-ED6B2B7362E4@istaff.org> References: <20150710100902.5292D32ACBDE@rock.dv.isc.org> <4ADDCF6E-7D60-404D-8669-ED6B2B7362E4@istaff.org> Message-ID: On 10 July 2015 at 13:30, John Curran wrote: > Baldur - > > I am not aware of the RIPE practices with respect to IPv6 end-user > assignments, > but in the ARIN region, ISPs/LIR's make assignments to end users based > on similar > practices that the community adopted for ARIN?s end-user assignments. > To my > knowledge, ARIN does not review these ISP IPv6 end-user assignments > (except > after the fact and in aggregate if an ISP were to come to ARIN seeking > an additional > IPv6 block due to utilization of the previous.) > > Differences in policies between the regions is not necessarily any > indication of a > ?problem?; it can just as easily be an appropriate reflection of > different underlying > circumstances. > > The RIPE policy https://www.ripe.net/publications/docs/ripe-641 section 5.4.2 states: "When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level". For a business user we might go through that process. But my question is about ordinary residential end users where we want to have as little manual processing as possible. Therefore we read the above as "do not do that". We do not entirely disagree with the policy either. I am more looking for a technical solution, that allows us to deliver a /48 yet still be as flexible as possible to the users wants and needs. Regards, Baldur From baldur.norddahl at gmail.com Sat Jul 11 10:55:45 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 11 Jul 2015 12:55:45 +0200 Subject: ISP DHCPv6 and /48 In-Reply-To: References: <20150710100902.5292D32ACBDE@rock.dv.isc.org> Message-ID: On 10 July 2015 at 15:21, George, Wes wrote: > On 7/10/15, 6:34 AM, "NANOG on behalf of Baldur Norddahl" > wrote: > > > >Perhaps the problem is that DHCPv6-PD is not intelligent enough. Yes there > >is a provision such that the user CPE could give a hint of how much space > >is want, but no, it doesn't work. > WG] Sorry, [citation needed]. We are using DHCPv6-PD that listens for and > responds properly to hints in production for millions of customers. Thank you for your insight. I went back and checked if I overlooked something. I managed to make a sample of 136 unique CPEs (not unique models, just unique devices). The sample was chosen so none of those had been previously provisioned with IPv6. Zero of them provided hints. It will look like this: (IA_PD IAID:1 T1:0 T2:0) or (IA_PD IAID:660514110 T1:3600 T2:5400) The values differ but none include hints. CPEs that have previously been configured will provide hints, but that is just our own prefix length that is returned back. Eg.: (IA_PD IAID:1 T1:300 T2:600 (IA_PD-prefix 2a00:7660:8ca::/48 pltime:600 vltime:600)) You wouldn't blame the protocol when IPv6 doesn't work for your customers > who use a device that doesn't support IPv6, would you? > No but I believe the RFCs lack useful directions in how CPEs and DHCP servers should use hints. My sample shows that the popular CPEs used by our users simply do not even attempt to use this mechanism. > > >The user CPE does not understand this > >issue either and has no information that could make it the smart place to > >do the decision. Plus which of the multiple CPEs would be in control? > WG] IETF Homenet WG is currently chewing on the problem of multiple CPEs > in an unmanaged environment. It's not an easy problem if you have to > design it so that it works automagically no matter how strangely it's > connected together. You may want to check it out: > http://datatracker.ietf.org/wg/homenet/charter/ > > Thank you for the link. It is good to see that someone is working on the issue. > > > >Maybe if the CPEs would go back and ask for more address space, if what > >they initially got ran out. But DHCPv6-PD does not really have a way to do > >that. In any case no CPE implements any such thing. > > WG] also not exactly true. No, most CPE won't do it automatically, but > DHCPv6 can do it. Release existing prefix, request new prefix with bigger > hint. Depending on DHCP server policy, you might even be able to do it in > the opposite order (make before break) since you can have multiple > prefixes. My hunch is that on most residential broadband setups, it's not > likely to be hitless, and most cheap plastic routers can probably only do > it via a reboot after you reconfigure it to ask for more space in the > hint, but it's doable. See above recommendation for homenet if you want it > to be automatic. > > Actually DHCPv6 does not allow you to request additional prefixes. Section 12.2 from RFC 3633: " A delegating router examines the prefix(es) identified in IA_PD Prefix options (in an IA_PD option) in Renew and Rebind messages and responds according to the current status of the prefix(es). The delegating router returns IA_PD Prefix options (within an IA_PD option) with updated lifetimes for each valid prefix in the message from the requesting router. * If the delegating router finds that any* * of the prefixes are not in the requesting router's binding entry, the* * delegating router returns the prefix to the requesting router with* * lifetimes of 0.* " If you attempt that, you will just get the prefix back with lifetime zero. So the only way is to release the binding and start over. That does not feel like a real solution and is also not anything likely implemented. I am looking for solutions that I can implement today. It appears the right thing to do is to take 4 bits from the user and use at the ISP level. He is still getting his /48 allocation, but we used 4 bits for the first layer of delegating routers. He will see this as multiple sequential /52 delegations. 95% of the users will only connect one CPE and will only be able to use /52 worth of space. But really, we have not seen any actual use case presented where this is a problem. I believe we will be providing a better service by delivering /52 by default and then allow multiple DHCP bindings, than to do a single /48 and refuse multiple bindings. We could implement respecting /48 hints from a CPE, such that a user can override the /52 default behavior by asking his CPE to request a /48. It is just that my sample indicates that most CPEs may not have this option. Regards, Baldur From joelja at bogus.com Sat Jul 11 20:11:29 2015 From: joelja at bogus.com (joel jaeggli) Date: Sat, 11 Jul 2015 13:11:29 -0700 Subject: AW: Level3 routing issue US west coast In-Reply-To: <11cd4154ae384babbdd11b5df252ee1f@anx-i-dag02.anx.local> References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> <11cd4154ae384babbdd11b5df252ee1f@anx-i-dag02.anx.local> Message-ID: <55A17871.4060501@bogus.com> On 7/10/15 7:54 AM, J?rgen Jaritsch wrote: > Wow .... Level3 responded to me that they had an issue last night .... but they simply did nothing ... for at least 10 hours they did nothing to fix the issue: It's more likely that there's a certain amount of nonsense and a lot of loose ends in the ticketing system; than that the issue resolved itself without intervention. You might reasonably conclude that the corrective action and the ticket are unrelated at least as far as the noc is concerned. > ### > > Event Case ID: 9446216 > Location: Los Angeles, CA > Impacted For: 10 hours 52 minutes > ETR: Unknown > Bridge: N/A > > > 08:52 GMT - Event Conclusion Summary > > Start Time: 07/09 19:48 GMT > Stop Time: 07/10 06:40 GMT > > Root Cause: A packet loss issue in Los Angeles, CA. > > Fix Action: The packet loss issue resolved before any action was taken. > Summary: The IP NOC is currently investigated a packet loss issue in Los Angeles, CA that was impacting IP services. The packet loss issue resolved before any action was taken and the IP NOC deemed services are stable after monitoring was concluded. > > 07:53 GMT - The IP NOC is currently monitoring services after the packet loss issue resolved before any action was taken. An update will be sent when traffic is deemed stable or if status changes. > > 06:43 GMT - The IP NOC is currently investigating a packet loss issue in Los Angeles, CA that is impacting IP services. Troubleshooting efforts are ongoing with no estimated time to restore services available at this point. Please be advised that updates for this event will be relayed hourly unless otherwise noted. > > ### > > > best regards > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > > -----Urspr?ngliche Nachricht----- > Von: J?rgen Jaritsch > Gesendet: Freitag, 10. Juli 2015 15:47 > An: 'Ca By'; Joseph Jenkins > Cc: nanog at nanog.org > Betreff: AW: Level3 routing issue US west coast > > Hi, > > sitting here and watching the packet loss coming and going :(. > > It changes every 10-25min. Looks like an massive issue in San Jose - routers out there sometimes have an latency from 5-6 SECONDS ... > > best regards > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > > -----Urspr?ngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Ca By > Gesendet: Freitag, 10. Juli 2015 15:42 > An: Joseph Jenkins > Cc: nanog at nanog.org > Betreff: Re: Level3 routing issue US west coast > > On Friday, July 10, 2015, Joseph Jenkins wrote: > >> Level3 had an issue with one of their core routers in Los Angeles last >> night(7pm Pacific) and early this morning(1am Pacific). Last update to my >> trouble ticket had the issue still being reviewed by engineering, but that >> a core router was dropping packets. >> >> > I have seen this several times with level3. They confirm packets are > dropping and sevice is degraded yet they refuse to take tactical corrective > action for hours and hours. > > Makes me furious. > > CB > > >>> On Jul 10, 2015, at 3:59 AM, J?rgen Jaritsch > > wrote: >>> >>> Hi, >>> >>> does anyone else experience issues with the Level3 network at the US >> west coast? We see lots of broken paths like this: >>> >>> Packets >> Pings >>> Host Loss% Snt Last >> Avg Best Wrst StDev >>> 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 231 0.6 >> 0.5 0.2 18.1 1.2 >>> 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 231 0.5 >> 9.9 0.3 361.1 40.1 >>> 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 230 6.5 >> 7.7 6.3 49.7 5.3 >>> 4. win-b4-link.telia.net 0.0% 230 6.6 >> 6.8 6.4 20.2 1.5 >>> 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 230 6.6 >> 9.3 6.3 69.1 9.6 >>> 6. ae-2-70.edge1.SanJose3.Level3.net 38.4% 230 164.8 >> 165.0 164.5 194.9 2.6 >>> 7. ae-2-70.edge1.SanJose3.Level3.net 45.9% 230 164.7 >> 164.8 164.5 174.1 0.9 >>> 8. 4.53.208.102 34.3% 230 634.9 >> 310.7 168.5 680.1 199.7 >>> 9. TenGE5-4.br01.seo01.pccwbtn.net 34.1% 230 412.0 >> 455.2 304.9 954.6 203.4 >>> 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 40.6% 230 323.4 >> 441.4 323.1 822.0 182.1 >>> 11. 211.115.201.92 38.4% 230 289.8 >> 412.9 289.6 846.7 185.4 >>> 12. 61.250.89.2 35.8% 230 290.6 >> 439.4 290.2 804.3 205.1 >>> 13. ??? >>> >>> Trace from NYC is also broken: >>> >>> Packets >> Pings >>> Host Loss% Snt >> Last Avg Best Wrst StDev >>> 1. cr-01.0v-00-05.anx32.nyc.us.anexia-it.com 0.0% 30 >> 0.4 4.3 0.4 57.8 13.3 >>> 2. nyk-b5-link.telia.net 0.0% 30 >> 0.3 0.4 0.3 0.9 0.1 >>> 3. ??? >>> 4. ae-3-80.edge1.SanJose3.Level3.net 17.2% 30 >> 71.7 73.2 71.7 98.7 5.5 >>> 5. ae-3-80.edge1.SanJose3.Level3.net 0.0% 30 >> 71.8 71.8 71.7 72.0 0.1 >>> 6. 4.53.208.102 31.0% 30 >> 569.6 250.7 70.5 579.3 231.2 >>> 7. 63.218.250.73 31.0% 30 >> 672.6 355.5 178.0 672.6 232.1 >>> >>> >>> At 10:24 UTC+2 it was even more broken: >>> >>> Packets >> Pings >>> Host Loss% Snt Last >> Avg Best Wrst StDev >>> 1. er-01.0v-00-03.anx01.klu.at.anexia-it.com 0.0% 326 0.4 >> 0.5 0.3 39.7 2.2 >>> 2. cr-01.0v-08-06.anx01.klu.at.anexia-it.com 0.0% 326 0.5 >> 6.7 0.3 198.1 26.3 >>> 3. cr-04.01-01-04.anx03.vie.at.anexia-it.com 0.0% 326 6.6 >> 7.6 6.4 43.6 4.5 >>> 4. win-b4-link.telia.net 0.0% 326 6.7 >> 7.4 6.3 43.1 3.2 >>> 5. level-ic-1573273-wien-b4.c.telia.net 0.0% 326 6.9 >> 9.2 6.3 73.2 10.1 >>> 6. ae-1-60.edge5.LosAngeles1.Level3.net 62.6% 326 164.7 >> 165.5 164.5 176.7 1.5 >>> ae-2-70.edge1.SanJose3.Level3.net >>> 7. ae-1-60.edge5.LosAngeles1.Level3.net 63.1% 326 164.8 >> 165.8 164.6 204.2 3.9 >>> ae-2-70.edge1.SanJose3.Level3.net >>> 8. 205.129.5.70 74.2% 326 799.9 >> 487.2 169.0 799.9 305.7 >>> 4.53.208.102 >>> 9. TenGE5-4.br01.seo01.pccwbtn.net 77.2% 326 1359. >> 701.0 308.7 3716. 510.6 >>> 10. sejong-telecom.ge5-3.br01.seo01.pccwbtn.net 75.1% 326 960.4 >> 643.0 323.4 960.4 307.6 >>> 11. 211.115.201.92 68.9% 326 925.3 >> 674.2 289.8 932.3 296.6 >>> 12. 61.250.89.2 72.9% 326 928.5 >> 637.2 291.9 928.5 304.3 >>> 13. ??? >>> >>> >>> best regards >>> >>> J?rgen Jaritsch >>> Head of Network & Infrastructure >>> >>> ANEXIA Internetdienstleistungs GmbH >>> >>> Telefon: +43-5-0556-300 >>> Telefax: +43-5-0556-500 >>> >>> E-Mail: jj at anexia.at > >>> Web: http://www.anexia.at >>> >>> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >>> Gesch?ftsf?hrer: Alexander Windbichler >>> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT >> U63216601 >>> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From mr.npp at nopatentpending.com Fri Jul 10 18:05:37 2015 From: mr.npp at nopatentpending.com (Mr. NPP) Date: Fri, 10 Jul 2015 11:05:37 -0700 Subject: Level3 routing issue US west coast In-Reply-To: References: <5aea0a23de084d508d02aa46e4a08513@anx-i-dag02.anx.local> <3F419656-849B-4D64-A5F1-5E081C91E2C5@breathe-underwater.com> <11cd4154ae384babbdd11b5df252ee1f@anx-i-dag02.anx.local> <005d01d0bb23$6475de00$2d619a00$@bofh.de> Message-ID: We took them down yesterday, and attempted to bring them back up midnight PST, and still massive packet loss. so they remain down for now. On Fri, Jul 10, 2015 at 9:44 AM, J?rgen Jaritsch wrote: > Hi, > > No SLA broken cause A- and B-End were not directly our circuits ... but it > helps a lot to place some new orders ... at other partners :). > > > best regards > > J?rgen Jaritsch > > > -----Urspr?ngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Jens Hoffmann > Gesendet: Freitag, 10. Juli 2015 17:16 > An: nanog at nanog.org > Betreff: AW: Level3 routing issue US west coast > > Hi, > > >Wow .... Level3 responded to me that they had an issue last night .... > but they simply did nothing ... for at least 10 hours they >did nothing to > fix the issue: > > Any SLA broken? Probably not, that would be a reason to move. > > Kind regards, > Jens > > From stenn at nwtime.org Fri Jul 10 20:30:15 2015 From: stenn at nwtime.org (Harlan Stenn) Date: Fri, 10 Jul 2015 13:30:15 -0700 Subject: NTP versions in production use? In-Reply-To: <55A01D04.6080003@nwtime.org> References: <55A01D04.6080003@nwtime.org> Message-ID: <55A02B57.1010404@nwtime.org> Resending... On 7/10/15 12:29 PM, Harlan Stenn wrote: > I'm trying to build a list of the versions of NTP that are in active use > on various active pieces of network gear. > > I know that Cisco, for example, uses NTP in around 10 different product > lines, but I don't know what versions of NTP are in current use. > > I'm also curious about the answers here for Juniper and other network > gear providers. That would include routers, switches, and other types > of gear. > > If you have information about this I'd appreciate your letting me know. > -- Harlan Stenn http://networktimefoundation.org - be a member! From marka at isc.org Sat Jul 11 23:05:53 2015 From: marka at isc.org (Mark Andrews) Date: Sun, 12 Jul 2015 09:05:53 +1000 Subject: ISP DHCPv6 and /48 In-Reply-To: Your message of "Sat, 11 Jul 2015 12:12:00 +0200." References: <20150710100902.5292D32ACBDE@rock.dv.isc.org> <4ADDCF6E-7D60-404D-8669-ED6B2B7362E4@istaff.org> Message-ID: <20150711230553.35C7332BBE7F@rock.dv.isc.org> In message , Baldur Norddahl writes: > On 10 July 2015 at 13:30, John Curran wrote: > > > Baldur - > > > > I am not aware of the RIPE practices with respect to IPv6 end-user > > assignments, > > but in the ARIN region, ISPs/LIR's make assignments to end users base= > d > > on similar > > practices that the community adopted for ARIN=E2=80=99s end-user assi= > gnments. > > To my > > knowledge, ARIN does not review these ISP IPv6 end-user assignments > > (except > > after the fact and in aggregate if an ISP were to come to ARIN seekin= > g > > an additional > > IPv6 block due to utilization of the previous.) > > > > Differences in policies between the regions is not necessarily any > > indication of a > > =E2=80=9Cproblem=E2=80=9D; it can just as easily be an appropriate re= > flection of > > different underlying > > circumstances. > > > > > > The RIPE policy https://www.ripe.net/publications/docs/ripe-641 section > 5.4.2 states: > > "When a single End Site requires an assignment shorter than a /48, it must > request the assignment with documentation or materials that justify the > request. Requests for multiple or additional prefixes exceeding a /48 > assignment for a single End Site will be processed and reviewed (i.e., > evaluation of justification) at the RIR/NIR level". > > For a business user we might go through that process. But my question is > about ordinary residential end users where we want to have as little manual > processing as possible. Therefore we read the above as "do not do that". > > We do not entirely disagree with the policy either. I am more looking for a > technical solution, that allows us to deliver a /48 yet still be as > flexible as possible to the users wants and needs. > > Regards, > > Baldur Well you don't know if it is a single end site or two sharing a common uplink. You could just configure them both for /49's from the /48 and let them worry about ip6.arpa sub delegation. They should be getting a /128 regardless. That said this really isn't your problem. It is their problem. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From oliver.oboyle at gmail.com Sun Jul 12 00:17:13 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Sat, 11 Jul 2015 20:17:13 -0400 Subject: ISP DHCPv6 and /48 In-Reply-To: <20150711230553.35C7332BBE7F@rock.dv.isc.org> References: <20150710100902.5292D32ACBDE@rock.dv.isc.org> <4ADDCF6E-7D60-404D-8669-ED6B2B7362E4@istaff.org> <20150711230553.35C7332BBE7F@rock.dv.isc.org> Message-ID: > > > >That said this really isn't your problem. It is their problem. Marc, Your response surprises me a bit. I wish more ISP would consider their customer's use cases more thoroughly and aim to address them as best as possible. Regional differences in expectations are reasonable and provide a good pool of use cases to examine. Agreed there are a number of ways to resolve this issue and address the use case, however. Oliver > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- :o@> From dovid at telecurve.com Sun Jul 12 02:58:19 2015 From: dovid at telecurve.com (Dovid Bender) Date: Sat, 11 Jul 2015 22:58:19 -0400 Subject: NTP versions in production use? In-Reply-To: <55A02B57.1010404@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> Message-ID: Juniper MX5 root at YYY.XXXXXX.net> show ntp status status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg, version="ntpd 4.2.0-a Thu Mar 13 08:29:55 UTC 2014 (1)", processor="powerpc", system="JUNOS12.3R6.6", leap=00, stratum=3, precision=-18, rootdelay=90.375, rootdispersion=20.620, peer=29748, refid=208.75.88.4, reftime=d94c5338.ac6565a8 Sat, Jul 11 2015 22:45:12.673, poll=7, clock=d94c55ad.b634aa52 Sat, Jul 11 2015 22:55:41.711, state=4, offset=-0.428, frequency=2.394, jitter=3.505, stability=0.004 Juniper EX4200: root at YYYY> show ntp status status=c011 sync_alarm, sync_unspec, 1 event, event_restart, version="ntpd 4.2.0-a Sat Jan 5 18:41:34 UTC 2013 (1)", processor="powerpc", system="JUNOS11.4R6.6", leap=11, stratum=16, precision=-18, rootdelay=0.000, rootdispersion=656381.655, peer=0, refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 1:28:16.000, poll=4, clock=d94c5a40.fa58e5f0 Sat, Jul 11 2015 23:15:12.977, state=0, offset=0.000, frequency=0.000, jitter=0.004, stability=0.000 On Fri, Jul 10, 2015 at 4:30 PM, Harlan Stenn wrote: > Resending... > > On 7/10/15 12:29 PM, Harlan Stenn wrote: > > I'm trying to build a list of the versions of NTP that are in active use > > on various active pieces of network gear. > > > > I know that Cisco, for example, uses NTP in around 10 different product > > lines, but I don't know what versions of NTP are in current use. > > > > I'm also curious about the answers here for Juniper and other network > > gear providers. That would include routers, switches, and other types > > of gear. > > > > If you have information about this I'd appreciate your letting me know. > > > > -- > Harlan Stenn > http://networktimefoundation.org - be a member! > > From stenn at nwtime.org Sun Jul 12 03:17:37 2015 From: stenn at nwtime.org (Harlan Stenn) Date: Sat, 11 Jul 2015 20:17:37 -0700 Subject: NTP versions in production use? In-Reply-To: References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> Message-ID: <55A1DC51.4080101@nwtime.org> Dovid, Thanks, and I'm kinda stunned that folks are running such ancient versions of NTP. https://support.ntp.org/bin/view/Dev/ReleaseTimeline 4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in the codebase since then. H On 7/11/15 7:58 PM, Dovid Bender wrote: > Juniper MX5 > root at YYY.XXXXXX.net> show ntp status > status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg, > version="ntpd 4.2.0-a Thu Mar 13 08:29:55 UTC 2014 (1)", > processor="powerpc", system="JUNOS12.3R6.6", leap=00, stratum=3, > precision=-18, rootdelay=90.375, rootdispersion=20.620, peer=29748, > refid=208.75.88.4, > reftime=d94c5338.ac6565a8 Sat, Jul 11 2015 22:45:12.673, poll=7, > clock=d94c55ad.b634aa52 Sat, Jul 11 2015 22:55:41.711, state=4, > offset=-0.428, frequency=2.394, jitter=3.505, stability=0.004 > > Juniper EX4200: > root at YYYY> show ntp status > status=c011 sync_alarm, sync_unspec, 1 event, event_restart, > version="ntpd 4.2.0-a Sat Jan 5 18:41:34 UTC 2013 (1)", > processor="powerpc", system="JUNOS11.4R6.6", leap=11, stratum=16, > precision=-18, rootdelay=0.000, rootdispersion=656381.655, peer=0, > refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 1:28:16.000, > poll=4, clock=d94c5a40.fa58e5f0 Sat, Jul 11 2015 23:15:12.977, state=0, > offset=0.000, frequency=0.000, jitter=0.004, stability=0.000 > > > On Fri, Jul 10, 2015 at 4:30 PM, Harlan Stenn wrote: > >> Resending... >> >> On 7/10/15 12:29 PM, Harlan Stenn wrote: >>> I'm trying to build a list of the versions of NTP that are in active use >>> on various active pieces of network gear. >>> >>> I know that Cisco, for example, uses NTP in around 10 different product >>> lines, but I don't know what versions of NTP are in current use. >>> >>> I'm also curious about the answers here for Juniper and other network >>> gear providers. That would include routers, switches, and other types >>> of gear. >>> >>> If you have information about this I'd appreciate your letting me know. >>> >> >> -- >> Harlan Stenn >> http://networktimefoundation.org - be a member! >> >> > -- Harlan Stenn http://networktimefoundation.org - be a member! From dovid at telecurve.com Sun Jul 12 03:21:11 2015 From: dovid at telecurve.com (Dovid Bender) Date: Sat, 11 Jul 2015 23:21:11 -0400 Subject: NTP versions in production use? In-Reply-To: <55A1DC51.4080101@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> Message-ID: You would need to ask Juniper that.... On Sat, Jul 11, 2015 at 11:17 PM, Harlan Stenn wrote: > Dovid, > > Thanks, and I'm kinda stunned that folks are running such ancient > versions of NTP. > > https://support.ntp.org/bin/view/Dev/ReleaseTimeline > > 4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in > the codebase since then. > > H > > On 7/11/15 7:58 PM, Dovid Bender wrote: > > Juniper MX5 > > root at YYY.XXXXXX.net> show ntp status > > status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg, > > version="ntpd 4.2.0-a Thu Mar 13 08:29:55 UTC 2014 (1)", > > processor="powerpc", system="JUNOS12.3R6.6", leap=00, stratum=3, > > precision=-18, rootdelay=90.375, rootdispersion=20.620, peer=29748, > > refid=208.75.88.4, > > reftime=d94c5338.ac6565a8 Sat, Jul 11 2015 22:45:12.673, poll=7, > > clock=d94c55ad.b634aa52 Sat, Jul 11 2015 22:55:41.711, state=4, > > offset=-0.428, frequency=2.394, jitter=3.505, stability=0.004 > > > > Juniper EX4200: > > root at YYYY> show ntp status > > status=c011 sync_alarm, sync_unspec, 1 event, event_restart, > > version="ntpd 4.2.0-a Sat Jan 5 18:41:34 UTC 2013 (1)", > > processor="powerpc", system="JUNOS11.4R6.6", leap=11, stratum=16, > > precision=-18, rootdelay=0.000, rootdispersion=656381.655, peer=0, > > refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 1:28:16.000, > > poll=4, clock=d94c5a40.fa58e5f0 Sat, Jul 11 2015 23:15:12.977, state=0, > > offset=0.000, frequency=0.000, jitter=0.004, stability=0.000 > > > > > > On Fri, Jul 10, 2015 at 4:30 PM, Harlan Stenn wrote: > > > >> Resending... > >> > >> On 7/10/15 12:29 PM, Harlan Stenn wrote: > >>> I'm trying to build a list of the versions of NTP that are in active > use > >>> on various active pieces of network gear. > >>> > >>> I know that Cisco, for example, uses NTP in around 10 different product > >>> lines, but I don't know what versions of NTP are in current use. > >>> > >>> I'm also curious about the answers here for Juniper and other network > >>> gear providers. That would include routers, switches, and other types > >>> of gear. > >>> > >>> If you have information about this I'd appreciate your letting me know. > >>> > >> > >> -- > >> Harlan Stenn > >> http://networktimefoundation.org - be a member! > >> > >> > > > > -- > Harlan Stenn > http://networktimefoundation.org - be a member! > > From stenn at nwtime.org Sun Jul 12 03:24:06 2015 From: stenn at nwtime.org (Harlan Stenn) Date: Sat, 11 Jul 2015 20:24:06 -0700 Subject: NTP versions in production use? In-Reply-To: References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> Message-ID: <55A1DDD6.8050404@nwtime.org> We will. But we're going to be asking them for support for network time. Folks like you are probably paying them for support. They'll listen more to people like you. This goes to *all* vendors who embed NTP in their products, we're not interested in in picking on anybody here. H -- On 7/11/15 8:21 PM, Dovid Bender wrote: > You would need to ask Juniper that.... > > > On Sat, Jul 11, 2015 at 11:17 PM, Harlan Stenn wrote: > >> Dovid, >> >> Thanks, and I'm kinda stunned that folks are running such ancient >> versions of NTP. >> >> https://support.ntp.org/bin/view/Dev/ReleaseTimeline >> >> 4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in >> the codebase since then. >> >> H >> >> On 7/11/15 7:58 PM, Dovid Bender wrote: >>> Juniper MX5 >>> root at YYY.XXXXXX.net> show ntp status >>> status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg, >>> version="ntpd 4.2.0-a Thu Mar 13 08:29:55 UTC 2014 (1)", >>> processor="powerpc", system="JUNOS12.3R6.6", leap=00, stratum=3, >>> precision=-18, rootdelay=90.375, rootdispersion=20.620, peer=29748, >>> refid=208.75.88.4, >>> reftime=d94c5338.ac6565a8 Sat, Jul 11 2015 22:45:12.673, poll=7, >>> clock=d94c55ad.b634aa52 Sat, Jul 11 2015 22:55:41.711, state=4, >>> offset=-0.428, frequency=2.394, jitter=3.505, stability=0.004 >>> >>> Juniper EX4200: >>> root at YYYY> show ntp status >>> status=c011 sync_alarm, sync_unspec, 1 event, event_restart, >>> version="ntpd 4.2.0-a Sat Jan 5 18:41:34 UTC 2013 (1)", >>> processor="powerpc", system="JUNOS11.4R6.6", leap=11, stratum=16, >>> precision=-18, rootdelay=0.000, rootdispersion=656381.655, peer=0, >>> refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 1:28:16.000, >>> poll=4, clock=d94c5a40.fa58e5f0 Sat, Jul 11 2015 23:15:12.977, state=0, >>> offset=0.000, frequency=0.000, jitter=0.004, stability=0.000 >>> >>> >>> On Fri, Jul 10, 2015 at 4:30 PM, Harlan Stenn wrote: >>> >>>> Resending... >>>> >>>> On 7/10/15 12:29 PM, Harlan Stenn wrote: >>>>> I'm trying to build a list of the versions of NTP that are in active >> use >>>>> on various active pieces of network gear. >>>>> >>>>> I know that Cisco, for example, uses NTP in around 10 different product >>>>> lines, but I don't know what versions of NTP are in current use. >>>>> >>>>> I'm also curious about the answers here for Juniper and other network >>>>> gear providers. That would include routers, switches, and other types >>>>> of gear. >>>>> >>>>> If you have information about this I'd appreciate your letting me know. >>>>> >>>> >>>> -- >>>> Harlan Stenn >>>> http://networktimefoundation.org - be a member! >>>> >>>> >>> >> >> -- >> Harlan Stenn >> http://networktimefoundation.org - be a member! >> >> > -- Harlan Stenn http://networktimefoundation.org - be a member! From nanog at studio442.com.au Sun Jul 12 04:10:14 2015 From: nanog at studio442.com.au (Julien Goodwin) Date: Sun, 12 Jul 2015 14:10:14 +1000 Subject: NTP versions in production use? In-Reply-To: <55A1DC51.4080101@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> Message-ID: <55A1E8A6.2070707@studio442.com.au> On 12/07/15 13:17, Harlan Stenn wrote: > Dovid, > > Thanks, and I'm kinda stunned that folks are running such ancient > versions of NTP. > > https://support.ntp.org/bin/view/Dev/ReleaseTimeline > > 4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in > the codebase since then. Juniper have recently (15.1, still not out for all platforms) rebased JunOS on a slightly less ancient FreeBSD release, and nothing I have in my lab has it released yet, and I can't be bothered to go spelunking in the install image for what version of NTP it's running. From stenn at ntp.org Sun Jul 12 04:14:46 2015 From: stenn at ntp.org (Harlan Stenn) Date: Sun, 12 Jul 2015 04:14:46 +0000 Subject: NTP versions in production use? In-Reply-To: <55A1DDD6.8050404@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> <55A1DDD6.8050404@nwtime.org> Message-ID: Harlan Stenn writes: > We will. But we're going to be asking them for support for network > time. Folks like you are probably paying them for support. They'll > listen more to people like you. > > This goes to *all* vendors who embed NTP in their products, we're not > interested in in picking on anybody here. Network Time doesn't *only* need support from network equipment providers. If accurate time is important to you, or you and your customers, please pitch in. I've probably strayed offtopic here. Sorry about that. But help us anyway. H -- > -- > On 7/11/15 8:21 PM, Dovid Bender wrote: > > You would need to ask Juniper that.... > > > > > > On Sat, Jul 11, 2015 at 11:17 PM, Harlan Stenn wrote: > > > >> Dovid, > >> > >> Thanks, and I'm kinda stunned that folks are running such ancient > >> versions of NTP. > >> > >> https://support.ntp.org/bin/view/Dev/ReleaseTimeline > >> > >> 4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in > >> the codebase since then. > >> > >> H > >> > >> On 7/11/15 7:58 PM, Dovid Bender wrote: > >>> Juniper MX5 > >>> root at YYY.XXXXXX.net> show ntp status > >>> status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg, > >>> version="ntpd 4.2.0-a Thu Mar 13 08:29:55 UTC 2014 (1)", > >>> processor="powerpc", system="JUNOS12.3R6.6", leap=00, stratum=3, > >>> precision=-18, rootdelay=90.375, rootdispersion=20.620, peer=29748, > >>> refid=208.75.88.4, > >>> reftime=d94c5338.ac6565a8 Sat, Jul 11 2015 22:45:12.673, poll=7, > >>> clock=d94c55ad.b634aa52 Sat, Jul 11 2015 22:55:41.711, state=4, > >>> offset=-0.428, frequency=2.394, jitter=3.505, stability=0.004 > >>> > >>> Juniper EX4200: > >>> root at YYYY> show ntp status > >>> status=c011 sync_alarm, sync_unspec, 1 event, event_restart, > >>> version="ntpd 4.2.0-a Sat Jan 5 18:41:34 UTC 2013 (1)", > >>> processor="powerpc", system="JUNOS11.4R6.6", leap=11, stratum=16, > >>> precision=-18, rootdelay=0.000, rootdispersion=656381.655, peer=0, > >>> refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 1:28:16.000, > >>> poll=4, clock=d94c5a40.fa58e5f0 Sat, Jul 11 2015 23:15:12.977, state=0, > >>> offset=0.000, frequency=0.000, jitter=0.004, stability=0.000 > >>> > >>> > >>> On Fri, Jul 10, 2015 at 4:30 PM, Harlan Stenn wrote: > >>> > >>>> Resending... > >>>> > >>>> On 7/10/15 12:29 PM, Harlan Stenn wrote: > >>>>> I'm trying to build a list of the versions of NTP that are in active > >> use > >>>>> on various active pieces of network gear. > >>>>> > >>>>> I know that Cisco, for example, uses NTP in around 10 different product > >>>>> lines, but I don't know what versions of NTP are in current use. > >>>>> > >>>>> I'm also curious about the answers here for Juniper and other network > >>>>> gear providers. That would include routers, switches, and other types > >>>>> of gear. > >>>>> > >>>>> If you have information about this I'd appreciate your letting me know. > >>>>> > >>>> > >>>> -- > >>>> Harlan Stenn > >>>> http://networktimefoundation.org - be a member! > >>>> > >>>> > >>> > >> > >> -- > >> Harlan Stenn > >> http://networktimefoundation.org - be a member! > >> > >> > > > > -- > Harlan Stenn > http://networktimefoundation.org - be a member! > > From list at satchell.net Sun Jul 12 04:37:53 2015 From: list at satchell.net (Stephen Satchell) Date: Sat, 11 Jul 2015 21:37:53 -0700 Subject: NTP versions in production use? In-Reply-To: <55A1DC51.4080101@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> Message-ID: <55A1EF21.1070801@satchell.net> On 07/11/2015 08:17 PM, Harlan Stenn wrote: > Thanks, and I'm kinda stunned that folks are running such ancient > versions of NTP. > > https://support.ntp.org/bin/view/Dev/ReleaseTimeline > > 4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in > the codebase since then. I used to do a lot of work with embedded software years ago in my career. What I remember is that when a piece of code was ported to the embedded product, the only time the port was repeated was when there was a revenue-impacting issue. So if there was something in those 3,000 issues that would adversely affect the containing product to the point where it would be reflected in sales, I wouldn't hold your breath. When the porting process is trivial, then it can be a different story. But remember that there is a Q/A impact on incorporating the new code from upstream, so it's the same deal. If you would like the vendors to update, you need to make a strong case for doing so. From colinj at gt86car.org.uk Sun Jul 12 04:40:15 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Sun, 12 Jul 2015 05:40:15 +0100 Subject: NTP versions in production use? In-Reply-To: <55A02B57.1010404@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> Message-ID: <18506C5A-291A-4BA4-8357-0469F36683F0@gt86car.org.uk> ntpd - NTP daemon program - Ver. 4.2.6 Colins-iMac:~ colinj$ uname -a Darwin Colins-iMac.home 15.0.0 Darwin Kernel Version 15.0.0: Sun Jun 28 00:25:56 PDT 2015; root:xnu-3247.1.36~7/RELEASE_X86_64 x86_64 (10.11 osx el capitan) -bash-4.2$ uname -a Linux oraclelinux 3.8.13-68.1.2.el7uek.x86_64 #2 SMP Mon Mar 30 11:45:57 PDT 2015 x86_64 x86_64 x86_64 GNU/Linux ntpd - NTP daemon program - Ver. 4.2.6p5 2015:07:11-01:05:57 cloudsophosvm ntpd[17219]: ntpd 4.2.6p5 at 1.2349 Tue Feb 4 13:03:59 UTC 2014 (1) Sophos UTM 9.313-3 Colin From tore at fud.no Sun Jul 12 06:29:40 2015 From: tore at fud.no (Tore Anderson) Date: Sun, 12 Jul 2015 08:29:40 +0200 Subject: NTP versions in production use? In-Reply-To: <55A1E8A6.2070707@studio442.com.au> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> <55A1E8A6.2070707@studio442.com.au> Message-ID: <20150712082940.6ff9c534@envy.fud.no> * Julien Goodwin > Juniper have recently (15.1, still not out for all platforms) rebased > JunOS on a slightly less ancient FreeBSD release, and nothing I have in > my lab has it released yet, and I can't be bothered to go spelunking in > the install image for what version of NTP it's running. FWIW: root at lab-ex4200:RE:1% ntpq -c rv status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg, version="ntpd 4.2.0-a Fri May 29 07:45:35 2015 (1)", processor="powerpc", system="JUNOS15.1R1.8", leap=00, stratum=3, precision=-18, rootdelay=8.087, rootdispersion=52.195, peer=32436, refid=87.238.33.2, reftime=d94c85fa.7b317b80 Sun, Jul 12 2015 8:21:46.481, poll=10, clock=d94c8669.9b6e8a47 Sun, Jul 12 2015 8:23:37.607, state=4, offset=-1.039, frequency=-32.350, jitter=0.445, stability=0.040 It seems they've pulled the 15.1 release though, at least I can't download it anymore. Tore From mjo at dojo.mi.org Sun Jul 12 14:15:20 2015 From: mjo at dojo.mi.org (Mike O'Connor) Date: Sun, 12 Jul 2015 10:15:20 -0400 Subject: NTP versions in production use? In-Reply-To: <55A1DC51.4080101@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> Message-ID: <20150712141520.GD99711@dojo.mi.org> :Thanks, and I'm kinda stunned that folks are running such ancient :versions of NTP. I suggest you get accustomed to being stunned. :https://support.ntp.org/bin/view/Dev/ReleaseTimeline : :4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in :the codebase since then. 4.2.0 may have been EOL'd in 2006, but it was still shipping as the default in FreeBSD until 2009. Out of those 3000 issues, only a tiny fraction are security-related that would apply to JunOS. I expect that they backport security and other fixes as necessary, until some bigger engineering effort and|or headache calls for a forklift/mass upgrade of things. -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "Fire me, boy!" -The Human Bullet -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From magicsata at gmail.com Sun Jul 12 14:24:58 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Sun, 12 Jul 2015 15:24:58 +0100 Subject: NTP versions in production use? In-Reply-To: <20150712141520.GD99711@dojo.mi.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> <20150712141520.GD99711@dojo.mi.org> Message-ID: I?m currently running a scan of the internet and querying NTP versions. I?ll publish the results of it on Github and mail them in here :) On 12/07/2015 15:15, "NANOG on behalf of Mike O'Connor" wrote: >:Thanks, and I'm kinda stunned that folks are running such ancient >:versions of NTP. > >I suggest you get accustomed to being stunned. > >:https://support.ntp.org/bin/view/Dev/ReleaseTimeline >: >:4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in >:the codebase since then. > >4.2.0 may have been EOL'd in 2006, but it was still shipping as the >default in FreeBSD until 2009. > >Out of those 3000 issues, only a tiny fraction are security-related >that would apply to JunOS. I expect that they backport security and >other fixes as necessary, until some bigger engineering effort and|or >headache calls for a forklift/mass upgrade of things. > > >-- > Michael J. O'Connor mjo at dojo.mi.org > =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= >"Fire me, boy!" -The Human Bullet From mlm at pixelgate.net Sun Jul 12 15:35:42 2015 From: mlm at pixelgate.net (Mark Milhollan) Date: Sun, 12 Jul 2015 08:35:42 -0700 (PDT) Subject: NTP versions in production use? In-Reply-To: <55A1DC51.4080101@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> Message-ID: On Sat, 11 Jul 2015, Harlan Stenn wrote: >I'm kinda stunned that folks are running such ancient >versions of NTP. This is not surprising at all, nor should you be surprised to find xntp3 still in use because of the even older software on decrepit but still functional hardware. I.e., in addition to the issues Stephen Satchell mentioned as to why vendors might not be keeping up, users may have similar needs keeping them from using the latest releases of device software. And then there are those that never even check for updates so long as their device keeps them happy. /mark From D.Lasher at f5.com Sun Jul 12 16:13:20 2015 From: D.Lasher at f5.com (Donn Lasher) Date: Sun, 12 Jul 2015 16:13:20 +0000 Subject: Level3 routing issue US west coast? In-Reply-To: Message-ID: While I can?t say with any degree of certainty it's related, it?s somewhat coincidental that one of one of their west coast customers (Daybreak Games / SOE) has been under a fairly hefty DDoS since mid-week. From what I recall see Daybreak/SOE only uses Level3. (Lots to talk about in that case.. They?ve invaded his life.. Not sure I?d react much better, albeit privately..) http://fortune.com/2015/07/10/john-smedley-vs-hackers/ http://eq2wire.com/2015/07/09/daybreak-ceo-to-convicted-lizard-squad-hacker -im-coming-for-you/ On 7/10/15, 11:05 AM, "Mr. NPP" wrote: >We took them down yesterday, and attempted to bring them back up midnight >PST, and still massive packet loss. so they remain down for now. > >On Fri, Jul 10, 2015 at 9:44 AM, J?rgen Jaritsch wrote: > >> Hi, >> >> No SLA broken cause A- and B-End were not directly our circuits ... but >>it >> helps a lot to place some new orders ... at other partners :). >> >> >> best regards >> >> J?rgen Jaritsch >> >> >> -----Urspr?ngliche Nachricht----- >> Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Jens Hoffmann >> Gesendet: Freitag, 10. Juli 2015 17:16 >> An: nanog at nanog.org >> Betreff: AW: Level3 routing issue US west coast >> >> Hi, >> >> >Wow .... Level3 responded to me that they had an issue last night .... >> but they simply did nothing ... for at least 10 hours they >did nothing >>to >> fix the issue: >> >> Any SLA broken? Probably not, that would be a reason to move. >> >> Kind regards, >> Jens >> >> From baconzombie at gmail.com Sun Jul 12 16:51:15 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Sun, 12 Jul 2015 18:51:15 +0200 Subject: NTP versions in production use? In-Reply-To: References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> <20150712141520.GD99711@dojo.mi.org> Message-ID: Are you using Nmap or masscan? Also I'd be interested in what switches and settings you are using. On 12 Jul 2015 16:26, "Alistair Mackenzie" wrote: > I?m currently running a scan of the internet and querying NTP versions. > > I?ll publish the results of it on Github and mail them in here :) > > > > > On 12/07/2015 15:15, "NANOG on behalf of Mike O'Connor" < > nanog-bounces at nanog.org on behalf of mjo at dojo.mi.org> wrote: > > >:Thanks, and I'm kinda stunned that folks are running such ancient > >:versions of NTP. > > > >I suggest you get accustomed to being stunned. > > > >:https://support.ntp.org/bin/view/Dev/ReleaseTimeline > >: > >:4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in > >:the codebase since then. > > > >4.2.0 may have been EOL'd in 2006, but it was still shipping as the > >default in FreeBSD until 2009. > > > >Out of those 3000 issues, only a tiny fraction are security-related > >that would apply to JunOS. I expect that they backport security and > >other fixes as necessary, until some bigger engineering effort and|or > >headache calls for a forklift/mass upgrade of things. > > > > > >-- > > Michael J. O'Connor > mjo at dojo.mi.org > > > =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= > >"Fire me, boy!" -The Human > Bullet > > From cb.list6 at gmail.com Sun Jul 12 18:16:14 2015 From: cb.list6 at gmail.com (Ca By) Date: Sun, 12 Jul 2015 11:16:14 -0700 Subject: NTP versions in production use? In-Reply-To: References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> <20150712141520.GD99711@dojo.mi.org> Message-ID: On Sunday, July 12, 2015, Alistair Mackenzie wrote: > I?m currently running a scan of the internet and querying NTP versions. > > I?ll publish the results of it on Github and mail them in here :) > > Please don't. Please see http://openntpproject.org/ > > > > On 12/07/2015 15:15, "NANOG on behalf of Mike O'Connor" < > nanog-bounces at nanog.org on behalf of mjo at dojo.mi.org > > wrote: > > >:Thanks, and I'm kinda stunned that folks are running such ancient > >:versions of NTP. > > > >I suggest you get accustomed to being stunned. > > > >:https://support.ntp.org/bin/view/Dev/ReleaseTimeline > >: > >:4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in > >:the codebase since then. > > > >4.2.0 may have been EOL'd in 2006, but it was still shipping as the > >default in FreeBSD until 2009. > > > >Out of those 3000 issues, only a tiny fraction are security-related > >that would apply to JunOS. I expect that they backport security and > >other fixes as necessary, until some bigger engineering effort and|or > >headache calls for a forklift/mass upgrade of things. > > > > > >-- > > Michael J. O'Connor > mjo at dojo.mi.org > > > =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= > >"Fire me, boy!" -The Human > Bullet > > From jared at puck.Nether.net Sun Jul 12 18:23:09 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Sun, 12 Jul 2015 14:23:09 -0400 Subject: NTP versions in production use? In-Reply-To: References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> <20150712141520.GD99711@dojo.mi.org> Message-ID: <20150712182309.GA16258@puck.nether.net> On Sun, Jul 12, 2015 at 11:16:14AM -0700, Ca By wrote: > On Sunday, July 12, 2015, Alistair Mackenzie wrote: > > > I?m currently running a scan of the internet and querying NTP versions. > > > > I?ll publish the results of it on Github and mail them in here :) > > > > > Please don't. > > Please see http://openntpproject.org/ A polite ask would get you data specifically about ntpd versions. Note that some korean CPEs had their firmware all built in KST: 38645 ntpd 4.1.1c-rc1 at 1.836 Mon Mar 30 16:45:15 KST 2015 (12) 26508 ntpd 4.1.1c-rc1 at 1.836 Tue Jan 6 15:54:39 KST 2015 (40) 23111 ntpd 4.1.1c-rc1 at 1.836 Thu Apr 16 23:42:15 KST 2015 (33) 16715 ntpd 4.1.1c-rc1 at 1.836 Mon Sep 3 11:11:56 KST 2012 (413) 15033 ntpd 4.2.4p6 at 1.1549 Tue Jan 5 17:30:09 UTC 2010 (1) 14307 ntpd 4.1.1c-rc1 at 1.836 Tue Dec 30 11:06:17 KST 2014 (26) 14247 ntpd 4.1.0 Thu May 22 08:58:17 KST 2003 (26) 12104 ntpd 4.2.4p5-a (1) 10802 ntpd 4.1.1c-rc1 at 1.836 Mon Mar 30 16:30:53 KST 2015 (9) 8236 ntpd 4.1.1c-rc1 at 1.836 Tue Apr 12 02:17:55 KST 2011 (471) 8130 ntpd 4.1.1c-rc1 at 1.836 Wed Aug 8 14:37:46 KST 2012 (361) 5599 ntpd 4.1.1c-rc1 at 1.836 Fri Nov 19 10:37:40 KST 2010 (414) 4591 ntpd 4.1.1 at 1.786 Thu Sep 20 21:30:08 KST 2012 (1) 3822 ntpd 4.1.0 Fri Sep 3 21:16:13 KST 2010 (1) 3642 ntpd 4.1.1c-rc1 at 1.836 Mon Apr 13 16:30:44 KST 2015 (12) 3557 ntpd 4.1.1c-rc1 at 1.836 Fri Feb 7 13:59:35 KST 2014 (3) 3411 ntpd 4.1.1 at 1.786 Sat Mar 20 23:54:04 KST 2004 (71) 3287 ntpd 4.1.1 at 1.786 Tue Jan 26 16:44:08 KST 2010 (1) 3280 ntpd 4.1.1c-rc1 at 1.836 Wed Apr 8 13:32:51 KST 2015 (25) 2892 ntpd 4.1.1 at 1.786 Wed Oct 20 16:50:38 KST 2010 (1) 2698 ntpd 4.1.1 at 1.786 Mon Jul 21 19:56:22 KST 2014 (32) 2590 ntpd 4.2.6p2 at 1.2194 Tue Jul 17 09:08:49 UTC 2012 (1) 2415 ntpd 4.2.6p2 at 1.2194 Mon Dec 22 02:40:05 UTC 2014 (1) 2393 ntpd 4.1.1c-rc1 at 1.836 Mon Sep 3 10:59:53 KST 2012 (412) 2357 ntpd 4.1.1c-rc1 at 1.836 Wed Nov 12 17:35:24 KST 2014 (5) 2303 ntpd 4.1.0 Fri Nov 26 19:21:49 KST 2010 (28) 2299 ntpd 4.1.1 at 1.786 Sat May 16 01:59:28 CST 2009 (1) 2072 ntpd 4.1.1 at 1.786 Thu Nov 21 15:27:20 KST 2013 (1) 1943 ntpd 4.1.1 at 1.786 Thu Dec 15 16:09:31 KST 2011 (1) 1846 ntpd 4.2.6p5 at 1.2349 Mon Dec 2 09:52:06 UTC 2013 (37) 1827 ntpd 4.1.1a at 1.791 Wed Feb 5 17:54:41 PST 2003 (42) 1782 ntpd 4.2.6p5 at 1.2349 Tue Jul 22 08:19:36 UTC 2014 (1) 1773 ntpd 4.2.6p5 at 1.2349-o Wed Apr 1 08:17:37 UTC 2015 (1) 1772 ntpd 4.2.4p4 at 1.1520 Tue Feb 19 10:06:54 UTC 2008 (1) 1760 ntpd 4.1.1c-rc1 at 1.836 Wed Jan 4 19:51:13 KST 2012 (564) 1657 ntpd 4.2.6p5 at 1.2349-o Mon Mar 16 14:53:03 UTC 2015 (1) 1632 ntpd 4.1.1c-rc1 at 1.836 Fri Jan 25 16:54:43 KST 2013 (411) 1531 ntpd 4.1.1 at 1.786 Thu Oct 7 21:30:18 KST 2010 (19) 1482 ntpd 4.1.1c-rc1 at 1.836 Mon Jan 28 18:56:40 KST 2013 (2) 1448 ntpd 4.1.1 at 1.786 Mon Dec 9 17:42:42 KST 2013 (12) 1415 ntpd 4.1.1c-rc1 at 1.836 Fri Jan 25 16:35:27 KST 2013 (411) 1337 ntpd 4.2.0-r Thu Aug 11 12:41:19 CDT 2005 (1) 1317 ntpd 4.2.7p440 at 1.2483-o Fri Aug 15 12:50:53 UTC 2014 (1) 1281 ntpd 4.2.8p2 at 1.3265-o Thu Apr 9 14:13:40 UTC 2015 (1) 1263 ntpd 4.1.1 at 1.786 Tue Nov 26 10:21:44 KST 2013 (7) 1236 ntpd 4.2.6p5 at 1.2349 Fri May 16 02:16:26 UTC 2014 (1) 1193 ntpd 4.1.0-a Wed Oct 9 12:19:42 GMT 2002 (1) 1103 ntpd 4.1.1 at 1.786 Fri Apr 10 11:45:44 KST 2015 (1) 1062 ntpd 4.2.5p113 at 1.1720-o Wed Aug 27 15:20:28 UTC 2014 (1) 1055 ntpd 4.1.1c-rc1 at 1.836 Fri May 7 14:34:37 KST 2010 (416) 1051 ntpd 4.2.6p2 at 1.2194 Fri Dec 27 03:51:03 UTC 2013 (2) 1038 ntpd 4.2.6p3 at 1.2290 Wed May 25 02:36:25 UTC 2011 (1) 1018 ntpd 4.1.1c-rc1 at 1.836 Wed Nov 16 17:52:53 KST 2011 (120) -- snip -- trimmed past 1k -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From jj at anexia.at Sun Jul 12 19:14:49 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Sun, 12 Jul 2015 19:14:49 +0000 Subject: AW: Level3 routing issue US west coast? In-Reply-To: References: Message-ID: <0521f4786fc24837ae58ce3901d2e3dd@anx-i-dag02.anx.local> One the DDoS targets was PCCW and their ports were congested ... this was the official explanation we got. Lots of discussion starts from here .... J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Donn Lasher Gesendet: Sonntag, 12. Juli 2015 18:13 An: nanog at nanog.org Betreff: Re: Level3 routing issue US west coast? While I can?t say with any degree of certainty it's related, it?s somewhat coincidental that one of one of their west coast customers (Daybreak Games / SOE) has been under a fairly hefty DDoS since mid-week. From what I recall see Daybreak/SOE only uses Level3. (Lots to talk about in that case.. They?ve invaded his life.. Not sure I?d react much better, albeit privately..) http://fortune.com/2015/07/10/john-smedley-vs-hackers/ http://eq2wire.com/2015/07/09/daybreak-ceo-to-convicted-lizard-squad-hacker -im-coming-for-you/ On 7/10/15, 11:05 AM, "Mr. NPP" wrote: >We took them down yesterday, and attempted to bring them back up midnight >PST, and still massive packet loss. so they remain down for now. > >On Fri, Jul 10, 2015 at 9:44 AM, J?rgen Jaritsch wrote: > >> Hi, >> >> No SLA broken cause A- and B-End were not directly our circuits ... but >>it >> helps a lot to place some new orders ... at other partners :). >> >> >> best regards >> >> J?rgen Jaritsch >> >> >> -----Urspr?ngliche Nachricht----- >> Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Jens Hoffmann >> Gesendet: Freitag, 10. Juli 2015 17:16 >> An: nanog at nanog.org >> Betreff: AW: Level3 routing issue US west coast >> >> Hi, >> >> >Wow .... Level3 responded to me that they had an issue last night .... >> but they simply did nothing ... for at least 10 hours they >did nothing >>to >> fix the issue: >> >> Any SLA broken? Probably not, that would be a reason to move. >> >> Kind regards, >> Jens >> >> From henson at acm.org Sun Jul 12 21:25:57 2015 From: henson at acm.org (Paul B. Henson) Date: Sun, 12 Jul 2015 14:25:57 -0700 Subject: another tilt at the Verizon FIOS IPv6 windmill Message-ID: <20150712212557.GG3716@bender.unx.cpp.edu> I think it's been about a year and a half since I last looked (and cried) at the status of FIOS IPv6. As far as I can tell, there's been no new official news since 2013. We're deploying IPv6 at the university I work at, so IPv6 at home is moving from "wish I had it to play with" towards "need to have it to work from home". So it seems I either cancel my fios and go with business class cable (I live in Time Warner territory and it looks like they're good to go with IPv6) or set up a tunnel with HE. Or pray Google fiber comes to my neck of the woods. Any new rumors floating around? Any Verizon employees interested in posting anonymously and explaining what on earth is going on inside the company? Any secret phone numbers to call to get in on an alpha/beta test in the So Cal area ;)? If nothing else, it always feels better to hear other people say how ridiculous this is too :). Thanks... From cb.list6 at gmail.com Sun Jul 12 21:32:33 2015 From: cb.list6 at gmail.com (Ca By) Date: Sun, 12 Jul 2015 14:32:33 -0700 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <20150712212557.GG3716@bender.unx.cpp.edu> References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: On Sunday, July 12, 2015, Paul B. Henson wrote: > I think it's been about a year and a half since I last looked (and > cried) at the status of FIOS IPv6. As far as I can tell, there's been no > new official news since 2013. We're deploying IPv6 at the university I > work at, so IPv6 at home is moving from "wish I had it to play with" > towards "need to have it to work from home". So it seems I either cancel > my fios and go with business class cable (I live in Time Warner > territory and it looks like they're good to go with IPv6) or set up a > tunnel with HE. Or pray Google fiber comes to my neck of the woods. > > Any new rumors floating around? Any Verizon employees interested in > posting anonymously and explaining what on earth is going on inside the > company? Any secret phone numbers to call to get in on an alpha/beta > test in the So Cal area ;)? > > If nothing else, it always feels better to hear other people say how > ridiculous this is too :). > > Thanks... > Yes, move your business to TWC. TWC has a proven v6 deployment and is actively engaged in the community, as where vz Fios is not. Business only understand $ CB From john-nanog at peachfamily.net Sun Jul 12 21:35:35 2015 From: john-nanog at peachfamily.net (John Peach) Date: Sun, 12 Jul 2015 17:35:35 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <20150712212557.GG3716@bender.unx.cpp.edu> References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: <20150712173535.11619d06@hulk> The only reason I have FIOS is because they gave me a 2 year deal of 15/15 internet for $30/month. Their advertising is basically just lies and I wouldn't hold my breath over IPv6; I have to run stunnel so I can send email from home because they don't even use TLS..... Having said that, I have an HE tunnel which works flawlessly with my Asus RT-N66U router.... On Sun, 12 Jul 2015 14:25:57 -0700 "Paul B. Henson" wrote: > I think it's been about a year and a half since I last looked (and > cried) at the status of FIOS IPv6. As far as I can tell, there's been no > new official news since 2013. We're deploying IPv6 at the university I > work at, so IPv6 at home is moving from "wish I had it to play with" > towards "need to have it to work from home". So it seems I either cancel > my fios and go with business class cable (I live in Time Warner > territory and it looks like they're good to go with IPv6) or set up a > tunnel with HE. Or pray Google fiber comes to my neck of the woods. > > Any new rumors floating around? Any Verizon employees interested in > posting anonymously and explaining what on earth is going on inside the > company? Any secret phone numbers to call to get in on an alpha/beta > test in the So Cal area ;)? > > If nothing else, it always feels better to hear other people say how > ridiculous this is too :). > > Thanks... -- John PGP Public Key: 412934AC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From yang.yu.list at gmail.com Sun Jul 12 21:41:50 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Mon, 13 Jul 2015 06:41:50 +0900 Subject: Level3 routing issue US west coast? In-Reply-To: <0521f4786fc24837ae58ce3901d2e3dd@anx-i-dag02.anx.local> References: <0521f4786fc24837ae58ce3901d2e3dd@anx-i-dag02.anx.local> Message-ID: On Mon, Jul 13, 2015 at 4:14 AM, J?rgen Jaritsch wrote: > One the DDoS targets was PCCW and their ports were congested ... this was the official explanation we got. > > Lots of discussion starts from here .... Can it be somehow related to the DDoS on Telegram (AS62041, AS59930)? 200Gbps SYN flood was what they said on twitter. I don't see 3491 as an upstream for either ASN any more. On a side note 3356 became upstream for 62041 about a week ago http://www.inmediahk.net/files/imagecache/w456/column_images/113252.png (the tweet has been deleted) From Valdis.Kletnieks at vt.edu Sun Jul 12 18:31:12 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 12 Jul 2015 14:31:12 -0400 Subject: NTP versions in production use? In-Reply-To: Your message of "Sun, 12 Jul 2015 10:15:20 -0400." <20150712141520.GD99711@dojo.mi.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> <20150712141520.GD99711@dojo.mi.org> Message-ID: <106318.1436725872@turing-police.cc.vt.edu> On Sun, 12 Jul 2015 10:15:20 -0400, "Mike O'Connor" said: > :Thanks, and I'm kinda stunned that folks are running such ancient > :versions of NTP. > > I suggest you get accustomed to being stunned. He obviously didn't see my post a few weeks back about hosts that were looking for an NTP server that went out of service back in 1999. And yes, some were still using NTP v1 and v2. There's a *lot* of stuff on very serious autopilot out there.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jj at anexia.at Sun Jul 12 22:05:52 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Sun, 12 Jul 2015 22:05:52 +0000 Subject: AW: Level3 routing issue US west coast? In-Reply-To: References: <0521f4786fc24837ae58ce3901d2e3dd@anx-i-dag02.anx.local> Message-ID: No idea about the final target ... I heard so much wrong information in the past 3 days ... Level3 didn't investigate in my packet loss report because there was another incident ongoing and so they thought my report was related to this issue. Even when I updated them AFTER they reported "solved" for the first issue they did nothing ... Other involved companies did nothing because of 100% incompetence ... It's simply frustrating .. :( J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: Yang Yu [mailto:yang.yu.list at gmail.com] Gesendet: Sonntag, 12. Juli 2015 23:42 An: J?rgen Jaritsch Cc: nanog at nanog.org Betreff: Re: Level3 routing issue US west coast? On Mon, Jul 13, 2015 at 4:14 AM, J?rgen Jaritsch wrote: > One the DDoS targets was PCCW and their ports were congested ... this was the official explanation we got. > > Lots of discussion starts from here .... Can it be somehow related to the DDoS on Telegram (AS62041, AS59930)? 200Gbps SYN flood was what they said on twitter. I don't see 3491 as an upstream for either ASN any more. On a side note 3356 became upstream for 62041 about a week ago http://www.inmediahk.net/files/imagecache/w456/column_images/113252.png (the tweet has been deleted) From stenn at nwtime.org Sun Jul 12 22:23:58 2015 From: stenn at nwtime.org (Harlan Stenn) Date: Sun, 12 Jul 2015 15:23:58 -0700 Subject: NTP versions in production use? In-Reply-To: <106318.1436725872@turing-police.cc.vt.edu> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> <20150712141520.GD99711@dojo.mi.org> <106318.1436725872@turing-police.cc.vt.edu> Message-ID: <55A2E8FE.1000404@nwtime.org> On 7/12/15 11:31 AM, Valdis.Kletnieks at vt.edu wrote: > On Sun, 12 Jul 2015 10:15:20 -0400, "Mike O'Connor" said: > >> :Thanks, and I'm kinda stunned that folks are running such ancient >> :versions of NTP. >> >> I suggest you get accustomed to being stunned. > > He obviously didn't see my post a few weeks back about hosts that were > looking for an NTP server that went out of service back in 1999. And yes, > some were still using NTP v1 and v2. > > There's a *lot* of stuff on very serious autopilot out there.... I did see it, and I was assuming it was a "local" configuration problem. This is "death by 1,000 cuts" and when I wrote my recent query I was looking for the big offenders. To me this situation goes hand-in-hand with the problems getting bcp38 deployed, and what Dan Geer talked about in his keynote speech at Black Hat 2014: http://www.youtube.com/watch?v=nT-TGvYOBpI I get that some folks have real problems with their build systems and it's hard to upgrade software tools in that environment. I know it's can be expensive to solve that problem. I'd love to find a way to have the "versioned tool chain" stuff that I implemented at Cisco/Andiamo be generally available, but I haven't found that many folks willing to support it yet and I just don't have the spare cycles to add that to my "do it for free" pile. I do know that if more companies were to use this sort of tool that the argument of "we can't patch older releases because we don't have those tools anymore and the Q/A process becomes horribly expensive" goes away. And that also means that it's far less expensive and therefore far more profitable to offer maintenance support on older software releases for much longer periods of time. But I must be missing something here as well, as I was never able to make headway with this idea when I was at Cisco. -- Harlan Stenn http://networktimefoundation.org - be a member! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 670 bytes Desc: OpenPGP digital signature URL: From jared at puck.Nether.net Mon Jul 13 01:12:06 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Sun, 12 Jul 2015 21:12:06 -0400 Subject: NTP versions in production use? In-Reply-To: <55A2E8FE.1000404@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> <55A1DC51.4080101@nwtime.org> <20150712141520.GD99711@dojo.mi.org> <106318.1436725872@turing-police.cc.vt.edu> <55A2E8FE.1000404@nwtime.org> Message-ID: <20150713011205.GB16258@puck.nether.net> On Sun, Jul 12, 2015 at 03:23:58PM -0700, Harlan Stenn wrote: > On 7/12/15 11:31 AM, Valdis.Kletnieks at vt.edu wrote: > > On Sun, 12 Jul 2015 10:15:20 -0400, "Mike O'Connor" said: > > > >> :Thanks, and I'm kinda stunned that folks are running such ancient > >> :versions of NTP. > >> > >> I suggest you get accustomed to being stunned. > > > > He obviously didn't see my post a few weeks back about hosts that were > > looking for an NTP server that went out of service back in 1999. And yes, > > some were still using NTP v1 and v2. > > > > There's a *lot* of stuff on very serious autopilot out there.... > > I did see it, and I was assuming it was a "local" configuration problem. > This is "death by 1,000 cuts" and when I wrote my recent query I was > looking for the big offenders. > > To me this situation goes hand-in-hand with the problems getting bcp38 > deployed, and what Dan Geer talked about in his keynote speech at Black > Hat 2014: > > http://www.youtube.com/watch?v=nT-TGvYOBpI > > I get that some folks have real problems with their build systems and > it's hard to upgrade software tools in that environment. I know it's > can be expensive to solve that problem. I'd love to find a way to have > the "versioned tool chain" stuff that I implemented at Cisco/Andiamo be > generally available, but I haven't found that many folks willing to > support it yet and I just don't have the spare cycles to add that to my > "do it for free" pile. > > I do know that if more companies were to use this sort of tool that the > argument of "we can't patch older releases because we don't have those > tools anymore and the Q/A process becomes horribly expensive" goes > away. And that also means that it's far less expensive and therefore > far more profitable to offer maintenance support on older software > releases for much longer periods of time. But I must be missing > something here as well, as I was never able to make headway with this > idea when I was at Cisco. The problem is people like Cisco don't make it easy to configure these protocols at all. You can only insert an IP address and their configuration system is all fire-and-forget additive causing config bloat. What's the harm in putting in a few more NTP lines if it just works. The NTP software does a lot of very esoteric things that don't matter much to those outside the super-time-geek space. This isn't blame, but it makes it harder for the upstream systems to injest them. Take JunOS which is effectively a type of FreeBSD port. The FreeBSD devs have very strict ideas of what should be part of the core OS, quality and ideas that prevent injesting something that isn't marked "full release". The release-early and release-often mantra comes to mind for me. If you do that, it's much easier for downstream people to package your latest upstream package. They take the idea of what you consider stable seriously and many developers i know don't like issuing a release because they know it does or might have some bugs. Sometimes that means rapid iterations which is much better than having stale software for N years where N is quite large like it is here. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mel at beckman.org Mon Jul 13 01:31:54 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Jul 2015 01:31:54 +0000 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <20150712212557.GG3716@bender.unx.cpp.edu> References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: Just set up the tunnel. It works beautifully. And thank you, HE.net, for being such a stellar tech leader! -mel > On Jul 12, 2015, at 2:26 PM, Paul B. Henson wrote: > > I think it's been about a year and a half since I last looked (and > cried) at the status of FIOS IPv6. As far as I can tell, there's been no > new official news since 2013. We're deploying IPv6 at the university I > work at, so IPv6 at home is moving from "wish I had it to play with" > towards "need to have it to work from home". So it seems I either cancel > my fios and go with business class cable (I live in Time Warner > territory and it looks like they're good to go with IPv6) or set up a > tunnel with HE. Or pray Google fiber comes to my neck of the woods. > ... From henson at acm.org Mon Jul 13 03:35:01 2015 From: henson at acm.org (Paul B. Henson) Date: Sun, 12 Jul 2015 20:35:01 -0700 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: <20150713033501.GH3716@bender.unx.cpp.edu> On Sun, Jul 12, 2015 at 02:32:33PM -0700, Ca By wrote: > Yes, move your business to TWC. TWC has a proven v6 deployment and is > actively engaged in the community, as where vz Fios is not. > > Business only understand $ Yah, cheap bastards :). I've got 50/50 fios right now; TWC can match the downstream but it looks like the upstream maxes out at 20 :(. At least for standard business internet, looks like their "Dedicated Internet Access" can be had at up to 10G. Arg, no prices for anything online though. I'd really hate to lose my upstream and I don't think I want to know how much DIA costs ;). I'm paying $125 for 50/50 with 5 static IPs right now. And I'm actually pretty happy with it other than the dead silence regarding IPv6. I suppose the average "business" user doesn't even know what IPv6 is , and Verizon probably doesn't care if they lose a handful of techies :(. What has Frontier done about IPv6 in the fios territories they've already purchased? Assuming the deal goes though I'll be a Frontier customer by this time next year... From henson at acm.org Mon Jul 13 03:38:13 2015 From: henson at acm.org (Paul B. Henson) Date: Sun, 12 Jul 2015 20:38:13 -0700 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <20150712173535.11619d06@hulk> References: <20150712212557.GG3716@bender.unx.cpp.edu> <20150712173535.11619d06@hulk> Message-ID: <20150713033813.GI3716@bender.unx.cpp.edu> On Sun, Jul 12, 2015 at 05:35:35PM -0400, John Peach wrote: > and I wouldn't hold my breath over IPv6; I have to run stunnel so I > can send email from home because they don't even use TLS..... Having Hmm, I just recently set up my mail client to use Verizon's smtp servers, and TLS seemed to work fine for me. smtp.verizon.net port 465, smtps. Took me a while to sort out smtp.verizon.net vs relay.verizon.net vs outgoing.verizon.net, but once I found the right one it's been working fine. From henson at acm.org Mon Jul 13 03:40:21 2015 From: henson at acm.org (Paul B. Henson) Date: Sun, 12 Jul 2015 20:40:21 -0700 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: <20150713034021.GJ3716@bender.unx.cpp.edu> On Mon, Jul 13, 2015 at 01:31:54AM +0000, Mel Beckman wrote: > Just set up the tunnel. It works beautifully. Yeah, I probably will. Shouldn't expose my bluff, but I probably won't switch to business cable, I actually use my upstream 8-/. But I needed to get in one last rant before I went that way :). > And thank you, HE.net, for being such a stellar tech leader! And thanks in advance from a soon-to-be tunnel requestor ;). From streiner at cluebyfour.org Mon Jul 13 05:58:29 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 13 Jul 2015 01:58:29 -0400 (EDT) Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <20150712212557.GG3716@bender.unx.cpp.edu> References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: On Sun, 12 Jul 2015, Paul B. Henson wrote: > I think it's been about a year and a half since I last looked (and > cried) at the status of FIOS IPv6. As far as I can tell, there's been no > new official news since 2013. We're deploying IPv6 at the university I > work at, so IPv6 at home is moving from "wish I had it to play with" > towards "need to have it to work from home". So it seems I either cancel > my fios and go with business class cable (I live in Time Warner > territory and it looks like they're good to go with IPv6) or set up a > tunnel with HE. Or pray Google fiber comes to my neck of the woods. I've shaken this tree many times in the 3 years I've had FIOS (Pittsburgh, PA), and the results from Verizon have not been promising. I call their customer service center to ask about IPv6 availability every few months, and get the electronic equivalent of a blank stare. Promises to "make a notation in my account" don't mean much if no one who is in a position to act on that notation will ever read it. I've also asked our Verizon rep through $dayjob about the v6 deployment status, and Verizon is so segmented and siloed internally, that it's been nearly impossible for them to find the right people. As others have suggested, set up a tunnel with Hurricane Electric, and move on with life. I've had one for probably two years, and it's been rock-solid. While it would be great to have native v6 from Verizon, it doesn't look like it'll happen any time soon. >From what I understand, many of the ONTs and possibly set-top boxes if you have FIOS TV service don't play nicely with v6. I don't know how true that is, or if those are still issues. I do recall hearing that upgrading to their Quantum service might get you a different ONT, but if that's true, I don't know if the those ONTs are any more v6-friendly. I don't know if there are any v6 compatibility issues further up the chain from the ONT. jms From jsklein at gmail.com Mon Jul 13 08:52:25 2015 From: jsklein at gmail.com (Joe Klein) Date: Mon, 13 Jul 2015 04:52:25 -0400 Subject: Overlay broad patent on IPv6? Message-ID: I was recently reading a few IPv6 patent, and happened upon on developed by Wesley E. George, Time Warner Cable Inc. on the topic of Use of dns information as trigger for dynamic ipv4 address allocation. It seems to impact the allocation of the IPv4 & IPv6 address for the gateway router, software defined consumer CPE, UPNP, CGN, content-based network, residential broadband networks; DSL networks; fiber-to-the-home (FTTH), fiber-to-the-node (FTTN), or fiber-to-the-curb (FTTC) networks; wireless Internet service providers (WISP)(fixed wireless to replace home broadband, typically in rural areas); or indeed to any situation with an on-demand IPv4 connection and dynamically assigned addressing. Am I reading this wrong? Has Time Warner patented all functions on the CPE? Joe Klein "Inveniam viam aut faciam" From jsklein at gmail.com Mon Jul 13 09:20:53 2015 From: jsklein at gmail.com (Joe Klein) Date: Mon, 13 Jul 2015 05:20:53 -0400 Subject: Overlay broad patent on IPv6? In-Reply-To: References: Message-ID: http://www.google.com/patents/US20130254423 Sorry missed the link. Joe Klein "Inveniam viam aut faciam" On Mon, Jul 13, 2015 at 4:52 AM, Joe Klein wrote: > I was recently reading a few IPv6 patent, and happened upon on developed > by Wesley E. George, Time Warner Cable Inc. on the topic of Use of dns > information as trigger for dynamic ipv4 address allocation. > > It seems to impact the allocation of the IPv4 & IPv6 address for the > gateway router, software defined consumer CPE, UPNP, CGN, content-based > network, residential broadband networks; DSL networks; fiber-to-the-home > (FTTH), fiber-to-the-node (FTTN), or fiber-to-the-curb (FTTC) networks; > wireless Internet service providers (WISP)(fixed wireless to replace home > broadband, typically in rural areas); or indeed to any situation with an > on-demand IPv4 connection and dynamically assigned addressing. > > Am I reading this wrong? Has Time Warner patented all functions on the CPE? > > Joe Klein > "Inveniam viam aut faciam" > From baldur.norddahl at gmail.com Mon Jul 13 09:45:58 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 13 Jul 2015 11:45:58 +0200 Subject: Overlay broad patent on IPv6? In-Reply-To: References: Message-ID: No 99% of the text is noise. Read the claims and notice the limitations: the patent is about a CPE with IPv6 without IPv4 that somehow acquires IPv4 as soon something does a DNS lookup that results in a reply without AAAA. It is a stupid idea if you ask me, so the patent is worthless. Regards, Baldur From A.L.M.Buxey at lboro.ac.uk Mon Jul 13 09:59:40 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 13 Jul 2015 09:59:40 +0000 Subject: Overlay broad patent on IPv6? In-Reply-To: References: Message-ID: <20150713095940.GB26042@lboro.ac.uk> Hi, > It is a stupid idea if you ask me, ..and thus, based on most of the current technology patents out there, perfectly patentable. dont worry, the rest of the internet will probably need something like this in the future... and whats happened here is some coffee-room tech chat or water cooler propeller-head conversation got captured and written-up by some over-zealous manager/techie combo to ensure that the world cant do something obvious later when needed (its probably not obvious to most people righ tnow as we havent even bothered looking at it...but if we did then it would probably be an obvious method and first one out of the wash). when it means is that most of those ISPs that do a captive portal answer for failed DNS responses are going to be violating this patent if the query was for IPv6 and didnt get an answer..... ;-) alan From jason at lixfeld.ca Mon Jul 13 11:43:12 2015 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 13 Jul 2015 07:43:12 -0400 Subject: In-rack DC distribution Message-ID: <404CEFD2-0EDA-4CAC-8F0D-E0037CEC2394@lixfeld.ca> Mornin?, I?ve been looking for the holy grail of in-rack A/B DC distribution, unfortunately without much success so far. In a perfect world, I?d have the equivalent of what we know and love about 0U vertical AC distribution rails (i.e.: APC), except with A/B feeds - lots of outlets, takes up no space in the rack, managed, remotely switched, etc. I?ve only found one vendor who makes such a beast for the DC world, but the breakers are manual - if it trips, or if you need to cycle it, you're rolling a truck. The beauty of this though is that it can take the gambit of breakers from 5A-200A. I?ve also been looking for something in the 1U world with A/B feeds. GMT panels are super high density, but GMT fuses are limited to 15A, so something that had small breakers (solid state, maybe??) 5-40A would be the holy grail there. Again, managed, remotely monitored per input/per output, remotely switched or reset would be the holy grail. Does anyone know of anything like this out there anywhere? From john-nanog at peachfamily.net Mon Jul 13 12:02:18 2015 From: john-nanog at peachfamily.net (John Peach) Date: Mon, 13 Jul 2015 08:02:18 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <20150713033813.GI3716@bender.unx.cpp.edu> References: <20150712212557.GG3716@bender.unx.cpp.edu> <20150712173535.11619d06@hulk> <20150713033813.GI3716@bender.unx.cpp.edu> Message-ID: <20150713080218.2303d4fe@jpeach-desktop.anbg.mssm.edu> On Sun, 12 Jul 2015 20:38:13 -0700 "Paul B. Henson" wrote: > On Sun, Jul 12, 2015 at 05:35:35PM -0400, John Peach wrote: > > and I wouldn't hold my breath over IPv6; I have to run stunnel so I > > can send email from home because they don't even use TLS..... Having > > Hmm, I just recently set up my mail client to use Verizon's smtp > servers, and TLS seemed to work fine for me. smtp.verizon.net port > 465, smtps. Took me a while to sort out smtp.verizon.net vs > relay.verizon.net vs outgoing.verizon.net, but once I found the right > one it's been working fine. smtps was deprecated years ago and is not implemented in postfix, hence the need for stunnel. I should have said they don't implement STARTTLS on either 25 or 587. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From jtk at cymru.com Mon Jul 13 13:01:17 2015 From: jtk at cymru.com (John Kristoff) Date: Mon, 13 Jul 2015 08:01:17 -0500 Subject: NTP versions in production use? In-Reply-To: <55A02B57.1010404@nwtime.org> References: <55A01D04.6080003@nwtime.org> <55A02B57.1010404@nwtime.org> Message-ID: <20150713080117.1b94d3bf@localhost> Hi Harlan, On Fri, 10 Jul 2015 13:30:15 -0700 Harlan Stenn wrote: > > I know that Cisco, for example, uses NTP in around 10 different > > product lines, but I don't know what versions of NTP are in current > > use. At least with the equipment with which I'm familiar they weren't using the reference implementation and as such, they didn't implement all the bells and whistles. So monlist and all the mode 6/7 stuff for instance isn't something you get with typical cisco gear, nor any ntp specific version number. Their implementation may be "older" in that sense, but perhaps safer, because it is "simpler" too. I had once heard the ntp code in ios was based on ntpd v3 (the code and protocol) and was relatively robust, done by a very capable coder. An authoritative voice on what the current state is would be helpful of course. Nonetheless, there are lots of cisco devices with ntp on them. Presumably most of them are using roughly the same code. > > I'm also curious about the answers here for Juniper and other > > network gear providers. That would include routers, switches, and > > other types of gear. JUNOS roughly follows FreeBSD and the reference implementation, but they have lagged behind a bit of what is generally available of course. You can easily find ntp running on JUNOS5 if that is any indication of what is in the wild. Jared probably has as good as any source of this data, but we have some too that might go back a little further. If you need anything more specific than the above, let me know. John From mhuff at ox.com Mon Jul 13 13:17:01 2015 From: mhuff at ox.com (Matthew Huff) Date: Mon, 13 Jul 2015 13:17:01 +0000 Subject: Speaking of NTP... Message-ID: We have 5 NTP server: 2 x stratum 1 rubidium oscillator time servers with GPS sync, and 3 servers running NTP 4.2.6p5-3 synced to external internet based NTP stratum 1 servers. We monitor our NTP environment closely, and over the last 10+ years, normally all of our NTP servers are sync'ed within +/- 2 msec. Starting last Friday, we started seeing some remote NTP servers with GPS reference consistently offset by 10 msec. Any one else seeing this? ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 From bortzmeyer at nic.fr Mon Jul 13 13:26:27 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 13 Jul 2015 15:26:27 +0200 Subject: Speaking of NTP... In-Reply-To: References: Message-ID: <20150713132627.GA30604@nic.fr> On Mon, Jul 13, 2015 at 01:17:01PM +0000, Matthew Huff wrote a message of 14 lines which said: > We have 5 NTP server: 2 x stratum 1 rubidium oscillator time servers > with GPS sync, and 3 servers running NTP 4.2.6p5-3 synced to > external internet based NTP stratum 1 servers. We monitor our NTP > environment closely, and over the last 10+ years, normally all of > our NTP servers are sync'ed within +/- 2 msec. Starting last Friday, > we started seeing some remote NTP servers with GPS reference > consistently offset by 10 msec. I have no idea but I just wanted to remind people that, for a few months, RIPE Atlas probes have been able to do NTP queries so it may be a cool way to monitor NTP servers from many points. From Lee at asgard.org Mon Jul 13 14:05:32 2015 From: Lee at asgard.org (Lee Howard) Date: Mon, 13 Jul 2015 10:05:32 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: On 7/9/15, 11:04 AM, "NANOG on behalf of Mel Beckman" wrote: >I working on a large airport WiFi deployment right now. IPv6 is "allowed >for in the future" but not configured in the short term. With less than >10,000 ephemeral users, we don't expect users to demand IPv6 until most >mobile devices and apps come ready to use IPv6 by default. I didn?t see anybody point out that most mobile devices and apps come ready to use IPv6 by default. At least, all Android and iOS devices do, and Apple recently announced that IPv6 support will be mandatory in future apps. Plus, Facebook, at least, says IPv6 is faster over mobile. Don?t know how it does over Wi-Fi. Lee From jared at puck.Nether.net Mon Jul 13 14:07:50 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Mon, 13 Jul 2015 10:07:50 -0400 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: <20150713140750.GB13043@puck.nether.net> On Mon, Jul 13, 2015 at 10:05:32AM -0400, Lee Howard wrote: > > > On 7/9/15, 11:04 AM, "NANOG on behalf of Mel Beckman" > wrote: > > >I working on a large airport WiFi deployment right now. IPv6 is "allowed > >for in the future" but not configured in the short term. With less than > >10,000 ephemeral users, we don't expect users to demand IPv6 until most > >mobile devices and apps come ready to use IPv6 by default. > > I didn?t see anybody point out that most mobile devices and apps come > ready to use IPv6 by default. > At least, all Android and iOS devices do, and Apple recently announced > that IPv6 support will be mandatory in future apps. > Plus, Facebook, at least, says IPv6 is faster over mobile. Don?t know how > it does over Wi-Fi. While this is true, the fear of new/unknown causes many people to behave like deer in the headlights. At some point someone needs to blink and move. On the "wifi here" locations they need these stickers also affixed: http://tnx.nl/legacy-ip-only.svg - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mel at beckman.org Mon Jul 13 15:20:35 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Jul 2015 15:20:35 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> , Message-ID: I've done fairly extensive testing, and IPv6 support, while pretty solid on the carrier side, is still iffy on WiFi. Both iOS and Android have various reliability problems with IPv6 and WiFi, mostly related to acquiring a DNS address or maintaining a connection while roaming. Combine that with less-than-fully-baked IPv6 on some enterprise WiFi platforms, and it's easy to see that deploying WiFi IPv6 today is at least a challenge, and definitely a risk. Android, for example, doesn't yet support DHCPv6 on WiFi (it's not needed on the carrier side, which does DNS intercept), and intermittently looses its unicast address on some hardware devices (notably tablets, in my experience). Even when android gets DHCPv6, or these hardware problems get solved, there will be several years of legacy devices in the field to contend with. -mel beckman > On Jul 13, 2015, at 7:05 AM, Lee Howard wrote: > > > > On 7/9/15, 11:04 AM, "NANOG on behalf of Mel Beckman" > wrote: > >> I working on a large airport WiFi deployment right now. IPv6 is "allowed >> for in the future" but not configured in the short term. With less than >> 10,000 ephemeral users, we don't expect users to demand IPv6 until most >> mobile devices and apps come ready to use IPv6 by default. > > I didn?t see anybody point out that most mobile devices and apps come > ready to use IPv6 by default. > At least, all Android and iOS devices do, and Apple recently announced > that IPv6 support will be mandatory in future apps. > Plus, Facebook, at least, says IPv6 is faster over mobile. Don?t know how > it does over Wi-Fi. > > Lee > > From johnl at iecc.com Mon Jul 13 15:25:51 2015 From: johnl at iecc.com (John Levine) Date: 13 Jul 2015 15:25:51 -0000 Subject: Overlay broad patent on IPv6? In-Reply-To: Message-ID: <20150713152551.18531.qmail@ary.lan> In article you write: >http://www.google.com/patents/US20130254423 This is not a patent. It is a patent application. Most applications do not turn into patents, or at least not with all of the claims included. If you look at the claims, which are what matter, this is for a rather specific hack in a broadband router which assigns a v4 address on the fly when a DNS lookup from behind the router returns a result that suggests that v4 traffic will happen, presumably by returning an A record. I can't imagine how anyone would misread this as a patent on IPv6. R's, John From shane at ronan-online.com Mon Jul 13 15:31:03 2015 From: shane at ronan-online.com (Shane Ronan) Date: Mon, 13 Jul 2015 11:31:03 -0400 Subject: Overlay broad patent on IPv6? In-Reply-To: <20150713152551.18531.qmail@ary.lan> References: <20150713152551.18531.qmail@ary.lan> Message-ID: This is actually a good idea. Roll out an IPV6 only network and only pass out an IPV4 address if it's needed based on actual traffic. On Jul 13, 2015 11:27 AM, "John Levine" wrote: > In article vs-KEdGU276fWGXqn1J9jmORLq8sW4xPE-Wg at mail.gmail.com> you write: > >http://www.google.com/patents/US20130254423 > > This is not a patent. It is a patent application. Most applications > do not turn into patents, or at least not with all of the claims > included. > > If you look at the claims, which are what matter, this is for a rather > specific hack in a broadband router which assigns a v4 address on the > fly when a DNS lookup from behind the router returns a result that > suggests that v4 traffic will happen, presumably by returning an A > record. > > I can't imagine how anyone would misread this as a patent on IPv6. > > R's, > John > From joe at nethead.com Mon Jul 13 15:47:35 2015 From: joe at nethead.com (Joe Hamelin) Date: Mon, 13 Jul 2015 08:47:35 -0700 Subject: Level3 routing issue US west coast? In-Reply-To: References: <0521f4786fc24837ae58ce3901d2e3dd@anx-i-dag02.anx.local> Message-ID: We have an MPLS circuit down in Philly with Level3. No explanation from them. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > From A.L.M.Buxey at lboro.ac.uk Mon Jul 13 15:54:30 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 13 Jul 2015 15:54:30 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> Message-ID: <20150713155430.GC27032@lboro.ac.uk> Hi, > I've done fairly extensive testing, and IPv6 support, while pretty solid on the carrier side, is still iffy on WiFi. Both iOS and Android have various reliability problems with IPv6 and WiFi, mostly related to acquiring a DNS address or maintaining a connection while roaming. Combine that with less-than-fully-baked IPv6 on some enterprise WiFi platforms, and it's easy to see that deploying WiFi IPv6 today is at least a challenge, and definitely a risk. > > Android, for example, doesn't yet support DHCPv6 on WiFi (it's not needed on the carrier side, which does DNS intercept), and intermittently looses its unicast address on some hardware devices (notably tablets, in my experience). Even when android gets DHCPv6, or these hardware problems get solved, there will be several years of legacy devices in the field to contend with. we had problems with IPv4 in the early days - people still adopted it. without adoption, the bugs/issues with clients dont get addressed. alan From baldur.norddahl at gmail.com Mon Jul 13 15:54:49 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 13 Jul 2015 17:54:49 +0200 Subject: Overlay broad patent on IPv6? In-Reply-To: References: <20150713152551.18531.qmail@ary.lan> Message-ID: Too bad it won't actually work. I type Slashdot.org in my browser. The web browser does DNS lookup. The CPE notices there is only an A record available and boots the IPv4 stack. However there is no way to push an IPv4 configuration to my computer. DHCP is pull not push. Even if there was, the web browser would not be prepared for an IPv4 configuration to suddenly appear in the middle of a request. I notice the patent application does not actually specify how this is supposed to work. It should not be possible to patent without building a prototype and indeed without even knowing how to build one. Then if someone later figures out the details, you somehow owe your soul to these guys that just did some handwaving. Regards Baldur Den 13/07/2015 17.33 skrev "Shane Ronan" : > This is actually a good idea. Roll out an IPV6 only network and only pass > out an IPV4 address if it's needed based on actual traffic. > On Jul 13, 2015 11:27 AM, "John Levine" wrote: > > > In article > vs-KEdGU276fWGXqn1J9jmORLq8sW4xPE-Wg at mail.gmail.com> you write: > > >http://www.google.com/patents/US20130254423 > > > > This is not a patent. It is a patent application. Most applications > > do not turn into patents, or at least not with all of the claims > > included. > > > > If you look at the claims, which are what matter, this is for a rather > > specific hack in a broadband router which assigns a v4 address on the > > fly when a DNS lookup from behind the router returns a result that > > suggests that v4 traffic will happen, presumably by returning an A > > record. > > > > I can't imagine how anyone would misread this as a patent on IPv6. > > > > R's, > > John > > > From A.L.M.Buxey at lboro.ac.uk Mon Jul 13 15:55:16 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 13 Jul 2015 15:55:16 +0000 Subject: Overlay broad patent on IPv6? In-Reply-To: References: <20150713152551.18531.qmail@ary.lan> Message-ID: <20150713155516.GD27032@lboro.ac.uk> Hi, > This is actually a good idea. Roll out an IPV6 only network and only pass > out an IPV4 address if it's needed based on actual traffic. yes...shame someones applied for a patent on that! ;-) alan From mel at beckman.org Mon Jul 13 15:59:52 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Jul 2015 15:59:52 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <20150713155430.GC27032@lboro.ac.uk> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> , <20150713155430.GC27032@lboro.ac.uk> Message-ID: <36368527-A382-422D-BD84-53A6B86999D9@beckman.org> Of course. The question is, is a highly visible public wifi network the place to hammer out problems? My customer decided no. -mel beckman > On Jul 13, 2015, at 8:54 AM, "A.L.M.Buxey at lboro.ac.uk" wrote: > > Hi, >> I've done fairly extensive testing, and IPv6 support, while pretty solid on the carrier side, is still iffy on WiFi. Both iOS and Android have various reliability problems with IPv6 and WiFi, mostly related to acquiring a DNS address or maintaining a connection while roaming. Combine that with less-than-fully-baked IPv6 on some enterprise WiFi platforms, and it's easy to see that deploying WiFi IPv6 today is at least a challenge, and definitely a risk. >> >> Android, for example, doesn't yet support DHCPv6 on WiFi (it's not needed on the carrier side, which does DNS intercept), and intermittently looses its unicast address on some hardware devices (notably tablets, in my experience). Even when android gets DHCPv6, or these hardware problems get solved, there will be several years of legacy devices in the field to contend with. > > we had problems with IPv4 in the early days - people still adopted it. without adoption, the bugs/issues with clients dont > get addressed. > > alan From ikiris at gmail.com Mon Jul 13 16:04:40 2015 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 13 Jul 2015 09:04:40 -0700 Subject: Overlay broad patent on IPv6? In-Reply-To: <20150713155516.GD27032@lboro.ac.uk> References: <20150713152551.18531.qmail@ary.lan> <20150713155516.GD27032@lboro.ac.uk> Message-ID: The point is you'd already have a 192 address or something, and it would only grab the external address for a short duration for use as an external PAT address, thus oversubscribing the ip4 pool to users who need it (based on dns). Its still pretty broken, but less broken than you describe. On Mon, Jul 13, 2015 at 8:55 AM, wrote: > Hi, >> This is actually a good idea. Roll out an IPV6 only network and only pass >> out an IPV4 address if it's needed based on actual traffic. > > yes...shame someones applied for a patent on that! ;-) > > alan From mel at beckman.org Mon Jul 13 16:07:44 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Jul 2015 16:07:44 +0000 Subject: Overlay broad patent on IPv6? In-Reply-To: References: <20150713152551.18531.qmail@ary.lan> , Message-ID: <33ED4D14-E4DC-4A11-935C-31A2D4D758F0@beckman.org> Balder, That may well be the subject of one of the other patents. Also, there is no requirement under US patent law to build a prototype. It just has to be possible for one "usually skilled in the art" to construct one from the content of the patent. Also, most patents are not for a complete system. They just describe the function of a single invention, possibly useful in a larger system. For example, consider the patent of a gravity escapement in a clock (No. 739,245. Pat. Sept 15, 1903. W. Willmann). The escapement is useless on its own, but has application in many mechanical clocks, including watches. So there's no requirement that the patent explain how IPv4 addresses are acquired by the client. -mel beckman > On Jul 13, 2015, at 8:58 AM, Baldur Norddahl wrote: > > Too bad it won't actually work. I type Slashdot.org in my browser. The web > browser does DNS lookup. The CPE notices there is only an A record > available and boots the IPv4 stack. However there is no way to push an IPv4 > configuration to my computer. DHCP is pull not push. Even if there was, the > web browser would not be prepared for an IPv4 configuration to suddenly > appear in the middle of a request. > > I notice the patent application does not actually specify how this is > supposed to work. It should not be possible to patent without building a > prototype and indeed without even knowing how to build one. Then if someone > later figures out the details, you somehow owe your soul to these guys that > just did some handwaving. > > Regards > > Baldur > Den 13/07/2015 17.33 skrev "Shane Ronan" : > >> This is actually a good idea. Roll out an IPV6 only network and only pass >> out an IPV4 address if it's needed based on actual traffic. >>> On Jul 13, 2015 11:27 AM, "John Levine" wrote: >>> >>> In article >> vs-KEdGU276fWGXqn1J9jmORLq8sW4xPE-Wg at mail.gmail.com> you write: >>>> http://www.google.com/patents/US20130254423 >>> >>> This is not a patent. It is a patent application. Most applications >>> do not turn into patents, or at least not with all of the claims >>> included. >>> >>> If you look at the claims, which are what matter, this is for a rather >>> specific hack in a broadband router which assigns a v4 address on the >>> fly when a DNS lookup from behind the router returns a result that >>> suggests that v4 traffic will happen, presumably by returning an A >>> record. >>> >>> I can't imagine how anyone would misread this as a patent on IPv6. >>> >>> R's, >>> John >>> >> From nanog at ics-il.net Mon Jul 13 16:09:04 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 13 Jul 2015 11:09:04 -0500 (CDT) Subject: Overlay broad patent on IPv6? In-Reply-To: Message-ID: <1341806287.695.1436803762955.JavaMail.mhammett@ThunderFuck> The CPE does the private IP space it traditionally does for the end user equipment. If a v4 address is needed, it is pushed from the provider to the CPE, where it does NAT. It doesn't need your Windows, Linux, Android box to support anything atypical. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Monday, July 13, 2015 10:54:49 AM Subject: Re: Overlay broad patent on IPv6? Too bad it won't actually work. I type Slashdot.org in my browser. The web browser does DNS lookup. The CPE notices there is only an A record available and boots the IPv4 stack. However there is no way to push an IPv4 configuration to my computer. DHCP is pull not push. Even if there was, the web browser would not be prepared for an IPv4 configuration to suddenly appear in the middle of a request. I notice the patent application does not actually specify how this is supposed to work. It should not be possible to patent without building a prototype and indeed without even knowing how to build one. Then if someone later figures out the details, you somehow owe your soul to these guys that just did some handwaving. Regards Baldur Den 13/07/2015 17.33 skrev "Shane Ronan" : > This is actually a good idea. Roll out an IPV6 only network and only pass > out an IPV4 address if it's needed based on actual traffic. > On Jul 13, 2015 11:27 AM, "John Levine" wrote: > > > In article > vs-KEdGU276fWGXqn1J9jmORLq8sW4xPE-Wg at mail.gmail.com> you write: > > >http://www.google.com/patents/US20130254423 > > > > This is not a patent. It is a patent application. Most applications > > do not turn into patents, or at least not with all of the claims > > included. > > > > If you look at the claims, which are what matter, this is for a rather > > specific hack in a broadband router which assigns a v4 address on the > > fly when a DNS lookup from behind the router returns a result that > > suggests that v4 traffic will happen, presumably by returning an A > > record. > > > > I can't imagine how anyone would misread this as a patent on IPv6. > > > > R's, > > John > > > From nanog at ics-il.net Mon Jul 13 16:58:15 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 13 Jul 2015 11:58:15 -0500 (CDT) Subject: Access to nanog.cluepon.net In-Reply-To: <001501d0a07e$0e9566a0$2bc033e0$@iname.com> Message-ID: <839678675.805.1436806706594.JavaMail.mhammett@ThunderFuck> Seems like it's still down? :-\ ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Frank Bulk" To: nanog at nanog.org Sent: Saturday, June 6, 2015 12:27:24 PM Subject: Access to nanog.cluepon.net I'd like to update some material on nanog.cluepon.net (not very responsive to HTTP requests right now) and my account doesn't work anymore. I reached out to Richard S. but have not heard back from him - anyone else here who has admin access and can set me up again? Frank From baldur.norddahl at gmail.com Mon Jul 13 17:10:12 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 13 Jul 2015 19:10:12 +0200 Subject: Fwd: Overlay broad patent on IPv6? In-Reply-To: References: <20150713152551.18531.qmail@ary.lan> <20150713155516.GD27032@lboro.ac.uk> Message-ID: Nah what you describe is a different invention. Someone probably already has a patent on that. The browser will do a DNS lookup on slashdot.org and then cache that - forever (or until you restart the browser). Yes it will ignore the TTL (apps don't get the TTL at all, so apps don't know). Same happens if you ssh to yourserver.someplace.com. One DNS lookup, the traffic sticks there forever or until the session is terminated. DNS is horrible for this. If they had a IPv4 internal private network going you would not need to hook unto the DNS at all. Just get IP address when something wants to be routed out the WAN port. Also the NAT table is a good indicator of when you can release the address again. On other words, that would work, but the system described in the patent app wont. Of course both systems are useless. I can not imagine any end user that wont have a ton of IPv4 going on for the next decade to come. And when time comes, we are more likely to NAT64 than this. Regards, Baldur On 13 July 2015 at 18:04, Blake Dunlap wrote: > The point is you'd already have a 192 address or something, and it > would only grab the external address for a short duration for use as > an external PAT address, thus oversubscribing the ip4 pool to users > who need it (based on dns). Its still pretty broken, but less broken > than you describe. > > On Mon, Jul 13, 2015 at 8:55 AM, wrote: > > Hi, > >> This is actually a good idea. Roll out an IPV6 only network and only > pass > >> out an IPV4 address if it's needed based on actual traffic. > > > > yes...shame someones applied for a patent on that! ;-) > > > > alan > From mikea at mikea.ath.cx Mon Jul 13 17:51:00 2015 From: mikea at mikea.ath.cx (mikea) Date: Mon, 13 Jul 2015 12:51:00 -0500 Subject: Hotels/Airports with IPv6 In-Reply-To: <29B817E0-B42A-41FB-A3BA-9A49DBB1232E@beckman.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> <29B817E0-B42A-41FB-A3BA-9A49DBB1232E@beckman.org> Message-ID: <20150713175100.GA83516@mikea.ath.cx> On Sat, Jul 11, 2015 at 05:34:03AM +0000, Mel Beckman wrote: > Owen, > > I never said it was a greenfield deployment. Someone else tagged it with > that term. > > My understanding of the term "greenfield" WRT wifi is that there are no > interfering signals to contend with. I don't know of any U.S. airport that > meets that definition. First you have all the wifi of concessionaires, the > airlines' passenger clubs and operations, and service organizations for > food, fuel, and FAA. You can't control those users, thanks to the FAA's > recent decisions restricting wifi regulation to itself. FAA? Could you possibly have meant FCC? FAA has little or nothing to do with regulation of radio TTBOMK, while FCC has everything to do with it. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From henson at acm.org Mon Jul 13 19:06:56 2015 From: henson at acm.org (Paul B. Henson) Date: Mon, 13 Jul 2015 12:06:56 -0700 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <20150713080218.2303d4fe@jpeach-desktop.anbg.mssm.edu> References: <20150712212557.GG3716@bender.unx.cpp.edu> <20150712173535.11619d06@hulk> <20150713033813.GI3716@bender.unx.cpp.edu> <20150713080218.2303d4fe@jpeach-desktop.anbg.mssm.edu> Message-ID: <055f01d0bd9f$16eec1a0$44cc44e0$@acm.org> > From: John Peach > Sent: Monday, July 13, 2015 5:02 AM > > smtps was deprecated years ago and is not implemented in postfix, hence > the need for stunnel. I should have said they don't implement STARTTLS > on either 25 or 587. Oh, ok; I assumed you were talking about a client, not an MTA. Why are you relaying through Verizon rather than just sending directly? My home MTA on FIOS hasn't had any problems sending mail to the Internet at large, although I do have a static IP with appropriate matching/reverse DNS. Seems to be a lot less noise on this iteration of the shake fist at Verizon's lack of IPv6 thread, I guess everybody is pretty much burned out and given up 8-/. Verizon should just update their IPv6 status page with a link to hurricane electric's tunnel broker page . From john-nanog at peachfamily.net Mon Jul 13 19:12:28 2015 From: john-nanog at peachfamily.net (John Peach) Date: Mon, 13 Jul 2015 15:12:28 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <055f01d0bd9f$16eec1a0$44cc44e0$@acm.org> References: <20150712212557.GG3716@bender.unx.cpp.edu> <20150712173535.11619d06@hulk> <20150713033813.GI3716@bender.unx.cpp.edu> <20150713080218.2303d4fe@jpeach-desktop.anbg.mssm.edu> <055f01d0bd9f$16eec1a0$44cc44e0$@acm.org> Message-ID: <20150713151228.43ec8429@jpeach-desktop.anbg.mssm.edu> On Mon, 13 Jul 2015 12:06:56 -0700 "Paul B. Henson" wrote: > > From: John Peach > > Sent: Monday, July 13, 2015 5:02 AM > > > > smtps was deprecated years ago and is not implemented in postfix, > > hence the need for stunnel. I should have said they don't implement > > STARTTLS on either 25 or 587. > > Oh, ok; I assumed you were talking about a client, not an MTA. Why > are you relaying through Verizon rather than just sending directly? > My home MTA on FIOS hasn't had any problems sending mail to the > Internet at large, although I do have a static IP with appropriate > matching/reverse DNS. I'm cheap :) For $30 a month they don't allow port 25 outbound. > > Seems to be a lot less noise on this iteration of the shake fist at > Verizon's lack of IPv6 thread, I guess everybody is pretty much > burned out and given up 8-/. Verizon should just update their IPv6 > status page with a link to hurricane electric's tunnel broker page > . The fact that my router supports the HE tunnel natively makes this completely painless. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From tony at lavanauts.org Mon Jul 13 19:27:28 2015 From: tony at lavanauts.org (Antonio Querubin) Date: Mon, 13 Jul 2015 09:27:28 -1000 (HST) Subject: Hotels/Airports with IPv6 In-Reply-To: <36368527-A382-422D-BD84-53A6B86999D9@beckman.org> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> , <20150713155430.GC27032@lboro.ac.uk> <36368527-A382-422D-BD84-53A6B86999D9@beckman.org> Message-ID: On Mon, 13 Jul 2015, Mel Beckman wrote: > Of course. The question is, is a highly visible public wifi network the > place to hammer out problems? My customer decided no. Public Wifi nets almost always have administratively built-in limitations which may not be apparent at first to the end-users. I don't think your end-users are gonna be moaning about IPv6 issues when there will likely be other limitations they'll be cursing about :) Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From jfbeam at gmail.com Mon Jul 13 19:43:26 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 13 Jul 2015 15:43:26 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: On Sun, 12 Jul 2015 17:32:33 -0400, Ca By wrote: > Yes, move your business to TWC. TWC has a proven v6 deployment and is > actively engaged in the community, as where vz Fios is not. Yes, because TWC-BC's IPv6 support is stellar. Sorry, I misspelled "non-existent". Their "DIA" (metro-e) stuff, *might*, but I doubt it. From mel at beckman.org Mon Jul 13 20:00:02 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Jul 2015 20:00:02 +0000 Subject: Hotels/Airports with IPv6 In-Reply-To: <20150713175100.GA83516@mikea.ath.cx> References: <9E28F309-5175-4EAE-90DC-D8E94DB8587F@puck.nether.net> <20150710214153.3A3DA32B42B9@rock.dv.isc.org> <20150710220258.622AD32B47BD@rock.dv.isc.org> <29B817E0-B42A-41FB-A3BA-9A49DBB1232E@beckman.org>, <20150713175100.GA83516@mikea.ath.cx> Message-ID: <218869E6-BD9D-4141-A611-93EF6DDB5501@beckman.org> Right. FCC. Sorry -mel beckman > On Jul 13, 2015, at 10:53 AM, mikea wrote: > >> On Sat, Jul 11, 2015 at 05:34:03AM +0000, Mel Beckman wrote: >> Owen, >> >> I never said it was a greenfield deployment. Someone else tagged it with >> that term. >> >> My understanding of the term "greenfield" WRT wifi is that there are no >> interfering signals to contend with. I don't know of any U.S. airport that >> meets that definition. First you have all the wifi of concessionaires, the >> airlines' passenger clubs and operations, and service organizations for >> food, fuel, and FAA. You can't control those users, thanks to the FAA's >> recent decisions restricting wifi regulation to itself. > > FAA? Could you possibly have meant FCC? FAA has little or nothing to do with > regulation of radio TTBOMK, while FCC has everything to do with it. > > -- > Mike Andrews, W5EGO > mikea at mikea.ath.cx > Tired old sysadmin From streiner at cluebyfour.org Mon Jul 13 20:18:54 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 13 Jul 2015 16:18:54 -0400 (EDT) Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <055f01d0bd9f$16eec1a0$44cc44e0$@acm.org> References: <20150712212557.GG3716@bender.unx.cpp.edu> <20150712173535.11619d06@hulk> <20150713033813.GI3716@bender.unx.cpp.edu> <20150713080218.2303d4fe@jpeach-desktop.anbg.mssm.edu> <055f01d0bd9f$16eec1a0$44cc44e0$@acm.org> Message-ID: On Mon, 13 Jul 2015, Paul B. Henson wrote: > Seems to be a lot less noise on this iteration of the shake fist at > Verizon's lack of IPv6 thread, I guess everybody is pretty much burned out > and given up 8-/. Verizon should just update their IPv6 status page with a > link to hurricane electric's tunnel broker page . For a long time, Verizon's general "What is IPv6?" page stated the standard assignment for customers was a /56... or 56 LANs. *headdesk*. jms From dhubbard at dino.hostasaurus.com Mon Jul 13 20:45:51 2015 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Mon, 13 Jul 2015 16:45:51 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill References: <055f01d0bd9f$16eec1a0$44cc44e0$@acm.org> Message-ID: On Mon, 13 Jul 2015, Paul B. Henson wrote: > Seems to be a lot less noise on this iteration of the shake fist at > Verizon's lack of IPv6 thread, I guess everybody is pretty much burned > out and given up 8-/. Verizon should just update their IPv6 status > page with a link to hurricane electric's tunnel broker page . I think that's exactly what's occurred. There was a point where I spent several years wasting time sending notes to the sales rep, opening support tickets, trolling them on twitter and their own forum, etc., all with either no useful answer or no answer at all; ultimately I gave up and replaced the inexpensive Fios connection with a more $$ TWTC circuit. I'd flip it back to Fios if they rolled out v6 since it was a lot less expensive and had been perfectly reliable at the location that used it. David From mel at beckman.org Mon Jul 13 20:57:07 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Jul 2015 20:57:07 +0000 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <055f01d0bd9f$16eec1a0$44cc44e0$@acm.org>, Message-ID: <2821F753-AA62-4C1F-804D-FA56162D3917@beckman.org> David, Did you consider running an IPv6 tunnel through HE.net? -mel via cell > On Jul 13, 2015, at 1:46 PM, David Hubbard wrote: > >> On Mon, 13 Jul 2015, Paul B. Henson wrote: >> >> Seems to be a lot less noise on this iteration of the shake fist at >> Verizon's lack of IPv6 thread, I guess everybody is pretty much burned > >> out and given up 8-/. Verizon should just update their IPv6 status >> page with a link to hurricane electric's tunnel broker page . > > I think that's exactly what's occurred. There was a point where I spent > several years wasting time sending notes to the sales rep, opening > support tickets, trolling them on twitter and their own forum, etc., all > with either no useful answer or no answer at all; ultimately I gave up > and replaced the inexpensive Fios connection with a more $$ TWTC > circuit. I'd flip it back to Fios if they rolled out v6 since it was a > lot less expensive and had been perfectly reliable at the location that > used it. > > David From betty at nanog.org Mon Jul 13 21:28:18 2015 From: betty at nanog.org (Betty Burke ) Date: Mon, 13 Jul 2015 17:28:18 -0400 Subject: [NANOG-announce] NANOG 65, October 5-7, 2015, Montreal, Quebec Canada Message-ID: NANOGers, We are pleased to announce the opening of NANOG 65 Registration. NANOG 65 will be our customary revisit to Canada, and Montreal is sure be an excellent destination for our October 2017 meeting. We are expecting strong attendance and another great Program. Posted on our website, and noted here, are a few NANOG 65 links for your reference and convenience: - Call for Presentations - Registration - Hotel Reservation - Agenda Outline - Peering Personals submission request - Postel Scholarship Application - Fellowship Application(s) - In and Around Montreal Leading to NANOG 65, we will be adding additional links and information to our meeting website. In the mean time, should you have any questions please direct them to nanog-support at nanog.org. Sincerely, Betty on behalf of the Registration Staff ___________________________________ Betty J. Burke NANOG Executive Director 2864 Carpenter Rd., Ste 100 Ann Arbor, MI 48108 +1 866-902-1336 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From betty at nanog.org Mon Jul 13 21:35:39 2015 From: betty at nanog.org (Betty Burke ) Date: Mon, 13 Jul 2015 17:35:39 -0400 Subject: [NANOG-announce] NANOG 65, October 5-7, 2015, Montreal, Quebec Canada In-Reply-To: References: Message-ID: So very very sorry! I am working on October 2017 now, our registration for NANOG 65 is indeed October 2015. All best Betty Betty J. Burke NANOG Executive Director 2864 Carpenter Rd., Ste 100 Ann Arbor, MI 48108 +1 866-902-1336 On Mon, Jul 13, 2015 at 5:28 PM, Betty Burke < betty at nanog.org> wrote: > NANOGers, > > We are pleased to announce the opening of NANOG 65 Registration. NANOG 65 > will be our customary revisit to Canada, and Montreal is sure be an > excellent destination for our October 2017 meeting. We are expecting > strong attendance and another great Program. > > Posted on our website, and noted here, are a few NANOG 65 links for your > reference and convenience: > > - Call for Presentations > > - Registration > - Hotel Reservation > > - Agenda Outline > - Peering Personals submission request > > - Postel Scholarship Application > > - Fellowship Application(s) > > - In and Around Montreal > > > > Leading to NANOG 65, we will be adding additional links and information to > our meeting website. In the mean time, should you have any questions > please direct them to nanog-support at nanog.org. > > > Sincerely, > Betty on behalf of the Registration Staff > ___________________________________ > > Betty J. Burke > NANOG Executive Director > 2864 Carpenter Rd., Ste 100 > Ann Arbor, MI 48108 > +1 866-902-1336 > > -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jmaimon at ttec.com Mon Jul 13 23:16:13 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 13 Jul 2015 19:16:13 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> Message-ID: <55A446BD.6000605@ttec.com> Owen DeLong wrote: > JimBob?s ISP can apply to ARIN for a /16 Like I said, very possibly not a good thing for the address space. From lyndon at orthanc.ca Tue Jul 14 03:02:17 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 13 Jul 2015 20:02:17 -0700 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <2821F753-AA62-4C1F-804D-FA56162D3917@beckman.org> References: <055f01d0bd9f$16eec1a0$44cc44e0$@acm.org>, <2821F753-AA62-4C1F-804D-FA56162D3917@beckman.org> Message-ID: On Jul 13, 2015, at 1:57 PM, Mel Beckman wrote: > David, > Did you consider running an IPv6 tunnel through HE.net? Tunnels work, but they really are getting old. I have run 3ffe:: 6bone, HE tunnels, and (currently) aiccu. They all work very reliably, and I have immense gratitude towards the people who commit the time, the hardware, and the software, to making that go. But the bottom line is that 200+ms RTTs to my servers over v6 tunnels simply can't compete with 20ms RTTs on native v4. I know my code works over v6, but how can I ever know it works well when I'm behind a v6 dialup link? This past weekend I bit the projectile and decided to flip my service over to Teksavvy. The latter have native v6, claim to offer /48s, and have the audacity to charge me $10/month less than Telus. I'm game. More importantly, after eight years of Telus promising an IPv6 beta, I can tell them to see https://orthanc.ca/figure-1 :-P --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dhubbard at dino.hostasaurus.com Tue Jul 14 03:32:23 2015 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Mon, 13 Jul 2015 23:32:23 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill References: <2821F753-AA62-4C1F-804D-FA56162D3917@beckman.org> Message-ID: From: Mel Beckman [mailto:mel at beckman.org] > > David, > Did you consider running an IPv6 tunnel through HE.net? > We couldn't get the desired throughput via HE tunnel. We tried it, then switched to v6 through VPN using a slice of our own allocation, but ultimately didn't want that overhead either. David From lyndon at orthanc.ca Tue Jul 14 03:35:10 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 13 Jul 2015 20:35:10 -0700 Subject: another tilt^2 [real numbers] In-Reply-To: References: <055f01d0bd9f$16eec1a0$44cc44e0$@acm.org>, <2821F753-AA62-4C1F-804D-FA56162D3917@beckman.org> Message-ID: For a bit of fun, the results after 30 minutes of https://orthanc.ca/figure-1 being out on the nanog list: IPv4: 315 IPv6: 22 This is strictly GETs on the target page, not tainted by CSS or favicon nonsense. I don't know what this says about the proclivity of Nanog readers to blindly click on email URLs. (But the delineation between web and MUA email client user behaviours is ... interesting ...) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Tue Jul 14 04:22:03 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Jul 2015 21:22:03 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A446BD.6000605@ttec.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> Message-ID: How so? There are 8192 /16s in the current /3. ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person can?t really be all that many? 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. 7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed. Really, if we burn through all 8,192 of them in less than 50 years and I?m still alive when we do, I?ll help you promote more restrictive policy to be enacted while we burn through the second /3. That?ll still leave us 75% of the address space to work with on that new policy. If you want to look at places where IPv6 is really getting wasted, let?s talk about an entire /9 reserved without an RFC to make it usable or it?s partner /9 with an RFC to make it mostly useless, but popular among those few remaining NAT fanboys. Together that constitutes 1/256th of the address space cast off to waste. Yeah, I?m not too worried about the ISPs that can legitimately justify a /16. Owen > On Jul 13, 2015, at 16:16 , Joe Maimon wrote: > > > > Owen DeLong wrote: >> JimBob?s ISP can apply to ARIN for a /16 > > Like I said, very possibly not a good thing for the address space. From robert at ufl.edu Tue Jul 14 11:37:48 2015 From: robert at ufl.edu (Scott, Robert D.) Date: Tue, 14 Jul 2015 11:37:48 +0000 Subject: ARIN IPV4 Countdown Message-ID: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> If you have been keeping an eye on the ARIN IPV4 countdown, they allocated their last /23 yesterday. There are only 400 /24s in the pool now. https://www.arin.net/resources/request/ipv4_countdown.html Robert D. Scott Robert at ufl.edu Network Engineer 3 352-273-0113 Phone UF Information Technology 321-663-0421 Cell Network Services 352-273-0743 FAX University of Florida Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 3216630421 at messaging.sprintpcs.com From nwarren at barryelectric.com Tue Jul 14 13:19:43 2015 From: nwarren at barryelectric.com (Nicholas Warren) Date: Tue, 14 Jul 2015 13:19:43 +0000 Subject: 'gray' market IPv4 Message-ID: Where is one of these v4 markets that we can buy some IPv4 space from? I would prefer to have a place where we could see recent transactions, something along the lines of x amount of addresses for y amount of monies. Google search is failing me for some reason.. - Thanks, Nich From nanog at ics-il.net Tue Jul 14 13:23:19 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 14 Jul 2015 08:23:19 -0500 (CDT) Subject: 'gray' market IPv4 In-Reply-To: Message-ID: <1359126815.2748.1436880212935.JavaMail.mhammett@ThunderFuck> Even if we're happy with our current v4 allocations, I think seeing what sort of rates blocks are going for (even if they're anonymized) would be nice. Prefix length and $ would I think be the relevent items. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Nicholas Warren" To: nanog at nanog.org Sent: Tuesday, July 14, 2015 8:19:43 AM Subject: 'gray' market IPv4 Where is one of these v4 markets that we can buy some IPv4 space from? I would prefer to have a place where we could see recent transactions, something along the lines of x amount of addresses for y amount of monies. Google search is failing me for some reason.. - Thanks, Nich From bill at herrin.us Tue Jul 14 13:31:22 2015 From: bill at herrin.us (William Herrin) Date: Tue, 14 Jul 2015 09:31:22 -0400 Subject: 'gray' market IPv4 In-Reply-To: References: Message-ID: On Tue, Jul 14, 2015 at 9:19 AM, Nicholas Warren wrote: > Where is one of these v4 markets that we can buy some IPv4 space from? > Google search is failing me for some reason.. Google "buy IPv4 addresses." The first four links are places facilitating sales. -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From seth.mos at dds.nl Tue Jul 14 13:39:07 2015 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 14 Jul 2015 15:39:07 +0200 Subject: 'gray' market IPv4 Message-ID: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> We had the same thing finding a broker for a /24 pi in the RIPE region. Not all of the brokers have the size you want, eg a /20 when you need a /24. It ends up being between 2500 to 4000 euros depending on notary fees and if you already have a LIR agreement. Cheers -------- Oorspronkelijk bericht --------Van: Nicholas Warren Datum: 14-07-2015 15:19 (GMT+01:00) Aan: nanog at nanog.org Onderwerp: 'gray' market IPv4 Where is one of these v4 markets that we can buy some IPv4 space from? I would prefer to have a place where we could see recent transactions, something along the lines of x amount of addresses for y amount of monies. Google search is failing me for some reason.. - Thanks, Nich From hank at efes.iucc.ac.il Tue Jul 14 13:48:50 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 14 Jul 2015 16:48:50 +0300 Subject: 'gray' market IPv4 In-Reply-To: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> Message-ID: <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> At 15:39 14/07/2015 +0200, Seth Mos wrote: >We had the same thing finding a broker for a /24 pi in the RIPE region. >Not all of the brokers have the size you want, eg a /20 when you need a /24. https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/brokers https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/listing https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers Enuff? -Hank From hannigan at gmail.com Tue Jul 14 14:05:58 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 14 Jul 2015 10:05:58 -0400 Subject: 'gray' market IPv4 In-Reply-To: <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> References: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> Message-ID: On Tue, Jul 14, 2015 at 9:48 AM, Hank Nussbacher wrote: > At 15:39 14/07/2015 +0200, Seth Mos wrote: > >> We had the same thing finding a broker for a /24 pi in the RIPE region. >> Not all of the brokers have the size you want, eg a /20 when you need a /24. >> > > > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/brokers > > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/listing > > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers > > Enuff? > > > /personal opinion, self, etc. Should we enter them all into Yelp and start rating? That's too many to comparison shop. I'm being a little wry, I know who is naughty and nice. I've been tracking them all since the beginning. Not everyone else has. The potential for harm to network operators is moderate IMHO. Best, -M< From lists at mtin.net Tue Jul 14 14:12:12 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Tue, 14 Jul 2015 10:12:12 -0400 Subject: 'gray' market IPv4 In-Reply-To: References: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> Message-ID: Thes folks (and I am not advertising or affiliated with them) publish a list of most recent transfer completed: http://ipv4marketgroup.com/broker-services/buy/ Justin --- Justin Wilson http://www.mtin.net Managed Services ? xISP Solutions ? Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering ? Transit ? Internet Exchange > On Jul 14, 2015, at 10:05 AM, Martin Hannigan wrote: > > On Tue, Jul 14, 2015 at 9:48 AM, Hank Nussbacher > wrote: > >> At 15:39 14/07/2015 +0200, Seth Mos wrote: >> >>> We had the same thing finding a broker for a /24 pi in the RIPE region. >>> Not all of the brokers have the size you want, eg a /20 when you need a /24. >>> >> >> >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/brokers >> >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/listing >> >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers >> >> Enuff? >> >> >> > /personal opinion, self, etc. > > Should we enter them all into Yelp and start rating? That's too many to > comparison shop. I'm being a little wry, I know who is naughty and nice. > I've been tracking them all since the beginning. Not everyone else has. The > potential for harm to network operators is moderate IMHO. > > Best, > > -M< From mjkelly at gmail.com Tue Jul 14 14:22:39 2015 From: mjkelly at gmail.com (Matt Kelly) Date: Tue, 14 Jul 2015 10:22:39 -0400 Subject: 'gray' market IPv4 In-Reply-To: References: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> Message-ID: This list is actual sale prices,?http://www.ipv4auctions.com/previous_auctions/ --? Matt On July 14, 2015 at 10:14:05 AM, Justin Wilson - MTIN (lists at mtin.net) wrote: Thes folks (and I am not advertising or affiliated with them) publish a list of most recent transfer completed: http://ipv4marketgroup.com/broker-services/buy/ Justin --- Justin Wilson http://www.mtin.net Managed Services ? xISP Solutions ? Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering ? Transit ? Internet Exchange > On Jul 14, 2015, at 10:05 AM, Martin Hannigan wrote: > > On Tue, Jul 14, 2015 at 9:48 AM, Hank Nussbacher > wrote: > >> At 15:39 14/07/2015 +0200, Seth Mos wrote: >> >>> We had the same thing finding a broker for a /24 pi in the RIPE region. >>> Not all of the brokers have the size you want, eg a /20 when you need a /24. >>> >> >> >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/brokers >> >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/listing >> >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers >> >> Enuff? >> >> >> > /personal opinion, self, etc. > > Should we enter them all into Yelp and start rating? That's too many to > comparison shop. I'm being a little wry, I know who is naughty and nice. > I've been tracking them all since the beginning. Not everyone else has. The > potential for harm to network operators is moderate IMHO. > > Best, > > -M< From hannigan at gmail.com Tue Jul 14 15:31:51 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 14 Jul 2015 11:31:51 -0400 Subject: 'gray' market IPv4 In-Reply-To: References: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> Message-ID: On Tue, Jul 14, 2015 at 10:22 AM, Matt Kelly wrote: > This list is actual sale prices, > http://www.ipv4auctions.com/previous_auctions/ > > > -- > Matt > > > On July 14, 2015 at 10:14:05 AM, Justin Wilson - MTIN (lists at mtin.net) > wrote: > > Thes folks (and I am not advertising or affiliated with them) publish a > list of most recent transfer completed: > > http://ipv4marketgroup.com/broker-services/buy/ > > http://ipv4marketgroup.com/broker-services/buy/ vs. http://www.ipv4auctions.com/previous_auctions/ If you compare the pricing that both have made available you will find one is posting average prices exponentially higher than the other. When you trend the granular auction site data the auction numbers demonstrate a trend would expect, that smaller prefixes are more expensive since it takes a similar amount of effort to process a /24 as it does a /20. Dollar differences between a /24 unit and a /17 unit move the needle significantly. Based on both of both sets of public data its easy to conclude that auctions will work for at least small buyers of space if they're sophisticated enough to address the RIR issues. If you do decide to take the simple broker approach (not all are simple and not all approaches are suitable to simple brokers), use an RFP. And Yelp. :-) Best, -M< From owen at delong.com Tue Jul 14 16:27:03 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jul 2015 09:27:03 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> Message-ID: <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> I vote for a /24 lotto to get rid of the rest! (just kidding) Owen > On Jul 14, 2015, at 04:37 , Scott, Robert D. wrote: > > If you have been keeping an eye on the ARIN IPV4 countdown, they allocated their last /23 yesterday. There are only 400 /24s in the pool now. > > https://www.arin.net/resources/request/ipv4_countdown.html > > Robert D. Scott Robert at ufl.edu > Network Engineer 3 352-273-0113 Phone > UF Information Technology 321-663-0421 Cell > Network Services 352-273-0743 FAX > University of Florida > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 3216630421 at messaging.sprintpcs.com > > From alh-ietf at tndh.net Tue Jul 14 16:53:17 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 14 Jul 2015 09:53:17 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> Message-ID: <019c01d0be55$95459f90$bfd0deb0$@tndh.net> Owen DeLong wrote: > I vote for a /24 lotto to get rid of the rest! That would take too long to get organized. Just suspend fees and policy requirements and give one to each of the first 400 requestors. Overall it would reduce costs related to evaluating "need", so the lack of fee income would not be a major loss. > > (just kidding) I am not ... It is long past time to move on, so getting rid of the distraction might help with those still holding out hope. Tony > > Owen > > > On Jul 14, 2015, at 04:37 , Scott, Robert D. wrote: > > > > If you have been keeping an eye on the ARIN IPV4 countdown, they > allocated their last /23 yesterday. There are only 400 /24s in the pool now. > > > > https://www.arin.net/resources/request/ipv4_countdown.html > > > > Robert D. Scott Robert at ufl.edu > > Network Engineer 3 352-273-0113 Phone > > UF Information Technology 321-663-0421 Cell > > Network Services 352-273-0743 FAX > > University of Florida > > Florida Lambda Rail 352-294-3571 FLR NOC > > Gainesville, FL 32611 3216630421 at messaging.sprintpcs.com > > > > From owen at delong.com Tue Jul 14 17:00:07 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jul 2015 10:00:07 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> Message-ID: 30 years ago, if you?d told anyone that EVERYONE would be using the internet 30 years ago, they would have looked at you like you were stark raving mad. If you asked anyone 30 years ago ?will 4 billion internet addresses be enough if everyone ends up using the internet??, they all would have told you ?no way.?. I will again repeat? Let?s try liberal allocations until we use up the first /3. I bet we don?t finish that before we hit other scaling limits of IPv6. If I?m wrong and we burn through the first /3 while I am still alive, I will happily help you get more restrictive policy for the remaining 3/4 of the IPv6 address space while we continue to burn through the second /3 as the policy is developed. Owen > On Jul 14, 2015, at 06:23 , George Metz wrote: > > That's all well and good Owen, and the math is compelling, but 30 years ago if you'd told anyone that we'd go through all four billion IPv4 addresses in anyone's lifetime, they'd have looked at you like you were stark raving mad. That's what's really got most of the people who want (dare I say more sane?) more restrictive allocations to be the default concerned; 30 years ago the math for how long IPv4 would last would have been compelling as well, which is why we have the entire Class E block just unusable and large blocks of IP address space that people were handed for no particular reason than it sounded like a good idea at the time. > > It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect. > > On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong > wrote: > How so? > > There are 8192 /16s in the current /3. > > ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person > can?t really be all that many? > > > 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. > > 7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed. > > Really, if we burn through all 8,192 of them in less than 50 years and I?m still alive > when we do, I?ll help you promote more restrictive policy to be enacted while we > burn through the second /3. That?ll still leave us 75% of the address space to work > with on that new policy. > > If you want to look at places where IPv6 is really getting wasted, let?s talk about > an entire /9 reserved without an RFC to make it usable or it?s partner /9 with an > RFC to make it mostly useless, but popular among those few remaining NAT > fanboys. Together that constitutes 1/256th of the address space cast off to > waste. > > Yeah, I?m not too worried about the ISPs that can legitimately justify a /16. > > Owen > > > On Jul 13, 2015, at 16:16 , Joe Maimon > wrote: > > > > > > > > Owen DeLong wrote: > >> JimBob?s ISP can apply to ARIN for a /16 > > > > Like I said, very possibly not a good thing for the address space. > > From alh-ietf at tndh.net Tue Jul 14 17:10:08 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 14 Jul 2015 10:10:08 -0700 Subject: Overlay broad patent on IPv6? In-Reply-To: References: <20150713152551.18531.qmail@ary.lan> <20150713155516.GD27032@lboro.ac.uk> Message-ID: <019d01d0be57$eff41f50$cfdc5df0$@tndh.net> There is prior art here, and likely patents held by HP http://tools.ietf.org/html/draft-bound-dstm-exp-04 > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur > Norddahl > Sent: Monday, July 13, 2015 10:10 AM > To: nanog at nanog.org > Subject: Fwd: Overlay broad patent on IPv6? > > Nah what you describe is a different invention. Someone probably already > has a patent on that. > > The browser will do a DNS lookup on slashdot.org and then cache that - > forever (or until you restart the browser). Yes it will ignore the TTL (apps > don't get the TTL at all, so apps don't know). Same happens if you ssh to > yourserver.someplace.com. One DNS lookup, the traffic sticks there forever > or until the session is terminated. DNS is horrible for this. > > If they had a IPv4 internal private network going you would not need to > hook unto the DNS at all. Just get IP address when something wants to be > routed out the WAN port. Also the NAT table is a good indicator of when > you can release the address again. > > On other words, that would work, but the system described in the patent > app wont. > > Of course both systems are useless. I can not imagine any end user that > wont have a ton of IPv4 going on for the next decade to come. And when > time comes, we are more likely to NAT64 than this. > > Regards, > > Baldur > > > > > > On 13 July 2015 at 18:04, Blake Dunlap wrote: > > > The point is you'd already have a 192 address or something, and it > > would only grab the external address for a short duration for use as > > an external PAT address, thus oversubscribing the ip4 pool to users > > who need it (based on dns). Its still pretty broken, but less broken > > than you describe. > > > > On Mon, Jul 13, 2015 at 8:55 AM, wrote: > > > Hi, > > >> This is actually a good idea. Roll out an IPV6 only network and > > >> only > > pass > > >> out an IPV4 address if it's needed based on actual traffic. > > > > > > yes...shame someones applied for a patent on that! ;-) > > > > > > alan > > From mel at beckman.org Tue Jul 14 17:13:57 2015 From: mel at beckman.org (Mel Beckman) Date: Tue, 14 Jul 2015 17:13:57 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> , Message-ID: Owen, By the same token, who 30 years ago would have said there was anything wrong with giving single companies very liberal /8 allocations? Companies that for the most part wasted that space, leading to a faster exhaustion of IPv4 addresses. History cuts both ways. I think it's reasonable to be at least somewhat judicious with our spanking new IPv6 pool. That's not IPv4-think. That's just reasonable caution. We can always be more generous later. -mel beckman > On Jul 14, 2015, at 10:04 AM, Owen DeLong wrote: > > 30 years ago, if you?d told anyone that EVERYONE would be using the internet 30 years > ago, they would have looked at you like you were stark raving mad. > > If you asked anyone 30 years ago ?will 4 billion internet addresses be enough if everyone > ends up using the internet??, they all would have told you ?no way.?. > > I will again repeat? Let?s try liberal allocations until we use up the first /3. I bet we don?t > finish that before we hit other scaling limits of IPv6. > > If I?m wrong and we burn through the first /3 while I am still alive, I will happily help you > get more restrictive policy for the remaining 3/4 of the IPv6 address space while we > continue to burn through the second /3 as the policy is developed. > > Owen > > >> On Jul 14, 2015, at 06:23 , George Metz wrote: >> >> That's all well and good Owen, and the math is compelling, but 30 years ago if you'd told anyone that we'd go through all four billion IPv4 addresses in anyone's lifetime, they'd have looked at you like you were stark raving mad. That's what's really got most of the people who want (dare I say more sane?) more restrictive allocations to be the default concerned; 30 years ago the math for how long IPv4 would last would have been compelling as well, which is why we have the entire Class E block just unusable and large blocks of IP address space that people were handed for no particular reason than it sounded like a good idea at the time. >> >> It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect. >> >> On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong > wrote: >> How so? >> >> There are 8192 /16s in the current /3. >> >> ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person >> can?t really be all that many? >> >> >> 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. >> >> 7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed. >> >> Really, if we burn through all 8,192 of them in less than 50 years and I?m still alive >> when we do, I?ll help you promote more restrictive policy to be enacted while we >> burn through the second /3. That?ll still leave us 75% of the address space to work >> with on that new policy. >> >> If you want to look at places where IPv6 is really getting wasted, let?s talk about >> an entire /9 reserved without an RFC to make it usable or it?s partner /9 with an >> RFC to make it mostly useless, but popular among those few remaining NAT >> fanboys. Together that constitutes 1/256th of the address space cast off to >> waste. >> >> Yeah, I?m not too worried about the ISPs that can legitimately justify a /16. >> >> Owen >> >>> On Jul 13, 2015, at 16:16 , Joe Maimon > wrote: >>> >>> >>> >>> Owen DeLong wrote: >>>> JimBob?s ISP can apply to ARIN for a /16 >>> >>> Like I said, very possibly not a good thing for the address space. >> >> > From matthew at matthew.at Tue Jul 14 17:22:21 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 14 Jul 2015 10:22:21 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <019c01d0be55$95459f90$bfd0deb0$@tndh.net> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> Message-ID: My proposal to dump the rest of the v4 space this way was rejected as a policy proposal already. Matthew Kaufman (Sent from my iPhone) > On Jul 14, 2015, at 9:53 AM, Tony Hain wrote: > > Owen DeLong wrote: >> I vote for a /24 lotto to get rid of the rest! > > That would take too long to get organized. Just suspend fees and policy > requirements and give one to each of the first 400 requestors. Overall it > would reduce costs related to evaluating "need", so the lack of fee income > would not be a major loss. > >> >> (just kidding) > > I am not ... It is long past time to move on, so getting rid of the > distraction might help with those still holding out hope. > > Tony > >> >> Owen >> >>> On Jul 14, 2015, at 04:37 , Scott, Robert D. wrote: >>> >>> If you have been keeping an eye on the ARIN IPV4 countdown, they >> allocated their last /23 yesterday. There are only 400 /24s in the pool > now. >>> >>> https://www.arin.net/resources/request/ipv4_countdown.html >>> >>> Robert D. Scott Robert at ufl.edu >>> Network Engineer 3 352-273-0113 Phone >>> UF Information Technology 321-663-0421 Cell >>> Network Services 352-273-0743 FAX >>> University of Florida >>> Florida Lambda Rail 352-294-3571 FLR NOC >>> Gainesville, FL 32611 3216630421 at messaging.sprintpcs.com > From owen at delong.com Tue Jul 14 17:30:23 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jul 2015 10:30:23 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> Message-ID: You don?t think holding nearly 7/8ths of the address space in reserve for a future addressing policy is adequate judiciuosness? The IPv4 /8s constituted 1/2 of the address space. The /16s another 1/4, and the /24s an additional 1/8th at the time. Overall, that was 7/8ths of the address space assigned to unicast and 9/16ths allocated if you included multicast. In IPv6, we have 1/8th set aside for unicast, 1/256th for multicast, 1/256th for ULA, 1/1024th for link-local, and a couple of infinitesimal fractions set aside for other things like localhost, IPV6_ADDR_ANY, etc. As I said, let?s be liberal as designed with the first /3. If I?m wrong and you can prove it in my remaining lifetime, I will happily help you develop more restrictive allocation policy for the remaining 3/4 while the second /3 is used to continue growing the IPv6 internet. Whatever unexpected thing causes us to finish off the first /3 likely won?t burn through the second /3 before we can respond with new policy. We still have almost 3/4 of the address space available for more restrictive allocations. Frankly, I bet about 1/8th of the IPv4 address space probably is in the hands of the top 64 organizations. Maybe more. In this case, 1/8th of the address space will more than cover the entire known need many many many times over, even with very liberal allocations. Owen > On Jul 14, 2015, at 10:13 , Mel Beckman wrote: > > Owen, > > By the same token, who 30 years ago would have said there was anything wrong with giving single companies very liberal /8 allocations? Companies that for the most part wasted that space, leading to a faster exhaustion of IPv4 addresses. History cuts both ways. > > I think it's reasonable to be at least somewhat judicious with our spanking new IPv6 pool. That's not IPv4-think. That's just reasonable caution. > > We can always be more generous later. > > -mel beckman > >> On Jul 14, 2015, at 10:04 AM, Owen DeLong wrote: >> >> 30 years ago, if you?d told anyone that EVERYONE would be using the internet 30 years >> ago, they would have looked at you like you were stark raving mad. >> >> If you asked anyone 30 years ago ?will 4 billion internet addresses be enough if everyone >> ends up using the internet??, they all would have told you ?no way.?. >> >> I will again repeat? Let?s try liberal allocations until we use up the first /3. I bet we don?t >> finish that before we hit other scaling limits of IPv6. >> >> If I?m wrong and we burn through the first /3 while I am still alive, I will happily help you >> get more restrictive policy for the remaining 3/4 of the IPv6 address space while we >> continue to burn through the second /3 as the policy is developed. >> >> Owen >> >> >>> On Jul 14, 2015, at 06:23 , George Metz wrote: >>> >>> That's all well and good Owen, and the math is compelling, but 30 years ago if you'd told anyone that we'd go through all four billion IPv4 addresses in anyone's lifetime, they'd have looked at you like you were stark raving mad. That's what's really got most of the people who want (dare I say more sane?) more restrictive allocations to be the default concerned; 30 years ago the math for how long IPv4 would last would have been compelling as well, which is why we have the entire Class E block just unusable and large blocks of IP address space that people were handed for no particular reason than it sounded like a good idea at the time. >>> >>> It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect. >>> >>> On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong > wrote: >>> How so? >>> >>> There are 8192 /16s in the current /3. >>> >>> ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person >>> can?t really be all that many? >>> >>> >>> 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. >>> >>> 7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed. >>> >>> Really, if we burn through all 8,192 of them in less than 50 years and I?m still alive >>> when we do, I?ll help you promote more restrictive policy to be enacted while we >>> burn through the second /3. That?ll still leave us 75% of the address space to work >>> with on that new policy. >>> >>> If you want to look at places where IPv6 is really getting wasted, let?s talk about >>> an entire /9 reserved without an RFC to make it usable or it?s partner /9 with an >>> RFC to make it mostly useless, but popular among those few remaining NAT >>> fanboys. Together that constitutes 1/256th of the address space cast off to >>> waste. >>> >>> Yeah, I?m not too worried about the ISPs that can legitimately justify a /16. >>> >>> Owen >>> >>>> On Jul 13, 2015, at 16:16 , Joe Maimon > wrote: >>>> >>>> >>>> >>>> Owen DeLong wrote: >>>>> JimBob?s ISP can apply to ARIN for a /16 >>>> >>>> Like I said, very possibly not a good thing for the address space. >>> >>> >> From geoffk at geoffk.org Tue Jul 14 18:28:06 2015 From: geoffk at geoffk.org (Geoffrey Keating) Date: 14 Jul 2015 11:28:06 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <019c01d0be55$95459f90$bfd0deb0$@tndh.net> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> Message-ID: "Tony Hain" writes: > Owen DeLong wrote: > > I vote for a /24 lotto to get rid of the rest! > > That would take too long to get organized. Just suspend fees and policy > requirements and give one to each of the first 400 requestors. Overall it > would reduce costs related to evaluating "need", so the lack of fee income > would not be a major loss. > > > > > (just kidding) > > I am not ... It is long past time to move on, so getting rid of the > distraction might help with those still holding out hope. It won't be long, ARIN has been processing over 350 IPv4 requests each of the last few months. From johnl at iecc.com Tue Jul 14 18:44:25 2015 From: johnl at iecc.com (John Levine) Date: 14 Jul 2015 18:44:25 -0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Message-ID: <20150714184425.24695.qmail@ary.lan> >I think it's reasonable to be at least somewhat judicious with our >spanking new IPv6 pool. That's not IPv4-think. That's just reasonable >caution. It's optimizing for the wrong thing. While the supply of IPv6 addresses exceeds any plausible demand, the supply of route slots in routers does not. The right way to allocate v6 space is the first time someone asks for some, give them as much as they'll ever need. If you give them less and they have to come back for more later, you've wasted a router slot. In theory one can renumber into a larger block and abandon or return the old block, but in a world where the value of used IPv6 space is $0, how likely is that? >We can always be more generous later. Too late. R's, John From alh-ietf at tndh.net Tue Jul 14 18:56:34 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 14 Jul 2015 11:56:34 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> , Message-ID: <01c401d0be66$ce0b40d0$6a21c270$@tndh.net> Mel Beckman wrote: > Owen, > > By the same token, who 30 years ago would have said there was anything > wrong with giving single companies very liberal /8 allocations? Actually 30 years ago it was very difficult to get a /8 even for a US Gov organization. I have firsthand experience with being refused. As much as people on this list like to paint a fantasy about 'the liberal policies of the good-old- days' it was not as wild and loose as it is often made out to be. 40 years ago it was easier to get a /8 than it was 30 year ago, but there were still restrictions. At the end of the day, your impact on the routing system determined which bucket you were put in, because the global routing table was the scarce resource that needed management. > Companies > that for the most part wasted that space, leading to a faster exhaustion of > IPv4 addresses. History cuts both ways. Call it waste if you want, but it is more likely that it was just allocation a decade ahead of need, and that need would likely not have developed if the global routing system collapsed due to too many /16's being allocated before routers could handle that. > > I think it's reasonable to be at least somewhat judicious with our spanking > new IPv6 pool. That's not IPv4-think. That's just reasonable caution. "Reasonable caution" was only allocating 1/8th of the space up front, and recommending that end sites be limited to a /48 without justifying more (rfc 3177). "IPv4-think" is refusing to acknowledge the math, and insisting that just because the average consumer has been limited to a single subnet for the last 15 years, that it was all they will ever need. Rewind the clock 16 years and you found that the restriction was a single mac-address, because 'nobody needs anything more than a single computer'. CPE developers have to manage their costs, and they will build to the limits of what is available across the majority of providers. When that is artificially restricted by unnecessary "IPv4-think" conservation, you will build a deployed base that has limited capability. Just as it is still taking time to remove the deployed base of IPv4-only cpe, getting rid of limitations will be slow, difficult, and costly. Fast forward 30 years, and the network managers of the day will be asking why the clowns who insisted on such an artificially restricted allocation model could be so short sighted because they will not have been tainted by or understand "IPv4-think". IPv6 is not the last protocol known to mankind. IF it burns out in 400-500 years, something will have gone terribly wrong, because newer ideas about networking will have been squashed along the way. 64 bits for both hosts and routing was over 3 orders of magnitude more than sufficient to meet the design goals for the IPv4 replacement, but in the context of the dot-com bubble there was a vast outcry from the ops community that it would be insufficient for the needs of routing. So the entire 64 bits of the original proposal was given to routing, and the IETF spent another year arguing about how many bits more to add for hosts. Now, post bubble burst, we are left with 32,768x the already more than sufficient number of routing prefixes, but "IPv4-think" conservation believes we still need to be extremely conservative about allocations. Tony > > We can always be more generous later. > > -mel beckman > > > On Jul 14, 2015, at 10:04 AM, Owen DeLong wrote: > > > > 30 years ago, if you'd told anyone that EVERYONE would be using the > > internet 30 years ago, they would have looked at you like you were stark > raving mad. > > > > If you asked anyone 30 years ago "will 4 billion internet addresses be > > enough if everyone ends up using the internet?", they all would have told > you "no way.". > > > > I will again repeat. Let's try liberal allocations until we use up the > > first /3. I bet we don't finish that before we hit other scaling limits of IPv6. > > > > If I'm wrong and we burn through the first /3 while I am still alive, > > I will happily help you get more restrictive policy for the remaining > > 3/4 of the IPv6 address space while we continue to burn through the > second /3 as the policy is developed. > > > > Owen > > > > > >> On Jul 14, 2015, at 06:23 , George Metz wrote: > >> > >> That's all well and good Owen, and the math is compelling, but 30 years > ago if you'd told anyone that we'd go through all four billion IPv4 addresses > in anyone's lifetime, they'd have looked at you like you were stark raving > mad. That's what's really got most of the people who want (dare I say more > sane?) more restrictive allocations to be the default concerned; 30 years ago > the math for how long IPv4 would last would have been compelling as well, > which is why we have the entire Class E block just unusable and large blocks > of IP address space that people were handed for no particular reason than it > sounded like a good idea at the time. > >> > >> It's always easier to be prudent from the get-go than it is to rein in the > insanity at a later date. Just because we can't imagine a world where IPv6 > depletion is possible doesn't mean it can't exist, and exist far sooner than > one might expect. > >> > >> On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong > wrote: > >> How so? > >> > >> There are 8192 /16s in the current /3. > >> > >> ISPs with that many pops at 5,000,000 end-sites per POP, even > >> assuming 32 end-sites per person can't really be all that many. > >> > >> > >> 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. > >> > >> 7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s > consumed. > >> > >> Really, if we burn through all 8,192 of them in less than 50 years > >> and I'm still alive when we do, I'll help you promote more > >> restrictive policy to be enacted while we burn through the second /3. > >> That'll still leave us 75% of the address space to work with on that new > policy. > >> > >> If you want to look at places where IPv6 is really getting wasted, > >> let's talk about an entire /9 reserved without an RFC to make it > >> usable or it's partner /9 with an RFC to make it mostly useless, but > >> popular among those few remaining NAT fanboys. Together that > >> constitutes 1/256th of the address space cast off to waste. > >> > >> Yeah, I'm not too worried about the ISPs that can legitimately justify a > /16. > >> > >> Owen > >> > >>> On Jul 13, 2015, at 16:16 , Joe Maimon > wrote: > >>> > >>> > >>> > >>> Owen DeLong wrote: > >>>> JimBob's ISP can apply to ARIN for a /16 > >>> > >>> Like I said, very possibly not a good thing for the address space. > >> > >> > > From nwarren at barryelectric.com Tue Jul 14 19:33:19 2015 From: nwarren at barryelectric.com (Nicholas Warren) Date: Tue, 14 Jul 2015 19:33:19 +0000 Subject: M$ no v6 or just me? Message-ID: Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, or is Microsoft not available over v6? Thanks, Nich From mel at beckman.org Tue Jul 14 19:35:46 2015 From: mel at beckman.org (Mel Beckman) Date: Tue, 14 Jul 2015 19:35:46 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> , Message-ID: <0C521EF9-B55B-4F3A-9E9F-F4F5B918C467@beckman.org> I have no problems with ISPs giving out /48s to residential subscribers. Neither do I mind if they give out /56s. That still gives every residential customer 256 /64 subnets. I don't see this as something that needs to become a standard. Those end-users who want more can ask for more fro their ISP whenever the need arises. If there is a market for selling those larger prefixes to end users, that's free enterprise, which I also support. I don't think it's wise to delegate by rule or convention that the entire first 1/8th of IPv6 space should be delegated in /48s. You see this as not a huge deal. To me, 12.5% is a huge deal. I appreciate your offer to give your services away for free to remedy any problems the /3 bolus creates. But as history has shown, neither of us is likely to be in circulation -- or even alive -- when a problem would occur. -mel beckman > On Jul 14, 2015, at 10:30 AM, Owen DeLong wrote: > > You don?t think holding nearly 7/8ths of the address space in reserve for a future addressing policy is adequate judiciuosness? > > The IPv4 /8s constituted 1/2 of the address space. The /16s another 1/4, and the /24s an additional 1/8th at the time. > Overall, that was 7/8ths of the address space assigned to unicast and 9/16ths allocated if you included multicast. > > In IPv6, we have 1/8th set aside for unicast, 1/256th for multicast, 1/256th for ULA, 1/1024th for link-local, and > a couple of infinitesimal fractions set aside for other things like localhost, IPV6_ADDR_ANY, etc. > > As I said, let?s be liberal as designed with the first /3. If I?m wrong and you can prove it in my remaining lifetime, I will happily > help you develop more restrictive allocation policy for the remaining 3/4 while the second /3 is used to continue growing the > IPv6 internet. > > Whatever unexpected thing causes us to finish off the first /3 likely won?t burn through the second /3 before we can > respond with new policy. We still have almost 3/4 of the address space available for more restrictive allocations. > > Frankly, I bet about 1/8th of the IPv4 address space probably is in the hands of the top 64 organizations. Maybe more. > > In this case, 1/8th of the address space will more than cover the entire known need many many many times over, even > with very liberal allocations. > > Owen > >> On Jul 14, 2015, at 10:13 , Mel Beckman wrote: >> >> Owen, >> >> By the same token, who 30 years ago would have said there was anything wrong with giving single companies very liberal /8 allocations? Companies that for the most part wasted that space, leading to a faster exhaustion of IPv4 addresses. History cuts both ways. >> >> I think it's reasonable to be at least somewhat judicious with our spanking new IPv6 pool. That's not IPv4-think. That's just reasonable caution. >> >> We can always be more generous later. >> >> -mel beckman >> >>> On Jul 14, 2015, at 10:04 AM, Owen DeLong wrote: >>> >>> 30 years ago, if you?d told anyone that EVERYONE would be using the internet 30 years >>> ago, they would have looked at you like you were stark raving mad. >>> >>> If you asked anyone 30 years ago ?will 4 billion internet addresses be enough if everyone >>> ends up using the internet??, they all would have told you ?no way.?. >>> >>> I will again repeat? Let?s try liberal allocations until we use up the first /3. I bet we don?t >>> finish that before we hit other scaling limits of IPv6. >>> >>> If I?m wrong and we burn through the first /3 while I am still alive, I will happily help you >>> get more restrictive policy for the remaining 3/4 of the IPv6 address space while we >>> continue to burn through the second /3 as the policy is developed. >>> >>> Owen >>> >>> >>>> On Jul 14, 2015, at 06:23 , George Metz wrote: >>>> >>>> That's all well and good Owen, and the math is compelling, but 30 years ago if you'd told anyone that we'd go through all four billion IPv4 addresses in anyone's lifetime, they'd have looked at you like you were stark raving mad. That's what's really got most of the people who want (dare I say more sane?) more restrictive allocations to be the default concerned; 30 years ago the math for how long IPv4 would last would have been compelling as well, which is why we have the entire Class E block just unusable and large blocks of IP address space that people were handed for no particular reason than it sounded like a good idea at the time. >>>> >>>> It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect. >>>> >>>> On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong > wrote: >>>> How so? >>>> >>>> There are 8192 /16s in the current /3. >>>> >>>> ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person >>>> can?t really be all that many? >>>> >>>> >>>> 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. >>>> >>>> 7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed. >>>> >>>> Really, if we burn through all 8,192 of them in less than 50 years and I?m still alive >>>> when we do, I?ll help you promote more restrictive policy to be enacted while we >>>> burn through the second /3. That?ll still leave us 75% of the address space to work >>>> with on that new policy. >>>> >>>> If you want to look at places where IPv6 is really getting wasted, let?s talk about >>>> an entire /9 reserved without an RFC to make it usable or it?s partner /9 with an >>>> RFC to make it mostly useless, but popular among those few remaining NAT >>>> fanboys. Together that constitutes 1/256th of the address space cast off to >>>> waste. >>>> >>>> Yeah, I?m not too worried about the ISPs that can legitimately justify a /16. >>>> >>>> Owen >>>> >>>>> On Jul 13, 2015, at 16:16 , Joe Maimon > wrote: >>>>> >>>>> >>>>> >>>>> Owen DeLong wrote: >>>>>> JimBob?s ISP can apply to ARIN for a /16 >>>>> >>>>> Like I said, very possibly not a good thing for the address space. > From Valdis.Kletnieks at vt.edu Tue Jul 14 19:35:36 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 14 Jul 2015 15:35:36 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "14 Jul 2015 18:44:25 -0000." <20150714184425.24695.qmail@ary.lan> References: <20150714184425.24695.qmail@ary.lan> Message-ID: <23735.1436902536@turing-police.cc.vt.edu> On 14 Jul 2015 18:44:25 -0000, "John Levine" said: > routers does not. The right way to allocate v6 space is the first > time someone asks for some, give them as much as they'll ever need. > If you give them less and they have to come back for more later, > you've wasted a router slot. Amen. Integers are cheap. FIB slots cost real money. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From josh at imaginenetworksllc.com Tue Jul 14 19:37:20 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 14 Jul 2015 15:37:20 -0400 Subject: M$ no v6 or just me? In-Reply-To: References: Message-ID: There is C:\Users\jluthman>dig -t aaaa www.microsoft.com +short toggle.www.ms.akadns.net. www.microsoft.com-c.edgekey.net. www.microsoft.com-c.edgekey.net.globalredir.akadns.net. e10088.dspb.akamaiedge.net. 2600:1407:10:390::2768 2600:1407:10:389::2768 Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Jul 14, 2015 at 3:33 PM, Nicholas Warren wrote: > Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, or > is Microsoft not available over v6? > > Thanks, > Nich > > From jared at puck.Nether.net Tue Jul 14 19:39:35 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 14 Jul 2015 15:39:35 -0400 Subject: M$ no v6 or just me? In-Reply-To: References: Message-ID: <20150714193935.GA12072@puck.nether.net> www.microsoft.com seems to pass these checks for me: http://ipv6-test.com/validate.php Perhaps they have some other site that doesn't have it enabled? - Jared On Tue, Jul 14, 2015 at 07:33:19PM +0000, Nicholas Warren wrote: > Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, or is Microsoft not available over v6? > > Thanks, > Nich -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From dan at drakontas.org Tue Jul 14 19:43:01 2015 From: dan at drakontas.org (Daniel C. Eckert) Date: Tue, 14 Jul 2015 12:43:01 -0700 Subject: M$ no v6 or just me? In-Reply-To: References: Message-ID: Which property are you trying to access? Bing? Azure? O365? Something else? On Jul 14, 2015 12:34 PM, "Nicholas Warren" wrote: > Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, or > is Microsoft not available over v6? > > Thanks, > Nich > > From mel at beckman.org Tue Jul 14 19:43:50 2015 From: mel at beckman.org (Mel Beckman) Date: Tue, 14 Jul 2015 19:43:50 +0000 Subject: M$ no v6 or just me? In-Reply-To: References: Message-ID: Microsoft is highly IPv6 connected. nslookup >set type=AAAA >www.microsoft.com. Server: 206.83.0.42 Address: 206.83.0.42#53 Non-authoritative answer: www.microsoft.com canonical name = toggle.www.ms.akadns.net. toggle.www.ms.akadns.net canonical name = www.microsoft.com-c.edgekey.net. www.microsoft.com-c.edgekey.net canonical name = www.microsoft.com-c.edgekey.net.globalredir.akadns.net. www.microsoft.com-c.edgekey.net.globalredir.akadns.net canonical name = e10088.dspb.akamaiedge.net. e10088.dspb.akamaiedge.net has AAAA address 2600:1406:34:280::2768 e10088.dspb.akamaiedge.net has AAAA address 2600:1406:34:288::2768 What did you lookup? -mel beckman > On Jul 14, 2015, at 12:34 PM, Nicholas Warren wrote: > > Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, or is Microsoft not available over v6? > > Thanks, > Nich > From johnl at iecc.com Tue Jul 14 19:44:06 2015 From: johnl at iecc.com (John Levine) Date: 14 Jul 2015 19:44:06 -0000 Subject: M$ no v6 or just me? In-Reply-To: Message-ID: <20150714194406.24874.qmail@ary.lan> In article you write: >Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, or is Microsoft not available over v6? Looks like it's your DNS. ; <<>> DiG 9.10.2-P2 <<>> www.microsoft.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16645 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.microsoft.com. IN AAAA ;; ANSWER SECTION: www.microsoft.com. 3559 IN CNAME toggle.www.ms.akadns.net. toggle.www.ms.akadns.net. 260 IN CNAME www.microsoft.com-c.edgekey.net. www.microsoft.com-c.edgekey.net. 21560 IN CNAME www.microsoft.com-c.edgekey.net.globalredir.akadns.net. www.microsoft.com-c.edgekey.net.globalredir.akadns.net. 3560 IN CNAME e10088.dspb.akamaiedge.net. e10088.dspb.akamaiedge.net. 9 IN AAAA 2600:1408:10:18f::2768 From mel at beckman.org Tue Jul 14 19:45:42 2015 From: mel at beckman.org (Mel Beckman) Date: Tue, 14 Jul 2015 19:45:42 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <23735.1436902536@turing-police.cc.vt.edu> References: <20150714184425.24695.qmail@ary.lan>, <23735.1436902536@turing-police.cc.vt.edu> Message-ID: <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> We're talking about end user assignments made by ISPs, not ISP assignments. An ISP's /32 is likely the only entry one needs in the FIB. -mel beckman > On Jul 14, 2015, at 12:41 PM, "Valdis.Kletnieks at vt.edu" wrote: > > On 14 Jul 2015 18:44:25 -0000, "John Levine" said: > >> routers does not. The right way to allocate v6 space is the first >> time someone asks for some, give them as much as they'll ever need. >> If you give them less and they have to come back for more later, >> you've wasted a router slot. > > Amen. Integers are cheap. FIB slots cost real money. From jimpop at gmail.com Tue Jul 14 19:48:49 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Tue, 14 Jul 2015 15:48:49 -0400 Subject: M$ no v6 or just me? In-Reply-To: References: Message-ID: On Tue, Jul 14, 2015 at 3:37 PM, Josh Luthman wrote: > There is And there isn't ~$ dig -t AAAA www.microsoft.com +short toggle.www.ms.akadns.net. www.microsoft.com-c.edgekey.net. www.microsoft.com-c.edgekey.net.globalredir.akadns.net. e10088.dspb.akamaiedge.net. ~$ host e10088.dspb.akamaiedge.net e10088.dspb.akamaiedge.net has address 23.220.92.16 -Jim P. From mark at viviotech.net Tue Jul 14 19:50:10 2015 From: mark at viviotech.net (Mark Keymer) Date: Tue, 14 Jul 2015 12:50:10 -0700 Subject: M$ no v6 or just me? In-Reply-To: <20150714193935.GA12072@puck.nether.net> References: <20150714193935.GA12072@puck.nether.net> Message-ID: <55A567F2.9010401@viviotech.net> I agree that www.microsoft.com passes. But it looks like microsoft.com does not. sincerely, Mark Keymer CFO/COO Vivio Technologies On 7/14/2015 12:39 PM, Jared Mauch wrote: > www.microsoft.com seems to pass these checks for me: > > http://ipv6-test.com/validate.php > > Perhaps they have some other site that doesn't have it enabled? > > - Jared > > On Tue, Jul 14, 2015 at 07:33:19PM +0000, Nicholas Warren wrote: >> Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, or is Microsoft not available over v6? >> >> Thanks, >> Nich From jimpop at gmail.com Tue Jul 14 19:53:29 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Tue, 14 Jul 2015 15:53:29 -0400 Subject: M$ no v6 or just me? In-Reply-To: References: Message-ID: On Tue, Jul 14, 2015 at 3:48 PM, Jim Popovitch wrote: > On Tue, Jul 14, 2015 at 3:37 PM, Josh Luthman > wrote: >> There is > > And there isn't > > ~$ dig -t AAAA www.microsoft.com +short > toggle.www.ms.akadns.net. > www.microsoft.com-c.edgekey.net. > www.microsoft.com-c.edgekey.net.globalredir.akadns.net. > e10088.dspb.akamaiedge.net. > > ~$ host e10088.dspb.akamaiedge.net > e10088.dspb.akamaiedge.net has address 23.220.92.16 > BTW, the issue is Google Public DNS: ~$ dig -t AAAA www.microsoft.com +short @2001:4860:4860::8888 toggle.www.ms.akadns.net. www.microsoft.com-c.edgekey.net. www.microsoft.com-c.edgekey.net.globalredir.akadns.net. e10088.dspb.akamaiedge.net. 2600:1408:17:28e::2768 2600:1408:17:280::2768 ~$ dig -t AAAA www.microsoft.com +short @8.8.8.8 toggle.www.ms.akadns.net. www.microsoft.com-c.edgekey.net. www.microsoft.com-c.edgekey.net.globalredir.akadns.net. e10088.dspb.akamaiedge.net. -Jim P. From johnl at iecc.com Tue Jul 14 19:53:56 2015 From: johnl at iecc.com (John R. Levine) Date: 14 Jul 2015 15:53:56 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> References: <20150714184425.24695.qmail@ary.lan>, <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> Message-ID: > We're talking about end user assignments made by ISPs, not ISP > assignments. An ISP's /32 is likely the only entry one needs in the FIB. In that case, why should anyone care how the ISP assigns space to its customers? R's, John From Valdis.Kletnieks at vt.edu Tue Jul 14 19:53:41 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 14 Jul 2015 15:53:41 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Tue, 14 Jul 2015 19:45:42 -0000." <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> References: <20150714184425.24695.qmail@ary.lan>, <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> Message-ID: <25137.1436903621@turing-police.cc.vt.edu> On Tue, 14 Jul 2015 19:45:42 -0000, Mel Beckman said: > We're talking about end user assignments made by ISPs, not ISP assignments. Do the math for how big a chunk Comcast needs, assuming they give each residential customer a /60, or a /56, or a /48. If their first chunk was sized based on ubiquitous /56s and it turns out /48 would have been better, they may need another trip to the well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From owen at delong.com Tue Jul 14 19:56:58 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jul 2015 12:56:58 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <0C521EF9-B55B-4F3A-9E9F-F4F5B918C467@beckman.org> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <0C521EF9-B55B-4F3A-9E9F-F4F5B918C467@beckman.org> Message-ID: <704F396F-A70E-4DE4-B938-3EAA275AB4C2@delong.com> I expect to be actively involved at least 20 more years. If I'm not around, thats 160 years to runout. I'm betting the protocol can't live that long for other reasons. Owen > On Jul 14, 2015, at 12:35, Mel Beckman wrote: > > I have no problems with ISPs giving out /48s to residential subscribers. Neither do I mind if they give out /56s. That still gives every residential customer 256 /64 subnets. > > I don't see this as something that needs to become a standard. Those end-users who want more can ask for more fro their ISP whenever the need arises. If there is a market for selling those larger prefixes to end users, that's free enterprise, which I also support. > > I don't think it's wise to delegate by rule or convention that the entire first 1/8th of IPv6 space should be delegated in /48s. You see this as not a huge deal. To me, 12.5% is a huge deal. > > I appreciate your offer to give your services away for free to remedy any problems the /3 bolus creates. But as history has shown, neither of us is likely to be in circulation -- or even alive -- when a problem would occur. > > -mel beckman > >> On Jul 14, 2015, at 10:30 AM, Owen DeLong wrote: >> >> You don?t think holding nearly 7/8ths of the address space in reserve for a future addressing policy is adequate judiciuosness? >> >> The IPv4 /8s constituted 1/2 of the address space. The /16s another 1/4, and the /24s an additional 1/8th at the time. >> Overall, that was 7/8ths of the address space assigned to unicast and 9/16ths allocated if you included multicast. >> >> In IPv6, we have 1/8th set aside for unicast, 1/256th for multicast, 1/256th for ULA, 1/1024th for link-local, and >> a couple of infinitesimal fractions set aside for other things like localhost, IPV6_ADDR_ANY, etc. >> >> As I said, let?s be liberal as designed with the first /3. If I?m wrong and you can prove it in my remaining lifetime, I will happily >> help you develop more restrictive allocation policy for the remaining 3/4 while the second /3 is used to continue growing the >> IPv6 internet. >> >> Whatever unexpected thing causes us to finish off the first /3 likely won?t burn through the second /3 before we can >> respond with new policy. We still have almost 3/4 of the address space available for more restrictive allocations. >> >> Frankly, I bet about 1/8th of the IPv4 address space probably is in the hands of the top 64 organizations. Maybe more. >> >> In this case, 1/8th of the address space will more than cover the entire known need many many many times over, even >> with very liberal allocations. >> >> Owen >> >>> On Jul 14, 2015, at 10:13 , Mel Beckman wrote: >>> >>> Owen, >>> >>> By the same token, who 30 years ago would have said there was anything wrong with giving single companies very liberal /8 allocations? Companies that for the most part wasted that space, leading to a faster exhaustion of IPv4 addresses. History cuts both ways. >>> >>> I think it's reasonable to be at least somewhat judicious with our spanking new IPv6 pool. That's not IPv4-think. That's just reasonable caution. >>> >>> We can always be more generous later. >>> >>> -mel beckman >>> >>>> On Jul 14, 2015, at 10:04 AM, Owen DeLong wrote: >>>> >>>> 30 years ago, if you?d told anyone that EVERYONE would be using the internet 30 years >>>> ago, they would have looked at you like you were stark raving mad. >>>> >>>> If you asked anyone 30 years ago ?will 4 billion internet addresses be enough if everyone >>>> ends up using the internet??, they all would have told you ?no way.?. >>>> >>>> I will again repeat? Let?s try liberal allocations until we use up the first /3. I bet we don?t >>>> finish that before we hit other scaling limits of IPv6. >>>> >>>> If I?m wrong and we burn through the first /3 while I am still alive, I will happily help you >>>> get more restrictive policy for the remaining 3/4 of the IPv6 address space while we >>>> continue to burn through the second /3 as the policy is developed. >>>> >>>> Owen >>>> >>>> >>>>> On Jul 14, 2015, at 06:23 , George Metz wrote: >>>>> >>>>> That's all well and good Owen, and the math is compelling, but 30 years ago if you'd told anyone that we'd go through all four billion IPv4 addresses in anyone's lifetime, they'd have looked at you like you were stark raving mad. That's what's really got most of the people who want (dare I say more sane?) more restrictive allocations to be the default concerned; 30 years ago the math for how long IPv4 would last would have been compelling as well, which is why we have the entire Class E block just unusable and large blocks of IP address space that people were handed for no particular reason than it sounded like a good idea at the time. >>>>> >>>>> It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect. >>>>> >>>>> On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong > wrote: >>>>> How so? >>>>> >>>>> There are 8192 /16s in the current /3. >>>>> >>>>> ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 end-sites per person >>>>> can?t really be all that many? >>>>> >>>>> >>>>> 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. >>>>> >>>>> 7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s consumed. >>>>> >>>>> Really, if we burn through all 8,192 of them in less than 50 years and I?m still alive >>>>> when we do, I?ll help you promote more restrictive policy to be enacted while we >>>>> burn through the second /3. That?ll still leave us 75% of the address space to work >>>>> with on that new policy. >>>>> >>>>> If you want to look at places where IPv6 is really getting wasted, let?s talk about >>>>> an entire /9 reserved without an RFC to make it usable or it?s partner /9 with an >>>>> RFC to make it mostly useless, but popular among those few remaining NAT >>>>> fanboys. Together that constitutes 1/256th of the address space cast off to >>>>> waste. >>>>> >>>>> Yeah, I?m not too worried about the ISPs that can legitimately justify a /16. >>>>> >>>>> Owen >>>>> >>>>>> On Jul 13, 2015, at 16:16 , Joe Maimon > wrote: >>>>>> >>>>>> >>>>>> >>>>>> Owen DeLong wrote: >>>>>>> JimBob?s ISP can apply to ARIN for a /16 >>>>>> >>>>>> Like I said, very possibly not a good thing for the address space. >> From tony at lavanauts.org Tue Jul 14 20:02:52 2015 From: tony at lavanauts.org (Antonio Querubin) Date: Tue, 14 Jul 2015 10:02:52 -1000 (HST) Subject: M$ no v6 or just me? In-Reply-To: <20150714193935.GA12072@puck.nether.net> References: <20150714193935.GA12072@puck.nether.net> Message-ID: On Tue, 14 Jul 2015, Jared Mauch wrote: > www.microsoft.com seems to pass these checks for me: > > http://ipv6-test.com/validate.php > > Perhaps they have some other site that doesn't have it enabled? http://www.mrp.net/cgi-bin/ipv6-status.cgi SMTP fails for both microsoft.com and xbox.com live.com has only DNS. bing.com is a total fail. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From A.L.M.Buxey at lboro.ac.uk Tue Jul 14 20:30:02 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Tue, 14 Jul 2015 20:30:02 +0000 Subject: M$ no v6 or just me? In-Reply-To: References: Message-ID: <20150714203002.GB31815@lboro.ac.uk> Hi, > And there isn't its your DNS ;-) host e10088.dspb.akamaiedge.net e10088.dspb.akamaiedge.net has address 104.70.251.201 e10088.dspb.akamaiedge.net has IPv6 address 2a02:26f0:cb:2a4::2768 e10088.dspb.akamaiedge.net has IPv6 address 2a02:26f0:cb:29a::2768 alan From A.L.M.Buxey at lboro.ac.uk Tue Jul 14 20:31:09 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Tue, 14 Jul 2015 20:31:09 +0000 Subject: M$ no v6 or just me? In-Reply-To: References: <20150714193935.GA12072@puck.nether.net> Message-ID: <20150714203109.GC31815@lboro.ac.uk> Hi, however...this revelation is shocking...my users can access www.microsoft.com material via IPv6?? turn this filth off!! ;-) alan From mel at beckman.org Tue Jul 14 20:32:35 2015 From: mel at beckman.org (Mel Beckman) Date: Tue, 14 Jul 2015 20:32:35 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <25137.1436903621@turing-police.cc.vt.edu> References: <20150714184425.24695.qmail@ary.lan>, <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org>, <25137.1436903621@turing-police.cc.vt.edu> Message-ID: Ok. Two RIB entries for Comcast. Your argument doesn't scale. -mel via cell On Jul 14, 2015, at 12:53 PM, "Valdis.Kletnieks at vt.edu" > wrote: On Tue, 14 Jul 2015 19:45:42 -0000, Mel Beckman said: We're talking about end user assignments made by ISPs, not ISP assignments. Do the math for how big a chunk Comcast needs, assuming they give each residential customer a /60, or a /56, or a /48. If their first chunk was sized based on ubiquitous /56s and it turns out /48 would have been better, they may need another trip to the well. From jimpop at gmail.com Tue Jul 14 20:33:12 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Tue, 14 Jul 2015 16:33:12 -0400 Subject: M$ no v6 or just me? In-Reply-To: <20150714203002.GB31815@lboro.ac.uk> References: <20150714203002.GB31815@lboro.ac.uk> Message-ID: On Tue, Jul 14, 2015 at 4:30 PM, wrote: > Hi, > >> And there isn't > > > its your DNS ;-) No. My DNS (using the roots) gets it right. ;-) The failure is somewhere between Google Public DNS's IPv4 servers and Akamai. See my earlier post. -Jim P. From chuckchurch at gmail.com Tue Jul 14 20:47:33 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 14 Jul 2015 16:47:33 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150714184425.24695.qmail@ary.lan>, <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org>, <25137.1436903621@turing-police.cc.vt.edu> Message-ID: <002f01d0be76$52b0c800$f8125800$@gmail.com> What about dual-homed customers? Or are they all expected to have their own PI space? Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mel Beckman Sent: Tuesday, July 14, 2015 4:33 PM To: Valdis.Kletnieks at vt.edu Cc: John Levine; nanog at nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion Ok. Two RIB entries for Comcast. Your argument doesn't scale. -mel via cell On Jul 14, 2015, at 12:53 PM, "Valdis.Kletnieks at vt.edu" > wrote: On Tue, 14 Jul 2015 19:45:42 -0000, Mel Beckman said: We're talking about end user assignments made by ISPs, not ISP assignments. Do the math for how big a chunk Comcast needs, assuming they give each residential customer a /60, or a /56, or a /48. If their first chunk was sized based on ubiquitous /56s and it turns out /48 would have been better, they may need another trip to the well. From johnl at iecc.com Tue Jul 14 20:50:13 2015 From: johnl at iecc.com (John R. Levine) Date: 14 Jul 2015 16:50:13 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <002f01d0be76$52b0c800$f8125800$@gmail.com> References: <20150714184425.24695.qmail@ary.lan>, <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org>, <25137.1436903621@turing-police.cc.vt.edu> <002f01d0be76$52b0c800$f8125800$@gmail.com> Message-ID: > What about dual-homed customers? Or are they all expected to have their own > PI space? This is IPv6. Why shouldn't they have their own PI space? R's, John From mhuff at ox.com Tue Jul 14 21:09:39 2015 From: mhuff at ox.com (Matthew Huff) Date: Tue, 14 Jul 2015 21:09:39 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150714184425.24695.qmail@ary.lan>, <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org>, <25137.1436903621@turing-police.cc.vt.edu> <002f01d0be76$52b0c800$f8125800$@gmail.com> Message-ID: <589b69a22fdf4eeebafae7ee8d893943@pur-vm-exch13n1.ox.com> Exactly. As a business entity and not a provider, we wouldn't have even contemplated deploying IPv6 without PI addresses. The myth of easy renumbering and/or having multiple prefixes/address per host for failover still shows up from time to time, but mostly gets ignored (at least in the corporate world). Remember SHIM? Any reasonable size organization that expects reliable internet connections is going to go BGP/PI. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John R. Levine Sent: Tuesday, July 14, 2015 4:50 PM To: Chuck Church Cc: nanog at nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion > What about dual-homed customers? Or are they all expected to have their own > PI space? This is IPv6. Why shouldn't they have their own PI space? R's, John From A.L.M.Buxey at lboro.ac.uk Tue Jul 14 21:22:31 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Tue, 14 Jul 2015 21:22:31 +0000 Subject: M$ no v6 or just me? In-Reply-To: References: <20150714203002.GB31815@lboro.ac.uk> Message-ID: <20150714212231.GA32044@lboro.ac.uk> Hi, > No. My DNS (using the roots) gets it right. ;-) so if you choose google DNS you dont see the right stuff..in which case its your DNS and not microsoft or Akamai not doing IPv6 ;-) same true for OpenDNS? likely... alan From jimpop at gmail.com Tue Jul 14 21:26:22 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Tue, 14 Jul 2015 17:26:22 -0400 Subject: M$ no v6 or just me? In-Reply-To: <20150714212231.GA32044@lboro.ac.uk> References: <20150714203002.GB31815@lboro.ac.uk> <20150714212231.GA32044@lboro.ac.uk> Message-ID: On Tue, Jul 14, 2015 at 5:22 PM, wrote: > Hi, > >> No. My DNS (using the roots) gets it right. ;-) > > so if you choose google DNS you dont see the right stuff..in which case its your DNS > and not microsoft or Akamai not doing IPv6 ;-) same true for OpenDNS? likely... Dude, it was a test I ran for Nicholas... not my dns. It doesn't mean something is internal or related to a person just because they post some data here. Do I need to spoon feed you the test data that I posted earlier? -Jim P. From jared at puck.nether.net Tue Jul 14 21:42:05 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 14 Jul 2015 17:42:05 -0400 Subject: M$ no v6 or just me? In-Reply-To: References: <20150714203002.GB31815@lboro.ac.uk> <20150714212231.GA32044@lboro.ac.uk> Message-ID: <4C7B485E-FF13-4B96-A1D9-97EC8B974F9A@puck.nether.net> > On Jul 14, 2015, at 5:26 PM, Jim Popovitch wrote: > > On Tue, Jul 14, 2015 at 5:22 PM, wrote: >> Hi, >> >>> No. My DNS (using the roots) gets it right. ;-) >> >> so if you choose google DNS you dont see the right stuff..in which case its your DNS >> and not microsoft or Akamai not doing IPv6 ;-) same true for OpenDNS? likely... > > Dude, it was a test I ran for Nicholas... not my dns. It doesn't > mean something is internal or related to a person just because they > post some data here. > > Do I need to spoon feed you the test data that I posted earlier? Perhaps the smiley? :) I think the general statement is that if someone uses Google DNS they may not be getting the full IPv6 experience which may be surprising to some people. I?m not sure why google would filter the AAAA responses, or if it?s something else happening but it does make me wonder what other queries that google would get wrong. - Jared From mark at viviotech.net Tue Jul 14 21:45:01 2015 From: mark at viviotech.net (Mark Keymer) Date: Tue, 14 Jul 2015 14:45:01 -0700 Subject: M$ no v6 or just me? In-Reply-To: <20150714212231.GA32044@lboro.ac.uk> References: <20150714203002.GB31815@lboro.ac.uk> <20150714212231.GA32044@lboro.ac.uk> Message-ID: <55A582DD.1060509@viviotech.net> Umm, ok so your saying you get AAAA records for "microsoft.com" I am Not talking about www.microsoft.com I agree that it has AAAA records. But the request was for "microsoft.com" And as noted other domains without the WWW might not have AAAA Records. Sincerely, Mark Keymer CFO/COO Vivio Technologies On 7/14/2015 2:22 PM, A.L.M.Buxey at lboro.ac.uk wrote: > Hi, > >> No. My DNS (using the roots) gets it right. ;-) > so if you choose google DNS you dont see the right stuff..in which case its your DNS > and not microsoft or Akamai not doing IPv6 ;-) same true for OpenDNS? likely... > > alan From jimpop at gmail.com Tue Jul 14 21:48:38 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Tue, 14 Jul 2015 17:48:38 -0400 Subject: M$ no v6 or just me? In-Reply-To: <4C7B485E-FF13-4B96-A1D9-97EC8B974F9A@puck.nether.net> References: <20150714203002.GB31815@lboro.ac.uk> <20150714212231.GA32044@lboro.ac.uk> <4C7B485E-FF13-4B96-A1D9-97EC8B974F9A@puck.nether.net> Message-ID: On Tue, Jul 14, 2015 at 5:42 PM, Jared Mauch wrote: > >> On Jul 14, 2015, at 5:26 PM, Jim Popovitch wrote: >> >> On Tue, Jul 14, 2015 at 5:22 PM, wrote: >>> Hi, >>> >>>> No. My DNS (using the roots) gets it right. ;-) >>> >>> so if you choose google DNS you dont see the right stuff..in which case its your DNS >>> and not microsoft or Akamai not doing IPv6 ;-) same true for OpenDNS? likely... >> >> Dude, it was a test I ran for Nicholas... not my dns. It doesn't >> mean something is internal or related to a person just because they >> post some data here. >> >> Do I need to spoon feed you the test data that I posted earlier? > > Perhaps the smiley? :) Yes. ;-) :) -Jim P. From shopik at inblock.ru Tue Jul 14 22:10:04 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Wed, 15 Jul 2015 01:10:04 +0300 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <589b69a22fdf4eeebafae7ee8d893943@pur-vm-exch13n1.ox.com> References: <20150714184425.24695.qmail@ary.lan> <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> <25137.1436903621@turing-police.cc.vt.edu> <002f01d0be76$52b0c800$f8125800$@gmail.com> <589b69a22fdf4eeebafae7ee8d893943@pur-vm-exch13n1.ox.com> Message-ID: Or wait ILNP/ILA https://lwn.net/Articles/647515/ > On 15 ???? 2015 ?., at 0:09, Matthew Huff wrote: > > Exactly. > > As a business entity and not a provider, we wouldn't have even contemplated deploying IPv6 without PI addresses. The myth of easy renumbering and/or having multiple prefixes/address per host for failover still shows up from time to time, but mostly gets ignored (at least in the corporate world). Remember SHIM? > > Any reasonable size organization that expects reliable internet connections is going to go BGP/PI. > > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John R. Levine > Sent: Tuesday, July 14, 2015 4:50 PM > To: Chuck Church > Cc: nanog at nanog.org > Subject: RE: Dual stack IPv6 for IPv4 depletion > >> What about dual-homed customers? Or are they all expected to have their own >> PI space? > > This is IPv6. Why shouldn't they have their own PI space? > > R's, > John From pavel.odintsov at gmail.com Tue Jul 14 22:15:10 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 15 Jul 2015 01:15:10 +0300 Subject: 'gray' market IPv4 In-Reply-To: References: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> Message-ID: Hello, folks! I have finished multiple (and 5th in RIPE) inter RIR subnet moves in RIPE region. We have moved multiple /21-/20 networks and awerage cost was about $10 per ip. On Tuesday, July 14, 2015, Martin Hannigan wrote: > On Tue, Jul 14, 2015 at 10:22 AM, Matt Kelly > wrote: > > > This list is actual sale prices, > > http://www.ipv4auctions.com/previous_auctions/ > > > > > > -- > > Matt > > > > > > On July 14, 2015 at 10:14:05 AM, Justin Wilson - MTIN (lists at mtin.net > ) > > wrote: > > > > Thes folks (and I am not advertising or affiliated with them) publish a > > list of most recent transfer completed: > > > > http://ipv4marketgroup.com/broker-services/buy/ > > > > > http://ipv4marketgroup.com/broker-services/buy/ vs. > http://www.ipv4auctions.com/previous_auctions/ > > > If you compare the pricing that both have made available you will find one > is posting average prices exponentially higher than the other. When you > trend the granular auction site data the auction numbers demonstrate a > trend would expect, that smaller prefixes are more expensive since it > takes a similar amount of effort to process a /24 as it does a /20. Dollar > differences between a /24 unit and a /17 unit move the needle > significantly. > > Based on both of both sets of public data its easy to conclude that > auctions will work for at least small buyers of space if they're > sophisticated enough to address the RIR issues. If you do decide to take > the simple broker approach (not all are simple and not all approaches are > suitable to simple brokers), use an RFP. And Yelp. :-) > > Best, > > -M< > -- Sincerely yours, Pavel Odintsov From marka at isc.org Tue Jul 14 22:54:33 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 15 Jul 2015 08:54:33 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Tue, 14 Jul 2015 16:47:33 -0400." <002f01d0be76$52b0c800$f8125800$@gmail.com> References: <20150714184425.24695.qmail@ary.lan>, <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org>, <25137.1436903621@turing-police.cc.vt.edu> <002f01d0be76$52b0c800$f8125800$@gmail.com> Message-ID: <20150714225433.E880A330305A@rock.dv.isc.org> In message <002f01d0be76$52b0c800$f8125800$@gmail.com>, "Chuck Church" writes: > What about dual-homed customers? Or are they all expected to have their own > PI space? > > Chuck For the home dual PA prefixes + ULA with CPE routers that support source and destination based routing automatically. This is the technology being experimentally deployed today. Go look at the bleading edge of OpenWrt. It will also work for small businesses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From randy at psg.com Tue Jul 14 23:05:02 2015 From: randy at psg.com (Randy Bush) Date: Tue, 14 Jul 2015 16:05:02 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <019c01d0be55$95459f90$bfd0deb0$@tndh.net> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> Message-ID: > I am not ... It is long past time to move on, so getting rid of the > distraction might help with those still holding out hope. i think that is unfair to the ipv6 fanboys (and girls). ipv6 use is increasing slowly. i bet it hits 10% by the time we retire. randy From cmaurand at xyonet.com Tue Jul 14 23:09:30 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 14 Jul 2015 19:09:30 -0400 Subject: ARIN IPV4 Countdown In-Reply-To: References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> Message-ID: <55A596AA.8090406@xyonet.com> i think IPV6 adoption is going to be very slow. It's very difficult for the layman to understand and that contributes to the slow rate of uptake. --Curtis On 7/14/2015 7:05 PM, Randy Bush wrote: >> I am not ... It is long past time to move on, so getting rid of the >> distraction might help with those still holding out hope. > i think that is unfair to the ipv6 fanboys (and girls). ipv6 use is > increasing slowly. i bet it hits 10% by the time we retire. > > randy -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From owen at delong.com Tue Jul 14 23:34:53 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jul 2015 16:34:53 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150714184425.24695.qmail@ary.lan> <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> Message-ID: <2C50C88F-D328-40B4-A785-5115965F6128@delong.com> For one thing a /32 is nowhere near enough for anything bigger than a modest ISP today. Many will need /28, /24, or even larger. The biggest ones probably need /16 or even /12 in some cases. Owen On Jul 14, 2015, at 12:53, John R. Levine wrote: >> We're talking about end user assignments made by ISPs, not ISP assignments. An ISP's /32 is likely the only entry one needs in the FIB. > > In that case, why should anyone care how the ISP assigns space to its customers? > > R's, > John From list at satchell.net Tue Jul 14 23:46:10 2015 From: list at satchell.net (Stephen Satchell) Date: Tue, 14 Jul 2015 16:46:10 -0700 Subject: Remember "Internet-In-A-Box"? Message-ID: <55A59F42.1080205@satchell.net> This goes back a number of years. There was a product that literally was a cardboard box that contained everything one needed to get started on the Internet. Just add a modem and a computer, and you were on your way. No fuss, no "learning curve". I'm beginning to think that someone needs to create a similar product, but for IPv6 internet. The Internet service providers would provide the same sort of kit to get people started. Just add a CSU/DSU (like a cable modem) and a computer, and you are on your way. Also, I think we need a *real* book called "IPv6 for Dummies" (maybe even published by IDG Books) that walks through all the beginner stuff. There's beginner stuff that I've seen by using a search engine; a dead-tree book, though, may well be better for Joe Average. Just my pair-o-pennies(tm) From brett at the-watsons.org Tue Jul 14 23:57:00 2015 From: brett at the-watsons.org (Brett Watson) Date: Tue, 14 Jul 2015 16:57:00 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A59F42.1080205@satchell.net> References: <55A59F42.1080205@satchell.net> Message-ID: > On Jul 14, 2015, at 4:46 PM, Stephen Satchell wrote: > > This goes back a number of years. There was a product that literally was a cardboard box that contained everything one needed to get started on the Internet. Just add a modem and a computer, and you were on your way. No fuss, no "learning curve?. MCI (way back, original MCI when I worked there) had ?MCI One? that was similar with bundled voice/internet/etc, may be what you?re thinking of or not? > I'm beginning to think that someone needs to create a similar product, but for IPv6 internet. The Internet service providers would provide the same sort of kit to get people started. Just add a CSU/DSU (like a cable modem) and a computer, and you are on your way. > > Also, I think we need a *real* book called "IPv6 for Dummies" (maybe even published by IDG Books) that walks through all the beginner stuff. There's beginner stuff that I've seen by using a search engine; a dead-tree book, though, may well be better for Joe Average. While I don?t disagree on a dummy package so to speak, I spent *years* explaining IPv4 to my mother, to no avail, so I highly doubt anyone can explain IPv6 to anyone outside of this (NANOG) group with any certainty, even if you call it ?IPv6 for Dummies.? The ?bundle? that you are talking about would have to be *literally* plug-n-play such that the end user would have no idea that it was IPv6 vs. IPv4 vs. any-other-IPv-anything. > Just my pair-o-pennies(tm) Just my opinion after 25+ years of doing this stuff and trying to explain what I (or we) do to family/friends/etc. -b From egon at egon.cc Tue Jul 14 23:57:31 2015 From: egon at egon.cc (James Downs) Date: Tue, 14 Jul 2015 16:57:31 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <55A596AA.8090406@xyonet.com> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> Message-ID: <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> > On Jul 14, 2015, at 16:09, Curtis Maurand wrote: > > i think IPV6 adoption is going to be very slow. It's very difficult for the layman to understand and that contributes to the slow rate of uptake. Who is the layman in this story? Almost every system I work with at home and in the datacenter has IPv6 turned on by default. If someone wandered through those networks, and started turning on IPv6 infrastructure so that they started getting IPv6 addresses, my bet is that most of the java-based applications would already be bound to the stacks in such a way that they would just start sending traffic over IPv6. I base this on the fact that any number of developers have been confused by ?::? being somewhere in their world now. Those people don?t care about the network, or IPv4 vs IPv6. It would just work. Now, if layman == Network Operators, and Networking people at Corporations, well, there you might be right. Cheers, -j From mike-nanog at tiedyenetworks.com Wed Jul 15 00:02:33 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Tue, 14 Jul 2015 17:02:33 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A59F42.1080205@satchell.net> References: <55A59F42.1080205@satchell.net> Message-ID: <55A5A319.2070701@tiedyenetworks.com> On 07/14/2015 04:46 PM, Stephen Satchell wrote: > This goes back a number of years. There was a product that literally > was a cardboard box that contained everything one needed to get > started on the Internet. Just add a modem and a computer, and you > were on your way. No fuss, no "learning curve". > > I'm beginning to think that someone needs to create a similar product, > but for IPv6 internet. The Internet service providers would provide > the same sort of kit to get people started. Just add a CSU/DSU (like > a cable modem) and a computer, and you are on your way. > > Also, I think we need a *real* book called "IPv6 for Dummies" (maybe > even published by IDG Books) that walks through all the beginner > stuff. There's beginner stuff that I've seen by using a search > engine; a dead-tree book, though, may well be better for Joe Average. > > Just my pair-o-pennies(tm) > > I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a /32 of v6, but no clue yet how to get from where I am today to where we all should be. The flame wars and vitrol and rhetoric is too much noise for me to derive anything useful from. Someone needs to stand up and lead. I will happily follow. Whats really needed, is for you gods of ipv6, to write that 'ipv6 for ipv4 dummies', targeting service providers and telling us exactly what we need to do. No religious wars about subnet allocation sizes or dhcpv6 vs slaac or anything. Tell us how to get it onto our network, give us reasonable deployment scenarios that leverage our experience with IPv4 and tell us what we are going to tell our customers. Help us understand WHY nat is not a security model, and how to achieve the same benefits we have with nat now, in an ipv6 enabled world. Mike From yang.yu.list at gmail.com Wed Jul 15 00:05:02 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Wed, 15 Jul 2015 09:05:02 +0900 Subject: M$ no v6 or just me? In-Reply-To: References: Message-ID: On Wed, Jul 15, 2015 at 4:33 AM, Nicholas Warren wrote: > Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, or is Microsoft not available over v6? > > Thanks, > Nich > probably not Google DNS filtering test point 1 $ dig e10088.dspb.akamaiedge.net AAAA @n0dspb.akamaiedge.net ; <<>> DiG 9.10.2-P2 <<>> e10088.dspb.akamaiedge.net AAAA @n0dspb.akamaiedge.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51914 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;e10088.dspb.akamaiedge.net. IN AAAA ;; AUTHORITY SECTION: dspb.akamaiedge.net. 1000 IN SOA n0dspb.akamaiedge.net. hostmaster.akamai.com. 1436917052 1000 1000 1000 1800 ;; Query time: 51 msec ;; SERVER: 96.7.248.137#53(96.7.248.137) ;; WHEN: Wed Jul 15 08:37:32 KST 2015 ;; MSG SIZE rcvd: 119 test point 2 $ dig e10088.dspb.akamaiedge.net AAAA @n0dspb.akamaiedge.net ; <<>> DiG 9.8.1-P1 <<>> e10088.dspb.akamaiedge.net AAAA @n0dspb.akamaiedge.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27887 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;e10088.dspb.akamaiedge.net. IN AAAA ;; ANSWER SECTION: e10088.dspb.akamaiedge.net. 20 IN AAAA 2600:1408:10:18f::2768 e10088.dspb.akamaiedge.net. 20 IN AAAA 2600:1408:10:181::2768 e10088.dspb.akamaiedge.net. 20 IN AAAA 2600:1408:10:188::2768 ;; Query time: 18 msec ;; SERVER: 88.221.81.193#53(88.221.81.193) ;; WHEN: Tue Jul 14 16:37:17 2015 ;; MSG SIZE rcvd: 128 I get different IPs for n0dspb.akamaiedge.net / n0dscb.akamaiedge.net every time. So it depends on source IP of the query and which akamai DNS server is answering? From steve at blighty.com Wed Jul 15 00:06:16 2015 From: steve at blighty.com (Steve Atkins) Date: Tue, 14 Jul 2015 17:06:16 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A59F42.1080205@satchell.net> References: <55A59F42.1080205@satchell.net> Message-ID: <89AE4974-B2E3-423A-B60C-2A5DEF7F19B5@blighty.com> > On Jul 14, 2015, at 4:46 PM, Stephen Satchell wrote: > > This goes back a number of years. There was a product that literally was a cardboard box that contained everything one needed to get started on the Internet. Just add a modem and a computer, and you were on your way. No fuss, no "learning curve". > > I'm beginning to think that someone needs to create a similar product, but for IPv6 internet. The Internet service providers would provide the same sort of kit to get people started. Just add a CSU/DSU (like a cable modem) and a computer, and you are on your way. > > Also, I think we need a *real* book called "IPv6 for Dummies" (maybe even published by IDG Books) that walks through all the beginner stuff. There's beginner stuff that I've seen by using a search engine; a dead-tree book, though, may well be better for Joe Average. If a consumer internet connection works I wouldn't expect the typical user to have to know that IPv6 exists, let alone anything about it. If you need to manually see anything at that level then hasn't the ISP, OS vendor or app developer done something horribly wrong? IPv6 for dummies for app developers and small ISPs, OTOH ... Cheers, Steve From george.metz at gmail.com Tue Jul 14 13:23:17 2015 From: george.metz at gmail.com (George Metz) Date: Tue, 14 Jul 2015 09:23:17 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> Message-ID: That's all well and good Owen, and the math is compelling, but 30 years ago if you'd told anyone that we'd go through all four billion IPv4 addresses in anyone's lifetime, they'd have looked at you like you were stark raving mad. That's what's really got most of the people who want (dare I say more sane?) more restrictive allocations to be the default concerned; 30 years ago the math for how long IPv4 would last would have been compelling as well, which is why we have the entire Class E block just unusable and large blocks of IP address space that people were handed for no particular reason than it sounded like a good idea at the time. It's always easier to be prudent from the get-go than it is to rein in the insanity at a later date. Just because we can't imagine a world where IPv6 depletion is possible doesn't mean it can't exist, and exist far sooner than one might expect. On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong wrote: > How so? > > There are 8192 /16s in the current /3. > > ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 > end-sites per person > can?t really be all that many? > > > 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. > > 7,000,000,000 * 32 = 224,000,000,000 / 125,000,000 = 1,792 total /16s > consumed. > > Really, if we burn through all 8,192 of them in less than 50 years and I?m > still alive > when we do, I?ll help you promote more restrictive policy to be enacted > while we > burn through the second /3. That?ll still leave us 75% of the address > space to work > with on that new policy. > > If you want to look at places where IPv6 is really getting wasted, let?s > talk about > an entire /9 reserved without an RFC to make it usable or it?s partner /9 > with an > RFC to make it mostly useless, but popular among those few remaining NAT > fanboys. Together that constitutes 1/256th of the address space cast off to > waste. > > Yeah, I?m not too worried about the ISPs that can legitimately justify a > /16. > > Owen > > > On Jul 13, 2015, at 16:16 , Joe Maimon wrote: > > > > > > > > Owen DeLong wrote: > >> JimBob?s ISP can apply to ARIN for a /16 > > > > Like I said, very possibly not a good thing for the address space. > > From caine at burlingamepolice.org Tue Jul 14 17:22:57 2015 From: caine at burlingamepolice.org (Caine, Ronda) Date: Tue, 14 Jul 2015 17:22:57 +0000 Subject: Text Messages being blocked by AT&T Message-ID: <872DEEF87BDBCE49ADFC8854F9610C03018D16E87A@heracles.pd.local> I am having a problem that started last Friday. Text messages sent from my domain seem to be being blocked by AT&T. Does anyone have a direct contact at AT&T who might be able to assist us in getting unblocked? Thank you in advance for any assistance you can offer. Ronda From dougb at dougbarton.us Wed Jul 15 00:38:46 2015 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 14 Jul 2015 17:38:46 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> Message-ID: <55A5AB96.8090101@dougbarton.us> On 7/14/15 6:23 AM, George Metz wrote: > It's always easier to be prudent from the get-go than it is to rein in the > insanity at a later date. Just because we can't imagine a world where IPv6 > depletion is possible doesn't mean it can't exist, and exist far sooner > than one might expect. I've been trying to stay out of this Nth repetition of the same nonsensical debate, since neither side has anything new to add. However George makes a valid point, which is "learn from the mistakes of the past." So let me ask George, who seems like a reasonable fellow ... do you think that creating an addressing plan that is more than adequate for even the wildest dreams of current users and future growth out of just 1/8 of the available space (meaning of course that we have 7/8 left to work with should we make a complete crap-show out of 2000::/3) constitutes being prudent, or not? And please note, this is not a snark, I am genuinely interested in the answer. I used to be one of the people responsible for the prudent use of the integers (as the former IANA GM) so this is something I've put a lot of thought into, and care deeply about. If there is something we've missed in concocting the current plan, I definitely want to know about it. Even taking into account some of the dubious decisions that were made 20 years ago, the numbers involved in IPv6 deployment are literally so overwhelming that the human brain has a hard time conceiving of them. Combine that with the conservation mindset that's been drilled into everyone regarding IPv4 resources, and a certain degree of over-enthusiasm for conserving IPv6 resources is understandable. But at the same time, because the volume of integers is so vast, it could be just as easy to slip into the early-days v4 mindset of "infinite," which is why I like to hear a good reality check now and again. :) Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mel at beckman.org Wed Jul 15 00:57:19 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 15 Jul 2015 00:57:19 +0000 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A5A319.2070701@tiedyenetworks.com> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> Message-ID: <61275C7D-0667-4363-89D8-29E0DE0DB267@beckman.org> Mike, I agree that something like that needs to be done. Maybe I?ll do it. In the meantime, have you got an IPv6 lab set up? I?m guessing that with your /32 allocation in hand, you likely do. Have you run through HE.net?s excellent personal IPv6 certification program? Until you gain fluency in IPv6, you won?t understand any advice anyway. If you?re already reasonably skilled at IPv6 manipulations, then you should be able to start designing a practical IPv6 deployment scheme. The essential processes are (a) getting IPv6 into your provisioning system, so you keep track of your assignments, and (b) distributing /48 (or whatever) prefixes to customers across your core network. (b) depends entirely on your IGP (OSPF, iBGP, MPLS, etc) and the CPE at your customers. -mel > On Jul 14, 2015, at 5:02 PM, Mike wrote: > > > > On 07/14/2015 04:46 PM, Stephen Satchell wrote: >> This goes back a number of years. There was a product that literally was a cardboard box that contained everything one needed to get started on the Internet. Just add a modem and a computer, and you were on your way. No fuss, no "learning curve". >> >> I'm beginning to think that someone needs to create a similar product, but for IPv6 internet. The Internet service providers would provide the same sort of kit to get people started. Just add a CSU/DSU (like a cable modem) and a computer, and you are on your way. >> >> Also, I think we need a *real* book called "IPv6 for Dummies" (maybe even published by IDG Books) that walks through all the beginner stuff. There's beginner stuff that I've seen by using a search engine; a dead-tree book, though, may well be better for Joe Average. >> >> Just my pair-o-pennies(tm) >> >> > > I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a /32 of v6, but no clue yet how to get from where I am today to where we all should be. The flame wars and vitrol and rhetoric is too much noise for me to derive anything useful from. Someone needs to stand up and lead. I will happily follow. > > Whats really needed, is for you gods of ipv6, to write that 'ipv6 for ipv4 dummies', targeting service providers and telling us exactly what we need to do. No religious wars about subnet allocation sizes or dhcpv6 vs slaac or anything. Tell us how to get it onto our network, give us reasonable deployment scenarios that leverage our experience with IPv4 and tell us what we are going to tell our customers. Help us understand WHY nat is not a security model, and how to achieve the same benefits we have with nat now, in an ipv6 enabled world. > > Mike > > > From mel at beckman.org Wed Jul 15 00:59:02 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 15 Jul 2015 00:59:02 +0000 Subject: Text Messages being blocked by AT&T In-Reply-To: <872DEEF87BDBCE49ADFC8854F9610C03018D16E87A@heracles.pd.local> References: <872DEEF87BDBCE49ADFC8854F9610C03018D16E87A@heracles.pd.local> Message-ID: <2C36A04F-DD26-4A48-87D4-E0DAFB0CE04B@beckman.org> AT&T does a kind of spam filtering on texts. AFAIK the only solution is to either send your texts via one of AT&T?s pay-for messaging channels, or get the receiving party to complain to their AT&T support rep. If you?re the receiving party, just call and say you want to whitelist an SMS source. -mel > On Jul 14, 2015, at 10:22 AM, Caine, Ronda wrote: > > I am having a problem that started last Friday. Text messages sent from my domain seem to be being blocked by AT&T. Does anyone have a direct contact at AT&T who might be able to assist us in getting unblocked? > > Thank you in advance for any assistance you can offer. > > Ronda From marka at isc.org Wed Jul 15 01:00:18 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 15 Jul 2015 11:00:18 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Tue, 14 Jul 2015 09:23:17 -0400." References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> Message-ID: <20150715010018.CC3C733059FF@rock.dv.isc.org> In message , George Metz writes: > That's all well and good Owen, and the math is compelling, but 30 years ago > if you'd told anyone that we'd go through all four billion IPv4 addresses > in anyone's lifetime, they'd have looked at you like you were stark raving > mad. I did that math ~30 years ago '88, when I got my first address blocks, and realised that IPv4 wasn't sustainable then. > That's what's really got most of the people who want (dare I say more > sane?) more restrictive allocations to be the default concerned; 30 years > ago the math for how long IPv4 would last would have been compelling as > well, which is why we have the entire Class E block just unusable and large > blocks of IP address space that people were handed for no particular reason > than it sounded like a good idea at the time. We don't use Class E because were using up IPv4 space too quickly to make it worthwhile to make it work cleanly for everyone. Note also the other 7/8ths the IPv6 space is reserved for unicast addresses. Class E was reserved for experimentation so in reality there is no comparison. > It's always easier to be prudent from the get-go than it is to rein in the > insanity at a later date. Just because we can't imagine a world where IPv6 > depletion is possible doesn't mean it can't exist, and exist far sooner > than one might expect. How many sites per person on the planet do you see in use in a 100 years, 1000 years. Out of this 1/8th there is around 350 per / person with /48's. > On Tue, Jul 14, 2015 at 12:22 AM, Owen DeLong wrote: > > > How so? > > > > There are 8192 /16s in the current /3. > > > > ISPs with that many pops at 5,000,000 end-sites per POP, even assuming 32 > > end-sites per person > > can=E2=80=99t really be all that many=E2=80=A6 > > > > > > 25 POPS at 5,000,000 end-sites each is 125,000,000 end-sites per ISP. > > > > 7,000,000,000 * 32 =3D 224,000,000,000 / 125,000,000 =3D 1,792 total /16s > > consumed. > > > > Really, if we burn through all 8,192 of them in less than 50 years and I= > =E2=80=99m > > still alive > > when we do, I=E2=80=99ll help you promote more restrictive policy to be e= > nacted > > while we > > burn through the second /3. That=E2=80=99ll still leave us 75% of the add= > ress > > space to work > > with on that new policy. > > > > If you want to look at places where IPv6 is really getting wasted, let=E2= > =80=99s > > talk about > > an entire /9 reserved without an RFC to make it usable or it=E2=80=99s pa= > rtner /9 > > with an > > RFC to make it mostly useless, but popular among those few remaining NAT > > fanboys. Together that constitutes 1/256th of the address space cast off = > to > > waste. > > > > Yeah, I=E2=80=99m not too worried about the ISPs that can legitimately ju= > stify a > > /16. > > > > Owen > > > > > On Jul 13, 2015, at 16:16 , Joe Maimon wrote: > > > > > > > > > > > > Owen DeLong wrote: > > >> JimBob=E2=80=99s ISP can apply to ARIN for a /16 > > > > > > Like I said, very possibly not a good thing for the address space. > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mfidelman at meetinghouse.net Wed Jul 15 01:15:50 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 14 Jul 2015 21:15:50 -0400 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A59F42.1080205@satchell.net> References: <55A59F42.1080205@satchell.net> Message-ID: <55A5B446.9020401@meetinghouse.net> Stephen Satchell wrote: > This goes back a number of years. There was a product that literally > was a cardboard box that contained everything one needed to get > started on the Internet. Just add a modem and a computer, and you > were on your way. No fuss, no "learning curve". > > I'm beginning to think that someone needs to create a similar product, > but for IPv6 internet. The Internet service providers would provide > the same sort of kit to get people started. Just add a CSU/DSU (like > a cable modem) and a computer, and you are on your way. > These days, wouldn't that be a pre-loaded tablet or smartphone with internal cell card - generally delivered pre-configured, in a cardboard box? :-) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From alter3d at alter3d.ca Wed Jul 15 01:19:34 2015 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 14 Jul 2015 21:19:34 -0400 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A5A319.2070701@tiedyenetworks.com> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> Message-ID: <55A5B526.8030804@alter3d.ca> On 7/14/2015 8:02 PM, Mike wrote: > The flame wars and vitrol and rhetoric is too much noise for me to > derive anything useful from. Someone needs to stand up and lead. I > will happily follow. "Too much noise" has been v6's problem from the start. Every time I've looked at v6 for use in the enterprise or even at home over the last ~15 years, the answer is always "wait -- v6 isn't standardized yet", "implement now -- v6 is ready for production", "wait -- v6 is missing critical features", "implement now -- v6 is easier than v4" and "wait -- v6 is too complex, and we don't have the best practices figured out yet" -- all simultaneously, depending on who you ask, the phase of the moon, local weather patterns, etc. And, to a significant degree, that's still happening today. That's exarcerbated by the long development cycle, multiple conflicting revisions/implementations over the years, and a severe case of feature creep. Most people started to tune out around the third time we heard "it's really here, for real this time!", and were completely underwhelmed (or overwhelmed, as the case may be) when the "really here for real" version arrived after a long hype cycle. So basically.... IPv6 is the Duke Nukem Forever of the networking world. Took forever to get here, was completely underwhelming when it did, and wasn't compelling enough for people to pony up money for other than as a curiosity. Unfortunately v6 is an essential part of making the Internet continue to work, because in any other scenario it would have been abandoned as vaporware 10-15 years ago. If a product is in development for 20 years, the expectation is that it's perfect out of the box, reduced to the simplest possible implementation, and easily understood -- and that's not what we have. - Pete From jsqnanog at quarterman.com Wed Jul 15 01:32:06 2015 From: jsqnanog at quarterman.com (John S. Quarterman) Date: Tue, 14 Jul 2015 21:32:06 -0400 Subject: Remember "Internet-In-A-Box"? In-Reply-To: Your message of "Tue, 14 Jul 2015 21:15:50 EDT." <55A5B446.9020401@meetinghouse.net> Message-ID: <1436923931.779619.22398@rudra.quarterman.com> In Japan, they had that on a CD in 1994, just after the law changed. Lines snaked across the floor at Interop in the huge new Makuhari Messe conference center in Chiba. -jsq > Stephen Satchell wrote: > > This goes back a number of years. There was a product that literally > > was a cardboard box that contained everything one needed to get > > started on the Internet. Just add a modem and a computer, and you > > were on your way. No fuss, no "learning curve". > > > > I'm beginning to think that someone needs to create a similar product, > > but for IPv6 internet. The Internet service providers would provide > > the same sort of kit to get people started. Just add a CSU/DSU (like > > a cable modem) and a computer, and you are on your way. > > > These days, wouldn't that be a pre-loaded tablet or smartphone with > internal cell card - generally delivered pre-configured, in a cardboard > box? :-) From cmaurand at xyonet.com Wed Jul 15 01:33:39 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 14 Jul 2015 21:33:39 -0400 Subject: ARIN IPV4 Countdown In-Reply-To: <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> Message-ID: <55A5B873.5010602@xyonet.com> Since IPV6 does not have NAT, it's going to be difficult for the layman to understand their firewall. deployment of ipv4 is pretty simple. ipv6 on the otherhand is pretty difficult at the network level. yes, all the clients get everything automatically except for the router/firewall. -C On 7/14/2015 7:57 PM, James Downs wrote: >> On Jul 14, 2015, at 16:09, Curtis Maurand wrote: >> >> i think IPV6 adoption is going to be very slow. It's very difficult for the layman to understand and that contributes to the slow rate of uptake. > Who is the layman in this story? Almost every system I work with at home and in the datacenter has IPv6 turned on by default. If someone wandered through those networks, and started turning on IPv6 infrastructure so that they started getting IPv6 addresses, my bet is that most of the java-based applications would already be bound to the stacks in such a way that they would just start sending traffic over IPv6. I base this on the fact that any number of developers have been confused by ?::? being somewhere in their world now. Those people don?t care about the network, or IPv4 vs IPv6. It would just work. > > Now, if layman == Network Operators, and Networking people at Corporations, well, there you might be right. > > Cheers, > -j -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From marka at isc.org Wed Jul 15 01:43:04 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 15 Jul 2015 11:43:04 +1000 Subject: ARIN IPV4 Countdown In-Reply-To: Your message of "Tue, 14 Jul 2015 21:33:39 -0400." <55A5B873.5010602@xyonet.com> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> <55A5B873.5010602@xyonet.com> Message-ID: <20150715014304.9831E33086A2@rock.dv.isc.org> In message <55A5B873.5010602 at xyonet.com>, Curtis Maurand writes: > > Since IPV6 does not have NAT, it's going to be difficult for the layman > to understand their firewall. deployment of ipv4 is pretty simple. > ipv6 on the otherhand is pretty difficult at the network level. yes, > all the clients get everything automatically except for the router/firewall. > > -C Absolute garbage. CPE already ship with basically the same controls for IPv6 as for IPv4. Default block in except reply traffic + specified holes for services you want to open up to the world. The is same paradigm that has been in use in IPv4 for a years now. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tqr2813d376cjozqap1l at tutanota.com Wed Jul 15 01:43:42 2015 From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com) Date: Wed, 15 Jul 2015 01:43:42 +0000 (UTC) Subject: ARIN IPV4 Countdown In-Reply-To: <55A5B873.5010602@xyonet.com> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <<8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu>> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <<8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com>> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <<019c01d0be55$95459f90$bfd0deb0$@tndh.net>> <> <55A596AA.8090406@xyonet.com> <<55A596AA.8090406@xyonet.com>> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> <<8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc>> <55A5B873.5010602@xyonet.com> Message-ID: 15. Jul 2015 01:33 by cmaurand at xyonet.com: > > Since IPV6 does not have NAT, it's going to be difficult for the layman to > understand their firewall. deployment of ipv4 is pretty simple. ipv6 on > the otherhand is pretty difficult at the network level. yes, all the > clients get everything automatically except for the router/firewall. > > -C > You're right! Let's call the whole thing off[1] 1: https://www.youtube.com/watch?v=J2oEmPP5dTM From lyndon at orthanc.ca Wed Jul 15 01:51:25 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 14 Jul 2015 18:51:25 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <55A5B873.5010602@xyonet.com> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> <55A5B873.5010602@xyonet.com> Message-ID: <348A8690-451F-4F48-9B4B-48B383CCE139@orthanc.ca> On Jul 14, 2015, at 6:33 PM, Curtis Maurand wrote: > Since IPV6 does not have NAT, it's going to be difficult for the layman to understand their firewall. deployment of ipv4 is pretty simple. ipv6 on the otherhand is pretty difficult at the network level. yes, all the clients get everything automatically except for the router/firewall. Are we *still* doing this argument?!? block all pass out on $extif keep state Is it that fucking difficult for people to figure out? Really? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nsuan at nonexiste.net Wed Jul 15 02:09:01 2015 From: nsuan at nonexiste.net (Nicholas Suan) Date: Tue, 14 Jul 2015 22:09:01 -0400 Subject: ARIN IPV4 Countdown In-Reply-To: <55A5B873.5010602@xyonet.com> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> <55A5B873.5010602@xyonet.com> Message-ID: On Tue, Jul 14, 2015 at 9:33 PM, Curtis Maurand wrote: > > Since IPV6 does not have NAT, it's going to be difficult for the layman to > understand their firewall. deployment of ipv4 is pretty simple. ipv6 on > the otherhand is pretty difficult at the network level. yes, all the > clients get everything automatically except for the router/firewall. > > -C Enabling IPv6 on my CPE was extremely difficult, yes. It took three extra clicks to enable connection sharing and then subsequently enable incoming connections. From lyndon at orthanc.ca Wed Jul 15 02:19:31 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 14 Jul 2015 19:19:31 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <01c401d0be66$ce0b40d0$6a21c270$@tndh.net> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> , <01c401d0be66$ce0b40d0$6a21c270$@tndh.net> Message-ID: <5E1E40A1-ED46-4D4A-A9C2-067F7855C1EA@orthanc.ca> On Jul 14, 2015, at 11:56 AM, Tony Hain wrote: > IPv6 is not the last protocol known to mankind. IF it burns out in 400-500 > years, something will have gone terribly wrong, because newer ideas about > networking will have been squashed along the way. 64 bits for both hosts and > routing was over 3 orders of magnitude more than sufficient to meet the > design goals for the IPv4 replacement, but in the context of the dot-com > bubble there was a vast outcry from the ops community that it would be > insufficient for the needs of routing. So the entire 64 bits of the original > proposal was given to routing, and the IETF spent another year arguing about > how many bits more to add for hosts. Now, post bubble burst, we are left > with 32,768x the already more than sufficient number of routing prefixes, > but "IPv4-think" conservation believes we still need to be extremely > conservative about allocations. If you look at how the IoT model is evolving, the entire host+service (i.e. IP address + port number) model is rapidly disintegrating. Services are the end-points now. They need to be individually addressable, since they really have no affinity to physical hardware in the sense we currently think of "hosts," with IP and MAC addresses. Host hardware is fungible; services are mobile. The IPv6 address space conservatives are missing the entire point that IPv6, as a global addressing scheme, will collapse in the next couple of decades. Host+port endpoint identifiers are already done. We just haven't noticed yet. --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Valdis.Kletnieks at vt.edu Wed Jul 15 02:26:40 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 14 Jul 2015 22:26:40 -0400 Subject: ARIN IPV4 Countdown In-Reply-To: Your message of "Tue, 14 Jul 2015 18:51:25 -0700." <348A8690-451F-4F48-9B4B-48B383CCE139@orthanc.ca> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> <55A5B873.5010602@xyonet.com> <348A8690-451F-4F48-9B4B-48B383CCE139@orthanc.ca> Message-ID: <55151.1436927200@turing-police.cc.vt.edu> On Tue, 14 Jul 2015 18:51:25 -0700, Lyndon Nerenberg said: > Are we *still* doing this argument?!? > > block all > pass out on $extif keep state > > Is it that fucking difficult for people to figure out? Really? But.. But... How does that work without using UPNP? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Jul 15 02:26:22 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 14 Jul 2015 22:26:22 -0400 Subject: ARIN IPV4 Countdown In-Reply-To: Your message of "Tue, 14 Jul 2015 21:33:39 -0400." <55A5B873.5010602@xyonet.com> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> <55A5B873.5010602@xyonet.com> Message-ID: <55110.1436927182@turing-police.cc.vt.edu> On Tue, 14 Jul 2015 21:33:39 -0400, Curtis Maurand said: > Since IPV6 does not have NAT, it's going to be difficult for the layman > to understand their firewall. Like "the layman" actually understand what a PS3 means by "NAT Type 2" without consulting Google? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From lyndon at orthanc.ca Wed Jul 15 02:30:02 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 14 Jul 2015 19:30:02 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <55151.1436927200@turing-police.cc.vt.edu> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> <55A5B873.5010602@xyonet.com> <348A8690-451F-4F48-9B4B-48B383CCE139@orthanc.ca> <55151.1436927200@turing-police.cc.vt.edu> Message-ID: <7745F8C1-84BA-43B3-A716-F005450E2B07@orthanc.ca> On Jul 14, 2015, at 7:26 PM, Valdis.Kletnieks at vt.edu wrote: > But.. But... How does that work without using UPNP? :) SHOUT LOUDER! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From joelja at bogus.com Wed Jul 15 02:35:31 2015 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Jul 2015 19:35:31 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A59F42.1080205@satchell.net> References: <55A59F42.1080205@satchell.net> Message-ID: This stuff has been consumerized. If you walk into any vzw store you can for $99 and $60 a month no contract walk out with a mifi with v6. You don't even have to ask, or configure anything, pretty much as it should be, the consumer wants internet, Facebook email, and all the upper layer services that the find valuable enough to pay a service provider and buy hardware for. Running an ISP or IT department assumes a certain amount of familiarity with the craft, which means you should be buying the picees that meet your needs, rather than what other people think you need. Sent from my iPhone > On Jul 14, 2015, at 16:46, Stephen Satchell wrote: > > This goes back a number of years. There was a product that literally was a cardboard box that contained everything one needed to get started on the Internet. Just add a modem and a computer, and you were on your way. No fuss, no "learning curve". > > I'm beginning to think that someone needs to create a similar product, but for IPv6 internet. The Internet service providers would provide the same sort of kit to get people started. Just add a CSU/DSU (like a cable modem) and a computer, and you are on your way. > > Also, I think we need a *real* book called "IPv6 for Dummies" (maybe even published by IDG Books) that walks through all the beginner stuff. There's beginner stuff that I've seen by using a search engine; a dead-tree book, though, may well be better for Joe Average. > > Just my pair-o-pennies(tm) > From drc at virtualized.org Wed Jul 15 03:09:02 2015 From: drc at virtualized.org (David Conrad) Date: Tue, 14 Jul 2015 20:09:02 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <55A5B873.5010602@xyonet.com> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> <55A5B873.5010602@xyonet.com> Message-ID: <5A40105A-83B0-4779-B7F0-2B44502019E9@virtualized.org> > Since IPV6 does not have NAT, http://www.juniper.net/documentation/en_US/junos11.4/topics/concept/ipv6-nat-overview.html, but perhaps you meant something else. > it's going to be difficult for the layman to understand their firewall. Not really. I suspect a stateful firewall for IPv6 will look pretty indistinguishable from a NAT. > deployment of ipv4 is pretty simple. Now, yes. > ipv6 on the otherhand is pretty difficult at the network level. I haven't found it to be. In fact, in my home network (Comcast+Apple gear), it sort of just happened. I don't recall configuring anything special. > yes, all the clients get everything automatically except for the router/firewall. All clients also get router/firewall. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alh-ietf at tndh.net Wed Jul 15 03:10:25 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 14 Jul 2015 20:10:25 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> Message-ID: <02a601d0beab$cb492d40$61db87c0$@tndh.net> Randy Bush wrote: > > I am not ... It is long past time to move on, so getting rid of the > > distraction might help with those still holding out hope. > > i think that is unfair to the ipv6 fanboys (and girls). ipv6 use is increasing > slowly. i bet it hits 10% by the time we retire. Are you planning to retire this year? Select a logistic curve for 1800 days forward at: https://www.vyncke.org/ipv6status/project.php While the base curve it runs on is running ahead of the measured traffic curve, the measure of IPv6 enabled browsers is a reasonable indicator for what is happening. Tony From randy at psg.com Wed Jul 15 03:16:37 2015 From: randy at psg.com (Randy Bush) Date: Tue, 14 Jul 2015 20:16:37 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <02a601d0beab$cb492d40$61db87c0$@tndh.net> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <02a601d0beab$cb492d40$61db87c0$@tndh.net> Message-ID: > While the base curve it runs on is running ahead of the measured traffic > curve, the measure of IPv6 enabled browsers is a reasonable indicator for > what is happening. we're an isp, with ipv6 enabled since 1997. we measure real traffic, not wishes of what could be. randy From kauer at biplane.com.au Wed Jul 15 03:53:31 2015 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 15 Jul 2015 13:53:31 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> Message-ID: <1436932411.17261.38.camel@karl> On Tue, 2015-07-14 at 09:23 -0400, George Metz wrote: > It's always easier to be prudent from the get-go than it is to rein in the > insanity at a later date. Just because we can't imagine a world where IPv6 > depletion is possible doesn't mean it can't exist, and exist far sooner > than one might expect. The big difference between IPv4 initial policies and IPv6 initial policies is that with IPv4 there were no policies to speak of in the early days. Space was handed out more or less willy-nilly - so some US organisations ended up with multiple A-classes each, while later on all of Vietnam got one /26. With IPv6 there is a policy, it's been there from day one, it's well thought out, and if followed will see everyone (yes EVERYONE) getting vastly more address space than they are ever likely to need *even if our wildest expectations are exceeded*. Four billion isn't really that much. It never was. It was obvious decades ago that it would run out. IPv6 was designed with that in mind. That's the big difference - IPv6 has been designed to provide abundant address space. Restrictions like /56 instead of /48 are unnecessary limitations - limitations that the protocol was designed to remove! Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From randy at psg.com Wed Jul 15 04:15:56 2015 From: randy at psg.com (Randy Bush) Date: Tue, 14 Jul 2015 21:15:56 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1436932411.17261.38.camel@karl> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.camel@karl> Message-ID: > The big difference between IPv4 initial policies and IPv6 initial > policies is that with IPv4 there were no policies to speak of in the > early days. Space was handed out more or less willy-nilly - so some US > organisations ended up with multiple A-classes each, while later on all > of Vietnam got one /26. this is not really true. viet nam was not in the early days at all, and the cause of the small allocation was techno-colonialiasm by telco. the pre netsol allocations by sri, isc, ... were needs based. but the allocators had only very gross knobs, A, B, and C. in the early early days, some big allocations were made to big entities, ibm, dec, at&t, ... some used them well. some have returned them. randy From bmanning at karoshi.com Wed Jul 15 04:31:49 2015 From: bmanning at karoshi.com (manning) Date: Tue, 14 Jul 2015 21:31:49 -0700 Subject: BIS re-regulating crypto is on the table... Message-ID: <8930211F-4131-438D-B730-8E25CEE5ACB7@karoshi.com> if you use crypto (antivirus, mmap, etc.) or encrypt your data, use VPNs, etc? you might want to read and comment. Comment period closes next week. https://www.federalregister.gov/articles/2015/05/20/2015-11642/wassenaar-arrangement-2013-plenary-agreements-implementation-intrusion-and-surveillance-items manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 From randy at psg.com Wed Jul 15 04:50:30 2015 From: randy at psg.com (Randy Bush) Date: Tue, 14 Jul 2015 21:50:30 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.camel@karl> Message-ID: > the pre netsol allocations by sri, isc usc, sigh From fergdawgster at mykolab.com Wed Jul 15 04:57:28 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 14 Jul 2015 21:57:28 -0700 Subject: BIS re-regulating crypto is on the table... In-Reply-To: <8930211F-4131-438D-B730-8E25CEE5ACB7@karoshi.com> References: <8930211F-4131-438D-B730-8E25CEE5ACB7@karoshi.com> Message-ID: <55A5E838.8010201@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Actually, this is *not* about crypto at all, it is about "exploitations" tools, pen testing, vulnerability exposure, etc. See also: https://threatpost.com/security-researchers-sound-off-on-proposed-us-was senaar-rules/113023 And as a matter of fact: "Today the Department of Commerce?s Bureau of Industry and Security published a public meeting notice in the Federal Register (80 FR 40997-40998) for the Information Systems Technology Advisory Committee. The partially closed meeting will be held on July 29th and 30th, 2015 in Washington, DC. The open portion of the meeting will include an industry presentation on 'Penetration Testing and Implementation of Wassenaar 2013 Cyber-Related Provisions' on Wednesday. " http://www.gpo.gov/fdsys/pkg/FR-2015-07-14/html/2015-17235.htm There has been a mailing list set up to discuss the BIS's (Dept. of Commerce's Bureau of Industry and Security) proposed export restrictions (similar to crypto under the ITAR dual-use export restrictions) on said tools and mechanics: https://lists.alchemistowl.org/mailman/listinfo/regs The discussion archives are public. FYI, - - ferg On 7/14/2015 9:31 PM, manning wrote: > if you use crypto (antivirus, mmap, etc.) or encrypt your data, use > VPNs, etc? you might want to read and comment. Comment period > closes next week. > > https://www.federalregister.gov/articles/2015/05/20/2015-11642/wassena ar-arrangement-2013-plenary-agreements-implementation-intrusion-and-surv eillance-items > > manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA > 90295 310.322.8102 > > > > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWl6DgACgkQKJasdVTchbLF4gEAxwujdkfPBfB52TS/AyJLXvIo 0PpDWxUEg1G1ewWk11YA/2Shb3Ao5SaOabg440ZTPTr+J3BEvA41g9h4HQCggTYG =9Uz4 -----END PGP SIGNATURE----- From kauer at biplane.com.au Wed Jul 15 04:59:12 2015 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 15 Jul 2015 14:59:12 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.camel@karl> Message-ID: <1436936352.17261.60.camel@karl> On Tue, 2015-07-14 at 21:15 -0700, Randy Bush wrote: > > The big difference between IPv4 initial policies and IPv6 initial > > policies is that with IPv4 there were no policies to speak of in the > > early days. Space was handed out more or less willy-nilly - so some US > > organisations ended up with multiple A-classes each, while later on all > > of Vietnam got one /26. > > this is not really true. viet nam was not in the early days at all Er - yes. That's why I said "later". > and the cause of the small allocation was techno-colonialiasm > by telco. Is a techno-colonialiasm the end result of some sort of musical/military fetish? On reflection I think I was wrong about the /26 anyway. It would have been much less. The first Internet-like connection into Vietnam, around 1992, was dialup links from the Australian National University and basically just carried email. It was probably just a few end-point addresses. By the time there was anything properly Internetty into Vietnam it was the late 90s. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From mpetach at netflight.com Wed Jul 15 05:09:22 2015 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 14 Jul 2015 22:09:22 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A59F42.1080205@satchell.net> References: <55A59F42.1080205@satchell.net> Message-ID: On Tue, Jul 14, 2015 at 4:46 PM, Stephen Satchell wrote: > This goes back a number of years. There was a product that literally was a > cardboard box that contained everything one needed to get started on the > Internet. Just add a modem and a computer, and you were on your way. No > fuss, no "learning curve". Ah, Spry Inc, where are you now? I still have the tee shirt and the totebag... https://en.wikipedia.org/wiki/Internet_in_a_Box http://images.search.yahoo.com/images/view;_ylt=AwrTcXcg6qVVBN4AYA42nIlQ;_ylu=X3oDMTIycGdrdTYyBHNlYwNzcgRzbGsDaW1nBG9pZAMyZTA0OTNhZjcyNzRlZTlhMjA5NjYzNWYzMDQxYWFmYQRncG9zAzQEaXQDYmluZw--?.origin=&back=http%3A%2F%2Fimages.search.yahoo.com%2Fyhs%2Fsearch%3Fp%3Dinternet%2Bin%2Ba%2Bbox%26type%3D__alt__ddc_linuxmint_com%26fr%3Dsfp%26fr2%3Dpiv-web%26hsimp%3Dyhs-linuxmint%26hspart%3Dddc%26tab%3Dorganic%26ri%3D4&w=270&h=252&imgurl=archive.cigarweekly.com%2Fimages%2Fint-in-a-box.jpg&rurl=http%3A%2F%2Farchive.cigarweekly.com%2Fmagazine%2Fcigarticles%2F02-04-2008%2Flife%2C-computers-and-the-partagas-serie-d-no.-4%3A-one-man-s-journey&size=14.2KB&name=Here+is+what+%3Cb%3EInternet+in+a+Box%3C%2Fb%3E+looked+like.&p=internet+in+a+box&oid=2e0493af7274ee9a2096635f3041aafa&fr2=piv-web&fr=sfp&tt=Here+is+what+%3Cb%3EInternet+in+a+Box%3C%2Fb%3E+looked+like.&b=0&ni=21&no=4&ts=&tab=organic&sigr=1402hm764&sigb=14ugkuu5g&sigi=11fniht2d&sigt=11iu4mkfg&sign=11iu4mkfg&fr=sfp&fr2=piv-web&hsimp=yhs-linuxmint&hspart=ddc&type=__alt__ddc_linuxmint_com I may even have my original box around, still unopened. ^_^; Ah, now you've got me all nostalgic.... Matt From randy at psg.com Wed Jul 15 05:25:48 2015 From: randy at psg.com (Randy Bush) Date: Tue, 14 Jul 2015 22:25:48 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1436936352.17261.60.camel@karl> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.camel@karl> <1436936352.17261.60.camel@karl> Message-ID: > Is a techno-colonialiasm the end result of some sort of musical/military > fetish? http://psg.com/on-technocolonialism.html > On reflection I think I was wrong about the /26 anyway. quite. and your dates are fuzzy too. but not really relevant. randy From owen at delong.com Wed Jul 15 06:20:09 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jul 2015 23:20:09 -0700 Subject: ARIN IPV4 Countdown In-Reply-To: <55A5B873.5010602@xyonet.com> References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <55A596AA.8090406@xyonet.com> <8FBED356-CCA0-4E05-8462-62230B5004D1@egon.cc> <55A5B873.5010602@xyonet.com> Message-ID: <10DE5D5F-7EDD-4716-8B43-4D8C09EBDD39@delong.com> Wait? You?re trying to convince me that it?s easier to understand ?You have this box in the way. It blocks many of the packets you want and some of the packets you don?t want. It also does weird things to the header in the process.? than it is to understand ?You have this box. By default it only allows outbound connections and blocks all incoming connections. You can tell it what you want to permit inbound. Your packet headers are the same on both sides of the box.? You have a different definition of ?easy to understand? than I do. Owen > On Jul 14, 2015, at 18:33 , Curtis Maurand wrote: > > > Since IPV6 does not have NAT, it's going to be difficult for the layman to understand their firewall. deployment of ipv4 is pretty simple. ipv6 on the otherhand is pretty difficult at the network level. yes, all the clients get everything automatically except for the router/firewall. > > -C > > On 7/14/2015 7:57 PM, James Downs wrote: >>> On Jul 14, 2015, at 16:09, Curtis Maurand wrote: >>> >>> i think IPV6 adoption is going to be very slow. It's very difficult for the layman to understand and that contributes to the slow rate of uptake. >> Who is the layman in this story? Almost every system I work with at home and in the datacenter has IPv6 turned on by default. If someone wandered through those networks, and started turning on IPv6 infrastructure so that they started getting IPv6 addresses, my bet is that most of the java-based applications would already be bound to the stacks in such a way that they would just start sending traffic over IPv6. I base this on the fact that any number of developers have been confused by ?::? being somewhere in their world now. Those people don?t care about the network, or IPv4 vs IPv6. It would just work. >> >> Now, if layman == Network Operators, and Networking people at Corporations, well, there you might be right. >> >> Cheers, >> -j > > -- > Best Regards > Curtis Maurand > Principal > Xyonet Web Hosting > mailto:cmaurand at xyonet.com > http://www.xyonet.com From marka at isc.org Wed Jul 15 06:22:33 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 15 Jul 2015 16:22:33 +1000 Subject: Remember "Internet-In-A-Box"? In-Reply-To: Your message of "Tue, 14 Jul 2015 21:19:34 -0400." <55A5B526.8030804@alter3d.ca> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> Message-ID: <20150715062233.E0CA0332D24B@rock.dv.isc.org> In message <55A5B526.8030804 at alter3d.ca>, Peter Kristolaitis writes: > On 7/14/2015 8:02 PM, Mike wrote: > > The flame wars and vitrol and rhetoric is too much noise for me to > > derive anything useful from. Someone needs to stand up and lead. I > > will happily follow. > > "Too much noise" has been v6's problem from the start. Every time I've > looked at v6 for use in the enterprise or even at home over the last ~15 > years, the answer is always "wait -- v6 isn't standardized yet", > "implement now -- v6 is ready for production", "wait -- v6 is missing > critical features", "implement now -- v6 is easier than v4" and "wait -- > v6 is too complex, and we don't have the best practices figured out yet" > -- all simultaneously, depending on who you ask, the phase of the moon, > local weather patterns, etc. And, to a significant degree, that's > still happening today. > > That's exarcerbated by the long development cycle, multiple conflicting > revisions/implementations over the years, and a severe case of feature > creep. Most people started to tune out around the third time we heard > "it's really here, for real this time!", and were completely > underwhelmed (or overwhelmed, as the case may be) when the "really here > for real" version arrived after a long hype cycle. > > So basically.... IPv6 is the Duke Nukem Forever of the networking > world. Took forever to get here, was completely underwhelming when it > did, and wasn't compelling enough for people to pony up money for other > than as a curiosity. Unfortunately v6 is an essential part of making > the Internet continue to work, because in any other scenario it would > have been abandoned as vaporware 10-15 years ago. If a product is in > development for 20 years, the expectation is that it's perfect out of > the box, reduced to the simplest possible implementation, and easily > understood -- and that's not what we have. Yet I can take a Windows XP box. Tell it to enable IPv6 and it just works. Everything that a node needed existed when Windows XP was released. The last 15 years has been waiting for ISP's and CPE vendors to deliver IPv6 as a product. This is not to say that every vendor deployed all the parts of the protocol properly but they existed. Most of the noise was people saying "We don't need IPv6" and second guessing the design decisions because they still had IPv4 think. If you look at the protocol it basically hasn't changed in the last 15 years. There has been minor tweak but what was there was complete enough to deploy. > - Pete -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mdavids at forfun.net Wed Jul 15 08:09:56 2015 From: mdavids at forfun.net (Marco Davids) Date: Wed, 15 Jul 2015 10:09:56 +0200 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150715062233.E0CA0332D24B@rock.dv.isc.org> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> Message-ID: <55A61554.30902@forfun.net> Mark is right and I couldn't agree more with him. On 15/07/15 08:22, Mark Andrews wrote: > Yet I can take a Windows XP box. Tell it to enable IPv6 and it > just works. Everything that a node needed existed when Windows XP > was released. The last 15 years has been waiting for ISP's and CPE > vendors to deliver IPv6 as a product. This is not to say that every > vendor deployed all the parts of the protocol properly but they > existed. > > Most of the noise was people saying "We don't need IPv6" and second > guessing the design decisions because they still had IPv4 think. > If you look at the protocol it basically hasn't changed in the last > 15 years. There has been minor tweak but what was there was complete > enough to deploy. > -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4239 bytes Desc: S/MIME Cryptographic Signature URL: From baldur.norddahl at gmail.com Wed Jul 15 10:28:35 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 15 Jul 2015 12:28:35 +0200 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A5A319.2070701@tiedyenetworks.com> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> Message-ID: On 15 July 2015 at 02:02, Mike wrote: > I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a /32 > of v6, but no clue yet how to get from where I am today to where we all > should be. The flame wars and vitrol and rhetoric is too much noise for me > to derive anything useful from. Someone needs to stand up and lead. I will > happily follow. > > Whats really needed, is for you gods of ipv6, to write that 'ipv6 for ipv4 > dummies', targeting service providers and telling us exactly what we need > to do. No religious wars about subnet allocation sizes or dhcpv6 vs slaac > or anything. Tell us how to get it onto our network, give us reasonable > deployment scenarios that leverage our experience with IPv4 and tell us > what we are going to tell our customers. Help us understand WHY nat is not > a security model, and how to achieve the same benefits we have with nat > now, in an ipv6 enabled world. You can't be a "dummy" and a service provider... There is a million ways to implement a service provider network and that goes for both IPv4 and IPv6. Writing a simple text that covers all possibilities is impossible. What is your setup like? Implementing IPv6 can be very simple, almost just run the "on" command. Or it can be very hard. It depends on what equipment you got and what features you need. And your luck. In my case it turned out to be hard. I thought it would be easy. I bought equipment that had IPv6 written all over it and it was a greenfield network. The plan was to have IPv6 from birth. That was not to be. A year later knew far too much about: DHCPv6 relay chaining - not supported. Relay chaining is when you have the access switch tag the DHCPv6 request with a customer identifier and then your access router has to do DHCPv6 relay on that. DHCPv6 relay in supervlan - not supported. IPv6 must not be enabled at the same time as MPLS layer 2 VPN (VPLS). DHCPv6-PD: When we said we had DHCPv6 support we meant IA_NA not IA_PD. DHCPv6 snooping not supported with prefix delegation. MPLS VPNv6 not supported. IPv6 prefixes more specific than /64 gets routed in CPU without any warnings. No support for route injection by DHCPv6-PD snooping. Oh and they just said they fixed most of the above issue in a new firmware that is not compatible with the hardware I got. I am afraid that even in 2015 many IPv6 implementations are still half baked. I was left feeling like I was the first guy to actually test this stuff. I managed to duct tape it all together despite the above limitations. But forget about easy. Regards, Baldur From baldur.norddahl at gmail.com Wed Jul 15 10:43:49 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 15 Jul 2015 12:43:49 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <2C50C88F-D328-40B4-A785-5115965F6128@delong.com> References: <20150714184425.24695.qmail@ary.lan> <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> <2C50C88F-D328-40B4-A785-5115965F6128@delong.com> Message-ID: On 15 July 2015 at 01:34, Owen DeLong wrote: > For one thing a /32 is nowhere near enough for anything bigger than a > modest ISP today. Many will need /28, /24, or even larger. The biggest ones > probably need /16 or even /12 in some cases. > What is the definition of a modest and a large ISP? In the RIPE region even the smallest ISP can get a /29 with no documentation necessary. But likely that is all they will ever get because policy requires that you use that /29 at about 30% efficiency if you do /48 allocations to end users. You would need more than a million users to get a /24. I do not think the RIPE region has an ISP large enough to apply for a /16 or anything near it. Therefore we can conclude that if ARIN manages to use up all the /3 address space currently reserved for allocation, we will still be able to get address space in Europe for the next thousands years :-). It is thought that RIPE will not use up the /12 that IANA allocated to RIPE - ever. Personally I believe the ARIN policy is the sane one. But we need to abide by the rules in the region we live in. Regards, Baldur From jared at puck.nether.net Wed Jul 15 11:54:58 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 15 Jul 2015 07:54:58 -0400 Subject: ATT wireless IPv6 Message-ID: Does anyone know what the story is here? They have some transparent proxies for IPv4 traffic and I was wondering if they were to be IPv6 enabled soon or if IPv6 will reach the handset. Thanks, Jared Mauch From mel at beckman.org Wed Jul 15 12:52:23 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 15 Jul 2015 12:52:23 +0000 Subject: Remember "Internet-In-A-Box"? In-Reply-To: References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com>, Message-ID: <227A0305-0D44-4FF4-BFD3-A94FC6510E8B@beckman.org> Did you deploy Mikrotik routers by any chance? -mel beckman > On Jul 15, 2015, at 3:29 AM, Baldur Norddahl wrote: > >> On 15 July 2015 at 02:02, Mike wrote: >> >> I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a /32 >> of v6, but no clue yet how to get from where I am today to where we all >> should be. The flame wars and vitrol and rhetoric is too much noise for me >> to derive anything useful from. Someone needs to stand up and lead. I will >> happily follow. >> >> Whats really needed, is for you gods of ipv6, to write that 'ipv6 for ipv4 >> dummies', targeting service providers and telling us exactly what we need >> to do. No religious wars about subnet allocation sizes or dhcpv6 vs slaac >> or anything. Tell us how to get it onto our network, give us reasonable >> deployment scenarios that leverage our experience with IPv4 and tell us >> what we are going to tell our customers. Help us understand WHY nat is not >> a security model, and how to achieve the same benefits we have with nat >> now, in an ipv6 enabled world. > > > You can't be a "dummy" and a service provider... > > There is a million ways to implement a service provider network and that > goes for both IPv4 and IPv6. Writing a simple text that covers all > possibilities is impossible. What is your setup like? > > Implementing IPv6 can be very simple, almost just run the "on" command. Or > it can be very hard. It depends on what equipment you got and what features > you need. And your luck. > > In my case it turned out to be hard. I thought it would be easy. I bought > equipment that had IPv6 written all over it and it was a greenfield > network. The plan was to have IPv6 from birth. That was not to be. > > A year later knew far too much about: > > DHCPv6 relay chaining - not supported. Relay chaining is when you have the > access switch tag the DHCPv6 request with a customer identifier and then > your access router has to do DHCPv6 relay on that. > > DHCPv6 relay in supervlan - not supported. > > IPv6 must not be enabled at the same time as MPLS layer 2 VPN (VPLS). > > DHCPv6-PD: When we said we had DHCPv6 support we meant IA_NA not IA_PD. > DHCPv6 snooping not supported with prefix delegation. > > MPLS VPNv6 not supported. > > IPv6 prefixes more specific than /64 gets routed in CPU without any > warnings. > > No support for route injection by DHCPv6-PD snooping. > > Oh and they just said they fixed most of the above issue in a new firmware > that is not compatible with the hardware I got. > > I am afraid that even in 2015 many IPv6 implementations are still half > baked. I was left feeling like I was the first guy to actually test this > stuff. > > I managed to duct tape it all together despite the above limitations. But > forget about easy. > > Regards, > > Baldur From chuckchurch at gmail.com Wed Jul 15 13:00:28 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 15 Jul 2015 09:00:28 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150714184425.24695.qmail@ary.lan>, <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org>, <25137.1436903621@turing-police.cc.vt.edu> <002f01d0be76$52b0c800$f8125800$@gmail.com> Message-ID: <005701d0befe$3f70c4b0$be524e10$@gmail.com> -----Original Message----- From: John R. Levine [mailto:johnl at iecc.com] Sent: Tuesday, July 14, 2015 4:50 PM To: Chuck Church Cc: nanog at nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion >This is IPv6. Why shouldn't they have their own PI space? Same way it happens today. Business starts out small, uses IP space from their single ISP. Couple years later, they're bigger and want to dual-home for better uptime or other reasons. Unless there is something stopping them from advertising their ISP 'A' space out to ISP 'B' in IPv6 land, we're probably going to see the same things we see with IPv4 no? Chuck From jlk at thrashyour.com Wed Jul 15 13:27:08 2015 From: jlk at thrashyour.com (John Kinsella) Date: Wed, 15 Jul 2015 16:27:08 +0300 Subject: Remember "Internet-In-A-Box"? In-Reply-To: References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> Message-ID: <55A65FAC.3090208@thrashyour.com> On 7/15/15 1:28 PM, Baldur Norddahl wrote: > You can't be a "dummy" and a service provider... oh? :) From Lee at asgard.org Wed Jul 15 13:52:22 2015 From: Lee at asgard.org (Lee Howard) Date: Wed, 15 Jul 2015 09:52:22 -0400 Subject: ARIN IPV4 Countdown In-Reply-To: References: <8788f4b230e6431f89c4ded02a46168f@exmbxprd01.ad.ufl.edu> <8370BDBC-2A04-4F3F-B042-DF1D1B166871@delong.com> <019c01d0be55$95459f90$bfd0deb0$@tndh.net> <02a601d0beab$cb492d40$61db87c0$@tndh.net> Message-ID: On 7/14/15, 11:16 PM, "NANOG on behalf of Randy Bush" wrote: >> While the base curve it runs on is running ahead of the measured traffic >> curve, the measure of IPv6 enabled browsers is a reasonable indicator >>for >> what is happening. > >we're an isp, with ipv6 enabled since 1997. we measure real traffic, >not wishes of what could be. I don?t know how much of your traffic is IPv6, but ?10% by the time we retire? sure looks like a prediction. If it?s number of users, that?s well above 10%. IPv6 support in a couple of video streaming devices would push it well past that. I hope you?re right about retiring at 10%?it would be great to have the resources to retire this year. Lee > >randy > From Lee at asgard.org Wed Jul 15 13:59:09 2015 From: Lee at asgard.org (Lee Howard) Date: Wed, 15 Jul 2015 09:59:09 -0400 Subject: 'gray' market IPv4 In-Reply-To: References: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> Message-ID: Price varies significantly by prefix length, and somewhat by region. Regional variance may not be as much as it used to be. Lee On 7/14/15, 6:15 PM, "NANOG on behalf of Pavel Odintsov" wrote: >Hello, folks! > >I have finished multiple (and 5th in RIPE) inter RIR subnet moves in RIPE >region. We have moved multiple /21-/20 networks and awerage cost was about >$10 per ip. > >On Tuesday, July 14, 2015, Martin Hannigan wrote: > >> On Tue, Jul 14, 2015 at 10:22 AM, Matt Kelly > > wrote: >> >> > This list is actual sale prices, >> > http://www.ipv4auctions.com/previous_auctions/ >> > >> > >> > -- >> > Matt >> > >> > >> > On July 14, 2015 at 10:14:05 AM, Justin Wilson - MTIN (lists at mtin.net >> ) >> > wrote: >> > >> > Thes folks (and I am not advertising or affiliated with them) publish >>a >> > list of most recent transfer completed: >> > >> > http://ipv4marketgroup.com/broker-services/buy/ >> > >> > >> http://ipv4marketgroup.com/broker-services/buy/ vs. >> http://www.ipv4auctions.com/previous_auctions/ >> >> >> If you compare the pricing that both have made available you will find >>one >> is posting average prices exponentially higher than the other. When you >> trend the granular auction site data the auction numbers demonstrate a >> trend would expect, that smaller prefixes are more expensive since it >> takes a similar amount of effort to process a /24 as it does a /20. >>Dollar >> differences between a /24 unit and a /17 unit move the needle >> significantly. >> >> Based on both of both sets of public data its easy to conclude that >> auctions will work for at least small buyers of space if they're >> sophisticated enough to address the RIR issues. If you do decide to take >> the simple broker approach (not all are simple and not all approaches >>are >> suitable to simple brokers), use an RFP. And Yelp. :-) >> >> Best, >> >> -M< >> > > >-- >Sincerely yours, Pavel Odintsov > From mikea at mikea.ath.cx Wed Jul 15 14:05:31 2015 From: mikea at mikea.ath.cx (mikea) Date: Wed, 15 Jul 2015 09:05:31 -0500 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A65FAC.3090208@thrashyour.com> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A65FAC.3090208@thrashyour.com> Message-ID: <20150715140531.GA76169@mikea.ath.cx> On Wed, Jul 15, 2015 at 04:27:08PM +0300, John Kinsella wrote: > On 7/15/15 1:28 PM, Baldur Norddahl wrote: > >You can't be a "dummy" and a service provider... > > oh? :) Counterexample: Cox. They refuse to even admit to me that they are even considering IPV6. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From joelja at bogus.com Wed Jul 15 15:14:52 2015 From: joelja at bogus.com (joel jaeggli) Date: Wed, 15 Jul 2015 08:14:52 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150714184425.24695.qmail@ary.lan> <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> <2C50C88F-D328-40B4-A785-5115965F6128@delong.com> Message-ID: <55A678EC.80304@bogus.com> On 7/15/15 3:43 AM, Baldur Norddahl wrote: > On 15 July 2015 at 01:34, Owen DeLong wrote: > >> For one thing a /32 is nowhere near enough for anything bigger than a >> modest ISP today. Many will need /28, /24, or even larger. The biggest ones >> probably need /16 or even /12 in some cases. >> > > What is the definition of a modest and a large ISP? > > In the RIPE region even the smallest ISP can get a /29 with no > documentation necessary. But likely that is all they will ever get because > policy requires that you use that /29 at about 30% efficiency if you do /48 > allocations to end users. > > You would need more than a million users to get a /24. > > I do not think the RIPE region has an ISP large enough to apply for a /16 > or anything near it. there are 4 organizations that originate something on the order of a /19 1 AS7922 ORG+TRN Originate: 36318243454976 /18.95 Transit: 38476054528 /28.84 COMCAST-7922 - Comcast Cable Communications, Inc.,US 2 AS3320 ORG+TRN Originate: 35219269156864 /19.00 Transit: 569424150528 /24.95 DTAG Deutsche Telekom AG,DE 3 AS5511 ORG+TRN Originate: 35188667187200 /19.00 Transit: 17818772963328 /19.98 OPENTRANSIT Orange S.A.,FR 4 AS17676 ORG+TRN Originate: 18695992639488 /19.91 Transit: 12885032960 /30.42 GIGAINFRA Softbank BB Corp.,JP > Therefore we can conclude that if ARIN manages to use up all the /3 address > space currently reserved for allocation, we will still be able to get > address space in Europe for the next thousands years :-). It is thought > that RIPE will not use up the /12 that IANA allocated to RIPE - ever. > > Personally I believe the ARIN policy is the sane one. But we need to abide > by the rules in the region we live in. > > Regards, > > Baldur > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From george.metz at gmail.com Wed Jul 15 15:20:20 2015 From: george.metz at gmail.com (George Metz) Date: Wed, 15 Jul 2015 11:20:20 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A5AB96.8090101@dougbarton.us> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dougbarton.us> Message-ID: Reasonability, like beauty, is in the eye of the beholder, but I thank you for the compliment. :) The short answer is "yes, that constitutes being prudent". The longer answer is "it depends on what you consider the wildest dreams". There's a couple of factors playing in. First, look at every /64 that is assigned as an IPv4 /32 that someone is running NAT behind. This is flat out WRONG from a routing perspective, but from an allocation perspective, it's very much exactly what's happening because of SLAAC and the 48-bit MAC address basis for it. Since /64 is the minimum, that leaves us with less than half of the available bit mask in which to hand out that 1/8th the address space. Still oodles of addresses, but worth noting and is probably one reason why some of the "conservationists" react the way they do. Next, let's look at the wildest dreams aspect. The current "implementation" I'm thinking of in modern pop culture is Big Hero 6 (the movie, not the comics as I've never read them). Specifically, Hiro's "microbots". Each one needs an address to be able to communicate with the controller device. Even with the numbers of them, can probably be handled with a /64, but you'd also probably want them in separate "buckets" if you're doing separated tasks. Even so, a /48 could EASILY handle it. Now make them the size of a large-ish molecule. Or atom. Or protons. Nanotech or femtotech that's advanced enough gets into Clarke's Law - any sufficiently advanced technology is indistinguishable from magic - but in order to do that they need to communicate. If you think that won't be possible in the next 30 years, you probably haven't been paying attention. However, that's - barring a fundamental breakthrough - probably a decade or two off. Meanwhile we've got connected soda cans to worry about. I wrote my email as a way of pointing out that maybe the concerns (on both sides)- aren't baseless, but at the same time maybe there's a way to split the difference. It's not too much of a stretch to see that, soon, 256 subnets may not actually be enough to deal with the connected world and "Internet of Things" that's currently being developed. But would 1024? How about 4096? Is there any need in the next 10-15 years for EVERYONE to be getting handed 65,536 /64 subnets? Split the difference, go with a /52 and suddenly you've got FOUR THOUSAND subnets for individual users so that their soda cans can tell the suspension on their car that it's been opened and please smooth out the ride. Frankly, both sides seem intent on overkill in their preferred direction, and it's not particularly hard to meet in the middle. On Tue, Jul 14, 2015 at 8:38 PM, Doug Barton wrote: > On 7/14/15 6:23 AM, George Metz wrote: > >> It's always easier to be prudent from the get-go than it is to rein in the >> insanity at a later date. Just because we can't imagine a world where IPv6 >> depletion is possible doesn't mean it can't exist, and exist far sooner >> than one might expect. >> > > I've been trying to stay out of this Nth repetition of the same > nonsensical debate, since neither side has anything new to add. However > George makes a valid point, which is "learn from the mistakes of the past." > > So let me ask George, who seems like a reasonable fellow ... do you think > that creating an addressing plan that is more than adequate for even the > wildest dreams of current users and future growth out of just 1/8 of the > available space (meaning of course that we have 7/8 left to work with > should we make a complete crap-show out of 2000::/3) constitutes being > prudent, or not? > > And please note, this is not a snark, I am genuinely interested in the > answer. I used to be one of the people responsible for the prudent use of > the integers (as the former IANA GM) so this is something I've put a lot of > thought into, and care deeply about. If there is something we've missed in > concocting the current plan, I definitely want to know about it. > > Even taking into account some of the dubious decisions that were made 20 > years ago, the numbers involved in IPv6 deployment are literally so > overwhelming that the human brain has a hard time conceiving of them. > Combine that with the conservation mindset that's been drilled into > everyone regarding IPv4 resources, and a certain degree of over-enthusiasm > for conserving IPv6 resources is understandable. But at the same time, > because the volume of integers is so vast, it could be just as easy to slip > into the early-days v4 mindset of "infinite," which is why I like to hear a > good reality check now and again. :) > > Doug > > -- > I am conducting an experiment in the efficacy of PGP/MIME signatures. This > message should be signed. If it is not, or the signature does not validate, > please let me know how you received this message (direct, or to a list) and > the mail software you use. Thanks! > > From Lee at asgard.org Wed Jul 15 15:24:35 2015 From: Lee at asgard.org (Lee Howard) Date: Wed, 15 Jul 2015 11:24:35 -0400 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A5A319.2070701@tiedyenetworks.com> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> Message-ID: I google?d ?IPv6 for Dummies? and found this: https://www.wesecure.nl/upload/documents/tinymce/IPv6.pdf It?s licensed from the For Dummies series, written and published by Infoblox. more below. . . On 7/14/15, 8:02 PM, "NANOG on behalf of Mike" wrote: > > >On 07/14/2015 04:46 PM, Stephen Satchell wrote: >> This goes back a number of years. There was a product that literally >> was a cardboard box that contained everything one needed to get >> started on the Internet. Just add a modem and a computer, and you >> were on your way. No fuss, no "learning curve". >> >> I'm beginning to think that someone needs to create a similar product, >> but for IPv6 internet. The Internet service providers would provide >> the same sort of kit to get people started. Just add a CSU/DSU (like >> a cable modem) and a computer, and you are on your way. >> >> Also, I think we need a *real* book called "IPv6 for Dummies" (maybe >> even published by IDG Books) that walks through all the beginner >> stuff. There's beginner stuff that I've seen by using a search >> engine; a dead-tree book, though, may well be better for Joe Average. >> >> Just my pair-o-pennies(tm) >> >> > >I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a >/32 of v6, but no clue yet how to get from where I am today to where we >all should be. The flame wars and vitrol and rhetoric is too much noise >for me to derive anything useful from. Someone needs to stand up and >lead. I will happily follow. I also co-authored RFC6782, intended to be guidance for landline ISPs deploying IPv6: http://tools.ietf.org/html/rfc6782 We really tried to make it step-by-step, and you don?t necessarily need to hit each step (as we explain in the document). > >Whats really needed, is for you gods of ipv6, to write that 'ipv6 for >ipv4 dummies', targeting service providers and telling us exactly what >we need to do. No religious wars about subnet allocation sizes or dhcpv6 >vs slaac or anything. Tell us how to get it onto our network, give us >reasonable deployment scenarios that leverage our experience with IPv4 >and tell us what we are going to tell our customers. Help us understand >WHY nat is not a security model, and how to achieve the same benefits we >have with nat now, in an ipv6 enabled world. Send me private email and we can set up time to talk. I won?t know the IPv6 capabilities of every piece of equipment you have, but I might be able to help you plan. Lee > >Mike > > > > From johnl at iecc.com Wed Jul 15 15:25:05 2015 From: johnl at iecc.com (John Levine) Date: 15 Jul 2015 15:25:05 -0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <005701d0befe$3f70c4b0$be524e10$@gmail.com> Message-ID: <20150715152505.26352.qmail@ary.lan> >Same way it happens today. Business starts out small, uses IP space from >their single ISP. Couple years later, they're bigger and want to dual-home >for better uptime or other reasons. Unless there is something stopping them >from advertising their ISP 'A' space out to ISP 'B' in IPv6 land, we're >probably going to see the same things we see with IPv4 no? Sigh. We can hope that ISP B would push back a little and tell the customer that it's a lot easier to get v6 space, and once they do, they will have their own IP space forever and not be in thrall to ISP A. It would be nice if it were possible to implement BCP 38 in IPv6, since this is the reason it isn't in IPv4. R's, John From Valdis.Kletnieks at vt.edu Wed Jul 15 15:49:14 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 15 Jul 2015 11:49:14 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "15 Jul 2015 15:25:05 -0000." <20150715152505.26352.qmail@ary.lan> References: <20150715152505.26352.qmail@ary.lan> Message-ID: <3772.1436975354@turing-police.cc.vt.edu> On 15 Jul 2015 15:25:05 -0000, "John Levine" said: > It would be nice if it were possible to implement BCP 38 in IPv6, since this > is the reason it isn't in IPv4. There isn't any technical reason that an organization can't fix its edge so it doesn't urinate bad IPv6 traffic all over the Internet. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From matthew at matthew.at Wed Jul 15 15:50:49 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 15 Jul 2015 08:50:49 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150715152505.26352.qmail@ary.lan> References: <20150715152505.26352.qmail@ary.lan> Message-ID: <55A68159.6080406@matthew.at> On 7/15/2015 8:25 AM, John Levine wrote: > It would be nice if it were possible to implement BCP 38 in IPv6, > since this is the reason it isn't in IPv4. Too bad the hazards of allowing people to use arbitrary source addresses weren't known when IPv6 was designed. Matthew Kaufman From matthew at matthew.at Wed Jul 15 15:57:26 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 15 Jul 2015 08:57:26 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150715062233.E0CA0332D24B@rock.dv.isc.org> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> Message-ID: <55A682E6.1050607@matthew.at> On 7/14/2015 11:22 PM, Mark Andrews wrote: > > Yet I can take a Windows XP box. Tell it to enable IPv6 and it > just works. Everything that a node needed existed when Windows XP > was released. The last 15 years has been waiting for ISP's and CPE > vendors to deliver IPv6 as a product. This is not to say that every > vendor deployed all the parts of the protocol properly but they > existed. This is only true for dual-stacked networks. I just tried to set up an IPv6-only WiFi network at my house recently, and it was a total fail due to non-implementation of relatively new standards... starting with the fact that my Juniper SRX doesn't run a load new enough to include RDNSS information in RAs, and some of the devices I wanted to test with (Android tablets) won't do DHCPv6. The XP box is in an even worse situation if you try to run it on a v6-only network. And yet we've known for years now that dual-stack wasn't going to be an acceptable solution, because nobody was on track to get to 100% IPv6 before IPv4 runout happened. Go to any business with hardware that is 3-5 years old in its IT infrastructure and devices ranging from PCs running XP to the random consumer gear people bring in (cameras, printers, tablets, etc.) and see how easy it is to get everything talking on an IPv6-only (no IPv4 at all) network... including using IPv6 to do automatic updates and all the other pieces that need to work. We're nowhere near ready for that. Matthew Kaufman From owen at delong.com Wed Jul 15 15:58:19 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 08:58:19 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150714184425.24695.qmail@ary.lan> <23735.1436902536@turing-police.cc.vt.edu> <4F0F86FC-4751-4CE9-9CA9-16270ADBDF1E@beckman.org> <2C50C88F-D328-40B4-A785-5115965F6128@delong.com> Message-ID: <778184BA-EE82-4103-B8EE-7EA4EDBF294D@delong.com> > On Jul 15, 2015, at 03:43 , Baldur Norddahl wrote: > > On 15 July 2015 at 01:34, Owen DeLong wrote: > >> For one thing a /32 is nowhere near enough for anything bigger than a >> modest ISP today. Many will need /28, /24, or even larger. The biggest ones >> probably need /16 or even /12 in some cases. >> > > What is the definition of a modest and a large ISP? > > In the RIPE region even the smallest ISP can get a /29 with no > documentation necessary. But likely that is all they will ever get because > policy requires that you use that /29 at about 30% efficiency if you do /48 > allocations to end users. Which is fine? 30% of a /29 at /48 is 524,288 end-sites served. For a residential provider, I?d say that?s a medium-sized provider. A large provider would be one that serves several million end-sites. There are at least a handful of providers in the US for example, that have 10,000,000+ customers. A /29 wouldn?t be enough for them. RIPEs policy ignores the inefficiencies created by topology and that?s kind of unfortunate in my opinion, but so far it doesn?t appear too egregious, so I haven?t taken the time to propose better policy. > You would need more than a million users to get a /24. Sure. Many ISPs have more than a million end-sites (note end-sites != users). In many cases customer and end-site are synonymous, but in many cases, a single customer may have many end-sites. For example, a business which has several buildings in a campus may treat each building as an end-site. A multi-tenant building would likely treat each tenant as a separate end-site. etc. > I do not think the RIPE region has an ISP large enough to apply for a /16 > or anything near it. Perhaps. There are at least 2 ISPs in the US that I know of with 20,000,000+ customers. Since the NA in NANOG stands for North America, I kind of figured that the situation in North America ought to be considered somewhat relevant. > Therefore we can conclude that if ARIN manages to use up all the /3 address > space currently reserved for allocation, we will still be able to get > address space in Europe for the next thousands years :-). It is thought > that RIPE will not use up the /12 that IANA allocated to RIPE - ever. I doubt even with our current policy, ARIN is unlikely to use up the /12 in my lifetime or even in the lifetime of the IPv6 protocol. Even if we do, I doubt we will use more than 2 or 3 /12s ever. > Personally I believe the ARIN policy is the sane one. But we need to abide > by the rules in the region we live in. I agree with you, but as the author of the current ARIN ISP IPv6 policy, I may be biased. ;-) Owen From johnl at iecc.com Wed Jul 15 16:10:51 2015 From: johnl at iecc.com (John R. Levine) Date: 15 Jul 2015 12:10:51 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <3772.1436975354@turing-police.cc.vt.edu> References: <20150715152505.26352.qmail@ary.lan> <3772.1436975354@turing-police.cc.vt.edu> Message-ID: >> It would be nice if it were possible to implement BCP 38 in IPv6, since this >> is the reason it isn't in IPv4. > > There isn't any technical reason that an organization can't fix its edge > so it doesn't urinate bad IPv6 traffic all over the Internet. In IPv4 systems, the problem is (so I have been told by some largish ISPs) that a dual homed customer gets address ranges from ISPs A and B, and sends traffic with A addresses to the B interface. The ISPs have no practical way to tell legit dual homed traffic from malicious, particularly when there is a chain of resellers in between. If the ISP tells the customer to send the traffic over the right interface, the usual response is "if you don't want our business, I'm sure we can find another ISP that does." Like I said, it would be nice if ISPs could persuade their v6 customers to get their own PI space early on, because if they don't they'll have exactly the same problem. R's, John From owen at delong.com Wed Jul 15 16:20:25 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 09:20:25 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dou! gbarton.us> Message-ID: > On Jul 15, 2015, at 08:20 , George Metz wrote: > > Reasonability, like beauty, is in the eye of the beholder, but I thank you > for the compliment. :) > > The short answer is "yes, that constitutes being prudent". The longer > answer is "it depends on what you consider the wildest dreams". > > There's a couple of factors playing in. First, look at every /64 that is > assigned as an IPv4 /32 that someone is running NAT behind. This is flat > out WRONG from a routing perspective, but from an allocation perspective, > it's very much exactly what's happening because of SLAAC and the 48-bit MAC > address basis for it. Since /64 is the minimum, that leaves us with less > than half of the available bit mask in which to hand out that 1/8th the > address space. Still oodles of addresses, but worth noting and is probably > one reason why some of the "conservationists" react the way they do. Then they are being silly. The thinking for IPv6 was a 64-bit address in toto until SLAAC was proposed and 64 bits were added to enable that. Even at 64 bits, you have more than 4 billion times as many network numbers as you had host numbers in all of IPv4. > Next, let's look at the wildest dreams aspect. The current "implementation" > I'm thinking of in modern pop culture is Big Hero 6 (the movie, not the > comics as I've never read them). Specifically, Hiro's "microbots". Each one > needs an address to be able to communicate with the controller device. Even > with the numbers of them, can probably be handled with a /64, but you'd > also probably want them in separate "buckets" if you're doing separated > tasks. Even so, a /48 could EASILY handle it. Right? > Now make them the size of a large-ish molecule. Or atom. Or protons. > Nanotech or femtotech that's advanced enough gets into Clarke's Law - any > sufficiently advanced technology is indistinguishable from magic - but in > order to do that they need to communicate. If you think that won't be > possible in the next 30 years, you probably haven't been paying attention. Sure, but do you really think that IPv6 can handle that in all the other ways? I think we?ll need a new protocol to do that for reasons other than address space limitations well before we run out of IPv6 addresses. > However, that's - barring a fundamental breakthrough - probably a decade or > two off. Meanwhile we've got connected soda cans to worry about. True. > I wrote my email as a way of pointing out that maybe the concerns (on both > sides)- aren't baseless, but at the same time maybe there's a way to split > the difference. It's not too much of a stretch to see that, soon, 256 > subnets may not actually be enough to deal with the connected world and > "Internet of Things" that's currently being developed. But would 1024? How > about 4096? Is there any need in the next 10-15 years for EVERYONE to be > getting handed 65,536 /64 subnets? Split the difference, go with a /52 and > suddenly you've got FOUR THOUSAND subnets for individual users so that > their soda cans can tell the suspension on their car that it's been opened > and please smooth out the ride. There are two ways to waste addresses. One is to allocate them to users who don?t actually use all of them. The other is to keep them on the shelf in the free pool until well past the useful life of the protocol. I don?t see splitting the difference at /52 as being any more useful than leaving it at /48. Certainly it is an incremental improvement over /56 and wildly better than /60, but it remains an unnecessarily inferior solution. > Frankly, both sides seem intent on overkill in their preferred direction, > and it's not particularly hard to meet in the middle. Perhaps, but it?s also not hard to do harmful things with the best of intent. Owen > > On Tue, Jul 14, 2015 at 8:38 PM, Doug Barton wrote: > >> On 7/14/15 6:23 AM, George Metz wrote: >> >>> It's always easier to be prudent from the get-go than it is to rein in the >>> insanity at a later date. Just because we can't imagine a world where IPv6 >>> depletion is possible doesn't mean it can't exist, and exist far sooner >>> than one might expect. >>> >> >> I've been trying to stay out of this Nth repetition of the same >> nonsensical debate, since neither side has anything new to add. However >> George makes a valid point, which is "learn from the mistakes of the past." >> >> So let me ask George, who seems like a reasonable fellow ... do you think >> that creating an addressing plan that is more than adequate for even the >> wildest dreams of current users and future growth out of just 1/8 of the >> available space (meaning of course that we have 7/8 left to work with >> should we make a complete crap-show out of 2000::/3) constitutes being >> prudent, or not? >> >> And please note, this is not a snark, I am genuinely interested in the >> answer. I used to be one of the people responsible for the prudent use of >> the integers (as the former IANA GM) so this is something I've put a lot of >> thought into, and care deeply about. If there is something we've missed in >> concocting the current plan, I definitely want to know about it. >> >> Even taking into account some of the dubious decisions that were made 20 >> years ago, the numbers involved in IPv6 deployment are literally so >> overwhelming that the human brain has a hard time conceiving of them. >> Combine that with the conservation mindset that's been drilled into >> everyone regarding IPv4 resources, and a certain degree of over-enthusiasm >> for conserving IPv6 resources is understandable. But at the same time, >> because the volume of integers is so vast, it could be just as easy to slip >> into the early-days v4 mindset of "infinite," which is why I like to hear a >> good reality check now and again. :) >> >> Doug >> >> -- >> I am conducting an experiment in the efficacy of PGP/MIME signatures. This >> message should be signed. If it is not, or the signature does not validate, >> please let me know how you received this message (direct, or to a list) and >> the mail software you use. Thanks! >> >> From owen at delong.com Wed Jul 15 16:24:40 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 09:24:40 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A682E6.1050607@matthew.at> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> Message-ID: > On Jul 15, 2015, at 08:57 , Matthew Kaufman wrote: > > On 7/14/2015 11:22 PM, Mark Andrews wrote: >> >> Yet I can take a Windows XP box. Tell it to enable IPv6 and it >> just works. Everything that a node needed existed when Windows XP >> was released. The last 15 years has been waiting for ISP's and CPE >> vendors to deliver IPv6 as a product. This is not to say that every >> vendor deployed all the parts of the protocol properly but they >> existed. > > This is only true for dual-stacked networks. I just tried to set up an IPv6-only WiFi network at my house recently, and it was a total fail due to non-implementation of relatively new standards... starting with the fact that my Juniper SRX doesn't run a load new enough to include RDNSS information in RAs, and some of the devices I wanted to test with (Android tablets) won't do DHCPv6. That?s a pretty old load then, as I?ve had RDNSS on my SRX-100 for several years now. > The XP box is in an even worse situation if you try to run it on a v6-only network. Only if you care about DNS. > And yet we've known for years now that dual-stack wasn't going to be an acceptable solution, because nobody was on track to get to 100% IPv6 before IPv4 runout happened. An IPv6-only DNS server with RFC-1918 IPv4 connectivity to your XP box does solve the problem in question. > Go to any business with hardware that is 3-5 years old in its IT infrastructure and devices ranging from PCs running XP to the random consumer gear people bring in (cameras, printers, tablets, etc.) and see how easy it is to get everything talking on an IPv6-only (no IPv4 at all) network... including using IPv6 to do automatic updates and all the other pieces that need to work. We're nowhere near ready for that. Anyone who has that already has IPv4 addresses on all that ancient gear, so they can, in fact, dual stack at least that fraction of their network. How about helping them deploy instead of continually trying to throw red herrings in their path. Owen From Lee at asgard.org Wed Jul 15 16:41:08 2015 From: Lee at asgard.org (Lee Howard) Date: Wed, 15 Jul 2015 12:41:08 -0400 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A682E6.1050607@matthew.at> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> Message-ID: On 7/15/15, 11:57 AM, "NANOG on behalf of Matthew Kaufman" wrote: > >Go to any business with hardware that is 3-5 years old in its IT >infrastructure and devices ranging from PCs running XP to the random >consumer gear people bring in (cameras, printers, tablets, etc.) and see >how easy it is to get everything talking on an IPv6-only (no IPv4 at >all) network... including using IPv6 to do automatic updates and all the >other pieces that need to work. We're nowhere near ready for that. This is painfully true. I don?t have much sympathy for Windows XP, since it?s a year past extended End of Support, and it?s a 15-year-old operating system, now five generations obsolete? But specific-purpose consumer electronics are failures: not just cameras, but game consoles, set-top boxes, audio-video systems. Even security critical stuff like software updates, anti-virus updates, CRL checks, are almost completely unavailable over IPv6. Unless you run a large enough enterprise to have your own update servers; then they can pull updates over IPv4, and serve clients over IPv6. However, if you dual-stack now, you?ll be able to identify which things are still dependent on IPv4, and either engineer differently, or substitute equipment over time. Lee > >Matthew Kaufman > > From jmaimon at ttec.com Wed Jul 15 17:24:29 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 15 Jul 2015 13:24:29 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150715010018.CC3C733059FF@rock.dv.isc.org> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> Message-ID: <55A6974D.2010102@ttec.com> Mark Andrews wrote: > In message > We don't use Class E because were using up IPv4 space too quickly > to make it worthwhile to make it work cleanly for everyone. That is a self fulfilling prophecy. I suspect a 16 /8 right about now would be very welcome for everybody other then the ipv6 adherents. Seems like procrastination is only bad when its your baby. The jury is still out on class E, but the verdict is in for the community who created it. Joe From dougb at dougbarton.us Wed Jul 15 18:11:05 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 15 Jul 2015 11:11:05 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dougbarton.us> Message-ID: <55A6A239.2080304@dougbarton.us> On 7/15/15 8:20 AM, George Metz wrote: > Reasonability, like beauty, is in the eye of the beholder, but I thank > you for the compliment. :) I call them like I see them. :) > The short answer is "yes, that constitutes being prudent". Ok, good news so far. :) > The longer > answer is "it depends on what you consider the wildest dreams". > > There's a couple of factors playing in. First, look at every /64 that is > assigned as an IPv4 /32 that someone is running NAT behind. Ok, that's a relatively common analogy, even if it isn't quite technically correct. > This is flat > out WRONG from a routing perspective, but from an allocation > perspective, it's very much exactly what's happening because of SLAAC > and the 48-bit MAC address basis for it. Since /64 is the minimum, that > leaves us with less than half of the available bit mask in which to hand > out that 1/8th the address space. I have my own issues with RA/SLAAC, but let's leave those aside for a second. It's probably a more correct analogy (although still not completely accurate) to say that a /64 is equivalent to an IPv4 /24, or some other small network that would be utilized by an end user with the expectation that there are multiple devices running in it. I agree with you that you'd never want to route that /64, but you (generally) wouldn't want to route a /24, or more accurately something like a /28, either. Also, as Owen pointed out, the original concept for IPv6 networking was a 64 bit address space all along. The "extra" (or some would say, "wasted") 64 bits were tacked on later. > Still oodles of addresses, but worth > noting and is probably one reason why some of the "conservationists" > react the way they do. It's easy to look at the mandatory /64 limit and say "See, the address space is cut in half to start with!" but it's not accurate. Depending on who's using it a single /64 could have thousands of devices, up to the limit of the broadcast domain on the network gear. At minimum even for a home user you're going to get "several" devices. > Next, let's look at the wildest dreams aspect. The current > "implementation" I'm thinking of in modern pop culture is Big Hero 6 > (the movie, not the comics as I've never read them). Specifically, > Hiro's "microbots". Each one needs an address to be able to communicate > with the controller device. Even with the numbers of them, can probably > be handled with a /64, but you'd also probably want them in separate > "buckets" if you're doing separated tasks. Even so, a /48 could EASILY > handle it. Right, 65k /64s in a /48. > Now make them the size of a large-ish molecule. Or atom. Or protons. > Nanotech or femtotech that's advanced enough gets into Clarke's Law - > any sufficiently advanced technology is indistinguishable from magic - > but in order to do that they need to communicate. If you think that > won't be possible in the next 30 years, you probably haven't been paying > attention. I do see that as a possibility, however in this world that you're positing, how many of those molecules need to talk to the big-I Internet? Certainly they need to communicate internally, but do they need routable space? Also, stay tuned for some math homework. :) > I wrote my email as a way of pointing out that maybe the concerns (on > both sides)- aren't baseless, Please note that I try very hard not to dismiss anyone's concerns as baseless, whether I agree with them or not. As I mentioned in my previous message, I believe I have a pretty good understanding of how the "IPv6 conservationists" think. My concern however is that while their concerns have a basis, their premise is wrong. > but at the same time maybe there's a way > to split the difference. It's not too much of a stretch to see that, > soon, 256 subnets may not actually be enough to deal with the connected > world and "Internet of Things" that's currently being developed. But > would 1024? How about 4096? Is there any need in the next 10-15 years > for EVERYONE to be getting handed 65,536 /64 subnets? So, here's where the math gets to be both fun, and mind-boggling. :) There are 32 /8s in 2000::/3. Let's assume for sake of argument that we've "wasted" two whole /8s with various drama. There are 2 to the 40th power /48s in a /8, multiply by 30, and divide by 10 billion (to represent a fairly future-proof number of people on the planet). That's 3,298.5 /48s per person. So you asked an interesting question about whether or not we NEED to give everyone a /48. Based on the math, I think the more interesting question is, what reason is there NOT to give everyone a /48? You want to future proof it to 20 billion people? Ok, that's 1,600+ /48s per person. You want to future proof it more to 25% sparse allocation? Ok, that's 400+ /48s per person (at 20 billion people). At those levels even if you gave every person's every device a /48, we're still not going to run out, in the first 1/8 of the available space. > Split the difference, go with a /52 That's not splitting the difference. :) A /56 is half way between a /48 and a /64. That's 256 /64s, for those keeping score at home. So the advice I've been giving out for quite a while now, which has been both well received and implemented with success, is for ISPs who want to practice conservation to *reserve* a /48 for every home user, and to *allocate* the first /56 from it. To some extent I agree with Owen that the world would be a better place if everyone just gave out /48s. But I'm also pragmatic, and I'd rather see IPv6 deployed sooner rather than later. I think that 256 networks should be enough for even the most complex home networks (including multiple layers of routers, etc.) and it's incumbent on the software authors to slice up what they are handed, rather than making assumptions. Meanwhile, if the ISP "blows through" their end-user pool at /48 reservations, they can go to their RIR and get more space. And if cosmic rays befuddle the minds of every RIR on the planet and somehow that doesn't become possible, they can go back through their /48 reservations and start allocating the first /56 from the bottom /49 to new customers. Lather, rinse, repeat. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From joelja at bogus.com Wed Jul 15 18:30:49 2015 From: joelja at bogus.com (joel jaeggli) Date: Wed, 15 Jul 2015 11:30:49 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6974D.2010102@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> Message-ID: <55A6A6D9.4080501@bogus.com> On 7/15/15 10:24 AM, Joe Maimon wrote: > > > Mark Andrews wrote: >> In message >> > >> We don't use Class E because were using up IPv4 space too quickly >> to make it worthwhile to make it work cleanly for everyone. > > That is a self fulfilling prophecy. > > I suspect a 16 /8 right about now would be very welcome for everybody > other then the ipv6 adherents. > > Seems like procrastination is only bad when its your baby. > > The jury is still out on class E, but the verdict is in for the > community who created it. joel at ubuntu:~$ uname -a Linux ubuntu 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux joel at ubuntu:~$ sudo ifconfig eth0:0 240.0.0.1/24 SIOCSIFADDR: Invalid argument SIOCSIFFLAGS: Cannot assign requested address SIOCSIFNETMASK: Cannot assign requested address now go test that on every exisitng ipv4 device on the planet that's not getting an upgrade. it doesn't extend the life of ipv4 usefully and it wouldn't have if we started 10 years ago either. the goal in stringing along ipv4 is to not hose your current or potential customers rather than prevent still more obstacles to their success. joel > Joe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.us Wed Jul 15 18:31:48 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 15 Jul 2015 11:31:48 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6974D.2010102@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> Message-ID: <55A6A714.2020903@dougbarton.us> On 7/15/15 10:24 AM, Joe Maimon wrote: > I suspect a 16 /8 right about now would be very welcome for everybody > other then the ipv6 adherents. Globally we were burning through about a /8 every month or two in "the good old days." So in the best case scenario we'd get 32 more months of easy to get IPv4, but at an overwhelming cost to re-implement every network stack. This option was considered back in the early 2000's when I was still involved in the discussion, and rejected as impractical. -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From drc at virtualized.org Wed Jul 15 18:32:00 2015 From: drc at virtualized.org (David Conrad) Date: Wed, 15 Jul 2015 11:32:00 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <1436932411.17261.38.camel@karl> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.camel@karl> Message-ID: <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> Hi, On Jul 14, 2015, at 8:53 PM, Karl Auer wrote: > Space was handed out more or less willy-nilly - so some US > organisations ended up with multiple A-classes each, while later on all > of Vietnam got one /26. IIRC (I was running APNIC at the time), when the first organization from Vietnam approached APNIC for address space, we allocated a /22 to them and reserved the /16 from which that allocation was made for other ISPs in Vietnam (as was the policy back then). > That's the big difference - IPv6 has been designed to provide abundant > address space. There is no amount of fixed address space that can't be consumed with stupid allocation policies. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johnl at iecc.com Wed Jul 15 18:33:16 2015 From: johnl at iecc.com (John Levine) Date: 15 Jul 2015 18:33:16 -0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6974D.2010102@ttec.com> Message-ID: <20150715183316.26843.qmail@ary.lan> >I suspect a 16 /8 right about now would be very welcome for everybody >other then the ipv6 adherents. It would, if the software supported it. But it doesn't. Is there any reason to think the world would update its TCP stacks to handle those extra IPv4 addresses any sooner than it'd update its stacks to handle IPv6? Doesn't seem likely. R's, John From owen at delong.com Wed Jul 15 19:05:15 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 12:05:15 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6974D.2010102@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> Message-ID: <7EE3204D-3FC6-469E-911C-7AF7E641BDD7@delong.com> > On Jul 15, 2015, at 10:24 , Joe Maimon wrote: > > > > Mark Andrews wrote: >> In message > >> We don't use Class E because were using up IPv4 space too quickly >> to make it worthwhile to make it work cleanly for everyone. > > That is a self fulfilling prophecy. > > I suspect a 16 /8 right about now would be very welcome for everybody other then the ipv6 adherents. But it wouldn?t be right now. It would be after everyone put lots of effort into updating lots of systems so that they could support those 16 /8s. By the time you?ve done that, you might as well have focused that effort on making those same systems do IPv6. > Seems like procrastination is only bad when its your baby. Not really? This isn?t a question of procrastination or not. It?s a question of given that roughly the same effort is required to do thing A or thing B and thing A (class E) leads nowhere in the long run while thing B provides a permanent solution, it makes much more sense to focus said effort on thing B than to postpone thing B in favor of thing A. > The jury is still out on class E, but the verdict is in for the community who created it. Not really. I think if you really consider what would be required for deployment of class E, you?ll find that there truly is no there there. Owen From owen at delong.com Wed Jul 15 19:20:08 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 12:20:08 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.! camel@karl> <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> Message-ID: > On Jul 15, 2015, at 11:32 , David Conrad wrote: > > Hi, > > On Jul 14, 2015, at 8:53 PM, Karl Auer wrote: >> Space was handed out more or less willy-nilly - so some US >> organisations ended up with multiple A-classes each, while later on all >> of Vietnam got one /26. > > IIRC (I was running APNIC at the time), when the first organization from Vietnam approached APNIC for address space, we allocated a /22 to them and reserved the /16 from which that allocation was made for other ISPs in Vietnam (as was the policy back then). > >> That's the big difference - IPv6 has been designed to provide abundant >> address space. > > There is no amount of fixed address space that can't be consumed with stupid allocation policies. > True. However, are you making the argument that any of the current or proposed allocation policies are, in fact, stupid in such a way that this is likely? If so, which ones? If not, then how is that relevant to the current discussion of what to do in terms of deployment given existing policies? Owen From george.metz at gmail.com Wed Jul 15 19:43:14 2015 From: george.metz at gmail.com (George Metz) Date: Wed, 15 Jul 2015 15:43:14 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6A239.2080304@dougbarton.us> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dougbarton.us> <55A6A239.2080304@dougbarton.us> Message-ID: On Wed, Jul 15, 2015 at 2:11 PM, Doug Barton wrote: > On 7/15/15 8:20 AM, George Metz wrote: > >> >> Snip! > Also, as Owen pointed out, the original concept for IPv6 networking was a > 64 bit address space all along. The "extra" (or some would say, "wasted") > 64 bits were tacked on later. > > Still oodles of addresses, but worth >> noting and is probably one reason why some of the "conservationists" >> react the way they do. >> > > It's easy to look at the mandatory /64 limit and say "See, the address > space is cut in half to start with!" but it's not accurate. Depending on > who's using it a single /64 could have thousands of devices, up to the > limit of the broadcast domain on the network gear. At minimum even for a > home user you're going to get "several" devices. Allow me to rephrase: "A single /32 could have thousands of devices, up to the limit of a 10/8 NATted behind it". This, plus the fact that it WAS originally 64-bit and was expanded to include RA/SLAAC, is why I chose that analogy. > Next, let's look at the wildest dreams aspect. The current >> "implementation" I'm thinking of in modern pop culture is Big Hero 6 >> (the movie, not the comics as I've never read them). Specifically, >> Hiro's "microbots". Each one needs an address to be able to communicate >> with the controller device. Even with the numbers of them, can probably >> be handled with a /64, but you'd also probably want them in separate >> "buckets" if you're doing separated tasks. Even so, a /48 could EASILY >> handle it. >> > > Right, 65k /64s in a /48. > > Now make them the size of a large-ish molecule. Or atom. Or protons. >> Nanotech or femtotech that's advanced enough gets into Clarke's Law - >> any sufficiently advanced technology is indistinguishable from magic - >> but in order to do that they need to communicate. If you think that >> won't be possible in the next 30 years, you probably haven't been paying >> attention. >> > > I do see that as a possibility, however in this world that you're > positing, how many of those molecules need to talk to the big-I Internet? > Certainly they need to communicate internally, but do they need routable > space? Also, stay tuned for some math homework. :) So, you're advising that all these trillions of nanites should, what, use NAT? Unroutable IP space of another kind? Why would we do that when we've already got virtually unlimited v6 address space? See what I mean? Personally I'd suspect something involving quantum states would be more likely for information passage, but who knows what the end result is? > I wrote my email as a way of pointing out that maybe the concerns (on >> both sides)- aren't baseless, >> > > Please note that I try very hard not to dismiss anyone's concerns as > baseless, whether I agree with them or not. As I mentioned in my previous > message, I believe I have a pretty good understanding of how the "IPv6 > conservationists" think. My concern however is that while their concerns > have a basis, their premise is wrong. I wasn't intending yourself as the recipient keep in mind. However, IS their premise wrong? Is prudence looking at incomprehensible numbers and saying "we're so unlikely to run out that it just doesn't matter" or is prudence "Well, we have no idea what's coming, so let's be a little less wild-haired in the early periods"? The theory being it's a lot harder to take away that /48 30 years from now than it is to just assign the rest of it to go along with the /56 (or /52 or whatever) if it turns out they're needed. I personally like your idea of reserving the /48 and issuing the /56. > So you asked an interesting question about whether or not we NEED to give > everyone a /48. Based on the math, I think the more interesting question > is, what reason is there NOT to give everyone a /48? You want to future > proof it to 20 billion people? Ok, that's 1,600+ /48s per person. You want > to future proof it more to 25% sparse allocation? Ok, that's 400+ /48s per > person (at 20 billion people). > > At those levels even if you gave every person's every device a /48, we're > still not going to run out, in the first 1/8 of the available space. > > Split the difference, go with a /52 >> > > That's not splitting the difference. :) A /56 is half way between a /48 > and a /64. That's 256 /64s, for those keeping score at home. > It's splitting the difference between a /56 and a /48. I can't imagine short of the Nanotech Revolution that anyone really needs eight thousand separate networks, and even then... Besides, I recall someone at some point being grumpy about oddly numbered masks, and a /51 is probably going to trip that. :) I think folks are missing the point in part of the conservationists, and all the math in the world isn't going to change that. While the... let's call them IPv6 Libertines... are arguing that there's no mathematically foreseeable way we're going to run out of addresses even at /48s for the proverbial soda cans, the conservationists are going, "Yes, you do math wonderfully. Meantime is it REALLY causing anguish for someone to only get 256 (or 1024, or 4096) networks as opposed to 65,536 of them? If not, why not go with the smaller one? It bulletproofs us against the unforeseen to an extent." As an aside, someone else has stated that for one reason or another IPv6 is unlikely to last more than a couple of decades, and so even if something crazy happened to deplete it, the replacement would be in place anyhow before it could. I would like to ask what about the last 20 years of IPv6 adoption in the face of v4 exhaustion inspires someone to believe that just because it's better that people will be willing to make the change over? From owen at delong.com Wed Jul 15 20:06:37 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 13:06:37 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dougbarton.us> <55A6A239.2080304@dougbarton.us> Message-ID: <5544B946-0DBD-489A-BECF-C92CDB779674@delong.com> > > I wasn't intending yourself as the recipient keep in mind. However, IS > their premise wrong? Is prudence looking at incomprehensible numbers and > saying "we're so unlikely to run out that it just doesn't matter" or is > prudence "Well, we have no idea what's coming, so let's be a little less > wild-haired in the early periods"? The theory being it's a lot harder to > take away that /48 30 years from now than it is to just assign the rest of > it to go along with the /56 (or /52 or whatever) if it turns out they're > needed. I personally like your idea of reserving the /48 and issuing the > /56. Yes? Their premise is wrong. We?re not talking about /48s for soda cans. We?re talking about /48s for end-sites? Households, individual business buildings, etc. The soda can is probably just one host on a /64 somewhere within that /48. Every six-pack in your house probably fits in the same /64. > > >> So you asked an interesting question about whether or not we NEED to give >> everyone a /48. Based on the math, I think the more interesting question >> is, what reason is there NOT to give everyone a /48? You want to future >> proof it to 20 billion people? Ok, that's 1,600+ /48s per person. You want >> to future proof it more to 25% sparse allocation? Ok, that's 400+ /48s per >> person (at 20 billion people). >> >> At those levels even if you gave every person's every device a /48, we're >> still not going to run out, in the first 1/8 of the available space. >> >> Split the difference, go with a /52 >>> >> >> That's not splitting the difference. :) A /56 is half way between a /48 >> and a /64. That's 256 /64s, for those keeping score at home. >> > > It's splitting the difference between a /56 and a /48. I can't imagine > short of the Nanotech Revolution that anyone really needs eight thousand > separate networks, and even then... Besides, I recall someone at some point > being grumpy about oddly numbered masks, and a /51 is probably going to > trip that. :) It?s not about the number of networks. It?s about the number of bits available to provide flexibility in automating topology to create pluggable network components that just work. We?ve only begun to explore the new capabilities of DHCPv6-PD within a site. Clamping down the size of a ?site? to less than the original design-criteria considered when DHCPv6-PD was developed will, in fact, stifle innovation in this area most likely. > I think folks are missing the point in part of the conservationists, and > all the math in the world isn't going to change that. While the... let's > call them IPv6 Libertines... are arguing that there's no mathematically > foreseeable way we're going to run out of addresses even at /48s for the > proverbial soda cans, the conservationists are going, "Yes, you do math > wonderfully. Meantime is it REALLY causing anguish for someone to only get > 256 (or 1024, or 4096) networks as opposed to 65,536 of them? If not, why > not go with the smaller one? It bulletproofs us against the unforeseen to > an extent.? The problem is that the conservationists are arguing against /48s for soda cans while the libertines are not arguing for that. /48 protects against the unforeseen pretty well. Even if it doesn?t, that?s why we also have the /3 safeguard. If we turn out to have gotten it wrong? If it turns out that we use up all of the first /3 before we run out of useful life in the protocol, then I?m all for coming up with different policy for the remaining /3s. Even if you want to argue that we have to keep handing out addresses while we develop that policy, I?ll say you can hand out the second /3 in the same way while we develop the more restrictive policy for the remaining 74.9999999999% of the total address space. Short of something incredibly surprising, we?re not going to exhaust that first /3 in less than 50 years even if we give many /48s to every end site on the planet. In case of something really surprising, it would be even more surprising if we found a way to make IPv6 scale to that on many levels other than address space: 1. IPv6 developers punted on the routing problem and insisted that aggregation was the desired alternative to solving the routing problem. In reality, I think this will most likely be the first scaling limit we see in IPv6, but I could be wrong. Aggregation is somewhere between inconvenient and infeasible as we have seen with IPv4 where we managed to get some small gains when aggregation was first introduced and we took the routing table from ~65,000 entries to ~45,000. Look where it is now. More than 500,000 entries and continuing to grow. More multihoming and more individual PI prefixes are going to become the norm, not less. 2. IP is a relatively high overhead protocol. Putting an IPv6 stack into a molecule-sized device is, in fact, unlikely because of the limits of storage for software in a molecule-sized device. Nanobots ala Big Hero-6, sure? Do you really think they needed more than a /48 to address every nanobot on the screen throughout the entire movie? I bet you could probably give a unique address to every nanobot in every frame of the movie and still not burn through a /48. So of the 400 /48s we can give each person on earth, let?s dedicate 100 of them to running their nanobots. We?ve still got 300 /48s available, of which 1 will run the rest of their household and we have 299 in reserve. Yes, their premise is wrong. They are optimizing for the wrong thing. > As an aside, someone else has stated that for one reason or another IPv6 is > unlikely to last more than a couple of decades, and so even if something > crazy happened to deplete it, the replacement would be in place anyhow > before it could. I would like to ask what about the last 20 years of IPv6 > adoption in the face of v4 exhaustion inspires someone to believe that just > because it's better that people will be willing to make the change over? I try to avoid ?20 years?, but instead say ?50 years?. The reality is that in any wildest projection of current policies and crazy scientific development, the first /3 lasts more than 100 years. If you don?t think IPv4 is past its useful lifetime, you aren?t paying attention. However, even assuming that IPv4 (RFC791, September, 1981) lasts another 10 years, that would be a total protocol life time of (2025-1981 =) 44 years. Yes, there will still be islands of IPv4 utilization floating around well past that time just as there are still islands of NCP today. Oh, wait? Just as there are islands of IPX today. However, nobody will route IPv4 natively on the global internet 10 years from now. It will have gone the way of latin. Scholars will remember it, but it will not have much in the way of day-to-day utilization except in specialized circumstances. I don?t think people will make the change just because it?s better. I think just as is the case now, somewhere within the next 50 years, people will move away from IPv6 because we hit some other limitation baked into the protocol and we had to move on. As long as we have enough addresses to make sure that address shortage is not the cause of protocol end-of-life, any additional conservatism is, in fact, just waste. If it has negative impact on development, then it is even worse than waste, it is actually harmful. Owen From dougb at dougbarton.us Wed Jul 15 20:19:27 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 15 Jul 2015 13:19:27 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dougbarton.us> <55A6A239.2080304@dougbarton.us> Message-ID: <55A6C04F.5060807@dougbarton.us> On 7/15/15 12:43 PM, George Metz wrote: > > > On Wed, Jul 15, 2015 at 2:11 PM, Doug Barton > wrote: > > On 7/15/15 8:20 AM, George Metz wrote: > > > > Snip! > > Also, as Owen pointed out, the original concept for IPv6 networking > was a 64 bit address space all along. The "extra" (or some would > say, "wasted") 64 bits were tacked on later. > > Still oodles of addresses, but worth > noting and is probably one reason why some of the "conservationists" > react the way they do. > > > It's easy to look at the mandatory /64 limit and say "See, the > address space is cut in half to start with!" but it's not accurate. > Depending on who's using it a single /64 could have thousands of > devices, up to the limit of the broadcast domain on the network > gear. At minimum even for a home user you're going to get "several" > devices. > > Allow me to rephrase: "A single /32 could have thousands of devices, up > to the limit of a 10/8 NATted behind it". This, plus the fact that it > WAS originally 64-bit and was expanded to include RA/SLAAC, is why I > chose that analogy. Sure, so in that context it's a valid analogy, but my point still stands. We're not talking about routable/PI space for customers, even at the /48 level. Now it is true that the CW seems to be leaning towards /48 being the largest routable prefix *for commercial networks*, but that's orthogonal to the issue of home users. > I do see that as a possibility, however in this world that you're > positing, how many of those molecules need to talk to the big-I > Internet? Certainly they need to communicate internally, but do they > need routable space? Also, stay tuned for some math homework. :) > > > So, you're advising that all these trillions of nanites should, what, > use NAT? Unroutable IP space of another kind? Why would we do that when > we've already got virtually unlimited v6 address space? > > See what I mean? Personally I'd suspect something involving quantum > states would be more likely for information passage, but who knows what > the end result is? I very carefully tried to skirt the issue, since NAT is a hot-button topic for the most ardent of the IPv6 zealots. You were positing a world where we need addressing at a molecular level, my point is simply that in that world we may or may not be dealing with publicly routable space; but *more importantly*, even if we are, we're still covered. > I wrote my email as a way of pointing out that maybe the > concerns (on > both sides)- aren't baseless, > > > Please note that I try very hard not to dismiss anyone's concerns as > baseless, whether I agree with them or not. As I mentioned in my > previous message, I believe I have a pretty good understanding of > how the "IPv6 conservationists" think. My concern however is that > while their concerns have a basis, their premise is wrong. > > I wasn't intending yourself as the recipient keep in mind. However, IS > their premise wrong? Is prudence looking at incomprehensible numbers and > saying "we're so unlikely to run out that it just doesn't matter" Yeah, that's totally not what I'm saying, and I don't think even the most ardent IPv6 zealot is saying it either. What I'm saying is that there is a very solid, mathematical foundation on which to base the conclusion that ISPs handing out /48s to end users is a very reasonable thing to do. > or is > prudence "Well, we have no idea what's coming, so let's be a little less > wild-haired in the early periods"? The theory being it's a lot harder to > take away that /48 30 years from now than it is to just assign the rest > of it to go along with the /56 (or /52 or whatever) if it turns out > they're needed. I personally like your idea of reserving the /48 and > issuing the /56. Thanks. :) I do recognize that even with all of the math in the world we don't know what the world will look like in 20 years, so *some degree* of pragmatism is valuable, especially as we're ramping up deployment. But your argument that it'll be hard to take away the /48 is almost certainly wrong. This isn't like handling out "Class A's" and "Class B's" in the early days of IPv4, when we're talking home users we're talking about PA space, which can be withdrawn at will. Even at the RIR level, assuming some unimaginable future where 400+ /48s per human on the planet isn't enough, they can simply revise their policies to require justification at some other level per user than /48, thereby proclaiming that an ISP's existing space is "adequate" by administrative fiat. In that sense I actually believe that we've learned the lessons from the early days of IPv4, and that we've adequately accounted for them in the current set of policies. ... and not to flog the expired equine, but we're still only talking about 1/8 of the available space. I'm not being snarky when I say that we really are dealing with numbers that are so large that it's hard for the human mind to comprehend them. > That's not splitting the difference. :) A /56 is half way between a > /48 and a /64. That's 256 /64s, for those keeping score at home. > > > It's splitting the difference between a /56 and a /48. I can't imagine > short of the Nanotech Revolution that anyone really needs eight thousand > separate networks, and even then... Besides, I recall someone at some > point being grumpy about oddly numbered masks, and a /51 is probably > going to trip that. :) The issue is more nibble boundaries than odd-numbered masks. But my point wasn't really to say "/56 is the right answer," since it's not, /48 is. :) > I think folks are missing the point in part of the conservationists, and > all the math in the world isn't going to change that. While the... let's > call them IPv6 Libertines... are arguing that there's no mathematically > foreseeable way we're going to run out of addresses even at /48s for the > proverbial soda cans, the conservationists are going, "Yes, you do math > wonderfully. Meantime is it REALLY causing anguish for someone to only > get 256 (or 1024, or 4096) networks as opposed to 65,536 of them? If > not, why not go with the smaller one? It bulletproofs us against the > unforeseen to an extent." The short answer to your question is, "Yes." The longer answer is that we are only just starting down the road of what's going to be possible for home users with IPv6. There is already a desire to use multiple different subnets, and nested routers. My personal feeling is that 256 networks (a /56) is going to be enough for the foreseeable future, but the point Owen has made quite eloquently is that we don't want to hamstring these efforts from the outset with something ludicrously small. So it really isn't a matter of not understanding the conservationists, it's more a matter that the math really does work. But even given all that, I still advise to reserve the /48, and allocate the /56, then as the next couple of years go by it will become increasingly obvious what the right answer is, and no matter who was "right" we'll still have all the space we need. I'm glad that we seem to have reached agreement on that point at least. :) Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From Lee at asgard.org Wed Jul 15 20:20:11 2015 From: Lee at asgard.org (Lee Howard) Date: Wed, 15 Jul 2015 16:20:11 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: On 7/13/15, 3:43 PM, "NANOG on behalf of Ricky Beam" wrote: >On Sun, 12 Jul 2015 17:32:33 -0400, Ca By wrote: >> Yes, move your business to TWC. TWC has a proven v6 deployment and is >> actively engaged in the community, as where vz Fios is not. > >Yes, because TWC-BC's IPv6 support is stellar. Sorry, I misspelled >"non-existent". Business Class DOCSIS customers get a prefix automatically (unless you provide your own gateway and DHCPv6 isn?t enabled). Since it?s dynamic, it might change; working on providing stable prefixes. http://www.timewarnercable.com/en/support/internet/topics/ipv6.html > >Their "DIA" (metro-e) stuff, *might*, but I doubt it. > Does, but since it requires BGP or static route configuration, you have to ask. Lee From jfbeam at gmail.com Wed Jul 15 20:23:36 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 15 Jul 2015 16:23:36 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.! camel@karl> <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> Message-ID: On Wed, 15 Jul 2015 15:20:08 -0400, Owen DeLong wrote: >>> That's the big difference - IPv6 has been designed to provide abundant >>> address space. >> >> There is no amount of fixed address space that can't be consumed with >> stupid allocation policies. > > True. However, are you making the argument that any of the current or > proposed allocation policies are, in fact, stupid in such a way that > this is likely? What seems like a great idea today becomes tomorrow's "what the f*** were they thinking". From alh-ietf at tndh.net Wed Jul 15 20:34:34 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 15 Jul 2015 13:34:34 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dougbarton.us> <55A6A239.2080304@dougbarton.us> Message-ID: <03cb01d0bf3d$a90016d0$fb004470$@tndh.net> George Metz wrote: > > snip > > Split the difference, go with a /52 > >> > > > > That's not splitting the difference. :) A /56 is half way between a > > /48 and a /64. That's 256 /64s, for those keeping score at home. > > > > It's splitting the difference between a /56 and a /48. I can't imagine short of > the Nanotech Revolution that anyone really needs eight thousand separate > networks, and even then... Besides, I recall someone at some point being > grumpy about oddly numbered masks, and a /51 is probably going to trip > that. :) > > I think folks are missing the point in part of the conservationists, and all the > math in the world isn't going to change that. While the... let's call them IPv6 > Libertines... are arguing that there's no mathematically foreseeable way > we're going to run out of addresses even at /48s for the proverbial soda > cans, the conservationists are going, "Yes, you do math wonderfully. > Meantime is it REALLY causing anguish for someone to only get > 256 (or 1024, or 4096) networks as opposed to 65,536 of them? If not, why > not go with the smaller one? It bulletproofs us against the unforeseen to an > extent." You are looking at this from the perspective of a network manager, and not considering the implications of implementing plug-n-play for consumers. A network manager can construct a very efficient topology with a small number of bits, but automation has to make "gross waste" trade-offs to "just work" when a consumer plugs things together without understanding the technology constraints. Essentially the conservationist argument is demanding waste, because the unallocated prefixes will still be sitting on the shelf in 400 years. It would be better to allocate them now and allow innovation at the cpe level, rather than make it too costly for cpe vendors to work around all the random allocation sizes in addition to the random ways people plug the devices together. > > As an aside, someone else has stated that for one reason or another IPv6 is > unlikely to last more than a couple of decades, and so even if something > crazy happened to deplete it, the replacement would be in place anyhow > before it could. I would like to ask what about the last 20 years of IPv6 > adoption in the face of v4 exhaustion inspires someone to believe that just > because it's better that people will be willing to make the change over? TDM voice providers had 100 years of history on their side, but voip won, because cheaper always wins. From jfbeam at gmail.com Wed Jul 15 20:43:38 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 15 Jul 2015 16:43:38 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: On Wed, 15 Jul 2015 16:20:11 -0400, Lee Howard wrote: > Business Class DOCSIS customers get a prefix automatically (unless you > provide your own gateway and DHCPv6 isn?t enabled). I looked last night at the office in Cary, NC. NO RAs are seen on the link coming from the Ubee (bridged) providing our dynamic/DOCSIS connection. Without an RA, nothing will attempt IPv6. (I've not checked the one in Raleigh that's also a hotspot) Residential? sure, there's lot of v6 there -- has been for over a year. But as I'm an Earthlink customer, and those morons cannot be bothered to give TWC one of their *5* UNUSED /32's, all I get is: (IA_PD IAID:327681 T1:0 T2:0 (status code no prefixes)) --Ricky From Valdis.Kletnieks at vt.edu Wed Jul 15 20:48:10 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 15 Jul 2015 16:48:10 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Wed, 15 Jul 2015 16:23:36 -0400." References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.! ! camel@karl> <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> Message-ID: <27212.1436993290@turing-police.cc.vt.edu> On Wed, 15 Jul 2015 16:23:36 -0400, "Ricky Beam" said: > What seems like a great idea today becomes tomorrow's "what the f*** were > they thinking". However, this statement doesn't provide any actual guidance, as it's potentially equally applicable to the "give each end customer a /48" crew and the "Give them all a /56" crew..... Actually, not true - in fact, it's demonstrable that a residential customer can run through a /56. Just get a largish house, put up one router using CeroWRT (or, I suspect a current/recent OpenWRT) that burns through 6-7 subnet allocations), and then put a second one at the other end of the house and it burns through 6-7. The second one has to dhcp-pd request at least 3 bits for itself, which leaves the first one only 5 bits, of which *it* will burn at least 3. If you create any VLANs at all, you just burned 4 and 4 bits, and there goes that /56. And that's burned all the subnets in a /56 *just hooking up 2 plug and play routers*. There's none left for doing anything experimental/different. (And I suspect Dave Taht can provide several CeroWRT config checkboxes that will each burn another 1-3 bits each if you click on them and hit "apply" :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From bzs at world.std.com Wed Jul 15 20:55:31 2015 From: bzs at world.std.com (Barry Shein) Date: Wed, 15 Jul 2015 16:55:31 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dou! gbarton.us> Message-ID: <21926.51395.248847.677579@world.std.com> On July 15, 2015 at 09:20 owen at delong.com (Owen DeLong) wrote: > > There are two ways to waste addresses. One is to allocate them to users who > don,Ab??(Bt actually use all of them. > > The other is to keep them on the shelf in the free pool until well past the useful > life of the protocol. I'd add a third which is segmentation and I think that's a real threat. That is, assigning large chunks to specific functions by policy usually in support of technical needs. For example IPv4's multicast block. Poof, 224/4 gone. Or similar. Suddenly it's not 2^N bits it's just N bits. My claim is that such segmentation tends to grow over time as people find good arguments to segment. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From dougb at dougbarton.us Wed Jul 15 21:02:12 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 15 Jul 2015 14:02:12 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <27212.1436993290@turing-police.cc.vt.edu> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.! ! camel@karl> <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> <27212.1436993290@turing-police.cc.vt.edu> Message-ID: <55A6CA54.7000103@dougbarton.us> On 7/15/15 1:48 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 15 Jul 2015 16:23:36 -0400, "Ricky Beam" said: > >> What seems like a great idea today becomes tomorrow's "what the f*** were >> they thinking". > > However, this statement doesn't provide any actual guidance, as it's > potentially equally applicable to the "give each end customer a /48" crew and > the "Give them all a /56" crew..... > > Actually, not true - in fact, it's demonstrable that a residential customer > can run through a /56. Just get a largish house, put up one router using > CeroWRT (or, I suspect a current/recent OpenWRT) that burns through 6-7 subnet > allocations), and then put a second one at the other end of the house and > it burns through 6-7. The second one has to dhcp-pd request at least 3 bits > for itself, which leaves the first one only 5 bits, of which *it* will burn > at least 3. If you create any VLANs at all, you just burned 4 and 4 bits, > and there goes that /56. > > And that's burned all the subnets in a /56 *just hooking up 2 plug and play > routers*. There's none left for doing anything experimental/different. > > (And I suspect Dave Taht can provide several CeroWRT config checkboxes that > will each burn another 1-3 bits each if you click on them and hit "apply" :) I tend to think that you're correct here, Validis; which is why I suggest reserving the /48 per customer whatever they decide to assign. I think the problem of expanding the assignment to a more reasonable size will happen on its own since at some point the support calls for "hey, I need more space!" will become a burden. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From owen at delong.com Wed Jul 15 21:23:52 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 14:23:52 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.! ! camel@karl> <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> Message-ID: > On Jul 15, 2015, at 13:23 , Ricky Beam wrote: > > On Wed, 15 Jul 2015 15:20:08 -0400, Owen DeLong wrote: >>>> That's the big difference - IPv6 has been designed to provide abundant >>>> address space. >>> >>> There is no amount of fixed address space that can't be consumed with stupid allocation policies. >> >> True. However, are you making the argument that any of the current or proposed allocation policies are, in fact, stupid in such a way that this is likely? > > What seems like a great idea today becomes tomorrow's "what the f*** were they thinking". But I can already say ?what the F*** were they thinking about /60. I can kind of see it being valid on /56. I have a harder time arguing about /52s, but once you go that far is there any meaningful difference that makes it worth the trouble not going to /48? Besides, if /48s don?t become tomorrows what the f*** were they thinking, then it will be something else. I will point out that nobody has said ?what the F*** were they thinking? when they made it possible to use 4GB of RAM instead of just 640k, but lots of people have said ?what the F*** were they thinking when they limited it to 640k.? Owen From owen at delong.com Wed Jul 15 21:34:13 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 14:34:13 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <21926.51395.248847.677579@world.std.com> References: <817684569.327.1436447535397.JavaMail.mhammett@ThunderFuck> <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dou! ! gbarton.us> <21926.51395.248847.677579@world.std.com> Message-ID: <356637FD-272E-4092-9BA9-73FA52740B4C@delong.com> > On Jul 15, 2015, at 13:55 , Barry Shein wrote: > > > On July 15, 2015 at 09:20 owen at delong.com (Owen DeLong) wrote: >> >> There are two ways to waste addresses. One is to allocate them to users who >> don,Ab??t actually use all of them. >> >> The other is to keep them on the shelf in the free pool until well past the useful >> life of the protocol. > > I'd add a third which is segmentation and I think that's a real > threat. That is, assigning large chunks to specific functions by > policy usually in support of technical needs. For example IPv4's > multicast block. Poof, 224/4 gone. Or similar. > > Suddenly it's not 2^N bits it's just N bits. > > My claim is that such segmentation tends to grow over time as people > find good arguments to segment. > fd00::/8 is already wasted on ULA. fe80::/10 (effectively fe00::/8) is already allocated (somewhat wastefully, as a /64 probably would do the trick) to link local ff00::/8 is already allocated to multicast. That covers multicast and RFC-1918. Are there any other IPv4 segmentations that you can think of? I?m not being snarky? I?m genuinely interested. Given that we came up with 3 total segmentations in IPv4 over the course of 30 years of IPv4 protocol use, which consumed a total of /4(multicast)+/8+/12+/16(RFC-1918)+/16(link local) of IPv4 and 3 /8s of IPv6. Even if we toss 5 more /8s to segmentation over the next 30 years, I think we?re OK, though we would have burned through a /5 at that point in segmentation. I think effectively, we can consider that e000::/3 is essentially set aside for such purposes and we still have 5/8ths of the address space after burning through the current /3 of unicast and a second /3 of unicast while we contemplate a more restrictive policy. Owen > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jfbeam at gmail.com Wed Jul 15 21:43:38 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 15 Jul 2015 17:43:38 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.! ! camel@karl> <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> Message-ID: On Wed, 15 Jul 2015 17:23:52 -0400, Owen DeLong wrote: > I will point out that nobody has said ?what the F*** were they thinking? > when they made it possible to use 4GB of RAM instead of just 640k, but > lots of people have said ?what the F*** were they thinking when they > limited it to 640k.? Actually, they did. And "PAE" was invented. (or "re-invented", as various paging mechanisms had existed for many decades by then) From jfbeam at gmail.com Wed Jul 15 21:53:38 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 15 Jul 2015 17:53:38 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <356637FD-272E-4092-9BA9-73FA52740B4C@delong.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dou! ! gbarton.us> <21926.51395.248847.677579@world.std.com> <356637FD-272E-4092-9BA9-73FA52740B4C@delong.com> Message-ID: On Wed, 15 Jul 2015 17:34:13 -0400, Owen DeLong wrote: > That covers multicast and RFC-1918. Are there any other IPv4 > segmentations that you can think of? ... > Given that we came up with 3 total segmentations in IPv4 over the course #1-3,#4 RFC-1918 is 3 "segments" and we recently added a 4th (for CGN). #5 Localhost (127/8) #6 Multicast (224/4) #7 "Class E" (240/4) #8 0/8 #9 255/8 (technically, part of class e, but it's called out specifically in various RFCs) From khuon at NEEBU.Net Wed Jul 15 22:29:50 2015 From: khuon at NEEBU.Net (Jake Khuon) Date: Wed, 15 Jul 2015 15:29:50 -0700 Subject: ATT wireless IPv6 In-Reply-To: References: Message-ID: <55A6DEDE.2090701@NEEBU.Net> On 15/07/15 04:54, Jared Mauch wrote: > Does anyone know what the story is here? They have some transparent proxies for IPv4 traffic and I was wondering if they were to be IPv6 enabled soon or if IPv6 will reach the handset. Hmmm... I'm seeing my rmnet1 interface on my Galaxy S5 as having an address out of the 2600:380:46ae::/38 space which is allocated to AT&T Mobility. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Wed Jul 15 22:33:54 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 15 Jul 2015 18:33:54 -0400 Subject: ATT wireless IPv6 In-Reply-To: <55A6DEDE.2090701@NEEBU.Net> References: <55A6DEDE.2090701@NEEBU.Net> Message-ID: <3627BB47-6B49-4F42-9165-45FA19D7EFD3@puck.nether.net> > On Jul 15, 2015, at 6:29 PM, Jake Khuon wrote: > > On 15/07/15 04:54, Jared Mauch wrote: >> Does anyone know what the story is here? They have some transparent proxies for IPv4 traffic and I was wondering if they were to be IPv6 enabled soon or if IPv6 will reach the handset. > > Hmmm... I'm seeing my rmnet1 interface on my Galaxy S5 as having an > address out of the 2600:380:46ae::/38 space which is allocated to AT&T > Mobility. I exchanged a few emails earlier today with someone and it seems to depend on your APN. If you have the VoLTE APN on your device you can get IPv6, including when tethering. The APN you want is nxtgenphone. If you have a device where you can not edit the APN settings (iPhone) you can not use the IPv6 enabled VoLTE APN. I suspect this will be enabled if they launch VoLTE on the iPhone. - Jared From jmaimon at ttec.com Wed Jul 15 23:35:07 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 15 Jul 2015 19:35:07 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6A6D9.4080501@bogus.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A6D9.4080501@bogus.com> Message-ID: <55A6EE2B.5040201@ttec.com> joel jaeggli wrote: > On 7/15/15 10:24 AM, Joe Maimon wrote: >> >> The jury is still out on class E, but the verdict is in for the >> community who created it. > > joel at ubuntu:~$ uname -a > Linux ubuntu 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 > 04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > joel at ubuntu:~$ sudo ifconfig eth0:0 240.0.0.1/24 > SIOCSIFADDR: Invalid argument > SIOCSIFFLAGS: Cannot assign requested address > SIOCSIFNETMASK: Cannot assign requested address > So your point is that those who claimed it would not help managed to make it so? Would it have really hurt to remove experimental status and replace it with use at your own risk status? Even now? > now go test that on every exisitng ipv4 device on the planet that's not > getting an upgrade. Thanks to (continuing) shortsightedness that course of action is still foreclosed. > > it doesn't extend the life of ipv4 usefully and it wouldn't have if we > started 10 years ago either. You dont know either of those. However, by continuing to insist on them, you make it so. > > the goal in stringing along ipv4 is to not hose your current or > potential customers rather than prevent still more obstacles to their > success. > > joel > At this point, you are running the risk of conflating your goals with your technical objections to the goals of others. And this has always been the real underlying issue. Joe From jmaimon at ttec.com Wed Jul 15 23:35:56 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 15 Jul 2015 19:35:56 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.! camel@karl> <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> Message-ID: <55A6EE5C.1020200@ttec.com> Ricky Beam wrote: > On Wed, 15 Jul 2015 15:20:08 -0400, Owen DeLong wrote: >>>> That's the big difference - IPv6 has been designed to provide abundant >>>> address space. >>> >>> There is no amount of fixed address space that can't be consumed with >>> stupid allocation policies. >> >> True. However, are you making the argument that any of the current or >> proposed allocation policies are, in fact, stupid in such a way that >> this is likely? > > What seems like a great idea today becomes tomorrow's "what the f*** > were they thinking". > > There will be ample evidence of what any and all of were saying. Thinking, maybe not. From jmaimon at ttec.com Wed Jul 15 23:45:55 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 15 Jul 2015 19:45:55 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6A714.2020903@dougbarton.us> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> Message-ID: <55A6F0B3.8010302@ttec.com> Doug Barton wrote: > On 7/15/15 10:24 AM, Joe Maimon wrote: >> I suspect a 16 /8 right about now would be very welcome for everybody >> other then the ipv6 adherents. > > Globally we were burning through about a /8 every month or two in "the > good old days." So in the best case scenario we'd get 32 more months of > easy to get IPv4, but at an overwhelming cost to re-implement every > network stack. > > This option was considered back in the early 2000's when I was still > involved in the discussion, and rejected as impractical. > Removing experimental status does not equate with the burden of making it equivalent use to the rest of the address space. How about the ARIN burn rate post IANA runout? How long does 16 /8 last then? What would be wrong with removing experimental status and allowing one of the /8 to be used for low barrier to /16 assignment to any party demonstrating a willingness to coax usability of the space? Yes, any such effort has to run the gauntlet of IETF/IANA/RIR policy. CGN /10 managed. This could too, if all the naysayers would just step out of the way. From jmaimon at ttec.com Wed Jul 15 23:54:37 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 15 Jul 2015 19:54:37 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150715183316.26843.qmail@ary.lan> References: <20150715183316.26843.qmail@ary.lan> Message-ID: <55A6F2BD.5010105@ttec.com> John Levine wrote: >> I suspect a 16 /8 right about now would be very welcome for everybody >> other then the ipv6 adherents. > > It would, if the software supported it. But it doesn't. > > Is there any reason to think the world would update its TCP stacks to > handle those extra IPv4 addresses any sooner than it'd update its > stacks to handle IPv6? Doesn't seem likely. > > R's, > John > > Are you really equating an incremental silent update to remove something between one if statement or slightly more and an entire protocol stack that when active fundamentally changes the host networking behavior? This objection hinges on the assumption that if there is even ONE host on the network that will not accept that address, then the entire effort was a waste. Because there would then be no difference to the many many IPv4 (and IPv6) updates that were made with no guarantee of universal adoption. Its not really standards place to make that judgement call. Worse, it is not the standards role to ensure the outcome by making that judgement call. Joe From list at satchell.net Wed Jul 15 23:55:15 2015 From: list at satchell.net (Stephen Satchell) Date: Wed, 15 Jul 2015 16:55:15 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.! ! camel@karl> <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> Message-ID: <55A6F2E3.50603@satchell.net> On 07/15/2015 02:23 PM, Owen DeLong wrote: > I will point out that nobody has said ?what the F*** were they > thinking? when they made it possible to use 4GB of RAM instead of > just 640k, but lots of people have said ?what the F*** were they > thinking when they limited it to 640k.? That 640k was the architectural limit imposed on Intel 16-bit 8086 system implementations, once you allocated fixed space for ROM. This was specific to the "IBM PC". This has to do with the 20-bit addressing used in the 8086. One could "grow" the address space externally, and some computer systems (not "IBM PC compatible") did so. Again, the 4-GB RAM limits is an architectural limit of the hardware; there is no "speed-of-light" limit in the amount of DRAM one can have in a system. Let's review the bidding on Internet Protocol, shall we? APRANET NCP (1970) -- 8-bit host Version 0 -- can't figure out the limit, if any; 4-bit "chunks" Version 1 -- 16-bit net/host address Version 2 -- variable! in octet increments Version 3 -- (not available) Version 4-78jun -- variable! in octet increments Version 4-78sep -- 32 bit net/host address, Class A (8-bit net) Version 5 -- (experimental circuit-switch protocol) Version 6 -- 128-bit From marka at isc.org Wed Jul 15 23:58:18 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 16 Jul 2015 09:58:18 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Wed, 15 Jul 2015 19:35:07 -0400." <55A6EE2B.5040201@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A6D9.4080501@bogus.com> <55A6EE2B.5040201@ttec.com> Message-ID: <20150715235818.61D6A333300E@rock.dv.isc.org> In message <55A6EE2B.5040201 at ttec.com>, Joe Maimon writes: > joel jaeggli wrote: > > On 7/15/15 10:24 AM, Joe Maimon wrote: > >> > >> The jury is still out on class E, but the verdict is in for the > >> community who created it. > > > > joel at ubuntu:~$ uname -a > > Linux ubuntu 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 > > 04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > > > joel at ubuntu:~$ sudo ifconfig eth0:0 240.0.0.1/24 > > SIOCSIFADDR: Invalid argument > > SIOCSIFFLAGS: Cannot assign requested address > > SIOCSIFNETMASK: Cannot assign requested address > > > > So your point is that those who claimed it would not help managed to > make it so? No. The test was there before the requests which is why people were saying that it wouldn't work without upgrading lots of machines. > Would it have really hurt to remove experimental status and replace it > with use at your own risk status? Even now? No, but you couldn't assign the addresses to users for another decade or more without there being problems. We still haven't removed all the class based code out there and that is 20 years now. For quite a while one had to be careful to not use the first and last blocks when subnetting. The use of addresses ending in .0 (class C) or .0.0 (class B) is still problematic with supernets. > > now go test that on every exisitng ipv4 device on the planet that's not > > getting an upgrade. > > Thanks to (continuing) shortsightedness that course of action is still > foreclosed. > > > > > it doesn't extend the life of ipv4 usefully and it wouldn't have if we > > started 10 years ago either. > > You dont know either of those. > > However, by continuing to insist on them, you make it so. Do you think adding 2 more years would have done anything except let people procrastinate for 2 more years before starting to deploy IPv6? Vendors have had 15 years to develop products that support IPv6. That was more than enough time. We added IPv6 support to BIND back in the 1990's. DHCP has supported IPv6 just about as long. F was running on IPv6 years before the root servers officially supported IPv6. Just in time is nice if it works but it hasn't. We have people that are only contactable over IPv6 because they are now behind CGNs but everyone doesn't have IPv6 available to them. That is a failure of the industry to deploy IPv6 in time. > > the goal in stringing along ipv4 is to not hose your current or > > potential customers rather than prevent still more obstacles to their > > success. > > > > joel > > > > At this point, you are running the risk of conflating your goals with > your technical objections to the goals of others. And this has always > been the real underlying issue. > > Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.nether.net Wed Jul 15 23:58:23 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 15 Jul 2015 19:58:23 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6F0B3.8010302@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> Message-ID: <5C239FC0-EFA6-4A20-8ABC-78750229AD67@puck.nether.net> > On Jul 15, 2015, at 7:45 PM, Joe Maimon wrote: > > > > Doug Barton wrote: >> On 7/15/15 10:24 AM, Joe Maimon wrote: >>> I suspect a 16 /8 right about now would be very welcome for everybody >>> other then the ipv6 adherents. >> >> Globally we were burning through about a /8 every month or two in "the >> good old days." So in the best case scenario we'd get 32 more months of >> easy to get IPv4, but at an overwhelming cost to re-implement every >> network stack. >> >> This option was considered back in the early 2000's when I was still >> involved in the discussion, and rejected as impractical. >> > > > Removing experimental status does not equate with the burden of making it equivalent use to the rest of the address space. > > How about the ARIN burn rate post IANA runout? How long does 16 /8 last then? > > What would be wrong with removing experimental status and allowing one of the /8 to be used for low barrier to /16 assignment to any party demonstrating a willingness to coax usability of the space? > > Yes, any such effort has to run the gauntlet of IETF/IANA/RIR policy. > > CGN /10 managed. This could too, if all the naysayers would just step out of the way. This isn?t really a giant set of naysayers IMHO, but there is enough embedded logic in devices that it doesn?t make that much sense. Either you can survive with some type of NAT or you can?t. Many of my devices would not be missing capabilities if I had just IPv6 on them with some gateway to reach the IPv4 internet. I could likely make a short list of the sites that I really need access to that are IPv4 only. With Amazon/Walmart day, they would be well suited to have a fast IPv6 site :) It?s just a few operating systems that need to be changed: windows linux various *bsd flavors macos I don?t think it?s impossible, but so many things check for 224 > A > 1 it would be a large bit of work to fix those. This is excluding the routing equipment. What i?ve learned is that stuff like the netgear/linksys you have at your house spends around ~6 months in the supply chain before it reaches you. these all need to be updated as well as the ?big iron? stuff like cisco/juniper/arista as well as their embedded OS underneath, so maybe QNX or something else ?odd?. That effort would need to have everyone moving in the same direction now which seems unlikely. - Jared From jmaimon at ttec.com Thu Jul 16 00:02:15 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 15 Jul 2015 20:02:15 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <7EE3204D-3FC6-469E-911C-7AF7E641BDD7@delong.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <7EE3204D-3FC6-469E-911C-7AF7E641BDD7@delong.com> Message-ID: <55A6F487.4000105@ttec.com> Owen DeLong wrote: > >> On Jul 15, 2015, at 10:24 , Joe Maimon wrote: >> I suspect a 16 /8 right about now would be very welcome for everybody other then the ipv6 adherents. > > But it wouldn?t be right now. It would be after everyone put lots of effort into updating lots of systems so that they could support those 16 /8s. I propose allowing and accepting that people get to decide on their own where to focus their efforts. I dont believe in top down management. I also dont believe that the available pool of other people efforts is a zero sum game. > > By the time you?ve done that, you might as well have focused that effort on making those same systems do IPv6. See above. > >> Seems like procrastination is only bad when its your baby. > > Not really? This isn?t a question of procrastination or not. It?s a question of given that roughly the same effort is required to do thing A or thing B > and thing A (class E) leads nowhere in the long run while thing B provides a permanent solution, it makes much more sense to focus said effort > on thing B than to postpone thing B in favor of thing A. See above. And really? "same effort?" > >> The jury is still out on class E, but the verdict is in for the community who created it. > > Not really. I think if you really consider what would be required for deployment of class E, you?ll find that there truly is no there there. > > Owen I am not advocating class E adoption. I am advocating removal of barrier to adoption and I will go so far as to advocate a bootstrapped incentive for adoption, for those who get to choose on their own how to focus their own efforts. Its nice to point out that we are rehashing the exact debate you and I had a few years back. Self-fulfilling. Joe > > > From joelja at bogus.com Thu Jul 16 00:07:56 2015 From: joelja at bogus.com (joel jaeggli) Date: Wed, 15 Jul 2015 17:07:56 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6EE2B.5040201@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A6D9.4080501@bogus.com> <55A6EE2B.5040201@ttec.com> Message-ID: <55A6F5DC.7050404@bogus.com> On 7/15/15 4:35 PM, Joe Maimon wrote: > At this point, you are running the risk of conflating your goals with > your technical objections to the goals of others. And this has always > been the real underlying issue. My goal in an operational capacity is to continue to hold onto the quality and utility of IPv4 services until my customers don't need them anymore whether that comes 5 years from now, 10 or never. balkanzing them on the basis of what prefixes they can reach, and consigning new or growning entrants to address ranges that poorly serve the installed base doesn't serve that end. IPv4 as a mature deployed technology is quite successful at resisting innovation whether in the forwarding plane or at the transport. When I consider where I should be expending resources on IPv4 inovation or elsewhere, I look to minimize the NRE I have to expend sustaining IPv4. > Joe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From jfbeam at gmail.com Thu Jul 16 00:13:42 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 15 Jul 2015 20:13:42 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6EE2B.5040201@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A6D9.4080501@bogus.com> <55A6EE2B.5040201@ttec.com> Message-ID: On Wed, 15 Jul 2015 19:35:07 -0400, Joe Maimon wrote: > So your point is that those who claimed it would not help managed to > make it so? > > Would it have really hurt to remove experimental status and replace it > with use at your own risk status? Even now? No. The point is it's been wired into everything that has ever existed that it's an invalid address. Even if the "experimental" had been moved 15 years ago, there would still be devices today that CANNOT use one of those addresses, and further, is 100% incapable of talking to anything using one. Interestingly, Cisco, who proposed using the space, still has those restrictions embedded in everything they make. (Of course, their non-nexus switches still have token-ring and fddi translation vlans hardcoded.) Factor in the people who cannot do math and think multicast is "anything greater than 224.0.0.0", and you have a section of address space that is permanently unusable. (like 1.1.1.0/24 and 1.2.3.0/24) I'm not going to name names, but I've see proprietary code -- from more than one source -- that did that, because "bge [branch greater or equal] is a single instruction." If you think that's a "lame optimization", then you should be hunting down *everything* responsible for SLAAC. From jmaimon at ttec.com Thu Jul 16 00:13:52 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 15 Jul 2015 20:13:52 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <5C239FC0-EFA6-4A20-8ABC-78750229AD67@puck.nether.net> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <5C239FC0-EFA6-4A20-8ABC-78750229AD67@puck.nether.net> Message-ID: <55A6F740.3000602@ttec.com> Jared Mauch wrote: > > This isn?t really a giant set of naysayers IMHO, but there is enough embedded logic in devices that it doesn?t make that much sense. Enough to scuttle all previous drafts. > linux a little google comes up with this http://www.gossamer-threads.com/lists/linux/kernel/866043 It defies reason to compare that kind of update to ipv6. > various *bsd flavors > That effort would need to have everyone moving in the same direction now which seems unlikely. > > - Jared All I ever wanted to see was that the (minimal) effort was made possible. No guarantee of its success should be required for that. Even now. Because by doing so, you guarantee failure. Joe From owen at delong.com Thu Jul 16 00:25:33 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 17:25:33 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6F0B3.8010302@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> Message-ID: > On Jul 15, 2015, at 16:45 , Joe Maimon wrote: > > > > Doug Barton wrote: >> On 7/15/15 10:24 AM, Joe Maimon wrote: >>> I suspect a 16 /8 right about now would be very welcome for everybody >>> other then the ipv6 adherents. >> >> Globally we were burning through about a /8 every month or two in "the >> good old days." So in the best case scenario we'd get 32 more months of >> easy to get IPv4, but at an overwhelming cost to re-implement every >> network stack. >> >> This option was considered back in the early 2000's when I was still >> involved in the discussion, and rejected as impractical. >> > > > Removing experimental status does not equate with the burden of making it equivalent use to the rest of the address space. > > How about the ARIN burn rate post IANA runout? How long does 16 /8 last then? Assuming you could somehow make 16 /8s available, do you really think that anyone would accept the idea of allocating all of them to a single RIR, let alone the one in North America? I tend to doubt it. So ARIN?s burn rate post-runout really isn?t all that relevant. > What would be wrong with removing experimental status and allowing one of the /8 to be used for low barrier to /16 assignment to any party demonstrating a willingness to coax usability of the space? The wasted effort of people whose time is better spent deploying IPv6. > Yes, any such effort has to run the gauntlet of IETF/IANA/RIR policy. Which I would rather have those folks focused on something useful than wasting their time on this. > CGN /10 managed. This could too, if all the naysayers would just step out of the way. The /10 did not require modifying every system on the internet or even any systems on the internet. It just required setting aside a block. Even then, it was actually more effort than it should have required, but it was pretty minimal. OTOH, it provided an actual usable solution to a real world problem. What you are proposing just wastes a lot of people?s time with nothing to show for it. Owen From owen at delong.com Thu Jul 16 00:48:39 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 17:48:39 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <1436932411.17261.38.! ! camel@karl> <98BB1D4D-73E4-4D60-B910-2A05449D45B6@virtualized.org> Message-ID: <104AC596-189D-4A86-B5E3-19222894AD9F@delong.com> > On Jul 15, 2015, at 14:43 , Ricky Beam wrote: > > On Wed, 15 Jul 2015 17:23:52 -0400, Owen DeLong wrote: >> I will point out that nobody has said ?what the F*** were they thinking? when they made it possible to use 4GB of RAM instead of just 640k, but lots of people have said ?what the F*** were they thinking when they limited it to 640k.? > > Actually, they did. And "PAE" was invented. (or "re-invented", as various paging mechanisms had existed for many decades by then) Huh? You?re missing the point or deliberately ignoring it, hard to tell which. Vast address availability has never lead to WTF moments. Restrictive addressing, OTOH, has created many WTF moments. I look at NAT and I think WTF were they thinking, but it was an unfortunate consequence of the 32-bit limitation of IPv4. It?s an effort at coping with the limitations, however misguided it may be. I look at providers handing out /60 and I think WTF are they thinking. There?s no legitimate reasoning behind it. Why repeat the same mistakes again by limiting IPv6 deployments to something less than /48? As to your arguments on segmentation, no, RFC1918 is 3 segments because, again, of limitations in IPv4. In IPv6, it?s still only one segment. Arguing that the 4th (which actually isn?t RFC-1918) is a segmentation isn?t entirely valid as it?s more of an allocation than a segmentation and in any case, all of them are more than covered in the single existing IPv6 segmentation of fc00::/0 or even fd00::/9. Class E isn?t so much a segmentation as an early error that never got corrected. By the time anyone recognized the need to fix class E, it was easier to move to IPv6 than to repair that part of IPv4, so we moved on. 255/8 is not really still applicable and does not apply to IPv6 in any way, so I don?t think you can count that one. Same with 0/8. These weren?t segmentations, they were limitations of the technology at the time those RFCs were written. You can argue that localhost is a segmentation, I suppose, but in IPv6, it has reserved ::1/128. Everything else in ::/3 is still available to the best of my knowledge. So, in terms of total impact on IPv6, we?ve got three segmentations other than Unicast that are carried forward from IPv4. No more, no less. (unless someone comes up with something not yet mentioned). Owen From johnl at iecc.com Thu Jul 16 01:00:12 2015 From: johnl at iecc.com (John R. Levine) Date: 15 Jul 2015 21:00:12 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6F2BD.5010105@ttec.com> References: <20150715183316.26843.qmail@ary.lan> <55A6F2BD.5010105@ttec.com> Message-ID: > Are you really equating an incremental silent update to remove something > between one if statement or slightly more and an entire protocol stack that > when active fundamentally changes the host networking behavior? Yeah. On the devices I have, there's no practical difference between a one line update and a complete reload. Either you update the software or you don't, and mostly you don't. PCs and servers are easy, embedded routers and printers and the like are not. R's, John From fergdawgster at mykolab.com Thu Jul 16 01:08:10 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 15 Jul 2015 18:08:10 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150715183316.26843.qmail@ary.lan> <55A6F2BD.5010105@ttec.com> Message-ID: <55A703FA.2040508@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/15/2015 6:00 PM, John R. Levine wrote: >> Are you really equating an incremental silent update to remove >> something between one if statement or slightly more and an entire >> protocol stack that when active fundamentally changes the host >> networking behavior? > > Yeah. On the devices I have, there's no practical difference > between a one line update and a complete reload. Either you > update the software or you don't, and mostly you don't. PCs and > servers are easy, embedded routers and printers and the like are > not. And on your mobile devices, for the most part you are reliant upon your carrier to make software updates available to you in a timely and utilitarian manner. In other words, don't hold your breath. Carriers are the major barrier to both feature upgrades and security fixes/enhancements. It is tremendously frustrating. - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWnA/oACgkQKJasdVTchbJAWAD8DhRq1QlPZlZhH8Apr66od+NU Tz8F1bLqu6+3dymwNJEBANjyOh0jwwHhIZk1hOy/jIj8lCuUkYQjuFZlzZFYfwh8 =NuSw -----END PGP SIGNATURE----- From dougb at dougbarton.us Thu Jul 16 03:07:40 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 15 Jul 2015 20:07:40 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6F0B3.8010302@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> Message-ID: <55A71FFC.2090301@dougbarton.us> On 7/15/15 4:45 PM, Joe Maimon wrote: > > > Doug Barton wrote: >> On 7/15/15 10:24 AM, Joe Maimon wrote: >>> I suspect a 16 /8 right about now would be very welcome for everybody >>> other then the ipv6 adherents. >> >> Globally we were burning through about a /8 every month or two in "the >> good old days." So in the best case scenario we'd get 32 more months of >> easy to get IPv4, but at an overwhelming cost to re-implement every >> network stack. >> >> This option was considered back in the early 2000's when I was still >> involved in the discussion, and rejected as impractical. >> > > > Removing experimental status does not equate with the burden of making > it equivalent use to the rest of the address space. > > How about the ARIN burn rate post IANA runout? How long does 16 /8 last > then? > > What would be wrong with removing experimental status and allowing one > of the /8 to be used for low barrier to /16 assignment to any party > demonstrating a willingness to coax usability of the space? > > Yes, any such effort has to run the gauntlet of IETF/IANA/RIR policy. > > CGN /10 managed. This could too, if all the naysayers would just step > out of the way. Joe, In this post, and in your many other posts today, you seem to be asserting that this would work if "$THEY" would just get out of the way, and let it work. You've also said explicitly that you believe that this is an example of top-down dictates. I know you may find this hard to believe, but neither of these ideas turn out to be accurate. A little history ... In 2004 I was the manager of the IANA. Tony Hain came to me and said that he'd been crunching some numbers and his preliminary research indicated that the burn rate on IPv4 was increasing fairly dramatically, and that runout was likely to happen a lot sooner than folks expected it would. Various people started doing their own research along similar lines and confirmed Tony's findings. So amongst many others, I started taking various steps to "get ready" for IPv4 runout. One of those steps was to talk to folks about the feasibility of utilizing Class E space. Now keep in mind that I have no dog in this hunt. I've never been part of an RIR, I've never worked for a network gear company, I'm a DNS guy. To me, bits are bits. I was told, universally, that there was no way to make Class E space work, in the public Internet or private networks (because the latter was being considered as an expansion of 1918). There are just too many barriers, not the least of which is the overwhelming number of person-years it would take to rewrite all the software that has assumptions about Class E space hard coded. Further, the vendors we spoke to said that they had no intention of putting one minute's worth of work into that project, because the ROI was basically zero. In order for address space to "work" the standard is universal acceptance ... and that was simply never going to happen. There are literally hundreds of millions of devices in active use right now that would never work with Class E space because they cannot be updated. Of course it's also true that various folks, particularly the IETF leadership, were/are very gung ho that IPv6 is the right answer, so any effort put into making Class E space work is wasted effort; which should be spent on deploying IPv6. On a *personal* level I agree with that sentiment, but (to the extent I'm capable of being objective) I didn't let that feeling color my effort to get an honest answer from the many folks I talked to about this. But all that said, nothing is stopping YOU from working on it. :) The IETF can't stop you, the vendors can't stop you, no one can stop you ... if you think you can make it work, by all means, prove us all wrong. :) Find some others that agree with you, work on the code, do the interoperability tests, and present your work. You never know what might happen. In the meantime, please stop saying that not using this space was dictated from the top down, or that any one party/cabal/etc. is holding you back, because neither of those are accurate. Good luck, Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From alh-ietf at tndh.net Thu Jul 16 04:08:16 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 15 Jul 2015 21:08:16 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6F740.3000602@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <5C239FC0-EFA6-4A20-8ABC-78750229AD67@puck.nether.net> <55A6F740.3000602@ttec.com> Message-ID: <042e01d0bf7d$0af9e1b0$20eda510$@tndh.net> Joe Maimon wrote: > Jared Mauch wrote: > > > > > This isn?t really a giant set of naysayers IMHO, but there is enough > embedded logic in devices that it doesn?t make that much sense. > > Enough to scuttle all previous drafts. > > > linux > > a little google comes up with this > > http://www.gossamer-threads.com/lists/linux/kernel/866043 > > It defies reason to compare that kind of update to ipv6. > > > various *bsd flavors > > > That effort would need to have everyone moving in the same direction > now which seems unlikely. > > > > - Jared > > All I ever wanted to see was that the (minimal) effort was made possible. > No guarantee of its success should be required for that. Even now. > > Because by doing so, you guarantee failure. Joe, It appears you are asking for the world to sanction your local efforts. There is nothing stopping you from deploying and using that space if you can. Asking for a change in the standards status though will only lead to confusion and anguish. If 15 years ago it had been, or would now be changed to unicast, people would expect to be able to use it as they use the rest of the space. Those with access to source for all their devices could accomplish that, but everyone else would have to beat on vendors and wait an indeterminate time to get usable code, and that still would not fix rom based devices. On the other hand people with source don't need any standards change, they can just turn it on. If you want the additional effort to manage a global distribution of the space so it is not just an extension of 1918, then you have to acknowledge that it would only last a few weeks at best. While ARIN managed to change policy and slow things down, when APnic flamed out they burned through 6 /8's in 8 weeks and were accelerating, while Ripe was burning through one every 3 months, and Lacnic was accelerating through their last one over 4 months. So ignoring pent up demand since they have all been out for awhile now, and assuming that they space was generically usable, you get 8 weeks tops. Recognizing that they are not generically usable though it will likely take quite a bit longer than that. This is not being a naysayer, it is simply presenting issues that have been raised and considered many times over the last 15 years. There is a lot of work to make that space usable, and as you pointed out above the smallest part of that is the code change. In the context of the amount of work required in relation to the few weeks of gain that would result, it has always been difficult to establish much interest. At the end of the day it is not that much more work to fix all the devices to run IPv6. At that point you have no limitations, while 240/4 still leads to the place where the IPv4 pool is exhausted. Tony From guu at google.com Thu Jul 16 04:47:08 2015 From: guu at google.com (Yunhong Gu) Date: Thu, 16 Jul 2015 00:47:08 -0400 Subject: M$ no v6 or just me? In-Reply-To: References: Message-ID: Thanks for the tests that show the NODATA is from the authoritative nameserver. To clarify, Google DNS does not filter either AAAA or any of these domains. Yunhong On Tue, Jul 14, 2015 at 8:05 PM, Yang Yu wrote: > On Wed, Jul 15, 2015 at 4:33 AM, Nicholas Warren > wrote: > > Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, > or is Microsoft not available over v6? > > > > Thanks, > > Nich > > > > probably not Google DNS filtering > > > test point 1 > > $ dig e10088.dspb.akamaiedge.net AAAA @n0dspb.akamaiedge.net > > ; <<>> DiG 9.10.2-P2 <<>> e10088.dspb.akamaiedge.net AAAA @ > n0dspb.akamaiedge.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51914 > ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;e10088.dspb.akamaiedge.net. IN AAAA > > ;; AUTHORITY SECTION: > dspb.akamaiedge.net. 1000 IN SOA n0dspb.akamaiedge.net. > hostmaster.akamai.com. 1436917052 1000 1000 1000 1800 > > ;; Query time: 51 msec > ;; SERVER: 96.7.248.137#53(96.7.248.137) > ;; WHEN: Wed Jul 15 08:37:32 KST 2015 > ;; MSG SIZE rcvd: 119 > > > > test point 2 > > $ dig e10088.dspb.akamaiedge.net AAAA @n0dspb.akamaiedge.net > > ; <<>> DiG 9.8.1-P1 <<>> e10088.dspb.akamaiedge.net AAAA @ > n0dspb.akamaiedge.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27887 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;e10088.dspb.akamaiedge.net. IN AAAA > > ;; ANSWER SECTION: > e10088.dspb.akamaiedge.net. 20 IN AAAA 2600:1408:10:18f::2768 > e10088.dspb.akamaiedge.net. 20 IN AAAA 2600:1408:10:181::2768 > e10088.dspb.akamaiedge.net. 20 IN AAAA 2600:1408:10:188::2768 > > ;; Query time: 18 msec > ;; SERVER: 88.221.81.193#53(88.221.81.193) > ;; WHEN: Tue Jul 14 16:37:17 2015 > ;; MSG SIZE rcvd: 128 > > > I get different IPs for n0dspb.akamaiedge.net / n0dscb.akamaiedge.net > every time. > > So it depends on source IP of the query and which akamai DNS server is > answering? > From marka at isc.org Thu Jul 16 02:32:19 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 16 Jul 2015 12:32:19 +1000 Subject: Remember "Internet-In-A-Box"? In-Reply-To: Your message of "Wed, 15 Jul 2015 08:57:26 -0700." <55A682E6.1050607@matthew.at> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> Message-ID: <20150716023244.80481333596E@rock.dv.isc.org> In message <55A682E6.1050607 at matthew.at>, Matthew Kaufman writes: > On 7/14/2015 11:22 PM, Mark Andrews wrote: > > > > Yet I can take a Windows XP box. Tell it to enable IPv6 and it > > just works. Everything that a node needed existed when Windows XP > > was released. The last 15 years has been waiting for ISP's and CPE > > vendors to deliver IPv6 as a product. This is not to say that every > > vendor deployed all the parts of the protocol properly but they > > existed. > > This is only true for dual-stacked networks. I just tried to set up an > IPv6-only WiFi network at my house recently, and it was a total fail due > to non-implementation of relatively new standards... starting with the > fact that my Juniper SRX doesn't run a load new enough to include RDNSS > information in RAs, and some of the devices I wanted to test with > (Android tablets) won't do DHCPv6. You can blame the religious zealots that insisted that everything DHCP does has to also be done via RA's. This means that everyone has to implement everything twice. Something Google should have realised when they releases Android. > The XP box is in an even worse situation if you try to run it on a > v6-only network. Which is fixable with a third party DHCPv6 client / manual configuration of the nameservers. > And yet we've known for years now that dual-stack wasn't going to be an > acceptable solution, because nobody was on track to get to 100% IPv6 > before IPv4 runout happened. > > Go to any business with hardware that is 3-5 years old in its IT > infrastructure and devices ranging from PCs running XP to the random > consumer gear people bring in (cameras, printers, tablets, etc.) and see > how easy it is to get everything talking on an IPv6-only (no IPv4 at > all) network... including using IPv6 to do automatic updates and all the > other pieces that need to work. We're nowhere near ready for that. None of which is the fault of the protocol. Blame the equipement vendors for being negligent. > Matthew Kaufman > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From matthew at matthew.at Thu Jul 16 05:46:13 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 15 Jul 2015 22:46:13 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150716023244.80481333596E@rock.dv.isc.org> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716023244.80481333596E@rock.dv.isc.org> Message-ID: <55A74525.8030405@matthew.at> On 7/15/15 7:32 PM, Mark Andrews wrote: > > > Go to any business with hardware that is 3-5 years old in its IT > infrastructure and devices ranging from PCs running XP to the random > consumer gear people bring in (cameras, printers, tablets, etc.) and see > how easy it is to get everything talking on an IPv6-only (no IPv4 at > all) network... including using IPv6 to do automatic updates and all the > other pieces that need to work. We're nowhere near ready for that. > None of which is the fault of the protocol. Blame the equipement vendors > for being negligent. > I could blame the people doing IT in those environments too, but that doesn't make it so that nobody needs IPv4 addresses to deploy servers to keep talking to these folks. Matthew Kaufman From tore at fud.no Thu Jul 16 05:59:14 2015 From: tore at fud.no (Tore Anderson) Date: Thu, 16 Jul 2015 07:59:14 +0200 Subject: Remember "Internet-In-A-Box"? In-Reply-To: References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> Message-ID: <20150716075914.464d25d7@echo.ms.redpill-linpro.com> * Owen DeLong > > On Jul 15, 2015, at 08:57 , Matthew Kaufman wrote: > > This is only true for dual-stacked networks. I just tried to set up > > an IPv6-only WiFi network at my house recently, and it was a total > > fail due to non-implementation of relatively new standards... > > starting with the fact that my Juniper SRX doesn't run a load new > > enough to include RDNSS information in RAs, and some of the devices > > I wanted to test with (Android tablets) won't do DHCPv6. > > That?s a pretty old load then, as I?ve had RDNSS on my SRX-100 for > several years now. Interesting. Which JUNOS version are you running, exactly? According to Juniper's web site, RDNSS support showed up in JUNOS 14.1, which isn't available for the SRX series (nor is any later version). http://www.juniper.net/techpubs/en_US/junos15.1/topics/reference/configuration-statement/dns-server-address-edit-protocols-router-advertisement.html Tore From list at satchell.net Thu Jul 16 06:02:14 2015 From: list at satchell.net (Stephen Satchell) Date: Wed, 15 Jul 2015 23:02:14 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150716023244.80481333596E@rock.dv.isc.org> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716023244.80481333596E@rock.dv.isc.org> Message-ID: <55A748E6.9050406@satchell.net> On 07/15/2015 07:32 PM, Mark Andrews wrote: > None of which is the fault of the protocol. Blame the equipement vendors > for being negligent. I'm sorry, it is just me? Or is the issue before us to fix the PROBLEM and not fix the BLAME? Pointing fingers isn't going to help get us to widespread IPv6 use. >> Go to any business with hardware that is 3-5 years old in its IT >> infrastructure and devices ranging from PCs running XP to the >> random consumer gear people bring in (cameras, printers, tablets, >> etc.) and see how easy it is to get everything talking on an >> IPv6-only (no IPv4 at all) network... including using IPv6 to do >> automatic updates and all the other pieces that need to work. We're >> nowhere near ready for that. So, what is the SOLUTION, or the start of a SOLUTION? From hugo at slabnet.com Thu Jul 16 06:03:36 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 15 Jul 2015 23:03:36 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150716023244.80481333596E@rock.dv.isc.org> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716023244.80481333596E@rock.dv.isc.org> Message-ID: <20150716060336.GA4261@bamboo.slabnet.com> On Thu 2015-Jul-16 12:32:19 +1000, Mark Andrews wrote: --snip-- >You can blame the religious zealots that insisted that everything >DHCP does has to also be done via RA's. This means that everyone >has to implement everything twice. Something Google should have >realised when they releases Android. oi...do we want to go down that road[1][2] again? -- Hugo hugo at slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone) [1] http://mailman.nanog.org/pipermail/nanog/2015-June/075915.html [2] https://code.google.com/p/android/issues/detail?id=32621 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From owen at delong.com Thu Jul 16 06:51:37 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 23:51:37 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150716023244.80481333596E@rock.dv.isc.org> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716023244.80481333596E@rock.dv.isc.org> Message-ID: <08222836-BB32-4683-AE8B-2F0F61CDF52D@delong.com> > On Jul 15, 2015, at 19:32 , Mark Andrews wrote: > > > In message <55A682E6.1050607 at matthew.at>, Matthew Kaufman writes: >> On 7/14/2015 11:22 PM, Mark Andrews wrote: >>> >>> Yet I can take a Windows XP box. Tell it to enable IPv6 and it >>> just works. Everything that a node needed existed when Windows XP >>> was released. The last 15 years has been waiting for ISP's and CPE >>> vendors to deliver IPv6 as a product. This is not to say that every >>> vendor deployed all the parts of the protocol properly but they >>> existed. >> >> This is only true for dual-stacked networks. I just tried to set up an >> IPv6-only WiFi network at my house recently, and it was a total fail due >> to non-implementation of relatively new standards... starting with the >> fact that my Juniper SRX doesn't run a load new enough to include RDNSS >> information in RAs, and some of the devices I wanted to test with >> (Android tablets) won't do DHCPv6. > > You can blame the religious zealots that insisted that everything > DHCP does has to also be done via RA's. This means that everyone > has to implement everything twice. Something Google should have > realised when they releases Android. Actually, no. In this case, the problem isn?t the things RA does, but the things his implementation of RA doesn?t do (RDNSS). Without RDNSS, android would still be brain-damaged and unable to figure out what an IPv6 nameserver is. The only way it would be able to talk to the IPv6 internet was if it got nameservers from DHCP4. At least with RDNSS, a thin lightweight client can get nameservers on IPv6. At least with RDNSS, a network administrator that doesn?t want to have to do DHCPv6 doesn?t have to in most cases. >> The XP box is in an even worse situation if you try to run it on a >> v6-only network. > > Which is fixable with a third party DHCPv6 client / manual configuration > of the nameservers. Nope? XP?s resolver is utterly and completely incapable of transmitting an IPv6 DNS request. You _HAVE_ to have an IPv4 resolver reachable to the box or forego any idea of using DNS. Owen From owen at delong.com Thu Jul 16 06:54:03 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jul 2015 23:54:03 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <55A74525.8030405@matthew.at> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716023244.80481333596E@rock.dv.isc.org> <55A74525.8030405@matthew.at> Message-ID: > On Jul 15, 2015, at 22:46 , Matthew Kaufman wrote: > > > > On 7/15/15 7:32 PM, Mark Andrews wrote: >> >> >> Go to any business with hardware that is 3-5 years old in its IT >> infrastructure and devices ranging from PCs running XP to the random >> consumer gear people bring in (cameras, printers, tablets, etc.) and see >> how easy it is to get everything talking on an IPv6-only (no IPv4 at >> all) network... including using IPv6 to do automatic updates and all the >> other pieces that need to work. We're nowhere near ready for that. >> None of which is the fault of the protocol. Blame the equipement vendors >> for being negligent. >> > > I could blame the people doing IT in those environments too, but that doesn't make it so that nobody needs IPv4 addresses to deploy servers to keep talking to these folks. > > Matthew Kaufman Need is not the problem. Availability is a problem now. It?s going to be a more difficult problem in the future. The sooner we get to where they are using IPv6 even if they?re just dual-stacked, the sooner availability becomes less of a problem due to the elimination of need. Since availability isn?t going to get better, really, the only option to make the situation better is to eliminate need. The best way to eliminate need for IPv4 is IPv6. It?s really as simple as that. Owen From seth.mos at dds.nl Thu Jul 16 07:34:00 2015 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 16 Jul 2015 09:34:00 +0200 Subject: Remember "Internet-In-A-Box"? Message-ID: So, if i get this right. The problem is not quite as bad to fix. It just needs a dnscache/dnsproxy process bound to the ipv4 localhost that uses the ipv6 dns server. Basically what dnsmasq does. Biggest problem is that it wouldn't follow autoconfigure and thus require manual intervention. That is a no go for dynamic networks of any sort. Cheers-------- Oorspronkelijk bericht --------Van: Owen DeLong Datum: 16-07-2015 08:51 (GMT+01:00) Aan: Mark Andrews Cc: nanog at nanog.org Onderwerp: Re: Remember "Internet-In-A-Box"? > On Jul 15, 2015, at 19:32 , Mark Andrews wrote: > > > In message <55A682E6.1050607 at matthew.at>, Matthew Kaufman writes: >> On 7/14/2015 11:22 PM, Mark Andrews wrote: >>> >>> Yet I can take a Windows XP box.? Tell it to enable IPv6 and it >>> just works.? Everything that a node needed existed when Windows XP >>> was released.? The last 15 years has been waiting for ISP's and CPE >>> vendors to deliver IPv6 as a product.? This is not to say that every >>> vendor deployed all the parts of the protocol properly but they >>> existed. >> >> This is only true for dual-stacked networks. I just tried to set up an >> IPv6-only WiFi network at my house recently, and it was a total fail due >> to non-implementation of relatively new standards... starting with the >> fact that my Juniper SRX doesn't run a load new enough to include RDNSS >> information in RAs, and some of the devices I wanted to test with >> (Android tablets) won't do DHCPv6. > > You can blame the religious zealots that insisted that everything > DHCP does has to also be done via RA's.? This means that everyone > has to implement everything twice.? Something Google should have > realised when they releases Android. Actually, no. In this case, the problem isn?t the things RA does, but the things his implementation of RA doesn?t do (RDNSS). Without RDNSS, android would still be brain-damaged and unable to figure out what an IPv6 nameserver is. The only way it would be able to talk to the IPv6 internet was if it got nameservers from DHCP4. At least with RDNSS, a thin lightweight client can get nameservers on IPv6. At least with RDNSS, a network administrator that doesn?t want to have to do DHCPv6 doesn?t have to in most cases. >> The XP box is in an even worse situation if you try to run it on a >> v6-only network. > > Which is fixable with a third party DHCPv6 client / manual configuration > of the nameservers. Nope? XP?s resolver is utterly and completely incapable of transmitting an IPv6 DNS request. You _HAVE_ to have an IPv4 resolver reachable to the box or forego any idea of using DNS. Owen From owen at delong.com Thu Jul 16 07:39:55 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Jul 2015 00:39:55 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: References: Message-ID: <504668B1-0A1A-4ECE-9002-DD6A727B8C07@delong.com> > On Jul 16, 2015, at 00:34 , Seth Mos wrote: > > So, if i get this right. The problem is not quite as bad to fix. > > It just needs a dnscache/dnsproxy process bound to the ipv4 localhost that uses the ipv6 dns server. > > Basically what dnsmasq does. Biggest problem is that it wouldn't follow autoconfigure and thus require manual intervention. That is a no go for dynamic networks of any sort. It?s a fairly safe bet that anything that involves a mobile OS is most likely a dynamic network of some sort. Owen > > Cheers > -------- Oorspronkelijk bericht -------- > Van: Owen DeLong > Datum: 16-07-2015 08:51 (GMT+01:00) > Aan: Mark Andrews > Cc: nanog at nanog.org > Onderwerp: Re: Remember "Internet-In-A-Box"? > > > On Jul 15, 2015, at 19:32 , Mark Andrews wrote: > > > > > > In message <55A682E6.1050607 at matthew.at>, Matthew Kaufman writes: > >> On 7/14/2015 11:22 PM, Mark Andrews wrote: > >>> > >>> Yet I can take a Windows XP box. Tell it to enable IPv6 and it > >>> just works. Everything that a node needed existed when Windows XP > >>> was released. The last 15 years has been waiting for ISP's and CPE > >>> vendors to deliver IPv6 as a product. This is not to say that every > >>> vendor deployed all the parts of the protocol properly but they > >>> existed. > >> > >> This is only true for dual-stacked networks. I just tried to set up an > >> IPv6-only WiFi network at my house recently, and it was a total fail due > >> to non-implementation of relatively new standards... starting with the > >> fact that my Juniper SRX doesn't run a load new enough to include RDNSS > >> information in RAs, and some of the devices I wanted to test with > >> (Android tablets) won't do DHCPv6. > > > > You can blame the religious zealots that insisted that everything > > DHCP does has to also be done via RA's. This means that everyone > > has to implement everything twice. Something Google should have > > realised when they releases Android. > > Actually, no. > > In this case, the problem isn?t the things RA does, but the things his > implementation of RA doesn?t do (RDNSS). > > Without RDNSS, android would still be brain-damaged and unable > to figure out what an IPv6 nameserver is. The only way it would be > able to talk to the IPv6 internet was if it got nameservers from DHCP4. > > At least with RDNSS, a thin lightweight client can get nameservers on IPv6. > At least with RDNSS, a network administrator that doesn?t want to have > to do DHCPv6 doesn?t have to in most cases. > > >> The XP box is in an even worse situation if you try to run it on a > >> v6-only network. > > > > Which is fixable with a third party DHCPv6 client / manual configuration > > of the nameservers. > > Nope? XP?s resolver is utterly and completely incapable of transmitting > an IPv6 DNS request. > > You _HAVE_ to have an IPv4 resolver reachable to the box or forego any > idea of using DNS. > > Owen > From marka at isc.org Thu Jul 16 11:19:54 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 16 Jul 2015 21:19:54 +1000 Subject: Remember "Internet-In-A-Box"? In-Reply-To: Your message of "Wed, 15 Jul 2015 23:03:36 -0700." <20150716060336.GA4261@bamboo.slabnet.com> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716023244.80481333596E@rock.dv.isc.org> <20150716060336.GA4261@bamboo.slabnet.com> Message-ID: <20150716111954.8B0B23337ED3@rock.dv.isc.org> In message <20150716060336.GA4261 at bamboo.slabnet.com>, Hugo Slabbert writes: > --snip-- > > >You can blame the religious zealots that insisted that everything > >DHCP does has to also be done via RA's. This means that everyone > >has to implement everything twice. Something Google should have > >realised when they releases Android. > > oi...do we want to go down that road[1][2] again? Once you have two methods of doing things, neither of which is manditory to implement, you can only get interoperate with everything if you implement both. The whole "we can't open a second socket" to do DHCP + SLACC because it is "too complicated" or "we don't want to run a second server" was nonsense. The direct consequence of doing that was Android not working on networks that supply other config over DHCP. We ship servers that speak multiple protocols on one multiple ports in the one binary. It isn't and never has been hard to do that. > -- > Hugo > > hugo at slabnet.com: email, xmpp/jabber > PGP fingerprint (B178313E): > CF18 15FA 9FE4 0CD1 2319 > 1D77 9AB1 0FFD B178 313E > > (also on textsecure & redphone) > > [1] http://mailman.nanog.org/pipermail/nanog/2015-June/075915.html > [2] https://code.google.com/p/android/issues/detail?id=32621 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark.tinka at seacom.mu Thu Jul 16 12:23:13 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 16 Jul 2015 14:23:13 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <3772.1436975354@turing-police.cc.vt.edu> References: <20150715152505.26352.qmail@ary.lan> <3772.1436975354@turing-police.cc.vt.edu> Message-ID: <55A7A231.7010506@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 15/Jul/15 17:49, Valdis.Kletnieks at vt.edu wrote: > > There isn't any technical reason that an organization can't fix its edge > so it doesn't urinate bad IPv6 traffic all over the Internet. Some hardware does not support uRPF, for example. ACL's would work, but there are administrative scaling issues. Still, better to have that than nothing at all. Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVp6IxAAoJEGcZuYTeKm+G8v4P+QE2PylGp9jDuThry8d4a1OD 8d6+8cKvgf0EG2Jg+Vm076JV6lwNFKRrf2i36AA0F3o2+cFFhFfbM5eUB+4HXGia UQtvEclba8CeTQHdxFAZDCOfXSxUT9bhTt4Uc9kplAY+BoF7yGyk6U2KxG45T+Fd 4kXlwXqSZmFqRsH4oRNPPvVKQsfj5VFz90iPW6Qh8gCawcH9sDU3d4esEemwGArz 3v79a+qlrNFgbv/C4soTyIveAE1BJ6lI1c0UQA0cGc+pbRvk/LByG5Ep+gD9Rsvc xjApdnmDSMw8qLMpn4zvtjYeKpaeaVuwsyr+iokYPOOi/uU3EB/rk7wobXCtdb2j tUqVtnbJocLhdmmPh90JDK0TNEaJLOY9H3dOfmOrIPCIg7jY9+4EW/+ivL1bARi/ 0iWpASGhJhLqaBhGay7pGgQA+2lf2DhHyLqRZd2hhQNZWrf5eEfY44ZzZSqezURD fV25Uf33HCEgV2M+Hqmmj83CFpSkt0gdjrBCp3FlcLesKJPr8+tSyerGdzCLSPlp q4kTV2rgXtLXmKm5ElsLlEgsrNEyDW1cZZj3ES35D7aDNzDH19uGd492nrIq2U6z 0Yk1ZUz3s6Ohxfmnhs8ompFGPoII2jEoZTIcVpdM71gLwwIMzSg4a3HoQ88mCCZT yxYaKw3YmjS8BhkbfaEJ =7ivn -----END PGP SIGNATURE----- From jared at puck.Nether.net Thu Jul 16 12:36:19 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 16 Jul 2015 08:36:19 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A6F740.3000602@ttec.com> References: <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <5C239FC0-EFA6-4A20-8ABC-78750229AD67@puck.nether.net> <55A6F740.3000602@ttec.com> Message-ID: <20150716123619.GA23980@puck.nether.net> On Wed, Jul 15, 2015 at 08:13:52PM -0400, Joe Maimon wrote: > Because by doing so, you guarantee failure. I'll take personal responsibility for the class E space not working if that makes you feel better. I suspect it would be easier to get 0.1.0.0-0.255.255.255 to work than 240-254 space. Think of the children with tablets/devices that can't be upgraded due to orphaned software by Android and Apple. The list goes on and on.. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From dovid at telecurve.com Thu Jul 16 13:34:26 2015 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 16 Jul 2015 09:34:26 -0400 Subject: ISP in NYC Message-ID: Hi, We are looking to peer with another ISP in NY. My options are: Telia Tata Cogent We currently have (and will keep): HE NTT TELX (They use NTT and HE and we are looking to replace them). We need an ISP that has a good peering/connectivity in Europe and Asia (Israel specific). Any advice on who to go with? From hugo at slabnet.com Thu Jul 16 15:03:43 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 16 Jul 2015 08:03:43 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150716111954.8B0B23337ED3@rock.dv.isc.org> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716023244.80481333596E@rock.dv.isc.org> <20150716060336.GA4261@bamboo.slabnet.com> <20150716111954.8B0B23337ED3@rock.dv.isc.org> Message-ID: <20150716150343.GB4261@bamboo.slabnet.com> On Thu 2015-Jul-16 21:19:54 +1000, Mark Andrews wrote: > >In message <20150716060336.GA4261 at bamboo.slabnet.com>, Hugo Slabbert writes: >> --snip-- >> >> >You can blame the religious zealots that insisted that everything >> >DHCP does has to also be done via RA's. This means that everyone >> >has to implement everything twice. Something Google should have >> >realised when they releases Android. >> >> oi...do we want to go down that road[1][2] again? > >Once you have two methods of doing things, neither of which is >manditory to implement, you can only get interoperate with everything >if you implement both. The whole "we can't open a second socket" >to do DHCP + SLACC because it is "too complicated" or "we don't >want to run a second server" was nonsense. The direct consequence >of doing that was Android not working on networks that supply other >config over DHCP. > >We ship servers that speak multiple protocols on one multiple ports >in the one binary. It isn't and never has been hard to do that. Not disagreeing with you. The discussion was just exhaustively expounded in that thread over (by my count) 182 messages, with very little to show for it. We can take another run at flinging words on the topic and trying to get Google to implement a DHCPv6 client in Android, but I have my doubts about how effective that will be. > >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Hugo hugo at slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jmaimon at ttec.com Thu Jul 16 15:24:20 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 16 Jul 2015 11:24:20 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A71FFC.2090301@dougbarton.us> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <55A71FFC.2090301@dougbarton.us> Message-ID: <55A7CCA4.2020002@ttec.com> Doug Barton wrote: > > Joe, > > In this post, and in your many other posts today, you seem to be > asserting that this would work if "$THEY" would just get out of the way, > and let it work. You've also said explicitly that you believe that this > is an example of top-down dictates. I know you may find this hard to > believe, but neither of these ideas turn out to be accurate. A little > history ... > > In 2004 I was the manager of the IANA. Tony Hain came to me and said > that he'd been crunching some numbers and his preliminary research > indicated that the burn rate on IPv4 was increasing fairly dramatically, > and that runout was likely to happen a lot sooner than folks expected it > would. Various people started doing their own research along similar > lines and confirmed Tony's findings. > > So amongst many others, I started taking various steps to "get ready" > for IPv4 runout. One of those steps was to talk to folks about the > feasibility of utilizing Class E space. Now keep in mind that I have no > dog in this hunt. I've never been part of an RIR, I've never worked for > a network gear company, I'm a DNS guy. To me, bits are bits. > > I was told, universally, that there was no way to make Class E space > work, in the public Internet or private networks (because the latter was > being considered as an expansion of 1918). There are just too many > barriers, not the least of which is the overwhelming number of > person-years it would take to rewrite all the software that has > assumptions about Class E space hard coded. > > Further, the vendors we spoke to said that they had no intention of > putting one minute's worth of work into that project, because the ROI > was basically zero. In order for address space to "work" the standard is > universal acceptance ... and that was simply never going to happen. > There are literally hundreds of millions of devices in active use right > now that would never work with Class E space because they cannot be > updated. > > Of course it's also true that various folks, particularly the IETF > leadership, were/are very gung ho that IPv6 is the right answer, so any > effort put into making Class E space work is wasted effort; which should > be spent on deploying IPv6. On a *personal* level I agree with that > sentiment, but (to the extent I'm capable of being objective) I didn't > let that feeling color my effort to get an honest answer from the many > folks I talked to about this. > > But all that said, nothing is stopping YOU from working on it. :) The > IETF can't stop you, the vendors can't stop you, no one can stop you ... > if you think you can make it work, by all means, prove us all wrong. :) > Find some others that agree with you, work on the code, do the > interoperability tests, and present your work. You never know what might > happen. > > In the meantime, please stop saying that not using this space was > dictated from the top down, or that any one party/cabal/etc. is holding > you back, because neither of those are accurate. > > Good luck, > > Doug > Thanks for the this. To clarify, my criticism of top down is specifically in response to the rationale presented that it is a valid objective to prevent, hinder and refuse to enable efforts that "compete" with ipv6 world-takeover resources. I have no intention of using Class E. I have no intention of developing code that uses Classe E. I will note that the code involved that is publicly searchable appears to be simple and small, the task that is large is adoption spread. But perhaps we can all agree that standards should be accurate and should not be used to advance uninvolved agenda. And class E experimental status is inaccurate. And keeping that status serves nobody, except those who believe it helps marshal efforts away from IPv4. And that is top down. Burn rate is specious. Applying liberally constrained green-field burn-rate as a projection of ROI on brownfield space likely to be heavily constrained by market force if nothing else is wholly inapplicable and inaccurate. Joe From mhuff at ox.com Thu Jul 16 15:45:20 2015 From: mhuff at ox.com (Matthew Huff) Date: Thu, 16 Jul 2015 15:45:20 +0000 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers Message-ID: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> Just ran into this issue this morning. The SEC requires companies to file EDGAR reports on https://edgarfiling.sec.gov. The newer versions of Firefox won't let you access the webpages without manually going into about:config and re-enabling the weak ciphers. Given the recent issue with the OPM, I would think this would be a very bad follow-up if the SEC got hacked. SSLLabs gives the website an "F". IE 11 won't work either (for other reasons). https://www.ssllabs.com/ssltest/analyze.html?d=edgarfiling.sec.gov The website looks like it was designed in the '90s. I've tried to reach out to their contacts (webmaster, oig, etc...) but haven't gotten a reply yet. It's possible that I might get a reply eventually, but does anyone have any direct contacts at the SEC? ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 From rafael at gav.ufsc.br Thu Jul 16 15:53:06 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 16 Jul 2015 10:53:06 -0500 Subject: Speaking of NTP... In-Reply-To: References: Message-ID: Depending on how exactly you have these servers configured with relation to one another, small variations from one single source can be augmented down the line. https://en.wikipedia.org/wiki/Propagation_of_uncertainty On Mon, Jul 13, 2015 at 8:17 AM, Matthew Huff wrote: > We have 5 NTP server: 2 x stratum 1 rubidium oscillator time servers with > GPS sync, and 3 servers running NTP 4.2.6p5-3 synced to external internet > based NTP stratum 1 servers. We monitor our NTP environment closely, and > over the last 10+ years, normally all of our NTP servers are sync'ed within > +/- 2 msec. Starting last Friday, we started seeing some remote NTP servers > with GPS reference consistently offset by 10 msec. > > Any one else seeing this? > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > From jacques.latour at cira.ca Thu Jul 16 16:20:39 2015 From: jacques.latour at cira.ca (Jacques Latour) Date: Thu, 16 Jul 2015 16:20:39 +0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A7CCA4.2020002@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <55A71FFC.2090301@dougbarton.us> <55A7CCA4.2020002@ttec.com> Message-ID: Hi, Dual stack is where we need to go 'now', but we need to think about the future where we run an IPv6 only stack and stop thinking how to leverage, extend, expand and create ugly IPv4 solutions. IPv4 is done; it served its purpose well, thank you. We need a date where IPv4 is no longer routed on the Internet. I am suggesting 4/4/2024. Whatever the timeline, we need to agree on the date and drive toward a common goal for a better Internet. My 2 Canadian cents :-) Jack > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Maimon > Sent: July-16-15 11:24 AM > To: Doug Barton; nanog at nanog.org > Subject: Re: Dual stack IPv6 for IPv4 depletion > > > > Doug Barton wrote: > > > > > Joe, > > > > In this post, and in your many other posts today, you seem to be > > asserting that this would work if "$THEY" would just get out of the > > way, and let it work. You've also said explicitly that you believe > > that this is an example of top-down dictates. I know you may find this > > hard to believe, but neither of these ideas turn out to be accurate. A > > little history ... > > > > In 2004 I was the manager of the IANA. Tony Hain came to me and said > > that he'd been crunching some numbers and his preliminary research > > indicated that the burn rate on IPv4 was increasing fairly > > dramatically, and that runout was likely to happen a lot sooner than > > folks expected it would. Various people started doing their own > > research along similar lines and confirmed Tony's findings. > > > > So amongst many others, I started taking various steps to "get ready" > > for IPv4 runout. One of those steps was to talk to folks about the > > feasibility of utilizing Class E space. Now keep in mind that I have > > no dog in this hunt. I've never been part of an RIR, I've never worked > > for a network gear company, I'm a DNS guy. To me, bits are bits. > > > > I was told, universally, that there was no way to make Class E space > > work, in the public Internet or private networks (because the latter > > was being considered as an expansion of 1918). There are just too many > > barriers, not the least of which is the overwhelming number of > > person-years it would take to rewrite all the software that has > > assumptions about Class E space hard coded. > > > > Further, the vendors we spoke to said that they had no intention of > > putting one minute's worth of work into that project, because the ROI > > was basically zero. In order for address space to "work" the standard > > is universal acceptance ... and that was simply never going to happen. > > There are literally hundreds of millions of devices in active use > > right now that would never work with Class E space because they cannot > > be updated. > > > > Of course it's also true that various folks, particularly the IETF > > leadership, were/are very gung ho that IPv6 is the right answer, so > > any effort put into making Class E space work is wasted effort; which > > should be spent on deploying IPv6. On a *personal* level I agree with > > that sentiment, but (to the extent I'm capable of being objective) I > > didn't let that feeling color my effort to get an honest answer from > > the many folks I talked to about this. > > > > But all that said, nothing is stopping YOU from working on it. :) The > > IETF can't stop you, the vendors can't stop you, no one can stop you ... > > if you think you can make it work, by all means, prove us all wrong. :) > > Find some others that agree with you, work on the code, do the > > interoperability tests, and present your work. You never know what > > might happen. > > > > In the meantime, please stop saying that not using this space was > > dictated from the top down, or that any one party/cabal/etc. is > > holding you back, because neither of those are accurate. > > > > Good luck, > > > > Doug > > > > > Thanks for the this. > > To clarify, my criticism of top down is specifically in response to the rationale > presented that it is a valid objective to prevent, hinder and refuse to enable > efforts that "compete" with ipv6 world-takeover resources. > > I have no intention of using Class E. I have no intention of developing code that > uses Classe E. I will note that the code involved that is publicly searchable > appears to be simple and small, the task that is large is adoption spread. > > But perhaps we can all agree that standards should be accurate and should not > be used to advance uninvolved agenda. And class E experimental status is > inaccurate. And keeping that status serves nobody, except those who believe it > helps marshal efforts away from IPv4. And that is top down. > > Burn rate is specious. Applying liberally constrained green-field burn-rate as a > projection of ROI on brownfield space likely to be heavily constrained by > market force if nothing else is wholly inapplicable and inaccurate. > > Joe From bzs at world.std.com Thu Jul 16 16:39:58 2015 From: bzs at world.std.com (Barry Shein) Date: Thu, 16 Jul 2015 12:39:58 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <55A5AB96.8090101@dou! ! gbarton.us> <21926.51395.248847.677579@world.std.com> <356637FD-272E-4092-9BA9-73FA52740B4C@delong.com> Message-ID: <21927.56926.338588.320221@world.std.com> Yeah wow 127/8, that one always amazed me, 16M addrs because it was computationally cheap to test for ((0x7f & addr) == 0x7f). I wonder what are the most 127.* addrs ever used by one site? I know there are some schemes which blackhole to 127.0.0.n incrementing n so the number of hits on each blackhole can be counted separately (more or less) but 16M? I doubt even 254 were used in those schemes very often. WWWT? (What Were We Thinking?) Oh well water under the bridge. On July 15, 2015 at 17:53 jfbeam at gmail.com (Ricky Beam) wrote: > On Wed, 15 Jul 2015 17:34:13 -0400, Owen DeLong wrote: > > That covers multicast and RFC-1918. Are there any other IPv4 > > segmentations that you can think of? > ... > > Given that we came up with 3 total segmentations in IPv4 over the course > > #1-3,#4 RFC-1918 is 3 "segments" and we recently added a 4th (for CGN). > #5 Localhost (127/8) > #6 Multicast (224/4) > #7 "Class E" (240/4) > #8 0/8 > #9 255/8 (technically, part of class e, but it's called out specifically > in various RFCs) -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From Bryan at bryanfields.net Thu Jul 16 16:47:36 2015 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 16 Jul 2015 12:47:36 -0400 Subject: 'gray' market IPv4 In-Reply-To: References: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> Message-ID: <55A7E028.1070402@bryanfields.net> On 7/15/15 9:59 AM, Lee Howard wrote: > Price varies significantly by prefix length, and somewhat by region. > Regional variance may not be as much as it used to be. Does legacy space command a premium in this? What's the going rate to lease space (say a /20 or /19 for discussion)? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From Lee at asgard.org Thu Jul 16 16:58:18 2015 From: Lee at asgard.org (Lee Howard) Date: Thu, 16 Jul 2015 12:58:18 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A7CCA4.2020002@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <55A71FFC.2090301@dougbarton.us> <55A7CCA4.2020002@ttec.com> Message-ID: On 7/16/15, 11:24 AM, "NANOG on behalf of Joe Maimon" wrote: > > >To clarify, my criticism of top down is specifically in response to the >rationale presented that it is a valid objective to prevent, hinder and >refuse to enable efforts that "compete" with ipv6 world-takeover >resources. I don?t see anybody hindering any efforts; I don?t see any efforts. > >I have no intention of using Class E. I have no intention of developing >code that uses Classe E. I will note that the code involved that is >publicly searchable appears to be simple and small, the task that is >large is adoption spread. So this argument is moot? > >But perhaps we can all agree that standards should be accurate and >should not be used to advance uninvolved agenda. And class E >experimental status is inaccurate. And keeping that status serves >nobody, except those who believe it helps marshal efforts away from >IPv4. And that is top down. So, you would like to update RFC 1112, which defines and reserves Class E? That?s easy enough. If somebody had a use in mind for the space, anybody can write such a draft assigning space, which is, I believe, how to direct IANA to do something with it. If you want to direct IANA to distribute Class E space among the RIRs, there?s more process, because you would also have to develop a global policy (no problem, we get the NRO NC to write it and get consensus at all the RIRs), and then each RIR would need to develop a policy under which to allocate it. I?d be surprised if all that could happen in less than three years. In any of these processes, nothing will move forward until there is consensus, and I don?t think there?s consensus. If you think your argument can be persuasive, let?s write an internet-draft and get it into the process. Lee > >Joe > From Lee at asgard.org Thu Jul 16 17:05:51 2015 From: Lee at asgard.org (Lee Howard) Date: Thu, 16 Jul 2015 13:05:51 -0400 Subject: 'gray' market IPv4 In-Reply-To: <55A7E028.1070402@bryanfields.net> References: <4bigtbjkgkn42etyu804qne5.1436881147778@email.android.com> <5.1.1.6.2.20150714164629.002fdeb0@efes.iucc.ac.il> <55A7E028.1070402@bryanfields.net> Message-ID: On 7/16/15, 12:47 PM, "NANOG on behalf of Bryan Fields" wrote: >On 7/15/15 9:59 AM, Lee Howard wrote: >> Price varies significantly by prefix length, and somewhat by region. >> Regional variance may not be as much as it used to be. > >Does legacy space command a premium in this? >From what I understand, and I have not been a party to any transactions, there are differences in transaction where the space looks ?cleaner.? That is, space that has been less delegated, and has never appeared an a spam blacklist. I don?t know whether that translates to higher prices, or whether buyers just won?t buy questionable space. > >What's the going rate to lease space (say a /20 or /19 for discussion)? Leases aren?t worth the trouble, because sellers believe that the only reason for a temporary lease is to originate spam, following which the address space is worthless. So if you can find a lease at all, it is likely to cost as much or more than buying outright. Personally, I wouldn?t lease space at all, because I wouldn?t want my organization?s name anywhere near it when the bad stuff started happening. The ipv4auctions.com site lists prefixes that large; recent /20s have been $7.45-$8.00 per address. Bear in mind that I?m essentially a researcher, and have no direct experience. You might want to talk to a broker or three. Lee > >-- >Bryan Fields > >727-409-1194 - Voice >727-214-2508 - Fax >http://bryanfields.net > From alh-ietf at tndh.net Thu Jul 16 19:24:11 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 16 Jul 2015 12:24:11 -0700 Subject: Speaking of NTP... In-Reply-To: References: Message-ID: <048001d0bffc$fea25660$fbe70320$@tndh.net> I have had a consistent 10ms offset on a set of servers for the last 5 years. After extensive one-way tracing, it turns out there is a 20ms asymmetry "within" the Seattle Westin colo between HE & Comcast, causing all the IPv6 peers appearing over the HE tunnel to be 10ms offset from everything else. There may be other instances of indirect peering causing a static asymmetric path delay, and NTP will report that as an offset of half of the difference. Tony > -----Original Message----- > From: NANOG [mailto:nanog-bounces+alh-ietf=tndh.net at nanog.org] On > Behalf Of Rafael Possamai > Sent: Thursday, July 16, 2015 8:53 AM > To: Matthew Huff > Cc: nanog at nanog.org > Subject: Re: Speaking of NTP... > > Depending on how exactly you have these servers configured with relation > to one another, small variations from one single source can be augmented > down the line. > > https://en.wikipedia.org/wiki/Propagation_of_uncertainty > > > > On Mon, Jul 13, 2015 at 8:17 AM, Matthew Huff wrote: > > > We have 5 NTP server: 2 x stratum 1 rubidium oscillator time servers > > with GPS sync, and 3 servers running NTP 4.2.6p5-3 synced to external > > internet based NTP stratum 1 servers. We monitor our NTP environment > > closely, and over the last 10+ years, normally all of our NTP servers > > are sync'ed within > > +/- 2 msec. Starting last Friday, we started seeing some remote NTP > > +servers > > with GPS reference consistently offset by 10 msec. > > > > Any one else seeing this? > > > > ---- > > Matthew Huff | 1 Manhattanville Rd > > Director of Operations | Purchase, NY 10577 > > OTA Management LLC | Phone: 914-460-4039 > > aim: matthewbhuff | Fax: 914-694-5669 > > > > From mhuff at ox.com Thu Jul 16 19:43:41 2015 From: mhuff at ox.com (Matthew Huff) Date: Thu, 16 Jul 2015 19:43:41 +0000 Subject: Speaking of NTP... In-Reply-To: <048001d0bffc$fea25660$fbe70320$@tndh.net> References: <048001d0bffc$fea25660$fbe70320$@tndh.net> Message-ID: <71FC8C51-3F9B-4795-9AC5-5D3DD4A23D81@ox.com> Thanks. We have always had a few outliers, but we have never had a large number of external NTP have a consistent offset, and not one as big as 10ms. Something changed last Friday, probably at some peering point that caused the issue. Maybe a symmetric path got created to route around some outage. Maybe some MPLS circuit got introduced into the mix that hides the underlying path/latency. Glad to know someone else has seen something like this. Our 3 NTP servers that sync from external sources have at least 5 upstream stratum 1 servers and are peered to each other . They have settled on a sense of time that is good within +/i 1 msec of our strata 1 clocks, so all is good, but it was a stage occurrence after we had been good for so long. Each of our servers are clients of our 2 x strata 1 servers and 3 x strata 2 NTP servers. They all look good now. > On Jul 16, 2015, at 3:24 PM, Tony Hain wrote: > > I have had a consistent 10ms offset on a set of servers for the last 5 years. After extensive one-way tracing, it turns out there is a 20ms asymmetry "within" the Seattle Westin colo between HE & Comcast, causing all the IPv6 peers appearing over the HE tunnel to be 10ms offset from everything else. There may be other instances of indirect peering causing a static asymmetric path delay, and NTP will report that as an offset of half of the difference. > > Tony > > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces+alh-ietf=tndh.net at nanog.org] On >> Behalf Of Rafael Possamai >> Sent: Thursday, July 16, 2015 8:53 AM >> To: Matthew Huff >> Cc: nanog at nanog.org >> Subject: Re: Speaking of NTP... >> >> Depending on how exactly you have these servers configured with relation >> to one another, small variations from one single source can be augmented >> down the line. >> >> https://en.wikipedia.org/wiki/Propagation_of_uncertainty >> >> >> >> On Mon, Jul 13, 2015 at 8:17 AM, Matthew Huff wrote: >> >>> We have 5 NTP server: 2 x stratum 1 rubidium oscillator time servers >>> with GPS sync, and 3 servers running NTP 4.2.6p5-3 synced to external >>> internet based NTP stratum 1 servers. We monitor our NTP environment >>> closely, and over the last 10+ years, normally all of our NTP servers >>> are sync'ed within >>> +/- 2 msec. Starting last Friday, we started seeing some remote NTP >>> +servers >>> with GPS reference consistently offset by 10 msec. >>> >>> Any one else seeing this? >>> >>> ---- >>> Matthew Huff | 1 Manhattanville Rd >>> Director of Operations | Purchase, NY 10577 >>> OTA Management LLC | Phone: 914-460-4039 >>> aim: matthewbhuff | Fax: 914-694-5669 >>> >>> > From jmaimon at ttec.com Thu Jul 16 20:22:57 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 16 Jul 2015 16:22:57 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <55A71FFC.2090301@dougbarton.us> <55A7CCA4.2020002@ttec.com> Message-ID: <55A812A1.6020007@ttec.com> Jacques Latour wrote: > Hi, > > Dual stack is where we need to go 'now', but we need to think about the future where we run an IPv6 only stack and stop thinking how to leverage, extend, expand and create ugly IPv4 solutions. IPv4 is done; it served its purpose well, thank you. We need a date where IPv4 is no longer routed on the Internet. I am suggesting 4/4/2024. Whatever the timeline, we need to agree on the date and drive toward a common goal for a better Internet. > > My 2 Canadian cents :-) > > Jack > Just as nobody is preventing you from going ipv6 only right now, I advocate against hindering anybody going ipv4 only for as long as they want/can. You may not like the results, but that does not make a top down approach any better a choice. Joe From jmaimon at ttec.com Thu Jul 16 20:32:47 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 16 Jul 2015 16:32:47 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <55A71FFC.2090301@dougbarton.us> <55A7CCA4.2020002@ttec.com> Message-ID: <55A814EF.5080009@ttec.com> Lee Howard wrote: > > I don?t see anybody hindering any efforts; I don?t see any efforts. There were efforts in the past. I am highlighting our malfeasance as a community in our past behavior. I have little hope of it changing in the future, but I can vent about it every couple years or so. You take the un-initiated and explain to them the actual utilization percentage of the bitspace and then you explain why they should trust us with bitspace management the second time around. > > > So, you would like to update RFC 1112, which defines and reserves Class E? > That?s easy enough. If somebody had a use in mind for the space, anybody > can write such a draft assigning space, which is, I believe, how to > direct IANA to do something with it. > nope http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/ All the same rationals, including how it might be bad for ipv6, its too late, its too hard, its too little were trotted out then, just as now. The only use I have in mind for the space is for it to cease being classified as experimental and therefore treated as invalid. > If you want to direct IANA to distribute Class E space among the RIRs, > there?s more process, because you would also have to develop a global > policy (no problem, we get the NRO NC to write it and get consensus at > all the RIRs), and then each RIR would need to develop a policy under > which to allocate it. I?d be surprised if all that could happen in > less than three years. I would not care about that, so long as the impediment, the experimental status was removed. Let the stakeholders have a real shot. > > In any of these processes, nothing will move forward until there is > consensus, and I don?t think there?s consensus. If you think your > argument can be persuasive, let?s write an internet-draft and get it > into the process. > > Lee > >> >> Joe >> > > > > From marka at isc.org Thu Jul 16 21:21:46 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 17 Jul 2015 07:21:46 +1000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Thu, 16 Jul 2015 16:22:57 -0400." <55A812A1.6020007@ttec.com> References: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <55A71FFC.2090301@dougbarton.us> <55A7CCA4.2020002@ttec.com> <55A812A1.6020007@ttec.com > Message-ID: <20150716212146.9F67133397FB@rock.dv.isc.org> In message <55A812A1.6020007 at ttec.com>, Joe Maimon writes: > > > Jacques Latour wrote: > > Hi, > > > > Dual stack is where we need to go 'now', but we need to think about the fut > ure where we run an IPv6 only stack and stop thinking how to leverage, extend > , expand and create ugly IPv4 solutions. IPv4 is done; it served its purpose > well, thank you. We need a date where IPv4 is no longer routed on the Interne > t. I am suggesting 4/4/2024. Whatever the timeline, we need to agree on the d > ate and drive toward a common goal for a better Internet. > > > > My 2 Canadian cents :-) > > > > Jack > > > > Just as nobody is preventing you from going ipv6 only right now, I > advocate against hindering anybody going ipv4 only for as long as they > want/can. There is nothing stopping you experimenting with class E addresses behind a NAT. Talk to your vendors to lift the restrictions and route the packets as unicast packets. Note this really doesn't help with the global shortage. > You may not like the results, but that does not make a top down approach > any better a choice. Turning Class E into global unicast is nearly as big a project as getting IPv6 deployed everywhere. There is lots of equipement that can't make the jump. Even starting 15 years ago we would still not be in a good faith position to hand the addresses out to be used by anyone to talk to anyone. Both end boxes have to support it and all the routers in between have to support it. It's not just about being able to assign the address locally. Its about everything involed in the path being able to route to/from the addresses. Keeping IPv4 going longer required more publically routeable IPv4 space and class E was never it. > Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From chuckchurch at gmail.com Thu Jul 16 21:59:34 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Thu, 16 Jul 2015 17:59:34 -0400 Subject: IPv6 CPE best practices Message-ID: <02d301d0c012$b4f39130$1edab390$@gmail.com> So, I've been following this IPv6 discussion for a while now. Putting much more thought into it than ever before. What I've gathered so far: We need both SLAAC and DHPCv6 on CPE router to support all end clients. Android and some other platforms still have some issues with a v6-addressed DNS server (or don't use DHCPv6 at all), so you really need your v4-addressed DNS server to hand out both AAAA and A records together. Is that close? So giving each customer a /48 is the way to go. How does one go about configuring CPEs for devices to use this? I'm aware of how DHCP-PD can dish out a /48 of a larger block. Should I move to a standard CPE that supports DHCP-PD (here is a list: https://getipv6.info/display/IPv6/Broadband+CPE , some mention PD)? Or should I just allow them to use any IPv6 compatible router, and issue each customer a /48, but only configure a /64 of that block for each CPE's inside interface (manual config). Is there anything other than DHCP-PD that can do this auto-magically? I support a small WISP occasionally, it's all wireless and Ethernet. Several hundred small business customers. Nothing super complicated. Been playing with an HE tunnel the last few days and found my netflow collector works fine with FNF and IPv6, so making some progress. Just wanting to avoid any big mistakes when we think about getting some customers on it. Thanks, Chuck From johnl at iecc.com Thu Jul 16 22:17:23 2015 From: johnl at iecc.com (John Levine) Date: 16 Jul 2015 22:17:23 -0000 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A812A1.6020007@ttec.com> Message-ID: <20150716221723.33698.qmail@ary.lan> >Just as nobody is preventing you from going ipv6 only right now, I >advocate against hindering anybody going ipv4 only for as long as they >want/can. Nobody's hindering you. You can get NAT boxes of all shapes and sizes. If you want to mess around with class E addresses on your own network, go ahead, nobody's hindering you there, either. But you're asking other people to spend their own time and money to change their equipment to handle class E. For reasons discussed at length, no. If you're offering to pay their costs, on the other hand, ... R's, John From marka at isc.org Thu Jul 16 22:25:00 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 17 Jul 2015 08:25:00 +1000 Subject: IPv6 CPE best practices In-Reply-To: Your message of "Thu, 16 Jul 2015 17:59:34 -0400." <02d301d0c012$b4f39130$1edab390$@gmail.com> References: <02d301d0c012$b4f39130$1edab390$@gmail.com> Message-ID: <20150716222500.4FA8D333E843@rock.dv.isc.org> In message <02d301d0c012$b4f39130$1edab390$@gmail.com>, "Chuck Church" writes: > So, I've been following this IPv6 discussion for a while now. Putting much > more thought into it than ever before. What I've gathered so far: > > > > We need both SLAAC and DHPCv6 on CPE router to support all end clients. Yep. > Android and some other platforms still have some issues with a v6-addressed > DNS server (or don't use DHCPv6 at all), so you really need your > v4-addressed DNS server to hand out both AAAA and A records together. Is > that close? Only for really old clients or stupid clients that don't support both. DHCPv6 has supported handing out nameserver addresses for over a decade (2003) so all clients SHOULD support this. RDNSS was only defined in 2010. > So giving each customer a /48 is the way to go. How does one go about > configuring CPEs for devices to use this? I'm aware of how DHCP-PD can dish > out a /48 of a larger block. The DHCPv6 client on the upstream interface requests a PD. > Should I move to a standard CPE that supports > DHCP-PD (here is a list: https://getipv6.info/display/IPv6/Broadband+CPE , > some mention PD)? Or should I just allow them to use any IPv6 compatible > router, and issue each customer a /48, but only configure a /64 of that > block for each CPE's inside interface (manual config). Is there anything > other than DHCP-PD that can do this auto-magically? The CPE divides the /48 up for local use and further assignment via PD from its DHCP server. If there is a CPE to old to do this you may need to do manual assignment. Your DHCP server should be able to do both static and automatic PD. Also see the homenet IETF working group. It is working on providing a standard home route that does this and source/destination based routing so that homes can have multiple PA prefixes with traffic going out the correct exit. There are OpenWrt based routers that implement this today. Business class routers may not support fetching the prefix delegation via PD but they are usually paying you more. > I support a small WISP occasionally, it's all wireless and Ethernet. > Several hundred small business customers. Nothing super complicated. Been > playing with an HE tunnel the last few days and found my netflow collector > works fine with FNF and IPv6, so making some progress. Just wanting to > avoid any big mistakes when we think about getting some customers on it. > > > > Thanks, > > > > Chuck > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jmaimon at ttec.com Thu Jul 16 22:29:48 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 16 Jul 2015 18:29:48 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <20150716221723.33698.qmail@ary.lan> References: <20150716221723.33698.qmail@ary.lan> Message-ID: <55A8305C.10401@ttec.com> John Levine wrote: >> Just as nobody is preventing you from going ipv6 only right now, I >> advocate against hindering anybody going ipv4 only for as long as they >> want/can. > > But you're asking other people to spend their own time and money to > change their equipment to handle class E. For reasons discussed at > length, no. All I am advocating is that if ever another draft standard comes along to enable people to try and make something of it, lead follow or get out of the way. > > If you're offering to pay their costs, on the other hand, ... > > R's, > John > > From baldur.norddahl at gmail.com Thu Jul 16 22:57:38 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 17 Jul 2015 00:57:38 +0200 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A8305C.10401@ttec.com> References: <20150716221723.33698.qmail@ary.lan> <55A8305C.10401@ttec.com> Message-ID: On 17 July 2015 at 00:29, Joe Maimon wrote: > All I am advocating is that if ever another draft standard comes along to > enable people to try and make something of it, lead follow or get out of > the way. > If I understand correctly you want someone (not you) to write a RFC that changes the word "experimental" to "something else". But you do not want IANA and the 5 RIRs to implement policies to hand out this space. Nor do you expect any vendor to change anything? May i then suggest that "something else" could be "junk" or "useless" ? Fact is that it is junk. It is probably not even routable in the default free zone. Nobody is going to want a class E address. Even if your own equipment was updated to allow it, you would not be able to communicate with most of the internet. Tell me, in what timeframe do you expect that would change, if someone did write that RFC and got it approved? What everyone here is trying to tell you is that the consensus is that timeframe would be very long indeed. There are people using routers with 10+ year old firmware and you just wouldn't be able to communicate with these guys. There would be no transition plan. No NAT64, no dualstack nor any other mechanism that would save the day. Your customers would be very unhappy with your service. If YouTube had their servers on a class E address, my smart TV would stop being able to play YouTube. Samsung stopped making updates to that TV long ago. NAT wont do anything to help my TV as NAT only maps my internal network (192.168.x.y) and not the external IP (the class E address of say YouTube). Lets say we declare that 10 years has to pass and then it is my problem if I am still hanging onto such an old TV. But honestly, in 10 years nobody is going to care. It is all IPv6 by then. And the few things that are not is all taken care of by various transition technologies. You got it all wrong when you believe it is a top down decision. It is the opposite. You are fighting _consensus_. Nobody wants to change the status of class E because it would not work and would only confuse. Regards, Baldur From kmedcalf at dessus.com Thu Jul 16 22:47:21 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 16 Jul 2015 16:47:21 -0600 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150716150343.GB4261@bamboo.slabnet.com> Message-ID: Internet in a box. Wasn't that the Japanese thing with the Woody Woodpecker logo and the (translated) English text: "Touch Woody, the Internet pecker"? Didn't go over to well in English speaking parts as I recall ... From jfbeam at gmail.com Fri Jul 17 01:33:45 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 16 Jul 2015 21:33:45 -0400 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150716023244.80481333596E@rock.dv.isc.org> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716023244.80481333596E@rock.dv.isc.org> Message-ID: On Wed, 15 Jul 2015 22:32:19 -0400, Mark Andrews wrote: > You can blame the religious zealots that insisted that everything > DHCP does has to also be done via RA's. I blame the anti-DHCP crowd for a lot of things. RAs are just dumb. There's a reason IPv4 can do *everything* through DHCP -- hell, even boot menu lists are sent in dhcp pakcets. >> The XP box is in an even worse situation if you try to run it on a >> v6-only network. > > Which is fixable with a third party DHCPv6 client / manual configuration > of the nameservers. Just like no "IP stack" was fixable in the 80's. No. Just, No. There are millions upon millions of internet users I wouldn't trust to double click setup.exe. > None of which is the fault of the protocol. Actually, it's 100% the fault of the protocol. IPv6-only networking has been a cluster-f*** from day one. And it still doesn't f'ing work today. Until there is *A* standard to implement, that stands still for more than an hour before something else "critical" gets bolted on to it, people are going to continue to ignore IPv6. Yes, my XP machines work fine with IPv6... on a network using SLAAC, where IPv4 (DHCPv4) is still enabled and providing the various bits necessary to do anything other than ping my gateway. From dave-nanog at pooserville.com Fri Jul 17 02:37:58 2015 From: dave-nanog at pooserville.com (Dave Pooser) Date: Thu, 16 Jul 2015 21:37:58 -0500 Subject: Remember "Internet-In-A-Box"? In-Reply-To: References: <20150716150343.GB4261@bamboo.slabnet.com> Message-ID: >Internet in a box. > >Wasn't that the Japanese thing with the Woody Woodpecker logo and the >(translated) English text: "Touch Woody, the Internet pecker"? > >Didn't go over to well in English speaking parts as I recall ... But it eventually evolved into ChatRoulette. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com From Valdis.Kletnieks at vt.edu Fri Jul 17 03:16:27 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 16 Jul 2015 23:16:27 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Thu, 16 Jul 2015 18:29:48 -0400." <55A8305C.10401@ttec.com> References: <20150716221723.33698.qmail@ary.lan> <55A8305C.10401@ttec.com> Message-ID: <126210.1437102987@turing-police.cc.vt.edu> On Thu, 16 Jul 2015 18:29:48 -0400, Joe Maimon said: > All I am advocating is that if ever another draft standard comes along > to enable people to try and make something of it, lead follow or get out > of the way. The problem is that if everybody gets out of the way and doesn't follow, your class E address is still *worthless*, because only "lead" and "follow" result in people updating their gear to support it. As I sit here: traceroute -A www.ttec.com traceroute to www.ttec.com (216.222.148.100), 30 hops max, 60 byte packets 1 gateway (172.30.42.65) [*] 1.572 ms 1.942 ms 3.574 ms 2 73.171.122.1 (73.171.122.1) [AS7922] 12.148 ms 17.771 ms 18.312 ms 3 68.86.127.121 (68.86.127.121) [AS7922] 16.262 ms 21.193 ms 22.037 ms 4 ae-18-0-ar02.charlvilleco.va.richmond.comcast.net (68.86.173.213) [AS7922] 40.610 ms 27.332 ms 27.655 ms 5 he-1-1-0-0-10-cr02.ashburn.va.ibone.comcast.net (68.86.91.53) [AS7922] 34.854 ms he-1-1-0-3-11-cr02.ashburn.va.ibone.comcast.net (68.86.94.21) [AS7922] 36.627 ms he-1-1-0-1-11-cr02.ashburn.va.ibone.comcast.net (68.86.95.69) [AS7922] 33.868 ms 6 he-0-10-0-1-pe07.ashburn.va.ibone.comcast.net (68.86.83.70) [AS7922] 32.243 ms 16.216 ms 27.123 ms 7 50-248-119-82-static.hfc.comcastbusiness.net (50.248.119.82) [AS7922] 27.405 ms 33.886 ms 43.109 ms 8 100ge5-1.core1.nyc4.he.net (184.105.223.166) [AS6939] 36.571 ms 37.881 ms 37.290 ms 9 209.51.164.26 (209.51.164.26) [AS6939] 40.093 ms 209.51.164.27 (209.51.164.27) [AS6939] 38.234 ms 209.51.164.26 (209.51.164.26) [AS6939] 38.647 ms 10 noc08rt08-p1-16.noc08.chl.net (216.222.144.33) [AS21719] 46.120 ms 46.462 ms 42.743 ms 11 * * * 12 webserver.ntcnct.net (216.222.148.100) [AS21719] 33.937 ms 28.058 ms 30.344 ms You're on the hook for 3 boxes. Can you get the software vendors for all three to *not* be in "get out of the way"? (Remember how many years a lot of vendors spent playing "get out of the way" on IPv6 support, and how many are still doing it *now*...) Oh, and don't forget whatever webserver software and web authoring/management software... And the 9 boxes in between apparently belong to Comcast and HE, both of which have drunk the IPv6 koolaid. What's the business case for them to add Class E support to their networks? Yeah. There's a whole lot of motivation to get out of the way here, because most of the path thinks IPv6 is the right answer, and not much business case for any of the companies or vendors to either lead or follow on a class E repurposing... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Lee at asgard.org Fri Jul 17 03:50:23 2015 From: Lee at asgard.org (Lee Howard) Date: Thu, 16 Jul 2015 23:50:23 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A814EF.5080009@ttec.com> References: <1b2903db305f4e1fa65400b0743397bd@pur-vm-exch13n1.ox.com> <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <55A71FFC.2090301@dougbarton.us> <55A7CCA4.2020002@ttec.com> <55A814EF.5080009@ttec.com> Message-ID: On 7/16/15, 4:32 PM, "Joe Maimon" wrote: > > >Lee Howard wrote: >> >> So, you would like to update RFC 1112, which defines and reserves Class >>E? >> That?s easy enough. If somebody had a use in mind for the space, anybody >> can write such a draft assigning space, which is, I believe, how to >> direct IANA to do something with it. >> > >nope ?Nope?? You mean you don?t want to update RFC1112? Or it?s not possible for somebody to write a draft telling IANA to assign space for an experiment? Somebody has to write a draft in order for the IETF to consider it, and there has to be IETF consensus for it to get published as an RFC. > >http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e- >addresses/ > >All the same rationals, including how it might be bad for ipv6, its too >late, its too hard, its too little were trotted out then, just as now. I don?t see the relevance. Nobody there proposed reclassifying the space. Nobody had a proposal for an experiment. Nobody wanted an assignment from it. > >The only use I have in mind for the space is for it to cease being >classified as experimental and therefore treated as invalid. You want the word ?RESERVED? for some entries on this page changed: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml What do you want it changed to? > >> If you want to direct IANA to distribute Class E space among the RIRs, >> there?s more process, because you would also have to develop a global >> policy (no problem, we get the NRO NC to write it and get consensus at >> all the RIRs), and then each RIR would need to develop a policy under >> which to allocate it. I?d be surprised if all that could happen in >> less than three years. > >I would not care about that, so long as the impediment, the experimental >status was removed. Let the stakeholders have a real shot. There?s more to it than that. How would people who want to use it get assignments? Right now, there?s no policy for assigning that space. You?ve told other people that there shouldn?t be a top-down restriction on this space; but there?s no top: it?s all consensus. The consensus here is very clear. You are welcome to try to change it, and a couple of us are trying to should you the processes (IETF, IANA, RIR) to do that. If all you want to do is vent, we?ll just move on to another thread. Lee From owen at delong.com Fri Jul 17 04:18:48 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Jul 2015 21:18:48 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A8305C.10401@ttec.com> References: <20150716221723.33698.qmail@ary.lan> <55A8305C.10401@ttec.com> Message-ID: <45DA2851-60BD-41F2-8B62-36A9427D3C3E@delong.com> > On Jul 16, 2015, at 15:29 , Joe Maimon wrote: > > > > John Levine wrote: >>> Just as nobody is preventing you from going ipv6 only right now, I >>> advocate against hindering anybody going ipv4 only for as long as they >>> want/can. > > > >> >> But you're asking other people to spend their own time and money to >> change their equipment to handle class E. For reasons discussed at >> length, no. > > All I am advocating is that if ever another draft standard comes along to enable people to try and make something of it, lead follow or get out of the way. Sometimes good leadership is knowing when to say ?not just no, but hell no.? Owen From jj at anexia.at Fri Jul 17 06:15:36 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 17 Jul 2015 06:15:36 +0000 Subject: Prefix-Hijack by AS7514 Message-ID: <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 .... Thanks & best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 From hslabbert at stargate.ca Fri Jul 17 06:22:38 2015 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Thu, 16 Jul 2015 23:22:38 -0700 Subject: Prefix-Hijack by AS7514 In-Reply-To: <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> References: <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> Message-ID: <20150717062238.GI22020@stargate.ca> Seeing the same; a /19. BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497. -- Hugo Slabbert Stargate Connections - AS19171 -----Original Message----- >Date: Fri, 17 Jul 2015 06:15:36 +0000 >From: J?rgen Jaritsch >To: "'nanog at nanog.org'" >Subject: Prefix-Hijack by AS7514 > >Hi, > >does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 .... > > >Thanks & best regards > >J?rgen Jaritsch >Head of Network & Infrastructure > >ANEXIA Internetdienstleistungs GmbH > >Telefon: +43-5-0556-300 >Telefax: +43-5-0556-500 > >E-Mail: jj at anexia.at >Web: http://www.anexia.at > >Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >Gesch?ftsf?hrer: Alexander Windbichler >Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > From jj at anexia.at Fri Jul 17 06:23:30 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 17 Jul 2015 06:23:30 +0000 Subject: AW: Prefix-Hijack by AS7514 In-Reply-To: <20150717062238.GI22020@stargate.ca> References: <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> <20150717062238.GI22020@stargate.ca> Message-ID: We already informed AS2497 but I have no idea if they we'll cooperate. Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: Hugo Slabbert [mailto:hslabbert at stargate.ca] Gesendet: Freitag, 17. Juli 2015 08:23 An: J?rgen Jaritsch Cc: 'nanog at nanog.org' Betreff: Re: Prefix-Hijack by AS7514 Seeing the same; a /19. BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497. -- Hugo Slabbert Stargate Connections - AS19171 -----Original Message----- >Date: Fri, 17 Jul 2015 06:15:36 +0000 >From: J?rgen Jaritsch >To: "'nanog at nanog.org'" >Subject: Prefix-Hijack by AS7514 > >Hi, > >does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 .... > > >Thanks & best regards > >J?rgen Jaritsch >Head of Network & Infrastructure > >ANEXIA Internetdienstleistungs GmbH > >Telefon: +43-5-0556-300 >Telefax: +43-5-0556-500 > >E-Mail: jj at anexia.at >Web: http://www.anexia.at > >Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >Gesch?ftsf?hrer: Alexander Windbichler >Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > From hank at efes.iucc.ac.il Fri Jul 17 06:23:47 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 17 Jul 2015 09:23:47 +0300 Subject: Prefix-Hijack by AS7514 In-Reply-To: <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> Message-ID: <5.1.1.6.2.20150717092337.04964340@efes.iucc.ac.il> At 06:15 17/07/2015 +0000, J?rgen Jaritsch wrote: >Hi, > >does anyone else see some prefix hijacks from AS7514? They started to >announce some of our /24 .... Worldwide. -Hank >Thanks & best regards > >J?rgen Jaritsch >Head of Network & Infrastructure > >ANEXIA Internetdienstleistungs GmbH > >Telefon: +43-5-0556-300 >Telefax: +43-5-0556-500 > >E-Mail: jj at anexia.at >Web: http://www.anexia.at > >Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >Gesch?ftsf?hrer: Alexander Windbichler >Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 From kawamucho at mesh.ad.jp Fri Jul 17 06:29:29 2015 From: kawamucho at mesh.ad.jp (Seiichi Kawamura) Date: Fri, 17 Jul 2015 15:29:29 +0900 Subject: AW: Prefix-Hijack by AS7514 In-Reply-To: References: <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> <20150717062238.GI22020@stargate.ca> Message-ID: <55A8A0C9.7050808@mesh.ad.jp> I contacted 7514. They are aware. -Seiichi On 2015/07/17 15:23, J?rgen Jaritsch wrote: > We already informed AS2497 but I have no idea if they we'll cooperate. > > > Best regards > > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > -----Urspr?ngliche Nachricht----- > Von: Hugo Slabbert [mailto:hslabbert at stargate.ca] > Gesendet: Freitag, 17. Juli 2015 08:23 > An: J?rgen Jaritsch > Cc: 'nanog at nanog.org' > Betreff: Re: Prefix-Hijack by AS7514 > > Seeing the same; a /19. > > BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being > accepted by 2497. > > -- > Hugo Slabbert > Stargate Connections - AS19171 > > -----Original Message----- >> Date: Fri, 17 Jul 2015 06:15:36 +0000 >> From: J?rgen Jaritsch >> To: "'nanog at nanog.org'" >> Subject: Prefix-Hijack by AS7514 >> >> Hi, >> >> does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 .... >> >> >> Thanks & best regards >> >> J?rgen Jaritsch >> Head of Network & Infrastructure >> >> ANEXIA Internetdienstleistungs GmbH >> >> Telefon: +43-5-0556-300 >> Telefax: +43-5-0556-500 >> >> E-Mail: jj at anexia.at >> Web: http://www.anexia.at >> >> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >> Gesch?ftsf?hrer: Alexander Windbichler >> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 >> > From jj at anexia.at Fri Jul 17 06:30:33 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 17 Jul 2015 06:30:33 +0000 Subject: AW: AW: Prefix-Hijack by AS7514 In-Reply-To: <55A8A0C9.7050808@mesh.ad.jp> References: <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> <20150717062238.GI22020@stargate.ca> <55A8A0C9.7050808@mesh.ad.jp> Message-ID: Hi, we also sent them an mail, but their MX is not reachable for us :( best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: Seiichi Kawamura [mailto:kawamucho at mesh.ad.jp] Gesendet: Freitag, 17. Juli 2015 08:29 An: J?rgen Jaritsch ; Hugo Slabbert Cc: 'nanog at nanog.org' Betreff: Re: AW: Prefix-Hijack by AS7514 I contacted 7514. They are aware. -Seiichi On 2015/07/17 15:23, J?rgen Jaritsch wrote: > We already informed AS2497 but I have no idea if they we'll cooperate. > > > Best regards > > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > -----Urspr?ngliche Nachricht----- > Von: Hugo Slabbert [mailto:hslabbert at stargate.ca] > Gesendet: Freitag, 17. Juli 2015 08:23 > An: J?rgen Jaritsch > Cc: 'nanog at nanog.org' > Betreff: Re: Prefix-Hijack by AS7514 > > Seeing the same; a /19. > > BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being > accepted by 2497. > > -- > Hugo Slabbert > Stargate Connections - AS19171 > > -----Original Message----- >> Date: Fri, 17 Jul 2015 06:15:36 +0000 >> From: J?rgen Jaritsch >> To: "'nanog at nanog.org'" >> Subject: Prefix-Hijack by AS7514 >> >> Hi, >> >> does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 .... >> >> >> Thanks & best regards >> >> J?rgen Jaritsch >> Head of Network & Infrastructure >> >> ANEXIA Internetdienstleistungs GmbH >> >> Telefon: +43-5-0556-300 >> Telefax: +43-5-0556-500 >> >> E-Mail: jj at anexia.at >> Web: http://www.anexia.at >> >> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >> Gesch?ftsf?hrer: Alexander Windbichler >> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 >> > From hank at efes.iucc.ac.il Fri Jul 17 06:33:03 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 17 Jul 2015 09:33:03 +0300 Subject: AW: Prefix-Hijack by AS7514 In-Reply-To: References: <20150717062238.GI22020@stargate.ca> <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> <20150717062238.GI22020@stargate.ca> Message-ID: <5.1.1.6.2.20150717093146.0495ceb8@efes.iucc.ac.il> At 06:23 17/07/2015 +0000, J?rgen Jaritsch wrote: >We already informed AS2497 but I have no idea if they we'll cooperate. All prefixes I see have the first octet as being 2 digits rather than 3. That is common among about 30 different alerts I have received. Curious if this is common worldwide. -Hank >Best regards > > >J?rgen Jaritsch >Head of Network & Infrastructure > >ANEXIA Internetdienstleistungs GmbH > >Telefon: +43-5-0556-300 >Telefax: +43-5-0556-500 > >E-Mail: jj at anexia.at >Web: http://www.anexia.at > >Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >Gesch?ftsf?hrer: Alexander Windbichler >Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > >-----Urspr?ngliche Nachricht----- >Von: Hugo Slabbert [mailto:hslabbert at stargate.ca] >Gesendet: Freitag, 17. Juli 2015 08:23 >An: J?rgen Jaritsch >Cc: 'nanog at nanog.org' >Betreff: Re: Prefix-Hijack by AS7514 > >Seeing the same; a /19. > >BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being >accepted by 2497. > >-- >Hugo Slabbert >Stargate Connections - AS19171 > >-----Original Message----- > >Date: Fri, 17 Jul 2015 06:15:36 +0000 > >From: J?rgen Jaritsch > >To: "'nanog at nanog.org'" > >Subject: Prefix-Hijack by AS7514 > > > >Hi, > > > >does anyone else see some prefix hijacks from AS7514? They started to > announce some of our /24 .... > > > > > >Thanks & best regards > > > >J?rgen Jaritsch > >Head of Network & Infrastructure > > > >ANEXIA Internetdienstleistungs GmbH > > > >Telefon: +43-5-0556-300 > >Telefax: +43-5-0556-500 > > > >E-Mail: jj at anexia.at > >Web: http://www.anexia.at > > > >Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > >Gesch?ftsf?hrer: Alexander Windbichler > >Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT > U63216601 > > From jj at anexia.at Fri Jul 17 06:35:37 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 17 Jul 2015 06:35:37 +0000 Subject: AW: AW: Prefix-Hijack by AS7514 In-Reply-To: <5.1.1.6.2.20150717093146.0495ceb8@efes.iucc.ac.il> References: <20150717062238.GI22020@stargate.ca> <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> <20150717062238.GI22020@stargate.ca> <5.1.1.6.2.20150717093146.0495ceb8@efes.iucc.ac.il> Message-ID: Hi, all affected prefixes starts with 37... no other prefixes from AS42473 are affected. Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: Hank Nussbacher [mailto:hank at efes.iucc.ac.il] Gesendet: Freitag, 17. Juli 2015 08:33 An: J?rgen Jaritsch ; Hugo Slabbert Cc: 'nanog at nanog.org' Betreff: Re: AW: Prefix-Hijack by AS7514 At 06:23 17/07/2015 +0000, J?rgen Jaritsch wrote: >We already informed AS2497 but I have no idea if they we'll cooperate. All prefixes I see have the first octet as being 2 digits rather than 3. That is common among about 30 different alerts I have received. Curious if this is common worldwide. -Hank >Best regards > > >J?rgen Jaritsch >Head of Network & Infrastructure > >ANEXIA Internetdienstleistungs GmbH > >Telefon: +43-5-0556-300 >Telefax: +43-5-0556-500 > >E-Mail: jj at anexia.at >Web: http://www.anexia.at > >Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >Gesch?ftsf?hrer: Alexander Windbichler >Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > >-----Urspr?ngliche Nachricht----- >Von: Hugo Slabbert [mailto:hslabbert at stargate.ca] >Gesendet: Freitag, 17. Juli 2015 08:23 >An: J?rgen Jaritsch >Cc: 'nanog at nanog.org' >Betreff: Re: Prefix-Hijack by AS7514 > >Seeing the same; a /19. > >BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being >accepted by 2497. > >-- >Hugo Slabbert >Stargate Connections - AS19171 > >-----Original Message----- > >Date: Fri, 17 Jul 2015 06:15:36 +0000 > >From: J?rgen Jaritsch > >To: "'nanog at nanog.org'" > >Subject: Prefix-Hijack by AS7514 > > > >Hi, > > > >does anyone else see some prefix hijacks from AS7514? They started to > announce some of our /24 .... > > > > > >Thanks & best regards > > > >J?rgen Jaritsch > >Head of Network & Infrastructure > > > >ANEXIA Internetdienstleistungs GmbH > > > >Telefon: +43-5-0556-300 > >Telefax: +43-5-0556-500 > > > >E-Mail: jj at anexia.at > >Web: http://www.anexia.at > > > >Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > >Gesch?ftsf?hrer: Alexander Windbichler > >Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT > U63216601 > > From contact at winterei.se Fri Jul 17 06:38:13 2015 From: contact at winterei.se (Paul S.) Date: Fri, 17 Jul 2015 15:38:13 +0900 Subject: AW: AW: Prefix-Hijack by AS7514 In-Reply-To: References: <0d9a8105fce244478bd2c22afe10e988@anx-i-dag02.anx.local> <20150717062238.GI22020@stargate.ca> <55A8A0C9.7050808@mesh.ad.jp> Message-ID: <55A8A2D5.20809@winterei.se> I let IIJ know too, hopefully they'll filter it soon. On 7/17/2015 ?? 03:30, J?rgen Jaritsch wrote: > Hi, > > we also sent them an mail, but their MX is not reachable for us :( > > > best regards > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > -----Urspr?ngliche Nachricht----- > Von: Seiichi Kawamura [mailto:kawamucho at mesh.ad.jp] > Gesendet: Freitag, 17. Juli 2015 08:29 > An: J?rgen Jaritsch ; Hugo Slabbert > Cc: 'nanog at nanog.org' > Betreff: Re: AW: Prefix-Hijack by AS7514 > > I contacted 7514. They are aware. > > -Seiichi > > On 2015/07/17 15:23, J?rgen Jaritsch wrote: >> We already informed AS2497 but I have no idea if they we'll cooperate. >> >> >> Best regards >> >> >> J?rgen Jaritsch >> Head of Network & Infrastructure >> >> ANEXIA Internetdienstleistungs GmbH >> >> Telefon: +43-5-0556-300 >> Telefax: +43-5-0556-500 >> >> E-Mail: jj at anexia.at >> Web: http://www.anexia.at >> >> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >> Gesch?ftsf?hrer: Alexander Windbichler >> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 >> >> -----Urspr?ngliche Nachricht----- >> Von: Hugo Slabbert [mailto:hslabbert at stargate.ca] >> Gesendet: Freitag, 17. Juli 2015 08:23 >> An: J?rgen Jaritsch >> Cc: 'nanog at nanog.org' >> Betreff: Re: Prefix-Hijack by AS7514 >> >> Seeing the same; a /19. >> >> BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being >> accepted by 2497. >> >> -- >> Hugo Slabbert >> Stargate Connections - AS19171 >> >> -----Original Message----- >>> Date: Fri, 17 Jul 2015 06:15:36 +0000 >>> From: J?rgen Jaritsch >>> To: "'nanog at nanog.org'" >>> Subject: Prefix-Hijack by AS7514 >>> >>> Hi, >>> >>> does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 .... >>> >>> >>> Thanks & best regards >>> >>> J?rgen Jaritsch >>> Head of Network & Infrastructure >>> >>> ANEXIA Internetdienstleistungs GmbH >>> >>> Telefon: +43-5-0556-300 >>> Telefax: +43-5-0556-500 >>> >>> E-Mail: jj at anexia.at >>> Web: http://www.anexia.at >>> >>> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >>> Gesch?ftsf?hrer: Alexander Windbichler >>> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 >>> From jared at compuwizz.net Fri Jul 17 06:52:50 2015 From: jared at compuwizz.net (Jared Geiger) Date: Thu, 16 Jul 2015 23:52:50 -0700 Subject: ISP in NYC In-Reply-To: References: Message-ID: HE uses Telia for Transit. So you won't gain much redundancy there. I would go with Cogent if you have lots of European customers and North American business customers. One not on your list is Level3. They would be strong in that blend too. You might also try joining a peering point. You'll gain a lot by just peering with the route servers. On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender wrote: > Hi, > > We are looking to peer with another ISP in NY. My options are: > Telia > Tata > Cogent > > We currently have (and will keep): > HE > NTT > TELX (They use NTT and HE and we are looking to replace them). > > We need an ISP that has a good peering/connectivity in Europe and Asia > (Israel specific). > > Any advice on who to go with? > From colinj at gt86car.org.uk Fri Jul 17 07:06:30 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 17 Jul 2015 08:06:30 +0100 Subject: ISP in NYC In-Reply-To: References: Message-ID: <2A3E401F-D247-4B3B-AAAE-B999C95C5DAD@gt86car.org.uk> good isp's / peers are in no particular order bt telstra ex psinet uk/eu colin Sent from my iPhone > On 17 Jul 2015, at 07:52, Jared Geiger wrote: > > HE uses Telia for Transit. So you won't gain much redundancy there. I would > go with Cogent if you have lots of European customers and North American > business customers. One not on your list is Level3. They would be strong in > that blend too. > > You might also try joining a peering point. You'll gain a lot by just > peering with the route servers. > >> On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender wrote: >> >> Hi, >> >> We are looking to peer with another ISP in NY. My options are: >> Telia >> Tata >> Cogent >> >> We currently have (and will keep): >> HE >> NTT >> TELX (They use NTT and HE and we are looking to replace them). >> >> We need an ISP that has a good peering/connectivity in Europe and Asia >> (Israel specific). >> >> Any advice on who to go with? >> From alh-ietf at tndh.net Fri Jul 17 07:07:59 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 17 Jul 2015 00:07:59 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716023244.80481333596E@rock.dv.isc.org> Message-ID: <04b701d0c05f$509e92a0$f1dbb7e0$@tndh.net> Ricky Beamwrote: > On Wed, 15 Jul 2015 22:32:19 -0400, Mark Andrews wrote: > > You can blame the religious zealots that insisted that everything DHCP > > does has to also be done via RA's. > > I blame the anti-DHCP crowd for a lot of things. RAs are just dumb. > There's a reason IPv4 can do *everything* through DHCP -- hell, even boot > menu lists are sent in dhcp pakcets. The reason is that DHC was the longest lived working group in IETF history. It took over 15 years of changes to get what you consider a working implementation. At the point the IPv6 RA was specified, it was very difficult for people to get addressing and routers consistently configured via dhcp, let alone everything else that was added. > > >> The XP box is in an even worse situation if you try to run it on a > >> v6-only network. > > > > Which is fixable with a third party DHCPv6 client / manual > > configuration of the nameservers. > > Just like no "IP stack" was fixable in the 80's. No. Just, No. There are millions > upon millions of internet users I wouldn't trust to double click setup.exe. > > > None of which is the fault of the protocol. > > Actually, it's 100% the fault of the protocol. IPv6-only networking has been a > cluster-f*** from day one. And it still doesn't f'ing work today. > Until there is *A* standard to implement, that stands still for more than an > hour before something else "critical" gets bolted on to it, people are going > to continue to ignore IPv6. So if you want to wait for a stable specification, why did you ever implement IPv4? Here we are 35+ years later and there are still changes to the base IPv4 header in the works. http://tools.ietf.org/rfcmarkup?doc=draft-dreibholz-ipv4-flowlabel How could anyone ever implement a target that has continued to move for that long a period? With over 5,000 documents describing the continuous changes to IPv4, there is obviously "A standard to implement" in there somewhere. Clearly some people have figured out how to deploy IPv6, but if you want to wait, that is your choice. > > Yes, my XP machines work fine with IPv6... on a network using SLAAC, > where > IPv4 (DHCPv4) is still enabled and providing the various bits necessary to do > anything other than ping my gateway. The XP implementation was never expected to last as long as it did, The delay in shipping the Vista/W7 stack resulted in quite a bit of functionality being late. The entire point of the XP implementation was to put a working API in the hands of app developers. It was never intended to be used in IPv6-only networks 15 years after its release. Tony From contact at winterei.se Fri Jul 17 07:20:31 2015 From: contact at winterei.se (Paul S.) Date: Fri, 17 Jul 2015 16:20:31 +0900 Subject: ISP in NYC In-Reply-To: <2A3E401F-D247-4B3B-AAAE-B999C95C5DAD@gt86car.org.uk> References: <2A3E401F-D247-4B3B-AAAE-B999C95C5DAD@gt86car.org.uk> Message-ID: <55A8ACBF.2010102@winterei.se> Rather than a peer, it might be an okay idea to try out peering at NYIIX (and if the funds permit to get transport, AMS-IX/DE-CIX). You'll quickly find that peering is *very* useful in Europe, if you have any EU bound traffic at all. On 7/17/2015 ?? 04:06, Colin Johnston wrote: > good isp's / peers are in no particular order > bt > telstra ex psinet uk/eu > > colin > > Sent from my iPhone > >> On 17 Jul 2015, at 07:52, Jared Geiger wrote: >> >> HE uses Telia for Transit. So you won't gain much redundancy there. I would >> go with Cogent if you have lots of European customers and North American >> business customers. One not on your list is Level3. They would be strong in >> that blend too. >> >> You might also try joining a peering point. You'll gain a lot by just >> peering with the route servers. >> >>> On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender wrote: >>> >>> Hi, >>> >>> We are looking to peer with another ISP in NY. My options are: >>> Telia >>> Tata >>> Cogent >>> >>> We currently have (and will keep): >>> HE >>> NTT >>> TELX (They use NTT and HE and we are looking to replace them). >>> >>> We need an ISP that has a good peering/connectivity in Europe and Asia >>> (Israel specific). >>> >>> Any advice on who to go with? >>> From magicsata at gmail.com Fri Jul 17 07:40:53 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Fri, 17 Jul 2015 08:40:53 +0100 Subject: ISP in NYC In-Reply-To: <55A8ACBF.2010102@winterei.se> References: <2A3E401F-D247-4B3B-AAAE-B999C95C5DAD@gt86car.org.uk> <55A8ACBF.2010102@winterei.se> Message-ID: Hibernia (5580) have good latency throughout Europe and are huge on AMS-IX. Latency is around 18ms from Edinburgh to Amsterdam and 5ms from London via their network. Used them for transit and they gave me a circuit onto AMS-IX too which could be worth you looking into. Between the route servers and peers on the exchange I was getting ~210k routes. On 17 Jul 2015 08:22, "Paul S." wrote: > Rather than a peer, it might be an okay idea to try out peering at NYIIX > (and if the funds permit to get transport, AMS-IX/DE-CIX). > > You'll quickly find that peering is *very* useful in Europe, if you have > any EU bound traffic at all. > > On 7/17/2015 ?? 04:06, Colin Johnston wrote: > >> good isp's / peers are in no particular order >> bt >> telstra ex psinet uk/eu >> >> colin >> >> Sent from my iPhone >> >> On 17 Jul 2015, at 07:52, Jared Geiger wrote: >>> >>> HE uses Telia for Transit. So you won't gain much redundancy there. I >>> would >>> go with Cogent if you have lots of European customers and North American >>> business customers. One not on your list is Level3. They would be strong >>> in >>> that blend too. >>> >>> You might also try joining a peering point. You'll gain a lot by just >>> peering with the route servers. >>> >>> On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender >>>> wrote: >>>> >>>> Hi, >>>> >>>> We are looking to peer with another ISP in NY. My options are: >>>> Telia >>>> Tata >>>> Cogent >>>> >>>> We currently have (and will keep): >>>> HE >>>> NTT >>>> TELX (They use NTT and HE and we are looking to replace them). >>>> >>>> We need an ISP that has a good peering/connectivity in Europe and Asia >>>> (Israel specific). >>>> >>>> Any advice on who to go with? >>>> >>>> > From randy at psg.com Fri Jul 17 08:14:35 2015 From: randy at psg.com (Randy Bush) Date: Fri, 17 Jul 2015 10:14:35 +0200 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> Message-ID: many web sites are gonna have to upgrade ciphers and get rid of flash. this will take vastly longer than prudence would dictate. randy From outsider at scarynet.org Fri Jul 17 08:26:22 2015 From: outsider at scarynet.org (Alexander Maassen) Date: Fri, 17 Jul 2015 10:26:22 +0200 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> Message-ID: <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> Well, this block also affects people who have old management hardware around using such ciphers that are for example no longer supported. In my case for example the old Dell DRAC's. And it seems there is no way to disable this block. Ok, it is good to think about security, but not giving you any chance to make exceptions is simply forcing users to use another browser in order to manage those devices, or to keep an old machine around that not gets updated. On Fri, July 17, 2015 10:14 am, Randy Bush wrote: > many web sites are gonna have to upgrade ciphers and get rid of flash. > this will take vastly longer than prudence would dictate. > > randy > From maz at iij.ad.jp Fri Jul 17 08:32:11 2015 From: maz at iij.ad.jp (Matsuzaki Yoshinobu) Date: Fri, 17 Jul 2015 17:32:11 +0900 (JST) Subject: AW: AW: Prefix-Hijack by AS7514 In-Reply-To: <55A8A2D5.20809@winterei.se> References: <55A8A0C9.7050808@mesh.ad.jp> <55A8A2D5.20809@winterei.se> Message-ID: <20150717.173211.1827498141128697853.maz@iij.ad.jp> Date: Fri, 17 Jul 2015 15:38:13 +0900 "Paul S." wrote > I let IIJ know too, hopefully they'll filter it soon. It seems AS7514 stopped the announcements around 06:54UTC. I am not sure how BGPmon guesses AS relationships, but it needs improvements as it shows IIJ as an upstream of AS7514 wrongly. ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 From colinj at gt86car.org.uk Fri Jul 17 08:44:48 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 17 Jul 2015 09:44:48 +0100 Subject: AW: AW: Prefix-Hijack by AS7514 In-Reply-To: <20150717.173211.1827498141128697853.maz@iij.ad.jp> References: <55A8A0C9.7050808@mesh.ad.jp> <55A8A2D5.20809@winterei.se> <20150717.173211.1827498141128697853.maz@iij.ad.jp> Message-ID: any idea why error happened ? what config needs fixing to mitigate mistake? it was easy to see problem via ripe atlas :) colin Sent from my iPhone > On 17 Jul 2015, at 09:32, Matsuzaki Yoshinobu wrote: > > Date: Fri, 17 Jul 2015 15:38:13 +0900 > "Paul S." wrote >> I let IIJ know too, hopefully they'll filter it soon. > > It seems AS7514 stopped the announcements around 06:54UTC. > > I am not sure how BGPmon guesses AS relationships, but it needs > improvements as it shows IIJ as an upstream of AS7514 wrongly. > ----- > Matsuzaki Yoshinobu > - IIJ/AS2497 INOC-DBA: 2497*629 From maz at iij.ad.jp Fri Jul 17 08:55:53 2015 From: maz at iij.ad.jp (Matsuzaki Yoshinobu) Date: Fri, 17 Jul 2015 17:55:53 +0900 (JST) Subject: AW: AW: Prefix-Hijack by AS7514 In-Reply-To: References: <55A8A2D5.20809@winterei.se> <20150717.173211.1827498141128697853.maz@iij.ad.jp> Message-ID: <20150717.175553.1297824131323484151.maz@iij.ad.jp> Colin Johnston wrote > any idea why error happened ? > what config needs fixing to mitigate mistake? > it was easy to see problem via ripe atlas :) I just got brief explanation from a friend in AS7514. A router in their network suddenly went out of control, and it seems this somehow generated wrong routing information. They solved the issue by disconnecting the router and are now investigating it. ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 From colinj at gt86car.org.uk Fri Jul 17 09:17:23 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 17 Jul 2015 10:17:23 +0100 Subject: AW: AW: Prefix-Hijack by AS7514 In-Reply-To: <20150717.175553.1297824131323484151.maz@iij.ad.jp> References: <55A8A2D5.20809@winterei.se> <20150717.173211.1827498141128697853.maz@iij.ad.jp> <20150717.175553.1297824131323484151.maz@iij.ad.jp> Message-ID: even if customer router crash fault, should have been filtered via prefix list blocking to only allow customer network prefixs to be anounced onwards ? as per best practice colin Sent from my iPhone > On 17 Jul 2015, at 09:55, Matsuzaki Yoshinobu wrote: > > Colin Johnston wrote >> any idea why error happened ? >> what config needs fixing to mitigate mistake? >> it was easy to see problem via ripe atlas :) > > I just got brief explanation from a friend in AS7514. > > A router in their network suddenly went out of control, and it seems > this somehow generated wrong routing information. They solved the > issue by disconnecting the router and are now investigating it. > ----- > Matsuzaki Yoshinobu > - IIJ/AS2497 INOC-DBA: 2497*629 From maz at iij.ad.jp Fri Jul 17 09:46:26 2015 From: maz at iij.ad.jp (Matsuzaki Yoshinobu) Date: Fri, 17 Jul 2015 18:46:26 +0900 (JST) Subject: AW: AW: Prefix-Hijack by AS7514 In-Reply-To: References: <20150717.175553.1297824131323484151.maz@iij.ad.jp> Message-ID: <20150717.184626.1455805858013349614.maz@iij.ad.jp> Colin Johnston wrote > even if customer router crash fault, should have been filtered via > prefix list blocking to only allow customer network prefixs to be > anounced onwards ? as per best practice Yes, I agree, and we have done that. How about peering partners - which is our case this time. Is it feasible to maintain strict inbound prefix filters for all peering relationships? ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 From mark.tinka at seacom.mu Fri Jul 17 10:03:04 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 17 Jul 2015 12:03:04 +0200 Subject: AW: AW: Prefix-Hijack by AS7514 In-Reply-To: <20150717.184626.1455805858013349614.maz@iij.ad.jp> References: <20150717.175553.1297824131323484151.maz@iij.ad.jp> <20150717.184626.1455805858013349614.maz@iij.ad.jp> Message-ID: <55A8D2D8.6080802@seacom.mu> On 17/Jul/15 11:46, Matsuzaki Yoshinobu wrote: > Yes, I agree, and we have done that. How about peering partners - > which is our case this time. Is it feasible to maintain strict > inbound prefix filters for all peering relationships? To be honest, not really. Some countries I know do this for their exchange points. But by-and-large, it is not scalable. Same goes for AS_PATH lists for peering. One can be liberal at peering points but have max-prefix as a basic protection mechanism (which is what we do). Of course, IRR's are the other way to go. Mark. From morrowc.lists at gmail.com Fri Jul 17 10:25:26 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 17 Jul 2015 06:25:26 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: On Wed, Jul 15, 2015 at 4:43 PM, Ricky Beam wrote: > On Wed, 15 Jul 2015 16:20:11 -0400, Lee Howard wrote: >> >> Business Class DOCSIS customers get a prefix automatically (unless you >> provide your own gateway and DHCPv6 isn?t enabled). > doesn't the last paranthetical here > > I looked last night at the office in Cary, NC. NO RAs are seen on the link > coming from the Ubee (bridged) providing our dynamic/DOCSIS connection. > Without an RA, nothing will attempt IPv6. > mean that your UBee has to do dhcpv6? (or the downstream thingy from the UBee has to do dhcpv6?) > (I've not checked the one in Raleigh that's also a hotspot) > > Residential? sure, there's lot of v6 there -- has been for over a year. But > as I'm an Earthlink customer, and those morons cannot be bothered to give > TWC one of their *5* UNUSED /32's, all I get is: > (IA_PD IAID:327681 T1:0 T2:0 (status code no prefixes)) > > --Ricky From wolfgang.tremmel at de-cix.net Fri Jul 17 10:47:38 2015 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Fri, 17 Jul 2015 10:47:38 +0000 Subject: Prefix-Hijack by AS7514 In-Reply-To: <55A8D2D8.6080802@seacom.mu> References: <20150717.175553.1297824131323484151.maz@iij.ad.jp> <20150717.184626.1455805858013349614.maz@iij.ad.jp> <55A8D2D8.6080802@seacom.mu> Message-ID: <27DF913E-B956-444D-9E32-6D9367466DC7@de-cix.net> > On 17.07.2015, at 12:03, Mark Tinka wrote: > > Some countries I know do this for their exchange points. But > by-and-large, it is not scalable. Same goes for AS_PATH lists for peering. it does scale. We do this for all our routeservers at all exchange points we operate. In Frankfurt we have 745 peers on our routeservers. (And: we are not a country but an exchange point operator :-) best regards Wolfgang -- Wolfgang Tremmel e-mail: wolfgang.tremmel at de-cix.net DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt Geschaeftsfuehrer Harald A. Summa Fax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln From mark.tinka at seacom.mu Fri Jul 17 10:53:19 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 17 Jul 2015 12:53:19 +0200 Subject: Prefix-Hijack by AS7514 In-Reply-To: <27DF913E-B956-444D-9E32-6D9367466DC7@de-cix.net> References: <20150717.175553.1297824131323484151.maz@iij.ad.jp> <20150717.184626.1455805858013349614.maz@iij.ad.jp> <55A8D2D8.6080802@seacom.mu> <27DF913E-B956-444D-9E32-6D9367466DC7@de-cix.net> Message-ID: <55A8DE9F.50009@seacom.mu> On 17/Jul/15 12:47, Wolfgang Tremmel wrote: > it does scale. > We do this for all our routeservers at all exchange points we operate. > In Frankfurt we have 745 peers on our routeservers. So you have prefix and AS_PATH lists for each of the members you peer with that strictly define the prefixes they will announce to your route server? > > (And: we are not a country but an exchange point operator :-) One learns something new everyday... Mark. From jj at anexia.at Fri Jul 17 11:12:11 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 17 Jul 2015 11:12:11 +0000 Subject: AW: Prefix-Hijack by AS7514 In-Reply-To: <27DF913E-B956-444D-9E32-6D9367466DC7@de-cix.net> References: <20150717.175553.1297824131323484151.maz@iij.ad.jp> <20150717.184626.1455805858013349614.maz@iij.ad.jp> <55A8D2D8.6080802@seacom.mu> <27DF913E-B956-444D-9E32-6D9367466DC7@de-cix.net> Message-ID: <13b95224984a48caa98cc45f2b920a82@anx-i-dag02.anx.local> Wolfgang, it's unfair ... you do not have to deal with hardware routers :). Install AS_PATH ACL and prefix list on a Cisco router (e.g. with an RSP720-3CXL) and you'll run into lots of pain ... best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Wolfgang Tremmel Gesendet: Freitag, 17. Juli 2015 12:48 An: nanog at nanog.org Betreff: Re: Prefix-Hijack by AS7514 > On 17.07.2015, at 12:03, Mark Tinka wrote: > > Some countries I know do this for their exchange points. But > by-and-large, it is not scalable. Same goes for AS_PATH lists for peering. it does scale. We do this for all our routeservers at all exchange points we operate. In Frankfurt we have 745 peers on our routeservers. (And: we are not a country but an exchange point operator :-) best regards Wolfgang -- Wolfgang Tremmel e-mail: wolfgang.tremmel at de-cix.net DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt Geschaeftsfuehrer Harald A. Summa Fax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln From rdrake at direcpath.com Fri Jul 17 12:41:50 2015 From: rdrake at direcpath.com (Robert Drake) Date: Fri, 17 Jul 2015 08:41:50 -0400 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> Message-ID: <55A8F80E.60900@direcpath.com> On 7/17/2015 4:26 AM, Alexander Maassen wrote: > Well, this block also affects people who have old management hardware > around using such ciphers that are for example no longer supported. In my > case for example the old Dell DRAC's. And it seems there is no way to > disable this block. > > Ok, it is good to think about security, but not giving you any chance to > make exceptions is simply forcing users to use another browser in order to > manage those devices, or to keep an old machine around that not gets > updated. > Or just fallback to no SSL in some cases :( We have some old vendor things that were chugging along until everyone upgraded firefox and then suddenly they stopped working. The "fix" was to use the alternate non-SSL web port rather than upgrade because even though the software is old, it's too critical to upgrade it in-line. The long term fix is to get new hardware and run it all in virtual machines with new software on top, but that may be in next years budget. I've also got a jetty server (opennms) that broke due to this, so I upgraded and fixed the SSL options and it's still broken in some way that won't log errors. I have no time to track that down so the workaround is to use the unencrypted version until I can figure it out. Having said that, it seems that there is a workaround in Firefox if people need it. about:config and re-enabling the weak ciphers. Hopefully turning them on leaves you with a even bigger warning than normal saying it's a bad cert, but you could get back in. This doesn't help my coworkers. I'm not going to advise a bunch of people with varying levels of technical competency to turn on weak ciphers, but it does help with a situation like yours where you absolutely can't update old DRAC stuff. https://support.mozilla.org/en-US/questions/1042061 From joelja at bogus.com Fri Jul 17 04:45:22 2015 From: joelja at bogus.com (joel jaeggli) Date: Thu, 16 Jul 2015 21:45:22 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150715152505.26352.qmail@ary.lan> <3772.1436975354@turing-police.cc.vt.edu> Message-ID: <55A88862.5050201@bogus.com> On 7/15/15 9:10 AM, John R. Levine wrote: >>> It would be nice if it were possible to implement BCP 38 in IPv6, >>> since this >>> is the reason it isn't in IPv4. >> >> There isn't any technical reason that an organization can't fix its edge >> so it doesn't urinate bad IPv6 traffic all over the Internet. > > In IPv4 systems, the problem is (so I have been told by some largish > ISPs) that a dual homed customer gets address ranges from ISPs A and B, > and sends traffic with A addresses to the B interface. The ISPs have no > practical way to tell legit dual homed traffic from malicious, > particularly when there is a chain of resellers in between. If the ISP > tells the customer to send the traffic over the right interface, the > usual response is "if you don't want our business, I'm sure we can find > another ISP that does." Strict rpf has the super nice property that if you withdraw you prefix from a peer, that peer blackholes traffic. there are all sorts of fun cases like for example MLPE peering on exchange fabrics where you can't just tag the prefix no export and send it to your neighbor, which means it's all or nothing. The exigent reality is that the less control customers have over their own policy then the easier they are to filter. retail isp customers with prefixes delegated by their provider, easy so when ISPS practice good hygiene on their retail side, great.. some dude at an exchange point direct adjacency or no, quite a bit harder. > Like I said, it would be nice if ISPs could persuade their v6 customers > to get their own PI space early on, because if they don't they'll have > exactly the same problem. > > R's, > John > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From mhuff at ox.com Fri Jul 17 13:42:37 2015 From: mhuff at ox.com (Matthew Huff) Date: Fri, 17 Jul 2015 13:42:37 +0000 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <55A8F80E.60900@direcpath.com> References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com> Message-ID: After making the about:config changes, no warning is given to the user about the bad ciphers. Even if you click the SSL lock icon, no warning is given. Only if you know that the connection being made with "TLS_RSA_WITH_AES_128_CBC_SHA,128 bit keys, TLS 1.0" is a bad thing would you have any clue. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Robert Drake Sent: Friday, July 17, 2015 8:42 AM To: nanog at nanog.org Subject: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers On 7/17/2015 4:26 AM, Alexander Maassen wrote: > Well, this block also affects people who have old management hardware > around using such ciphers that are for example no longer supported. In my > case for example the old Dell DRAC's. And it seems there is no way to > disable this block. > > Ok, it is good to think about security, but not giving you any chance to > make exceptions is simply forcing users to use another browser in order to > manage those devices, or to keep an old machine around that not gets > updated. > Or just fallback to no SSL in some cases :( We have some old vendor things that were chugging along until everyone upgraded firefox and then suddenly they stopped working. The "fix" was to use the alternate non-SSL web port rather than upgrade because even though the software is old, it's too critical to upgrade it in-line. The long term fix is to get new hardware and run it all in virtual machines with new software on top, but that may be in next years budget. I've also got a jetty server (opennms) that broke due to this, so I upgraded and fixed the SSL options and it's still broken in some way that won't log errors. I have no time to track that down so the workaround is to use the unencrypted version until I can figure it out. Having said that, it seems that there is a workaround in Firefox if people need it. about:config and re-enabling the weak ciphers. Hopefully turning them on leaves you with a even bigger warning than normal saying it's a bad cert, but you could get back in. This doesn't help my coworkers. I'm not going to advise a bunch of people with varying levels of technical competency to turn on weak ciphers, but it does help with a situation like yours where you absolutely can't update old DRAC stuff. https://support.mozilla.org/en-US/questions/1042061 From jeffg at opennms.org Fri Jul 17 13:56:52 2015 From: jeffg at opennms.org (Jeff Gehlbach) Date: Fri, 17 Jul 2015 09:56:52 -0400 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <55A8F80E.60900@direcpath.com> References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com> Message-ID: <55A909A4.6000208@opennms.org> On 07/17/2015 08:41 AM, Robert Drake wrote: > I've also got a jetty server (opennms) that broke due to this, > so I upgraded and fixed the SSL options and it's still broken in some > way that won't log errors. I have no time to track that down so the > workaround is to use the unencrypted version until I can figure it out. We had a ticket about this a couple weeks ago from a support client who was catching flak from a PCI-DSS audit team. Here's the changeset that should address the problem: https://github.com/OpenNMS/opennms/commit/6da9e8952e7f81b0b863da93add684c5e963e0ba -jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From outsider at scarynet.org Fri Jul 17 14:41:00 2015 From: outsider at scarynet.org (Alexander Maassen) Date: Fri, 17 Jul 2015 16:41:00 +0200 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <55A8F80E.60900@direcpath.com> References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com> Message-ID: As of 38.0.5, this no longer is even an option, as they removed sslv3 support, see the reviews at https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/ On Fri, July 17, 2015 2:41 pm, Robert Drake wrote: > > > On 7/17/2015 4:26 AM, Alexander Maassen wrote: >> Well, this block also affects people who have old management hardware >> around using such ciphers that are for example no longer supported. In >> my >> case for example the old Dell DRAC's. And it seems there is no way to >> disable this block. >> >> Ok, it is good to think about security, but not giving you any chance to >> make exceptions is simply forcing users to use another browser in order >> to >> manage those devices, or to keep an old machine around that not gets >> updated. >> > Or just fallback to no SSL in some cases :( We have some old vendor > things that were chugging along until everyone upgraded firefox and then > suddenly they stopped working. The "fix" was to use the alternate > non-SSL web port rather than upgrade because even though the software is > old, it's too critical to upgrade it in-line. > > The long term fix is to get new hardware and run it all in virtual > machines with new software on top, but that may be in next years > budget. I've also got a jetty server (opennms) that broke due to this, > so I upgraded and fixed the SSL options and it's still broken in some > way that won't log errors. I have no time to track that down so the > workaround is to use the unencrypted version until I can figure it out. > > Having said that, it seems that there is a workaround in Firefox if > people need it. about:config and re-enabling the weak ciphers. > Hopefully turning them on leaves you with a even bigger warning than > normal saying it's a bad cert, but you could get back in. This doesn't > help my coworkers. I'm not going to advise a bunch of people with > varying levels of technical competency to turn on weak ciphers, but it > does help with a situation like yours where you absolutely can't update > old DRAC stuff. > > https://support.mozilla.org/en-US/questions/1042061 > From Lee at asgard.org Fri Jul 17 14:49:20 2015 From: Lee at asgard.org (Lee Howard) Date: Fri, 17 Jul 2015 10:49:20 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: On 7/17/15, 6:25 AM, "Christopher Morrow" wrote: >On Wed, Jul 15, 2015 at 4:43 PM, Ricky Beam wrote: >> On Wed, 15 Jul 2015 16:20:11 -0400, Lee Howard wrote: >>> >>> Business Class DOCSIS customers get a prefix automatically (unless you >>> provide your own gateway and DHCPv6 isn?t enabled). >> > >doesn't the last paranthetical here > >> >> I looked last night at the office in Cary, NC. NO RAs are seen on the >>link >> coming from the Ubee (bridged) providing our dynamic/DOCSIS connection. >> Without an RA, nothing will attempt IPv6. >> > >mean that your UBee has to do dhcpv6? (or the downstream thingy from >the UBee has to do dhcpv6?) Yes. I should have said that there are some modems that don?t support IPv6, and a few that should-but-don?t-properly-yet. Ricky and I have corresponded privately. Lee > >> (I've not checked the one in Raleigh that's also a hotspot) >> >> Residential? sure, there's lot of v6 there -- has been for over a year. >>But >> as I'm an Earthlink customer, and those morons cannot be bothered to >>give >> TWC one of their *5* UNUSED /32's, all I get is: >> (IA_PD IAID:327681 T1:0 T2:0 (status code no prefixes)) >> >> --Ricky > From infinityape at gmail.com Fri Jul 17 15:12:48 2015 From: infinityape at gmail.com (Dennis B) Date: Fri, 17 Jul 2015 11:12:48 -0400 Subject: NANOG Digest, Vol 90, Issue 1 In-Reply-To: <4699E142-FD73-4D23-B3A4-0702B3621210@arbor.net> References: <56B9AB8A-C47E-4C52-87EF-C482AC008DF7@arbor.net> <4699E142-FD73-4D23-B3A4-0702B3621210@arbor.net> Message-ID: To Ramy, Thank you for the acknowledgement. DDoS Mitigation service providers, regardless if its pure cloud, hybrid cloud, or CPE only, all face these challenges when it comes to DDoS Attacks. Can you restate your question again or rephrase it for the forum? Seems there is some confusion or maybe people didn't grasp it. My understanding of the question RAMY asked was around DDoS mitigation providers and during the Time-to-Detect, Time-to-Start-to-Mitigate. How do businesses protect themselves when attack traffic is NOT stopped at first?.IE: Defense in depth NOTE: Some DDoS mitigation providers offer Time-to-stop-the-attack SLA's. Its all moot though. These types of solutions do not guarantee up time during the initial attack start time, PERIOD! How can anyone guarantee up-time during a 40Gbps attack and lets say - all you have are 2 x 1GB CAT5E links over multi-homed BGP providers. Having larger port capacity (IE: 10GB ports) only gives you minutes/hours to react and redirect to a Cloud Provider. The time to start mitigation (average industry time) 30 - 45 minutes. What is happening to your WAN infrastructure when there is 40Gbps of attack on your doorstep. Will your 2Gbps worth of aggregated ISP bandwidth keep sessions up? No, it will get saturated, BGP will flap and any GRE connections or any other traffic will be lost. This means, even with local CPE mitigation, things will bounce. This is 1 scenario of 1000's. There are positive security models that you can employ as as stop gap to prevent these types of scenario's, but mostly its on the Service Providers best practices or traffic posture model. IE: On-Demand, On-Demand with monitoring, Always-On monitoring, Always-On monitoring and mitigation. Having local mitigation for DDoS attacks is a loosing battle in my opinion. Its only buying you time to redirect. It does solve problems like attacks that are low in scale that you can consume with your port capacity or quick to hit and run attacks (1-2min durations). But then you need auto-mitigation enabled and that leads to collateral damage most of the times for legitimate traffic. Pretty sure other SP's will offer different opinion. This is my technical opinion, not representing Akamai or any other companies official position. >From an engineering perspective, assume when an advisory targets your business and they have 1/2 way decent attacking nodes, expect an outage. Message that to the board but explain that you have every capability to mitigate these risks. Given the SP you go with has enough staff, resources, capacity, technology, SLA, and knowledge/experience in the attack vector hitting you. If you want to "learn more", keep up the engagements with the market DDoS providers you are communicating with and ask these tough questions. If anyone "sells" you the perfect solution, they are LIEING to you! On a personal note, thank you for reaching out privately in email and explaining who you are talking too. Trust me when I tell you, I know the organization VERY WELL from the other competitor you are looking at and i will offer you my candid opinion of them, if you'd like. My friend runs their SOC over there, an old colleague of mine from when i was in the SOC blocking attacks. Love this topic! Dennis On Wed, Jul 8, 2015 at 12:00 PM, Roland Dobbins wrote: > > On 8 Jul 2015, at 22:26, Roland Dobbins wrote: > > Hardware-based GRE processing is required on both ends for anything other >> than trivial speeds; in general, the day of software-based Internet >> routers is long gone, and any organization still running software-based >> routers on their transit/peering edges at risk. >> > > To clarify, I'm referring to GRE processing on routers; hardware > processing is pretty much a requirement on routers. Other types of devices > can often handle GRE at significantly higher rates than software-based > routers. > > > > ----------------------------------- > Roland Dobbins > From jmaimon at ttec.com Fri Jul 17 16:03:41 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 17 Jul 2015 12:03:41 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <939dc84108954b5182c99f578809402e@pur-vm-exch13n1.ox.com> <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com> <832A243E-38C5-4C6F-A953-61D9E78386D1@delong.com> <9578293AE169674F9A048B2BC9A081B401C7097901@MUNPRDMBXA1.medline.com> <57B47422-2B92-4C74-A3C8-FF2D980703F7@delong.com> <559F7B59.5040101@ttec.com> <7E82D53D-8BCF-4AA8-9635-F1D8E35D6496@delong.com> <55A446BD.6000605@ttec.com> <20150715010018.CC3C733059FF@rock.dv.isc.org> <55A6974D.2010102@ttec.com> <55A6A714.2020903@dougbarton.us> <55A6F0B3.8010302@ttec.com> <55A71FFC.2090301@dougbarton.us> <55A7CCA4.2020002@ttec.com> <55A814EF.5080009@ttec.com> Message-ID: <55A9275D.4090601@ttec.com> Lee Howard wrote: > > > On 7/16/15, 4:32 PM, "Joe Maimon" wrote: > >> >> >> Lee Howard wrote: >>> >>> So, you would like to update RFC 1112, which defines and reserves Class >>> E? >>> That?s easy enough. If somebody had a use in mind for the space, anybody >>> can write such a draft assigning space, which is, I believe, how to >>> direct IANA to do something with it. >>> >> >> nope > > ?Nope?? Nope, there were previous attempts that failed and the task was not "easy enough", unnecessarily so. > You mean you don?t want to update RFC1112? > Or it?s not possible for somebody to write a draft telling IANA to assign > space > for an experiment? Somebody has to write a draft in order for the IETF to > consider it, Which has happened. and there has to be IETF consensus for it to get published as > an > RFC. > Which did not happen, due in no small part, I allege, to spurious and specious concerns about ipv6 adoption and to to irrelevant and misprojected concerns as to whether it was "worth it". > > I don?t see the relevance. Nobody there proposed reclassifying the space. > Nobody had a proposal for an experiment. Nobody wanted an assignment from > it. Quoted directly there is an I-D to utilize at least some portion of the space for what we later allocated public unicast /10 Carrier private. > > >> >> The only use I have in mind for the space is for it to cease being >> classified as experimental and therefore treated as invalid. > > You want the word ?RESERVED? for some entries on this page changed: > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml > What do you want it changed to? Personally, a /6 of LSN/CGN private, /8 (per rir?) of public early adopter by the /16, and the rest reserved for if/when it ever becomes A) more useful and/or B) rehabilitated, /8 per rir. But I would get behind any effort for any status that would indicate proper behavior for any/and all new updated stacks is to allow its use without differentiation. > > > There?s more to it than that. > How would people who want to use it get assignments? > Right now, there?s no policy for assigning that space. > The first stop is to change the standard so that considering the address illegal to use in software could be considered improper behavior. If the community cant even get past that, and they have not in the past, no other scheme stands a chance. Tying objections to removing that barrier due to lack of a fully acceptable allocation policy is unnecessarily inflating the hurdle to that goal. > You?ve told other people that there shouldn?t be a top-down restriction on > this space; but there?s no top: it?s all consensus. The consensus here is > very clear. You are welcome to try to change it, and a couple of us are > trying to should you the processes (IETF, IANA, RIR) to do that. > My categorization as inappropriate top down restrictions is specifically calling out those who believe policy is a tool to direct and marshal other peoples efforts, away from what they consider competing goals. I dont consider that a valid rational and I think its quite inappropriate. > If all you want to do is vent, we?ll just move on to another thread. > > Lee > Venting is a form of consensus building. If there are any drafts anywhere that could use some of that, please point them out. Joe From jmaimon at ttec.com Fri Jul 17 16:13:15 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 17 Jul 2015 12:13:15 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: References: <20150716221723.33698.qmail@ary.lan> <55A8305C.10401@ttec.com> Message-ID: <55A9299B.2070804@ttec.com> Baldur Norddahl wrote: > On 17 July 2015 at 00:29, Joe Maimon wrote: > >> All I am advocating is that if ever another draft standard comes along to >> enable people to try and make something of it, lead follow or get out of >> the way. >> > > If I understand correctly you want someone (not you) to write a RFC that > changes the word "experimental" to "something else". Yes. Even me. > But you do not want > IANA and the 5 RIRs to implement policies to hand out this space. I dont consider that a necessary part of status change. > Nor do > you expect any vendor to change anything? I dont expect them to change anything unless experimental/reserved for future potentially non-unicast protocol behavior is removed from IETF standards. > > May i then suggest that "something else" could be "junk" or "useless" ? Which would still render software that refused to allow use of the space non standards compliant, so I can accept that as a starting basis. > > Fact is that it is junk. It is probably not even routable in the default > free zone. Anyone up for an experiment? Probably need to change the standards first. > > Nobody is going to want a class E address. Even if your own equipment was > updated to allow it, you would not be able to communicate with most of the > internet. Tell me, in what timeframe do you expect that would change, if > someone did write that RFC and got it approved? A lot sooner if people would stop complaining that it takes too long. Otherwise, never. > You got it all wrong when you believe it is a top down decision. It is the > opposite. You are fighting _consensus_. Nobody wants to change the status > of class E because it would not work and would only confuse. > > Regards, > > Baldur > Plenty of people want(ed) to change the status. The objections of the naysayers amount(ed) to, we think it will take too long to be usable in equivalent fashion to current unicast, and we think if it ever is usable it wont be enough of a difference to have made it worth it and we want ipv6 instead so we dont want anyone to even try. Even if all those objections are valid, they still do not justify doing nothing. Joe From jmaimon at ttec.com Fri Jul 17 16:17:15 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 17 Jul 2015 12:17:15 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <45DA2851-60BD-41F2-8B62-36A9427D3C3E@delong.com> References: <20150716221723.33698.qmail@ary.lan> <55A8305C.10401@ttec.com> <45DA2851-60BD-41F2-8B62-36A9427D3C3E@delong.com> Message-ID: <55A92A8B.5070208@ttec.com> Owen DeLong wrote: > >> On Jul 16, 2015, at 15:29 , Joe Maimon wrote: >> >> All I am advocating is that if ever another draft standard comes along to enable people to try and make something of it, lead follow or get out of the way. > > Sometimes good leadership is knowing when to say ?not just no, but hell no.? > > Owen This is not one of them. Your stated reason for hell no is that you want no distractions from ipv6 rollout. That is not leadership. That is dictatorship via tyranny of the minority, enabled by consensus, Joe From shane at ronan-online.com Fri Jul 17 16:34:13 2015 From: shane at ronan-online.com (Shane Ronan) Date: Fri, 17 Jul 2015 12:34:13 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A92A8B.5070208@ttec.com> References: <20150716221723.33698.qmail@ary.lan> <55A8305C.10401@ttec.com> <45DA2851-60BD-41F2-8B62-36A9427D3C3E@delong.com> <55A92A8B.5070208@ttec.com> Message-ID: <55A92E85.1070201@ronan-online.com> Dictatorship enabled by consensus == Democratic Republic, Welcome to America! On 7/17/15 12:17 PM, Joe Maimon wrote: > > > Owen DeLong wrote: >> >>> On Jul 16, 2015, at 15:29 , Joe Maimon wrote: >>> >>> All I am advocating is that if ever another draft standard comes >>> along to enable people to try and make something of it, lead follow >>> or get out of the way. >> >> Sometimes good leadership is knowing when to say ?not just no, but >> hell no.? >> >> Owen > > This is not one of them. Your stated reason for hell no is that you > want no distractions from ipv6 rollout. That is not leadership. That > is dictatorship via tyranny of the minority, enabled by consensus, > > Joe From cra at WPI.EDU Fri Jul 17 16:36:51 2015 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 17 Jul 2015 12:36:51 -0400 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150716075914.464d25d7@echo.ms.redpill-linpro.com> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716075914.464d25d7@echo.ms.redpill-linpro.com> Message-ID: <20150717163651.GJ31099@angus.ind.WPI.EDU> On Thu, Jul 16, 2015 at 07:59:14AM +0200, Tore Anderson wrote: > * Owen DeLong > > > > On Jul 15, 2015, at 08:57 , Matthew Kaufman wrote: > > > This is only true for dual-stacked networks. I just tried to set up > > > an IPv6-only WiFi network at my house recently, and it was a total > > > fail due to non-implementation of relatively new standards... > > > starting with the fact that my Juniper SRX doesn't run a load new > > > enough to include RDNSS information in RAs, and some of the devices > > > I wanted to test with (Android tablets) won't do DHCPv6. > > > > That?s a pretty old load then, as I?ve had RDNSS on my SRX-100 for > > several years now. > > Interesting. Which JUNOS version are you running, exactly? > > According to Juniper's web site, RDNSS support showed up in JUNOS 14.1, > which isn't available for the SRX series (nor is any later version). > > http://www.juniper.net/techpubs/en_US/junos15.1/topics/reference/configuration-statement/dns-server-address-edit-protocols-router-advertisement.html Strange. dns-server-address IS available to be configured on my MX box running 13.3R4. It is however not there for SRX on 12.1X44-D50. From hugo at slabnet.com Fri Jul 17 16:50:06 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 17 Jul 2015 09:50:06 -0700 Subject: Remember "Internet-In-A-Box"? In-Reply-To: <20150717163651.GJ31099@angus.ind.WPI.EDU> References: <55A59F42.1080205@satchell.net> <55A5A319.2070701@tiedyenetworks.com> <55A5B526.8030804@alter3d.ca> <20150715062233.E0CA0332D24B@rock.dv.isc.org> <55A682E6.1050607@matthew.at> <20150716075914.464d25d7@echo.ms.redpill-linpro.com> <20150717163651.GJ31099@angus.ind.WPI.EDU> Message-ID: <20150717165006.GC4261@bamboo.slabnet.com> On Fri 2015-Jul-17 12:36:51 -0400, Chuck Anderson wrote: >On Thu, Jul 16, 2015 at 07:59:14AM +0200, Tore Anderson wrote: >> * Owen DeLong >> >> > > On Jul 15, 2015, at 08:57 , Matthew Kaufman wrote: >> > > This is only true for dual-stacked networks. I just tried to set up >> > > an IPv6-only WiFi network at my house recently, and it was a total >> > > fail due to non-implementation of relatively new standards... >> > > starting with the fact that my Juniper SRX doesn't run a load new >> > > enough to include RDNSS information in RAs, and some of the devices >> > > I wanted to test with (Android tablets) won't do DHCPv6. >> > >> > That?s a pretty old load then, as I?ve had RDNSS on my SRX-100 for >> > several years now. >> >> Interesting. Which JUNOS version are you running, exactly? >> >> According to Juniper's web site, RDNSS support showed up in JUNOS 14.1, >> which isn't available for the SRX series (nor is any later version). >> >> http://www.juniper.net/techpubs/en_US/junos15.1/topics/reference/configuration-statement/dns-server-address-edit-protocols-router-advertisement.html > >Strange. dns-server-address IS available to be configured on my MX >box running 13.3R4. > >It is however not there for SRX on 12.1X44-D50. ...or 12.1X46-D35.1 (JTAC bumped the rec'd release June 29th, so it's in the lab). -- Hugo hugo at slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jared at puck.Nether.net Fri Jul 17 17:17:50 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 17 Jul 2015 13:17:50 -0400 Subject: Prefix-Hijack by AS7514 In-Reply-To: <27DF913E-B956-444D-9E32-6D9367466DC7@de-cix.net> References: <20150717.175553.1297824131323484151.maz@iij.ad.jp> <20150717.184626.1455805858013349614.maz@iij.ad.jp> <55A8D2D8.6080802@seacom.mu> <27DF913E-B956-444D-9E32-6D9367466DC7@de-cix.net> Message-ID: <20150717171750.GA16235@puck.nether.net> On Fri, Jul 17, 2015 at 10:47:38AM +0000, Wolfgang Tremmel wrote: > > > On 17.07.2015, at 12:03, Mark Tinka wrote: > > > > Some countries I know do this for their exchange points. But > > by-and-large, it is not scalable. Same goes for AS_PATH lists for peering. > > it does scale. > We do this for all our routeservers at all exchange points we operate. > In Frankfurt we have 745 peers on our routeservers. Scale has become my favorite term from vendors that sets off alarm bells. The problem is usually limited by someones imagination like "why would you have more than 1 comment/remark", or "what do you mean a customer has 200k prefixes registered". it all depends on who/where and what role you play. We have tried prefix filtering peers before. It's an excercise in frustration when it comes to vendors ability to ingest the large sets and/or changes. I talked about this privately and at things like IEPG. http://iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf The situation and technology haven't substantively changed in the interim. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From Bob.Watson at wwt.com Fri Jul 17 17:58:29 2015 From: Bob.Watson at wwt.com (Watson, Bob) Date: Fri, 17 Jul 2015 17:58:29 +0000 Subject: NANOG Digest, Vol 90, Issue 1 In-Reply-To: References: <56B9AB8A-C47E-4C52-87EF-C482AC008DF7@arbor.net> <4699E142-FD73-4D23-B3A4-0702B3621210@arbor.net>, Message-ID: <26E293B0-4438-4549-9AAA-30B83CD9FFC1@wwt.com> P Bob Watson > On Jul 17, 2015, at 10:14 AM, Dennis B wrote: > > To Ramy, > > Thank you for the acknowledgement. DDoS Mitigation service providers, > regardless if its pure cloud, hybrid cloud, or CPE only, all face these > challenges when it comes to DDoS Attacks. > > Can you restate your question again or rephrase it for the forum? Seems > there is some confusion or maybe people didn't grasp it. > > My understanding of the question RAMY asked was around DDoS mitigation > providers and during the Time-to-Detect, Time-to-Start-to-Mitigate. How do > businesses protect themselves when attack traffic is NOT stopped at > first?.IE: Defense in depth > > NOTE: Some DDoS mitigation providers offer Time-to-stop-the-attack SLA's. > > Its all moot though. These types of solutions do not guarantee up time > during the initial attack start time, PERIOD! > > How can anyone guarantee up-time during a 40Gbps attack and lets say - all > you have are 2 x 1GB CAT5E links over multi-homed BGP providers. Having > larger port capacity (IE: 10GB ports) only gives you minutes/hours to react > and redirect to a Cloud Provider. > > The time to start mitigation (average industry time) 30 - 45 minutes. What > is happening to your WAN infrastructure when there is 40Gbps of attack on > your doorstep. > > Will your 2Gbps worth of aggregated ISP bandwidth keep sessions up? No, it > will get saturated, BGP will flap and any GRE connections or any other > traffic will be lost. This means, even with local CPE mitigation, things > will bounce. This is 1 scenario of 1000's. > > There are positive security models that you can employ as as stop gap to > prevent these types of scenario's, but mostly its on the Service Providers > best practices or traffic posture model. IE: On-Demand, On-Demand with > monitoring, Always-On monitoring, Always-On monitoring and mitigation. > > Having local mitigation for DDoS attacks is a loosing battle in my opinion. > Its only buying you time to redirect. It does solve problems like attacks > that are low in scale that you can consume with your port capacity or quick > to hit and run attacks (1-2min durations). But then you need > auto-mitigation enabled and that leads to collateral damage most of the > times for legitimate traffic. > > Pretty sure other SP's will offer different opinion. This is my technical > opinion, not representing Akamai or any other companies official position. > > From an engineering perspective, assume when an advisory targets your > business and they have 1/2 way decent attacking nodes, expect an outage. > Message that to the board but explain that you have every capability to > mitigate these risks. Given the SP you go with has enough staff, resources, > capacity, technology, SLA, and knowledge/experience in the attack vector > hitting you. > > If you want to "learn more", keep up the engagements with the market DDoS > providers you are communicating with and ask these tough questions. If > anyone "sells" you the perfect solution, they are LIEING to you! > > On a personal note, thank you for reaching out privately in email and > explaining who you are talking too. Trust me when I tell you, I know the > organization VERY WELL from the other competitor you are looking at and i > will offer you my candid opinion of them, if you'd like. My friend runs > their SOC over there, an old colleague of mine from when i was in the SOC > blocking attacks. > > Love this topic! > > Dennis > > > > > > > >> On Wed, Jul 8, 2015 at 12:00 PM, Roland Dobbins wrote: >> >> >> On 8 Jul 2015, at 22:26, Roland Dobbins wrote: >> >> Hardware-based GRE processing is required on both ends for anything other >>> than trivial speeds; in general, the day of software-based Internet >>> routers is long gone, and any organization still running software-based >>> routers on their transit/peering edges at risk. >> >> To clarify, I'm referring to GRE processing on routers; hardware >> processing is pretty much a requirement on routers. Other types of devices >> can often handle GRE at significantly higher rates than software-based >> routers. >> >> >> >> ----------------------------------- >> Roland Dobbins >> From nick at flhsi.com Fri Jul 17 17:58:33 2015 From: nick at flhsi.com (Nick Olsen) Date: Fri, 17 Jul 2015 13:58:33 -0400 Subject: ATT wireless IPv6 In-Reply-To: <3627BB47-6B49-4F42-9165-45FA19D7EFD3@puck.nether.net> References: <55A6DEDE.2090701@NEEBU.Net> <3627BB47-6B49-4F42-9165-45FA19D7EFD3@puck.nether.net> Message-ID: <829d5df9d2e5441b884ba466d35c6523@flhsi.com> FYI, My Note 4, With APN nextgenphone doesn't have IPv6 in Cocoa Florida (Central Florida region) Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Jared Mauch" Sent: Wednesday, July 15, 2015 6:38 PM To: "Jake Khuon" Cc: "North American Network Operators' Group" Subject: Re: ATT wireless IPv6 > On Jul 15, 2015, at 6:29 PM, Jake Khuon wrote: > > On 15/07/15 04:54, Jared Mauch wrote: >> Does anyone know what the story is here? They have some transparent proxies for IPv4 traffic and I was wondering if they were to be IPv6 enabled soon or if IPv6 will reach the handset. > > Hmmm... I'm seeing my rmnet1 interface on my Galaxy S5 as having an > address out of the 2600:380:46ae::/38 space which is allocated to AT&T > Mobility. I exchanged a few emails earlier today with someone and it seems to depend on your APN. If you have the VoLTE APN on your device you can get IPv6, including when tethering. The APN you want is nxtgenphone. If you have a device where you can not edit the APN settings (iPhone) you can not use the IPv6 enabled VoLTE APN. I suspect this will be enabled if they launch VoLTE on the iPhone. - Jared From cscora at apnic.net Fri Jul 17 18:11:41 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Jul 2015 04:11:41 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201507171811.t6HIBfbb013747@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 18 Jul, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 552114 Prefixes after maximum aggregation (per Origin AS): 208717 Deaggregation factor: 2.65 Unique aggregates announced (without unneeded subnets): 269446 Total ASes present in the Internet Routing Table: 50925 Prefixes per ASN: 10.84 Origin-only ASes present in the Internet Routing Table: 36684 Origin ASes announcing only one prefix: 16204 Transit ASes present in the Internet Routing Table: 6344 Transit-only ASes present in the Internet Routing Table: 173 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 39 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 1393 Unregistered ASNs in the Routing Table: 468 Number of 32-bit ASNs allocated by the RIRs: 10255 Number of 32-bit ASNs visible in the Routing Table: 7897 Prefixes from 32-bit ASNs in the Routing Table: 29205 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 394 Number of addresses announced to Internet: 2768034912 Equivalent to 164 /8s, 252 /16s and 220 /24s Percentage of available address space announced: 74.8 Percentage of allocated address space announced: 74.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.5 Total number of prefixes smaller than registry allocations: 184582 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 136627 Total APNIC prefixes after maximum aggregation: 39587 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 143533 Unique aggregates announced from the APNIC address blocks: 58259 APNIC Region origin ASes present in the Internet Routing Table: 5064 APNIC Prefixes per ASN: 28.34 APNIC Region origin ASes announcing only one prefix: 1193 APNIC Region transit ASes present in the Internet Routing Table: 882 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1550 Number of APNIC addresses announced to Internet: 751143744 Equivalent to 44 /8s, 197 /16s and 139 /24s Percentage of available APNIC address space announced: 87.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179472 Total ARIN prefixes after maximum aggregation: 87853 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182133 Unique aggregates announced from the ARIN address blocks: 85215 ARIN Region origin ASes present in the Internet Routing Table: 16609 ARIN Prefixes per ASN: 10.97 ARIN Region origin ASes announcing only one prefix: 6109 ARIN Region transit ASes present in the Internet Routing Table: 1738 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 551 Number of ARIN addresses announced to Internet: 1083495456 Equivalent to 64 /8s, 148 /16s and 212 /24s Percentage of available ARIN address space announced: 57.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 133904 Total RIPE prefixes after maximum aggregation: 66659 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 140644 Unique aggregates announced from the RIPE address blocks: 87280 RIPE Region origin ASes present in the Internet Routing Table: 17964 RIPE Prefixes per ASN: 7.83 RIPE Region origin ASes announcing only one prefix: 8093 RIPE Region transit ASes present in the Internet Routing Table: 2978 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3864 Number of RIPE addresses announced to Internet: 698388864 Equivalent to 41 /8s, 160 /16s and 145 /24s Percentage of available RIPE address space announced: 101.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 60452 Total LACNIC prefixes after maximum aggregation: 11503 LACNIC Deaggregation factor: 5.26 Prefixes being announced from the LACNIC address blocks: 71351 Unique aggregates announced from the LACNIC address blocks: 33083 LACNIC Region origin ASes present in the Internet Routing Table: 2450 LACNIC Prefixes per ASN: 29.12 LACNIC Region origin ASes announcing only one prefix: 613 LACNIC Region transit ASes present in the Internet Routing Table: 514 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1800 Number of LACNIC addresses announced to Internet: 168644224 Equivalent to 10 /8s, 13 /16s and 78 /24s Percentage of available LACNIC address space announced: 100.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12213 Total AfriNIC prefixes after maximum aggregation: 3066 AfriNIC Deaggregation factor: 3.98 Prefixes being announced from the AfriNIC address blocks: 14059 Unique aggregates announced from the AfriNIC address blocks: 5243 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 19.13 AfriNIC Region origin ASes announcing only one prefix: 196 AfriNIC Region transit ASes present in the Internet Routing Table: 158 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 132 Number of AfriNIC addresses announced to Internet: 65865472 Equivalent to 3 /8s, 237 /16s and 7 /24s Percentage of available AfriNIC address space announced: 65.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2949 11305 940 Korea Telecom 17974 2699 904 78 PT Telekomunikasi Indonesia 7545 2568 339 137 TPG Telecom Limited 4538 2084 4190 71 China Education and Research 4755 2035 428 236 TATA Communications formerly 9829 1803 1359 151 National Internet Backbone 9808 1586 8717 29 Guangdong Mobile Communicatio 9583 1516 119 570 Sify Limited 4808 1464 2245 471 CNCGROUP IP network China169 9498 1360 335 107 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3173 2957 136 Cox Communications Inc. 6389 2758 3688 51 BellSouth.net Inc. 3356 2580 10703 512 Level 3 Communications, Inc. 18566 2063 381 200 MegaPath Corporation 20115 1868 1843 407 Charter Communications 6983 1751 850 244 EarthLink, Inc. 4323 1609 1022 414 tw telecom holdings, inc. 30036 1572 321 433 Mediacom Communications Corp 701 1393 11371 677 MCI Communications Services, 22561 1382 415 257 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 2209 305 366 TELLCOM ILETISIM HIZMETLERI A 20940 2047 805 1480 Akamai International B.V. 6849 1209 355 21 JSC "Ukrtelecom" 8551 1104 376 52 Bezeq International-Ltd 13188 1062 97 76 TOV "Bank-Inform" 31148 1055 46 24 Freenet Ltd. 8402 990 544 15 OJSC "Vimpelcom" 12479 961 933 77 France Telecom Espana SA 6830 919 2696 471 Liberty Global Operations B.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3293 537 189 Telmex Colombia S.A. 28573 2285 2171 111 NET Servi?os de Comunica??o S 8151 1699 3273 474 Uninet S.A. de C.V. 7303 1630 1008 239 Telecom Argentina S.A. 6147 1398 374 30 Telefonica del Peru S.A.A. 6503 1309 421 55 Axtel, S.A.B. de C.V. 26615 1098 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 953 430 163 COLOMBIA TELECOMUNICACIONES S 11830 892 364 15 Instituto Costarricense de El Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 876 280 26 Link Egypt (Link.NET) 8452 831 958 13 TE-AS 36903 512 258 99 Office National des Postes et 36992 441 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 307 146 12 Vodafone Data 3741 250 857 208 Internet Solutions 29571 246 21 13 Cote d'Ivoire Telecom 37054 211 20 7 Data Telecom Service 36947 187 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3293 537 189 Telmex Colombia S.A. 22773 3173 2957 136 Cox Communications Inc. 4766 2949 11305 940 Korea Telecom 6389 2758 3688 51 BellSouth.net Inc. 17974 2699 904 78 PT Telekomunikasi Indonesia 3356 2580 10703 512 Level 3 Communications, Inc. 7545 2568 339 137 TPG Telecom Limited 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2285 2171 111 NET Servi?os de Comunica??o S 34984 2209 305 366 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3173 3037 Cox Communications Inc. 6389 2758 2707 BellSouth.net Inc. 17974 2699 2621 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2568 2431 TPG Telecom Limited 28573 2285 2174 NET Servi?os de Comunica??o S 3356 2580 2068 Level 3 Communications, Inc. 4538 2084 2013 China Education and Research 4766 2949 2009 Korea Telecom 18566 2063 1863 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 47051 UNALLOCATED 8.36.119.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:95 /12:260 /13:505 /14:1002 /15:1730 /16:12896 /17:7279 /18:12347 /19:25575 /20:36002 /21:38764 /22:60364 /23:52568 /24:299641 /25:1104 /26:1155 /27:708 /28:14 /29:13 /30:9 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2373 3173 Cox Communications Inc. 18566 2007 2063 MegaPath Corporation 6389 1629 2758 BellSouth.net Inc. 34984 1464 2209 TELLCOM ILETISIM HIZMETLERI A 6983 1398 1751 EarthLink, Inc. 30036 1394 1572 Mediacom Communications Corp 10620 1161 3293 Telmex Colombia S.A. 11492 1110 1193 CABLE ONE, INC. 22561 1055 1382 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1518 2:666 4:93 5:1889 6:25 8:1377 12:1817 13:14 14:1322 15:16 16:2 17:45 18:22 20:49 23:1250 24:1752 27:1991 31:1617 32:37 33:2 34:4 35:3 36:156 37:1966 38:1034 39:5 40:69 41:2726 42:292 43:1370 44:28 45:816 46:2304 47:47 49:925 50:787 52:12 54:79 55:4 56:6 57:42 58:1334 59:720 60:482 61:1752 62:1371 63:1891 64:4367 65:2261 66:4022 67:2061 68:1057 69:3250 70:1026 71:445 72:1952 74:2628 75:342 76:398 77:1272 78:1183 79:808 80:1352 81:1319 82:851 83:686 84:795 85:1351 86:435 87:1060 88:533 89:1913 90:143 91:6009 92:832 93:2268 94:2081 95:2201 96:435 97:348 98:1050 99:53 100:72 101:846 103:7810 104:1982 105:64 106:339 107:1029 108:627 109:2089 110:1145 111:1447 112:839 113:1109 114:843 115:1258 116:1416 117:1068 118:1871 119:1456 120:455 121:1137 122:2158 123:1838 124:1518 125:1626 128:628 129:393 130:411 131:1211 132:512 133:171 134:407 135:94 136:335 137:321 138:988 139:151 140:238 141:450 142:660 143:506 144:548 145:123 146:783 147:577 148:1146 149:414 150:565 151:706 152:523 153:251 154:489 155:881 156:439 157:420 158:356 159:1022 160:396 161:659 162:1982 163:439 164:693 165:697 166:306 167:828 168:1263 169:181 170:1465 171:246 172:275 173:1549 174:720 175:689 176:1443 177:3902 178:2165 179:939 180:1937 181:1612 182:1852 183:628 184:762 185:3881 186:2855 187:1771 188:2069 189:1635 190:7693 191:1037 192:8517 193:5658 194:4217 195:3706 196:1998 197:1025 198:5547 199:5495 200:6620 201:3253 202:9533 203:9140 204:4713 205:2846 206:3056 207:2969 208:3983 209:3917 210:3586 211:1923 212:2558 213:2320 214:850 215:72 216:5751 217:1836 218:722 219:470 220:1465 221:797 222:466 223:786 End of report From Valdis.Kletnieks at vt.edu Fri Jul 17 18:26:49 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 17 Jul 2015 14:26:49 -0400 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: Your message of "Wed, 15 Jul 2015 19:54:37 -0400." <55A6F2BD.5010105@ttec.com> References: <20150715183316.26843.qmail@ary.lan> <55A6F2BD.5010105@ttec.com> Message-ID: <12872.1437157609@turing-police.cc.vt.edu> On Wed, 15 Jul 2015 19:54:37 -0400, Joe Maimon said: > This objection hinges on the assumption that if there is even ONE host > on the network that will not accept that address, then the entire effort > was a waste. "if there's even ONE host" isn't the assertion, so do us a favor and don't claim it is. The problem is that *successfully* using the class E space for anything depends on it having pretty damned ubiquitous support. Statistics problem for you: Assuming an average hop count of 14, what percentage of intermediate routers need to support it in order to provide a 90% chance that a connection will make it through? Answer: 99.3% have to upgrade. Statistics problem 2: Assuming a 90% upgrade and 14 hops, what's the chance that a given connection works? Answer: Only 22.8%. (Yea, 0.9**14 nosedives pretty quickly). Are you starting to see the problem here? > Because there would then be no difference to the many many IPv4 (and > IPv6) updates that were made with no guarantee of universal adoption. The difference is that pretty much all of those other IPv4 updates were designed in such a way that failure to implement them just means failure to use *that feature*, and you could still talk unless using that feature was deemed critical to the connection. Somebody doesn't do ECN? You still talk, just without being able to use ECN. Somebody doesn't do QoS tagging? You still talk, just without being able to use QoS. Somebody doesn't do SACK? You still talk, just without being able to use SACK. Somebody doesn't do Class E? You still talk, just without being able to use Class E. Do you remember on Sesame Street, the game "one of these things is not like the others?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From geoffk at geoffk.org Fri Jul 17 19:00:07 2015 From: geoffk at geoffk.org (Geoffrey Keating) Date: 17 Jul 2015 12:00:07 -0700 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <55A8F80E.60900@direcpath.com> References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com> Message-ID: Robert Drake writes: > On 7/17/2015 4:26 AM, Alexander Maassen wrote: > > Well, this block also affects people who have old management hardware > > around using such ciphers that are for example no longer supported. In my > > case for example the old Dell DRAC's. And it seems there is no way to > > disable this block. > > > > Ok, it is good to think about security, but not giving you any chance to > > make exceptions is simply forcing users to use another browser in order to > > manage those devices, or to keep an old machine around that not gets > > updated. > > > Or just fallback to no SSL in some cases :( We have some old vendor > things that were chugging along until everyone upgraded firefox and > then suddenly they stopped working. The "fix" was to use the > alternate non-SSL web port rather than upgrade because even though the > software is old, it's too critical to upgrade it in-line. This is going to happen, probably more and more in the future. There's a point where making 99% of the web secure is better than keeping an old 1% working; so if you have hardware that's in the 1% or .1%, one day you'll wake up and there'll be an update out and that update will break your old stuff. Worse, in the future the update might have already been applied overnight. The next one of these that I know is coming, and just don't know exactly when, is RC4. Somewhere on the horizon is SHA-1. Also: <2048-bit RSA keys, <2048-bit DH, TLS 1.0. There's probably others I have forgotten. From michael.holstein at csuohio.edu Fri Jul 17 19:14:17 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Fri, 17 Jul 2015 19:14:17 +0000 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com>, Message-ID: >making 99% of the web secure is better than keeping an old 1% working A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the "I'm sorry Dave" sort of attitude. As an example .. we have a vendor who, in the current release (last 3 months) still requires "weak" ciphers in authentication responses. That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers. My $0.02 Michael Holstein Cleveland State University From niels=nanog at bakker.net Fri Jul 17 20:30:27 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 17 Jul 2015 22:30:27 +0200 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com> Message-ID: <20150717203027.GB81337@excession.tpb.net> * michael.holstein at csuohio.edu (Michael O Holstein) [Fri 17 Jul 2015, 21:14 CEST]: >>making 99% of the web secure is better than keeping an old 1% working >A fine idea, unless for $reason your application is among the 1% .. >nevermind the arrogance of the "I'm sorry Dave" sort of attitude. Why do you upgrade your management systems asynchronously to your applications? You bring this on yourself. >As an example .. we have a vendor who, in the current release (last >3 months) still requires "weak" ciphers in authentication responses. >That was mostly okay until another vendor (with more sense) wanted >to auth the same way but only permitted strong ciphers. Why do you access mission-critical systems that are provably insecure from systems that also have internet access? If it's not mission-critical, then you should explain why you haven't dumped that vendor yet for shipping insecure software - an insecurity that is very easy to mitigate by them, should they have chosen to. -- Niels. From outsider at scarynet.org Fri Jul 17 20:50:12 2015 From: outsider at scarynet.org (Alexander Maassen) Date: Fri, 17 Jul 2015 22:50:12 +0200 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers Message-ID: (Sorry Michael for the duplicate, forgot to press reply all :P) No problem making the web more secure, but in such cases I think it would have been better if you could set this behaviour per site, same as with 'invalid/self signed certs'. And in some cases, vendors use weak ciphers because they also utilize less resources. Everyone who has a DRAC knows about it's sluggish performance. Another backdraw of the DRAC's is, they are https only, and you cannot turn this behaviour off. Guess for that the only options would be to make your own interface and utilize the telnet/snmp interface. (Which is probably less secure then SSLv3), or some form of SSLv3 <-> strong cipher proxy. And needing to replace hardware that works perfectly fine for the purposes it's intended for just because a browser refuses to connect to it and denies you the option to make exceptions sounds just like the well known error 'Not enough money spend on hardware' On Fri, July 17, 2015 9:14 pm, Michael O Holstein wrote: >>making 99% of the web secure is better than keeping an old 1% working > > A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the "I'm sorry Dave" sort of attitude. > > As an example .. we have a vendor who, in the current release (last 3 months) still requires "weak" ciphers in authentication responses. That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers. > > My $0.02 > > Michael Holstein > Cleveland State University From michael.holstein at csuohio.edu Fri Jul 17 20:48:24 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Fri, 17 Jul 2015 20:48:24 +0000 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <20150717203027.GB81337@excession.tpb.net> References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com> , <20150717203027.GB81337@excession.tpb.net> Message-ID: >Why do you upgrade your management systems asynchronously to your >applications? You bring this on yourself. Perhaps, but SaaS "management systems" are out of our control. They TELL us when they upgrade, they do not ASK. A web browser isn't really an application, you can't wait to upgrade. Related head-shaker .. the premier vendor of time management (who shall remain nameless) requires an outdated version of java that has a number of known vulnerabilities. They have been doing this for several years now. >Why do you access mission-critical systems that are provably insecure >from systems that also have internet access? Because they are "hosted" magical unicorn "cloud services" .. they ARE ON the Internet. >If it's not mission-critical, then you should explain why you haven't >dumped that vendor yet for shipping insecure software - an insecurity >that is very easy to mitigate by them, should they have chosen to. Contracts, that's why. And it's not "shipping" anything .. these are "enterprise" cloud services that cost on the order of $50k-$100k per year. My $0.02 .. any reference to a company fictional or not is purely coincidental, etc. Michael Holstein Cleveland State University From michael.holstein at csuohio.edu Fri Jul 17 20:59:41 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Fri, 17 Jul 2015 20:59:41 +0000 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: References: Message-ID: Yes, the config option in FF is global .. I'm sure it could be done with an extension though. The 'el cheapo' solution that comes to mind is use a Rasberry Pi with dual ethernet (second via USB) and run Nginx on it .. secure out the front, insecure out the back. It'd cost you something like $50. I'm surprised "SSL stupidifiers" aren't on sale for $9 at Aliexpress or DX. -Mike ________________________________________ From: NANOG on behalf of Alexander Maassen Sent: Friday, July 17, 2015 4:50 PM To: nanog at nanog.org Subject: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers (Sorry Michael for the duplicate, forgot to press reply all :P) No problem making the web more secure, but in such cases I think it would have been better if you could set this behaviour per site, same as with 'invalid/self signed certs'. And in some cases, vendors use weak ciphers because they also utilize less resources. Everyone who has a DRAC knows about it's sluggish performance. Another backdraw of the DRAC's is, they are https only, and you cannot turn this behaviour off. Guess for that the only options would be to make your own interface and utilize the telnet/snmp interface. (Which is probably less secure then SSLv3), or some form of SSLv3 <-> strong cipher proxy. And needing to replace hardware that works perfectly fine for the purposes it's intended for just because a browser refuses to connect to it and denies you the option to make exceptions sounds just like the well known error 'Not enough money spend on hardware' On Fri, July 17, 2015 9:14 pm, Michael O Holstein wrote: >>making 99% of the web secure is better than keeping an old 1% working > > A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the "I'm sorry Dave" sort of attitude. > > As an example .. we have a vendor who, in the current release (last 3 months) still requires "weak" ciphers in authentication responses. That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers. > > My $0.02 > > Michael Holstein > Cleveland State University From cidr-report at potaroo.net Fri Jul 17 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Jul 2015 22:00:01 GMT Subject: The Cidr Report Message-ID: <201507172200.t6HM01ue098109@wattle.apnic.net> This report has been generated at Fri Jul 17 21:14:51 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-07-15 560303 305915 11-07-15 560446 305557 12-07-15 559883 305833 13-07-15 560432 305824 14-07-15 560613 305838 15-07-15 560683 306360 16-07-15 561105 305878 17-07-15 560782 306017 AS Summary 51217 Number of ASes in routing system 20355 Number of ASes announcing only one prefix 3294 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120761600 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 17Jul15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 561291 305997 255294 45.5% All ASes AS22773 3177 166 3011 94.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2758 71 2687 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2699 78 2621 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS9394 2919 314 2605 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS39891 2473 33 2440 98.7% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2286 117 2169 94.9% NET Servi?os de Comunica??o S.A.,BR AS3356 2584 778 1806 69.9% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2949 1234 1715 58.2% KIXS-AS-KR Korea Telecom,KR AS10620 3294 1599 1695 51.5% Telmex Colombia S.A.,CO AS9808 1586 66 1520 95.8% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS7545 2686 1179 1507 56.1% TPG-INTERNET-AP TPG Telecom Limited,AU AS6983 1750 247 1503 85.9% ITCDELTA - Earthlink, Inc.,US AS20115 1868 421 1447 77.5% CHARTER-NET-HKY-NC - Charter Communications,US AS4755 2034 652 1382 67.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS9498 1360 121 1239 91.1% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1615 416 1199 74.2% TWTC - tw telecom holdings, inc.,US AS18566 2064 912 1152 55.8% MEGAPATH5-US - MegaPath Corporation,US AS6147 1398 277 1121 80.2% Telefonica del Peru S.A.A.,PE AS7552 1158 60 1098 94.8% VIETEL-AS-AP Viettel Corporation,VN AS22561 1382 313 1069 77.4% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7303 1630 580 1050 64.4% Telecom Argentina S.A.,AR AS4808 1513 509 1004 66.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS6849 1206 216 990 82.1% UKRTELNET JSC UKRTELECOM,UA AS8151 1702 733 969 56.9% Uninet S.A. de C.V.,MX AS26615 1098 134 964 87.8% Tim Celular S.A.,BR AS8402 984 21 963 97.9% CORBINA-AS OJSC "Vimpelcom",RU AS4788 1168 248 920 78.8% TMNET-AS-AP TM Net, Internet Service Provider,MY AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS4538 2102 1253 849 40.4% ERX-CERNET-BKB China Education and Research Network Center,CN AS38285 977 130 847 86.7% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU Total 57419 12961 44458 77.4% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.17.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.126.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 64.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.57.192.0/22 AS33321 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.228.160.0/20 AS7233 YAHOO-US - Yahoo,US 66.228.176.0/21 AS17110 YAHOO-US2 - Yahoo,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 69.24.96.0/20 AS26804 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 100.64.9.0/24 AS10620 Telmex Colombia S.A.,CO 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.11.160.0/24 AS13216 103.11.161.0/24 AS13216 103.11.162.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.11.163.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.25.144.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.37.188.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.228.8.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.228.224.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.229.152.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.230.124.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.104.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 116.199.200.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.201.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.202.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.203.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.204.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.205.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.206.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.207.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 144.1.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 168.253.32.0/19 AS31856 CABS,ZW 168.253.64.0/20 AS37417 SONIC-Wireless,ZA 170.95.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 179.60.128.0/20 AS26317 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 182.236.116.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 182.236.117.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 182.236.118.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 182.236.119.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.109.188.0/22 AS20912 ASN-PANSERVICE Panservice,IT 185.109.240.0/22 AS20219 EDSI-TECH EDSI-Tech Sarl,CH 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.189.25.0/24 AS39395 HYDRABURX-CORPORATION - HYDRABURX CORPORATION,US 192.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.9.9.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd.,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.103.89.0/24 AS19523 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.59.208.0/20 AS26317 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.133.208.0/20 AS17440 IDNIC-ID Indonesia Network Information Center,ID 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.160.128.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.130.4.0/23 AS4891 FERRI-3 - Ferric Systems, LLC,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 17 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Jul 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201507172200.t6HM02pL098129@wattle.apnic.net> BGP Update Report Interval: 09-Jul-15 -to- 16-Jul-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 216684 5.0% 170.9 -- BSNL-NIB National Internet Backbone,IN 2 - AS21669 126329 2.9% 126329.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 3 - AS22059 113750 2.6% 56875.0 -- -Reserved AS-,ZZ 4 - AS11056 112931 2.6% 112931.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US 5 - AS36947 84263 1.9% 877.7 -- ALGTEL-AS,DZ 6 - AS54169 83988 1.9% 83988.0 -- MGH-ION-1 - Marin General Hospital,US 7 - AS39891 70210 1.6% 53.1 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 8 - AS25438 65707 1.5% 619.9 -- ASN-ICCNET International Computer Company, Ltd.,SA 9 - AS3709 59533 1.4% 2204.9 -- NET-CITY-SA - City of San Antonio,US 10 - AS33659 47554 1.1% 23777.0 -- CMCS - Comcast Cable Communications, Inc.,US 11 - AS3316 43148 1.0% 1269.1 -- RELARN Association of scientific and educational organizations-computer networks users "RELARN",RU 12 - AS24699 40378 0.9% 1009.5 -- IVTELECOM-AS OJSC Rostelecom,RU 13 - AS33287 36114 0.8% 18057.0 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US 14 - AS25563 34671 0.8% 11557.0 -- WEBLAND-AS Webland AG,CH 15 - AS10620 33665 0.8% 15.1 -- Telmex Colombia S.A.,CO 16 - AS28573 32854 0.8% 22.5 -- NET Servi?os de Comunica??o S.A.,BR 17 - AS131090 29996 0.7% 340.9 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 18 - AS59943 28031 0.6% 28031.0 -- RADAR-AS Radar LLC,RU 19 - AS45271 27464 0.6% 58.9 -- ICLNET-AS-AP Idea Cellular Limited,IN 20 - AS13036 24797 0.6% 1549.8 -- TMOBILE-CZ T-Mobile Czech Republic a.s.,CZ TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS21669 126329 2.9% 126329.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - AS11056 112931 2.6% 112931.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US 3 - AS54169 83988 1.9% 83988.0 -- MGH-ION-1 - Marin General Hospital,US 4 - AS22059 113750 2.6% 56875.0 -- -Reserved AS-,ZZ 5 - AS59943 28031 0.6% 28031.0 -- RADAR-AS Radar LLC,RU 6 - AS33659 47554 1.1% 23777.0 -- CMCS - Comcast Cable Communications, Inc.,US 7 - AS33287 36114 0.8% 18057.0 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US 8 - AS25563 34671 0.8% 11557.0 -- WEBLAND-AS Webland AG,CH 9 - AS40637 11492 0.3% 11492.0 -- MAILROUTE - MailRoute, Inc.,US 10 - AS14244 11345 0.3% 11345.0 -- NSIHOSTING-EQX-VA - NSI Hosting,US 11 - AS197914 10370 0.2% 10370.0 -- STOCKHO-AS Stockho Hosting SARL,FR 12 - AS393588 9590 0.2% 9590.0 -- MUBEA-FLO - Mubea,US 13 - AS40493 8153 0.2% 8153.0 -- FACILITYSOURCEINC - FacilitySource,US 14 - AS38000 6270 0.1% 6270.0 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 15 - AS6629 7801 0.2% 3900.5 -- NOAA-AS - NOAA,US 16 - AS47680 10662 0.2% 3554.0 -- NHCS EOBO Limited,IE 17 - AS201558 3398 0.1% 3398.0 -- TFEB-AS The State Bank for Foreign Affairs of Turkmenistan,TM 18 - AS55741 2714 0.1% 2714.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN 19 - AS33440 10471 0.2% 2617.8 -- WEBRULON-NETWORK - webRulon, LLC,US 20 - AS45606 11410 0.3% 2282.0 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.212.8.0/24 126329 2.8% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - 50.202.59.0/24 112931 2.5% AS11056 -- BERGERMONTAGUE - Berger & Montague, P.C,US 3 - 204.80.242.0/24 83988 1.9% AS54169 -- MGH-ION-1 - Marin General Hospital,US 4 - 199.204.107.0/24 83657 1.9% AS33287 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US AS33659 -- CMCS - Comcast Cable Communications, Inc.,US 5 - 105.96.0.0/22 83525 1.9% AS36947 -- ALGTEL-AS,DZ 6 - 76.191.107.0/24 56941 1.3% AS22059 -- -Reserved AS-,ZZ 7 - 64.34.125.0/24 56809 1.3% AS22059 -- -Reserved AS-,ZZ 8 - 61.7.155.0/24 29580 0.7% AS131090 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 9 - 185.65.148.0/24 28031 0.6% AS59943 -- RADAR-AS Radar LLC,RU 10 - 186.208.186.0/24 14937 0.3% AS262741 -- CONECTSUL - COMERCIO E SERVICOS LTDA,BR 11 - 64.5.116.0/24 12783 0.3% AS26972 -- SIRIUS-FIBER - Sirius Fiber, Inc.,US 12 - 92.43.216.0/21 11794 0.3% AS25563 -- WEBLAND-AS Webland AG,CH 13 - 199.89.0.0/21 11492 0.3% AS40637 -- MAILROUTE - MailRoute, Inc.,US 14 - 185.84.192.0/22 11491 0.3% AS25563 -- WEBLAND-AS Webland AG,CH 15 - 178.174.96.0/19 11386 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 16 - 208.71.166.0/24 11345 0.2% AS14244 -- NSIHOSTING-EQX-VA - NSI Hosting,US 17 - 74.117.78.0/24 11339 0.2% AS26972 -- SIRIUS-FIBER - Sirius Fiber, Inc.,US 18 - 88.87.160.0/19 10650 0.2% AS47680 -- NHCS EOBO Limited,IE 19 - 130.0.192.0/21 10370 0.2% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 20 - 192.58.137.0/24 9590 0.2% AS393588 -- MUBEA-FLO - Mubea,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jfbeam at gmail.com Fri Jul 17 23:14:53 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 17 Jul 2015 19:14:53 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: On Fri, 17 Jul 2015 06:25:26 -0400, Christopher Morrow wrote: > mean that your UBee has to do dhcpv6? (or the downstream thingy from > the UBee has to do dhcpv6?) The Ubee "router" is in bridge mode. Customers have ZERO access to the thing, even when it is running in routed mode. So I have no idea what it's trying to do. All I can say is no RAs are coming from it (through it/whatever) It *could* be it's blocking it -- it's multicast, so who knows what it's doing with it. Without RAs, nothing connected to it will even attempt IPv6 -- the RA being the indicator to use DHCP or not, and who's the router. And further, when I tell my Cisco 1841 to do DHCP anyway, I get no answer. So, the blanket statement that "it's ready" isn't true. From mpalmer at hezmatt.org Sat Jul 18 02:39:02 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 18 Jul 2015 12:39:02 +1000 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> Message-ID: <20150718023857.GW18063@hezmatt.org> On Fri, Jul 17, 2015 at 10:26:22AM +0200, Alexander Maassen wrote: > Ok, it is good to think about security, but not giving you any chance to > make exceptions is simply forcing users to use another browser in order to > manage those devices, or to keep an old machine around that not gets > updated. Hey, if those DRACs can't get updated to not use piss-weak ciphers, what's the problem with having one more machine laying around unpatched to manage them? - Matt From mpalmer at hezmatt.org Sat Jul 18 02:45:34 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 18 Jul 2015 12:45:34 +1000 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com> Message-ID: <20150718024534.GX18063@hezmatt.org> On Fri, Jul 17, 2015 at 07:14:17PM +0000, Michael O Holstein wrote: > >making 99% of the web secure is better than keeping an old 1% working > > A fine idea, unless for $reason your application is among the 1% .. > nevermind the arrogance of the "I'm sorry Dave" sort of attitude. First they came for SSLv2, and I said nothing because... > As an example .. we have a vendor who, in the current release (last 3 > months) still requires "weak" ciphers in authentication responses. That > was mostly okay until another vendor (with more sense) wanted to auth the > same way but only permitted strong ciphers. So get up your vendors to update their stuff, and *preferably* before a super-critical hole is found in protocols that should have ideally died a natural death years ago. TLS 1.2, AES, and SHA-256 aren't exactly "OMFG new!" at this stage of the game. Also, take this as a learning experience: next time, make sure RFPs and contracts include an undertaking to maintain compatibility with reasonably recent standards, and financial penalties for the vendor if their failure to do so results in operational problems for you. - Matt -- aren't they getting rarer than amigas now? just without all that fuzzy "good times" nostalgia? -- Ron Lee, in #debian-devel, on Itanic From tqr2813d376cjozqap1l at tutanota.com Sat Jul 18 02:50:57 2015 From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com) Date: Sat, 18 Jul 2015 02:50:57 +0000 (UTC) Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <20150718024534.GX18063@hezmatt.org> References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <<1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com>> <> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <<3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org>> <55A8F80E.60900@direcpath.com> <<55A8F80E.60900@direcpath.com>> <> <> <20150718024534.GX18063@hezmatt.org> Message-ID: Weak ciphers? Old (insecure) protocol versions? Open security issues? Vendor will never provide a patch? Trash goes in the trash bin, no exceptions. From seth.mos at dds.nl Sat Jul 18 10:45:43 2015 From: seth.mos at dds.nl (Seth Mos) Date: Sat, 18 Jul 2015 12:45:43 +0200 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> Message-ID: <55AA2E57.6080303@dds.nl> Ricky Beam schreef op 18-7-2015 om 1:14: > On Fri, 17 Jul 2015 06:25:26 -0400, Christopher Morrow > wrote: >> mean that your UBee has to do dhcpv6? (or the downstream thingy from >> the UBee has to do dhcpv6?) > > The Ubee "router" is in bridge mode. Customers have ZERO access to the > thing, even when it is running in routed mode. So I have no idea what > it's trying to do. All I can say is no RAs are coming from it > (through it/whatever) It *could* be it's blocking it -- it's > multicast, so who knows what it's doing with it. Without RAs, nothing > connected to it will even attempt IPv6 -- the RA being the indicator > to use DHCP or not, and who's the router. > > And further, when I tell my Cisco 1841 to do DHCP anyway, I get no > answer. > > So, the blanket statement that "it's ready" isn't true. For a point of interest, the Ubee 320 and 321 wireless routers/modems are in use by Ziggo in the Netherlands. Although they've rolled back the 320 modems to a older firmware, the 321 is still active on their IPv6 rollout. The problems were not strictly related to Ipv6 perse, but the newer firmware broken Voice on these all-the -things-in-one devices. The 321 appears to be unaffected and is still active, although in just a few regions at this point of the rollout. What's very specific about this rollout in relation to the above, is that Ziggo is currently only supporting IPv6 with the Ubee in router mode (with the wifi hotspot). The good news is that it also operates a DHCP-PD server so that you can connect your own router to the Ubee and still get IPv6 routed to you out of the /56 allocated to the customer. For now, all the customers with the Ubee in bridge mode are SOL. It's not clear what the reason is, but Ubee in bridge mode with IPv6 is listed on the road map. If that's intentional policy or that the firmware isn't ready yet is not clear at this point. Regards, Seth From george.metz at gmail.com Sat Jul 18 14:02:39 2015 From: george.metz at gmail.com (George Metz) Date: Sat, 18 Jul 2015 10:02:39 -0400 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com> <20150718024534.GX18063@hezmatt.org> Message-ID: Federal government lands on you like a sack of bricks if you don't provide this information through their (in)secure website. No exceptions. Sometimes you can't fire the vendor because they're not a vendor, they're a freaking regulatory agency with the power to crush you like a bug, and a 5 year approval process to get anything done, never mind a month turnaround for a recently discovered exploit. On Fri, Jul 17, 2015 at 10:50 PM, wrote: > Weak ciphers? Old (insecure) protocol versions? Open security issues? > Vendor > will never provide a patch? Trash goes in the trash bin, no exceptions. > From trelane at trelane.net Sat Jul 18 18:08:39 2015 From: trelane at trelane.net (Andrew Kirch) Date: Sat, 18 Jul 2015 14:08:39 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <55AA2E57.6080303@dds.nl> References: <20150712212557.GG3716@bender.unx.cpp.edu> <55AA2E57.6080303@dds.nl> Message-ID: I had to beat up on AT&T quite a bit, but instead of letting them "make notes", escalate to tier-2 because you can't reach work. Explain that you must have IPv6 to reach work to the tier-2. If they won't help demand to be escalated further. Your time on the phone costs them money. On Sat, Jul 18, 2015 at 6:45 AM, Seth Mos wrote: > Ricky Beam schreef op 18-7-2015 om 1:14: > > On Fri, 17 Jul 2015 06:25:26 -0400, Christopher Morrow < >> morrowc.lists at gmail.com> wrote: >> >>> mean that your UBee has to do dhcpv6? (or the downstream thingy from >>> the UBee has to do dhcpv6?) >>> >> >> The Ubee "router" is in bridge mode. Customers have ZERO access to the >> thing, even when it is running in routed mode. So I have no idea what it's >> trying to do. All I can say is no RAs are coming from it (through >> it/whatever) It *could* be it's blocking it -- it's multicast, so who knows >> what it's doing with it. Without RAs, nothing connected to it will even >> attempt IPv6 -- the RA being the indicator to use DHCP or not, and who's >> the router. >> >> And further, when I tell my Cisco 1841 to do DHCP anyway, I get no answer. >> >> So, the blanket statement that "it's ready" isn't true. >> > For a point of interest, the Ubee 320 and 321 wireless routers/modems are > in use by Ziggo in the Netherlands. > > Although they've rolled back the 320 modems to a older firmware, the 321 > is still active on their IPv6 rollout. The problems were not strictly > related to Ipv6 perse, but the newer firmware broken Voice on these all-the > -things-in-one devices. > > The 321 appears to be unaffected and is still active, although in just a > few regions at this point of the rollout. > > What's very specific about this rollout in relation to the above, is that > Ziggo is currently only supporting IPv6 with the Ubee in router mode (with > the wifi hotspot). The good news is that it also operates a DHCP-PD server > so that you can connect your own router to the Ubee and still get IPv6 > routed to you out of the /56 allocated to the customer. > > For now, all the customers with the Ubee in bridge mode are SOL. It's not > clear what the reason is, but Ubee in bridge mode with IPv6 is listed on > the road map. If that's intentional policy or that the firmware isn't ready > yet is not clear at this point. > > Regards, > Seth > From morrowc.lists at gmail.com Sat Jul 18 18:16:34 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 18 Jul 2015 14:16:34 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> <55AA2E57.6080303@dds.nl> Message-ID: On Sat, Jul 18, 2015 at 2:08 PM, Andrew Kirch wrote: > I had to beat up on AT&T quite a bit, but instead of letting them "make > notes", escalate to tier-2 because you can't reach work. Explain that you > must have IPv6 to reach work to the tier-2. If they won't help demand to > be escalated further. Your time on the phone costs them money. it's fun to screw up their ARPU, but really... in the end, if they don't want to be helpful to your cause / the intertubes, then why contnue to give them duckets? i don't see any hope for VZ nn this, sadly... and I bet ATT is taking it's time doing something useful as well, because 'telco', and because they have enough v4 that they don't HAVE to do anything yet. (they can still roll out territories with v4 for a long while to come) spend your money on providers that will do what you want... Also it's good to recognize that your single link move from ATT -> comcast isn't going to move the needle at ATT as far as 'gosh we really should care about this now!' -chris > On Sat, Jul 18, 2015 at 6:45 AM, Seth Mos wrote: > >> Ricky Beam schreef op 18-7-2015 om 1:14: >> >> On Fri, 17 Jul 2015 06:25:26 -0400, Christopher Morrow < >>> morrowc.lists at gmail.com> wrote: >>> >>>> mean that your UBee has to do dhcpv6? (or the downstream thingy from >>>> the UBee has to do dhcpv6?) >>>> >>> >>> The Ubee "router" is in bridge mode. Customers have ZERO access to the >>> thing, even when it is running in routed mode. So I have no idea what it's >>> trying to do. All I can say is no RAs are coming from it (through >>> it/whatever) It *could* be it's blocking it -- it's multicast, so who knows >>> what it's doing with it. Without RAs, nothing connected to it will even >>> attempt IPv6 -- the RA being the indicator to use DHCP or not, and who's >>> the router. >>> >>> And further, when I tell my Cisco 1841 to do DHCP anyway, I get no answer. >>> >>> So, the blanket statement that "it's ready" isn't true. >>> >> For a point of interest, the Ubee 320 and 321 wireless routers/modems are >> in use by Ziggo in the Netherlands. >> >> Although they've rolled back the 320 modems to a older firmware, the 321 >> is still active on their IPv6 rollout. The problems were not strictly >> related to Ipv6 perse, but the newer firmware broken Voice on these all-the >> -things-in-one devices. >> >> The 321 appears to be unaffected and is still active, although in just a >> few regions at this point of the rollout. >> >> What's very specific about this rollout in relation to the above, is that >> Ziggo is currently only supporting IPv6 with the Ubee in router mode (with >> the wifi hotspot). The good news is that it also operates a DHCP-PD server >> so that you can connect your own router to the Ubee and still get IPv6 >> routed to you out of the /56 allocated to the customer. >> >> For now, all the customers with the Ubee in bridge mode are SOL. It's not >> clear what the reason is, but Ubee in bridge mode with IPv6 is listed on >> the road map. If that's intentional policy or that the firmware isn't ready >> yet is not clear at this point. >> >> Regards, >> Seth >> From rafael at gav.ufsc.br Sat Jul 18 19:43:32 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 18 Jul 2015 14:43:32 -0500 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> <55AA2E57.6080303@dds.nl> Message-ID: The best way to "complain" is to simply move the service to another provider (when possible). 50 bucks a month of revenue to them is not worth the hassle of having a tech user asking for all sorts of non-standard configs. It shouldn't be that way, but that's how it usually goes. Think about it, everyone else (almost literally) is watching cat videos on youtube and streaming shows on Netflix, so as long as that works, they will be making their money and not caring about anything else. When I got TWC business class a while back, I asked the account manager to draft a month to month contract. When I realized their DOCSIS network sucked, and that my gateway was going dark several times a week, I just cancelled, didn't bother arguing with them. I bet I was the only person in my block that cared about 99.9% uptime, so why would they bother doing anything. On Sat, Jul 18, 2015 at 1:08 PM, Andrew Kirch wrote: > I had to beat up on AT&T quite a bit, but instead of letting them "make > notes", escalate to tier-2 because you can't reach work. Explain that you > must have IPv6 to reach work to the tier-2. If they won't help demand to > be escalated further. Your time on the phone costs them money. > > On Sat, Jul 18, 2015 at 6:45 AM, Seth Mos wrote: > > > Ricky Beam schreef op 18-7-2015 om 1:14: > > > > On Fri, 17 Jul 2015 06:25:26 -0400, Christopher Morrow < > >> morrowc.lists at gmail.com> wrote: > >> > >>> mean that your UBee has to do dhcpv6? (or the downstream thingy from > >>> the UBee has to do dhcpv6?) > >>> > >> > >> The Ubee "router" is in bridge mode. Customers have ZERO access to the > >> thing, even when it is running in routed mode. So I have no idea what > it's > >> trying to do. All I can say is no RAs are coming from it (through > >> it/whatever) It *could* be it's blocking it -- it's multicast, so who > knows > >> what it's doing with it. Without RAs, nothing connected to it will even > >> attempt IPv6 -- the RA being the indicator to use DHCP or not, and who's > >> the router. > >> > >> And further, when I tell my Cisco 1841 to do DHCP anyway, I get no > answer. > >> > >> So, the blanket statement that "it's ready" isn't true. > >> > > For a point of interest, the Ubee 320 and 321 wireless routers/modems are > > in use by Ziggo in the Netherlands. > > > > Although they've rolled back the 320 modems to a older firmware, the 321 > > is still active on their IPv6 rollout. The problems were not strictly > > related to Ipv6 perse, but the newer firmware broken Voice on these > all-the > > -things-in-one devices. > > > > The 321 appears to be unaffected and is still active, although in just a > > few regions at this point of the rollout. > > > > What's very specific about this rollout in relation to the above, is that > > Ziggo is currently only supporting IPv6 with the Ubee in router mode > (with > > the wifi hotspot). The good news is that it also operates a DHCP-PD > server > > so that you can connect your own router to the Ubee and still get IPv6 > > routed to you out of the /56 allocated to the customer. > > > > For now, all the customers with the Ubee in bridge mode are SOL. It's not > > clear what the reason is, but Ubee in bridge mode with IPv6 is listed on > > the road map. If that's intentional policy or that the firmware isn't > ready > > yet is not clear at this point. > > > > Regards, > > Seth > > > From owen at delong.com Sun Jul 19 06:00:47 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Jul 2015 23:00:47 -0700 Subject: Dual stack IPv6 for IPv4 depletion In-Reply-To: <55A92A8B.5070208@ttec.com> References: <20150716221723.33698.qmail@ary.lan> <55A8305C.10401@ttec.com> <45DA2851-60BD-41F2-8B62-36A9427D3C3E@delong.com> <55A92A8B.5070208@ttec.com> Message-ID: > On Jul 17, 2015, at 09:17 , Joe Maimon wrote: > > > > Owen DeLong wrote: >> >>> On Jul 16, 2015, at 15:29 , Joe Maimon wrote: >>> >>> All I am advocating is that if ever another draft standard comes along to enable people to try and make something of it, lead follow or get out of the way. >> >> Sometimes good leadership is knowing when to say ?not just no, but hell no.? >> >> Owen > > This is not one of them. Your stated reason for hell no is that you want no distractions from ipv6 rollout. That is not leadership. That is dictatorship via tyranny of the minority, enabled by consensus, Tryanny of the minority enabled by consensus? That?s an amusing concept. If we were such a minority, how did we get consensus. Reality check, Joe? You?re pretty much the only one left still beating this drum. Owen From ab at lists.gxis.de Sun Jul 19 10:59:38 2015 From: ab at lists.gxis.de (Alexander Bochmann) Date: Sun, 19 Jul 2015 12:59:38 +0200 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: References: <1db40030d63d47dabec629179d0ac63d@pur-vm-exch13n1.ox.com> <3572af1c8b7ed5dbc7941230d68b07ee.squirrel@mail.scarynet.org> <55A8F80E.60900@direcpath.com> Message-ID: <20150719105937.GA1223@gxis.de> ...on Fri, Jul 17, 2015 at 01:42:37PM +0000, Matthew Huff wrote: > After making the about:config changes, no warning is given to the user about the bad ciphers. Even if you click the SSL lock icon, no warning is given. Only if you know that the connection being made with "TLS_RSA_WITH_AES_128_CBC_SHA,128 bit keys, TLS 1.0" is a bad thing would you have any clue. I've found the Calomel SSL Validation Add-on to be quite useful in that regard. It adds some controls to access FF encryptions settings, as well as a quick overview on the quality of a TLS connection: https://calomel.org/firefox_ssl_validation.html https://addons.mozilla.org/en-us/firefox/addon/calomel-ssl-validation/ In general, an old version of Firefox Portable seems a must-have item in the admin toolchest right now - there's just too much stuff still out there that can't be accessed with either current Firefox or IE anymore. Alex. From nanog at ics-il.net Sun Jul 19 20:04:52 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 19 Jul 2015 15:04:52 -0500 (CDT) Subject: SIP trunking providers In-Reply-To: Message-ID: <84998225.2803.1437336324378.JavaMail.mhammett@ThunderFuck> I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Rafael Possamai" To: nanog at nanog.org Sent: Friday, June 19, 2015 4:40:48 PM Subject: SIP trunking providers Would anyone in the list be able to recommend a SIP trunk provider in the Chicago area? Not a VoIP expert, so just looking for someone with previous experience. Thanks, Rafael From dovid at telecurve.com Sun Jul 19 20:45:38 2015 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 19 Jul 2015 20:45:38 +0000 Subject: SIP trunking providers Message-ID: <268666819-1437338740-cardhu_decombobulator_blackberry.rim.net-777824434-@b11.c3.bise6.blackberry> Almost every itsp will do that to your traffic regardless of where you see it going. Under 100ms and you won't even notice it. ------Original Message------ From: Mike Hammett Sender: NANOG Cc: nanog at nanog.org Subject: Re: SIP trunking providers Sent: Jul 19, 2015 16:04 I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Rafael Possamai" To: nanog at nanog.org Sent: Friday, June 19, 2015 4:40:48 PM Subject: SIP trunking providers Would anyone in the list be able to recommend a SIP trunk provider in the Chicago area? Not a VoIP expert, so just looking for someone with previous experience. Thanks, Rafael Regards, Dovid From will.mcdermott at sjsu.edu Fri Jul 17 21:06:32 2015 From: will.mcdermott at sjsu.edu (Will M.) Date: Fri, 17 Jul 2015 14:06:32 -0700 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: References: Message-ID: <55A96E58.2030401@sjsu.edu> Load balancers can also be used like this, while maintaining redundancy (assuming HA LB config). Terminate SSL/TLS on the LB and run plain-text to the application/appliance. As long as the load balancer is in an acceptable part of the network. --Will On 7/17/15 1:59 PM, Michael O Holstein wrote: > Yes, the config option in FF is global .. I'm sure it could be done with an extension though. > > The 'el cheapo' solution that comes to mind is use a Rasberry Pi with dual ethernet (second via USB) and run Nginx on it .. secure out the front, insecure out the back. It'd cost you something like $50. > > I'm surprised "SSL stupidifiers" aren't on sale for $9 at Aliexpress or DX. > > -Mike > > ________________________________________ > From: NANOG on behalf of Alexander Maassen > Sent: Friday, July 17, 2015 4:50 PM > To: nanog at nanog.org > Subject: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers > > (Sorry Michael for the duplicate, forgot to press reply all :P) > > No problem making the web more secure, but in such cases I think it would > have been better if you could set this behaviour per site, same as with > 'invalid/self signed certs'. And in some cases, vendors use weak ciphers > because they also utilize less resources. Everyone who has a DRAC knows > about it's sluggish performance. > > Another backdraw of the DRAC's is, they are https only, and you cannot > turn this behaviour off. Guess for that the only options would be to make > your own interface and utilize the telnet/snmp interface. (Which is > probably less secure then SSLv3), or some form of SSLv3 <-> strong cipher > proxy. > > And needing to replace hardware that works perfectly fine for the purposes > it's intended for just because a browser refuses to connect to it and > denies you the option to make exceptions sounds just like the well known > error 'Not enough money spend on hardware' > > On Fri, July 17, 2015 9:14 pm, Michael O Holstein wrote: >>> making 99% of the web secure is better than keeping an old 1% working >> A fine idea, unless for $reason your application is among the 1% .. > nevermind the arrogance of the "I'm sorry Dave" sort of attitude. >> As an example .. we have a vendor who, in the current release (last 3 > months) still requires "weak" ciphers in authentication responses. That > was mostly okay until another vendor (with more sense) wanted to auth > the same way but only permitted strong ciphers. >> My $0.02 >> >> Michael Holstein >> Cleveland State University > > From tqr2813d376cjozqap1l at tutanota.com Mon Jul 20 03:02:38 2015 From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com) Date: Mon, 20 Jul 2015 03:02:38 +0000 (UTC) Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: <55A96E58.2030401@sjsu.edu> References: <> <> <55A96E58.2030401@sjsu.edu> Message-ID: 17. Jul 2015 21:06 by will.mcdermott at sjsu.edu: > Load balancers can also be used like this, while maintaining redundancy > (assuming HA LB config). Terminate SSL/TLS on the LB and run plain-text to > the application/appliance. As long as the load balancer is in an acceptable > part of the network. > Hm, that seems familiar... https://i.imgur.com/ZhQLJmG.jpg From nathana at fsr.com Mon Jul 20 09:11:37 2015 From: nathana at fsr.com (Nathan Anderson) Date: Mon, 20 Jul 2015 02:11:37 -0700 Subject: SIP trunking providers In-Reply-To: <84998225.2803.1437336324378.JavaMail.mhammett@ThunderFuck> References: , <84998225.2803.1437336324378.JavaMail.mhammett@ThunderFuck> Message-ID: Maybe I'm missing something here, but what does it matter if the RTP from your perspective ends in Chicago or not? If it does end in Chicago, that only means they are proxying the audio before sending it on to the actual media gateway for that call where it finally drops onto the PSTN. So all that happens is that the audio latency remains the same (or worse, because of the additional, unnecessary proxy) AND that the actual media gateway remains hidden from you. You won't be able to actually test and see the latency to the MG, and you will be under the (false) impression that latency across all calls is equally "good" because you are only measuring RTT to a specific and common media proxy. By sending the audio directly to an MG closer to the point of exit from IP-land, it is taking a more direct route to the callee than you are seemingly asking for. If you're not talking about adding a proxy to the equation, are you expecting to find a provider in Chicago that immediately goes from IP to PSTN within Chicago, regardless of the actual destination of the call? Circuit-switched TDM is not a no-latency connection. Physics is involved here. The farther apart the caller is from the callee, the more latency there will be, regardless of the medium. All other things being equal (similar network path, etc.), I doubt IP packet switching significantly increases the latency over and above TDM call trunking. But I'm not an expert, and again, if I'm missing something here, I would love to be proven wrong. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com ________________________________________ From: NANOG [nanog-bounces at nanog.org] On Behalf Of Mike Hammett [nanog at ics-il.net] Sent: Sunday, July 19, 2015 1:04 PM Cc: nanog at nanog.org Subject: Re: SIP trunking providers I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Rafael Possamai" To: nanog at nanog.org Sent: Friday, June 19, 2015 4:40:48 PM Subject: SIP trunking providers Would anyone in the list be able to recommend a SIP trunk provider in the Chicago area? Not a VoIP expert, so just looking for someone with previous experience. Thanks, Rafael From nanog at ics-il.net Mon Jul 20 10:36:51 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 20 Jul 2015 05:36:51 -0500 (CDT) Subject: SIP trunking providers In-Reply-To: Message-ID: <1212444734.2959.1437388624829.JavaMail.mhammett@ThunderFuck> I want the gateway in Chicago as well. I am Chicago based. The end users are Chicago based. Therefore the origination would be coming from a Chicago area gateway. Half of the calls (inbound would be guaranteed to be local as they'd be coming in through a local tandem anyway. Most of the termination traffic would again be to local numbers, therefore would again have to be through local tandems. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Nathan Anderson" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, July 20, 2015 4:11:37 AM Subject: RE: SIP trunking providers Maybe I'm missing something here, but what does it matter if the RTP from your perspective ends in Chicago or not? If it does end in Chicago, that only means they are proxying the audio before sending it on to the actual media gateway for that call where it finally drops onto the PSTN. So all that happens is that the audio latency remains the same (or worse, because of the additional, unnecessary proxy) AND that the actual media gateway remains hidden from you. You won't be able to actually test and see the latency to the MG, and you will be under the (false) impression that latency across all calls is equally "good" because you are only measuring RTT to a specific and common media proxy. By sending the audio directly to an MG closer to the point of exit from IP-land, it is taking a more direct route to the callee than you are seemingly asking for. If you're not talking about adding a proxy to the equation, are you expecting to find a provider in Chicago that immediately goes from IP to PSTN within Chicago, regardless of the actual destination of the call? Circuit-switched TDM is not a no-latency connection. Physics is involved here. The farther apart the caller is from the callee, the more latency there will be, regardless of the medium. All other things being equal (similar network path, etc.), I doubt IP packet switching significantly increases the latency over and above TDM call trunking. But I'm not an expert, and again, if I'm missing something here, I would love to be proven wrong. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com ________________________________________ From: NANOG [nanog-bounces at nanog.org] On Behalf Of Mike Hammett [nanog at ics-il.net] Sent: Sunday, July 19, 2015 1:04 PM Cc: nanog at nanog.org Subject: Re: SIP trunking providers I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Rafael Possamai" To: nanog at nanog.org Sent: Friday, June 19, 2015 4:40:48 PM Subject: SIP trunking providers Would anyone in the list be able to recommend a SIP trunk provider in the Chicago area? Not a VoIP expert, so just looking for someone with previous experience. Thanks, Rafael From owen at delong.com Mon Jul 20 13:04:24 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jul 2015 06:04:24 -0700 Subject: SIP trunking providers In-Reply-To: <1212444734.2959.1437388624829.JavaMail.mhammett@ThunderFuck> References: <1212444734.2959.1437388624829.JavaMail.mhammett@ThunderFuck> Message-ID: <2D72811B-9366-4210-8A9B-13B935A4DE33@delong.com> Why not set up a small Asterisk box in a local datacenter and only trunk out the non-local calls? Owen > On Jul 20, 2015, at 03:36 , Mike Hammett wrote: > > I want the gateway in Chicago as well. > > I am Chicago based. The end users are Chicago based. Therefore the origination would be coming from a Chicago area gateway. Half of the calls (inbound would be guaranteed to be local as they'd be coming in through a local tandem anyway. Most of the termination traffic would again be to local numbers, therefore would again have to be through local tandems. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Nathan Anderson" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Monday, July 20, 2015 4:11:37 AM > Subject: RE: SIP trunking providers > > Maybe I'm missing something here, but what does it matter if the RTP from your perspective ends in Chicago or not? If it does end in Chicago, that only means they are proxying the audio before sending it on to the actual media gateway for that call where it finally drops onto the PSTN. So all that happens is that the audio latency remains the same (or worse, because of the additional, unnecessary proxy) AND that the actual media gateway remains hidden from you. You won't be able to actually test and see the latency to the MG, and you will be under the (false) impression that latency across all calls is equally "good" because you are only measuring RTT to a specific and common media proxy. By sending the audio directly to an MG closer to the point of exit from IP-land, it is taking a more direct route to the callee than you are seemingly asking for. > > If you're not talking about adding a proxy to the equation, are you expecting to find a provider in Chicago that immediately goes from IP to PSTN within Chicago, regardless of the actual destination of the call? Circuit-switched TDM is not a no-latency connection. Physics is involved here. The farther apart the caller is from the callee, the more latency there will be, regardless of the medium. All other things being equal (similar network path, etc.), I doubt IP packet switching significantly increases the latency over and above TDM call trunking. But I'm not an expert, and again, if I'm missing something here, I would love to be proven wrong. > > -- > Nathan Anderson > First Step Internet, LLC > nathana at fsr.com > > ________________________________________ > From: NANOG [nanog-bounces at nanog.org] On Behalf Of Mike Hammett [nanog at ics-il.net] > Sent: Sunday, July 19, 2015 1:04 PM > Cc: nanog at nanog.org > Subject: Re: SIP trunking providers > > I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Rafael Possamai" > To: nanog at nanog.org > Sent: Friday, June 19, 2015 4:40:48 PM > Subject: SIP trunking providers > > Would anyone in the list be able to recommend a SIP trunk provider in the > Chicago area? Not a VoIP expert, so just looking for someone with previous > experience. > > > Thanks, > Rafael > > From jgreco at ns.sol.net Mon Jul 20 13:21:17 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 20 Jul 2015 08:21:17 -0500 (CDT) Subject: SIP trunking providers In-Reply-To: <2D72811B-9366-4210-8A9B-13B935A4DE33@delong.com> Message-ID: <201507201321.t6KDLHx0007944@aurora.sol.net> > Why not set up a small Asterisk box in a local datacenter and only trunk = > out the non-local calls? And do what with the local calls, then? You're still left with the problem of getting calls to and from the PSTN. Not everyone wants to deal with the hassle of dealing with POTS or T1 gatewaying. In general, it isn't practical to do on a small scale any more, especially as one looks forward a few years to the inevitable dismantling of the legacy POTS network. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From owen at delong.com Mon Jul 20 13:38:43 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jul 2015 06:38:43 -0700 Subject: SIP trunking providers In-Reply-To: <201507201321.t6KDLHx0007944@aurora.sol.net> References: <201507201321.t6KDLHx0007944@aurora.sol.net> Message-ID: > On Jul 20, 2015, at 06:21 , Joe Greco wrote: > >> Why not set up a small Asterisk box in a local datacenter and only trunk = >> out the non-local calls? > > And do what with the local calls, then? You're still left with the > problem of getting calls to and from the PSTN. > > Not everyone wants to deal with the hassle of dealing with POTS or T1 > gatewaying. In general, it isn't practical to do on a small scale any > more, especially as one looks forward a few years to the inevitable > dismantling of the legacy POTS network. If you?re going to the PSTN, who gives a shit where you do the interconnect as long as its within 100ms. If most of your calls are VOIP<->VOIP within Chicago, then it makes some sense to set up a box and just send the external calls out to the trunking provider where you no longer really care where they are. Absent significant network suckage, there?s no place in the contiguous US that isn?t within 100 ms of any other place in the contiguous US these days. Owen From SNaslund at medline.com Mon Jul 20 13:49:20 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 20 Jul 2015 13:49:20 +0000 Subject: SIP trunking providers In-Reply-To: References: <201507201321.t6KDLHx0007944@aurora.sol.net> Message-ID: <9578293AE169674F9A048B2BC9A081B401C70ABA80@MUNPRDMBXA1.medline.com> End to end delay is not the most limiting factor. Jitter is the issue and packet drops are the other issue that matters (more importantly the distribution of drops). I think the best reason to select the local provider over the distant one is that the sooner he gets off the IP network the less impairments he will run into. The TDM network as antiquated as it is, is less susceptible to congestion and call impairments than an IP backbone network is. I can tell you from running a bunch of International VOIP networks that they are just not as reliable as TDM. The average internet connection just does not meet the reliability standards that the TDM voice network has achieved. IP networks are affected by congestion and routing issues whereas the TDM network seldom has these type of problems. An outage on a TDM circuit rarely affects other TDM circuits so they see a lot less higher level outages. I can understand why he does not want to haul his voice cross country over IP when he is exiting locally most of the time. Yes, I understand that the carrier might very well be hauling that traffic via IP even after he gets to his gateway point but at that point it becomes their problem to deal with. Steven Naslund Chicago IL >If you?re going to the PSTN, who gives a shit where you do the interconnect as long as its within 100ms. > >If most of your calls are VOIP<->VOIP within Chicago, then it makes some sense to set up a box and just send the external calls out to the trunking provider where >you no longer really care where they are. > >Absent significant network suckage, there?s no place in the contiguous US that isn?t within 100 ms of any other place in the contiguous US these days. > >Owen From rafael at gav.ufsc.br Mon Jul 20 15:21:28 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Mon, 20 Jul 2015 10:21:28 -0500 Subject: SIP trunking providers In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C70ABA80@MUNPRDMBXA1.medline.com> References: <201507201321.t6KDLHx0007944@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B401C70ABA80@MUNPRDMBXA1.medline.com> Message-ID: When I originally posted the thread, I had asked Chicago due to physical proximity, and my assumption being the lesser the number of hops, the lower the probability of running into issues (latency, jitter and congestion). On the other hand, one of my sandboxes are out of Las Vegas and I haven't had any issues yet, but the number of test calls I've ran aren't enough to say with confidence that distance and hops don't matter (indirect ways of measuring latency, etc). Another thing is, having your packets stay in Chicago and in Chicago only is a nice thing, the efficiency of your overall system would be higher for what it's worth, but as an example, the 2nd hop this e-mail is taking to get delivered to Nanog is about 100 miles, who knows about the other ones. On Mon, Jul 20, 2015 at 8:49 AM, Naslund, Steve wrote: > End to end delay is not the most limiting factor. Jitter is the issue and > packet drops are the other issue that matters (more importantly the > distribution of drops). I think the best reason to select the local > provider over the distant one is that the sooner he gets off the IP network > the less impairments he will run into. The TDM network as antiquated as it > is, is less susceptible to congestion and call impairments than an IP > backbone network is. I can tell you from running a bunch of International > VOIP networks that they are just not as reliable as TDM. The average > internet connection just does not meet the reliability standards that the > TDM voice network has achieved. IP networks are affected by congestion and > routing issues whereas the TDM network seldom has these type of problems. > An outage on a TDM circuit rarely affects other TDM circuits so they see a > lot less higher level outages. I can understand why he does not want to > haul his voice cross country over IP when he is exiting locally most of the > time. > > Yes, I understand that the carrier might very well be hauling that traffic > via IP even after he gets to his gateway point but at that point it becomes > their problem to deal with. > > Steven Naslund > Chicago IL > > > >If you?re going to the PSTN, who gives a shit where you do the > interconnect as long as its within 100ms. > > > >If most of your calls are VOIP<->VOIP within Chicago, then it makes some > sense to set up a box and just send the external calls out to the trunking > provider where >you no longer really care where they are. > > > >Absent significant network suckage, there?s no place in the contiguous > US that isn?t within 100 ms of any other place in the contiguous US these > days. > > > >Owen > > From drew.weaver at thenap.com Mon Jul 20 15:51:27 2015 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 20 Jul 2015 15:51:27 +0000 Subject: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers In-Reply-To: References: <> <> <55A96E58.2030401@sjsu.edu> Message-ID: <9d86692294174a71860802c9f741be58@EXCHANGE2K13.thenap.com> Is this also why you can't login to wells fargo online using firefox? Neat. =) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of tqr2813d376cjozqap1l at tutanota.com Sent: Sunday, July 19, 2015 11:03 PM To: Will M. Cc: nanog at nanog.org Subject: Re: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers 17. Jul 2015 21:06 by will.mcdermott at sjsu.edu: > Load balancers can also be used like this, while maintaining > redundancy (assuming HA LB config). Terminate SSL/TLS on the LB and > run plain-text to the application/appliance. As long as the load > balancer is in an acceptable part of the network. > Hm, that seems familiar... https://i.imgur.com/ZhQLJmG.jpg From drew.weaver at thenap.com Mon Jul 20 15:57:14 2015 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 20 Jul 2015 15:57:14 +0000 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours Message-ID: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> Has anyone else seen a massive amount of illegitimate UDP 1720 traffic coming from China being sent towards IP addresses which provide VoIP services? I'm talking in the 20-30Gbps range? The first incident was yesterday at around 13:00 EST, the second incident was today at 09:00 EST. I'm assuming this is just another DDoS like all others, but I would be interested to hear if I am not the only one seeing this. On list or off-list is fine. Thanks, -Drew From jared at puck.nether.net Mon Jul 20 16:06:08 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 20 Jul 2015 12:06:08 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> Message-ID: <52172AF8-7B37-4BBF-BBC5-9C71409E38A8@puck.nether.net> I?m sure this is just the extension of all the UDP amplification attacks that are ongoing. My experience is that 1720/CUCM should not be connected to a public network as those devices are often not well maintained or patched. If it?s of value I can look at adding this to the set of things that are enumerated as part of the general UDP amplification problems that we continue to face due to the lack of SAV. - Jared > On Jul 20, 2015, at 11:57 AM, Drew Weaver wrote: > > Has anyone else seen a massive amount of illegitimate UDP 1720 traffic coming from China being sent towards IP addresses which provide VoIP services? > > I'm talking in the 20-30Gbps range? > > The first incident was yesterday at around 13:00 EST, the second incident was today at 09:00 EST. > > I'm assuming this is just another DDoS like all others, but I would be interested to hear if I am not the only one seeing this. > > On list or off-list is fine. > > Thanks, > -Drew From chris at aperturefiber.com Mon Jul 20 16:06:55 2015 From: chris at aperturefiber.com (Chris Garrett) Date: Mon, 20 Jul 2015 12:06:55 -0400 Subject: SIP trunking providers In-Reply-To: <84998225.2803.1437336324378.JavaMail.mhammett@ThunderFuck> References: <84998225.2803.1437336324378.JavaMail.mhammett@ThunderFuck> Message-ID: Might try OneSourceNetworks. They have a primary hub out of Chicago and do SIP very well. http://www.onesourcenetworks.com/ Been a while since I have had any dealings with them, but good folk all the way around. > On Jul 19, 2015, at 4:04 PM, Mike Hammett wrote: > > I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Rafael Possamai" > To: nanog at nanog.org > Sent: Friday, June 19, 2015 4:40:48 PM > Subject: SIP trunking providers > > Would anyone in the list be able to recommend a SIP trunk provider in the > Chicago area? Not a VoIP expert, so just looking for someone with previous > experience. > > > Thanks, > Rafael > > From drew.weaver at thenap.com Mon Jul 20 16:12:18 2015 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 20 Jul 2015 16:12:18 +0000 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <52172AF8-7B37-4BBF-BBC5-9C71409E38A8@puck.nether.net> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <52172AF8-7B37-4BBF-BBC5-9C71409E38A8@puck.nether.net> Message-ID: <7e2983baf29e4e95801764be087687da@EXCHANGE2K13.thenap.com> Ah, alright. I've seen the "general" amplification attacks SNMP/DNS/NTP/you name it, plenty but this is the first one I've ever seen one that targeted 1720/5060 and as its mitigated in one place it keeps moving from dst to dst fairly rapidly until none of the dst ips are available. -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Monday, July 20, 2015 12:06 PM To: Drew Weaver Cc: nanog at nanog.org Subject: Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours I?m sure this is just the extension of all the UDP amplification attacks that are ongoing. My experience is that 1720/CUCM should not be connected to a public network as those devices are often not well maintained or patched. If it?s of value I can look at adding this to the set of things that are enumerated as part of the general UDP amplification problems that we continue to face due to the lack of SAV. - Jared > On Jul 20, 2015, at 11:57 AM, Drew Weaver wrote: > > Has anyone else seen a massive amount of illegitimate UDP 1720 traffic coming from China being sent towards IP addresses which provide VoIP services? > > I'm talking in the 20-30Gbps range? > > The first incident was yesterday at around 13:00 EST, the second incident was today at 09:00 EST. > > I'm assuming this is just another DDoS like all others, but I would be interested to hear if I am not the only one seeing this. > > On list or off-list is fine. > > Thanks, > -Drew From colinj at gt86car.org.uk Mon Jul 20 18:04:27 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 20 Jul 2015 19:04:27 +0100 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> Message-ID: route block china range whole of and/or firewall block china range whole of then contact gov and tell them trade talks need to involve china engaging with incident teams and abuse teams colin Sent from my iPhone > On 20 Jul 2015, at 16:57, Drew Weaver wrote: > > Has anyone else seen a massive amount of illegitimate UDP 1720 traffic coming from China being sent towards IP addresses which provide VoIP services? > > I'm talking in the 20-30Gbps range? > > The first incident was yesterday at around 13:00 EST, the second incident was today at 09:00 EST. > > I'm assuming this is just another DDoS like all others, but I would be interested to hear if I am not the only one seeing this. > > On list or off-list is fine. > > Thanks, > -Drew > From Valdis.Kletnieks at vt.edu Mon Jul 20 18:18:57 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Jul 2015 14:18:57 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: Your message of "Mon, 20 Jul 2015 19:04:27 +0100." References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> Message-ID: <10608.1437416337@turing-police.cc.vt.edu> On Mon, 20 Jul 2015 19:04:27 +0100, Colin Johnston said: > route block china range whole of and/or firewall block china range whole of Do you have an authoritative list of *all* IP blocks that end up routed into China? For bonus points, IPv6 blocks too. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From contact at nullivex.com Mon Jul 20 18:40:12 2015 From: contact at nullivex.com (Bryan Tong) Date: Mon, 20 Jul 2015 12:40:12 -0600 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <10608.1437416337@turing-police.cc.vt.edu> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> Message-ID: My network also saw 30gbps+ originating from the same region on multiple occasions beginning last night around 2300EST. On Jul 20, 2015 12:20 PM, wrote: > On Mon, 20 Jul 2015 19:04:27 +0100, Colin Johnston said: > > route block china range whole of and/or firewall block china range whole > of > > Do you have an authoritative list of *all* IP blocks that end up routed > into China? > > For bonus points, IPv6 blocks too. :) > From colinj at gt86car.org.uk Mon Jul 20 18:42:39 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 20 Jul 2015 19:42:39 +0100 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <10608.1437416337@turing-police.cc.vt.edu> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> Message-ID: <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> see below for china ranges I believe, ipv4 and ipv6 1.0.1.0/24 1.0.2.0/23 1.0.8.0/21 1.0.32.0/19 1.1.0.0/24 1.1.2.0/23 1.1.4.0/22 1.1.8.0/21 1.1.16.0/20 1.1.32.0/19 1.2.0.0/23 1.2.2.0/24 1.2.4.0/22 1.2.8.0/21 1.2.16.0/20 1.2.32.0/19 1.2.64.0/18 1.3.0.0/16 1.4.1.0/24 1.4.2.0/23 1.4.4.0/22 1.4.8.0/21 1.4.16.0/20 1.4.32.0/19 1.4.64.0/18 1.8.0.0/16 1.10.0.0/21 1.10.8.0/23 1.10.11.0/24 1.10.12.0/22 1.10.16.0/20 1.10.32.0/19 1.10.64.0/18 1.12.0.0/14 1.24.0.0/13 1.34.0.0/32 1.45.0.0/16 1.48.0.0/14 1.56.0.0/13 1.68.0.0/14 1.80.0.0/12 1.116.0.0/14 1.180.0.0/14 1.184.0.0/15 1.188.0.0/14 1.192.0.0/13 1.202.0.0/15 1.204.0.0/14 14.0.0.0/21 14.0.12.0/22 14.1.0.0/22 14.16.0.0/12 14.102.128.0/22 14.102.156.0/22 14.103.0.0/16 14.104.0.0/13 14.112.0.0/12 14.130.0.0/15 14.134.0.0/15 14.144.0.0/12 14.192.60.0/22 14.192.76.0/22 14.196.0.0/15 14.204.0.0/15 14.208.0.0/12 27.8.0.0/13 27.16.0.0/12 27.34.232.0/21 27.36.0.0/14 27.40.0.0/13 27.50.40.0/21 27.50.128.0/17 27.54.72.0/21 27.54.152.0/21 27.54.192.0/18 27.98.208.0/20 27.98.224.0/19 27.99.128.0/17 27.103.0.0/16 27.106.128.0/18 27.106.204.0/22 27.109.32.0/19 27.112.0.0/18 27.112.80.0/20 27.113.128.0/18 27.115.0.0/17 27.116.44.0/22 27.121.72.0/21 27.121.120.0/21 27.128.0.0/15 27.131.220.0/22 27.144.0.0/16 27.148.0.0/14 27.152.0.0/13 27.184.0.0/13 27.192.0.0/11 27.224.0.0/14 31.220.30.224/27 36.0.0.0/22 36.0.8.0/21 36.0.16.0/20 36.0.32.0/19 36.0.64.0/18 36.0.128.0/17 36.1.0.0/16 36.4.0.0/14 36.16.0.0/12 36.32.0.0/14 36.36.0.0/16 36.37.0.0/19 36.37.36.0/23 36.37.39.0/24 36.37.40.0/21 36.37.48.0/20 36.40.0.0/13 36.48.0.0/15 36.51.0.0/16 36.56.0.0/13 36.96.0.0/11 36.128.0.0/10 36.192.0.0/11 36.248.0.0/14 36.254.0.0/16 37.153.134.0/25 37.156.6.0/25 39.0.0.0/24 39.0.2.0/23 39.0.4.0/22 39.0.8.0/21 39.0.16.0/20 39.0.32.0/19 39.0.64.0/18 39.0.128.0/17 39.64.0.0/11 39.96.0.1/32 39.96.0.2/31 39.96.0.4/30 39.96.0.8/29 39.96.0.16/28 39.96.0.32/27 39.96.0.64/26 39.96.0.128/25 39.96.1.0/24 39.96.2.0/23 39.96.4.0/22 39.96.8.0/21 39.96.16.0/20 39.96.32.0/19 39.96.64.0/18 39.96.128.0/17 39.97.0.0/16 39.98.0.0/15 39.100.0.0/14 39.104.0.0/14 39.108.0.0/16 39.128.0.0/10 42.0.0.0/22 42.0.8.0/21 42.0.16.0/21 42.0.24.0/22 42.0.32.0/19 42.0.128.0/17 42.1.0.0/19 42.1.32.0/20 42.1.48.0/21 42.1.56.0/22 42.1.128.0/17 42.4.0.0/14 42.48.0.0/13 42.56.0.0/14 42.62.0.0/17 42.62.128.0/19 42.62.160.0/20 42.62.180.0/22 42.62.184.0/21 42.63.0.0/16 42.80.0.0/15 42.83.64.0/20 42.83.80.0/22 42.83.88.0/21 42.83.96.0/19 42.83.128.0/17 42.84.0.0/14 42.88.0.0/13 42.96.64.0/19 42.96.96.0/21 42.96.108.0/22 42.96.112.0/20 42.96.128.0/17 42.97.0.0/16 42.99.0.0/18 42.99.64.0/19 42.99.96.0/20 42.99.112.0/22 42.99.120.0/21 42.100.0.0/14 42.120.0.0/15 42.122.0.0/16 42.123.0.0/19 42.123.36.0/22 42.123.40.0/21 42.123.48.0/20 42.123.64.0/18 42.123.128.0/17 42.128.0.0/12 42.156.0.0/19 42.156.36.0/22 42.156.40.0/21 42.156.48.0/20 42.156.64.0/18 42.156.128.0/17 42.157.0.0/16 42.158.0.0/15 42.160.0.0/12 42.176.0.0/13 42.184.0.0/15 42.186.0.0/16 42.187.0.0/18 42.187.64.0/19 42.187.96.0/20 42.187.112.0/21 42.187.120.0/22 42.187.128.0/17 42.192.0.0/13 42.201.0.0/17 42.202.0.0/15 42.204.0.0/14 42.208.0.0/12 42.224.0.0/12 42.240.0.0/16 42.242.0.0/15 42.244.0.0/14 42.248.0.0/13 43.224.12.0/22 43.224.24.0/22 43.224.44.0/22 43.224.52.0/22 43.224.56.0/22 43.224.64.0/21 43.224.72.0/22 43.224.80.0/22 43.224.100.0/22 43.224.140.0/22 43.224.144.0/22 43.224.160.0/22 43.224.176.0/22 43.224.184.0/22 43.224.200.0/21 43.224.208.0/21 43.224.216.0/22 43.224.224.0/22 43.224.240.0/22 43.225.76.0/22 43.225.84.0/22 43.225.120.0/21 43.225.140.0/22 43.225.172.0/22 43.225.180.0/22 43.225.184.0/22 43.225.208.0/22 43.225.216.0/21 43.225.224.0/20 43.225.240.0/21 43.225.252.0/22 43.226.32.0/19 43.226.64.0/19 43.226.96.0/20 43.226.112.0/21 43.226.120.0/22 43.226.128.0/18 43.226.192.0/20 43.226.208.0/21 43.226.236.0/22 43.226.240.0/20 43.227.0.0/21 43.227.8.0/22 43.227.28.0/22 43.227.32.0/19 43.227.64.0/19 43.227.96.0/21 43.227.104.0/22 43.227.136.0/21 43.227.144.0/22 43.227.152.0/21 43.227.160.0/20 43.227.176.0/21 43.227.188.0/22 43.227.192.0/19 43.227.232.0/22 43.227.248.0/21 43.228.0.0/18 43.228.64.0/21 43.228.76.0/22 43.228.100.0/22 43.228.116.0/22 43.228.120.0/22 43.228.132.0/22 43.228.136.0/22 43.228.148.0/22 43.228.152.0/22 43.228.180.0/22 43.228.188.0/22 43.228.204.0/22 43.228.240.0/22 43.229.16.0/22 43.229.40.0/22 43.229.48.0/22 43.229.56.0/22 43.229.96.0/22 43.229.108.0/22 43.229.120.0/22 43.229.136.0/21 43.229.144.0/22 43.229.168.0/21 43.229.176.0/20 43.229.192.0/21 43.229.216.0/21 43.229.232.0/21 43.230.20.0/22 43.230.32.0/22 43.230.68.0/22 43.230.72.0/22 43.230.84.0/22 43.230.124.0/22 43.230.136.0/22 43.230.168.0/22 43.230.220.0/22 43.230.224.0/19 43.231.32.0/20 43.231.80.0/20 43.231.96.0/20 43.231.136.0/21 43.231.144.0/20 43.231.160.0/20 43.231.176.0/21 43.236.0.0/15 43.238.0.0/16 43.239.0.0/19 43.239.32.0/20 43.239.48.0/22 43.240.0.0/22 43.240.48.0/22 43.240.56.0/21 43.240.68.0/22 43.240.72.0/21 43.240.84.0/22 43.240.124.0/22 43.240.128.0/21 43.240.136.0/22 43.240.156.0/22 43.240.160.0/19 43.240.192.0/19 43.240.236.0/22 43.240.240.0/20 43.241.0.0/20 43.241.16.0/21 43.241.48.0/22 43.241.76.0/22 43.241.80.0/20 43.241.112.0/22 43.241.168.0/21 43.241.176.0/21 43.241.184.0/22 43.241.196.0/22 43.241.208.0/20 43.241.224.0/20 43.241.240.0/22 43.241.248.0/21 43.242.8.0/21 43.242.16.0/20 43.242.44.0/22 43.242.48.0/20 43.242.64.0/22 43.242.72.0/21 43.242.80.0/20 43.242.96.0/22 43.242.144.0/20 43.242.160.0/21 43.242.168.0/22 43.242.180.0/22 43.242.188.0/22 43.242.192.0/21 43.242.204.0/22 43.242.216.0/21 43.242.252.0/22 43.243.4.0/22 43.243.8.0/21 43.243.16.0/22 43.243.24.0/22 43.243.88.0/22 43.243.128.0/22 43.243.136.0/22 43.243.144.0/21 43.243.156.0/22 43.243.168.0/22 43.243.180.0/22 43.243.188.0/22 43.243.228.0/22 43.243.232.0/22 43.243.244.0/22 43.246.0.0/17 43.247.4.0/22 43.247.8.0/22 43.247.44.0/22 43.247.48.0/22 43.247.68.0/22 43.247.76.0/22 43.247.84.0/22 43.247.88.0/21 43.247.96.0/21 43.247.108.0/22 43.247.112.0/22 43.247.148.0/22 43.247.152.0/22 43.247.176.0/20 43.247.196.0/22 43.247.200.0/21 43.247.208.0/20 43.247.224.0/19 43.248.0.0/21 43.248.20.0/22 43.248.28.0/22 43.248.48.0/22 43.248.56.0/22 43.248.76.0/22 43.248.80.0/20 43.248.96.0/19 43.248.128.0/20 43.248.144.0/21 43.248.176.0/20 43.248.192.0/20 43.248.208.0/22 43.248.228.0/22 43.248.232.0/22 43.248.244.0/22 43.249.0.0/21 43.249.8.0/22 43.249.24.0/22 43.249.120.0/22 43.249.132.0/22 43.249.136.0/22 43.249.144.0/20 43.249.160.0/21 43.249.168.0/22 43.249.192.0/22 43.249.236.0/22 43.250.4.0/22 43.250.12.0/22 43.250.16.0/21 43.250.28.0/22 43.250.32.0/21 43.250.72.0/22 43.250.96.0/20 43.250.112.0/21 43.250.128.0/22 43.250.144.0/21 43.250.160.0/22 43.250.168.0/21 43.250.176.0/22 43.250.200.0/22 43.250.212.0/22 43.250.216.0/21 43.250.236.0/22 43.250.244.0/22 43.251.4.0/22 43.251.8.0/21 43.251.16.0/23 43.251.36.0/22 43.251.116.0/22 43.251.192.0/22 43.251.232.0/21 43.251.244.0/22 43.252.48.0/22 43.252.56.0/22 43.252.224.0/22 43.254.0.0/21 43.254.8.0/22 43.254.24.0/22 43.254.36.0/22 43.254.44.0/22 43.254.52.0/22 43.254.64.0/22 43.254.72.0/22 43.254.84.0/22 43.254.88.0/21 43.254.100.0/22 43.254.104.0/22 43.254.112.0/21 43.254.128.0/22 43.254.136.0/21 43.254.144.0/20 43.254.168.0/21 43.254.180.0/22 43.254.184.0/21 43.254.192.0/21 43.254.200.0/22 43.254.208.0/22 43.254.220.0/22 43.254.224.0/20 43.254.240.0/22 43.254.248.0/21 43.255.0.0/21 43.255.8.0/22 43.255.16.0/22 43.255.48.0/22 43.255.60.0/23 43.255.62.0/24 43.255.64.0/20 43.255.84.0/22 43.255.96.0/22 43.255.108.0/22 43.255.144.0/22 43.255.168.0/22 43.255.176.0/22 43.255.184.0/22 43.255.192.0/22 43.255.200.0/21 43.255.208.0/21 43.255.224.0/21 43.255.232.0/22 43.255.244.0/22 45.59.171.0/24 45.61.112.0/20 45.64.112.0/23 45.112.132.0/22 45.112.188.0/22 45.112.208.0/20 45.112.228.0/22 45.112.232.0/21 45.113.12.0/22 45.113.16.0/20 45.113.40.0/22 45.113.52.0/22 45.113.56.0/22 45.113.72.0/22 45.113.108.0/22 45.113.144.0/21 45.113.168.0/22 45.113.176.0/22 45.113.184.0/22 45.113.200.0/21 45.113.208.0/20 45.113.228.0/22 45.113.240.0/22 45.113.252.0/22 45.114.0.0/22 45.114.12.0/22 45.114.32.0/22 45.114.40.0/22 45.114.52.0/22 45.114.96.0/22 45.114.104.0/22 45.114.136.0/22 45.114.196.0/22 45.114.200.0/22 45.114.228.0/22 45.114.236.0/22 45.114.252.0/22 45.115.44.0/22 45.115.100.0/22 45.115.120.0/22 45.115.132.0/22 45.115.144.0/22 45.115.156.0/22 45.115.164.0/22 45.115.200.0/22 45.115.212.0/22 45.115.216.0/22 45.115.228.0/22 45.115.236.0/22 45.115.244.0/22 45.115.248.0/22 45.116.16.0/21 45.116.24.0/22 45.116.32.0/21 45.116.52.0/22 45.116.60.0/22 45.116.64.0/22 45.116.96.0/21 45.116.140.0/22 45.116.152.0/22 45.116.208.0/22 45.117.8.0/22 45.117.20.0/22 45.117.40.0/22 45.117.68.0/22 45.117.124.0/22 45.117.252.0/22 45.119.52.0/22 45.119.60.0/22 45.119.64.0/21 45.119.72.0/22 45.119.104.0/22 45.119.116.0/22 45.119.160.0/22 45.119.232.0/22 45.120.100.0/22 45.120.140.0/22 45.120.158.0/23 45.120.164.0/22 45.120.220.0/22 45.120.240.0/22 45.121.20.0/22 45.121.52.0/22 45.121.64.0/21 45.121.72.0/22 45.121.92.0/22 45.121.96.0/22 45.121.104.0/22 45.121.172.0/22 45.121.176.0/22 45.121.212.0/22 45.121.240.0/20 45.122.0.0/19 45.122.32.0/21 45.122.40.0/22 46.36.194.111/32 46.36.194.112/29 46.36.194.120/32 46.102.251.0/25 46.161.56.128/25 47.92.0.0/14 47.96.0.0/11 49.4.0.0/14 49.51.0.0/16 49.52.0.0/14 49.64.0.0/11 49.112.0.0/13 49.120.0.0/14 49.128.0.0/24 49.128.2.0/23 49.140.0.0/15 49.152.0.0/14 49.208.0.0/14 49.220.0.0/14 49.232.0.0/14 49.239.0.0/18 49.239.192.0/18 49.246.224.0/19 50.2.252.64/29 50.118.128.0/24 54.222.0.0/15 54.231.208.0/20 58.14.0.0/15 58.16.0.0/13 58.24.0.0/15 58.30.0.0/15 58.32.0.0/11 58.65.232.0/21 58.66.0.0/15 58.68.128.0/17 58.82.0.0/17 58.83.0.0/16 58.87.64.0/18 58.99.128.0/17 58.100.0.0/15 58.116.0.0/14 58.128.0.0/13 58.144.0.0/16 58.154.0.0/15 58.192.0.0/11 58.240.0.0/12 59.32.0.0/11 59.64.0.0/12 59.80.0.0/14 59.107.0.0/16 59.108.0.0/14 59.151.0.0/17 59.155.0.0/16 59.172.0.0/14 59.191.0.0/17 59.191.240.0/21 59.191.248.0/22 59.191.252.0/23 59.191.254.0/24 59.192.0.0/10 60.0.0.0/11 60.55.0.0/16 60.63.0.0/16 60.160.0.0/11 60.194.0.0/15 60.200.0.0/13 60.208.0.0/12 60.232.0.0/15 60.235.0.0/16 60.245.128.0/17 60.247.0.0/16 60.252.0.0/16 60.253.128.0/17 60.255.0.0/16 61.4.80.0/20 61.4.176.0/20 61.8.160.0/20 61.28.0.0/17 61.28.195.0/24 61.28.196.0/24 61.29.128.0/17 61.45.128.0/18 61.45.224.0/20 61.47.128.0/18 61.48.0.0/13 61.87.192.0/18 61.128.0.0/10 61.232.0.0/14 61.236.0.0/15 61.240.0.0/14 63.162.142.0/24 64.71.172.0/28 64.71.172.16/31 64.71.172.19/32 64.71.172.20/30 64.71.172.24/29 64.71.172.32/27 64.71.172.64/26 64.71.172.128/25 64.78.162.0/24 64.104.125.0/24 65.19.152.0/24 65.19.188.0/24 65.255.36.0/22 66.160.130.0/24 66.160.162.0/24 66.201.188.0/24 72.28.117.0/24 74.125.16.64/26 77.81.167.0/24 91.234.36.0/24 95.130.197.0/25 98.126.221.0/24 98.126.222.0/24 101.0.0.0/22 101.1.0.0/22 101.2.172.0/22 101.4.0.0/14 101.16.0.0/12 101.32.0.0/12 101.48.0.0/15 101.50.56.0/22 101.52.0.0/16 101.53.100.0/22 101.54.0.0/16 101.55.224.0/21 101.64.0.0/13 101.72.0.0/14 101.76.0.0/15 101.78.0.0/22 101.78.32.0/19 101.80.0.0/12 101.96.0.0/21 101.96.8.0/22 101.96.16.0/20 101.96.128.0/17 101.99.96.0/19 101.101.64.0/19 101.101.100.0/24 101.101.102.0/23 101.101.104.0/21 101.101.112.0/20 101.102.64.0/19 101.102.100.0/23 101.102.102.0/24 101.102.104.0/21 101.102.112.0/20 101.104.0.0/14 101.110.64.0/19 101.110.96.0/20 101.110.116.0/22 101.110.120.0/21 101.120.0.0/14 101.124.0.0/15 101.126.0.0/16 101.128.0.0/22 101.128.8.0/21 101.128.16.0/20 101.128.32.0/19 101.129.0.0/16 101.130.0.0/15 101.132.0.0/14 101.144.0.0/12 101.192.0.0/13 101.200.0.0/15 101.203.128.0/19 101.203.160.0/21 101.203.172.0/22 101.203.176.0/20 101.204.0.0/14 101.224.0.0/13 101.232.0.0/15 101.234.64.0/21 101.234.76.0/22 101.234.80.0/20 101.234.96.0/19 101.236.0.0/14 101.240.0.0/13 101.248.0.0/15 101.251.0.0/22 101.251.8.0/21 101.251.16.0/20 101.251.32.0/19 101.251.64.0/18 101.251.128.0/17 101.252.0.0/15 101.254.0.0/16 103.1.8.0/22 103.1.20.0/22 103.1.24.0/22 103.1.72.0/22 103.1.88.0/22 103.1.168.0/22 103.2.108.0/22 103.2.156.0/22 103.2.164.0/22 103.2.200.0/21 103.2.208.0/21 103.3.84.0/22 103.3.88.0/21 103.3.96.0/19 103.3.128.0/20 103.3.148.0/22 103.3.152.0/21 103.4.56.0/22 103.4.168.0/22 103.4.184.0/22 103.5.36.0/22 103.5.52.0/22 103.5.56.0/22 103.5.252.0/22 103.6.76.0/22 103.6.220.0/22 103.7.4.0/22 103.7.28.0/22 103.7.212.0/22 103.7.216.0/21 103.8.4.0/22 103.8.8.0/22 103.8.32.0/22 103.8.52.0/22 103.8.108.0/22 103.8.156.0/22 103.8.200.0/21 103.8.220.0/22 103.9.152.0/22 103.9.248.0/21 103.10.0.0/22 103.10.16.0/22 103.10.84.0/22 103.10.111.0/24 103.10.140.0/22 103.11.180.0/22 103.12.32.0/22 103.12.68.0/22 103.12.136.0/22 103.12.184.0/22 103.12.232.0/22 103.13.124.0/22 103.13.144.0/22 103.13.196.0/22 103.13.244.0/22 103.14.84.0/22 103.14.132.0/22 103.14.136.0/22 103.14.156.0/22 103.14.240.0/22 103.15.4.0/22 103.15.8.0/22 103.15.16.0/22 103.15.96.0/22 103.15.200.0/22 103.16.52.0/22 103.16.80.0/21 103.16.88.0/22 103.16.108.0/22 103.16.124.0/22 103.17.40.0/22 103.17.120.0/22 103.17.160.0/22 103.17.204.0/22 103.17.228.0/22 103.18.192.0/22 103.18.208.0/21 103.18.224.0/22 103.19.12.0/22 103.19.40.0/21 103.19.64.0/21 103.19.72.0/22 103.19.232.0/22 103.20.12.0/22 103.20.32.0/22 103.20.112.0/22 103.20.128.0/22 103.20.160.0/22 103.20.248.0/22 103.21.112.0/21 103.21.136.0/21 103.21.176.0/22 103.21.208.0/22 103.21.240.0/22 103.22.0.0/18 103.22.64.0/19 103.22.100.0/22 103.22.104.0/21 103.22.112.0/20 103.22.188.0/22 103.22.228.0/22 103.22.252.0/22 103.23.8.0/22 103.23.56.0/22 103.23.160.0/21 103.23.176.0/22 103.23.228.0/22 103.24.116.0/22 103.24.128.0/22 103.24.144.0/22 103.24.176.0/22 103.24.184.0/22 103.24.220.0/22 103.24.228.0/22 103.24.248.0/21 103.25.8.0/23 103.25.20.0/22 103.25.24.0/21 103.25.32.0/21 103.25.40.0/22 103.25.48.0/22 103.25.64.0/21 103.25.148.0/22 103.25.156.0/22 103.25.216.0/22 103.26.0.0/22 103.26.64.0/22 103.26.156.0/22 103.26.160.0/22 103.26.228.0/22 103.26.240.0/22 103.27.4.0/22 103.27.12.0/22 103.27.24.0/22 103.27.56.0/22 103.27.96.0/22 103.27.208.0/22 103.27.240.0/22 103.28.4.0/22 103.28.8.0/22 103.28.204.0/22 103.29.16.0/22 103.29.128.0/21 103.29.136.0/22 103.30.20.0/22 103.30.96.0/22 103.30.148.0/22 103.30.200.0/22 103.30.216.0/22 103.30.228.0/22 103.30.236.0/22 103.31.0.0/22 103.31.48.0/20 103.31.64.0/21 103.31.148.0/22 103.31.160.0/22 103.31.168.0/22 103.31.200.0/22 103.32.0.0/15 103.34.0.0/16 103.35.0.0/19 103.35.32.0/20 103.35.48.0/22 103.36.20.0/22 103.36.28.0/22 103.36.36.0/22 103.36.56.0/21 103.36.64.0/22 103.36.72.0/22 103.36.96.0/22 103.36.132.0/22 103.36.136.0/22 103.36.160.0/19 103.36.192.0/19 103.36.224.0/20 103.36.240.0/21 103.37.0.0/22 103.37.12.0/22 103.37.16.0/22 103.37.24.0/22 103.37.44.0/22 103.37.52.0/22 103.37.56.0/22 103.37.72.0/22 103.37.100.0/22 103.37.104.0/22 103.37.124.0/22 103.37.136.0/21 103.37.144.0/20 103.37.160.0/21 103.37.172.0/22 103.37.176.0/22 103.37.208.0/20 103.37.248.0/21 103.38.0.0/22 103.38.32.0/22 103.38.40.0/21 103.38.56.0/22 103.38.76.0/22 103.38.84.0/22 103.38.92.0/22 103.38.96.0/22 103.38.116.0/22 103.38.132.0/22 103.38.140.0/22 103.38.220.0/22 103.38.224.0/21 103.38.232.0/22 103.38.252.0/22 103.39.16.0/22 103.39.64.0/22 103.39.88.0/22 103.39.100.0/22 103.39.104.0/21 103.39.144.0/22 103.39.160.0/19 103.39.200.0/21 103.39.208.0/20 103.39.224.0/21 103.39.232.0/22 103.40.12.0/22 103.40.16.0/20 103.40.32.0/20 103.40.88.0/22 103.40.100.0/22 103.40.112.0/22 103.40.192.0/22 103.40.212.0/22 103.40.220.0/22 103.40.228.0/22 103.40.232.0/21 103.40.240.0/20 103.41.0.0/22 103.41.16.0/22 103.41.52.0/22 103.41.116.0/22 103.41.140.0/22 103.41.148.0/22 103.41.152.0/22 103.41.160.0/21 103.41.220.0/22 103.41.224.0/21 103.41.232.0/22 103.42.8.0/22 103.42.24.0/21 103.42.32.0/22 103.42.64.0/21 103.42.76.0/22 103.42.104.0/22 103.42.180.0/22 103.42.232.0/22 103.43.16.0/22 103.43.24.0/22 103.43.84.0/22 103.43.96.0/21 103.43.104.0/22 103.43.124.0/22 103.43.132.0/22 103.43.164.0/22 103.43.184.0/22 103.43.192.0/21 103.43.208.0/22 103.43.220.0/22 103.43.224.0/22 103.43.232.0/22 103.43.240.0/22 103.44.56.0/22 103.44.80.0/22 103.44.88.0/22 103.44.120.0/21 103.44.132.0/22 103.44.144.0/22 103.44.152.0/22 103.44.168.0/22 103.44.176.0/20 103.44.192.0/20 103.44.224.0/22 103.44.236.0/22 103.44.240.0/20 103.45.0.0/18 103.45.72.0/21 103.45.80.0/20 103.45.96.0/19 103.45.128.0/18 103.45.192.0/19 103.45.224.0/22 103.45.248.0/22 103.46.0.0/22 103.46.12.0/22 103.46.16.0/20 103.46.32.0/19 103.46.64.0/18 103.46.128.0/21 103.46.136.0/22 103.46.142.0/24 103.46.152.0/21 103.46.160.0/20 103.46.176.0/21 103.46.244.0/22 103.46.248.0/22 103.47.4.0/22 103.47.20.0/22 103.47.36.0/22 103.47.40.0/22 103.47.48.0/22 103.47.80.0/22 103.47.96.0/22 103.47.108.0/22 103.47.116.0/22 103.47.120.0/22 103.47.136.0/21 103.47.144.0/24 103.47.200.0/22 103.47.212.0/22 103.47.220.0/22 103.47.248.0/22 103.48.20.0/22 103.48.52.0/22 103.48.92.0/22 103.48.144.0/20 103.48.202.0/23 103.48.216.0/21 103.48.224.0/20 103.48.240.0/21 103.49.12.0/22 103.49.20.0/22 103.49.72.0/21 103.49.92.0/22 103.49.96.0/22 103.49.108.0/22 103.49.128.0/22 103.49.176.0/21 103.49.196.0/22 103.49.248.0/22 103.50.36.0/22 103.50.44.0/22 103.50.48.0/20 103.50.64.0/21 103.50.72.0/22 103.50.108.0/22 103.50.112.0/20 103.50.132.0/22 103.50.136.0/21 103.50.172.0/22 103.50.176.0/20 103.50.192.0/21 103.50.200.0/22 103.50.220.0/22 103.50.224.0/20 103.50.240.0/21 103.50.248.0/22 103.52.40.0/22 103.52.72.0/21 103.52.80.0/21 103.52.96.0/21 103.52.104.0/22 103.52.160.0/21 103.52.172.0/22 103.52.176.0/22 103.52.184.0/22 103.52.196.0/22 103.53.4.0/22 103.53.64.0/21 103.53.92.0/22 103.53.100.0/22 103.53.124.0/22 103.53.128.0/20 103.53.144.0/22 103.53.160.0/22 103.53.180.0/22 103.53.204.0/22 103.53.208.0/22 103.53.216.0/22 103.53.236.0/22 103.53.248.0/22 103.54.8.0/22 103.54.48.0/22 103.54.60.0/22 103.54.160.0/21 103.54.212.0/22 103.54.228.0/22 103.54.240.0/22 103.55.24.0/22 103.55.80.0/22 103.55.120.0/22 103.55.152.0/22 103.55.172.0/22 103.55.204.0/22 103.55.208.0/22 103.55.228.0/22 103.55.236.0/22 103.55.240.0/22 103.56.8.0/22 103.56.16.0/21 103.56.32.0/22 103.56.56.0/21 103.56.72.0/21 103.56.100.0/22 103.56.104.0/22 103.56.140.0/22 103.56.152.0/22 103.56.184.0/22 103.56.200.0/22 103.57.12.0/22 103.57.52.0/22 103.57.56.0/22 103.57.76.0/22 103.57.108.0/22 103.57.136.0/22 103.57.196.0/22 103.58.24.0/22 103.58.182.0/23 103.59.76.0/22 103.59.100.0/22 103.59.112.0/20 103.59.128.0/22 103.59.148.0/22 103.59.164.0/22 103.59.216.0/22 103.60.32.0/22 103.60.44.0/22 103.60.164.0/22 103.60.228.0/22 103.60.236.0/22 103.61.60.0/22 103.61.104.0/22 103.61.140.0/22 103.61.152.0/21 103.61.160.0/22 103.61.172.0/22 103.61.176.0/22 103.61.184.0/21 103.62.24.0/22 103.62.52.0/22 103.62.72.0/21 103.62.80.0/21 103.62.88.0/22 103.62.96.0/19 103.62.128.0/21 103.224.40.0/21 103.224.60.0/22 103.224.220.0/22 103.224.224.0/21 103.224.232.0/22 103.225.84.0/22 103.226.16.0/22 103.226.40.0/22 103.226.56.0/21 103.226.80.0/22 103.226.116.0/22 103.226.132.0/22 103.226.156.0/22 103.226.180.0/22 103.226.196.0/22 103.227.48.0/22 103.227.72.0/21 103.227.80.0/22 103.227.100.0/22 103.227.120.0/22 103.227.132.0/22 103.227.136.0/22 103.227.196.0/22 103.227.204.0/22 103.227.212.0/22 103.227.228.0/22 103.228.12.0/22 103.228.28.0/22 103.228.68.0/22 103.228.88.0/22 103.228.128.0/22 103.228.160.0/22 103.228.176.0/22 103.228.204.0/22 103.228.208.0/22 103.228.228.0/22 103.228.232.0/22 103.229.20.0/22 103.229.136.0/22 103.229.148.0/22 103.229.172.0/22 103.229.212.0/22 103.229.216.0/21 103.229.228.0/22 103.229.236.0/22 103.229.240.0/22 103.230.0.0/22 103.230.28.0/22 103.230.40.0/21 103.230.96.0/22 103.230.196.0/22 103.230.200.0/21 103.230.212.0/22 103.230.236.0/22 103.231.16.0/21 103.231.64.0/21 103.231.144.0/22 103.231.180.0/22 103.231.184.0/22 103.231.244.0/22 103.232.4.0/22 103.232.144.0/22 103.232.212.0/22 103.233.4.0/22 103.233.44.0/22 103.233.52.0/22 103.233.104.0/22 103.233.128.0/22 103.233.136.0/22 103.233.228.0/22 103.234.0.0/22 103.234.20.0/22 103.234.56.0/22 103.234.124.0/22 103.234.128.0/22 103.234.172.0/22 103.234.180.0/22 103.235.16.0/22 103.235.48.0/22 103.235.56.0/21 103.235.80.0/21 103.235.128.0/20 103.235.144.0/21 103.235.184.0/22 103.235.192.0/22 103.235.200.0/22 103.235.220.0/22 103.235.224.0/19 103.236.0.0/17 103.237.0.0/20 103.237.24.0/21 103.237.68.0/22 103.237.88.0/22 103.237.152.0/22 103.237.176.0/20 103.237.192.0/18 103.238.0.0/21 103.238.16.0/20 103.238.32.0/20 103.238.48.0/21 103.238.56.0/22 103.238.88.0/21 103.238.96.0/22 103.238.132.0/22 103.238.140.0/22 103.238.144.0/22 103.238.160.0/19 103.238.196.0/22 103.238.204.0/22 103.238.252.0/22 103.239.0.0/22 103.239.40.0/21 103.239.68.0/22 103.239.96.0/22 103.239.152.0/21 103.239.176.0/21 103.239.184.0/22 103.239.192.0/21 103.239.204.0/22 103.239.208.0/22 103.239.224.0/22 103.239.244.0/22 103.240.16.0/22 103.240.36.0/22 103.240.72.0/22 103.240.84.0/22 103.240.124.0/22 103.240.156.0/22 103.240.172.0/22 103.240.244.0/22 103.241.12.0/22 103.241.72.0/22 103.241.92.0/22 103.241.96.0/22 103.241.160.0/22 103.241.184.0/21 103.241.220.0/22 103.242.8.0/22 103.242.64.0/22 103.242.128.0/21 103.242.160.0/22 103.242.168.0/21 103.242.176.0/22 103.242.200.0/22 103.242.212.0/22 103.242.220.0/22 103.242.240.0/22 103.243.24.0/22 103.243.136.0/22 103.243.252.0/22 103.244.16.0/22 103.244.58.0/23 103.244.60.0/22 103.244.64.0/20 103.244.80.0/21 103.244.164.0/22 103.244.232.0/22 103.244.252.0/22 103.245.23.0/24 103.245.52.0/22 103.245.60.0/22 103.245.80.0/22 103.245.124.0/22 103.245.128.0/22 103.246.8.0/21 103.246.120.0/21 103.246.132.0/22 103.246.152.0/21 103.247.168.0/21 103.247.176.0/22 103.247.200.0/22 103.247.212.0/22 103.248.0.0/23 103.248.64.0/22 103.248.100.0/22 103.248.124.0/22 103.248.152.0/22 103.248.168.0/22 103.248.192.0/22 103.248.212.0/22 103.248.224.0/21 103.249.12.0/22 103.249.52.0/22 103.249.128.0/22 103.249.136.0/22 103.249.144.0/22 103.249.164.0/22 103.249.168.0/21 103.249.176.0/22 103.249.188.0/22 103.249.192.0/22 103.249.244.0/22 103.249.252.0/22 103.250.32.0/22 103.250.104.0/22 103.250.124.0/22 103.250.180.0/22 103.250.192.0/22 103.250.216.0/22 103.250.224.0/22 103.250.236.0/22 103.250.248.0/21 103.251.32.0/22 103.251.84.0/22 103.251.96.0/22 103.251.124.0/22 103.251.128.0/22 103.251.160.0/22 103.251.204.0/22 103.251.240.0/22 103.252.28.0/22 103.252.36.0/22 103.252.64.0/22 103.252.104.0/22 103.252.172.0/22 103.252.204.0/22 103.252.208.0/22 103.252.232.0/22 103.252.248.0/22 103.253.4.0/22 103.253.60.0/22 103.253.204.0/22 103.253.220.0/22 103.253.224.0/22 103.253.232.0/22 103.254.8.0/22 103.254.20.0/22 103.254.64.0/20 103.254.112.0/22 103.254.176.0/22 103.254.188.0/22 103.254.196.0/24 103.255.68.0/22 103.255.88.0/21 103.255.136.0/21 103.255.184.0/22 103.255.200.0/22 103.255.208.0/21 103.255.228.0/22 104.37.2.0/24 104.166.103.0/24 104.167.214.0/24 104.167.231.0/24 104.207.86.0/24 104.222.196.0/24 104.250.160.0/24 106.0.0.0/24 106.0.2.0/23 106.0.4.0/22 106.0.8.0/21 106.0.16.0/20 106.0.64.0/18 106.2.0.0/15 106.4.0.0/14 106.8.0.0/15 106.11.0.0/16 106.12.0.0/14 106.16.0.0/12 106.32.0.0/12 106.48.0.0/15 106.50.0.0/16 106.52.0.0/14 106.56.0.0/13 106.74.0.0/15 106.80.0.0/12 106.108.0.0/14 106.112.0.0/12 106.224.0.0/12 107.150.96.0/20 110.6.0.0/15 110.16.0.0/14 110.34.140.0/22 110.40.0.0/14 110.44.144.0/20 110.48.0.0/16 110.51.0.0/16 110.52.0.0/15 110.56.0.0/13 110.64.0.0/15 110.72.0.0/15 110.75.0.0/16 110.76.0.0/18 110.76.156.0/22 110.76.184.0/22 110.76.192.0/18 110.77.0.0/17 110.80.0.0/13 110.88.0.0/14 110.93.32.0/19 110.94.0.0/15 110.96.0.0/11 110.152.0.0/14 110.156.0.0/15 110.165.32.0/19 110.166.0.0/15 110.172.192.0/18 110.173.0.0/19 110.173.32.0/20 110.173.64.0/18 110.173.192.0/19 110.176.0.0/12 110.192.0.0/11 110.228.0.0/14 110.232.32.0/19 110.236.0.0/15 110.240.0.0/12 111.0.0.0/10 111.66.0.0/16 111.67.192.0/20 111.68.64.0/19 111.72.0.0/13 111.85.0.0/16 111.91.192.0/19 111.112.0.0/14 111.116.0.0/15 111.118.200.0/21 111.119.64.0/18 111.119.128.0/19 111.120.0.0/14 111.124.0.0/16 111.126.0.0/15 111.128.0.0/11 111.160.0.0/13 111.170.0.0/16 111.172.0.0/14 111.176.0.0/13 111.186.0.0/15 111.192.0.0/12 111.208.0.0/13 111.221.28.0/24 111.221.128.0/17 111.222.0.0/16 111.223.240.0/22 111.223.248.0/22 111.224.0.0/13 111.235.96.0/19 111.235.156.0/22 111.235.160.0/19 112.0.0.0/10 112.64.0.0/14 112.73.0.0/16 112.74.0.0/15 112.80.0.0/12 112.96.0.0/13 112.109.128.0/17 112.111.0.0/16 112.112.0.0/14 112.116.0.0/15 112.122.0.0/15 112.124.0.0/14 112.128.0.0/14 112.132.0.0/16 112.137.48.0/21 112.192.0.0/14 112.224.0.0/11 113.0.0.0/13 113.8.0.0/15 113.11.192.0/19 113.12.0.0/14 113.16.0.0/15 113.18.0.0/16 113.24.0.0/14 113.31.0.0/16 113.44.0.0/14 113.48.0.0/14 113.52.160.0/19 113.54.0.0/15 113.56.0.0/15 113.58.0.0/16 113.59.0.0/17 113.59.224.0/22 113.62.0.0/15 113.64.0.0/10 113.128.0.0/15 113.130.96.0/20 113.130.112.0/21 113.132.0.0/14 113.136.0.0/13 113.194.0.0/15 113.197.100.0/22 113.200.0.0/15 113.202.0.0/16 113.204.0.0/14 113.208.96.0/19 113.208.128.0/17 113.209.0.0/16 113.212.0.0/18 113.212.100.0/22 113.212.184.0/21 113.213.0.0/17 113.214.0.0/15 113.218.0.0/15 113.220.0.0/14 113.224.0.0/12 113.240.0.0/13 113.248.0.0/14 114.28.0.0/16 114.54.0.0/15 114.60.0.0/14 114.64.0.0/14 114.68.0.0/16 114.79.64.0/18 114.80.0.0/12 114.96.0.0/13 114.104.0.0/14 114.110.0.0/20 114.110.64.0/18 114.111.0.0/19 114.111.160.0/19 114.112.0.0/17 114.112.128.0/18 114.112.192.0/19 114.112.232.0/22 114.113.0.0/17 114.113.128.0/18 114.113.195.0/24 114.113.196.0/22 114.113.200.0/21 114.113.208.0/20 114.113.224.0/20 114.113.240.0/21 114.113.248.0/22 114.114.0.0/15 114.116.0.0/14 114.132.0.0/16 114.135.0.0/16 114.138.0.0/15 114.141.64.0/21 114.141.128.0/18 114.196.0.0/15 114.198.248.0/21 114.208.0.0/12 114.224.0.0/11 115.24.0.0/14 115.28.0.0/15 115.32.0.0/14 115.44.0.0/14 115.48.0.0/12 115.69.64.0/20 115.84.0.0/18 115.84.192.0/19 115.85.192.0/18 115.100.0.0/14 115.104.0.0/14 115.120.0.0/14 115.124.16.0/20 115.148.0.0/14 115.152.0.0/13 115.166.64.0/19 115.168.0.0/13 115.180.0.0/14 115.190.0.0/15 115.192.0.0/11 115.224.0.0/12 116.0.8.0/21 116.0.24.0/21 116.1.0.0/16 116.2.0.0/15 116.4.0.0/14 116.8.0.0/14 116.13.0.0/16 116.16.0.0/12 116.50.0.0/20 116.52.0.0/14 116.56.0.0/15 116.58.128.0/20 116.58.208.0/20 116.60.0.0/14 116.66.0.0/17 116.69.0.0/16 116.70.0.0/17 116.76.0.0/14 116.85.0.0/16 116.89.144.0/20 116.90.80.0/20 116.90.184.0/21 116.95.0.0/16 116.112.0.0/14 116.116.0.0/15 116.128.0.0/10 116.192.0.0/16 116.193.16.0/20 116.193.32.0/19 116.193.176.0/21 116.194.0.0/15 116.196.0.0/16 116.198.0.0/16 116.199.0.0/17 116.199.128.0/19 116.204.0.0/15 116.207.0.0/16 116.208.0.0/14 116.212.160.0/20 116.213.64.0/18 116.213.128.0/17 116.214.32.0/19 116.214.64.0/20 116.214.128.0/17 116.215.0.0/16 116.216.0.0/14 116.224.0.0/12 116.242.0.0/15 116.244.0.0/14 116.248.0.0/15 116.251.64.0/18 116.252.0.0/15 116.254.128.0/17 116.255.128.0/17 117.8.0.0/13 117.18.38.0/24 117.21.0.0/16 117.22.0.0/15 117.24.0.0/13 117.32.0.0/13 117.40.0.0/14 117.44.0.0/15 117.48.0.0/14 117.53.48.0/20 117.53.176.0/20 117.57.0.0/16 117.58.0.0/17 117.59.0.0/16 117.60.0.0/14 117.64.0.0/13 117.72.0.0/15 117.74.64.0/19 117.74.128.0/17 117.75.0.0/16 117.76.0.0/14 117.80.0.0/12 117.100.0.0/15 117.103.16.0/20 117.103.40.0/21 117.103.72.0/21 117.103.128.0/20 117.104.168.0/21 117.106.0.0/15 117.112.0.0/13 117.120.64.0/18 117.120.128.0/17 117.121.0.0/17 117.121.128.0/18 117.121.192.0/21 117.122.128.0/17 117.124.0.0/14 117.128.0.0/10 118.24.0.0/15 118.26.0.0/16 118.28.0.0/14 118.64.0.0/15 118.66.0.0/16 118.67.112.0/20 118.72.0.0/13 118.80.0.0/15 118.84.0.0/15 118.88.32.0/19 118.88.64.0/18 118.88.128.0/17 118.89.0.0/16 118.91.240.0/20 118.102.16.0/20 118.102.32.0/21 118.103.240.0/21 118.112.0.0/13 118.120.0.0/14 118.124.0.0/15 118.126.0.0/16 118.127.128.0/19 118.132.0.0/14 118.144.0.0/14 118.178.0.0/16 118.180.0.0/14 118.184.0.0/16 118.186.0.0/15 118.188.0.0/16 118.190.0.0/15 118.192.0.0/16 118.193.0.0/17 118.193.128.0/18 118.193.192.0/19 118.193.225.0/24 118.193.226.0/23 118.193.228.0/22 118.193.232.0/21 118.193.240.0/20 118.194.0.0/15 118.196.0.0/14 118.202.0.0/15 118.204.0.0/14 118.212.0.0/15 118.224.0.0/14 118.228.0.0/15 118.230.0.0/16 118.239.0.0/16 118.242.0.0/16 118.244.0.0/14 118.248.0.0/13 119.0.0.0/15 119.2.0.0/19 119.2.128.0/17 119.4.0.0/14 119.8.0.0/16 119.10.0.0/17 119.15.136.0/21 119.16.0.0/16 119.18.192.0/20 119.18.208.0/21 119.18.224.0/19 119.19.0.0/16 119.20.0.0/14 119.27.64.0/18 119.27.128.0/17 119.28.0.0/15 119.30.48.0/20 119.31.192.0/19 119.32.0.0/13 119.40.0.0/18 119.40.64.0/20 119.40.128.0/17 119.41.0.0/16 119.42.0.0/19 119.42.128.0/20 119.42.224.0/19 119.44.0.0/15 119.48.0.0/13 119.57.0.0/16 119.58.0.0/16 119.59.128.0/17 119.60.0.0/15 119.62.0.0/16 119.63.32.0/19 119.75.208.0/20 119.78.0.0/15 119.80.0.0/16 119.81.248.88/29 119.82.208.0/20 119.84.0.0/14 119.88.0.0/14 119.96.0.0/13 119.108.0.0/15 119.112.0.0/12 119.128.0.0/12 119.144.0.0/14 119.148.160.0/19 119.151.192.0/18 119.160.200.0/21 119.161.128.0/17 119.162.0.0/15 119.164.0.0/14 119.176.0.0/12 119.232.0.0/15 119.235.128.0/18 119.248.0.0/14 119.252.96.0/21 119.252.240.0/20 119.253.0.0/16 119.254.0.0/15 120.0.0.0/12 120.24.0.0/14 120.30.0.0/15 120.32.0.0/12 120.48.0.0/15 120.52.0.0/14 120.64.0.0/13 120.72.32.0/19 120.72.128.0/17 120.76.0.0/14 120.80.0.0/13 120.88.8.0/21 120.90.0.0/15 120.92.0.0/16 120.94.0.0/15 120.128.0.0/13 120.136.128.0/18 120.137.0.0/17 120.143.128.0/19 120.192.0.0/10 121.0.8.0/21 121.0.16.0/20 121.4.0.0/15 121.8.0.0/13 121.16.0.0/12 121.32.0.0/13 121.40.0.0/14 121.46.0.0/15 121.48.0.0/15 121.50.8.0/21 121.51.0.0/16 121.52.160.0/19 121.52.208.0/20 121.52.224.0/19 121.54.176.0/21 121.55.0.0/18 121.56.0.0/15 121.58.0.0/17 121.58.136.0/21 121.58.144.0/20 121.58.160.0/21 121.59.0.0/16 121.60.0.0/14 121.68.0.0/14 121.76.0.0/15 121.79.128.0/18 121.89.0.0/16 121.100.128.0/17 121.101.0.0/18 121.101.208.0/20 121.192.0.0/13 121.200.192.0/21 121.201.0.0/16 121.204.0.0/14 121.224.0.0/12 121.248.0.0/14 121.255.0.0/16 122.0.64.0/18 122.0.128.0/17 122.4.0.0/14 122.8.0.0/16 122.10.112.0/21 122.10.128.0/17 122.11.0.0/17 122.12.0.0/15 122.14.0.0/17 122.14.128.0/24 122.14.138.1/32 122.14.138.2/31 122.14.138.4/30 122.14.138.8/29 122.14.138.16/28 122.14.138.32/27 122.14.138.64/26 122.14.138.128/25 122.14.139.0/24 122.14.140.0/22 122.14.144.0/20 122.14.160.0/19 122.14.192.0/18 122.48.0.0/16 122.49.0.0/18 122.51.0.0/16 122.64.0.0/11 122.96.0.0/15 122.102.0.0/20 122.102.64.0/19 122.112.0.0/15 122.114.0.0/16 122.115.0.0/18 122.115.64.0/21 122.115.72.0/22 122.115.80.0/20 122.115.96.0/19 122.115.128.0/17 122.119.0.0/16 122.128.120.0/21 122.136.0.0/13 122.144.128.0/17 122.152.192.0/18 122.156.0.0/14 122.188.0.0/14 122.192.0.0/14 122.198.0.0/16 122.200.64.0/18 122.201.48.0/20 122.204.0.0/14 122.224.0.0/12 122.240.0.0/13 122.248.24.0/21 122.248.48.0/20 122.255.64.0/21 123.0.128.0/18 123.4.0.0/14 123.8.0.0/13 123.49.128.0/17 123.50.160.0/19 123.52.0.0/14 123.56.0.0/14 123.61.0.0/16 123.62.0.0/16 123.64.0.0/11 123.96.0.0/15 123.98.0.0/17 123.99.128.0/17 123.100.0.0/19 123.101.0.0/16 123.103.0.0/17 123.108.128.0/20 123.108.208.0/20 123.112.0.0/12 123.128.0.0/13 123.136.80.0/20 123.137.0.0/16 123.138.0.0/15 123.144.0.0/12 123.160.0.0/12 123.176.60.0/22 123.176.80.0/20 123.177.0.0/16 123.178.0.0/15 123.180.0.0/14 123.184.0.0/13 123.196.0.0/15 123.199.128.0/17 123.206.0.0/15 123.232.0.0/14 123.242.0.0/17 123.244.0.0/14 123.249.0.0/16 123.253.0.0/16 124.6.64.0/18 124.14.0.0/15 124.16.0.0/15 124.20.0.0/14 124.28.192.0/18 124.29.0.0/17 124.31.0.0/16 124.40.112.0/20 124.40.128.0/18 124.40.192.0/19 124.42.0.0/16 124.47.0.0/18 124.64.0.0/15 124.66.0.0/17 124.67.0.0/16 124.68.0.0/14 124.72.0.0/13 124.88.0.0/13 124.108.8.0/21 124.108.40.0/21 124.109.96.0/21 124.112.0.0/13 124.126.0.0/15 124.128.0.0/13 124.147.128.0/17 124.151.0.0/16 124.152.0.0/16 124.156.0.0/16 124.160.0.0/13 124.172.0.0/14 124.192.0.0/15 124.196.0.0/16 124.200.0.0/13 124.220.0.0/14 124.224.0.0/12 124.240.0.0/17 124.240.128.0/18 124.242.0.0/16 124.243.192.0/18 124.248.0.0/17 124.249.0.0/16 124.250.0.0/15 124.254.0.0/18 125.31.192.0/18 125.32.0.0/12 125.58.128.0/17 125.61.128.0/17 125.62.0.0/18 125.64.0.0/11 125.96.0.0/15 125.98.0.0/16 125.104.0.0/13 125.112.0.0/12 125.169.0.0/16 125.171.0.0/16 125.208.0.0/18 125.210.0.0/15 125.213.0.0/17 125.214.96.0/19 125.215.0.0/18 125.216.0.0/13 125.254.128.0/17 139.9.0.0/16 139.129.0.0/16 139.148.0.0/16 139.155.0.0/16 139.159.0.0/16 139.170.0.0/16 139.176.0.0/16 139.183.0.0/16 139.186.0.0/16 139.189.0.0/16 139.196.0.0/14 139.200.0.0/13 139.208.0.0/13 139.217.0.0/16 139.219.0.0/16 139.220.0.0/15 139.224.0.0/16 139.226.0.0/15 140.75.0.0/16 140.143.0.0/16 140.205.0.0/16 140.206.0.0/15 140.210.0.0/16 140.224.0.0/16 140.237.0.0/16 140.240.0.0/16 140.243.0.0/16 140.246.0.0/16 140.249.0.0/16 140.250.0.0/16 140.255.0.0/16 142.4.107.0/24 142.4.118.0/23 142.4.121.0/24 142.4.122.0/23 142.4.125.0/24 144.0.0.0/16 144.7.0.0/16 144.12.0.0/16 144.36.146.0/23 144.36.218.0/24 144.36.240.0/23 144.52.0.0/16 144.123.0.0/16 144.255.0.0/16 147.243.224.0/19 150.0.0.0/16 150.115.0.0/16 150.121.0.0/16 150.122.0.0/16 150.129.8.0/23 150.129.10.0/24 150.129.152.0/22 150.129.192.0/22 150.129.216.0/22 150.129.252.0/22 150.138.0.0/15 150.223.0.0/16 150.242.0.0/21 150.242.8.0/22 150.242.28.0/22 150.242.44.0/22 150.242.48.0/21 150.242.56.0/22 150.242.76.0/22 150.242.80.0/22 150.242.92.0/22 150.242.96.0/22 150.242.112.0/21 150.242.120.0/22 150.242.152.0/21 150.242.160.0/21 150.242.168.0/22 150.242.184.0/21 150.242.192.0/22 150.242.212.0/22 150.242.224.0/22 150.242.232.0/21 150.242.240.0/21 150.242.248.0/22 150.255.0.0/16 152.104.128.0/17 153.0.0.0/16 153.3.0.0/16 153.34.0.0/15 153.36.0.0/15 153.99.0.0/16 153.101.0.0/16 153.118.0.0/15 155.254.199.0/24 155.254.236.0/24 157.0.0.0/16 157.18.0.0/16 157.61.0.0/16 157.122.0.0/16 157.148.0.0/16 157.156.0.0/16 157.255.0.0/16 159.153.120.0/22 159.226.0.0/16 161.202.3.80/28 161.207.0.0/16 162.105.0.0/16 162.254.0.0/21 163.0.0.0/16 163.47.4.0/22 163.53.0.0/20 163.53.36.0/22 163.53.40.0/21 163.53.48.0/20 163.53.64.0/22 163.53.88.0/21 163.53.96.0/19 163.53.128.0/21 163.53.136.0/22 163.53.160.0/20 163.53.188.0/22 163.53.220.0/22 163.53.240.0/22 163.125.0.0/16 163.142.0.0/16 163.177.0.0/16 163.179.0.0/16 163.204.0.0/16 163.244.246.0/24 166.111.0.0/16 167.88.102.0/23 167.139.0.0/16 167.189.0.0/16 168.160.0.0/16 171.8.0.0/13 171.34.0.0/15 171.36.0.0/14 171.40.0.0/13 171.80.0.0/12 171.104.0.0/13 171.112.0.0/12 171.208.0.0/12 173.1.158.48/28 173.44.248.240/29 173.231.194.0/24 173.231.196.0/22 173.231.201.0/24 173.231.223.0/24 173.231.228.0/24 173.231.230.0/24 173.231.233.0/24 173.232.149.96/29 173.249.207.0/24 173.253.64.0/21 173.253.80.0/20 173.253.98.0/23 173.253.100.0/22 173.253.104.0/21 175.0.0.0/12 175.16.0.0/13 175.24.0.0/14 175.30.0.0/15 175.42.0.0/15 175.44.0.0/16 175.46.0.0/15 175.48.0.0/12 175.64.0.0/11 175.102.0.0/16 175.106.128.0/17 175.146.0.0/15 175.148.0.0/14 175.152.0.0/14 175.160.0.0/12 175.178.0.0/16 175.184.128.0/18 175.185.0.0/16 175.186.0.0/15 175.188.0.0/14 180.76.0.0/14 180.84.0.0/15 180.86.0.0/16 180.87.10.20/30 180.88.0.0/14 180.94.56.0/21 180.94.96.0/20 180.95.128.0/17 180.96.0.0/11 180.129.128.0/17 180.130.0.0/16 180.136.0.0/13 180.148.16.0/21 180.148.152.0/21 180.148.216.0/21 180.148.224.0/19 180.149.128.0/19 180.150.160.0/19 180.152.0.0/13 180.160.0.0/12 180.178.192.0/18 180.184.0.0/14 180.188.0.0/17 180.189.148.0/22 180.200.252.0/22 180.201.0.0/16 180.202.0.0/15 180.208.0.0/15 180.210.224.0/19 180.212.0.0/15 180.222.224.0/19 180.223.0.0/16 180.233.0.0/18 180.233.64.0/19 180.235.64.0/19 182.16.192.0/19 182.18.0.0/17 182.23.184.0/21 182.23.200.0/21 182.32.0.0/12 182.48.96.0/19 182.49.0.0/16 182.50.0.0/20 182.50.112.0/20 182.51.0.0/16 182.54.0.0/17 182.61.0.0/16 182.80.0.0/13 182.88.0.0/14 182.92.0.0/16 182.96.0.0/11 182.128.0.0/12 182.144.0.0/13 182.157.0.0/16 182.160.64.0/19 182.174.0.0/15 182.200.0.0/13 182.236.128.0/17 182.238.0.0/16 182.239.0.0/19 182.240.0.0/13 182.254.0.0/16 183.0.0.0/10 183.64.0.0/13 183.78.180.0/22 183.81.180.0/22 183.84.0.0/15 183.91.128.0/22 183.91.136.0/21 183.91.144.0/20 183.92.0.0/14 183.128.0.0/11 183.160.0.0/13 183.168.0.0/15 183.170.0.0/16 183.172.0.0/14 183.182.0.0/19 183.184.0.0/13 183.192.0.0/10 185.46.86.128/25 185.56.163.112/28 188.213.218.128/25 188.240.211.0/25 192.137.31.0/24 192.151.208.0/20 192.151.224.0/20 192.151.255.0/24 192.161.92.0/22 192.188.170.0/24 192.200.24.0/24 198.16.32.0/20 198.16.48.0/21 198.40.48.0/24 198.40.50.0/24 198.40.59.0/24 198.40.63.0/24 198.200.33.240/28 198.244.53.0/24 198.244.63.0/24 199.15.119.0/24 199.244.118.0/24 202.0.100.0/23 202.0.122.0/23 202.3.128.0/23 202.4.128.0/19 202.4.252.0/22 202.6.6.0/23 202.6.66.0/23 202.6.72.0/23 202.6.87.0/24 202.6.88.0/23 202.6.92.0/23 202.6.103.0/24 202.6.108.0/24 202.6.110.0/23 202.6.114.0/24 202.6.176.0/20 202.8.0.0/24 202.8.2.0/23 202.8.4.0/23 202.8.12.0/24 202.8.24.0/24 202.8.77.0/24 202.8.128.0/19 202.8.192.0/20 202.9.32.0/24 202.9.34.0/23 202.9.48.0/23 202.9.51.0/24 202.9.52.0/22 202.9.57.0/24 202.9.58.0/23 202.10.64.0/20 202.12.1.0/24 202.12.2.0/24 202.12.17.0/24 202.12.18.0/24 202.12.72.0/24 202.12.84.0/23 202.12.96.0/24 202.12.98.0/23 202.12.106.0/24 202.12.111.0/24 202.12.116.0/24 202.14.64.0/23 202.14.69.0/24 202.14.73.0/24 202.14.74.0/23 202.14.76.0/24 202.14.78.0/23 202.14.88.0/24 202.14.97.0/24 202.14.104.0/23 202.14.108.0/23 202.14.111.0/24 202.14.114.0/23 202.14.118.0/23 202.14.124.0/23 202.14.127.0/24 202.14.129.0/24 202.14.135.0/24 202.14.136.0/24 202.14.149.0/24 202.14.151.0/24 202.14.157.0/24 202.14.158.0/23 202.14.169.0/24 202.14.170.0/23 202.14.176.0/24 202.14.184.0/23 202.14.208.0/23 202.14.213.0/24 202.14.219.0/24 202.14.220.0/24 202.14.222.0/23 202.14.224.0/22 202.14.231.0/24 202.14.235.0/24 202.14.236.0/22 202.14.246.0/24 202.14.251.0/24 202.20.66.0/24 202.20.79.0/24 202.20.87.0/24 202.20.88.0/23 202.20.90.0/24 202.20.94.0/23 202.20.114.0/24 202.20.117.0/24 202.20.120.0/24 202.20.125.0/24 202.20.127.0/24 202.21.131.0/24 202.21.132.0/24 202.21.141.0/24 202.21.142.0/24 202.21.147.0/24 202.21.148.0/24 202.21.150.0/23 202.21.152.0/23 202.21.154.0/24 202.21.156.0/24 202.22.248.0/21 202.27.136.0/23 202.38.0.0/22 202.38.8.0/21 202.38.48.0/20 202.38.64.0/18 202.38.128.0/21 202.38.136.0/23 202.38.138.0/24 202.38.140.0/22 202.38.146.0/23 202.38.149.0/24 202.38.150.0/23 202.38.152.0/22 202.38.156.0/24 202.38.158.0/23 202.38.160.0/23 202.38.164.0/22 202.38.168.0/22 202.38.176.0/23 202.38.184.0/21 202.38.192.0/18 202.40.4.0/23 202.40.7.0/24 202.40.15.0/24 202.40.135.0/24 202.40.136.0/24 202.40.140.0/24 202.40.143.0/24 202.40.144.0/23 202.40.150.0/24 202.40.155.0/24 202.40.156.0/24 202.40.158.0/23 202.40.162.0/24 202.41.8.0/23 202.41.11.0/24 202.41.12.0/23 202.41.128.0/24 202.41.130.0/23 202.41.152.0/21 202.41.192.0/24 202.41.240.0/20 202.43.76.0/22 202.43.144.0/20 202.44.16.0/20 202.44.67.0/24 202.44.74.0/24 202.44.129.0/24 202.44.132.0/23 202.44.146.0/23 202.45.0.0/23 202.45.2.0/24 202.45.15.0/24 202.45.16.0/20 202.46.16.0/23 202.46.18.0/24 202.46.20.0/23 202.46.32.0/19 202.46.128.0/24 202.46.224.0/20 202.47.82.0/23 202.47.126.0/24 202.47.128.0/24 202.47.130.0/23 202.57.240.0/20 202.58.0.0/24 202.59.0.0/24 202.59.212.0/22 202.59.232.0/23 202.59.236.0/24 202.60.48.0/21 202.60.96.0/21 202.60.112.0/20 202.60.132.0/22 202.60.136.0/21 202.60.144.0/20 202.62.112.0/22 202.62.248.0/22 202.62.252.0/24 202.62.255.0/24 202.63.80.0/20 202.63.160.0/19 202.63.248.0/22 202.65.0.0/21 202.65.8.0/23 202.67.0.0/22 202.69.4.0/22 202.69.16.0/20 202.70.0.0/19 202.70.96.0/20 202.70.192.0/20 202.72.40.0/21 202.72.80.0/20 202.73.128.0/22 202.74.8.0/21 202.74.80.0/20 202.74.254.0/23 202.75.208.0/20 202.75.252.0/22 202.76.252.0/22 202.77.80.0/21 202.77.92.0/22 202.77.170.48/28 202.78.8.0/21 202.79.224.0/21 202.79.248.0/22 202.80.192.0/20 202.81.0.0/22 202.82.16.160/29 202.83.252.0/22 202.84.4.0/22 202.84.8.0/21 202.84.16.0/23 202.84.24.0/21 202.85.208.0/20 202.86.249.0/24 202.86.252.0/22 202.87.80.0/20 202.89.8.0/21 202.89.21.0/24 202.89.232.0/21 202.90.0.0/22 202.90.112.0/20 202.90.196.0/24 202.90.224.0/20 202.91.0.0/22 202.91.96.0/20 202.91.128.0/22 202.91.176.0/20 202.91.224.0/19 202.92.0.0/22 202.92.8.0/21 202.92.48.0/20 202.92.252.0/22 202.93.0.0/22 202.93.252.0/22 202.94.92.0/22 202.95.0.0/19 202.95.240.0/21 202.95.252.0/22 202.96.0.0/12 202.112.0.0/13 202.120.0.0/15 202.122.0.0/21 202.122.32.0/21 202.122.64.0/19 202.122.112.0/20 202.122.128.0/24 202.122.132.0/24 202.123.96.0/20 202.124.16.0/21 202.124.24.0/22 202.125.112.0/20 202.125.176.0/20 202.127.0.0/21 202.127.12.0/22 202.127.16.0/20 202.127.40.0/21 202.127.48.0/20 202.127.112.0/20 202.127.128.0/19 202.127.160.0/21 202.127.192.0/20 202.127.208.0/23 202.127.212.0/22 202.127.216.0/21 202.127.224.0/19 202.130.0.0/19 202.130.224.0/19 202.131.16.0/21 202.131.48.0/20 202.131.208.0/20 202.133.32.0/20 202.134.58.0/24 202.134.128.0/20 202.136.48.0/20 202.136.208.0/20 202.136.224.0/20 202.137.231.0/24 202.141.160.0/19 202.142.16.0/20 202.143.4.0/22 202.143.16.0/20 202.143.32.0/20 202.143.56.0/21 202.146.160.0/20 202.146.188.0/22 202.146.196.0/22 202.146.200.0/21 202.147.144.0/20 202.148.32.0/20 202.148.64.0/18 202.149.32.0/19 202.149.160.0/19 202.149.224.0/19 202.150.16.0/20 202.150.32.0/20 202.150.56.0/22 202.150.192.0/20 202.150.224.0/19 202.151.0.0/22 202.151.128.0/19 202.152.176.0/20 202.153.0.0/22 202.153.48.0/20 202.157.192.0/19 202.158.160.0/19 202.160.176.0/20 202.162.67.0/24 202.162.75.0/24 202.164.0.0/20 202.164.96.0/19 202.165.176.0/20 202.165.208.0/20 202.165.239.0/24 202.165.240.0/23 202.165.243.0/24 202.165.245.0/24 202.165.251.0/24 202.165.252.0/22 202.166.224.0/19 202.168.160.0/19 202.170.128.0/19 202.170.216.0/21 202.170.224.0/19 202.171.216.0/21 202.171.235.0/24 202.172.0.0/22 202.173.0.0/22 202.173.8.0/21 202.173.224.0/19 202.174.64.0/20 202.176.224.0/19 202.179.240.0/20 202.180.128.0/19 202.180.208.0/21 202.181.112.0/20 202.182.32.0/20 202.182.192.0/19 202.189.0.0/18 202.189.80.0/20 202.189.184.0/21 202.191.0.0/24 202.191.68.0/22 202.191.72.0/21 202.191.80.0/20 202.192.0.0/12 203.0.4.0/22 203.0.10.0/23 203.0.18.0/24 203.0.24.0/24 203.0.42.0/23 203.0.45.0/24 203.0.46.0/23 203.0.81.0/24 203.0.82.0/23 203.0.90.0/23 203.0.96.0/23 203.0.104.0/21 203.0.114.0/23 203.0.122.0/24 203.0.128.0/24 203.0.130.0/23 203.0.132.0/22 203.0.137.0/24 203.0.142.0/24 203.0.144.0/24 203.0.146.0/24 203.0.148.0/24 203.0.150.0/23 203.0.152.0/24 203.0.177.0/24 203.0.224.0/24 203.1.4.0/22 203.1.18.0/24 203.1.26.0/23 203.1.65.0/24 203.1.66.0/23 203.1.70.0/23 203.1.76.0/23 203.1.90.0/24 203.1.97.0/24 203.1.98.0/23 203.1.100.0/22 203.1.108.0/24 203.1.253.0/24 203.1.254.0/24 203.2.64.0/21 203.2.73.0/24 203.2.112.0/21 203.2.126.0/23 203.2.140.0/24 203.2.150.0/24 203.2.152.0/22 203.2.156.0/23 203.2.160.0/21 203.2.180.0/23 203.2.196.0/23 203.2.209.0/24 203.2.214.0/23 203.2.226.0/23 203.2.229.0/24 203.2.236.0/23 203.3.68.0/24 203.3.72.0/23 203.3.75.0/24 203.3.80.0/21 203.3.96.0/22 203.3.105.0/24 203.3.112.0/21 203.3.120.0/24 203.3.123.0/24 203.3.135.0/24 203.3.139.0/24 203.3.143.0/24 203.4.132.0/23 203.4.134.0/24 203.4.151.0/24 203.4.152.0/22 203.4.174.0/23 203.4.180.0/24 203.4.186.0/24 203.4.205.0/24 203.4.208.0/22 203.4.227.0/24 203.4.230.0/23 203.5.4.0/23 203.5.7.0/24 203.5.8.0/23 203.5.11.0/24 203.5.21.0/24 203.5.22.0/24 203.5.44.0/24 203.5.46.0/23 203.5.52.0/22 203.5.56.0/23 203.5.60.0/23 203.5.114.0/23 203.5.118.0/24 203.5.120.0/24 203.5.172.0/24 203.5.180.0/23 203.5.182.0/24 203.5.185.0/24 203.5.186.0/24 203.5.188.0/23 203.5.190.0/24 203.5.195.0/24 203.5.214.0/23 203.5.218.0/23 203.6.131.0/24 203.6.136.0/24 203.6.138.0/23 203.6.142.0/24 203.6.150.0/23 203.6.157.0/24 203.6.159.0/24 203.6.224.0/20 203.6.248.0/23 203.7.129.0/24 203.7.138.0/23 203.7.147.0/24 203.7.150.0/23 203.7.158.0/24 203.7.192.0/23 203.7.200.0/24 203.8.0.0/24 203.8.8.0/24 203.8.23.0/24 203.8.70.0/24 203.8.82.0/24 203.8.86.0/23 203.8.91.0/24 203.8.110.0/23 203.8.115.0/24 203.8.166.0/23 203.8.169.0/24 203.8.173.0/24 203.8.184.0/24 203.8.186.0/23 203.8.190.0/23 203.8.192.0/24 203.8.197.0/24 203.8.198.0/23 203.8.203.0/24 203.8.209.0/24 203.8.210.0/23 203.8.212.0/22 203.8.217.0/24 203.8.220.0/24 203.9.32.0/24 203.9.36.0/23 203.9.57.0/24 203.9.63.0/24 203.9.65.0/24 203.9.70.0/23 203.9.72.0/24 203.9.75.0/24 203.9.76.0/23 203.9.96.0/22 203.9.100.0/23 203.9.108.0/24 203.9.158.0/24 203.10.34.0/24 203.10.56.0/24 203.10.74.0/23 203.10.84.0/22 203.10.88.0/24 203.10.95.0/24 203.10.125.0/24 203.11.70.0/24 203.11.76.0/22 203.11.82.0/24 203.11.84.0/22 203.11.100.0/22 203.11.109.0/24 203.11.117.0/24 203.11.122.0/24 203.11.126.0/24 203.11.136.0/22 203.11.141.0/24 203.11.142.0/23 203.11.180.0/22 203.11.208.0/22 203.12.16.0/24 203.12.19.0/24 203.12.24.0/24 203.12.57.0/24 203.12.65.0/24 203.12.66.0/24 203.12.70.0/23 203.12.87.0/24 203.12.100.0/23 203.12.103.0/24 203.12.114.0/24 203.12.118.0/24 203.12.130.0/24 203.12.137.0/24 203.12.196.0/22 203.12.211.0/24 203.12.219.0/24 203.12.226.0/24 203.12.240.0/22 203.13.18.0/24 203.13.24.0/24 203.13.44.0/23 203.13.88.0/23 203.13.92.0/22 203.13.173.0/24 203.13.224.0/23 203.13.227.0/24 203.13.233.0/24 203.14.24.0/22 203.14.33.0/24 203.14.56.0/24 203.14.61.0/24 203.14.62.0/24 203.14.104.0/24 203.14.114.0/23 203.14.118.0/24 203.14.162.0/24 203.14.192.0/24 203.14.194.0/23 203.14.214.0/24 203.14.231.0/24 203.14.246.0/24 203.15.0.0/20 203.15.20.0/23 203.15.22.0/24 203.15.87.0/24 203.15.88.0/23 203.15.105.0/24 203.15.112.0/21 203.15.130.0/23 203.15.149.0/24 203.15.151.0/24 203.15.156.0/22 203.15.174.0/24 203.15.227.0/24 203.15.232.0/21 203.15.240.0/23 203.15.246.0/24 203.16.10.0/24 203.16.12.0/23 203.16.16.0/21 203.16.27.0/24 203.16.38.0/24 203.16.49.0/24 203.16.50.0/23 203.16.58.0/24 203.16.133.0/24 203.16.161.0/24 203.16.162.0/24 203.16.186.0/23 203.16.228.0/24 203.16.238.0/24 203.16.240.0/24 203.16.245.0/24 203.17.2.0/24 203.17.18.0/24 203.17.28.0/24 203.17.39.0/24 203.17.56.0/24 203.17.74.0/23 203.17.88.0/23 203.17.136.0/24 203.17.164.0/24 203.17.187.0/24 203.17.190.0/23 203.17.231.0/24 203.17.233.0/24 203.17.248.0/24 203.17.255.0/24 203.18.2.0/23 203.18.4.0/24 203.18.7.0/24 203.18.31.0/24 203.18.37.0/24 203.18.48.0/23 203.18.52.0/24 203.18.72.0/22 203.18.80.0/23 203.18.87.0/24 203.18.100.0/23 203.18.105.0/24 203.18.107.0/24 203.18.110.0/24 203.18.129.0/24 203.18.131.0/24 203.18.132.0/23 203.18.144.0/24 203.18.153.0/24 203.18.199.0/24 203.18.208.0/24 203.18.211.0/24 203.18.215.0/24 203.19.18.0/24 203.19.24.0/24 203.19.30.0/24 203.19.41.0/24 203.19.44.0/23 203.19.46.0/24 203.19.58.0/24 203.19.60.0/23 203.19.64.0/24 203.19.68.0/24 203.19.72.0/24 203.19.101.0/24 203.19.111.0/24 203.19.131.0/24 203.19.133.0/24 203.19.144.0/24 203.19.149.0/24 203.19.156.0/24 203.19.176.0/24 203.19.178.0/23 203.19.208.0/24 203.19.228.0/22 203.19.233.0/24 203.19.242.0/24 203.19.248.0/23 203.19.255.0/24 203.20.17.0/24 203.20.40.0/23 203.20.48.0/24 203.20.61.0/24 203.20.65.0/24 203.20.84.0/23 203.20.89.0/24 203.20.106.0/23 203.20.115.0/24 203.20.117.0/24 203.20.118.0/23 203.20.122.0/24 203.20.126.0/23 203.20.135.0/24 203.20.150.0/24 203.20.230.0/24 203.20.232.0/24 203.20.236.0/24 203.21.0.0/23 203.21.2.0/24 203.21.8.0/24 203.21.10.0/24 203.21.18.0/24 203.21.33.0/24 203.21.34.0/24 203.21.41.0/24 203.21.44.0/24 203.21.68.0/24 203.21.82.0/24 203.21.96.0/22 203.21.124.0/24 203.21.136.0/23 203.21.145.0/24 203.21.206.0/24 203.22.24.0/24 203.22.28.0/23 203.22.31.0/24 203.22.68.0/24 203.22.76.0/24 203.22.78.0/24 203.22.84.0/24 203.22.87.0/24 203.22.92.0/22 203.22.99.0/24 203.22.106.0/24 203.22.122.0/23 203.22.131.0/24 203.22.163.0/24 203.22.166.0/24 203.22.170.0/24 203.22.194.0/24 203.22.242.0/23 203.22.245.0/24 203.22.246.0/24 203.22.252.0/23 203.23.0.0/24 203.23.47.0/24 203.23.61.0/24 203.23.62.0/23 203.23.73.0/24 203.23.85.0/24 203.23.92.0/22 203.23.98.0/24 203.23.107.0/24 203.23.112.0/24 203.23.130.0/24 203.23.140.0/23 203.23.172.0/24 203.23.182.0/24 203.23.186.0/23 203.23.192.0/24 203.23.197.0/24 203.23.198.0/24 203.23.204.0/22 203.23.224.0/24 203.23.226.0/23 203.23.228.0/22 203.23.249.0/24 203.23.251.0/24 203.24.13.0/24 203.24.18.0/24 203.24.27.0/24 203.24.43.0/24 203.24.56.0/24 203.24.58.0/24 203.24.67.0/24 203.24.74.0/24 203.24.79.0/24 203.24.80.0/23 203.24.84.0/23 203.24.86.0/24 203.24.90.0/24 203.24.111.0/24 203.24.112.0/24 203.24.116.0/24 203.24.122.0/23 203.24.145.0/24 203.24.152.0/23 203.24.157.0/24 203.24.161.0/24 203.24.167.0/24 203.24.186.0/23 203.24.199.0/24 203.24.202.0/24 203.24.212.0/23 203.24.217.0/24 203.24.219.0/24 203.24.244.0/24 203.25.19.0/24 203.25.20.0/23 203.25.46.0/24 203.25.64.0/23 203.25.91.0/24 203.25.99.0/24 203.25.100.0/24 203.25.106.0/24 203.25.131.0/24 203.25.135.0/24 203.25.138.0/24 203.25.147.0/24 203.25.153.0/24 203.25.154.0/23 203.25.164.0/24 203.25.166.0/24 203.25.174.0/23 203.25.180.0/24 203.25.182.0/24 203.25.191.0/24 203.25.199.0/24 203.25.200.0/24 203.25.202.0/23 203.25.208.0/20 203.25.229.0/24 203.25.235.0/24 203.25.236.0/24 203.25.242.0/24 203.26.12.0/24 203.26.34.0/24 203.26.49.0/24 203.26.50.0/24 203.26.55.0/24 203.26.56.0/23 203.26.60.0/24 203.26.65.0/24 203.26.68.0/24 203.26.76.0/24 203.26.80.0/24 203.26.84.0/24 203.26.97.0/24 203.26.102.0/23 203.26.115.0/24 203.26.116.0/24 203.26.129.0/24 203.26.143.0/24 203.26.144.0/24 203.26.148.0/23 203.26.154.0/24 203.26.158.0/23 203.26.170.0/24 203.26.173.0/24 203.26.176.0/24 203.26.185.0/24 203.26.202.0/23 203.26.210.0/24 203.26.214.0/24 203.26.222.0/24 203.26.224.0/24 203.26.228.0/24 203.26.232.0/24 203.27.0.0/24 203.27.10.0/24 203.27.15.0/24 203.27.16.0/24 203.27.20.0/24 203.27.22.0/23 203.27.40.0/24 203.27.45.0/24 203.27.53.0/24 203.27.65.0/24 203.27.66.0/24 203.27.81.0/24 203.27.88.0/24 203.27.102.0/24 203.27.109.0/24 203.27.117.0/24 203.27.121.0/24 203.27.122.0/23 203.27.125.0/24 203.27.200.0/24 203.27.202.0/24 203.27.233.0/24 203.27.241.0/24 203.27.250.0/24 203.28.10.0/24 203.28.12.0/24 203.28.33.0/24 203.28.34.0/23 203.28.43.0/24 203.28.44.0/24 203.28.54.0/24 203.28.56.0/24 203.28.73.0/24 203.28.74.0/24 203.28.76.0/24 203.28.86.0/24 203.28.88.0/24 203.28.112.0/24 203.28.131.0/24 203.28.136.0/24 203.28.140.0/24 203.28.145.0/24 203.28.165.0/24 203.28.169.0/24 203.28.170.0/24 203.28.178.0/23 203.28.185.0/24 203.28.187.0/24 203.28.196.0/24 203.28.226.0/23 203.28.239.0/24 203.29.2.0/24 203.29.8.0/23 203.29.13.0/24 203.29.14.0/24 203.29.28.0/24 203.29.46.0/24 203.29.57.0/24 203.29.61.0/24 203.29.63.0/24 203.29.69.0/24 203.29.73.0/24 203.29.81.0/24 203.29.90.0/24 203.29.95.0/24 203.29.100.0/24 203.29.103.0/24 203.29.112.0/24 203.29.120.0/22 203.29.182.0/23 203.29.187.0/24 203.29.189.0/24 203.29.190.0/24 203.29.205.0/24 203.29.210.0/24 203.29.217.0/24 203.29.227.0/24 203.29.231.0/24 203.29.233.0/24 203.29.234.0/24 203.29.248.0/24 203.29.254.0/23 203.30.16.0/23 203.30.25.0/24 203.30.27.0/24 203.30.29.0/24 203.30.66.0/24 203.30.81.0/24 203.30.87.0/24 203.30.111.0/24 203.30.121.0/24 203.30.123.0/24 203.30.152.0/24 203.30.156.0/24 203.30.162.0/24 203.30.173.0/24 203.30.175.0/24 203.30.187.0/24 203.30.194.0/24 203.30.217.0/24 203.30.220.0/24 203.30.222.0/24 203.30.232.0/23 203.30.235.0/24 203.30.240.0/23 203.30.246.0/24 203.30.250.0/23 203.31.45.0/24 203.31.46.0/24 203.31.49.0/24 203.31.51.0/24 203.31.54.0/23 203.31.69.0/24 203.31.72.0/24 203.31.80.0/24 203.31.85.0/24 203.31.97.0/24 203.31.105.0/24 203.31.106.0/24 203.31.108.0/23 203.31.124.0/24 203.31.162.0/24 203.31.174.0/24 203.31.177.0/24 203.31.181.0/24 203.31.187.0/24 203.31.189.0/24 203.31.204.0/24 203.31.220.0/24 203.31.222.0/23 203.31.225.0/24 203.31.229.0/24 203.31.248.0/23 203.31.253.0/24 203.32.20.0/24 203.32.48.0/23 203.32.56.0/24 203.32.60.0/24 203.32.62.0/24 203.32.68.0/23 203.32.76.0/24 203.32.81.0/24 203.32.84.0/23 203.32.95.0/24 203.32.102.0/24 203.32.105.0/24 203.32.130.0/24 203.32.133.0/24 203.32.140.0/24 203.32.152.0/24 203.32.186.0/23 203.32.192.0/24 203.32.196.0/24 203.32.203.0/24 203.32.204.0/23 203.32.212.0/24 203.33.4.0/24 203.33.7.0/24 203.33.21.0/24 203.33.26.0/24 203.33.32.0/24 203.33.63.0/24 203.33.64.0/24 203.33.67.0/24 203.33.68.0/24 203.33.73.0/24 203.33.79.0/24 203.33.100.0/24 203.33.122.0/24 203.33.129.0/24 203.33.131.0/24 203.33.145.0/24 203.33.156.0/24 203.33.158.0/23 203.33.174.0/24 203.33.185.0/24 203.33.200.0/24 203.33.202.0/23 203.33.204.0/24 203.33.206.0/23 203.33.214.0/23 203.33.224.0/23 203.33.226.0/24 203.33.233.0/24 203.33.243.0/24 203.33.250.0/24 203.34.4.0/24 203.34.21.0/24 203.34.27.0/24 203.34.39.0/24 203.34.48.0/23 203.34.54.0/24 203.34.56.0/23 203.34.67.0/24 203.34.69.0/24 203.34.76.0/24 203.34.92.0/24 203.34.106.0/24 203.34.113.0/24 203.34.147.0/24 203.34.150.0/24 203.34.152.0/23 203.34.161.0/24 203.34.162.0/24 203.34.187.0/24 203.34.204.0/22 203.34.232.0/24 203.34.240.0/24 203.34.242.0/24 203.34.245.0/24 203.34.251.0/24 203.55.2.0/23 203.55.4.0/24 203.55.10.0/24 203.55.13.0/24 203.55.22.0/24 203.55.30.0/24 203.55.93.0/24 203.55.101.0/24 203.55.109.0/24 203.55.110.0/24 203.55.116.0/23 203.55.119.0/24 203.55.128.0/23 203.55.146.0/23 203.55.192.0/24 203.55.196.0/24 203.55.218.0/23 203.55.221.0/24 203.55.224.0/24 203.56.1.0/24 203.56.4.0/24 203.56.12.0/24 203.56.24.0/24 203.56.38.0/24 203.56.40.0/24 203.56.46.0/24 203.56.68.0/23 203.56.82.0/23 203.56.84.0/23 203.56.95.0/24 203.56.110.0/24 203.56.121.0/24 203.56.161.0/24 203.56.169.0/24 203.56.172.0/23 203.56.175.0/24 203.56.183.0/24 203.56.185.0/24 203.56.187.0/24 203.56.192.0/24 203.56.198.0/24 203.56.201.0/24 203.56.208.0/23 203.56.210.0/24 203.56.214.0/24 203.56.216.0/24 203.56.227.0/24 203.56.228.0/24 203.56.232.0/24 203.56.240.0/24 203.56.252.0/24 203.56.254.0/24 203.57.5.0/24 203.57.6.0/24 203.57.12.0/23 203.57.28.0/24 203.57.39.0/24 203.57.46.0/24 203.57.58.0/24 203.57.61.0/24 203.57.66.0/24 203.57.69.0/24 203.57.70.0/23 203.57.73.0/24 203.57.90.0/24 203.57.101.0/24 203.57.109.0/24 203.57.123.0/24 203.57.157.0/24 203.57.200.0/24 203.57.202.0/24 203.57.206.0/24 203.57.222.0/24 203.57.224.0/20 203.57.246.0/23 203.57.249.0/24 203.57.253.0/24 203.57.254.0/23 203.62.2.0/24 203.62.131.0/24 203.62.139.0/24 203.62.161.0/24 203.62.197.0/24 203.62.228.0/22 203.62.234.0/24 203.62.246.0/24 203.76.160.0/22 203.76.168.0/22 203.77.180.0/22 203.78.48.0/20 203.79.0.0/20 203.80.4.0/23 203.80.32.0/20 203.80.57.0/24 203.80.132.0/22 203.80.144.0/20 203.81.16.0/20 203.82.0.0/23 203.83.0.0/22 203.83.56.0/21 203.83.224.0/20 203.86.0.0/17 203.86.254.0/23 203.88.32.0/19 203.88.192.0/19 203.89.0.0/22 203.89.136.0/22 203.90.0.0/22 203.90.8.0/22 203.90.128.0/18 203.90.192.0/19 203.91.32.0/19 203.91.96.0/20 203.91.120.0/21 203.92.0.0/22 203.92.160.0/19 203.93.0.0/16 203.94.0.0/19 203.95.0.0/21 203.95.96.0/19 203.95.128.0/18 203.95.224.0/19 203.99.16.0/20 203.99.80.0/20 203.100.32.0/20 203.100.63.0/24 203.100.80.0/20 203.100.96.0/19 203.100.192.0/20 203.104.32.0/20 203.105.96.0/19 203.105.128.0/19 203.107.0.0/17 203.110.160.0/19 203.110.208.0/20 203.110.232.0/23 203.110.234.0/24 203.114.244.0/22 203.118.192.0/19 203.118.241.0/24 203.118.248.0/22 203.119.24.0/21 203.119.32.0/22 203.119.80.0/22 203.119.85.0/24 203.119.113.0/24 203.119.114.0/23 203.119.116.0/22 203.119.128.0/17 203.128.32.0/19 203.128.96.0/19 203.130.32.0/19 203.132.32.0/19 203.134.240.0/21 203.135.96.0/19 203.135.160.0/20 203.142.224.0/19 203.144.96.0/19 203.145.0.0/19 203.148.0.0/18 203.148.64.0/20 203.148.80.0/22 203.148.86.0/23 203.149.92.0/22 203.152.64.0/19 203.152.128.0/19 203.153.0.0/22 203.156.192.0/18 203.158.16.0/21 203.160.129.0/24 203.160.192.0/19 203.161.0.0/22 203.161.180.0/24 203.161.192.0/19 203.166.160.0/19 203.168.0.0/19 203.170.58.0/23 203.171.0.0/22 203.171.224.0/20 203.174.4.0/24 203.174.7.0/24 203.174.96.0/19 203.175.128.0/19 203.175.192.0/18 203.176.0.0/18 203.176.64.0/19 203.176.168.0/21 203.184.80.0/20 203.187.160.0/19 203.189.0.0/23 203.189.6.0/23 203.189.112.0/22 203.189.192.0/19 203.190.96.0/20 203.190.249.0/24 203.191.0.0/23 203.191.20.0/22 203.191.28.0/22 203.191.64.0/18 203.191.144.0/20 203.192.0.0/19 203.193.81.60/30 203.193.224.0/19 203.195.64.0/19 203.195.128.0/17 203.196.0.0/21 203.202.236.0/22 203.205.64.0/19 203.205.128.0/17 203.207.64.0/18 203.207.128.0/17 203.208.0.0/20 203.208.16.0/22 203.208.32.0/19 203.209.224.0/19 203.212.0.0/20 203.212.80.0/20 203.215.146.0/24 204.69.150.0/24 206.221.221.64/29 207.117.165.0/24 207.254.180.0/22 207.254.185.0/24 207.254.186.0/23 207.254.188.0/24 209.93.189.0/24 209.93.190.0/23 210.2.0.0/19 210.5.0.0/19 210.5.56.0/21 210.5.128.0/19 210.12.0.0/15 210.14.64.0/19 210.14.112.0/20 210.14.128.0/17 210.15.0.0/17 210.15.128.0/18 210.16.128.0/18 210.21.0.0/16 210.22.0.0/16 210.23.32.0/19 210.25.0.0/16 210.26.0.0/15 210.28.0.0/14 210.32.0.0/12 210.51.0.0/16 210.52.0.0/18 210.52.64.0/19 210.52.96.0/21 210.52.104.0/22 210.52.108.0/24 210.52.110.0/23 210.52.112.0/20 210.52.128.0/17 210.53.0.0/16 210.56.192.0/19 210.72.0.0/14 210.76.0.0/15 210.78.0.0/16 210.79.64.0/18 210.79.224.0/19 210.82.0.0/15 210.87.128.0/18 210.176.26.0/27 210.177.188.84/32 210.185.192.0/18 210.192.96.0/19 211.64.0.0/13 211.80.0.0/12 211.96.0.0/13 211.136.0.0/13 211.144.0.0/12 211.160.0.0/13 212.63.183.19/32 218.0.0.0/11 218.56.0.0/13 218.64.0.0/11 218.96.0.0/14 218.100.88.0/21 218.100.96.0/19 218.100.128.0/17 218.104.0.0/14 218.108.0.0/15 218.185.192.0/19 218.185.240.0/21 218.192.0.0/12 218.240.0.0/13 218.249.0.0/16 219.72.0.0/16 219.82.0.0/16 219.83.128.0/17 219.128.0.0/11 219.216.0.0/13 219.224.0.0/12 219.242.0.0/15 219.244.0.0/14 220.101.192.0/18 220.112.0.0/14 220.152.128.0/17 220.154.0.0/15 220.160.0.0/11 220.192.0.0/12 220.231.0.0/18 220.231.128.0/17 220.232.64.0/18 220.234.0.0/16 220.242.0.0/15 220.247.136.0/21 220.248.0.0/14 220.252.0.0/16 221.0.0.0/13 221.8.0.0/14 221.12.0.0/17 221.12.128.0/18 221.13.0.0/16 221.14.0.0/15 221.122.0.0/15 221.128.128.0/17 221.129.0.0/16 221.130.0.0/15 221.133.224.0/19 221.136.0.0/15 221.172.0.0/14 221.176.0.0/13 221.192.0.0/14 221.196.0.0/15 221.198.0.0/16 221.199.0.0/17 221.199.128.0/18 221.199.192.0/20 221.199.224.0/19 221.200.0.0/13 221.208.0.0/12 221.224.0.0/12 222.16.0.0/12 222.32.0.0/11 222.64.0.0/11 222.125.0.0/16 222.126.128.0/17 222.128.0.0/12 222.160.0.0/14 222.168.0.0/13 222.176.0.0/12 222.192.0.0/11 222.240.0.0/13 222.248.0.0/15 223.0.0.0/12 223.20.0.0/15 223.27.184.0/22 223.64.0.0/11 223.96.0.0/12 223.112.0.0/14 223.116.0.0/15 223.120.0.0/13 223.128.0.0/15 223.144.0.0/12 223.160.0.0/14 223.166.0.0/15 223.192.0.0/15 223.198.0.0/15 223.201.0.0/16 223.202.0.0/15 223.208.0.0/13 223.220.0.0/15 223.223.176.0/20 223.223.192.0/20 223.240.0.0/13 223.248.0.0/14 223.252.128.0/19 223.252.160.0/24 223.252.161.0/26 223.252.161.128/25 223.252.162.0/23 223.252.164.0/22 223.252.168.0/21 223.252.176.0/20 223.252.192.0/18 223.254.0.0/16 223.255.0.0/17 223.255.236.0/22 223.255.252.0/23 2001:250::/39 2001:250:200::/46 2001:250:204::/47 2001:250:206::/48 2001:250:207::/49 2001:250:207:8000::/49 2001:250:208::/49 2001:250:208:8000::/49 2001:250:209::/49 2001:250:209:8000::/49 2001:250:20a::/49 2001:250:20a:8000::/49 2001:250:20b::/48 2001:250:20c::/46 2001:250:210::/46 2001:250:214::/47 2001:250:216::/48 2001:250:217::/49 2001:250:217:8000::/49 2001:250:218::/48 2001:250:219::/49 2001:250:219:8000::/49 2001:250:21a::/47 2001:250:21c::/46 2001:250:220::/43 2001:250:240::/42 2001:250:280::/41 2001:250:300::/40 2001:250:400::/48 2001:250:401::/48 2001:250:402::/47 2001:250:404::/48 2001:250:405::/49 2001:250:405:8000::/49 2001:250:406::/47 2001:250:408::/45 2001:250:410::/44 2001:250:420::/43 2001:250:440::/42 2001:250:480::/41 2001:250:500::/40 2001:250:600::/39 2001:250:800::/38 2001:250:c00::/48 2001:250:c01::/49 2001:250:c01:8000::/49 2001:250:c02::/49 2001:250:c02:8000::/49 2001:250:c03::/48 2001:250:c04::/46 2001:250:c08::/45 2001:250:c10::/44 2001:250:c20::/43 2001:250:c40::/42 2001:250:c80::/41 2001:250:d00::/40 2001:250:e00::/39 2001:250:1000::/48 2001:250:1001::/49 2001:250:1001:8000::/49 2001:250:1002::/49 2001:250:1002:8000::/49 2001:250:1003::/48 2001:250:1004::/49 2001:250:1004:8000::/49 2001:250:1005::/48 2001:250:1006::/48 2001:250:1007::/48 2001:250:1008::/45 2001:250:1010::/44 2001:250:1020::/43 2001:250:1040::/42 2001:250:1080::/41 2001:250:1100::/40 2001:250:1200::/39 2001:250:1400::/48 2001:250:1401::/49 2001:250:1401:8000::/49 2001:250:1402::/48 2001:250:1403::/49 2001:250:1403:8000::/49 2001:250:1404::/46 2001:250:1408::/45 2001:250:1410::/44 2001:250:1420::/43 2001:250:1440::/42 2001:250:1480::/41 2001:250:1500::/40 2001:250:1600::/39 2001:250:1800::/38 2001:250:1c00::/47 2001:250:1c02::/49 2001:250:1c02:8000::/49 2001:250:1c03::/48 2001:250:1c04::/46 2001:250:1c08::/45 2001:250:1c10::/44 2001:250:1c20::/43 2001:250:1c40::/42 2001:250:1c80::/41 2001:250:1d00::/40 2001:250:1e00::/39 2001:250:2000::/48 2001:250:2001::/49 2001:250:2001:8000::/49 2001:250:2002::/48 2001:250:2003::/49 2001:250:2003:8000::/49 2001:250:2004::/48 2001:250:2005::/49 2001:250:2005:8000::/49 2001:250:2006::/48 2001:250:2007::/49 2001:250:2007:8000::/49 2001:250:2008::/48 2001:250:2009::/49 2001:250:2009:8000::/49 2001:250:200a::/47 2001:250:200c::/46 2001:250:2010::/44 2001:250:2020::/43 2001:250:2040::/42 2001:250:2080::/41 2001:250:2100::/40 2001:250:2200::/39 2001:250:2400::/38 2001:250:2800::/49 2001:250:2800:8000::/49 2001:250:2801::/48 2001:250:2802::/47 2001:250:2804::/46 2001:250:2808::/45 2001:250:2810::/44 2001:250:2820::/43 2001:250:2840::/42 2001:250:2880::/41 2001:250:2900::/40 2001:250:2a00::/39 2001:250:2c00::/38 2001:250:3000::/49 2001:250:3000:8000::/49 2001:250:3001::/48 2001:250:3002::/49 2001:250:3002:8000::/49 2001:250:3003::/48 2001:250:3004::/46 2001:250:3008::/45 2001:250:3010::/44 2001:250:3020::/43 2001:250:3040::/42 2001:250:3080::/41 2001:250:3100::/40 2001:250:3200::/39 2001:250:3400::/38 2001:250:3800::/38 2001:250:3c00::/49 2001:250:3c00:8000::/49 2001:250:3c01::/48 2001:250:3c02::/49 2001:250:3c02:8000::/49 2001:250:3c03::/48 2001:250:3c04::/46 2001:250:3c08::/45 2001:250:3c10::/44 2001:250:3c20::/43 2001:250:3c40::/42 2001:250:3c80::/41 2001:250:3d00::/40 2001:250:3e00::/39 2001:250:4000::/48 2001:250:4001::/49 2001:250:4001:8000::/49 2001:250:4002::/49 2001:250:4002:8000::/49 2001:250:4003::/49 2001:250:4003:8000::/49 2001:250:4004::/48 2001:250:4005::/48 2001:250:4006::/47 2001:250:4008::/45 2001:250:4010::/44 2001:250:4020::/43 2001:250:4040::/42 2001:250:4080::/41 2001:250:4100::/40 2001:250:4200::/39 2001:250:4400::/48 2001:250:4401::/49 2001:250:4401:8000::/49 2001:250:4402::/49 2001:250:4402:8000::/49 2001:250:4403::/49 2001:250:4403:8000::/49 2001:250:4404::/46 2001:250:4408::/45 2001:250:4410::/44 2001:250:4420::/43 2001:250:4440::/42 2001:250:4480::/41 2001:250:4500::/40 2001:250:4600::/39 2001:250:4800::/45 2001:250:4808::/48 2001:250:4809::/49 2001:250:4809:8000::/49 2001:250:480a::/47 2001:250:480c::/47 2001:250:480e::/48 2001:250:480f::/49 2001:250:480f:8000::/49 2001:250:4810::/46 2001:250:4814::/49 2001:250:4814:8000::/49 2001:250:4815::/48 2001:250:4816::/47 2001:250:4818::/45 2001:250:4820::/43 2001:250:4840::/42 2001:250:4880::/41 2001:250:4900::/40 2001:250:4a00::/39 2001:250:4c00::/38 2001:250:5000::/47 2001:250:5002::/48 2001:250:5003::/48 2001:250:5004::/49 2001:250:5004:8000::/49 2001:250:5005::/48 2001:250:5006::/47 2001:250:5008::/46 2001:250:500c::/47 2001:250:500e::/48 2001:250:500f::/49 2001:250:500f:8000::/49 2001:250:5010::/44 2001:250:5020::/43 2001:250:5040::/42 2001:250:5080::/41 2001:250:5100::/40 2001:250:5200::/39 2001:250:5400::/48 2001:250:5401::/49 2001:250:5401:8000::/49 2001:250:5402::/49 2001:250:5402:8000::/49 2001:250:5403::/48 2001:250:5404::/49 2001:250:5404:8000::/49 2001:250:5405::/49 2001:250:5405:8000::/49 2001:250:5406::/47 2001:250:5408::/47 2001:250:540a::/49 2001:250:540a:8000::/49 2001:250:540b::/48 2001:250:540c::/46 2001:250:5410::/44 2001:250:5420::/43 2001:250:5440::/42 2001:250:5480::/41 2001:250:5500::/40 2001:250:5600::/39 2001:250:5800::/37 2001:250:6000::/38 2001:250:6400::/45 2001:250:6408::/47 2001:250:640a::/49 2001:250:640a:8000::/49 2001:250:640b::/48 2001:250:640c::/46 2001:250:6410::/44 2001:250:6420::/43 2001:250:6440::/42 2001:250:6480::/41 2001:250:6500::/40 2001:250:6600::/39 2001:250:6800::/48 2001:250:6801::/48 2001:250:6802::/48 2001:250:6803::/49 2001:250:6803:8000::/49 2001:250:6804::/49 2001:250:6804:8000::/49 2001:250:6805::/48 2001:250:6806::/47 2001:250:6808::/45 2001:250:6810::/44 2001:250:6820::/43 2001:250:6840::/42 2001:250:6880::/41 2001:250:6900::/40 2001:250:6a00::/39 2001:250:6c00::/49 2001:250:6c00:8000::/49 2001:250:6c01::/48 2001:250:6c02::/48 2001:250:6c03::/48 2001:250:6c04::/46 2001:250:6c08::/45 2001:250:6c10::/44 2001:250:6c20::/43 2001:250:6c40::/42 2001:250:6c80::/41 2001:250:6d00::/40 2001:250:6e00::/39 2001:250:7000::/38 2001:250:7400::/48 2001:250:7401::/48 2001:250:7402::/47 2001:250:7404::/46 2001:250:7408::/45 2001:250:7410::/44 2001:250:7420::/43 2001:250:7440::/42 2001:250:7480::/41 2001:250:7500::/40 2001:250:7600::/39 2001:250:7800::/48 2001:250:7801::/49 2001:250:7801:8000::/49 2001:250:7802::/49 2001:250:7802:8000::/49 2001:250:7803::/48 2001:250:7804::/46 2001:250:7808::/45 2001:250:7810::/44 2001:250:7820::/43 2001:250:7840::/42 2001:250:7880::/41 2001:250:7900::/40 2001:250:7a00::/39 2001:250:7c00::/38 2001:250:8000::/33 2001:251::/32 2001:252::/32 2001:254::/32 2001:256::/40 2001:256:100::/49 2001:256:100:8000::/49 2001:256:101::/48 2001:256:102::/47 2001:256:104::/46 2001:256:108::/45 2001:256:110::/44 2001:256:120::/43 2001:256:140::/42 2001:256:180::/41 2001:256:200::/39 2001:256:400::/38 2001:256:800::/37 2001:256:1000::/36 2001:256:2000::/35 2001:256:4000::/34 2001:256:8000::/33 2001:420:5883::/49 2001:420:5895::/49 2001:420:5a40::/49 2001:420:5a44:1200::/56 2001:420:c0d8::/49 2001:470:24::/49 2001:470:66::/49 2001:470:49e5:8000::/49 2001:470:8092::/49 2001:470:80b7::/49 2001:470:8328::/49 2001:470:83bc::/49 2001:470:83d0:8000::/49 2001:470:83e9::/49 2001:470:8579::/49 2001:470:f1fb::/49 2001:470:f383::/49 2001:470:f3be::/48 2001:470:f4b4:8000::/49 2001:470:f4c4::/49 2001:470:f892::/49 2001:470:f91c::/49 2001:470:fa49::/49 2001:470:fb3c::/49 2001:470:fc63::/49 2001:470:fe7c:8000::/49 2001:7fa:5::/48 2001:7fa:10::/48 2001:c68::/32 2001:cc0::/35 2001:cc0:2000::/44 2001:cc0:2010::/47 2001:cc0:2012::/49 2001:cc0:2012:8000::/49 2001:cc0:2013::/48 2001:cc0:2014::/47 2001:cc0:2016::/48 2001:cc0:2017::/48 2001:cc0:2018::/49 2001:cc0:2018:8000::/49 2001:cc0:2019::/48 2001:cc0:201a::/47 2001:cc0:201c::/47 2001:cc0:201e::/49 2001:cc0:201e:8000::/49 2001:cc0:201f::/48 2001:cc0:2020::/49 2001:cc0:2020:8000::/49 2001:cc0:2021::/48 2001:cc0:2022::/49 2001:cc0:2022:8000::/49 2001:cc0:2023::/48 2001:cc0:2024::/49 2001:cc0:2024:8000::/49 2001:cc0:2025::/48 2001:cc0:2026::/49 2001:cc0:2026:8000::/49 2001:cc0:2027::/48 2001:cc0:2028::/49 2001:cc0:2028:8000::/49 2001:cc0:2029::/48 2001:cc0:202a::/49 2001:cc0:202a:8000::/49 2001:cc0:202b::/48 2001:cc0:202c::/49 2001:cc0:202c:8000::/49 2001:cc0:202d::/48 2001:cc0:202e::/47 2001:cc0:2030::/46 2001:cc0:2034::/49 2001:cc0:2034:8000::/49 2001:cc0:2035::/48 2001:cc0:2036::/47 2001:cc0:2038::/46 2001:cc0:203c::/49 2001:cc0:203c:8000::/49 2001:cc0:203d::/48 2001:cc0:203e::/47 2001:cc0:2040::/46 2001:cc0:2044::/49 2001:cc0:2044:8000::/49 2001:cc0:2045::/48 2001:cc0:2046::/47 2001:cc0:2048::/45 2001:cc0:2050::/44 2001:cc0:2060::/43 2001:cc0:2080::/41 2001:cc0:2100::/40 2001:cc0:2200::/39 2001:cc0:2400::/44 2001:cc0:2410::/45 2001:cc0:2418::/46 2001:cc0:241c::/49 2001:cc0:241c:8000::/49 2001:cc0:241d::/48 2001:cc0:241e::/47 2001:cc0:2420::/46 2001:cc0:2424::/47 2001:cc0:2426::/49 2001:cc0:2426:8000::/49 2001:cc0:2427::/48 2001:cc0:2428::/45 2001:cc0:2430::/44 2001:cc0:2440::/44 2001:cc0:2450::/45 2001:cc0:2458::/46 2001:cc0:245c::/49 2001:cc0:245c:8000::/49 2001:cc0:245d::/48 2001:cc0:245e::/47 2001:cc0:2460::/43 2001:cc0:2480::/41 2001:cc0:2500::/40 2001:cc0:2600::/39 2001:cc0:2800::/38 2001:cc0:2c00::/39 2001:cc0:2e00::/40 2001:cc0:2f00::/41 2001:cc0:2f80::/42 2001:cc0:2fc0::/43 2001:cc0:2fe0::/44 2001:cc0:2ff0::/45 2001:cc0:2ff8::/46 2001:cc0:2ffc::/47 2001:cc0:2ffe::/48 2001:cc0:2fff::/49 2001:cc0:2fff:8000::/49 2001:cc0:3000::/36 2001:cc0:4000::/34 2001:cc0:8000::/35 2001:cc0:a000::/46 2001:cc0:a004::/49 2001:cc0:a004:8000::/49 2001:cc0:a005::/48 2001:cc0:a006::/49 2001:cc0:a006:8000::/49 2001:cc0:a007::/48 2001:cc0:a008::/49 2001:cc0:a008:8000::/49 2001:cc0:a009::/48 2001:cc0:a00a::/49 2001:cc0:a00a:8000::/49 2001:cc0:a00b::/48 2001:cc0:a00c::/49 2001:cc0:a00c:8000::/49 2001:cc0:a00d::/48 2001:cc0:a00e::/49 2001:cc0:a00e:8000::/49 2001:cc0:a00f::/48 2001:cc0:a010::/47 2001:cc0:a012::/48 2001:cc0:a013::/48 2001:cc0:a014::/49 2001:cc0:a014:8000::/49 2001:cc0:a015::/48 2001:cc0:a016::/47 2001:cc0:a018::/49 2001:cc0:a018:8000::/49 2001:cc0:a019::/48 2001:cc0:a01a::/47 2001:cc0:a01c::/46 2001:cc0:a020::/43 2001:cc0:a040::/42 2001:cc0:a080::/41 2001:cc0:a100::/40 2001:cc0:a200::/39 2001:cc0:a400::/38 2001:cc0:a800::/37 2001:cc0:b000::/47 2001:cc0:b002::/49 2001:cc0:b002:8000::/49 2001:cc0:b003::/48 2001:cc0:b004::/49 2001:cc0:b004:8000::/49 2001:cc0:b005::/48 2001:cc0:b006::/47 2001:cc0:b008::/46 2001:cc0:b00c::/49 2001:cc0:b00c:8000::/49 2001:cc0:b00d::/48 2001:cc0:b00e::/47 2001:cc0:b010::/44 2001:cc0:b020::/43 2001:cc0:b040::/42 2001:cc0:b080::/41 2001:cc0:b100::/40 2001:cc0:b200::/39 2001:cc0:b400::/38 2001:cc0:b800::/37 2001:cc0:c000::/47 2001:cc0:c002::/49 2001:cc0:c002:8000::/49 2001:cc0:c003::/48 2001:cc0:c004::/46 2001:cc0:c008::/49 2001:cc0:c008:8000::/49 2001:cc0:c009::/48 2001:cc0:c00a::/47 2001:cc0:c00c::/46 2001:cc0:c010::/44 2001:cc0:c020::/43 2001:cc0:c040::/42 2001:cc0:c080::/41 2001:cc0:c100::/40 2001:cc0:c200::/39 2001:cc0:c400::/38 2001:cc0:c800::/37 2001:cc0:d000::/47 2001:cc0:d002::/49 2001:cc0:d002:8000::/49 2001:cc0:d003::/48 2001:cc0:d004::/49 2001:cc0:d004:8000::/49 2001:cc0:d005::/48 2001:cc0:d006::/47 2001:cc0:d008::/45 2001:cc0:d010::/44 2001:cc0:d020::/43 2001:cc0:d040::/42 2001:cc0:d080::/41 2001:cc0:d100::/40 2001:cc0:d200::/39 2001:cc0:d400::/38 2001:cc0:d800::/37 2001:cc0:e000::/36 2001:cc0:f000::/45 2001:cc0:f008::/49 2001:cc0:f008:8000::/49 2001:cc0:f009::/48 2001:cc0:f00a::/47 2001:cc0:f00c::/46 2001:cc0:f010::/44 2001:cc0:f020::/43 2001:cc0:f040::/42 2001:cc0:f080::/41 2001:cc0:f100::/40 2001:cc0:f200::/39 2001:cc0:f400::/38 2001:cc0:f800::/37 2001:da8::/41 2001:da8:80::/43 2001:da8:a0::/45 2001:da8:a8::/46 2001:da8:ac::/47 2001:da8:ae::/48 2001:da8:af::/49 2001:da8:af:8000::/49 2001:da8:b0::/45 2001:da8:b8::/46 2001:da8:bc::/48 2001:da8:bd::/49 2001:da8:bd:8000::/49 2001:da8:be::/47 2001:da8:c0::/42 2001:da8:100::/40 2001:da8:200::/49 2001:da8:200:8000::/49 2001:da8:201::/49 2001:da8:201:8000::/49 2001:da8:202::/48 2001:da8:203::/48 2001:da8:204::/49 2001:da8:204:8000::/49 2001:da8:205::/49 2001:da8:205:8000::/49 2001:da8:206::/48 2001:da8:207::/48 2001:da8:208::/48 2001:da8:209::/49 2001:da8:209:8000::/49 2001:da8:20a::/49 2001:da8:20a:8000::/49 2001:da8:20b::/48 2001:da8:20c::/48 2001:da8:20d::/49 2001:da8:20d:8000::/49 2001:da8:20e::/48 2001:da8:20f::/49 2001:da8:20f:8000::/49 2001:da8:210::/48 2001:da8:211::/48 2001:da8:212::/47 2001:da8:214::/49 2001:da8:214:8000::/49 2001:da8:215::/48 2001:da8:216::/48 2001:da8:217::/48 2001:da8:218::/49 2001:da8:218:8000::/49 2001:da8:219::/49 2001:da8:219:8000::/49 2001:da8:21a::/47 2001:da8:21c::/49 2001:da8:21c:8000::/49 2001:da8:21d::/49 2001:da8:21d:8000::/49 2001:da8:21e::/47 2001:da8:220::/46 2001:da8:224::/48 2001:da8:225::/49 2001:da8:225:8000::/49 2001:da8:226::/47 2001:da8:228::/47 2001:da8:22a::/49 2001:da8:22a:8000::/49 2001:da8:22b::/48 2001:da8:22c::/48 2001:da8:22d::/48 2001:da8:22e::/47 2001:da8:230::/49 2001:da8:230:8000::/49 2001:da8:231::/48 2001:da8:232::/49 2001:da8:232:8000::/49 2001:da8:233::/48 2001:da8:234::/48 2001:da8:235::/49 2001:da8:235:8000::/49 2001:da8:236::/48 2001:da8:237::/48 2001:da8:238::/49 2001:da8:238:8000::/49 2001:da8:239::/48 2001:da8:23a::/48 2001:da8:23b::/49 2001:da8:23b:8000::/49 2001:da8:23c::/49 2001:da8:23c:8000::/49 2001:da8:23d::/49 2001:da8:23d:8000::/49 2001:da8:23e::/47 2001:da8:240::/45 2001:da8:248::/46 2001:da8:24c::/47 2001:da8:24e::/49 2001:da8:24e:8000::/49 2001:da8:24f::/48 2001:da8:250::/47 2001:da8:252::/48 2001:da8:253::/49 2001:da8:253:8000::/49 2001:da8:254::/48 2001:da8:255::/49 2001:da8:255:8000::/49 2001:da8:256::/47 2001:da8:258::/49 2001:da8:258:8000::/49 2001:da8:259::/48 2001:da8:25a::/47 2001:da8:25c::/46 2001:da8:260::/43 2001:da8:280::/41 2001:da8:300::/40 2001:da8:400::/38 2001:da8:800::/37 2001:da8:1000::/47 2001:da8:1002::/48 2001:da8:1003::/49 2001:da8:1003:8000::/49 2001:da8:1004::/49 2001:da8:1004:8000::/49 2001:da8:1005::/49 2001:da8:1005:8000::/49 2001:da8:1006::/49 2001:da8:1006:8000::/49 2001:da8:1007::/49 2001:da8:1007:8000::/49 2001:da8:1008::/49 2001:da8:1008:8000::/49 2001:da8:1009::/48 2001:da8:100a::/49 2001:da8:100a:8000::/49 2001:da8:100b::/48 2001:da8:100c::/47 2001:da8:100e::/49 2001:da8:100e:8000::/49 2001:da8:100f::/48 2001:da8:1010::/48 2001:da8:1011::/49 2001:da8:1011:8000::/49 2001:da8:1012::/47 2001:da8:1014::/46 2001:da8:1018::/45 2001:da8:1020::/44 2001:da8:1030::/48 2001:da8:1031::/49 2001:da8:1031:8000::/49 2001:da8:1032::/49 2001:da8:1032:8000::/49 2001:da8:1033::/48 2001:da8:1034::/46 2001:da8:1038::/45 2001:da8:1040::/42 2001:da8:1080::/41 2001:da8:1100::/40 2001:da8:1200::/39 2001:da8:1400::/38 2001:da8:1800::/37 2001:da8:2000::/47 2001:da8:2002::/48 2001:da8:2003::/48 2001:da8:2004::/49 2001:da8:2004:8000::/49 2001:da8:2005::/49 2001:da8:2005:8000::/49 2001:da8:2006::/49 2001:da8:2006:8000::/49 2001:da8:2007::/48 2001:da8:2008::/47 2001:da8:200a::/48 2001:da8:200b::/48 2001:da8:200c::/47 2001:da8:200e::/49 2001:da8:200e:8000::/49 2001:da8:200f::/49 2001:da8:200f:8000::/49 2001:da8:2010::/49 2001:da8:2010:8000::/49 2001:da8:2011::/48 2001:da8:2012::/48 2001:da8:2013::/49 2001:da8:2013:8000::/49 2001:da8:2014::/47 2001:da8:2016::/48 2001:da8:2017::/49 2001:da8:2017:8000::/49 2001:da8:2018::/48 2001:da8:2019::/49 2001:da8:2019:8000::/49 2001:da8:201a::/47 2001:da8:201c::/48 2001:da8:201d::/49 2001:da8:201d:8000::/49 2001:da8:201e::/47 2001:da8:2020::/43 2001:da8:2040::/42 2001:da8:2080::/41 2001:da8:2100::/40 2001:da8:2200::/39 2001:da8:2400::/38 2001:da8:2800::/37 2001:da8:3000::/48 2001:da8:3001::/49 2001:da8:3001:8000::/49 2001:da8:3002::/47 2001:da8:3004::/49 2001:da8:3004:8000::/49 2001:da8:3005::/48 2001:da8:3006::/47 2001:da8:3008::/45 2001:da8:3010::/47 2001:da8:3012::/49 2001:da8:3012:8000::/49 2001:da8:3013::/48 2001:da8:3014::/46 2001:da8:3018::/45 2001:da8:3020::/43 2001:da8:3040::/42 2001:da8:3080::/41 2001:da8:3100::/40 2001:da8:3200::/39 2001:da8:3400::/38 2001:da8:3800::/37 2001:da8:4000::/48 2001:da8:4001::/48 2001:da8:4002::/49 2001:da8:4002:8000::/49 2001:da8:4003::/49 2001:da8:4003:8000::/49 2001:da8:4004::/46 2001:da8:4008::/47 2001:da8:400a::/48 2001:da8:400b::/49 2001:da8:400b:8000::/49 2001:da8:400c::/46 2001:da8:4010::/46 2001:da8:4014::/48 2001:da8:4015::/49 2001:da8:4015:8000::/49 2001:da8:4016::/47 2001:da8:4018::/48 2001:da8:4019::/49 2001:da8:4019:8000::/49 2001:da8:401a::/47 2001:da8:401c::/46 2001:da8:4020::/43 2001:da8:4040::/42 2001:da8:4080::/41 2001:da8:4100::/40 2001:da8:4200::/39 2001:da8:4400::/38 2001:da8:4800::/37 2001:da8:5000::/49 2001:da8:5000:8000::/49 2001:da8:5001::/48 2001:da8:5002::/47 2001:da8:5004::/46 2001:da8:5008::/46 2001:da8:500c::/48 2001:da8:500d::/49 2001:da8:500d:8000::/49 2001:da8:500e::/47 2001:da8:5010::/46 2001:da8:5014::/48 2001:da8:5015::/49 2001:da8:5015:8000::/49 2001:da8:5016::/47 2001:da8:5018::/49 2001:da8:5018:8000::/49 2001:da8:5019::/48 2001:da8:501a::/47 2001:da8:501c::/46 2001:da8:5020::/43 2001:da8:5040::/42 2001:da8:5080::/41 2001:da8:5100::/40 2001:da8:5200::/39 2001:da8:5400::/38 2001:da8:5800::/37 2001:da8:6000::/49 2001:da8:6000:8000::/49 2001:da8:6001::/48 2001:da8:6002::/48 2001:da8:6003::/49 2001:da8:6003:8000::/49 2001:da8:6004::/49 2001:da8:6004:8000::/49 2001:da8:6005::/50 2001:da8:6005:4000::/52 2001:da8:6005:5000::/53 2001:da8:6005:5800::/55 2001:da8:6005:5a00::/56 2001:da8:6005:5b00::/56 2001:da8:6005:5c00::/54 2001:da8:6005:6000::/51 2001:da8:6005:8000::/49 2001:da8:6006::/47 2001:da8:6008::/46 2001:da8:600c::/47 2001:da8:600e::/49 2001:da8:600e:8000::/49 2001:da8:600f::/48 2001:da8:6010::/44 2001:da8:6020::/43 2001:da8:6040::/42 2001:da8:6080::/41 2001:da8:6100::/40 2001:da8:6200::/39 2001:da8:6400::/38 2001:da8:6800::/37 2001:da8:7000::/48 2001:da8:7001::/49 2001:da8:7001:8000::/49 2001:da8:7002::/48 2001:da8:7003::/49 2001:da8:7003:8000::/49 2001:da8:7004::/47 2001:da8:7006::/48 2001:da8:7007::/49 2001:da8:7007:8000::/49 2001:da8:7008::/45 2001:da8:7010::/47 2001:da8:7012::/49 2001:da8:7012:8000::/49 2001:da8:7013::/49 2001:da8:7013:8000::/49 2001:da8:7014::/46 2001:da8:7018::/45 2001:da8:7020::/43 2001:da8:7040::/42 2001:da8:7080::/41 2001:da8:7100::/40 2001:da8:7200::/39 2001:da8:7400::/38 2001:da8:7800::/37 2001:da8:8000::/47 2001:da8:8002::/49 2001:da8:8002:8000::/49 2001:da8:8003::/48 2001:da8:8004::/48 2001:da8:8005::/48 2001:da8:8006::/48 2001:da8:8007::/49 2001:da8:8007:8000::/49 2001:da8:8008::/49 2001:da8:8008:8000::/49 2001:da8:8009::/48 2001:da8:800a::/49 2001:da8:800a:8000::/49 2001:da8:800b::/48 2001:da8:800c::/49 2001:da8:800c:8000::/49 2001:da8:800d::/49 2001:da8:800d:8000::/49 2001:da8:800e::/47 2001:da8:8010::/45 2001:da8:8018::/47 2001:da8:801a::/48 2001:da8:801b::/49 2001:da8:801b:8000::/49 2001:da8:801c::/46 2001:da8:8020::/43 2001:da8:8040::/42 2001:da8:8080::/41 2001:da8:8100::/40 2001:da8:8200::/39 2001:da8:8400::/38 2001:da8:8800::/37 2001:da8:9000::/49 2001:da8:9000:8000::/49 2001:da8:9001::/49 2001:da8:9001:8000::/49 2001:da8:9002::/49 2001:da8:9002:8000::/49 2001:da8:9003::/48 2001:da8:9004::/47 2001:da8:9006::/49 2001:da8:9006:8000::/51 2001:da8:9006:a000::/52 2001:da8:9006:b000::/54 2001:da8:9006:b400::/54 2001:da8:9006:b800::/53 2001:da8:9006:c000::/50 2001:da8:9007::/49 2001:da8:9007:8000::/49 2001:da8:9008::/45 2001:da8:9010::/44 2001:da8:9020::/43 2001:da8:9040::/42 2001:da8:9080::/41 2001:da8:9100::/40 2001:da8:9200::/39 2001:da8:9400::/38 2001:da8:9800::/37 2001:da8:a000::/49 2001:da8:a000:8000::/49 2001:da8:a001::/48 2001:da8:a002::/49 2001:da8:a002:8000::/49 2001:da8:a003::/48 2001:da8:a004::/46 2001:da8:a008::/48 2001:da8:a009::/49 2001:da8:a009:8000::/49 2001:da8:a00a::/47 2001:da8:a00c::/46 2001:da8:a010::/44 2001:da8:a020::/43 2001:da8:a040::/42 2001:da8:a080::/41 2001:da8:a100::/40 2001:da8:a200::/39 2001:da8:a400::/38 2001:da8:a800::/48 2001:da8:a801::/49 2001:da8:a801:8000::/49 2001:da8:a802::/47 2001:da8:a804::/46 2001:da8:a808::/47 2001:da8:a80a::/49 2001:da8:a80a:8000::/49 2001:da8:a80b::/48 2001:da8:a80c::/46 2001:da8:a810::/44 2001:da8:a820::/43 2001:da8:a840::/42 2001:da8:a880::/41 2001:da8:a900::/40 2001:da8:aa00::/39 2001:da8:ac00::/38 2001:da8:b000::/49 2001:da8:b000:8000::/49 2001:da8:b001::/48 2001:da8:b002::/48 2001:da8:b003::/49 2001:da8:b003:8000::/49 2001:da8:b004::/49 2001:da8:b004:8000::/49 2001:da8:b005::/49 2001:da8:b005:8000::/49 2001:da8:b006::/49 2001:da8:b006:8000::/49 2001:da8:b007::/48 2001:da8:b008::/46 2001:da8:b00c::/48 2001:da8:b00d::/49 2001:da8:b00d:8000::/49 2001:da8:b00e::/47 2001:da8:b010::/44 2001:da8:b020::/43 2001:da8:b040::/42 2001:da8:b080::/41 2001:da8:b100::/40 2001:da8:b200::/39 2001:da8:b400::/38 2001:da8:b800::/49 2001:da8:b800:8000::/49 2001:da8:b801::/48 2001:da8:b802::/48 2001:da8:b803::/49 2001:da8:b803:8000::/49 2001:da8:b804::/47 2001:da8:b806::/48 2001:da8:b807::/48 2001:da8:b808::/45 2001:da8:b810::/44 2001:da8:b820::/43 2001:da8:b840::/42 2001:da8:b880::/41 2001:da8:b900::/40 2001:da8:ba00::/39 2001:da8:bc00::/38 2001:da8:c000::/49 2001:da8:c000:8000::/49 2001:da8:c001::/48 2001:da8:c002::/48 2001:da8:c003::/49 2001:da8:c003:8000::/49 2001:da8:c004::/46 2001:da8:c008::/45 2001:da8:c010::/44 2001:da8:c020::/43 2001:da8:c040::/42 2001:da8:c080::/41 2001:da8:c100::/40 2001:da8:c200::/39 2001:da8:c400::/38 2001:da8:c800::/49 2001:da8:c800:8000::/49 2001:da8:c801::/48 2001:da8:c802::/48 2001:da8:c803::/49 2001:da8:c803:8000::/49 2001:da8:c804::/49 2001:da8:c804:8000::/49 2001:da8:c805::/48 2001:da8:c806::/47 2001:da8:c808::/45 2001:da8:c810::/44 2001:da8:c820::/43 2001:da8:c840::/42 2001:da8:c880::/41 2001:da8:c900::/40 2001:da8:ca00::/39 2001:da8:cc00::/38 2001:da8:d000::/48 2001:da8:d001::/49 2001:da8:d001:8000::/49 2001:da8:d002::/47 2001:da8:d004::/46 2001:da8:d008::/45 2001:da8:d010::/44 2001:da8:d020::/43 2001:da8:d040::/42 2001:da8:d080::/41 2001:da8:d100::/40 2001:da8:d200::/39 2001:da8:d400::/38 2001:da8:d800::/49 2001:da8:d800:8000::/49 2001:da8:d801::/48 2001:da8:d802::/47 2001:da8:d804::/48 2001:da8:d805::/48 2001:da8:d806::/48 2001:da8:d807::/49 2001:da8:d807:8000::/49 2001:da8:d808::/45 2001:da8:d810::/44 2001:da8:d820::/43 2001:da8:d840::/42 2001:da8:d880::/41 2001:da8:d900::/40 2001:da8:da00::/39 2001:da8:dc00::/38 2001:da8:e000::/49 2001:da8:e000:8000::/49 2001:da8:e001::/48 2001:da8:e002::/47 2001:da8:e004::/46 2001:da8:e008::/45 2001:da8:e010::/44 2001:da8:e020::/43 2001:da8:e040::/42 2001:da8:e080::/41 2001:da8:e100::/40 2001:da8:e200::/39 2001:da8:e400::/38 2001:da8:e800::/48 2001:da8:e801::/48 2001:da8:e802::/48 2001:da8:e803::/49 2001:da8:e803:8000::/49 2001:da8:e804::/55 2001:da8:e804:200::/55 2001:da8:e804:400::/54 2001:da8:e804:800::/53 2001:da8:e804:1000::/52 2001:da8:e804:2000::/51 2001:da8:e804:4000::/50 2001:da8:e804:8000::/49 2001:da8:e805::/48 2001:da8:e806::/47 2001:da8:e808::/45 2001:da8:e810::/44 2001:da8:e820::/43 2001:da8:e840::/42 2001:da8:e880::/41 2001:da8:e900::/40 2001:da8:ea00::/39 2001:da8:ec00::/38 2001:da8:f000::/37 2001:da8:f800::/38 2001:da8:fc00::/39 2001:da8:fe00::/40 2001:da8:ff00::/43 2001:da8:ff20::/44 2001:da8:ff30::/45 2001:da8:ff38::/47 2001:da8:ff3a::/49 2001:da8:ff3a:8000::/49 2001:da8:ff3b::/48 2001:da8:ff3c::/46 2001:da8:ff40::/42 2001:da8:ff80::/41 2001:da9::/32 2001:daa::/32 2001:dc7::/32 2001:dd8:1::/48 2001:dd8:5::/48 2001:dd8:1a::/48 2001:df0:27e::/48 2001:df0:2e9::/48 2001:df0:423::/48 2001:df3:800::/44 2001:df5:7800::/48 2001:df6:6800::/48 2001:e08::/32 2001:e18::/32 2001:e80::/32 2001:e88::/32 2001:f38::/32 2001:f88::/32 2001:4438::/32 2001:4510::/29 2001:b010:fc80::/49 2400:1380::/32 2400:3200::/32 2400:3280::/32 2400:3600::/32 2400:3a00::/32 2400:3e00::/32 2400:4600::/32 2400:4e00::/32 2400:5080::/32 2400:5280::/32 2400:5400::/32 2400:5580::/32 2400:5600::/32 2400:5a00::/32 2400:5c80::/32 2400:5e80::/32 2400:6000::/32 2400:6200::/32 2400:6600::/32 2400:6a00::/32 2400:6e00::/32 2400:6f80::/32 2400:7100::/32 2400:7200::/32 2400:7680::/32 2400:7f80::/32 2400:8080::/32 2400:8200::/32 2400:8580::/32 2400:8600::/32 2400:8780::/32 2400:8980::/32 2400:8e00::/32 2400:8f00::/32 2400:9580::/32 2400:9600::/32 2400:9a00::/32 2400:9e00::/32 2400:a380::/32 2400:a480::/33 2400:a480:8000::/35 2400:a480:a000::/37 2400:a480:a800::/39 2400:a480:aa00::/41 2400:a480:aa80::/43 2400:a480:aaa0::/45 2400:a480:aaa8::/47 2400:a480:aaaa::/49 2400:a480:aaaa:8000::/49 2400:a480:aaab::/48 2400:a480:aaac::/46 2400:a480:aab0::/44 2400:a480:aac0::/42 2400:a480:ab00::/40 2400:a480:ac00::/38 2400:a480:b000::/36 2400:a480:c000::/34 2400:a780::/32 2400:a900::/32 2400:a980::/32 2400:ae00::/32 2400:b200::/32 2400:b500::/32 2400:b600::/32 2400:b700::/32 2400:ba00::/32 2400:be00::/32 2400:bf00::/32 2400:c200::/32 2400:c380::/32 2400:cb80::/32 2400:cc80::/32 2400:ce00::/32 2400:cf80::/32 2400:d100::/32 2400:d200::/32 2400:d300::/32 2400:d380::/32 2400:d600::/32 2400:d780::/32 2400:da00::/32 2400:dd00::/32 2400:dd01::/36 2400:dd01:1000::/48 2400:dd01:1001::/49 2400:dd01:1001:8000::/49 2400:dd01:1002::/49 2400:dd01:1002:8000::/49 2400:dd01:1003::/48 2400:dd01:1004::/46 2400:dd01:1008::/48 2400:dd01:1009::/49 2400:dd01:1009:8000::/49 2400:dd01:100a::/47 2400:dd01:100c::/47 2400:dd01:100e::/49 2400:dd01:100e:8000::/49 2400:dd01:100f::/48 2400:dd01:1010::/44 2400:dd01:1020::/49 2400:dd01:1020:8000::/49 2400:dd01:1021::/48 2400:dd01:1022::/47 2400:dd01:1024::/46 2400:dd01:1028::/45 2400:dd01:1030::/44 2400:dd01:1040::/42 2400:dd01:1080::/41 2400:dd01:1100::/40 2400:dd01:1200::/39 2400:dd01:1400::/38 2400:dd01:1800::/37 2400:dd01:2000::/49 2400:dd01:2000:8000::/49 2400:dd01:2001::/48 2400:dd01:2002::/47 2400:dd01:2004::/46 2400:dd01:2008::/47 2400:dd01:200a::/49 2400:dd01:200a:8000::/49 2400:dd01:200b::/48 2400:dd01:200c::/49 2400:dd01:200c:8000::/49 2400:dd01:200d::/48 2400:dd01:200e::/47 2400:dd01:2010::/44 2400:dd01:2020::/43 2400:dd01:2040::/42 2400:dd01:2080::/41 2400:dd01:2100::/40 2400:dd01:2200::/39 2400:dd01:2400::/38 2400:dd01:2800::/37 2400:dd01:3000::/49 2400:dd01:3000:8000::/49 2400:dd01:3001::/48 2400:dd01:3002::/47 2400:dd01:3004::/46 2400:dd01:3008::/45 2400:dd01:3010::/44 2400:dd01:3020::/43 2400:dd01:3040::/42 2400:dd01:3080::/41 2400:dd01:3100::/40 2400:dd01:3200::/39 2400:dd01:3400::/38 2400:dd01:3800::/37 2400:dd01:4000::/34 2400:dd01:8000::/33 2400:dd02::/31 2400:dd04::/36 2400:dd04:1000::/47 2400:dd04:1002::/48 2400:dd04:1003::/49 2400:dd04:1003:8000::/49 2400:dd04:1004::/49 2400:dd04:1004:8000::/49 2400:dd04:1005::/49 2400:dd04:1005:8000::/49 2400:dd04:1006::/47 2400:dd04:1008::/45 2400:dd04:1010::/44 2400:dd04:1020::/43 2400:dd04:1040::/42 2400:dd04:1080::/41 2400:dd04:1100::/40 2400:dd04:1200::/39 2400:dd04:1400::/38 2400:dd04:1800::/37 2400:dd04:2000::/35 2400:dd04:4000::/34 2400:dd04:8000::/33 2400:dd05::/32 2400:dd06::/32 2400:dd07::/36 2400:dd07:1000::/47 2400:dd07:1002::/48 2400:dd07:1003::/49 2400:dd07:1003:8000::/49 2400:dd07:1004::/46 2400:dd07:1008::/45 2400:dd07:1010::/44 2400:dd07:1020::/43 2400:dd07:1040::/42 2400:dd07:1080::/41 2400:dd07:1100::/40 2400:dd07:1200::/39 2400:dd07:1400::/38 2400:dd07:1800::/37 2400:dd07:2000::/35 2400:dd07:4000::/34 2400:dd07:8000::/33 2400:dd08::/32 2400:dd09::/36 2400:dd09:1000::/47 2400:dd09:1002::/49 2400:dd09:1002:8000::/49 2400:dd09:1003::/48 2400:dd09:1004::/46 2400:dd09:1008::/45 2400:dd09:1010::/44 2400:dd09:1020::/43 2400:dd09:1040::/42 2400:dd09:1080::/41 2400:dd09:1100::/40 2400:dd09:1200::/39 2400:dd09:1400::/38 2400:dd09:1800::/37 2400:dd09:2000::/35 2400:dd09:4000::/34 2400:dd09:8000::/33 2400:dd0a::/31 2400:dd0c::/32 2400:dd0d::/36 2400:dd0d:1000::/48 2400:dd0d:1001::/49 2400:dd0d:1001:8000::/49 2400:dd0d:1002::/47 2400:dd0d:1004::/46 2400:dd0d:1008::/45 2400:dd0d:1010::/44 2400:dd0d:1020::/43 2400:dd0d:1040::/42 2400:dd0d:1080::/41 2400:dd0d:1100::/40 2400:dd0d:1200::/39 2400:dd0d:1400::/38 2400:dd0d:1800::/37 2400:dd0d:2000::/35 2400:dd0d:4000::/34 2400:dd0d:8000::/33 2400:dd0e::/31 2400:de00::/32 2400:de80::/32 2400:e680::/32 2400:e880::/32 2400:ee00::/32 2400:f480::/32 2400:f980::/32 2400:fe00::/32 2401:80::/32 2401:780::/32 2401:800::/32 2401:a00::/32 2401:e00::/32 2401:1000::/32 2401:1200::/32 2401:1e00::/32 2401:2080::/32 2401:2600::/32 2401:2780::/32 2401:2980::/32 2401:2a00::/32 2401:2e00::/32 2401:3100::/32 2401:3380::/32 2401:3480::/32 2401:3780::/32 2401:3800::/32 2401:3880::/32 2401:3980::/32 2401:3a00::/32 2401:3a80::/32 2401:3b80::/32 2401:3c80::/32 2401:3d80::/32 2401:3e80::/32 2401:3f80::/32 2401:4080::/32 2401:4180::/32 2401:4280::/32 2401:4380::/32 2401:4480::/32 2401:4580::/32 2401:4680::/32 2401:4780::/32 2401:4880::/32 2401:4a80::/32 2401:4b00::/32 2401:4f80::/32 2401:5180::/32 2401:5680::/32 2401:5880::/32 2401:5c80::/32 2401:7180::/32 2401:7580::/32 2401:7680::/32 2401:7700::/32 2401:7780::/32 2401:7880::/32 2401:7980::/32 2401:7a00::/32 2401:7a80::/32 2401:7b80::/32 2401:7c80::/32 2401:7d80::/32 2401:7e00::/32 2401:7f80::/32 2401:8000::/49 2401:8200::/32 2401:8380::/32 2401:8600::/32 2401:8680::/32 2401:8d00::/47 2401:8d00:2::/48 2401:8d00:3::/49 2401:8d00:3:8000::/49 2401:8d00:4::/46 2401:8d00:8::/45 2401:8d00:10::/44 2401:8d00:20::/43 2401:8d00:40::/42 2401:8d00:80::/41 2401:8d00:100::/40 2401:8d00:200::/39 2401:8d00:400::/38 2401:8d00:800::/37 2401:8d00:1000::/36 2401:8d00:2000::/35 2401:8d00:4000::/34 2401:8d00:8000::/33 2401:9380::/32 2401:9600::/32 2401:9a00::/32 2401:9a80::/32 2401:9b80::/32 2401:9f80::/32 2401:a180::/32 2401:a980::/32 2401:aa00::/32 2401:b180::/32 2401:b400::/32 2401:b480::/32 2401:b580::/32 2401:b600::/32 2401:b680::/32 2401:ba00::/32 2401:bb80::/32 2401:be00::/32 2401:c200::/32 2401:c600::/32 2401:ca00::/32 2401:ca80::/32 2401:cb80::/32 2401:cc00::/32 2401:ce00::/32 2401:d180::/32 2401:d780::/32 2401:da00::/32 2401:de00::/48 2401:de00:1::/49 2401:de00:1:8000::/49 2401:de00:2::/47 2401:de00:4::/46 2401:de00:8::/45 2401:de00:10::/44 2401:de00:20::/43 2401:de00:40::/42 2401:de00:80::/41 2401:de00:100::/40 2401:de00:200::/39 2401:de00:400::/38 2401:de00:800::/37 2401:de00:1000::/36 2401:de00:2000::/35 2401:de00:4000::/34 2401:de00:8000::/33 2401:e080::/32 2401:ec00::/44 2401:ec00:10::/46 2401:ec00:14::/48 2401:ec00:15::/49 2401:ec00:15:8000::/49 2401:ec00:16::/48 2401:ec00:17::/49 2401:ec00:17:8000::/49 2401:ec00:18::/45 2401:ec00:20::/44 2401:ec00:30::/45 2401:ec00:38::/49 2401:ec00:38:8000::/49 2401:ec00:39::/48 2401:ec00:3a::/47 2401:ec00:3c::/46 2401:ec00:40::/42 2401:ec00:80::/44 2401:ec00:90::/46 2401:ec00:94::/47 2401:ec00:96::/48 2401:ec00:97::/49 2401:ec00:97:8000::/49 2401:ec00:98::/45 2401:ec00:a0::/43 2401:ec00:c0::/42 2401:ec00:100::/45 2401:ec00:108::/49 2401:ec00:108:8000::/49 2401:ec00:109::/48 2401:ec00:10a::/47 2401:ec00:10c::/46 2401:ec00:110::/44 2401:ec00:120::/43 2401:ec00:140::/43 2401:ec00:160::/48 2401:ec00:161::/49 2401:ec00:161:8000::/49 2401:ec00:162::/47 2401:ec00:164::/46 2401:ec00:168::/45 2401:ec00:170::/44 2401:ec00:180::/41 2401:ec00:200::/39 2401:ec00:400::/38 2401:ec00:800::/37 2401:ec00:1000::/44 2401:ec00:1010::/47 2401:ec00:1012::/49 2401:ec00:1012:8000::/49 2401:ec00:1013::/48 2401:ec00:1014::/46 2401:ec00:1018::/45 2401:ec00:1020::/49 2401:ec00:1020:8000::/49 2401:ec00:1021::/48 2401:ec00:1022::/47 2401:ec00:1024::/46 2401:ec00:1028::/45 2401:ec00:1030::/49 2401:ec00:1030:8000::/49 2401:ec00:1031::/48 2401:ec00:1032::/47 2401:ec00:1034::/46 2401:ec00:1038::/45 2401:ec00:1040::/49 2401:ec00:1040:8000::/49 2401:ec00:1041::/48 2401:ec00:1042::/47 2401:ec00:1044::/46 2401:ec00:1048::/45 2401:ec00:1050::/44 2401:ec00:1060::/43 2401:ec00:1080::/41 2401:ec00:1100::/40 2401:ec00:1200::/39 2401:ec00:1400::/38 2401:ec00:1800::/37 2401:ec00:2000::/36 2401:ec00:3000::/47 2401:ec00:3002::/48 2401:ec00:3003::/49 2401:ec00:3003:8000::/49 2401:ec00:3004::/49 2401:ec00:3004:8000::/49 2401:ec00:3005::/48 2401:ec00:3006::/47 2401:ec00:3008::/45 2401:ec00:3010::/44 2401:ec00:3020::/43 2401:ec00:3040::/42 2401:ec00:3080::/41 2401:ec00:3100::/40 2401:ec00:3200::/39 2401:ec00:3400::/38 2401:ec00:3800::/37 2401:ec00:4000::/34 2401:ec00:8000::/33 2401:f300::/32 2401:fa00:40::/49 2401:fa00:41::/49 2401:fa00:42::/49 2401:fa80::/32 2401:fb80::/32 2401:fc80::/32 2401:fe80::/32 2402:880::/32 2402:e00::/32 2402:1000::/32 2402:1600::/32 2402:1f80::/32 2402:2000::/32 2402:2280::/32 2402:2780::/32 2402:2a00::/32 2402:2b80::/32 2402:2d00::/32 2402:2d80::/32 2402:2e80::/32 2402:3080::/32 2402:3180::/32 2402:3c00::/32 2402:3e00::/32 2402:3f80::/32 2402:4500::/32 2402:4a00::/32 2402:4a80::/32 2402:4b80::/32 2402:4d80::/32 2402:4e00::/32 2402:4f80::/32 2402:5180::/32 2402:5880::/32 2402:5b80::/32 2402:5d00::/32 2402:5e00::/32 2402:6280::/32 2402:6a00::/32 2402:6e00::/32 2402:7d00::/32 2402:8300::/32 2402:8800::/32 2402:8900::/32 2402:a200::/32 2402:ae00::/32 2402:b200::/32 2402:cf00::/32 2402:d300::/32 2402:f000::/48 2402:f000:1::/48 2402:f000:2::/47 2402:f000:4::/48 2402:f000:5::/48 2402:f000:6::/48 2402:f000:7::/48 2402:f000:8::/48 2402:f000:9::/49 2402:f000:9:8000::/49 2402:f000:a::/47 2402:f000:c::/46 2402:f000:10::/44 2402:f000:20::/43 2402:f000:40::/42 2402:f000:80::/41 2402:f000:100::/40 2402:f000:200::/39 2402:f000:400::/38 2402:f000:800::/37 2402:f000:1000::/36 2402:f000:2000::/35 2402:f000:4000::/34 2402:f000:8000::/34 2402:f000:c000::/35 2402:f000:e000::/36 2402:f000:f000::/37 2402:f000:f800::/38 2402:f000:fc00::/39 2402:f000:fe00::/40 2402:f000:ff00::/41 2402:f000:ff80::/42 2402:f000:ffc0::/43 2402:f000:ffe0::/44 2402:f000:fff0::/45 2402:f000:fff8::/46 2402:f000:fffc::/47 2402:f000:fffe::/48 2402:f000:ffff::/49 2402:f000:ffff:8000::/49 2403:600::/32 2403:700::/32 2403:800::/31 2403:f00::/32 2403:2a00::/32 2403:4300::/32 2403:6a00::/32 2403:7700::/32 2403:7b00::/32 2403:8900::/32 2403:8b00::/32 2403:8c00::/32 2403:8d00::/32 2403:9b00::/32 2403:9d00::/32 2403:a100::/32 2403:a200::/32 2403:a300::/32 2403:ac00::/48 2403:ac00:1::/48 2403:ac00:2::/49 2403:ac00:2:8000::/49 2403:ac00:3::/48 2403:ac00:4::/46 2403:ac00:8::/45 2403:ac00:10::/44 2403:ac00:20::/43 2403:ac00:40::/42 2403:ac00:80::/41 2403:ac00:100::/40 2403:ac00:200::/39 2403:ac00:400::/38 2403:ac00:800::/37 2403:ac00:1000::/36 2403:ac00:2000::/35 2403:ac00:4000::/34 2403:ac00:8000::/33 2403:b400::/32 2403:c100::/32 2403:d400::/36 2403:d400:1000::/49 2403:d400:1000:8000::/49 2403:d400:1001::/48 2403:d400:1002::/47 2403:d400:1004::/46 2403:d400:1008::/45 2403:d400:1010::/44 2403:d400:1020::/43 2403:d400:1040::/42 2403:d400:1080::/41 2403:d400:1100::/40 2403:d400:1200::/39 2403:d400:1400::/38 2403:d400:1800::/37 2403:d400:2000::/35 2403:d400:4000::/34 2403:d400:8000::/33 2403:db00::/32 2403:e300::/32 2403:e500::/32 2403:e700::/32 2403:ed00::/32 2403:f100::/32 2403:f300::/32 2403:f800::/32 2403:f900::/32 2403:fb00::/32 2404:100::/32 2404:158::/32 2404:f00::/32 2404:3300::/32 2404:3700::/32 2404:3b00::/32 2404:4d00::/32 2404:5b00::/32 2404:5d00::/32 2404:6000::/32 2404:6100::/32 2404:6500::/32 2404:6700::/32 2404:7100::/32 2404:7600::/32 2404:7d00::/32 2404:8700::/32 2404:8b00::/32 2404:a000::/32 2404:b100::/32 2404:b900::/32 2404:c300::/32 2404:cd00::/32 2404:df00::/32 2405:3b00::/32 2405:5b00::/32 2405:6200::/32 2405:6f00::/32 2405:9300::/32 2405:9700::/32 2405:9900::/32 2405:9b00::/32 2405:9e00::/32 2405:a500::/32 2405:a900::/32 2405:ab00::/32 2405:ad00::/32 2405:af00::/32 2405:b100::/32 2405:b300::/32 2405:bb00::/32 2405:bd00::/32 2405:bf00::/32 2405:c500::/32 2405:d700::/32 2405:d900::/32 2405:e000::/32 2405:e600::/32 2406:1100::/32 2406:2700::/32 2406:3300::/32 2406:3700::/32 2406:4500::/32 2406:4d00::/32 2406:4f00::/32 2406:6100::/32 2406:6300::/32 2406:6500::/32 2406:7d00::/32 2406:8500::/32 2406:9200::/32 2406:c900::/32 2406:cf00::/32 2406:dc00::/32 2406:dd00::/32 2406:e500::/32 2406:f300::/32 2406:ff00::/32 2407:1900::/32 2407:1d00::/32 2407:3700::/32 2407:3900::/32 2407:4f00::/32 2407:5500::/32 2407:7d00::/32 2407:9f00::/32 2407:ba00::/32 2407:bc00::/32 2407:c400::/32 2407:c900::/32 2407:cf00::/32 2407:e800::/32 2408:8000::/27 2408:8020::/29 2408:8028::/31 2408:802a::/33 2408:802a:8000::/38 2408:802a:8400::/39 2408:802a:8600::/40 2408:802a:8700::/48 2408:802a:8701::/49 2408:802a:8701:8000::/49 2408:802a:8702::/49 2408:802a:8702:8000::/49 2408:802a:8703::/49 2408:802a:8703:8000::/49 2408:802a:8704::/47 2408:802a:8706::/49 2408:802a:8706:8000::/49 2408:802a:8707::/48 2408:802a:8708::/48 2408:802a:8709::/49 2408:802a:8709:8000::/49 2408:802a:870a::/48 2408:802a:870b::/49 2408:802a:870b:8000::/49 2408:802a:870c::/46 2408:802a:8710::/44 2408:802a:8720::/43 2408:802a:8740::/42 2408:802a:8780::/41 2408:802a:8800::/37 2408:802a:9000::/38 2408:802a:9400::/39 2408:802a:9600::/40 2408:802a:9700::/47 2408:802a:9702::/49 2408:802a:9702:8000::/49 2408:802a:9703::/48 2408:802a:9704::/48 2408:802a:9705::/49 2408:802a:9705:8000::/49 2408:802a:9706::/47 2408:802a:9708::/45 2408:802a:9710::/44 2408:802a:9720::/43 2408:802a:9740::/42 2408:802a:9780::/41 2408:802a:9800::/38 2408:802a:9c00::/39 2408:802a:9e00::/40 2408:802a:9f00::/46 2408:802a:9f04::/47 2408:802a:9f06::/49 2408:802a:9f06:8000::/49 2408:802a:9f07::/48 2408:802a:9f08::/45 2408:802a:9f10::/44 2408:802a:9f20::/43 2408:802a:9f40::/42 2408:802a:9f80::/41 2408:802a:a000::/35 2408:802a:c000::/34 2408:802b::/32 2408:802c::/30 2408:8030::/31 2408:8032::/32 2408:8033::/33 2408:8033:8000::/46 2408:8033:8004::/49 2408:8033:8004:8000::/49 2408:8033:8005::/48 2408:8033:8006::/48 2408:8033:8007::/49 2408:8033:8007:8000::/49 2408:8033:8008::/46 2408:8033:800c::/47 2408:8033:800e::/48 2408:8033:800f::/49 2408:8033:800f:8000::/49 2408:8033:8010::/45 2408:8033:8018::/49 2408:8033:8018:8000::/49 2408:8033:8019::/48 2408:8033:801a::/47 2408:8033:801c::/46 2408:8033:8020::/43 2408:8033:8040::/46 2408:8033:8044::/48 2408:8033:8045::/49 2408:8033:8045:8000::/49 2408:8033:8046::/48 2408:8033:8047::/49 2408:8033:8047:8000::/49 2408:8033:8048::/47 2408:8033:804a::/48 2408:8033:804b::/49 2408:8033:804b:8000::/49 2408:8033:804c::/47 2408:8033:804e::/48 2408:8033:804f::/48 2408:8033:8050::/49 2408:8033:8050:8000::/49 2408:8033:8051::/49 2408:8033:8051:8000::/49 2408:8033:8052::/49 2408:8033:8052:8000::/49 2408:8033:8053::/48 2408:8033:8054::/48 2408:8033:8055::/48 2408:8033:8056::/47 2408:8033:8058::/45 2408:8033:8060::/43 2408:8033:8080::/41 2408:8033:8100::/40 2408:8033:8200::/39 2408:8033:8400::/38 2408:8033:8800::/37 2408:8033:9000::/36 2408:8033:a000::/35 2408:8033:c000::/34 2408:8034::/30 2408:8038::/29 2408:8040::/28 2408:8050::/30 2408:8054::/31 2408:8056::/48 2408:8056:1::/49 2408:8056:1:8000::/49 2408:8056:2::/47 2408:8056:4::/46 2408:8056:8::/45 2408:8056:10::/44 2408:8056:20::/44 2408:8056:30::/49 2408:8056:30:8000::/49 2408:8056:31::/48 2408:8056:32::/47 2408:8056:34::/46 2408:8056:38::/45 2408:8056:40::/42 2408:8056:80::/41 2408:8056:100::/40 2408:8056:200::/39 2408:8056:400::/38 2408:8056:800::/37 2408:8056:1000::/36 2408:8056:2000::/35 2408:8056:4000::/34 2408:8056:8000::/33 2408:8057::/32 2408:8058::/29 2408:8060::/27 2408:8080::/25 2408:8100::/24 2408:8200::/23 2408:8400::/22 2408:8800::/21 2409:8000::/20 240a:8000::/21 240b:8000::/21 240c::/31 240c:2::/32 240c:3::/40 240c:3:100::/45 240c:3:108::/48 240c:3:109::/48 240c:3:10a::/47 240c:3:10c::/46 240c:3:110::/44 240c:3:120::/43 240c:3:140::/42 240c:3:180::/41 240c:3:200::/39 240c:3:400::/38 240c:3:800::/37 240c:3:1000::/36 240c:3:2000::/35 240c:3:4000::/34 240c:3:8000::/33 240c:4::/30 240c:8::/29 240c:8000::/21 240d:8000::/24 240e::/25 240e:80::/27 240e:a0::/30 240e:a4::/34 240e:a4:4000::/35 240e:a4:6000::/47 240e:a4:6002::/48 240e:a4:6003::/49 240e:a4:6003:8000::/49 240e:a4:6004::/46 240e:a4:6008::/45 240e:a4:6010::/44 240e:a4:6020::/43 240e:a4:6040::/42 240e:a4:6080::/41 240e:a4:6100::/40 240e:a4:6200::/39 240e:a4:6400::/38 240e:a4:6800::/37 240e:a4:7000::/36 240e:a4:8000::/33 240e:a5::/32 240e:a6::/31 240e:a8::/29 240e:b0::/29 240e:b8::/30 240e:bc::/33 240e:bc:8000::/34 240e:bc:c000::/45 240e:bc:c008::/46 240e:bc:c00c::/48 240e:bc:c00d::/49 240e:bc:c00d:8000::/49 240e:bc:c00e::/47 240e:bc:c010::/44 240e:bc:c020::/43 240e:bc:c040::/42 240e:bc:c080::/41 240e:bc:c100::/40 240e:bc:c200::/39 240e:bc:c400::/38 240e:bc:c800::/37 240e:bc:d000::/36 240e:bc:e000::/35 240e:bd::/32 240e:be::/31 240e:c0::/27 240e:e0::/29 240e:e8::/30 240e:ec::/39 240e:ec:200::/44 240e:ec:210::/48 240e:ec:211::/49 240e:ec:211:8000::/49 240e:ec:212::/47 240e:ec:214::/46 240e:ec:218::/45 240e:ec:220::/43 240e:ec:240::/42 240e:ec:280::/41 240e:ec:300::/40 240e:ec:400::/38 240e:ec:800::/37 240e:ec:1000::/36 240e:ec:2000::/35 240e:ec:4000::/35 240e:ec:6000::/38 240e:ec:6400::/40 240e:ec:6500::/41 240e:ec:6580::/42 240e:ec:65c0::/43 240e:ec:65e0::/48 240e:ec:65e1::/49 240e:ec:65e1:8000::/49 240e:ec:65e2::/47 240e:ec:65e4::/46 240e:ec:65e8::/45 240e:ec:65f0::/44 240e:ec:6600::/39 240e:ec:6800::/37 240e:ec:7000::/36 240e:ec:8000::/33 240e:ed::/32 240e:ee::/31 240e:f0::/29 240e:f8::/31 240e:fa::/48 240e:fa:1::/49 240e:fa:1:8000::/49 240e:fa:2::/47 240e:fa:4::/46 240e:fa:8::/45 240e:fa:10::/44 240e:fa:20::/43 240e:fa:40::/42 240e:fa:80::/41 240e:fa:100::/40 240e:fa:200::/39 240e:fa:400::/38 240e:fa:800::/37 240e:fa:1000::/36 240e:fa:2000::/35 240e:fa:4000::/34 240e:fa:8000::/33 240e:fb::/32 240e:fc::/30 240e:100::/24 240e:200::/23 240e:400::/22 240e:800::/21 240f:8000::/24 2620:0:dd0::/49 Colin > On 20 Jul 2015, at 19:18, Valdis.Kletnieks at vt.edu wrote: > > On Mon, 20 Jul 2015 19:04:27 +0100, Colin Johnston said: >> route block china range whole of and/or firewall block china range whole of > > Do you have an authoritative list of *all* IP blocks that end up routed into China? > > For bonus points, IPv6 blocks too. :) From rdobbins at arbor.net Mon Jul 20 18:49:54 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 20 Jul 2015 20:49:54 +0200 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <7e2983baf29e4e95801764be087687da@EXCHANGE2K13.thenap.com> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <52172AF8-7B37-4BBF-BBC5-9C71409E38A8@puck.nether.net> <7e2983baf29e4e95801764be087687da@EXCHANGE2K13.thenap.com> Message-ID: <4F61368C-1E46-4C02-BB53-1073F44F3955@arbor.net> On 20 Jul 2015, at 18:12, Drew Weaver wrote: > Ah, alright. I've seen the "general" amplification attacks > SNMP/DNS/NTP/you name it, plenty but this is the first one I've ever > seen one that targeted 1720/5060 and as its mitigated in one place it > keeps moving from dst to dst fairly rapidly until none of the dst ips > are available. What source ports and breadth of purported source IPs? I'm not sure this is reflection/amplification attack, it may be a straight packeting of H.323 systems. ----------------------------------- Roland Dobbins From Valdis.Kletnieks at vt.edu Mon Jul 20 18:57:18 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Jul 2015 14:57:18 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: Your message of "Mon, 20 Jul 2015 19:42:39 +0100." <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> Message-ID: <13446.1437418638@turing-police.cc.vt.edu> On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said: > see below for china ranges I believe, ipv4 and ipv6 You may believe... but are you *sure*? (Over the years, we've seen *lots* of "block China" lists that accidentally block chunks allocated to Taiwan or Australia or other Pacific Rim destinations). And remember - asking the NIC doesn't help, because there are almost certainly blocks allocated that the registration points to Korea or someplace, but the provider routes a sub-block to China. And let's not even get started on blocks allocated by ARIN or RIPE.... (Yes, it *was* a trick question :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From colinj at gt86car.org.uk Mon Jul 20 19:18:46 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 20 Jul 2015 20:18:46 +0100 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <13446.1437418638@turing-police.cc.vt.edu> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> Message-ID: <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> in war you take information at face value and use it if needed to mitigate risk, if there is legit traffic in blocked ranges then excemption procedure in place to unblock. colin Sent from my iPhone > On 20 Jul 2015, at 19:57, Valdis.Kletnieks at vt.edu wrote: > > On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said: >> see below for china ranges I believe, ipv4 and ipv6 > > You may believe... but are you *sure*? (Over the years, we've seen > *lots* of "block China" lists that accidentally block chunks allocated > to Taiwan or Australia or other Pacific Rim destinations). > > And remember - asking the NIC doesn't help, because there are almost > certainly blocks allocated that the registration points to Korea or > someplace, but the provider routes a sub-block to China. And let's > not even get started on blocks allocated by ARIN or RIPE.... > > (Yes, it *was* a trick question :) > From ml at kenweb.org Mon Jul 20 19:40:09 2015 From: ml at kenweb.org (ML) Date: Mon, 20 Jul 2015 15:40:09 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <13446.1437418638@turing-police.cc.vt.edu> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> Message-ID: <55AD4E99.5020605@kenweb.org> On 7/20/2015 2:57 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said: >> see below for china ranges I believe, ipv4 and ipv6 > You may believe... but are you *sure*? (Over the years, we've seen > *lots* of "block China" lists that accidentally block chunks allocated > to Taiwan or Australia or other Pacific Rim destinations). > If you really wanted to go the route of blocking all/almost all China. Isn't there a short list of ASNs that provide transit to China citizens/networks? I'm referring to AS4134, AS4837, etc Wouldn't blackholing any prefix with those ASNs in the AS path accomplish the goal and stay up to date with a new prefixes originated from China? From colinj at gt86car.org.uk Mon Jul 20 19:50:21 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 20 Jul 2015 20:50:21 +0100 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <55AD4E99.5020605@kenweb.org> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <55AD4E99.5020605@kenweb.org> Message-ID: <6528649C-95C9-4BCA-AB86-A5D21A21EAAE@gt86car.org.uk> new idea to free up network ranges for arin and ripe give a class c to china firewall, then put all the existing china ranges back in allocation pool and reallocate to new customers. anounce these new ranges with a higher pref than china ranges and then watch china start to cooperate at the nic level and abuse level colin Sent from my iPhone > On 20 Jul 2015, at 20:40, ML wrote: > >> On 7/20/2015 2:57 PM, Valdis.Kletnieks at vt.edu wrote: >> On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said: >>> see below for china ranges I believe, ipv4 and ipv6 >> You may believe... but are you *sure*? (Over the years, we've seen >> *lots* of "block China" lists that accidentally block chunks allocated >> to Taiwan or Australia or other Pacific Rim destinations). > > If you really wanted to go the route of blocking all/almost all China. Isn't there a short list of ASNs that provide transit to China citizens/networks? > I'm referring to AS4134, AS4837, etc > Wouldn't blackholing any prefix with those ASNs in the AS path accomplish the goal and stay up to date with a new prefixes originated from China? > From Valdis.Kletnieks at vt.edu Mon Jul 20 20:03:24 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Jul 2015 16:03:24 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: Your message of "Mon, 20 Jul 2015 15:40:09 -0400." <55AD4E99.5020605@kenweb.org> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <55AD4E99.5020605@kenweb.org> Message-ID: <18374.1437422604@turing-police.cc.vt.edu> On Mon, 20 Jul 2015 15:40:09 -0400, ML said: > If you really wanted to go the route of blocking all/almost all China. > Isn't there a short list of ASNs that provide transit to China > citizens/networks? > I'm referring to AS4134, AS4837, etc > Wouldn't blackholing any prefix with those ASNs in the AS path > accomplish the goal and stay up to date with a new prefixes originated > from China? What do you do if AS4134 has customers in Australia as well? And how do you even *tell* if they do or not, if the space hasn't been SWIP'ed or otherwise noted as customer space? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Mon Jul 20 20:04:37 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Jul 2015 16:04:37 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: Your message of "Mon, 20 Jul 2015 20:18:46 +0100." <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> Message-ID: <18523.1437422677@turing-police.cc.vt.edu> On Mon, 20 Jul 2015 20:18:46 +0100, Colin Johnston said: > in war you take information at face value and use it if needed to mitigate > risk, if there is legit traffic in blocked ranges then excemption procedure in > place to unblock. So how does Joe Aussie-Sixpack notify you that you goofed, when you've blocked his IP range? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From colinj at gt86car.org.uk Mon Jul 20 20:12:33 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 20 Jul 2015 21:12:33 +0100 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <18523.1437422677@turing-police.cc.vt.edu> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> Message-ID: > On 20 Jul 2015, at 21:04, Valdis.Kletnieks at vt.edu wrote: > > On Mon, 20 Jul 2015 20:18:46 +0100, Colin Johnston said: >> in war you take information at face value and use it if needed to mitigate >> risk, if there is legit traffic in blocked ranges then excemption procedure in >> place to unblock. > > So how does Joe Aussie-Sixpack notify you that you goofed, when you've > blocked his IP range? source user to use phone contact and or postal service to establish contact instead to build trust and then enable internet unblock depending on outcome. Sad fact it has come to this since engagement with China folks goes no where, always open to dialogue though to engage on this further. Colin From surfer at mauigateway.com Mon Jul 20 20:15:12 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 20 Jul 2015 13:15:12 -0700 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours Message-ID: <20150720131512.1DB7C433@m0048141.ppops.net> --- Valdis.Kletnieks at vt.edu wrote: On Mon, 20 Jul 2015 20:18:46 +0100, Colin Johnston said: > in war you take information at face value and use it > if needed to mitigate risk, if there is legit traffic > in blocked ranges then excemption procedure in place to > unblock. :: So how does Joe Aussie-Sixpack notify you that you :: goofed, when you've blocked his IP range? --------------------------------- He doesn't. This is war and us amuricans're gonna make them change their culture to fit our expectations, too. >;-) scott From Valdis.Kletnieks at vt.edu Mon Jul 20 20:20:01 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Jul 2015 16:20:01 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: Your message of "Mon, 20 Jul 2015 21:12:33 +0100." References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> Message-ID: <19770.1437423601@turing-police.cc.vt.edu> On Mon, 20 Jul 2015 21:12:33 +0100, Colin Johnston said: > source user to use phone contact and or postal service to establish contact And your phone and postal addresses are listed *where* that Joe Aussie-Sixpack is likely to be able to find? (Hint 1: If it's on your website, they can't find it.) (Hint 2: Mortal users have never heard of WHOIS or similar services) And what are the chances that after 3-4 days of unreachable, the user will simply conclude you've gone out of business and you've lost a customer/reader to a competitor? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From colinj at gt86car.org.uk Mon Jul 20 20:50:44 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 20 Jul 2015 21:50:44 +0100 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <19770.1437423601@turing-police.cc.vt.edu> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> Message-ID: <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> blocking to mitigate risk is a better trade off gaining better percentage legit traffic against a indventant minor valid good network range. Sent from my iPhone > On 20 Jul 2015, at 21:20, Valdis.Kletnieks at vt.edu wrote: > > On Mon, 20 Jul 2015 21:12:33 +0100, Colin Johnston said: >> source user to use phone contact and or postal service to establish contact > > And your phone and postal addresses are listed *where* that Joe Aussie-Sixpack > is likely to be able to find? > > (Hint 1: If it's on your website, they can't find it.) > > (Hint 2: Mortal users have never heard of WHOIS or similar services) > > And what are the chances that after 3-4 days of unreachable, the user will > simply conclude you've gone out of business and you've lost a customer/reader > to a competitor? From owen at delong.com Mon Jul 20 20:57:52 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jul 2015 13:57:52 -0700 Subject: SIP trunking providers In-Reply-To: References: <201507201321.t6KDLHx0007944@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B401C70ABA80@MUNPRDMBXA1.medline.com> Message-ID: <26DFD966-424D-4E33-93F5-04B07592D394@delong.com> FWIW, I don?t know where their root nodes are or where their proxies are located, but I?ve had excellent service from CallCentric for several years. They?ve just plain worked everywhere I?ve tried in first-world countries and generally fairly well even in places that were network challenged like Rwanda ~5 years ago, Haiti ~3 years ago, Suriname, Morocco ~6 years ago, etc. They?ve even worked pretty well from most of the hotel WiFi networks where I have attempted to use them. I given them $1.95 per month and something around a penny per minute on the rare occasion when I use the service. This gets me a DID number, as well as outgoing service with customized caller-ID mapping. Admittedly this is for a single-line rather than SIP trunking, but I believe they also offer trunking services. Owen > On Jul 20, 2015, at 08:21 , Rafael Possamai wrote: > > When I originally posted the thread, I had asked Chicago due to physical > proximity, and my assumption being the lesser the number of hops, the lower > the probability of running into issues (latency, jitter and congestion). On > the other hand, one of my sandboxes are out of Las Vegas and I haven't had > any issues yet, but the number of test calls I've ran aren't enough to say > with confidence that distance and hops don't matter (indirect ways of > measuring latency, etc). > > Another thing is, having your packets stay in Chicago and in Chicago only > is a nice thing, the efficiency of your overall system would be higher for > what it's worth, but as an example, the 2nd hop this e-mail is taking to > get delivered to Nanog is about 100 miles, who knows about the other ones. > > > > On Mon, Jul 20, 2015 at 8:49 AM, Naslund, Steve > wrote: > >> End to end delay is not the most limiting factor. Jitter is the issue and >> packet drops are the other issue that matters (more importantly the >> distribution of drops). I think the best reason to select the local >> provider over the distant one is that the sooner he gets off the IP network >> the less impairments he will run into. The TDM network as antiquated as it >> is, is less susceptible to congestion and call impairments than an IP >> backbone network is. I can tell you from running a bunch of International >> VOIP networks that they are just not as reliable as TDM. The average >> internet connection just does not meet the reliability standards that the >> TDM voice network has achieved. IP networks are affected by congestion and >> routing issues whereas the TDM network seldom has these type of problems. >> An outage on a TDM circuit rarely affects other TDM circuits so they see a >> lot less higher level outages. I can understand why he does not want to >> haul his voice cross country over IP when he is exiting locally most of the >> time. >> >> Yes, I understand that the carrier might very well be hauling that traffic >> via IP even after he gets to his gateway point but at that point it becomes >> their problem to deal with. >> >> Steven Naslund >> Chicago IL >> >> >>> If you?re going to the PSTN, who gives a shit where you do the >> interconnect as long as its within 100ms. >>> >>> If most of your calls are VOIP<->VOIP within Chicago, then it makes some >> sense to set up a box and just send the external calls out to the trunking >> provider where >you no longer really care where they are. >>> >>> Absent significant network suckage, there?s no place in the contiguous >> US that isn?t within 100 ms of any other place in the contiguous US these >> days. >>> >>> Owen >> >> From mikea at mikea.ath.cx Mon Jul 20 20:56:57 2015 From: mikea at mikea.ath.cx (mikea) Date: Mon, 20 Jul 2015 15:56:57 -0500 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> Message-ID: <20150720205657.GC34800@mikea.ath.cx> On Mon, Jul 20, 2015 at 09:50:44PM +0100, Colin Johnston wrote: > blocking to mitigate risk is a better trade off gaining better percentage > legit traffic against a indventant minor valid good network range. That may be your call, or your management's call, but that doesn't make it *my* call or my management's call. Reasonable people can disagree about this. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From tony at wicks.co.nz Mon Jul 20 21:31:15 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 21 Jul 2015 09:31:15 +1200 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <20150720131512.1DB7C433@m0048141.ppops.net> References: <20150720131512.1DB7C433@m0048141.ppops.net> Message-ID: <004501d0c333$686d0cf0$394726d0$@wicks.co.nz> > > :: So how does Joe Aussie-Sixpack notify you that you > :: goofed, when you've blocked his IP range? > --------------------------------- > > > He doesn't. This is war and us amuricans're gonna > make them change their culture to fit our expectations, > too. >;-) > Hahaha... Could not have said it better. But seriously as a new Zealand based engineer who has 20+ years in the internet industry the number of times I have had to deal with arrogant ******* who block ip ranges that affect my customers while thinking they are taking a swipe at China is a sad reflection on the attitude of some people. Then people wonder why the rest of the world does not trust the good old USA to run the Internet by itself. From owen at delong.com Mon Jul 20 21:33:41 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jul 2015 14:33:41 -0700 Subject: SIP trunking providers In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C70ABA80@MUNPRDMBXA1.medline.com> References: <201507201321.t6KDLHx0007944@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B401C70ABA80@MUNPRDMBXA1.medline.com> Message-ID: <188E7B5B-4D13-4D87-A544-436CC8AE1E6C@delong.com> The TDM network is rapidly being eliminated. The major telcos have been moving their backbones to VOIP and higher levels of oversubscription as a result for years now because of the very large cost savings that can be achieved. International TDM may still be pretty common, but domestic TDM is rapidly becoming as popular as a Strowger. Owen > On Jul 20, 2015, at 06:49 , Naslund, Steve wrote: > > End to end delay is not the most limiting factor. Jitter is the issue and packet drops are the other issue that matters (more importantly the distribution of drops). I think the best reason to select the local provider over the distant one is that the sooner he gets off the IP network the less impairments he will run into. The TDM network as antiquated as it is, is less susceptible to congestion and call impairments than an IP backbone network is. I can tell you from running a bunch of International VOIP networks that they are just not as reliable as TDM. The average internet connection just does not meet the reliability standards that the TDM voice network has achieved. IP networks are affected by congestion and routing issues whereas the TDM network seldom has these type of problems. An outage on a TDM circuit rarely affects other TDM circuits so they see a lot less higher level outages. I can understand why he does not want to haul his voice cross country over IP when he is exiting locally most of the time. > > Yes, I understand that the carrier might very well be hauling that traffic via IP even after he gets to his gateway point but at that point it becomes their problem to deal with. > > Steven Naslund > Chicago IL > > >> If you?re going to the PSTN, who gives a shit where you do the interconnect as long as its within 100ms. >> >> If most of your calls are VOIP<->VOIP within Chicago, then it makes some sense to set up a box and just send the external calls out to the trunking provider where >you no longer really care where they are. >> >> Absent significant network suckage, there?s no place in the contiguous US that isn?t within 100 ms of any other place in the contiguous US these days. >> >> Owen > From colinj at gt86car.org.uk Mon Jul 20 21:40:18 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 20 Jul 2015 22:40:18 +0100 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <004501d0c333$686d0cf0$394726d0$@wicks.co.nz> References: <20150720131512.1DB7C433@m0048141.ppops.net> <004501d0c333$686d0cf0$394726d0$@wicks.co.nz> Message-ID: a gentle talk to china folks from neighbours/asia associated areas might help to pursude china to do the right thing and tackle abuse and tackle direct network attacks. colin Sent from my iPhone On 20 Jul 2015, at 22:31, "Tony Wicks" wrote: >> >> :: So how does Joe Aussie-Sixpack notify you that you >> :: goofed, when you've blocked his IP range? >> --------------------------------- >> >> >> He doesn't. This is war and us amuricans're gonna >> make them change their culture to fit our expectations, >> too. >;-) > > Hahaha... Could not have said it better. But seriously as a new Zealand based engineer who has 20+ years in the internet industry the number of times I have had to deal with arrogant ******* who block ip ranges that affect my customers while thinking they are taking a swipe at China is a sad reflection on the attitude of some people. Then people wonder why the rest of the world does not trust the good old USA to run the Internet by itself. > From cb.list6 at gmail.com Mon Jul 20 21:40:27 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 20 Jul 2015 14:40:27 -0700 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> Message-ID: Folks, it may be time to take the next step and admit that UDP is too broken to support https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 Your comments have been requested On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver wrote: > Has anyone else seen a massive amount of illegitimate UDP 1720 traffic > coming from China being sent towards IP addresses which provide VoIP > services? > > I'm talking in the 20-30Gbps range? > > The first incident was yesterday at around 13:00 EST, the second incident > was today at 09:00 EST. > > I'm assuming this is just another DDoS like all others, but I would be > interested to hear if I am not the only one seeing this. > > On list or off-list is fine. > > Thanks, > -Drew > > From morrowc.lists at gmail.com Mon Jul 20 21:41:24 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 20 Jul 2015 17:41:24 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> Message-ID: On Mon, Jul 20, 2015 at 3:18 PM, Colin Johnston wrote: > in war you take information at face value and use it if needed to mitigate risk, if there is legit traffic in blocked ranges then excemption procedure in place to unblock. > it's not clear how blocking any list of addresse stops the 20-30gbps of packets from arriving at your doorstep, but if you feel you're doing the right thing for your network, I can only echo the words of another: "I encourage my competitors to do this" > colin > > Sent from my iPhone > >> On 20 Jul 2015, at 19:57, Valdis.Kletnieks at vt.edu wrote: >> >> On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said: >>> see below for china ranges I believe, ipv4 and ipv6 >> >> You may believe... but are you *sure*? (Over the years, we've seen >> *lots* of "block China" lists that accidentally block chunks allocated >> to Taiwan or Australia or other Pacific Rim destinations). >> >> And remember - asking the NIC doesn't help, because there are almost >> certainly blocks allocated that the registration points to Korea or >> someplace, but the provider routes a sub-block to China. And let's >> not even get started on blocks allocated by ARIN or RIPE.... >> >> (Yes, it *was* a trick question :) >> From morrowc.lists at gmail.com Mon Jul 20 21:44:47 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 20 Jul 2015 17:44:47 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <20150720131512.1DB7C433@m0048141.ppops.net> <004501d0c333$686d0cf0$394726d0$@wicks.co.nz> Message-ID: On Mon, Jul 20, 2015 at 5:40 PM, Colin Johnston wrote: > a gentle talk to china folks from neighbours/asia associated areas might help to pursude china to do the right thing and tackle abuse and tackle direct network attacks. it's confusing to me that you think china (the gov't or the ISPs) care a whit about what you think is going on? I suppose after ~15 yrs of this if you keep on doing it eventually they'll listen? the definition of crazy is... From cloos at jhcloos.com Mon Jul 20 21:50:45 2015 From: cloos at jhcloos.com (James Cloos) Date: Mon, 20 Jul 2015 17:50:45 -0400 Subject: SIP trunking providers In-Reply-To: <84998225.2803.1437336324378.JavaMail.mhammett@ThunderFuck> (Mike Hammett's message of "Sun, 19 Jul 2015 15:04:52 -0500 (CDT)") References: <84998225.2803.1437336324378.JavaMail.mhammett@ThunderFuck> Message-ID: >>>>> "MH" == Mike Hammett writes: MH> I too am looking for the Chicago area. Low volume. I'm looking for MH> people whose SIP and RTP hit the end of the road in Chicago. Not MH> interested in someone whose SIP servers are in LA , but will redirect MH> me to the nearest gateway... without telling me where said gateway is. I know that voip.ms has sip/rtp nodes in Chicago. I don't know what the next hop is (whether is is tdm or something like sip/rtp orver a dedicated ethernet to a clec or an ixc or what), but I find the latency minimal. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From jfbeam at gmail.com Mon Jul 20 21:59:59 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 20 Jul 2015 17:59:59 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <55AA2E57.6080303@dds.nl> References: <20150712212557.GG3716@bender.unx.cpp.edu> <55AA2E57.6080303@dds.nl> Message-ID: On Sat, 18 Jul 2015 06:45:43 -0400, Seth Mos wrote: > For now, all the customers with the Ubee in bridge mode are SOL. It's > not clear what the reason is, but Ubee in bridge mode with IPv6 is > listed on the road map. If that's intentional policy or that the > firmware isn't ready yet is not clear at this point. Even in bridge mode, it's router is still active (and consuming an address -- which TWC eventually "fixed" by upping the number of allowed devices by one.) In TWC-BC land, the customer has no access to the CPE, so we cannot see anything beyond the login screen. ("user" -- non-priv account -- can be accessed on some of them, which is how I know the router is still active, but I cannot do anything about it.) The Arris DG1670A is passing IPv6 through properly. (I'm told it is "known broken", but it's the *one* out of three that works.) The Arris CM820A -- used for their hotspot -- doesn't appear to work correctly; my (win7) laptop got a DHCP ::/128 but then couldn't get anywhere. (IPv4 worked fine) [For the record, TWC-BC hands out a /56 no matter what you ask for.] From jw at nuclearfallout.net Mon Jul 20 23:24:45 2015 From: jw at nuclearfallout.net (John Weekes) Date: Mon, 20 Jul 2015 16:24:45 -0700 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> Message-ID: <55AD833D.4060504@nuclearfallout.net> Ca, > Folks, it may be time to take the next step and admit that UDP is too > broken to support > > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > Your comments have been requested My comment would be that UDP is still widely used for game server traffic. This is unlikely to change in the near future because TCP (by default) is not well-suited for highly time-sensitive data, as even a small amount of packet loss causes significant delays. In light of this, it is a bad idea for network operators to apply overall rate-limits to UDP traffic right now. Rate-limiting specific UDP /ports/ that are frequently seen in reflection attacks -- such as 19, 123, and 1900 -- is a more reasonable practice, however, and it is becoming more common/. /UDP-based application protocols can be implemented correctly, such that they also have handshakes that limit their ability to be used for reflection attacks, and modern services (including modern game servers) do this. TCP and UDP can both be spoofed and used for direct attacks; we see this all the time. UDP is preferred due to many applications protocols' susceptibility to amplification attacks, but spoofed TCP attacks are often a bit thornier to deal with from the standpoint of a host attempting to externally mitigate, because tracking the three-way handshake requires keeping state. I spoke with Drew earlier and his attacks do not appear to be reflected, so this is orthogonal to his concern today. He is seeing directly-generated traffic, which could use any protocol. -John From cb.list6 at gmail.com Tue Jul 21 00:03:17 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 20 Jul 2015 17:03:17 -0700 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <55AD833D.4060504@nuclearfallout.net> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <55AD833D.4060504@nuclearfallout.net> Message-ID: On Monday, July 20, 2015, John Weekes wrote: > Ca, > > Folks, it may be time to take the next step and admit that UDP is too >> broken to support >> >> https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 >> >> Your comments have been requested >> > > My comment would be that UDP is still widely used for game server traffic. > This is unlikely to change in the near future because TCP (by default) is > not well-suited for highly time-sensitive data, as even a small amount of > packet loss causes significant delays. > > First, thanks for feedback. Opsec mailer in the ietf is a good place for detailed feedback. TCP packets travel at the same speed as udp. In fact nearly all video is delivered as tcp (youtube, netflix) Your level of tcp window pacing is relevant to your congestion algo. There is also sctp .... > In light of this, it is a bad idea for network operators to apply overall > rate-limits to UDP traffic right now. Rate-limiting specific UDP /ports/ > that are frequently seen in reflection attacks -- such as 19, 123, and 1900 > -- is a more reasonable practice, however, and it is becoming more common/. > > I noticed you did not include today's reported udp1720. Somebody took it on the chin because they did not rate limit that port. Tomorrow it will be a different port. Going back to the draft, it states that you should create a basline and understand it. > /UDP-based application protocols can be implemented correctly, such that > they also have handshakes that limit their ability to be used for > reflection attacks, and modern services (including modern game servers) do > this. > > Agreed. The issue is that there is so much broken ntp / chargen / ssdp .... That udp is a threat and "your udp app" will be collateral damage at some point (now, or in the future) > TCP and UDP can both be spoofed and used for direct attacks; we see this > all the time. UDP is preferred due to many applications protocols' > susceptibility to amplification attacks, but spoofed TCP attacks are often > a bit thornier to deal with from the standpoint of a host attempting to > externally mitigate, because tracking the three-way handshake requires > keeping state. > > What is the attack bandwidth volume ratio you see between tcp and udp? Mine is nearly 100% udp, but i have an eyeball network > I spoke with Drew earlier and his attacks do not appear to be reflected, > so this is orthogonal to his concern today. He is seeing directly-generated > traffic, which could use any protocol. > > -John > But it is udp, so it is not orthogonal and would hit the bitbucket on protocol level policer without anyone opening a ticket or getting pages. This draft is not trying to deperecate udp. It is simply illuminating a situation and a trend and providing advice. As a network operator, my concern is that protocols doing cool things like quic and webrtc will grow very quickly on udp and the signal will mix with ddos noise in such a way that i cannot tease them apart. Today, i rate limit udp with a sledge hammer just to keep the network up. If you say i have to rate limit with a scalpel, that probably wont work. CB From jmilko at gmail.com Mon Jul 20 19:45:24 2015 From: jmilko at gmail.com (James Milko) Date: Mon, 20 Jul 2015 15:45:24 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <55AD4E99.5020605@kenweb.org> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <55AD4E99.5020605@kenweb.org> Message-ID: On Mon, Jul 20, 2015 at 3:40 PM, ML wrote: > On 7/20/2015 2:57 PM, Valdis.Kletnieks at vt.edu wrote: > >> On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said: >> >>> see below for china ranges I believe, ipv4 and ipv6 >>> >> You may believe... but are you *sure*? (Over the years, we've seen >> *lots* of "block China" lists that accidentally block chunks allocated >> to Taiwan or Australia or other Pacific Rim destinations). >> >> > If you really wanted to go the route of blocking all/almost all China. > Isn't there a short list of ASNs that provide transit to China > citizens/networks? > I'm referring to AS4134, AS4837, etc > Wouldn't blackholing any prefix with those ASNs in the AS path accomplish > the goal and stay up to date with a new prefixes originated from China? > > That would prevent you from responding to their traffic (assuming DFZ), but their traffic would still have a valid route to your network. JM From jw at nuclearfallout.net Tue Jul 21 03:01:14 2015 From: jw at nuclearfallout.net (John) Date: Mon, 20 Jul 2015 20:01:14 -0700 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <55AD833D.4060504@nuclearfallout.net> Message-ID: <55ADB5FA.9060409@nuclearfallout.net> > TCP packets travel at the same speed as udp. I will go into more detail. TCP is designed to be a reliable protocol. When a packet is lost, TCP reduces the transfer rate and retransmits the packet. If enough packets are lost, the connection is reset entirely. This is not desirable with a video game, where game state is being constantly refreshed already; retransmissions are redundant, and the developer wants to control when the connection is considered unsalvageable. There are also other factors. A game developer could go into more detail with you on this (I am not involved with such decisions), but the simple fact is that UDP is used almost exclusively with fast-action video games. That definitely won't change for already-released games and it's unlikely to change in the near future for new games. > Your level of tcp window pacing is relevant to your congestion algo. > There is also sctp .... Yes, but the game developers want to control the way that congestion is handled, without trying to turn global knobs in the OS that may not even be exposed. > I noticed you did not include today's reported udp1720. UDP port 1720 was the destination port here, not the source port. As I understand it, the attack did not involve reflection and this is not a common target. His problem was mostly that a botnet was sending him attack traffic, not that it was using a specific protocol or port (those are just variables that the attacker could adjust -- and botnet users certainly will adjust to TCP if UDP starts seeing more rate-limiting). Blocking a destination service port like this would be akin to blocking TCP port 80 in response to an attack that involves spoofed TCP SYN traffic to port 80. That might be appropriate in some circumstances, such as if the victim is not a webserver, but it's not generally a good idea to limit it globally, and it's even less of a good idea to limit TCP overall. > Somebody took it on the chin because they did not rate limit that > port. Tomorrow it will be a different port. It is not the case that high-amplification-factor UDP services are discovered on a daily basis -- or anything close to that. > What is the attack bandwidth volume ratio you see between tcp and > udp? Mine is nearly 100% udp, but i have an eyeball network Attackers usually turn to UDP first, and if they use a spoofing traffic source, the preferred vector will usually be amplification using one of the big three -- NTP, DNS, or SSDP. When this fails, they will often turn to TCP attacks, or application-specific attacks. Those with botnets often use TCP SYN or small UDP packets to start. My networks have a large component of game server traffic, so at least 75% of legitimate traffic that we see is also UDP. I would expect to see most attacks here also use UDP, just because attackers frequently choose the protocol vector to match the service. > But it is udp, so it is not orthogonal and would hit the bitbucket on > protocol level policer without anyone opening a ticket or getting pages. A policer would degrade any UDP application and he'd probably have even more trouble tickets from customers than he would from just immediately null-routing the target IP addresses. Such tickets would could be a bit more complicated to troubleshoot, as staff and customers may not expect a UDP rate-limit to be the cause. My main point is that an overall UDP rate-limit is not a good idea for most networks -- and certainly not eyeball networks -- and we don't want to encourage it. Rate-limits (or other rules) on specific ports that are used in amplification attacks, however, might make a lot of sense, depending on the network. Potentially, an overall UDP rate-limit on individual users might also make sense (if those users are known to not need to use UDP). > This draft is not trying to deperecate udp. It is simply illuminating > a situation and a trend and providing advice. As a network operator, > my concern is that protocols doing cool things like quic and webrtc > will grow very quickly on udp and the signal will mix with ddos noise > in such a way that i cannot tease them apart. My concerns with this document, and the sentiment behind it, are primarily twofold. 1. Network operators may see it and think that an overall network-wide rate-limit UDP is a good idea, when there are much smarter mitigation options available. 2. Developers may read the document, consider UDP deprecated, and start to redevelop their libraries to use other protocols that may not be the right fit or might have a higher cost to develop. This unnecessarily burdens them. Right now, I haven't heard a lot of organizations tell me that they're rate-limiting UDP overall, thankfully. I really don't want it to start, and I hate to think that this sort of exposure might encourage that decision to be made more widely. Network operators reading this, please don't blanket rate-limit UDP across your network! > Today, i rate limit udp with a sledge hammer just to keep the network > up. If you say i have to rate limit with a scalpel, that probably wont > work. If you have an eyeball network that might have any gamers on it, you should consider switching to just a regular hammer, by limiting the major amplification vectors instead of UDP overall. At the very least, limit commonly-used reflection ports in an earlier rule, to pull out just the reflection traffic before resorting to the sledge. -John From itg at itechgeek.com Tue Jul 21 03:37:41 2015 From: itg at itechgeek.com (ITechGeek) Date: Mon, 20 Jul 2015 23:37:41 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <004501d0c333$686d0cf0$394726d0$@wicks.co.nz> References: <20150720131512.1DB7C433@m0048141.ppops.net> <004501d0c333$686d0cf0$394726d0$@wicks.co.nz> Message-ID: On Mon, Jul 20, 2015 at 5:31 PM, Tony Wicks wrote: > Hahaha... Could not have said it better. But seriously as a new Zealand > based engineer who has 20+ years in the internet industry the number of > times I have had to deal with arrogant ******* who block ip ranges that > affect my customers while thinking they are taking a swipe at China is a > sad reflection on the attitude of some people. Then people wonder why the > rest of the world does not trust the good old USA to run the Internet by > itself. And I thought it was because of the NSA. ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG at ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net From nathana at fsr.com Tue Jul 21 04:45:01 2015 From: nathana at fsr.com (Nathan Anderson) Date: Mon, 20 Jul 2015 21:45:01 -0700 Subject: SIP trunking providers In-Reply-To: <1212444734.2959.1437388624829.JavaMail.mhammett@ThunderFuck> References: , <1212444734.2959.1437388624829.JavaMail.mhammett@ThunderFuck> Message-ID: Okay, sure. But I think we might be talking past each other here. My whole response was predicated on the assumption that the media gateway that a given term call is sent to is picked based on its geographic proximity to either the ratecenter/CO or tandem of the callee. It doesn't really make sense for a provider to do anything otherwise, AFAICT, so I doubt that they would. If my assumption is correct, you gain no advantage by having your long-distance term calls go through a Chicago MG (which was my original argument to begin with), and any local Chicago calls would be sent to a local Chicago MG anyway, so you're sweating bullets over nothing. And, like you said, origination for your end users would be hitting a Chicago MG already. Soo...problem solved? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com ________________________________________ From: NANOG [nanog-bounces at nanog.org] On Behalf Of Mike Hammett [nanog at ics-il.net] Sent: Monday, July 20, 2015 3:36 AM To: nanog at nanog.org Subject: Re: SIP trunking providers I want the gateway in Chicago as well. I am Chicago based. The end users are Chicago based. Therefore the origination would be coming from a Chicago area gateway. Half of the calls (inbound would be guaranteed to be local as they'd be coming in through a local tandem anyway. Most of the termination traffic would again be to local numbers, therefore would again have to be through local tandems. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Nathan Anderson" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, July 20, 2015 4:11:37 AM Subject: RE: SIP trunking providers Maybe I'm missing something here, but what does it matter if the RTP from your perspective ends in Chicago or not? If it does end in Chicago, that only means they are proxying the audio before sending it on to the actual media gateway for that call where it finally drops onto the PSTN. So all that happens is that the audio latency remains the same (or worse, because of the additional, unnecessary proxy) AND that the actual media gateway remains hidden from you. You won't be able to actually test and see the latency to the MG, and you will be under the (false) impression that latency across all calls is equally "good" because you are only measuring RTT to a specific and common media proxy. By sending the audio directly to an MG closer to the point of exit from IP-land, it is taking a more direct route to the callee than you are seemingly asking for. If you're not talking about adding a proxy to the equation, are you expecting to find a provider in Chicago that immediately goes from IP to PSTN within Chicago, regardless of the actual destination of the call? Circuit-switched TDM is not a no-latency connection. Physics is involved here. The farther apart the caller is from the callee, the more latency there will be, regardless of the medium. All other things being equal (similar network path, etc.), I doubt IP packet switching significantly increases the latency over and above TDM call trunking. But I'm not an expert, and again, if I'm missing something here, I would love to be proven wrong. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com ________________________________________ From: NANOG [nanog-bounces at nanog.org] On Behalf Of Mike Hammett [nanog at ics-il.net] Sent: Sunday, July 19, 2015 1:04 PM Cc: nanog at nanog.org Subject: Re: SIP trunking providers I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Rafael Possamai" To: nanog at nanog.org Sent: Friday, June 19, 2015 4:40:48 PM Subject: SIP trunking providers Would anyone in the list be able to recommend a SIP trunk provider in the Chicago area? Not a VoIP expert, so just looking for someone with previous experience. Thanks, Rafael From nathana at fsr.com Tue Jul 21 04:53:09 2015 From: nathana at fsr.com (Nathan Anderson) Date: Mon, 20 Jul 2015 21:53:09 -0700 Subject: SIP trunking providers In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C70ABA80@MUNPRDMBXA1.medline.com> References: <201507201321.t6KDLHx0007944@aurora.sol.net> , <9578293AE169674F9A048B2BC9A081B401C70ABA80@MUNPRDMBXA1.medline.com> Message-ID: Okay, fair enough. I guess I made the assumption somehow that Mike was concerned solely about latency, which if that's all he is concerned about, then the points you bring up would largely be strawmen. But I just re-read Mike's post, and he doesn't state his reasons for wanting the local gateway. It must have been Dovid's reply that planted the seed of the idea in my mind that Mike was primarily concerned about latency. -- Nathan ________________________________________ From: NANOG [nanog-bounces at nanog.org] On Behalf Of Naslund, Steve [SNaslund at medline.com] Sent: Monday, July 20, 2015 6:49 AM To: nanog at nanog.org Subject: RE: SIP trunking providers End to end delay is not the most limiting factor. Jitter is the issue and packet drops are the other issue that matters (more importantly the distribution of drops). I think the best reason to select the local provider over the distant one is that the sooner he gets off the IP network the less impairments he will run into. The TDM network as antiquated as it is, is less susceptible to congestion and call impairments than an IP backbone network is. I can tell you from running a bunch of International VOIP networks that they are just not as reliable as TDM. The average internet connection just does not meet the reliability standards that the TDM voice network has achieved. IP networks are affected by congestion and routing issues whereas the TDM network seldom has these type of problems. An outage on a TDM circuit rarely affects other TDM circuits so they see a lot less higher level outages. I can understand why he does not want to haul his voice cross country over IP when he is exiting locally most of the time. Yes, I understand that the carrier might very well be hauling that traffic via IP even after he gets to his gateway point but at that point it becomes their problem to deal with. Steven Naslund Chicago IL >If you?re going to the PSTN, who gives a shit where you do the interconnect as long as its within 100ms. > >If most of your calls are VOIP<->VOIP within Chicago, then it makes some sense to set up a box and just send the external calls out to the trunking provider where >you no longer really care where they are. > >Absent significant network suckage, there?s no place in the contiguous US that isn?t within 100 ms of any other place in the contiguous US these days. > >Owen From lists at internetpolicyagency.com Tue Jul 21 09:29:07 2015 From: lists at internetpolicyagency.com (Roland Perry) Date: Tue, 21 Jul 2015 10:29:07 +0100 Subject: Why we did Internet-in-a-box (was: Remember "Internet-In-A-Box"?) In-Reply-To: References: <55A59F42.1080205@satchell.net> Message-ID: In article , Brett Watson writes >> This goes back a number of years. There was a product that literally >>was a cardboard box that contained everything one needed to get started >>on the Internet. Just add a modem and a computer, and you were on your >>way. No fuss, no "learning curve?. > >MCI (way back, original MCI when I worked there) had MCI One that was >similar with bundled voice/internet/etc, may be what you?re thinking >of or not There were numerous Internet "in a box" type products available in the 1994-95 timeframe, based largely on the existing Compuserve "in a box". I was responsible for the first one to go on sale in the UK, through a large chain of electronics retailers. The ISP was UK-Online. The commercial reason for the packs was to put the product in front of as many potential customers as possible, and make it easy to buy. Cover-disks on magazines had quite a wide circulation but didn't fully address the financial issues because... ...the corresponding operational reason was to overcome the bootstrapping problem of how do you sign someone up for an account and take a pre-payment if they aren't already online? A cover-disk could solve the problem of pre-installing the software needed, which in those days was generally a paid-for 3rd-party Stack and some kind of bulk-licenced browser (eg Trumpet + Netscape); but involved giving users a certain period of 'free trial', unless you employed the somewhat clumsy option of having them call in with credit card details during the set-up process. What an "in-a-box" product achieved was the ability to get wider distribution, because the retailer was typically receiving a 30% margin on his sale and therefore happy to have it on his shelves, but the ISP was also getting the 70% [less manufacturing cost, obviously] in order to part-fund the first month's access and the licence on the software, after which the person is online and can subscribe fully if they wish to continue. Even back then, there was the secondary effect that having spammers sign up to your service using a succession of "free trial" cover disks wasn't something to be encouraged. How any of this is relevant to IPv6 "in-a-box" I will leave as an exercise for the reader. Although my own inclination is to say it's much more to do with grappling with legacy hardware and operating systems that don't (either happily or at all) support IPv6, than getting a reasonably recent PC/CPE configured automagically via an existing IPv4 connection. -- Roland Perry From jared at puck.Nether.net Tue Jul 21 11:16:53 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 21 Jul 2015 07:16:53 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> Message-ID: <20150721111653.GA21987@puck.nether.net> I'm reminded of the "the russians are hacking our water system" stories from a few years back, when it turned out the water system adminstrator was on vacation in russia. often traffic comes from unexpected locations. perhaps you should fail-closed with good business practices to open things up. perhaps you fail-open then mitigate risk by using a blocklist. my suggestion is that if you didn't live through the days of the bogon lists, which were later allocated to RIRs, a block list is likely not the right approach if you truly working on security posture. - Jared On Mon, Jul 20, 2015 at 09:50:44PM +0100, Colin Johnston wrote: > blocking to mitigate risk is a better trade off gaining better percentage legit traffic against a indventant minor valid good network range. > > > Sent from my iPhone > > > On 20 Jul 2015, at 21:20, Valdis.Kletnieks at vt.edu wrote: > > > > On Mon, 20 Jul 2015 21:12:33 +0100, Colin Johnston said: > >> source user to use phone contact and or postal service to establish contact > > > > And your phone and postal addresses are listed *where* that Joe Aussie-Sixpack > > is likely to be able to find? > > > > (Hint 1: If it's on your website, they can't find it.) > > > > (Hint 2: Mortal users have never heard of WHOIS or similar services) > > > > And what are the chances that after 3-4 days of unreachable, the user will > > simply conclude you've gone out of business and you've lost a customer/reader > > to a competitor? -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From pavel.odintsov at gmail.com Tue Jul 21 11:55:22 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 21 Jul 2015 14:55:22 +0300 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <20150721111653.GA21987@puck.nether.net> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> <20150721111653.GA21987@puck.nether.net> Message-ID: Hello, folks! Could anybody tun my toolkit https://github.com/FastVPSEestiOu/fastnetmon with collect_attack_pcap_dumps = on option agains this attack type? With pcap dump we could do detailed analyze and share all details with Community. On Tue, Jul 21, 2015 at 2:16 PM, Jared Mauch wrote: > > I'm reminded of the "the russians are hacking our water system" > stories from a few years back, when it turned out the water system > adminstrator was on vacation in russia. > > often traffic comes from unexpected locations. perhaps you > should fail-closed with good business practices to open things up. > perhaps you fail-open then mitigate risk by using a blocklist. > > my suggestion is that if you didn't live through the days > of the bogon lists, which were later allocated to RIRs, a block > list is likely not the right approach if you truly working on > security posture. > > - Jared > > On Mon, Jul 20, 2015 at 09:50:44PM +0100, Colin Johnston wrote: >> blocking to mitigate risk is a better trade off gaining better percentage legit traffic against a indventant minor valid good network range. >> >> >> Sent from my iPhone >> >> > On 20 Jul 2015, at 21:20, Valdis.Kletnieks at vt.edu wrote: >> > >> > On Mon, 20 Jul 2015 21:12:33 +0100, Colin Johnston said: >> >> source user to use phone contact and or postal service to establish contact >> > >> > And your phone and postal addresses are listed *where* that Joe Aussie-Sixpack >> > is likely to be able to find? >> > >> > (Hint 1: If it's on your website, they can't find it.) >> > >> > (Hint 2: Mortal users have never heard of WHOIS or similar services) >> > >> > And what are the chances that after 3-4 days of unreachable, the user will >> > simply conclude you've gone out of business and you've lost a customer/reader >> > to a competitor? > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. -- Sincerely yours, Pavel Odintsov From cmaurand at xyonet.com Tue Jul 21 12:06:33 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 21 Jul 2015 08:06:33 -0400 Subject: SIP trunking providers In-Reply-To: <188E7B5B-4D13-4D87-A544-436CC8AE1E6C@delong.com> References: <201507201321.t6KDLHx0007944@aurora.sol.net> <9578293AE169674F9A048B2BC9A081B401C70ABA80@MUNPRDMBXA1.medline.com> <188E7B5B-4D13-4D87-A544-436CC8AE1E6C@delong.com> Message-ID: <55AE35C9.10802@xyonet.com> That may be true of metro areas, but in rural USA there's plenty of TDM to go around. Telco's are still delivering broadband on ADSL and phone on TDM. Worse those trunked circuits are TDM over HDSL. In many rural areas, there's not even ADSL or cable and that's within 40 miles of a small city. --Curtis On 7/20/2015 5:33 PM, Owen DeLong wrote: > The TDM network is rapidly being eliminated. The major telcos have been moving their backbones to VOIP and higher levels of oversubscription as a result for years now because of the very large cost savings that can be achieved. > > International TDM may still be pretty common, but domestic TDM is rapidly becoming as popular as a Strowger. > > Owen > >> On Jul 20, 2015, at 06:49 , Naslund, Steve wrote: >> >> End to end delay is not the most limiting factor. Jitter is the issue and packet drops are the other issue that matters (more importantly the distribution of drops). I think the best reason to select the local provider over the distant one is that the sooner he gets off the IP network the less impairments he will run into. The TDM network as antiquated as it is, is less susceptible to congestion and call impairments than an IP backbone network is. I can tell you from running a bunch of International VOIP networks that they are just not as reliable as TDM. The average internet connection just does not meet the reliability standards that the TDM voice network has achieved. IP networks are affected by congestion and routing issues whereas the TDM network seldom has these type of problems. An outage on a TDM circuit rarely affects other TDM circuits so they see a lot less higher level outages. I can understand why he does not want to haul his voice cross country over IP when he is exiting locally most of the time. >> >> Yes, I understand that the carrier might very well be hauling that traffic via IP even after he gets to his gateway point but at that point it becomes their problem to deal with. >> >> Steven Naslund >> Chicago IL >> >> >>> If you?re going to the PSTN, who gives a shit where you do the interconnect as long as its within 100ms. >>> >>> If most of your calls are VOIP<->VOIP within Chicago, then it makes some sense to set up a box and just send the external calls out to the trunking provider where >you no longer really care where they are. >>> >>> Absent significant network suckage, there?s no place in the contiguous US that isn?t within 100 ms of any other place in the contiguous US these days. >>> >>> Owen -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From cmaurand at xyonet.com Tue Jul 21 12:09:56 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 21 Jul 2015 08:09:56 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> Message-ID: <55AE3694.1070301@xyonet.com> DNS is still largely UDP. --Curtis On 7/20/2015 5:40 PM, Ca By wrote: > Folks, it may be time to take the next step and admit that UDP is too > broken to support > > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > Your comments have been requested > > > > On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver wrote: > >> Has anyone else seen a massive amount of illegitimate UDP 1720 traffic >> coming from China being sent towards IP addresses which provide VoIP >> services? >> >> I'm talking in the 20-30Gbps range? >> >> The first incident was yesterday at around 13:00 EST, the second incident >> was today at 09:00 EST. >> >> I'm assuming this is just another DDoS like all others, but I would be >> interested to hear if I am not the only one seeing this. >> >> On list or off-list is fine. >> >> Thanks, >> -Drew >> >> -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From cmaurand at xyonet.com Tue Jul 21 12:13:48 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 21 Jul 2015 08:13:48 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> <55AA2E57.6080303@dds.nl> Message-ID: <55AE377C.3060903@xyonet.com> On 7/20/2015 5:59 PM, Ricky Beam wrote: > On Sat, 18 Jul 2015 06:45:43 -0400, Seth Mos wrote: >> For now, all the customers with the Ubee in bridge mode are SOL. It's >> not clear what the reason is, but Ubee in bridge mode with IPv6 is >> listed on the road map. If that's intentional policy or that the >> firmware isn't ready yet is not clear at this point. > > Even in bridge mode, it's router is still active (and consuming an > address -- which TWC eventually "fixed" by upping the number of > allowed devices by one.) In TWC-BC land, the customer has no access to > the CPE, so we cannot see anything beyond the login screen. > > ("user" -- non-priv account -- can be accessed on some of them, which > is how I know the router is still active, but I cannot do anything > about it.) > > The Arris DG1670A is passing IPv6 through properly. (I'm told it is > "known broken", but it's the *one* out of three that works.) The Arris > CM820A -- used for their hotspot -- doesn't appear to work correctly; > my (win7) laptop got a DHCP ::/128 but then couldn't get anywhere. > (IPv4 worked fine) > > [For the record, TWC-BC hands out a /56 no matter what you ask for.] At least in Maine where I am, TWC does allow you to bring your own modem as long as it's DOCSIS 3 compliant and there's lots of those from motorola, netgear and others. You're not stuck with the Ubee. -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From nanog at ics-il.net Tue Jul 21 12:41:03 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 21 Jul 2015 07:41:03 -0500 (CDT) Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <19770.1437423601@turing-police.cc.vt.edu> Message-ID: <495130064.3612.1437482450109.JavaMail.mhammett@ThunderFuck> Probably not that big of a deal. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Valdis Kletnieks" To: "Colin Johnston" Cc: nanog at nanog.org Sent: Monday, July 20, 2015 3:20:01 PM Subject: Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours On Mon, 20 Jul 2015 21:12:33 +0100, Colin Johnston said: > source user to use phone contact and or postal service to establish contact And your phone and postal addresses are listed *where* that Joe Aussie-Sixpack is likely to be able to find? (Hint 1: If it's on your website, they can't find it.) (Hint 2: Mortal users have never heard of WHOIS or similar services) And what are the chances that after 3-4 days of unreachable, the user will simply conclude you've gone out of business and you've lost a customer/reader to a competitor? From nanog at ics-il.net Tue Jul 21 12:43:04 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 21 Jul 2015 07:43:04 -0500 (CDT) Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: Message-ID: <1614049833.3617.1437482573053.JavaMail.mhammett@ThunderFuck> Call it China hacking us and you'll get more attention, right or wrong. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Christopher Morrow" To: "Colin Johnston" Cc: "" Sent: Monday, July 20, 2015 4:44:47 PM Subject: Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours On Mon, Jul 20, 2015 at 5:40 PM, Colin Johnston wrote: > a gentle talk to china folks from neighbours/asia associated areas might help to pursude china to do the right thing and tackle abuse and tackle direct network attacks. it's confusing to me that you think china (the gov't or the ISPs) care a whit about what you think is going on? I suppose after ~15 yrs of this if you keep on doing it eventually they'll listen? the definition of crazy is... From jared at puck.Nether.net Tue Jul 21 12:43:08 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 21 Jul 2015 08:43:08 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <55AE3694.1070301@xyonet.com> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <55AE3694.1070301@xyonet.com> Message-ID: <20150721124308.GB5337@puck.nether.net> On Tue, Jul 21, 2015 at 08:09:56AM -0400, Curtis Maurand wrote: > > DNS is still largely UDP. Water is also still wet :) - but you may not be doing 10% of your links as UDP/53. DNS can also use TCP as well, including sending more than one query in a pipelined fashion. The challenge that Cameron is trying to document here is when seeing large volumes of UDP it becomes necessary to do something to keep the network up. This response is frustrating for those of us who prefer to have a unfiltered e2e network but maintaining the network as up in the face of these adverse conditions is important. - Jared > > --Curtis > > On 7/20/2015 5:40 PM, Ca By wrote: > >Folks, it may be time to take the next step and admit that UDP is too > >broken to support > > > >https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > > >Your comments have been requested > > > > > > > >On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver wrote: > > > >>Has anyone else seen a massive amount of illegitimate UDP 1720 traffic > >>coming from China being sent towards IP addresses which provide VoIP > >>services? > >> > >>I'm talking in the 20-30Gbps range? > >> > >>The first incident was yesterday at around 13:00 EST, the second incident > >>was today at 09:00 EST. > >> > >>I'm assuming this is just another DDoS like all others, but I would be > >>interested to hear if I am not the only one seeing this. > >> > >>On list or off-list is fine. > >> > >>Thanks, > >>-Drew > >> > >> > > -- > Best Regards > Curtis Maurand > Principal > Xyonet Web Hosting > mailto:cmaurand at xyonet.com > http://www.xyonet.com -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From rafael at gav.ufsc.br Tue Jul 21 13:07:34 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 21 Jul 2015 08:07:34 -0500 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <20150721124308.GB5337@puck.nether.net> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <55AE3694.1070301@xyonet.com> <20150721124308.GB5337@puck.nether.net> Message-ID: Has anyone tried to implement real-time SQC in their network? You can calculate summary statistics and use math to determine if traffic is "normal" or if there's a chance it's garbage. You won't be able to notice one-off attacks, but anything that repeats enough times should pop up. Facebook uses similar technology to figure out what kind of useless news to display on your feed. In summary, instead of blocking an entire country, we should be able to analyze traffic as it comes, and determine a DDoS attack without human intervention. On Tue, Jul 21, 2015 at 7:43 AM, Jared Mauch wrote: > On Tue, Jul 21, 2015 at 08:09:56AM -0400, Curtis Maurand wrote: > > > > DNS is still largely UDP. > > Water is also still wet :) - but you may not be doing 10% of your > links as UDP/53. > > DNS can also use TCP as well, including sending more than one > query in a pipelined fashion. > > The challenge that Cameron is trying to document here > is when seeing large volumes of UDP it becomes necessary to do > something to keep the network up. This response is frustrating for those > of us who prefer to have a unfiltered e2e network but maintaining > the network as up in the face of these adverse conditions is important. > > - Jared > > > > > --Curtis > > > > On 7/20/2015 5:40 PM, Ca By wrote: > > >Folks, it may be time to take the next step and admit that UDP is too > > >broken to support > > > > > >https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > > > > >Your comments have been requested > > > > > > > > > > > >On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver > wrote: > > > > > >>Has anyone else seen a massive amount of illegitimate UDP 1720 traffic > > >>coming from China being sent towards IP addresses which provide VoIP > > >>services? > > >> > > >>I'm talking in the 20-30Gbps range? > > >> > > >>The first incident was yesterday at around 13:00 EST, the second > incident > > >>was today at 09:00 EST. > > >> > > >>I'm assuming this is just another DDoS like all others, but I would be > > >>interested to hear if I am not the only one seeing this. > > >> > > >>On list or off-list is fine. > > >> > > >>Thanks, > > >>-Drew > > >> > > >> > > > > -- > > Best Regards > > Curtis Maurand > > Principal > > Xyonet Web Hosting > > mailto:cmaurand at xyonet.com > > http://www.xyonet.com > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > From pavel.odintsov at gmail.com Tue Jul 21 13:11:52 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 21 Jul 2015 16:11:52 +0300 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <55AE3694.1070301@xyonet.com> <20150721124308.GB5337@puck.nether.net> Message-ID: You could do SQC with FastNetMon. We have per subnet / per host and per protocol counters. We are working on multi 100GE mode very well :) On Tue, Jul 21, 2015 at 4:07 PM, Rafael Possamai wrote: > Has anyone tried to implement real-time SQC in their network? You can > calculate summary statistics and use math to determine if traffic is > "normal" or if there's a chance it's garbage. You won't be able to notice > one-off attacks, but anything that repeats enough times should pop up. > Facebook uses similar technology to figure out what kind of useless news to > display on your feed. > > In summary, instead of blocking an entire country, we should be able to > analyze traffic as it comes, and determine a DDoS attack without human > intervention. > > On Tue, Jul 21, 2015 at 7:43 AM, Jared Mauch wrote: > >> On Tue, Jul 21, 2015 at 08:09:56AM -0400, Curtis Maurand wrote: >> > >> > DNS is still largely UDP. >> >> Water is also still wet :) - but you may not be doing 10% of your >> links as UDP/53. >> >> DNS can also use TCP as well, including sending more than one >> query in a pipelined fashion. >> >> The challenge that Cameron is trying to document here >> is when seeing large volumes of UDP it becomes necessary to do >> something to keep the network up. This response is frustrating for those >> of us who prefer to have a unfiltered e2e network but maintaining >> the network as up in the face of these adverse conditions is important. >> >> - Jared >> >> > >> > --Curtis >> > >> > On 7/20/2015 5:40 PM, Ca By wrote: >> > >Folks, it may be time to take the next step and admit that UDP is too >> > >broken to support >> > > >> > >https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 >> > > >> > >Your comments have been requested >> > > >> > > >> > > >> > >On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver >> wrote: >> > > >> > >>Has anyone else seen a massive amount of illegitimate UDP 1720 traffic >> > >>coming from China being sent towards IP addresses which provide VoIP >> > >>services? >> > >> >> > >>I'm talking in the 20-30Gbps range? >> > >> >> > >>The first incident was yesterday at around 13:00 EST, the second >> incident >> > >>was today at 09:00 EST. >> > >> >> > >>I'm assuming this is just another DDoS like all others, but I would be >> > >>interested to hear if I am not the only one seeing this. >> > >> >> > >>On list or off-list is fine. >> > >> >> > >>Thanks, >> > >>-Drew >> > >> >> > >> >> > >> > -- >> > Best Regards >> > Curtis Maurand >> > Principal >> > Xyonet Web Hosting >> > mailto:cmaurand at xyonet.com >> > http://www.xyonet.com >> >> -- >> Jared Mauch | pgp key available via finger from jared at puck.nether.net >> clue++; | http://puck.nether.net/~jared/ My statements are only >> mine. >> -- Sincerely yours, Pavel Odintsov From nanog at ics-il.net Tue Jul 21 13:22:08 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 21 Jul 2015 08:22:08 -0500 (CDT) Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: Message-ID: <998981571.3647.1437484912639.JavaMail.mhammett@ThunderFuck> "Facebook uses similar technology to figure out what kind of useless news to display on your feed." In this case, it'll be of no use whatsoever. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Rafael Possamai" To: "Jared Mauch" Cc: nanog at nanog.org Sent: Tuesday, July 21, 2015 8:07:34 AM Subject: Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours Has anyone tried to implement real-time SQC in their network? You can calculate summary statistics and use math to determine if traffic is "normal" or if there's a chance it's garbage. You won't be able to notice one-off attacks, but anything that repeats enough times should pop up. Facebook uses similar technology to figure out what kind of useless news to display on your feed. In summary, instead of blocking an entire country, we should be able to analyze traffic as it comes, and determine a DDoS attack without human intervention. On Tue, Jul 21, 2015 at 7:43 AM, Jared Mauch wrote: > On Tue, Jul 21, 2015 at 08:09:56AM -0400, Curtis Maurand wrote: > > > > DNS is still largely UDP. > > Water is also still wet :) - but you may not be doing 10% of your > links as UDP/53. > > DNS can also use TCP as well, including sending more than one > query in a pipelined fashion. > > The challenge that Cameron is trying to document here > is when seeing large volumes of UDP it becomes necessary to do > something to keep the network up. This response is frustrating for those > of us who prefer to have a unfiltered e2e network but maintaining > the network as up in the face of these adverse conditions is important. > > - Jared > > > > > --Curtis > > > > On 7/20/2015 5:40 PM, Ca By wrote: > > >Folks, it may be time to take the next step and admit that UDP is too > > >broken to support > > > > > >https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > > > > >Your comments have been requested > > > > > > > > > > > >On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver > wrote: > > > > > >>Has anyone else seen a massive amount of illegitimate UDP 1720 traffic > > >>coming from China being sent towards IP addresses which provide VoIP > > >>services? > > >> > > >>I'm talking in the 20-30Gbps range? > > >> > > >>The first incident was yesterday at around 13:00 EST, the second > incident > > >>was today at 09:00 EST. > > >> > > >>I'm assuming this is just another DDoS like all others, but I would be > > >>interested to hear if I am not the only one seeing this. > > >> > > >>On list or off-list is fine. > > >> > > >>Thanks, > > >>-Drew > > >> > > >> > > > > -- > > Best Regards > > Curtis Maurand > > Principal > > Xyonet Web Hosting > > mailto:cmaurand at xyonet.com > > http://www.xyonet.com > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > From jared at puck.Nether.net Tue Jul 21 13:36:03 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 21 Jul 2015 09:36:03 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <55AE3694.1070301@xyonet.com> <20150721124308.GB5337@puck.nether.net> Message-ID: <20150721133603.GA17096@puck.nether.net> On Tue, Jul 21, 2015 at 08:07:34AM -0500, Rafael Possamai wrote: > Has anyone tried to implement real-time SQC in their network? You can > calculate summary statistics and use math to determine if traffic is > "normal" or if there's a chance it's garbage. You won't be able to notice > one-off attacks, but anything that repeats enough times should pop up. > Facebook uses similar technology to figure out what kind of useless news to > display on your feed. > > In summary, instead of blocking an entire country, we should be able to > analyze traffic as it comes, and determine a DDoS attack without human > intervention. We profile the protocols on our network so understand what the level of UDP, ICMP, IPv6, etc are. It's easy to pick out spikes in the graphs that are related to attacks. Setting thresholds related to this to minimize impact for customers is important as it eliminates the garbage that networks carry and reduce the impact to sites that are under attack. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From rafael at gav.ufsc.br Tue Jul 21 14:47:48 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 21 Jul 2015 09:47:48 -0500 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <998981571.3647.1437484912639.JavaMail.mhammett@ThunderFuck> References: <998981571.3647.1437484912639.JavaMail.mhammett@ThunderFuck> Message-ID: Yeah, it hurts to see advanced analytics being used to sort the kitten videos you're most likely to watch, but somehow they make money off of it. On the other hand, their datacenter and new switching technologies are really interesting, so that's an opposite example where their corporate investments can benefit society in general. On Tue, Jul 21, 2015 at 8:22 AM, Mike Hammett wrote: > "Facebook uses similar technology to figure out what kind of useless news > to display on your feed." > > In this case, it'll be of no use whatsoever. ;-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Rafael Possamai" > To: "Jared Mauch" > Cc: nanog at nanog.org > Sent: Tuesday, July 21, 2015 8:07:34 AM > Subject: Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in > last 24 hours > > Has anyone tried to implement real-time SQC in their network? You can > calculate summary statistics and use math to determine if traffic is > "normal" or if there's a chance it's garbage. You won't be able to notice > one-off attacks, but anything that repeats enough times should pop up. > Facebook uses similar technology to figure out what kind of useless news to > display on your feed. > > In summary, instead of blocking an entire country, we should be able to > analyze traffic as it comes, and determine a DDoS attack without human > intervention. > > On Tue, Jul 21, 2015 at 7:43 AM, Jared Mauch > wrote: > > > On Tue, Jul 21, 2015 at 08:09:56AM -0400, Curtis Maurand wrote: > > > > > > DNS is still largely UDP. > > > > Water is also still wet :) - but you may not be doing 10% of your > > links as UDP/53. > > > > DNS can also use TCP as well, including sending more than one > > query in a pipelined fashion. > > > > The challenge that Cameron is trying to document here > > is when seeing large volumes of UDP it becomes necessary to do > > something to keep the network up. This response is frustrating for those > > of us who prefer to have a unfiltered e2e network but maintaining > > the network as up in the face of these adverse conditions is important. > > > > - Jared > > > > > > > > --Curtis > > > > > > On 7/20/2015 5:40 PM, Ca By wrote: > > > >Folks, it may be time to take the next step and admit that UDP is too > > > >broken to support > > > > > > > >https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > > > > > > >Your comments have been requested > > > > > > > > > > > > > > > >On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver > > wrote: > > > > > > > >>Has anyone else seen a massive amount of illegitimate UDP 1720 > traffic > > > >>coming from China being sent towards IP addresses which provide VoIP > > > >>services? > > > >> > > > >>I'm talking in the 20-30Gbps range? > > > >> > > > >>The first incident was yesterday at around 13:00 EST, the second > > incident > > > >>was today at 09:00 EST. > > > >> > > > >>I'm assuming this is just another DDoS like all others, but I would > be > > > >>interested to hear if I am not the only one seeing this. > > > >> > > > >>On list or off-list is fine. > > > >> > > > >>Thanks, > > > >>-Drew > > > >> > > > >> > > > > > > -- > > > Best Regards > > > Curtis Maurand > > > Principal > > > Xyonet Web Hosting > > > mailto:cmaurand at xyonet.com > > > http://www.xyonet.com > > > > -- > > Jared Mauch | pgp key available via finger from jared at puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My statements are only > > mine. > > > > From rafael at gav.ufsc.br Tue Jul 21 14:48:59 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 21 Jul 2015 09:48:59 -0500 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <55AE3694.1070301@xyonet.com> <20150721124308.GB5337@puck.nether.net> Message-ID: Pavel, what kind of resources does the analysis of a 100G circuit require? Or is it just counting packets? On Tue, Jul 21, 2015 at 8:11 AM, Pavel Odintsov wrote: > You could do SQC with FastNetMon. We have per subnet / per host and > per protocol counters. We are working on multi 100GE mode very well :) > > On Tue, Jul 21, 2015 at 4:07 PM, Rafael Possamai > wrote: > > Has anyone tried to implement real-time SQC in their network? You can > > calculate summary statistics and use math to determine if traffic is > > "normal" or if there's a chance it's garbage. You won't be able to notice > > one-off attacks, but anything that repeats enough times should pop up. > > Facebook uses similar technology to figure out what kind of useless news > to > > display on your feed. > > > > In summary, instead of blocking an entire country, we should be able to > > analyze traffic as it comes, and determine a DDoS attack without human > > intervention. > > > > On Tue, Jul 21, 2015 at 7:43 AM, Jared Mauch > wrote: > > > >> On Tue, Jul 21, 2015 at 08:09:56AM -0400, Curtis Maurand wrote: > >> > > >> > DNS is still largely UDP. > >> > >> Water is also still wet :) - but you may not be doing 10% of > your > >> links as UDP/53. > >> > >> DNS can also use TCP as well, including sending more than one > >> query in a pipelined fashion. > >> > >> The challenge that Cameron is trying to document here > >> is when seeing large volumes of UDP it becomes necessary to do > >> something to keep the network up. This response is frustrating for > those > >> of us who prefer to have a unfiltered e2e network but maintaining > >> the network as up in the face of these adverse conditions is important. > >> > >> - Jared > >> > >> > > >> > --Curtis > >> > > >> > On 7/20/2015 5:40 PM, Ca By wrote: > >> > >Folks, it may be time to take the next step and admit that UDP is > too > >> > >broken to support > >> > > > >> > >https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > >> > > > >> > >Your comments have been requested > >> > > > >> > > > >> > > > >> > >On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver > > >> wrote: > >> > > > >> > >>Has anyone else seen a massive amount of illegitimate UDP 1720 > traffic > >> > >>coming from China being sent towards IP addresses which provide VoIP > >> > >>services? > >> > >> > >> > >>I'm talking in the 20-30Gbps range? > >> > >> > >> > >>The first incident was yesterday at around 13:00 EST, the second > >> incident > >> > >>was today at 09:00 EST. > >> > >> > >> > >>I'm assuming this is just another DDoS like all others, but I would > be > >> > >>interested to hear if I am not the only one seeing this. > >> > >> > >> > >>On list or off-list is fine. > >> > >> > >> > >>Thanks, > >> > >>-Drew > >> > >> > >> > >> > >> > > >> > -- > >> > Best Regards > >> > Curtis Maurand > >> > Principal > >> > Xyonet Web Hosting > >> > mailto:cmaurand at xyonet.com > >> > http://www.xyonet.com > >> > >> -- > >> Jared Mauch | pgp key available via finger from jared at puck.nether.net > >> clue++; | http://puck.nether.net/~jared/ My statements are only > >> mine. > >> > > > > -- > Sincerely yours, Pavel Odintsov > From pavel.odintsov at gmail.com Tue Jul 21 14:51:36 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 21 Jul 2015 17:51:36 +0300 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <55AE3694.1070301@xyonet.com> <20150721124308.GB5337@puck.nether.net> Message-ID: Hello! There are few vendors which could offer 100GE capture solutions which could be used with FastNetMon. I could share vendor names off list if you are interested in it. Now we do only packet counting and compare it with fixed thresholds. But we are working on deep packet inspection of attacks. But pps/bps thresholds still useful in this case too. On Tue, Jul 21, 2015 at 5:48 PM, Rafael Possamai wrote: > Pavel, what kind of resources does the analysis of a 100G circuit require? > Or is it just counting packets? > > On Tue, Jul 21, 2015 at 8:11 AM, Pavel Odintsov > wrote: >> >> You could do SQC with FastNetMon. We have per subnet / per host and >> per protocol counters. We are working on multi 100GE mode very well :) >> >> On Tue, Jul 21, 2015 at 4:07 PM, Rafael Possamai >> wrote: >> > Has anyone tried to implement real-time SQC in their network? You can >> > calculate summary statistics and use math to determine if traffic is >> > "normal" or if there's a chance it's garbage. You won't be able to >> > notice >> > one-off attacks, but anything that repeats enough times should pop up. >> > Facebook uses similar technology to figure out what kind of useless news >> > to >> > display on your feed. >> > >> > In summary, instead of blocking an entire country, we should be able to >> > analyze traffic as it comes, and determine a DDoS attack without human >> > intervention. >> > >> > On Tue, Jul 21, 2015 at 7:43 AM, Jared Mauch >> > wrote: >> > >> >> On Tue, Jul 21, 2015 at 08:09:56AM -0400, Curtis Maurand wrote: >> >> > >> >> > DNS is still largely UDP. >> >> >> >> Water is also still wet :) - but you may not be doing 10% of >> >> your >> >> links as UDP/53. >> >> >> >> DNS can also use TCP as well, including sending more than one >> >> query in a pipelined fashion. >> >> >> >> The challenge that Cameron is trying to document here >> >> is when seeing large volumes of UDP it becomes necessary to do >> >> something to keep the network up. This response is frustrating for >> >> those >> >> of us who prefer to have a unfiltered e2e network but maintaining >> >> the network as up in the face of these adverse conditions is important. >> >> >> >> - Jared >> >> >> >> > >> >> > --Curtis >> >> > >> >> > On 7/20/2015 5:40 PM, Ca By wrote: >> >> > >Folks, it may be time to take the next step and admit that UDP is >> >> > > too >> >> > >broken to support >> >> > > >> >> > >https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 >> >> > > >> >> > >Your comments have been requested >> >> > > >> >> > > >> >> > > >> >> > >On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver >> >> > > >> >> wrote: >> >> > > >> >> > >>Has anyone else seen a massive amount of illegitimate UDP 1720 >> >> > >> traffic >> >> > >>coming from China being sent towards IP addresses which provide >> >> > >> VoIP >> >> > >>services? >> >> > >> >> >> > >>I'm talking in the 20-30Gbps range? >> >> > >> >> >> > >>The first incident was yesterday at around 13:00 EST, the second >> >> incident >> >> > >>was today at 09:00 EST. >> >> > >> >> >> > >>I'm assuming this is just another DDoS like all others, but I would >> >> > >> be >> >> > >>interested to hear if I am not the only one seeing this. >> >> > >> >> >> > >>On list or off-list is fine. >> >> > >> >> >> > >>Thanks, >> >> > >>-Drew >> >> > >> >> >> > >> >> >> > >> >> > -- >> >> > Best Regards >> >> > Curtis Maurand >> >> > Principal >> >> > Xyonet Web Hosting >> >> > mailto:cmaurand at xyonet.com >> >> > http://www.xyonet.com >> >> >> >> -- >> >> Jared Mauch | pgp key available via finger from jared at puck.nether.net >> >> clue++; | http://puck.nether.net/~jared/ My statements are only >> >> mine. >> >> >> >> >> >> -- >> Sincerely yours, Pavel Odintsov > > -- Sincerely yours, Pavel Odintsov From owen at delong.com Tue Jul 21 15:31:56 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Jul 2015 08:31:56 -0700 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <55AE377C.3060903@xyonet.com> References: <20150712212557.GG3716@bender.unx.cpp.edu> <55AA2E57.6080303@dds.nl> <55AE377C.3060903@xyonet.com> Message-ID: <82B113E3-ECA2-4B91-9CB6-53E9CFBD9074@delong.com> Furst rule of dealing with $CABLECO ? If you don?t like the answer you get on this phone call, redial. The next person will probably give you a different answer. Certainly you can almost always get the answer you are looking for (even if it?s wrong) within 5 calls if you are that patient. Owen > On Jul 21, 2015, at 05:13 , Curtis Maurand wrote: > > > > On 7/20/2015 5:59 PM, Ricky Beam wrote: >> On Sat, 18 Jul 2015 06:45:43 -0400, Seth Mos wrote: >>> For now, all the customers with the Ubee in bridge mode are SOL. It's not clear what the reason is, but Ubee in bridge mode with IPv6 is listed on the road map. If that's intentional policy or that the firmware isn't ready yet is not clear at this point. >> >> Even in bridge mode, it's router is still active (and consuming an address -- which TWC eventually "fixed" by upping the number of allowed devices by one.) In TWC-BC land, the customer has no access to the CPE, so we cannot see anything beyond the login screen. >> >> ("user" -- non-priv account -- can be accessed on some of them, which is how I know the router is still active, but I cannot do anything about it.) >> >> The Arris DG1670A is passing IPv6 through properly. (I'm told it is "known broken", but it's the *one* out of three that works.) The Arris CM820A -- used for their hotspot -- doesn't appear to work correctly; my (win7) laptop got a DHCP ::/128 but then couldn't get anywhere. (IPv4 worked fine) >> >> [For the record, TWC-BC hands out a /56 no matter what you ask for.] > > At least in Maine where I am, TWC does allow you to bring your own modem as long as it's DOCSIS 3 compliant and there's lots of those from motorola, netgear and others. You're not stuck with the Ubee. > > -- > Best Regards > Curtis Maurand > Principal Xyonet Web Hosting > mailto:cmaurand at xyonet.com > http://www.xyonet.com From cmaurand at xyonet.com Tue Jul 21 16:33:16 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 21 Jul 2015 12:33:16 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <20150721124308.GB5337@puck.nether.net> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <55AE3694.1070301@xyonet.com> <20150721124308.GB5337@puck.nether.net> Message-ID: <55AE744C.2070404@xyonet.com> On 7/21/2015 8:43 AM, Jared Mauch wrote: > On Tue, Jul 21, 2015 at 08:09:56AM -0400, Curtis Maurand wrote: >> DNS is still largely UDP. > Water is also still wet :) - but you may not be doing 10% of your > links as UDP/53. > > DNS can also use TCP as well, including sending more than one > query in a pipelined fashion. > > The challenge that Cameron is trying to document here > is when seeing large volumes of UDP it becomes necessary to do > something to keep the network up. This response is frustrating for those > of us who prefer to have a unfiltered e2e network but maintaining > the network as up in the face of these adverse conditions is important. > > - Jared Point well taken. -Curtis >> --Curtis >> >> On 7/20/2015 5:40 PM, Ca By wrote: >>> Folks, it may be time to take the next step and admit that UDP is too >>> broken to support >>> >>> https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 >>> >>> Your comments have been requested >>> >>> >>> >>> On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver wrote: >>> >>>> Has anyone else seen a massive amount of illegitimate UDP 1720 traffic >>>> coming from China being sent towards IP addresses which provide VoIP >>>> services? >>>> >>>> I'm talking in the 20-30Gbps range? >>>> >>>> The first incident was yesterday at around 13:00 EST, the second incident >>>> was today at 09:00 EST. >>>> >>>> I'm assuming this is just another DDoS like all others, but I would be >>>> interested to hear if I am not the only one seeing this. >>>> >>>> On list or off-list is fine. >>>> >>>> Thanks, >>>> -Drew >>>> >>>> >> -- >> Best Regards >> Curtis Maurand >> Principal >> Xyonet Web Hosting >> mailto:cmaurand at xyonet.com >> http://www.xyonet.com -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From jfbeam at gmail.com Tue Jul 21 20:05:06 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 21 Jul 2015 16:05:06 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: <55AE377C.3060903@xyonet.com> References: <20150712212557.GG3716@bender.unx.cpp.edu> <55AA2E57.6080303@dds.nl> <55AE377C.3060903@xyonet.com> Message-ID: On Tue, 21 Jul 2015 08:13:48 -0400, Curtis Maurand wrote: > At least in Maine where I am, TWC does allow you to bring your own modem > as long as it's DOCSIS 3 compliant and there's lots of those from > motorola, netgear and others. You're not stuck with the Ubee. You are ignoring the "BUSINESS CLASS" part of the equation. TWC-BC provides the modem for you; you have little (arris) or no (ubee) access to it. From johnstong at westmancom.com Tue Jul 21 20:57:19 2015 From: johnstong at westmancom.com (Graham Johnston) Date: Tue, 21 Jul 2015 20:57:19 +0000 Subject: FIB Sizing Message-ID: <49EE1A35457387418410F97564A3752B013686BC6F@MSG6.westman.int> Does anybody have a working projection, or crystal ball, that can provide a recommendation on FIB size requirements for the next 24 months? Are we expecting the IPv4 table to continue to grow at somewhere around 50k routes a year? I came up with this from eyeballing the graph at http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active.txt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From cmaurand at xyonet.com Wed Jul 22 03:16:12 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 21 Jul 2015 23:16:12 -0400 Subject: another tilt at the Verizon FIOS IPv6 windmill In-Reply-To: References: <20150712212557.GG3716@bender.unx.cpp.edu> <55AA2E57.6080303@dds.nl> <55AE377C.3060903@xyonet.com> Message-ID: <55AF0AFC.9030508@xyonet.com> On 7/21/2015 4:05 PM, Ricky Beam wrote: > On Tue, 21 Jul 2015 08:13:48 -0400, Curtis Maurand > wrote: >> At least in Maine where I am, TWC does allow you to bring your own >> modem as long as it's DOCSIS 3 compliant and there's lots of those >> from motorola, netgear and others. You're not stuck with the Ubee. > > You are ignoring the "BUSINESS CLASS" part of the equation. TWC-BC > provides the modem for you; you have little (arris) or no (ubee) > access to it. Touche. Arris here in Maine. --C -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From bill at herrin.us Wed Jul 22 04:51:50 2015 From: bill at herrin.us (William Herrin) Date: Wed, 22 Jul 2015 00:51:50 -0400 Subject: FIB Sizing In-Reply-To: <49EE1A35457387418410F97564A3752B013686BC6F@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B013686BC6F@MSG6.westman.int> Message-ID: On Tue, Jul 21, 2015 at 4:57 PM, Graham Johnston wrote: > Does anybody have a working projection, or crystal ball, that can provide a recommendation on FIB size requirements for the next 24 months? Are we expecting the IPv4 table to continue to grow at somewhere around 50k routes a year? I came up with this from eyeballing the graph at http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active.txt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step. Hi Graham, The IPv4 BGP table has been growing by 10% to 15% per year since CIDR. It appears to be a compounding curve, not linear. IPv4 exhaustion is a new factor which may or may not impact the next 24 months' projection. There are arguments favoring a slower rate (no more free pool). There are arguments favoring a faster rate (fragmentation from address sales). No one has a crystal ball good enough to know for sure -- the situation is literally unprecedented. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From egypcio at googlemail.com Wed Jul 22 09:52:16 2015 From: egypcio at googlemail.com (=?UTF-8?Q?Vin=C3=ADcius_Zavam?=) Date: Wed, 22 Jul 2015 06:52:16 -0300 Subject: =?UTF-8?Q?Fwd=3A_BSDCon_Brasil_2015=3A_Apresenta=C3=A7=C3=B5es_=2F_Talks?= Message-ID: ---------- Forwarded message ---------- From: BSDCon Brasil 2015 Date: 2015-07-16 13:09 GMT-03:00 Subject: BSDCon Brasil 2015: Apresenta??es / Talks To: https://twitter.com/bsdcon_br/status/620727031630798852 ===== pt Acompanhe as atualiza??es da confer?ncia atrav?s do Twitter ou Facebook (fb.com/bsdconbrasil2015). Gostaria de patrocinar a BSDCon Brasil 2015? Entre em contato conosco atrav?s das redes sociais ou mande-nos um email. Escreva para patrocinio at bsdcon.com.br Conhe?a nossos patrocinadores: http://2015.bsdcon.com.br/patrocinio ===== en Follow conference updates on Twitter or Facebook (fb.com/bsdconbrasil2015). Would you like to become a sponsor? Please write to sponsorship at bsdcon.com.br Meet our sponsors: http://2015.bsdcon.com.br/sponsorship -- BSDCon Brasil 2015 http://2015.bsdcon.com.br http://2015.bsdcon.com.br/start http://twitter.com/bsdcon_br From colton.conor at gmail.com Wed Jul 22 13:48:46 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 22 Jul 2015 08:48:46 -0500 Subject: DE-CIX vs Equinix Message-ID: What are the main difference between these two peering companies, exchanges, and overall operating model? The market in question would be Dallas Texas where Equinix already has the only established peering exchange with over 100 members, and DE-CIX just announced today that that would also be building one in Dallas. It will take time for DE-CIX to establish their exchange in Dallas and get members, but they better question is why would people switch? For a 10G port with a cross connect to the exchange included Equinix charges $1000 per month. According to DE-CIX it looks like they charge $1250 per month for a 10G port in NYC, so I asusme the same would be true in Dallas. https://nyc.de-cix.net/products-services/pricing/ Looks like DE-CIX will offer a promo to entice new members to join, and their exchange will be in the carrier neatural meet me room operated by the infomart that will have little to no cross connect fees. Why would people pay more to connect to an exchange with less members? What is the european exchange that is a non-profit and basically only covers the cost of operating the exchange? From mark.tinka at seacom.mu Wed Jul 22 13:57:49 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 22 Jul 2015 15:57:49 +0200 Subject: DE-CIX vs Equinix In-Reply-To: References: Message-ID: <55AFA15D.1050105@seacom.mu> On 22/Jul/15 15:48, Colton Conor wrote: > > Why would people pay more to connect to an exchange with less members? What > is the european exchange that is a non-profit and basically only covers the > cost of operating the exchange? My knee-jerk response would be that the big EU exchange points are trading on their name - as being well-known, well-run exchange points - to get traction in markets outside of EU, that may or may not have established exchange points. Whether operators see value in that is an exercise left up to the reader. Mark. From cgucker at onesc.net Wed Jul 22 14:25:50 2015 From: cgucker at onesc.net (Charles Gucker) Date: Wed, 22 Jul 2015 10:25:50 -0400 Subject: DE-CIX vs Equinix In-Reply-To: References: Message-ID: On Wed, Jul 22, 2015 at 9:48 AM, Colton Conor wrote: > What are the main difference between these two peering companies, > exchanges, and overall operating model? The market in question would be > Dallas Texas where Equinix already has the only established peering > exchange with over 100 members, and DE-CIX just announced today that that > would also be building one in Dallas. It will take time for DE-CIX to > establish their exchange in Dallas and get members, but they better > question is why would people switch? In short, Equinix is by far and large a data center operator and the Internet exchange is an add-on service only available within their data center locations. DE-CIX is an exchange point operator who operates in multiple dis-parent data center locations. > For a 10G port with a cross connect to the exchange included Equinix > charges $1000 per month. According to DE-CIX it looks like they charge > $1250 per month for a 10G port in NYC, so I asusme the same would be true > in Dallas. https://nyc.de-cix.net/products-services/pricing/ I would not use DE-CIX NYC pricing as a benchmark. As DE-CIX learned, NYC is a very difficult market to get connectivity and to build an exchange in. As such their operating costs are a lot higher than in other markets and I don't believe it would be a good assumption to use NYC based pricing in Dallas. But keep in mind, DE-CIX likes to distribute their network access nodes to get a larger audience than within ones own facility. Also, I would suggest looking at the big picture and the cost of colocation services in a facility other than Equinix to "level the playing field". > Looks like DE-CIX will offer a promo to entice new members to join, and > their exchange will be in the carrier neatural meet me room operated by the > infomart that will have little to no cross connect fees. > > Why would people pay more to connect to an exchange with less members? What > is the european exchange that is a non-profit and basically only covers the > cost of operating the exchange? As stated above, when looking at the big picture, it may or may not be more expensive when all of your other services are considered. It should be said that I don't have any axe to grind and think very highly of Equinix. But with respect to Dallas, I would suggest looking at bigger picture and see if your assumptions still hold true. charles From randy at psg.com Wed Jul 22 15:49:29 2015 From: randy at psg.com (Randy Bush) Date: Wed, 22 Jul 2015 17:49:29 +0200 Subject: DE-CIX vs Equinix In-Reply-To: References: Message-ID: > As DE-CIX learned, NYC is a very difficult market to get connectivity > and to build an exchange in. As such their operating costs are a lot > higher than in other markets circuits in the states are more painful than northern europe, japan, etc. a bunch of smaller isps in the states were annoyed at equinix's domination of the east coast markets so encouraged some european community exchanges to colonize. what they did not do was offer to subsidize any surprizes in expense, gaining a market foothold, etc. this is sometimes known as "let's you and him fight." randy From streiner at cluebyfour.org Thu Jul 23 04:01:12 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 23 Jul 2015 00:01:12 -0400 (EDT) Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> Message-ID: On Mon, 20 Jul 2015, Colin Johnston wrote: > blocking to mitigate risk is a better trade off gaining better > percentage legit traffic against a indventant minor valid good network > range. There are bound to be an awful lot of babies in that bathwater you're planning to throw out. You're certainly free to block whatever traffic you wish, but your customers might not appreciate a heavy-handed approach to stopping bad traffic at the gates. jms From list at satchell.net Thu Jul 23 07:03:55 2015 From: list at satchell.net (Stephen Satchell) Date: Thu, 23 Jul 2015 00:03:55 -0700 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> Message-ID: <55B091DB.9000109@satchell.net> On 07/22/2015 09:01 PM, Justin M. Streiner wrote: > You're certainly free to block whatever traffic you wish, but your > customers might not appreciate a heavy-handed approach to stopping bad > traffic at the gates. As opposed to not being able to pass traffic at all? After all, isn't the goal of a distributed denial of service supposed to be to block people using the Internet? Show me a DDoS that just blocks rich people, for example. From nwarren at barryelectric.com Thu Jul 23 12:05:33 2015 From: nwarren at barryelectric.com (Nicholas Warren) Date: Thu, 23 Jul 2015 12:05:33 +0000 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: <55B091DB.9000109@satchell.net> References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> <55B091DB.9000109@satchell.net> Message-ID: How will the customer know the ISP is blocking the traffic? Does the FCC make ISPs disclose this information? Thank you, - Nich Warren On 07/22/2015 09:01 PM, Justin M. Streiner wrote: > You're certainly free to block whatever traffic you wish, but your > customers might not appreciate a heavy-handed approach to stopping bad > traffic at the gates. From mdavids at forfun.net Thu Jul 23 12:31:04 2015 From: mdavids at forfun.net (Marco Davids) Date: Thu, 23 Jul 2015 14:31:04 +0200 Subject: Gmail contact? Message-ID: <55B0DE88.4000508@forfun.net> Hi, Is there anyone on this list that can get me in touch with someone at Google/Gmail? I would like to discuss a suggested improvement with them in regard to RFC-compliance of DKIM/DMARC. Please contact me off-list. Thanks. -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4239 bytes Desc: S/MIME Cryptographic Signature URL: From streiner at cluebyfour.org Thu Jul 23 13:25:33 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 23 Jul 2015 09:25:33 -0400 (EDT) Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> <55B091DB.9000109@satchell.net> Message-ID: On Thu, 23 Jul 2015, Nicholas Warren wrote: > How will the customer know the ISP is blocking the traffic? Does the > FCC make ISPs disclose this information? If a customer is legitimately trying to reach someone in one of the affected IP ranges and failing, at some point, they will either a) give up and try later, or b) contact their provider to try to find out what's going on. If it's something widespread enough that the ISP's support line is blowing up with calls, I'd hope they would either put some sort of announcement on their website/support site/support line. As with anything else in the ISP world, it's about striking an appropriate balance. If ISP X is getting hit with DDoS traffic hard enough to severely impact their business, that can warrant an emergency response, albeit likely a short-term/tactical response. If not, perhaps a more limited response is better. Again, each provider is free to run their network as they see fit. The balance point can also change if downstream ISPs are involved, since ISP X might be making the decision to block or not block traffic for the downstreams, with or without their consent. jms > On 07/22/2015 09:01 PM, Justin M. Streiner wrote: >> You're certainly free to block whatever traffic you wish, but your >> customers might not appreciate a heavy-handed approach to stopping bad >> traffic at the gates. > From cb.list6 at gmail.com Thu Jul 23 14:18:02 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 23 Jul 2015 07:18:02 -0700 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> <55B091DB.9000109@satchell.net> Message-ID: On Thu, Jul 23, 2015 at 6:25 AM, Justin M. Streiner wrote: > On Thu, 23 Jul 2015, Nicholas Warren wrote: > > How will the customer know the ISP is blocking the traffic? Does the FCC >> make ISPs disclose this information? >> > > If a customer is legitimately trying to reach someone in one of the > affected IP ranges and failing, at some point, they will either a) give up > and try later, or b) contact their provider to try to find out what's going > on. > > If it's something widespread enough that the ISP's support line is blowing > up with calls, I'd hope they would either put some sort of announcement on > their website/support site/support line. > > As with anything else in the ISP world, it's about striking an appropriate > balance. If ISP X is getting hit with DDoS traffic hard enough to severely > impact their business, that can warrant an emergency response, albeit > likely a short-term/tactical response. If not, perhaps a more limited > response is better. Again, each provider is free to run their network as > they see fit. > > The balance point can also change if downstream ISPs are involved, since > ISP X might be making the decision to block or not block traffic for the > downstreams, with or without their consent. > > jms > > I agree with you about balance. The issue is that for many of us, UDP floods / DDoS, is daily business. It is not an emergency when you have a baseline for UDP and police it. Or, you can careen from emergency to emergency. CB > On 07/22/2015 09:01 PM, Justin M. Streiner wrote: >> >>> You're certainly free to block whatever traffic you wish, but your >>> customers might not appreciate a heavy-handed approach to stopping bad >>> traffic at the gates. >>> >> >> From nanog at ics-il.net Thu Jul 23 16:35:17 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 23 Jul 2015 11:35:17 -0500 (CDT) Subject: DE-CIX vs Equinix In-Reply-To: Message-ID: <1689360470.625.1437669350919.JavaMail.mhammett@ThunderFuck> I would expect DE-CIX to repeat what they've done elsewhere and expand the IX into any reasonable building in the metro area, greatly increasing its available member count and bringing the IX to places where Equinix isn't. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Colton Conor" To: "NANOG" Sent: Wednesday, July 22, 2015 8:48:46 AM Subject: DE-CIX vs Equinix What are the main difference between these two peering companies, exchanges, and overall operating model? The market in question would be Dallas Texas where Equinix already has the only established peering exchange with over 100 members, and DE-CIX just announced today that that would also be building one in Dallas. It will take time for DE-CIX to establish their exchange in Dallas and get members, but they better question is why would people switch? For a 10G port with a cross connect to the exchange included Equinix charges $1000 per month. According to DE-CIX it looks like they charge $1250 per month for a 10G port in NYC, so I asusme the same would be true in Dallas. https://nyc.de-cix.net/products-services/pricing/ Looks like DE-CIX will offer a promo to entice new members to join, and their exchange will be in the carrier neatural meet me room operated by the infomart that will have little to no cross connect fees. Why would people pay more to connect to an exchange with less members? What is the european exchange that is a non-profit and basically only covers the cost of operating the exchange? From nanog at ics-il.net Thu Jul 23 16:37:37 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 23 Jul 2015 11:37:37 -0500 (CDT) Subject: DE-CIX vs Equinix In-Reply-To: Message-ID: <1544120237.628.1437669490149.JavaMail.mhammett@ThunderFuck> Agreed. It costs more to transport an IX to another location than the IX makes off of the port they sold you. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Randy Bush" To: "Charles Gucker" Cc: "North American Network Operators' Group" Sent: Wednesday, July 22, 2015 10:49:29 AM Subject: Re: DE-CIX vs Equinix > As DE-CIX learned, NYC is a very difficult market to get connectivity > and to build an exchange in. As such their operating costs are a lot > higher than in other markets circuits in the states are more painful than northern europe, japan, etc. a bunch of smaller isps in the states were annoyed at equinix's domination of the east coast markets so encouraged some european community exchanges to colonize. what they did not do was offer to subsidize any surprizes in expense, gaining a market foothold, etc. this is sometimes known as "let's you and him fight." randy From Valdis.Kletnieks at vt.edu Thu Jul 23 18:45:30 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 23 Jul 2015 14:45:30 -0400 Subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours In-Reply-To: Your message of "Thu, 23 Jul 2015 09:25:33 -0400." References: <9a31dd85f5814c739dcebcdf3c80cb3c@EXCHANGE2K13.thenap.com> <10608.1437416337@turing-police.cc.vt.edu> <608BFE1E-6FCC-4A58-A184-74EA4BD67182@gt86car.org.uk> <13446.1437418638@turing-police.cc.vt.edu> <6C4BAFEF-04BF-4B0A-A095-E47C76986643@gt86car.org.uk> <18523.1437422677@turing-police.cc.vt.edu> <19770.1437423601@turing-police.cc.vt.edu> <0D2A44A8-72F3-45FD-8210-B2DDA5B47890@gt86car.org.uk> <55B091DB.9000109@satchell.net> Message-ID: <18155.1437677130@turing-police.cc.vt.edu> On Thu, 23 Jul 2015 09:25:33 -0400, "Justin M. Streiner" said: > If a customer is legitimately trying to reach someone in one of the > affected IP ranges and failing, at some point, they will either a) give up > and try later, or b) contact their provider to try to find out what's > going on. You missed (c) give up after a few days of retrying and figure the destination has folded and gone dark, and not bother trying anymore. It's particularly likely to happen if you haven't given *detailed* instructions to the people who answer your phones *and* a host they can test from *outside* your blocking. If your help desk responds with "It doesn't seem to be up for me either", outcome (c) is almost guaranteed... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog at ics-il.net Thu Jul 23 19:24:19 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 23 Jul 2015 14:24:19 -0500 (CDT) Subject: SIP trunking providers In-Reply-To: <2D72811B-9366-4210-8A9B-13B935A4DE33@delong.com> Message-ID: <1468986505.2260.1437679473208.JavaMail.mhammett@ThunderFuck> I have several Asterisk VMs running in my own facility, but that doesn't change the fact that a particular provider's media gateway that SIP reinvites me to is somewhere non-local. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Owen DeLong" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, July 20, 2015 8:04:24 AM Subject: Re: SIP trunking providers Why not set up a small Asterisk box in a local datacenter and only trunk out the non-local calls? Owen > On Jul 20, 2015, at 03:36 , Mike Hammett wrote: > > I want the gateway in Chicago as well. > > I am Chicago based. The end users are Chicago based. Therefore the origination would be coming from a Chicago area gateway. Half of the calls (inbound would be guaranteed to be local as they'd be coming in through a local tandem anyway. Most of the termination traffic would again be to local numbers, therefore would again have to be through local tandems. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Nathan Anderson" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Monday, July 20, 2015 4:11:37 AM > Subject: RE: SIP trunking providers > > Maybe I'm missing something here, but what does it matter if the RTP from your perspective ends in Chicago or not? If it does end in Chicago, that only means they are proxying the audio before sending it on to the actual media gateway for that call where it finally drops onto the PSTN. So all that happens is that the audio latency remains the same (or worse, because of the additional, unnecessary proxy) AND that the actual media gateway remains hidden from you. You won't be able to actually test and see the latency to the MG, and you will be under the (false) impression that latency across all calls is equally "good" because you are only measuring RTT to a specific and common media proxy. By sending the audio directly to an MG closer to the point of exit from IP-land, it is taking a more direct route to the callee than you are seemingly asking for. > > If you're not talking about adding a proxy to the equation, are you expecting to find a provider in Chicago that immediately goes from IP to PSTN within Chicago, regardless of the actual destination of the call? Circuit-switched TDM is not a no-latency connection. Physics is involved here. The farther apart the caller is from the callee, the more latency there will be, regardless of the medium. All other things being equal (similar network path, etc.), I doubt IP packet switching significantly increases the latency over and above TDM call trunking. But I'm not an expert, and again, if I'm missing something here, I would love to be proven wrong. > > -- > Nathan Anderson > First Step Internet, LLC > nathana at fsr.com > > ________________________________________ > From: NANOG [nanog-bounces at nanog.org] On Behalf Of Mike Hammett [nanog at ics-il.net] > Sent: Sunday, July 19, 2015 1:04 PM > Cc: nanog at nanog.org > Subject: Re: SIP trunking providers > > I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Rafael Possamai" > To: nanog at nanog.org > Sent: Friday, June 19, 2015 4:40:48 PM > Subject: SIP trunking providers > > Would anyone in the list be able to recommend a SIP trunk provider in the > Chicago area? Not a VoIP expert, so just looking for someone with previous > experience. > > > Thanks, > Rafael > > From gtaylor at tnetconsulting.net Thu Jul 23 19:42:26 2015 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 23 Jul 2015 14:42:26 -0500 Subject: Help with GMail... Message-ID: <55B143A2.70606@tnetconsulting.net> Hi, I was wondering if there were any GMail contacts on NANOG that might contact me either on or off list for some help. I am having problems sending email to GMail from my new (< 2 weeks old) Linode VPS. tncsrv06.tnetconsulting.net (IPv4: 45.33.28.24, IPv6: 2600:3c00:f03c:91ff:fe26:8849) I have forward and reverse DNS set up as well as following all of the same practices that I have used to administer email servers for the past 15 years. So, I think that I have everything covered. (If I've missed something, let me know and I'll take care of it.) Is there a chance that my IP address(es) (v4 and / or v6) have been blocked because of previous IP user actions? Or am I by chance part of a netblock that is black listed? Below is the multi-line SMTP response that is showing up in the DSN that I'm receiving. <<< 550-5.7.1 [2600:3c00::f03c:91ff:fe26:8849 12] Our system has detected that <<< 550-5.7.1 this message is likely unsolicited mail. To reduce the amount of spam <<< 550-5.7.1 sent to Gmail, this message has been blocked. Please visit <<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more information. f5si4126138oeo.56 - gsmtp Any help or suggestions you could provide would be greatly appreciated. I'm in the process of migrating off of my old server to my new Linode VPS as part of a move and would like to get this quickly, if possible. As a temporary work around, I have routed gmail.com email to my other Linode which can send email to GMail. tncsrv05.tnetconsulting.net (IPv4: 109.74.192.125, IPv6: 2a01:7e00::f03c:91ff:fe89:2935) Thanks for your time and any help you can provide. -- Grant. . . . unix || die P.S. I did send an email to postmaster at gmail.com, but it bounced saying that the address had been disabled. > > (reason: 550 5.2.1 The email account that you tried to reach is > disabled. n5si4180778oib.56 - gsmtp) From gtaylor at tnetconsulting.net Thu Jul 23 19:54:49 2015 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 23 Jul 2015 14:54:49 -0500 Subject: Help with GMail... In-Reply-To: <55B143A2.70606@tnetconsulting.net> References: <55B143A2.70606@tnetconsulting.net> Message-ID: <55B14689.90306@tnetconsulting.net> Kudos to Gareth T. who pointed out that I forgot to update my SPF record, which includes a "-all". I've updated my SPF record and will try again after my old info expires out of caches. -- Grant. . . . unix || die On 07/23/2015 02:42 PM, Grant Taylor via NANOG wrote: > Hi, > > I was wondering if there were any GMail contacts on NANOG that might > contact me either on or off list for some help. > > I am having problems sending email to GMail from my new (< 2 weeks > old) Linode VPS. > > tncsrv06.tnetconsulting.net (IPv4: 45.33.28.24, IPv6: > 2600:3c00:f03c:91ff:fe26:8849) > > I have forward and reverse DNS set up as well as following all of the > same practices that I have used to administer email servers for the > past 15 years. So, I think that I have everything covered. (If I've > missed something, let me know and I'll take care of it.) > > Is there a chance that my IP address(es) (v4 and / or v6) have been > blocked because of previous IP user actions? Or am I by chance part > of a netblock that is black listed? > > Below is the multi-line SMTP response that is showing up in the DSN > that I'm receiving. > > <<< 550-5.7.1 [2600:3c00::f03c:91ff:fe26:8849 12] Our system has > detected that > <<< 550-5.7.1 this message is likely unsolicited mail. To reduce the > amount of spam > <<< 550-5.7.1 sent to Gmail, this message has been blocked. Please visit > <<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more > information. f5si4126138oeo.56 - gsmtp > > Any help or suggestions you could provide would be greatly > appreciated. I'm in the process of migrating off of my old server to > my new Linode VPS as part of a move and would like to get this > quickly, if possible. > > As a temporary work around, I have routed gmail.com email to my other > Linode which can send email to GMail. > > tncsrv05.tnetconsulting.net (IPv4: 109.74.192.125, IPv6: > 2a01:7e00::f03c:91ff:fe89:2935) > > Thanks for your time and any help you can provide. > > > From morrowc.lists at gmail.com Thu Jul 23 20:03:25 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 23 Jul 2015 16:03:25 -0400 Subject: Help with GMail... In-Reply-To: <55B14689.90306@tnetconsulting.net> References: <55B143A2.70606@tnetconsulting.net> <55B14689.90306@tnetconsulting.net> Message-ID: $ host 2600:3c00:f03c:91ff:fe26:8849 Host 2600:3c00:f03c:91ff:fe26:8849 not found: 3(NXDOMAIN) you probably also want to fix that... On Thu, Jul 23, 2015 at 3:54 PM, Grant Taylor via NANOG wrote: > Kudos to Gareth T. who pointed out that I forgot to update my SPF record, > which includes a "-all". > > I've updated my SPF record and will try again after my old info expires out > of caches. > > > > -- > Grant. . . . > unix || die > > On 07/23/2015 02:42 PM, Grant Taylor via NANOG wrote: >> >> Hi, >> >> I was wondering if there were any GMail contacts on NANOG that might >> contact me either on or off list for some help. >> >> I am having problems sending email to GMail from my new (< 2 weeks old) >> Linode VPS. >> >> tncsrv06.tnetconsulting.net (IPv4: 45.33.28.24, IPv6: >> 2600:3c00:f03c:91ff:fe26:8849) >> >> I have forward and reverse DNS set up as well as following all of the same >> practices that I have used to administer email servers for the past 15 >> years. So, I think that I have everything covered. (If I've missed >> something, let me know and I'll take care of it.) >> >> Is there a chance that my IP address(es) (v4 and / or v6) have been >> blocked because of previous IP user actions? Or am I by chance part of a >> netblock that is black listed? >> >> Below is the multi-line SMTP response that is showing up in the DSN that >> I'm receiving. >> >> <<< 550-5.7.1 [2600:3c00::f03c:91ff:fe26:8849 12] Our system has >> detected that >> <<< 550-5.7.1 this message is likely unsolicited mail. To reduce the >> amount of spam >> <<< 550-5.7.1 sent to Gmail, this message has been blocked. Please visit >> <<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more >> information. f5si4126138oeo.56 - gsmtp >> >> Any help or suggestions you could provide would be greatly appreciated. >> I'm in the process of migrating off of my old server to my new Linode VPS as >> part of a move and would like to get this quickly, if possible. >> >> As a temporary work around, I have routed gmail.com email to my other >> Linode which can send email to GMail. >> >> tncsrv05.tnetconsulting.net (IPv4: 109.74.192.125, IPv6: >> 2a01:7e00::f03c:91ff:fe89:2935) >> >> Thanks for your time and any help you can provide. >> >> >> > From gtaylor at tnetconsulting.net Thu Jul 23 20:16:04 2015 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 23 Jul 2015 15:16:04 -0500 Subject: Help with GMail... In-Reply-To: References: <55B143A2.70606@tnetconsulting.net> <55B14689.90306@tnetconsulting.net> Message-ID: <55B14B84.3060604@tnetconsulting.net> Hi Christopher, Unless my eyes are deceiving me, I think "host" ate a colon in "::" for you. I *think* that I have forward and reverse DNS set up properly for both IPv4 and IPv6. > #[gtaylor at tncsrv04:~]$ dig a tncsrv06.tnetconsulting.net > tncsrv06.tnetconsulting.net. 3600 IN A 45.33.28.24 > #[gtaylor at tncsrv04:~]$ dig -x 45.33.28.24 > 24.28.33.45.in-addr.arpa. 86400 IN PTR tncsrv06.tnetconsulting.net. > #[gtaylor at tncsrv04:~]$ dig aaaa tncsrv06.tnetconsulting.net > tncsrv06.tnetconsulting.net. 3600 IN AAAA > 2600:3c00::f03c:91ff:fe26:8849 > #[gtaylor at tncsrv04:~]$ dig -x 2600:3c00::f03c:91ff:fe26:8849 > 9.4.8.8.6.2.e.f.f.f.1.9.c.3.0.f.0.0.0.0.0.0.0.0.0.0.c.3.0.0.6.2.ip6.arpa. > 83117 IN PTR tncsrv06.tnetconsulting.net. Thanks for the second set of eyes, because I obviously missed something. -- Grant. . . . unix || die On 07/23/2015 03:03 PM, Christopher Morrow wrote: > $ host 2600:3c00:f03c:91ff:fe26:8849 > Host 2600:3c00:f03c:91ff:fe26:8849 not found: 3(NXDOMAIN) > > you probably also want to fix that... From cma at cmadams.net Thu Jul 23 20:25:16 2015 From: cma at cmadams.net (Chris Adams) Date: Thu, 23 Jul 2015 15:25:16 -0500 Subject: Help with GMail... In-Reply-To: <55B143A2.70606@tnetconsulting.net> References: <55B143A2.70606@tnetconsulting.net> Message-ID: <20150723202516.GC5196@cmadams.net> Once upon a time, Grant Taylor via NANOG said: > I am having problems sending email to GMail from my new (< 2 weeks > old) Linode VPS. May not be the case here, but I had an issue with my Linode and IPv6 email (not with gmail.com though). If you just "request IPv6", you get a single /128 out of a common /64. The problem is that most people doing IPv6 anti-spam treat reputation on at least the /64, not individual /128s. You can request a /64 from Linode, no additional charge. I switched to using my own /64, and I haven't had any issues since. I use Lynx to look things up in Google sometimes, and was also periodically getting blocked from that (with a captcha!). Since switching to my own /64, I haven't had any issue there either. -- Chris Adams From hannigan at gmail.com Thu Jul 23 21:15:51 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 23 Jul 2015 17:15:51 -0400 Subject: OCP Data Center Spec: Ladder Tray Message-ID: Hi NANOG, The Open Compute Project "OCP" had, at least that I can recall but now can not find, a ladder tray deployment spec in the data center working group. It called for tray to span the middle of the aisle as I remember it. Anyone recall or have a pointer to it? My favorite search engine and the OCP wiki yields nothing. I was also hoping to find someone involved in the spec to discuss a related NFPA issue with. Best, -M< From gtaylor at tnetconsulting.net Thu Jul 23 21:53:57 2015 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 23 Jul 2015 16:53:57 -0500 Subject: Help with GMail... In-Reply-To: <55B14689.90306@tnetconsulting.net> References: <55B143A2.70606@tnetconsulting.net> <55B14689.90306@tnetconsulting.net> Message-ID: <55B16275.1040706@tnetconsulting.net> After updating my SPF record per Gareth's recommendation, email now seems to be flowing to GMail properly. -- Grant. . . . unix || |die On 07/23/2015 02:54 PM, Grant Taylor via NANOG wrote: > Kudos to Gareth T. who pointed out that I forgot to update my SPF > record, which includes a "-all". > > I've updated my SPF record and will try again after my old info > expires out of caches. > > > From owen at delong.com Fri Jul 24 01:56:47 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Jul 2015 18:56:47 -0700 Subject: SIP trunking providers In-Reply-To: <1468986505.2260.1437679473208.JavaMail.mhammett@ThunderFuck> References: <1468986505.2260.1437679473208.JavaMail.mhammett@ThunderFuck> Message-ID: Nor will the fact that your particular trunking provider is local, so I?m not sure what you seek to accomplish, then. Owen > On Jul 23, 2015, at 12:24 , Mike Hammett wrote: > > I have several Asterisk VMs running in my own facility, but that doesn't change the fact that a particular provider's media gateway that SIP reinvites me to is somewhere non-local. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Owen DeLong" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Monday, July 20, 2015 8:04:24 AM > Subject: Re: SIP trunking providers > > Why not set up a small Asterisk box in a local datacenter and only trunk out the non-local calls? > > Owen > >> On Jul 20, 2015, at 03:36 , Mike Hammett wrote: >> >> I want the gateway in Chicago as well. >> >> I am Chicago based. The end users are Chicago based. Therefore the origination would be coming from a Chicago area gateway. Half of the calls (inbound would be guaranteed to be local as they'd be coming in through a local tandem anyway. Most of the termination traffic would again be to local numbers, therefore would again have to be through local tandems. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Nathan Anderson" >> To: "Mike Hammett" >> Cc: nanog at nanog.org >> Sent: Monday, July 20, 2015 4:11:37 AM >> Subject: RE: SIP trunking providers >> >> Maybe I'm missing something here, but what does it matter if the RTP from your perspective ends in Chicago or not? If it does end in Chicago, that only means they are proxying the audio before sending it on to the actual media gateway for that call where it finally drops onto the PSTN. So all that happens is that the audio latency remains the same (or worse, because of the additional, unnecessary proxy) AND that the actual media gateway remains hidden from you. You won't be able to actually test and see the latency to the MG, and you will be under the (false) impression that latency across all calls is equally "good" because you are only measuring RTT to a specific and common media proxy. By sending the audio directly to an MG closer to the point of exit from IP-land, it is taking a more direct route to the callee than you are seemingly asking for. >> >> If you're not talking about adding a proxy to the equation, are you expecting to find a provider in Chicago that immediately goes from IP to PSTN within Chicago, regardless of the actual destination of the call? Circuit-switched TDM is not a no-latency connection. Physics is involved here. The farther apart the caller is from the callee, the more latency there will be, regardless of the medium. All other things being equal (similar network path, etc.), I doubt IP packet switching significantly increases the latency over and above TDM call trunking. But I'm not an expert, and again, if I'm missing something here, I would love to be proven wrong. >> >> -- >> Nathan Anderson >> First Step Internet, LLC >> nathana at fsr.com >> >> ________________________________________ >> From: NANOG [nanog-bounces at nanog.org] On Behalf Of Mike Hammett [nanog at ics-il.net] >> Sent: Sunday, July 19, 2015 1:04 PM >> Cc: nanog at nanog.org >> Subject: Re: SIP trunking providers >> >> I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Rafael Possamai" >> To: nanog at nanog.org >> Sent: Friday, June 19, 2015 4:40:48 PM >> Subject: SIP trunking providers >> >> Would anyone in the list be able to recommend a SIP trunk provider in the >> Chicago area? Not a VoIP expert, so just looking for someone with previous >> experience. >> >> >> Thanks, >> Rafael >> >> > From nanog at ics-il.net Fri Jul 24 02:17:30 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 23 Jul 2015 21:17:30 -0500 (CDT) Subject: SIP trunking providers In-Reply-To: Message-ID: <905343213.325.1437704287812.JavaMail.mhammett@ThunderFuck> That's why I asked for one with everything local. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Owen DeLong" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, July 23, 2015 8:56:47 PM Subject: Re: SIP trunking providers Nor will the fact that your particular trunking provider is local, so I?m not sure what you seek to accomplish, then. Owen > On Jul 23, 2015, at 12:24 , Mike Hammett wrote: > > I have several Asterisk VMs running in my own facility, but that doesn't change the fact that a particular provider's media gateway that SIP reinvites me to is somewhere non-local. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Owen DeLong" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Monday, July 20, 2015 8:04:24 AM > Subject: Re: SIP trunking providers > > Why not set up a small Asterisk box in a local datacenter and only trunk out the non-local calls? > > Owen > >> On Jul 20, 2015, at 03:36 , Mike Hammett wrote: >> >> I want the gateway in Chicago as well. >> >> I am Chicago based. The end users are Chicago based. Therefore the origination would be coming from a Chicago area gateway. Half of the calls (inbound would be guaranteed to be local as they'd be coming in through a local tandem anyway. Most of the termination traffic would again be to local numbers, therefore would again have to be through local tandems. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Nathan Anderson" >> To: "Mike Hammett" >> Cc: nanog at nanog.org >> Sent: Monday, July 20, 2015 4:11:37 AM >> Subject: RE: SIP trunking providers >> >> Maybe I'm missing something here, but what does it matter if the RTP from your perspective ends in Chicago or not? If it does end in Chicago, that only means they are proxying the audio before sending it on to the actual media gateway for that call where it finally drops onto the PSTN. So all that happens is that the audio latency remains the same (or worse, because of the additional, unnecessary proxy) AND that the actual media gateway remains hidden from you. You won't be able to actually test and see the latency to the MG, and you will be under the (false) impression that latency across all calls is equally "good" because you are only measuring RTT to a specific and common media proxy. By sending the audio directly to an MG closer to the point of exit from IP-land, it is taking a more direct route to the callee than you are seemingly asking for. >> >> If you're not talking about adding a proxy to the equation, are you expecting to find a provider in Chicago that immediately goes from IP to PSTN within Chicago, regardless of the actual destination of the call? Circuit-switched TDM is not a no-latency connection. Physics is involved here. The farther apart the caller is from the callee, the more latency there will be, regardless of the medium. All other things being equal (similar network path, etc.), I doubt IP packet switching significantly increases the latency over and above TDM call trunking. But I'm not an expert, and again, if I'm missing something here, I would love to be proven wrong. >> >> -- >> Nathan Anderson >> First Step Internet, LLC >> nathana at fsr.com >> >> ________________________________________ >> From: NANOG [nanog-bounces at nanog.org] On Behalf Of Mike Hammett [nanog at ics-il.net] >> Sent: Sunday, July 19, 2015 1:04 PM >> Cc: nanog at nanog.org >> Subject: Re: SIP trunking providers >> >> I too am looking for the Chicago area. Low volume. I'm looking for people whose SIP and RTP hit the end of the road in Chicago. Not interested in someone whose SIP servers are in LA , but will redirect me to the nearest gateway... without telling me where said gateway is. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Rafael Possamai" >> To: nanog at nanog.org >> Sent: Friday, June 19, 2015 4:40:48 PM >> Subject: SIP trunking providers >> >> Would anyone in the list be able to recommend a SIP trunk provider in the >> Chicago area? Not a VoIP expert, so just looking for someone with previous >> experience. >> >> >> Thanks, >> Rafael >> >> > From jared at compuwizz.net Fri Jul 24 03:04:05 2015 From: jared at compuwizz.net (Jared Geiger) Date: Thu, 23 Jul 2015 20:04:05 -0700 Subject: SIP trunking providers In-Reply-To: <905343213.325.1437704287812.JavaMail.mhammett@ThunderFuck> References: <905343213.325.1437704287812.JavaMail.mhammett@ThunderFuck> Message-ID: Peerless Network, Hypercube, Inteliquent, and Intelepeer all have switch equipment in Chicago. Inteliquent or Peerless would be your best choices. They run alternative tandem services in those markets so local calls will remain in area. Hypercube does offer a similar product, I'm just not sure if they have a tandem in Chicago also. Verizon also has a Chicago gateway but implementation takes forever. ~Jared Geiger On Thu, Jul 23, 2015 at 7:17 PM, Mike Hammett wrote: > That's why I asked for one with everything local. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Owen DeLong" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Thursday, July 23, 2015 8:56:47 PM > Subject: Re: SIP trunking providers > > Nor will the fact that your particular trunking provider is local, so I?m > not sure what you seek to accomplish, then. > > Owen > > > On Jul 23, 2015, at 12:24 , Mike Hammett wrote: > > > > I have several Asterisk VMs running in my own facility, but that doesn't > change the fact that a particular provider's media gateway that SIP > reinvites me to is somewhere non-local. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > ----- Original Message ----- > > > > From: "Owen DeLong" > > To: "Mike Hammett" > > Cc: nanog at nanog.org > > Sent: Monday, July 20, 2015 8:04:24 AM > > Subject: Re: SIP trunking providers > > > > Why not set up a small Asterisk box in a local datacenter and only trunk > out the non-local calls? > > > > Owen > > > >> On Jul 20, 2015, at 03:36 , Mike Hammett wrote: > >> > >> I want the gateway in Chicago as well. > >> > >> I am Chicago based. The end users are Chicago based. Therefore the > origination would be coming from a Chicago area gateway. Half of the calls > (inbound would be guaranteed to be local as they'd be coming in through a > local tandem anyway. Most of the termination traffic would again be to > local numbers, therefore would again have to be through local tandems. > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> ----- Original Message ----- > >> > >> From: "Nathan Anderson" > >> To: "Mike Hammett" > >> Cc: nanog at nanog.org > >> Sent: Monday, July 20, 2015 4:11:37 AM > >> Subject: RE: SIP trunking providers > >> > >> Maybe I'm missing something here, but what does it matter if the RTP > from your perspective ends in Chicago or not? If it does end in Chicago, > that only means they are proxying the audio before sending it on to the > actual media gateway for that call where it finally drops onto the PSTN. So > all that happens is that the audio latency remains the same (or worse, > because of the additional, unnecessary proxy) AND that the actual media > gateway remains hidden from you. You won't be able to actually test and see > the latency to the MG, and you will be under the (false) impression that > latency across all calls is equally "good" because you are only measuring > RTT to a specific and common media proxy. By sending the audio directly to > an MG closer to the point of exit from IP-land, it is taking a more direct > route to the callee than you are seemingly asking for. > >> > >> If you're not talking about adding a proxy to the equation, are you > expecting to find a provider in Chicago that immediately goes from IP to > PSTN within Chicago, regardless of the actual destination of the call? > Circuit-switched TDM is not a no-latency connection. Physics is involved > here. The farther apart the caller is from the callee, the more latency > there will be, regardless of the medium. All other things being equal > (similar network path, etc.), I doubt IP packet switching significantly > increases the latency over and above TDM call trunking. But I'm not an > expert, and again, if I'm missing something here, I would love to be proven > wrong. > >> > >> -- > >> Nathan Anderson > >> First Step Internet, LLC > >> nathana at fsr.com > >> > >> ________________________________________ > >> From: NANOG [nanog-bounces at nanog.org] On Behalf Of Mike Hammett [ > nanog at ics-il.net] > >> Sent: Sunday, July 19, 2015 1:04 PM > >> Cc: nanog at nanog.org > >> Subject: Re: SIP trunking providers > >> > >> I too am looking for the Chicago area. Low volume. I'm looking for > people whose SIP and RTP hit the end of the road in Chicago. Not interested > in someone whose SIP servers are in LA , but will redirect me to the > nearest gateway... without telling me where said gateway is. > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> ----- Original Message ----- > >> > >> From: "Rafael Possamai" > >> To: nanog at nanog.org > >> Sent: Friday, June 19, 2015 4:40:48 PM > >> Subject: SIP trunking providers > >> > >> Would anyone in the list be able to recommend a SIP trunk provider in > the > >> Chicago area? Not a VoIP expert, so just looking for someone with > previous > >> experience. > >> > >> > >> Thanks, > >> Rafael > >> > >> > > > > > From cscora at apnic.net Fri Jul 24 18:13:43 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Jul 2015 04:13:43 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201507241813.t6OIDh8j008357@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 25 Jul, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 553100 Prefixes after maximum aggregation (per Origin AS): 209326 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 269834 Total ASes present in the Internet Routing Table: 50975 Prefixes per ASN: 10.85 Origin-only ASes present in the Internet Routing Table: 36693 Origin ASes announcing only one prefix: 16176 Transit ASes present in the Internet Routing Table: 6344 Transit-only ASes present in the Internet Routing Table: 174 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 39 Max AS path prepend of ASN ( 12486) 32 Prefixes from unregistered ASNs in the Routing Table: 1826 Unregistered ASNs in the Routing Table: 576 Number of 32-bit ASNs allocated by the RIRs: 10330 Number of 32-bit ASNs visible in the Routing Table: 7938 Prefixes from 32-bit ASNs in the Routing Table: 29501 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 417 Number of addresses announced to Internet: 2770525221 Equivalent to 165 /8s, 34 /16s and 220 /24s Percentage of available address space announced: 74.8 Percentage of allocated address space announced: 74.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.5 Total number of prefixes smaller than registry allocations: 184978 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 136914 Total APNIC prefixes after maximum aggregation: 39806 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 143793 Unique aggregates announced from the APNIC address blocks: 58303 APNIC Region origin ASes present in the Internet Routing Table: 5075 APNIC Prefixes per ASN: 28.33 APNIC Region origin ASes announcing only one prefix: 1196 APNIC Region transit ASes present in the Internet Routing Table: 883 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1558 Number of APNIC addresses announced to Internet: 751328325 Equivalent to 44 /8s, 200 /16s and 92 /24s Percentage of available APNIC address space announced: 87.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179653 Total ARIN prefixes after maximum aggregation: 88052 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182431 Unique aggregates announced from the ARIN address blocks: 85355 ARIN Region origin ASes present in the Internet Routing Table: 16593 ARIN Prefixes per ASN: 10.99 ARIN Region origin ASes announcing only one prefix: 6083 ARIN Region transit ASes present in the Internet Routing Table: 1739 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 559 Number of ARIN addresses announced to Internet: 1085308960 Equivalent to 64 /8s, 176 /16s and 128 /24s Percentage of available ARIN address space announced: 57.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 134316 Total RIPE prefixes after maximum aggregation: 66801 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 140927 Unique aggregates announced from the RIPE address blocks: 87411 RIPE Region origin ASes present in the Internet Routing Table: 17973 RIPE Prefixes per ASN: 7.84 RIPE Region origin ASes announcing only one prefix: 8088 RIPE Region transit ASes present in the Internet Routing Table: 2975 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3875 Number of RIPE addresses announced to Internet: 698628224 Equivalent to 41 /8s, 164 /16s and 56 /24s Percentage of available RIPE address space announced: 101.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 60334 Total LACNIC prefixes after maximum aggregation: 11560 LACNIC Deaggregation factor: 5.22 Prefixes being announced from the LACNIC address blocks: 71453 Unique aggregates announced from the LACNIC address blocks: 33162 LACNIC Region origin ASes present in the Internet Routing Table: 2453 LACNIC Prefixes per ASN: 29.13 LACNIC Region origin ASes announcing only one prefix: 614 LACNIC Region transit ASes present in the Internet Routing Table: 510 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1811 Number of LACNIC addresses announced to Internet: 168750400 Equivalent to 10 /8s, 14 /16s and 237 /24s Percentage of available LACNIC address space announced: 100.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12197 Total AfriNIC prefixes after maximum aggregation: 3058 AfriNIC Deaggregation factor: 3.99 Prefixes being announced from the AfriNIC address blocks: 14079 Unique aggregates announced from the AfriNIC address blocks: 5234 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 19.13 AfriNIC Region origin ASes announcing only one prefix: 195 AfriNIC Region transit ASes present in the Internet Routing Table: 163 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 135 Number of AfriNIC addresses announced to Internet: 65998592 Equivalent to 3 /8s, 239 /16s and 15 /24s Percentage of available AfriNIC address space announced: 65.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2949 11305 941 Korea Telecom 17974 2699 904 78 PT Telekomunikasi Indonesia 7545 2571 339 137 TPG Telecom Limited 4755 2026 425 225 TATA Communications formerly 4538 1947 4190 71 China Education and Research 9829 1796 1356 151 National Internet Backbone 9808 1584 8717 29 Guangdong Mobile Communicatio 9583 1517 119 570 Sify Limited 4808 1465 2245 470 CNCGROUP IP network China169 9498 1360 335 105 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3174 2957 136 Cox Communications Inc. 6389 2758 3688 51 BellSouth.net Inc. 3356 2556 10702 512 Level 3 Communications, Inc. 18566 2068 381 203 MegaPath Corporation 20115 1868 1843 407 Charter Communications 6983 1750 850 244 EarthLink, Inc. 4323 1606 1022 414 tw telecom holdings, inc. 30036 1550 315 481 Mediacom Communications Corp 701 1393 11371 677 MCI Communications Services, 22561 1376 415 256 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 2196 306 367 TELLCOM ILETISIM HIZMETLERI A 20940 2053 807 1489 Akamai International B.V. 6849 1209 355 21 JSC "Ukrtelecom" 8551 1102 376 52 Bezeq International-Ltd 13188 1067 97 77 TOV "Bank-Inform" 31148 1058 46 26 Freenet Ltd. 8402 973 544 15 OJSC "Vimpelcom" 12479 966 933 77 France Telecom Espana SA 6830 918 2696 471 Liberty Global Operations B.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3292 532 249 Telmex Colombia S.A. 28573 2313 2171 111 NET Servi?os de Comunica??o S 8151 1656 3275 451 Uninet S.A. de C.V. 7303 1632 1008 238 Telecom Argentina S.A. 6147 1445 374 30 Telefonica del Peru S.A.A. 6503 1309 421 55 Axtel, S.A.B. de C.V. 26615 1100 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 950 430 163 COLOMBIA TELECOMUNICACIONES S 11830 892 364 15 Instituto Costarricense de El Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 888 280 26 Link Egypt (Link.NET) 8452 843 958 13 TE-AS 36903 512 258 99 Office National des Postes et 36992 442 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 307 146 12 Vodafone Data 3741 250 857 208 Internet Solutions 29571 246 21 13 Cote d'Ivoire Telecom 36947 195 807 13 Telecom Algeria 37054 189 20 7 Data Telecom Service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3292 532 249 Telmex Colombia S.A. 22773 3174 2957 136 Cox Communications Inc. 4766 2949 11305 941 Korea Telecom 6389 2758 3688 51 BellSouth.net Inc. 17974 2699 904 78 PT Telekomunikasi Indonesia 7545 2571 339 137 TPG Telecom Limited 3356 2556 10702 512 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2313 2171 111 NET Servi?os de Comunica??o S 34984 2196 306 367 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3174 3038 Cox Communications Inc. 6389 2758 2707 BellSouth.net Inc. 17974 2699 2621 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2571 2434 TPG Telecom Limited 28573 2313 2202 NET Servi?os de Comunica??o S 3356 2556 2044 Level 3 Communications, Inc. 4766 2949 2008 Korea Telecom 4538 1947 1876 China Education and Research 18566 2068 1865 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 560 UNALLOCATED 8.254.136.0/22 3356 Level 3 Communicatio 560 UNALLOCATED 8.254.136.0/23 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.34.0/24 31148 Freenet Ltd. 100.66.35.0/24 31148 Freenet Ltd. 100.67.26.0/24 31148 Freenet Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:95 /12:262 /13:505 /14:1003 /15:1728 /16:12892 /17:7284 /18:12346 /19:25559 /20:36012 /21:38728 /22:60605 /23:52840 /24:300118 /25:1136 /26:1160 /27:707 /28:14 /29:14 /30:9 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2374 3174 Cox Communications Inc. 18566 2010 2068 MegaPath Corporation 6389 1629 2758 BellSouth.net Inc. 34984 1471 2196 TELLCOM ILETISIM HIZMETLERI A 6983 1397 1750 EarthLink, Inc. 30036 1373 1550 Mediacom Communications Corp 10620 1177 3292 Telmex Colombia S.A. 11492 1111 1195 CABLE ONE, INC. 22561 1049 1376 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1539 2:697 4:96 5:1888 6:25 8:1385 12:1835 13:14 14:1320 15:17 16:2 17:44 18:22 20:49 23:1254 24:1757 27:1997 31:1603 32:37 33:2 34:4 35:3 36:158 37:1973 38:1039 39:14 40:69 41:2735 42:296 43:1362 44:30 45:841 46:2312 47:50 49:920 50:780 52:12 54:82 55:4 56:6 57:42 58:1353 59:718 60:478 61:1756 62:1374 63:1901 64:4403 65:2252 66:4032 67:2055 68:1060 69:3246 70:1024 71:445 72:1959 74:2615 75:341 76:397 77:1281 78:1169 79:808 80:1358 81:1313 82:860 83:718 84:801 85:1331 86:442 87:1038 88:538 89:1929 90:145 91:5998 92:842 93:2278 94:2079 95:2203 96:438 97:348 98:1023 99:54 100:76 101:846 103:7846 104:1992 105:65 106:337 107:1033 108:629 109:2088 110:1145 111:1450 112:821 113:1110 114:843 115:1259 116:1417 117:1074 118:1876 119:1462 120:451 121:1141 122:2163 123:1835 124:1516 125:1624 128:619 129:395 130:413 131:1210 132:514 133:171 134:409 135:97 136:334 137:327 138:1010 139:149 140:237 141:505 142:661 143:508 144:553 145:124 146:796 147:582 148:1197 149:416 150:563 151:706 152:523 153:251 154:470 155:882 156:423 157:420 158:354 159:1021 160:407 161:657 162:2000 163:439 164:698 165:695 166:298 167:829 168:1255 169:185 170:1472 171:246 172:271 173:1533 174:719 175:696 176:1439 177:3917 178:2174 179:937 180:1940 181:1619 182:1841 183:626 184:757 185:3917 186:2867 187:1772 188:2072 189:1628 190:7640 191:1099 192:8546 193:5648 194:4226 195:3677 196:1968 197:1037 198:5548 199:5513 200:6604 201:3202 202:9536 203:9153 204:4697 205:2842 206:3059 207:2982 208:3992 209:3888 210:3594 211:1920 212:2539 213:2351 214:846 215:71 216:5749 217:1836 218:733 219:467 220:1489 221:817 222:471 223:815 End of report From cidr-report at potaroo.net Fri Jul 24 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Jul 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201507242200.t6OM00Md095611@wattle.apnic.net> This report has been generated at Fri Jul 24 21:16:32 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 17-07-15 560782 305926 18-07-15 561232 306566 19-07-15 561244 306558 20-07-15 561108 306099 21-07-15 561336 307384 22-07-15 561839 307658 23-07-15 562000 307827 24-07-15 561972 308171 AS Summary 51245 Number of ASes in routing system 20336 Number of ASes announcing only one prefix 3305 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120757504 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 24Jul15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 561809 308127 253682 45.2% All ASes AS22773 3176 166 3010 94.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2699 78 2621 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS9394 2918 314 2604 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS39891 2473 35 2438 98.6% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2312 118 2194 94.9% NET Servi?os de Comunica??o S.A.,BR AS6389 2758 709 2049 74.3% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS3356 2560 779 1781 69.6% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2949 1235 1714 58.1% KIXS-AS-KR Korea Telecom,KR AS10620 3305 1594 1711 51.8% Telmex Colombia S.A.,CO AS9808 1584 65 1519 95.9% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1749 247 1502 85.9% ITCDELTA - Earthlink, Inc.,US AS20115 1868 421 1447 77.5% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2691 1376 1315 48.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS4755 2024 710 1314 64.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS9498 1360 119 1241 91.2% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1612 416 1196 74.2% TWTC - tw telecom holdings, inc.,US AS18566 2069 898 1171 56.6% MEGAPATH5-US - MegaPath Corporation,US AS6147 1445 277 1168 80.8% Telefonica del Peru S.A.A.,PE AS7552 1198 90 1108 92.5% VIETEL-AS-AP Viettel Corporation,VN AS7303 1634 527 1107 67.7% Telecom Argentina S.A.,AR AS22561 1376 314 1062 77.2% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS4808 1517 508 1009 66.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS26615 1100 130 970 88.2% Tim Celular S.A.,BR AS8151 1656 708 948 57.2% Uninet S.A. de C.V.,MX AS8402 962 23 939 97.6% CORBINA-AS OJSC "Vimpelcom",RU AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 977 130 847 86.7% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS6849 1206 414 792 65.7% UKRTELNET JSC UKRTELECOM,UA AS55430 852 66 786 92.3% STARHUBINTERNET-AS-NGNBN Starhub Internet Pte Ltd,SG AS24560 1244 459 785 63.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN Total 56273 13009 43264 76.9% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.17.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.126.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 61.14.224.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 64.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.57.192.0/22 AS33321 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.228.160.0/20 AS7233 YAHOO-US - Yahoo,US 66.228.176.0/21 AS17110 YAHOO-US2 - Yahoo,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 69.24.96.0/20 AS26804 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.212.135.0/24 AS49097 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 91.234.255.0/24 AS57755 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 100.64.9.0/24 AS10620 Telmex Colombia S.A.,CO 100.66.34.0/24 AS31148 FREENET-AS Freenet Ltd.,UA 100.66.35.0/24 AS31148 FREENET-AS Freenet Ltd.,UA 100.67.26.0/24 AS31148 FREENET-AS Freenet Ltd.,UA 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.25.144.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.37.188.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.228.8.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.228.224.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.229.152.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.230.124.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.104.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 106.0.32.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 116.199.200.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.201.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.202.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.203.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.204.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.205.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.206.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.207.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 138.122.196.0/22 AS61813 EDGE4M CONSULTORIA EM INFRAESTRUTURA LTDA.,BR 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 144.1.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 170.95.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 177.38.216.0/21 AS26241 -Reserved AS-,ZZ 177.84.56.0/22 AS52709 -Reserved AS-,ZZ 177.84.56.0/24 AS52709 -Reserved AS-,ZZ 177.84.57.0/24 AS52709 -Reserved AS-,ZZ 177.84.58.0/24 AS52709 -Reserved AS-,ZZ 177.84.59.0/24 AS52709 -Reserved AS-,ZZ 177.223.96.0/20 AS52726 -Reserved AS-,ZZ 177.223.96.0/21 AS52726 -Reserved AS-,ZZ 177.223.99.0/24 AS52726 -Reserved AS-,ZZ 177.223.104.0/21 AS52726 -Reserved AS-,ZZ 177.223.105.0/24 AS52726 -Reserved AS-,ZZ 177.223.106.0/24 AS52726 -Reserved AS-,ZZ 177.223.107.0/24 AS52726 -Reserved AS-,ZZ 177.223.108.0/24 AS52726 -Reserved AS-,ZZ 179.60.128.0/20 AS26317 179.106.112.0/24 AS52533 -Reserved AS-,ZZ 179.106.116.0/24 AS52533 -Reserved AS-,ZZ 179.106.117.0/24 AS52533 -Reserved AS-,ZZ 179.106.120.0/24 AS52533 -Reserved AS-,ZZ 179.106.121.0/24 AS52533 -Reserved AS-,ZZ 179.106.126.0/24 AS52533 -Reserved AS-,ZZ 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 186.250.60.0/22 AS26227 -Reserved AS-,ZZ 186.250.60.0/24 AS26227 -Reserved AS-,ZZ 186.250.61.0/24 AS26227 -Reserved AS-,ZZ 186.250.62.0/24 AS26227 -Reserved AS-,ZZ 186.250.63.0/24 AS26227 -Reserved AS-,ZZ 189.14.112.0/20 AS52720 WEBFOCO TELECOMUNICACOES LTDA,BR 189.14.112.0/24 AS52871 TASCOM TELECOMUNICA??ES LTDA,BR 189.14.116.0/22 AS28282 -Reserved AS-,ZZ 189.14.120.0/22 AS28282 -Reserved AS-,ZZ 189.14.124.0/22 AS28282 -Reserved AS-,ZZ 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.2.0/24 AS39408 THINKON-GUBOV - Think On, Inc.,CA 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.190.94.0/24 AS55293 A2HOSTING - A2 Hosting, Inc.,US 192.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.9.9.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd.,UA 194.247.58.0/24 AS52093 -Reserved AS-,ZZ 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.103.89.0/24 AS19523 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.59.208.0/20 AS26317 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.133.208.0/20 AS17440 IDNIC-ID Indonesia Network Information Center,ID 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.160.128.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 24 22:00:03 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Jul 2015 22:00:03 GMT Subject: BGP Update Report Message-ID: <201507242200.t6OM03gN095661@wattle.apnic.net> BGP Update Report Interval: 16-Jul-15 -to- 23-Jul-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 251302 6.4% 215.5 -- BSNL-NIB National Internet Backbone,IN 2 - AS22059 140461 3.6% 70230.5 -- -Reserved AS-,ZZ 3 - AS21669 123361 3.1% 123361.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 4 - AS11056 119655 3.0% 119655.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US 5 - AS36947 86974 2.2% 783.5 -- ALGTEL-AS,DZ 6 - AS54169 83684 2.1% 41842.0 -- MGH-ION-1 - Marin General Hospital,US 7 - AS3709 58718 1.5% 2174.7 -- NET-CITY-SA - City of San Antonio,US 8 - AS24138 39271 1.0% 1454.5 -- CRNET_BJ_IDC-CNNIC-AP China Tietong Telecommunication Corporation,CN 9 - AS25438 38494 1.0% 363.2 -- ASN-ICCNET International Computer Company, Ltd.,SA 10 - AS25563 38270 1.0% 12756.7 -- WEBLAND-AS Webland AG,CH 11 - AS131090 36658 0.9% 97.0 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 12 - AS7545 34929 0.9% 13.8 -- TPG-INTERNET-AP TPG Telecom Limited,AU 13 - AS28573 32453 0.8% 19.9 -- NET Servi?os de Comunica??o S.A.,BR 14 - AS45899 29233 0.7% 101.2 -- VNPT-AS-VN VNPT Corp,VN 15 - AS38197 28907 0.7% 27.5 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 16 - AS28024 26939 0.7% 17.2 -- Nuevatel PCS de Bolivia S.A.,BO 17 - AS59943 26889 0.7% 26889.0 -- RADAR-AS Radar LLC,RU 18 - AS30295 24786 0.6% 3098.2 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 19 - AS8402 24389 0.6% 133.3 -- CORBINA-AS OJSC "Vimpelcom",RU 20 - AS8151 22624 0.6% 27.2 -- Uninet S.A. de C.V.,MX TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS21669 123361 3.1% 123361.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - AS11056 119655 3.0% 119655.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US 3 - AS22059 140461 3.6% 70230.5 -- -Reserved AS-,ZZ 4 - AS54169 83684 2.1% 41842.0 -- MGH-ION-1 - Marin General Hospital,US 5 - AS59943 26889 0.7% 26889.0 -- RADAR-AS Radar LLC,RU 6 - AS25563 38270 1.0% 12756.7 -- WEBLAND-AS Webland AG,CH 7 - AS40637 12409 0.3% 12409.0 -- MAILROUTE - MailRoute, Inc.,US 8 - AS40493 10873 0.3% 10873.0 -- FACILITYSOURCEINC - FacilitySource,US 9 - AS14244 10365 0.3% 10365.0 -- NSIHOSTING-EQX-VA - NSI Hosting,US 10 - AS393588 9624 0.2% 9624.0 -- MUBEA-FLO - Mubea,US 11 - AS197914 5623 0.1% 5623.0 -- STOCKHO-AS Stockho Hosting SARL,FR 12 - AS26972 22286 0.6% 4457.2 -- SIRIUS-FIBER - Sirius Fiber, Inc.,US 13 - AS6629 7968 0.2% 3984.0 -- NOAA-AS - NOAA,US 14 - AS131112 3405 0.1% 3405.0 -- MMTC-AS-ID Sekolah Tinggi Multi Media "MMTC" Yogyakarta,ID 15 - AS56636 3359 0.1% 3359.0 -- ASVEDARU VEDA Ltd.,RU 16 - AS30295 24786 0.6% 3098.2 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 17 - AS38000 5791 0.1% 2895.5 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 18 - AS33440 11135 0.3% 2783.8 -- WEBRULON-NETWORK - webRulon, LLC,US 19 - AS6316 10163 0.3% 2540.8 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 20 - AS45606 12241 0.3% 2448.2 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.212.8.0/24 123361 3.0% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - 50.202.59.0/24 119655 2.9% AS11056 -- BERGERMONTAGUE - Berger & Montague, P.C,US 3 - 105.96.0.0/22 85288 2.1% AS36947 -- ALGTEL-AS,DZ 4 - 204.80.242.0/24 83678 2.0% AS54169 -- MGH-ION-1 - Marin General Hospital,US 5 - 64.34.125.0/24 70333 1.7% AS22059 -- -Reserved AS-,ZZ 6 - 76.191.107.0/24 70128 1.7% AS22059 -- -Reserved AS-,ZZ 7 - 61.7.155.0/24 35952 0.9% AS131090 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 8 - 185.65.148.0/24 26889 0.7% AS59943 -- RADAR-AS Radar LLC,RU 9 - 186.208.186.0/24 16367 0.4% AS262741 -- CONECTSUL - COMERCIO E SERVICOS LTDA,BR 10 - 92.43.216.0/21 12992 0.3% AS25563 -- WEBLAND-AS Webland AG,CH 11 - 185.84.192.0/22 12732 0.3% AS25563 -- WEBLAND-AS Webland AG,CH 12 - 178.174.96.0/19 12546 0.3% AS25563 -- WEBLAND-AS Webland AG,CH 13 - 199.89.0.0/21 12409 0.3% AS40637 -- MAILROUTE - MailRoute, Inc.,US 14 - 64.5.116.0/24 11607 0.3% AS26972 -- SIRIUS-FIBER - Sirius Fiber, Inc.,US 15 - 8.17.26.0/24 10873 0.3% AS40493 -- FACILITYSOURCEINC - FacilitySource,US 16 - 74.117.78.0/24 10409 0.2% AS26972 -- SIRIUS-FIBER - Sirius Fiber, Inc.,US 17 - 208.71.166.0/24 10365 0.2% AS14244 -- NSIHOSTING-EQX-VA - NSI Hosting,US 18 - 148.208.211.0/24 10206 0.2% AS8151 -- Uninet S.A. de C.V.,MX 19 - 66.19.194.0/24 10152 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 20 - 192.58.137.0/24 9624 0.2% AS393588 -- MUBEA-FLO - Mubea,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From baldur.norddahl at gmail.com Sat Jul 25 11:28:06 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 25 Jul 2015 13:28:06 +0200 Subject: FIB Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B013686BC6F@MSG6.westman.int> Message-ID: On 22 July 2015 at 06:51, William Herrin wrote: > The IPv4 BGP table has been growing by 10% to 15% per year since CIDR. > It appears to be a compounding curve, not linear. > > IPv4 exhaustion is a new factor which may or may not impact the next > 24 months' projection. There are arguments favoring a slower rate (no > more free pool). There are arguments favoring a faster rate > (fragmentation from address sales). No one has a crystal ball good > enough to know for sure -- the situation is literally unprecedented. > When will router vendors learn to do even simple aggregation before loading routes into FIB? It appears that most hardware will have plenty of FIB space if this was done. Also that aggregated routes are increasing at a slower pace. Regards, Baldur From shopik at inblock.ru Sat Jul 25 11:59:50 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Sat, 25 Jul 2015 14:59:50 +0300 Subject: FIB Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B013686BC6F@MSG6.westman.int> Message-ID: <9DDD5DB9-AE1D-4C1E-8D42-FCF803A5903C@inblock.ru> When de aggregation hit IPv6, with lot of /48 > On 25 ???? 2015 ?., at 14:28, Baldur Norddahl wrote: > >> On 22 July 2015 at 06:51, William Herrin wrote: >> >> The IPv4 BGP table has been growing by 10% to 15% per year since CIDR. >> It appears to be a compounding curve, not linear. >> >> IPv4 exhaustion is a new factor which may or may not impact the next >> 24 months' projection. There are arguments favoring a slower rate (no >> more free pool). There are arguments favoring a faster rate >> (fragmentation from address sales). No one has a crystal ball good >> enough to know for sure -- the situation is literally unprecedented. > > When will router vendors learn to do even simple aggregation before loading > routes into FIB? It appears that most hardware will have plenty of FIB > space if this was done. Also that aggregated routes are increasing at a > slower pace. > > Regards, > > Baldur From maxtul at netassist.ua Sat Jul 25 12:26:16 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Sat, 25 Jul 2015 15:26:16 +0300 Subject: BGP Update Report In-Reply-To: <201507242200.t6OM03gN095661@wattle.apnic.net> References: <201507242200.t6OM03gN095661@wattle.apnic.net> Message-ID: <55B38068.1010407@netassist.ua> Unassigned ASN is used and even is in top of the list? WTF?! On 25.07.15 01:00, cidr-report at potaroo.net wrote: > Rank ASN Upds % Upds/Pfx AS-Name > 2 - AS22059 140461 3.6% 70230.5 -- -Reserved AS-,ZZ From lists at sadiqs.com Sat Jul 25 15:05:33 2015 From: lists at sadiqs.com (Sadiq Saif) Date: Sat, 25 Jul 2015 11:05:33 -0400 Subject: BGP Update Report In-Reply-To: <55B38068.1010407@netassist.ua> References: <201507242200.t6OM03gN095661@wattle.apnic.net> <55B38068.1010407@netassist.ua> Message-ID: <55B3A5BD.1040106@sadiqs.com> On 7/25/2015 08:26, Max Tulyev wrote: > Unassigned ASN is used and even is in top of the list? WTF?! > > On 25.07.15 01:00, cidr-report at potaroo.net wrote: > >> Rank ASN Upds % Upds/Pfx AS-Name >> 2 - AS22059 140461 3.6% 70230.5 -- -Reserved AS-,ZZ > It appears it only recently became unassigned. The BGP update report from June 5 has the AS-Name: 3 - AS22059 118918 2.0% 16988.3 -- APVIO-1 - Apvio, Inc.,US So it became unassigned somewhere between June 5 and June 12 stats.ripe.net shows this AS has had large amounts of BGP update activity for the last 90 days. https://stat.ripe.net/AS22059#routing_routing-status.min_peers_seeing=0&routing_routing-status.resource=AS22059&tabId=routing -- Sadiq Saif (AS393949) https://staticsafe.ca From mkaipov at outlook.com Sat Jul 25 16:19:03 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Sat, 25 Jul 2015 19:19:03 +0300 Subject: Yandex DNS with Sophos antivirus blocking TrendMicro services Message-ID: Hello Guys. For 2 day I experience an issue with using my trendmicro software. For some reason web check didn't worked. I try to investigate this issue and found that yandex dns services blocking all trendmicro sites. I use yandex secure dns (dns.yandex.ru servers 77.88.8.8 and 77.88.8.2) for my home environment, which using Sophos antivirus for threat detection. If I change my dns server for another like google dns or some dns servers of my home ISP all works fine. Please if there some guys from yandex, Sophos or trendmicro help to resolve this issue. I'm very happy with my TrendMicro antivirus system and happy with yandex secure dns, but even Sophos or yandex blocking TrendMicro sites I and all peoples who use TrendMicro products and yandex dns can't use it anymore. Thank you. From bill at herrin.us Sat Jul 25 19:27:08 2015 From: bill at herrin.us (William Herrin) Date: Sat, 25 Jul 2015 15:27:08 -0400 Subject: FIB Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B013686BC6F@MSG6.westman.int> Message-ID: On Sat, Jul 25, 2015 at 7:28 AM, Baldur Norddahl wrote: > When will router vendors learn to do even simple aggregation before loading > routes into FIB? It appears that most hardware will have plenty of FIB > space if this was done. Also that aggregated routes are increasing at a > slower pace. Howdy, You can get a good reduction with FIB aggregation, but only upwards of 50% or so, and that only with the some pretty costly algorithms. Also, you tend to get better gains at the cheaper edge nodes rather than the more expensive core nodes. For now it's more cost effective to leave the code alone and just double the size of the TCAM. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From plucena at coopergeneral.com Sat Jul 25 20:19:49 2015 From: plucena at coopergeneral.com (Pablo Lucena) Date: Sat, 25 Jul 2015 16:19:49 -0400 Subject: FIB Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B013686BC6F@MSG6.westman.int> Message-ID: > > > > When will router vendors learn to do even simple aggregation before > loading > > routes into FIB? It appears that most hardware will have plenty of FIB > > space if this was done. Also that aggregated routes are increasing at a > > slower pace. > > Howdy, > > You can get a good reduction with FIB aggregation, but only upwards of > 50% or so, and that only with the some pretty costly algorithms. Also, > you tend to get better gains at the cheaper edge nodes rather than the > more expensive core nodes. For now it's more cost effective to leave > the code alone and just double the size of the TCAM. > > Regards, > Bill Herrin > > ?There are also features such as Selective RIB Download (or its equivalent in other vendors) which help out in different portions of the network.? Definitely not applicable to all router types though. From randy at psg.com Sun Jul 26 06:27:56 2015 From: randy at psg.com (Randy Bush) Date: Sun, 26 Jul 2015 08:27:56 +0200 Subject: FIB Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B013686BC6F@MSG6.westman.int> Message-ID: http://route-aggregation.net/ From glen.kent at gmail.com Mon Jul 27 14:12:46 2015 From: glen.kent at gmail.com (Glen Kent) Date: Mon, 27 Jul 2015 19:42:46 +0530 Subject: UDP clamped on service provider links Message-ID: Hi, Is it true that UDP is often subjected to stiffer rate limits than TCP? Is there a reason why this is often done so? Is this because UDP is stateless and any script kiddie could launch a DOS attack with a UDP stream? Given the state of affairs these days how difficult is it going to be for somebody to launch a DOS attack with some other protocol? Glen From morrowc.lists at gmail.com Mon Jul 27 14:19:22 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 27 Jul 2015 10:19:22 -0400 Subject: UDP clamped on service provider links In-Reply-To: References: Message-ID: On Mon, Jul 27, 2015 at 10:12 AM, Glen Kent wrote: > Hi, > > Is it true that UDP is often subjected to stiffer rate limits than TCP? Is I hear tell that some folk are engaging in this practice... You might have seen this hear little ditty: you may have also put your ear to the tracks and seen a bunch of kids using these 'you-dee-pee en-tee-pee' packets to fill up the tubes across the lands... Sometimes they use not just 'en-tee-pee', but also that old hoary bastard 'dee-en-ess' for their no good traffic backup propositions. > there a reason why this is often done so? Is this because UDP is stateless > and any script kiddie could launch a DOS attack with a UDP stream? I understand, and I'm new hear so bear with me, that there are you-dee-pee services out there in the hinterlands which will say a whole lot more to you than you said to them... like your worst nightmare when it comes to smalltalk. > Given the state of affairs these days how difficult is it going to be for > somebody to launch a DOS attack with some other protocol? > not very hard at all... but here's your lipstick and there's the pig... :) From dovid at telecurve.com Mon Jul 27 15:32:27 2015 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 27 Jul 2015 11:32:27 -0400 Subject: DDOS Simulation Message-ID: Hi All, We are looking into a few different DDOS solutions for a client. We need a LEGITIMATE company that can simulate some DDOS attacks (the generic + specific to the clients business). Anyone have any recommendations? Regards, Dovid From drohan at gmail.com Mon Jul 27 16:31:21 2015 From: drohan at gmail.com (Daniel Rohan) Date: Mon, 27 Jul 2015 09:31:21 -0700 Subject: DDOS Simulation In-Reply-To: References: Message-ID: Looking for similar here. -Dan On Mon, Jul 27, 2015 at 8:32 AM, Dovid Bender wrote: > Hi All, > > We are looking into a few different DDOS solutions for a client. We need a > LEGITIMATE company that can simulate some DDOS attacks (the generic + > specific to the clients business). Anyone have any recommendations? > > Regards, > > Dovid > From sysoleg at yandex.ru Mon Jul 27 17:37:12 2015 From: sysoleg at yandex.ru (Oleg A. Arkhangelsky) Date: Mon, 27 Jul 2015 20:37:12 +0300 Subject: Yandex DNS with Sophos antivirus blocking TrendMicro services In-Reply-To: References: Message-ID: <220821438018632@web27h.yandex.ru> 25.07.2015, 19:21, "Murat Kaipov" : > Hello Guys. > > For 2 day I experience an issue with using my trendmicro software. For some > reason web check didn't worked. I try to investigate this issue and found > that yandex dns services blocking all trendmicro sites. I use yandex secure > dns (dns.yandex.ru servers 77.88.8.8 and 77.88.8.2) for my home environment, > which using Sophos antivirus for threat detection. If I change my dns > server for another like google dns or some dns servers of my home ISP all > works fine. > > Please if there some guys from yandex, Sophos or trendmicro help to resolve > this issue. I'm very happy with my TrendMicro antivirus system and happy > with yandex secure dns, but even Sophos or yandex blocking TrendMicro sites > I and all peoples who use TrendMicro products and yandex dns can't use it > anymore. > It will be more efficient, if you report this issue here: https://feedback2.yandex.ru/dns/ -- wbr, Oleg. "Anarchy is about taking complete responsibility for yourself." ????? Alan Moore. From rps at maine.edu Mon Jul 27 19:56:58 2015 From: rps at maine.edu (Ray Soucy) Date: Mon, 27 Jul 2015 15:56:58 -0400 Subject: UDP clamped on service provider links In-Reply-To: References: Message-ID: "It depends on the network." is really the only answer. It's the kind of thing that happens quietly and often can be transient in nature (e.g. temporary "big stick" filters to deal with an active attack). As far as the reason it happens to UDP: UDP is a challenge because it's easy to leverage for reflection attacks where the source IP is spoofed to be the target. The major targets are small services that are typically left open on host systems. The big ones being NTP, DNS, and more recently SSDP (universal plug and play left open on consumer routers). Once in a while you see some really old protocols open like CHARGEN, but these are less common. The ones like NTP and DNS are popular because a small request can trigger a large response (e.g. amplification attack) if services are not appropriately locked down on the host. A while back a big one a lot of people were caught off guard by was the NTP MONLIST function which resulted in up to a 500:1 amplification. Hopefully rate limiting UDP traffic is something that doesn't happen often, and when people do rate-limit it they ideally limit the scope to known problem protocols (like NTP and DNS) and base limits such that normal use shouldn't be a problem. That said I'm sure there are some who just rate-limit everything (likely arguing that UDP is "mostly peer-to-peer anyway"). It's a bad practice no doubt. TCP is still vulnerable to some level of reflection, but these are generally easy to mitigate, and because the setup and teardown for TCP is so small, not very effective for denial of service. There isn't much that happens traffic-wise until the source address has confirmed a connection which is what avoids spoofing being as big of a problem with TCP as it is for UDP. Similarly ICMP is generally not a problem because ICMP responses are small by design. On Mon, Jul 27, 2015 at 10:12 AM, Glen Kent wrote: > Hi, > > Is it true that UDP is often subjected to stiffer rate limits than TCP? Is > there a reason why this is often done so? Is this because UDP is stateless > and any script kiddie could launch a DOS attack with a UDP stream? > > Given the state of affairs these days how difficult is it going to be for > somebody to launch a DOS attack with some other protocol? > > Glen > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From nanogml at Mail.DDoS-Mitigator.net Mon Jul 27 20:25:06 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Mon, 27 Jul 2015 13:25:06 -0700 Subject: DDOS Simulation In-Reply-To: References: Message-ID: <20150727202506.GA12870@Mail.DDoS-Mitigator.net> hi dovid On 07/27/15 at 11:32am, Dovid Bender wrote: > We are looking into a few different DDOS solutions for a client. We need a > LEGITIMATE company that can simulate some DDOS attacks (the generic + > specific to the clients business). Anyone have any recommendations? i've compiled a fairly comprehensive list is here: - http://ddos-mitigator.net/Competitors simulating ddos attacks are fairly easy to do, except one does have to be careful of process and proceedure and the all important "get out of jail for free" card ( let your local ISP techie's know too ) http://DDoS-Simulator.net/Demo ( wrapper gui around *perf/nc/nmap/*ping command options ) ddos mitigation is not a "single thing-a-ma-jig", and should be multi-layered, different solutions solving different DDoS issues http://ddos-solutions.net/Mitigation/#Howto - how are they attacking - who is attacking ( script kiddie vs master of deception ) - what are they attacking - when are they attacking - why are they attacking - ... # --------------------------------------------- # what kind of simulations are you trying to do ?? # --------------------------------------------- - volumetric attacks say 10gigabit vs 200gigabit attacks is trivial - ping flood, udp flood, arp flood, tcp flood, etc, etc local appliances with 10/100 gigabit NIC cards should be able to generate close to 100 gigabit/sec of ddos attacks - udp and icmp attacks are harder to mitigate, since those packets need to be stopped at the ISP .... if it came down the wire to the local offices, it already used the bandwidth, cpu, memory, time, people, etc, etc - tcp-based ddos attacks are trivial ( imho ) to defend against with iptables + tarpits if each tcp connection takes 2K bytes, the DDoS attacker that is intent on sending large quantity of tcp-based packets would incur a counter ddos attack using up its own kernel memory 100,000 tcp packet/sec * 2K byte --> 200M /sec of kernel memory ?? with tcp timeout of 2 minutes implies they'd need 24TB of ?? kernel memory to sustain a 100,000 tcp packet/sec attack # live demo of tarpit incoming ddos attacks http://ddos-mitigator.net/cgi-bin/IPtables-GUI.pl http://target-practice.net/cgi-bin/IPtables-GUI.pl # command line options is 100x faster and easier than html # to automatically add new incoming ddos attackers iptables-gui -doadd -addauto # to automatically remove inactive ddos attackers iptables-gui -dodel -deluto ssh based solutions are nice but only works on port 22 http based solutions are nice but only works on port 80 there are 65,533 other ports to defend against DDoS attacks which is defensible with tarpit - it is trivial to generate attacks against apache or web browser - it is trivial to generate attacks against sendmail or mail reader - netcat/socat/nc, hping*, nping, etc, etc - something that you can define source and destination IP# - something that you can define source and destination port# - it is harder to generate the various malformed tcp headers - gui to help set tcp header flags and options for nmap/hping - http://ddos-simulator.net/Demo/ - spam, virii and worms seems to be in its own category - another important question for your clients is if they are under any govermental regulations which will limit their choices of solutions - hippa, pci, sox, etc inhouse ddos solutions should not have any governmental compliance issues cloud based ddos solutions and their facilities would have to comply with the various govermental issues both inhouse and cloud based solutions solve some problems another 32+ point comparison for inhouse vs cloud based solutions - http://ddos-mitigator.net/InHouse-vs-Cloud thanx alvin - http://ddos-mitigator.net - http://ddos-simulator.net From pavel.odintsov at gmail.com Mon Jul 27 20:32:56 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 27 Jul 2015 23:32:56 +0300 Subject: DDOS Simulation In-Reply-To: <20150727202506.GA12870@Mail.DDoS-Mitigator.net> References: <20150727202506.GA12870@Mail.DDoS-Mitigator.net> Message-ID: Hello! I would like to recommend MoonGen for generating very high speed attacks (I have generated up to 56 mpps/40GE with it). There are another open project: quezstresser.com On Mon, Jul 27, 2015 at 11:25 PM, alvin nanog wrote: > > hi dovid > > On 07/27/15 at 11:32am, Dovid Bender wrote: >> We are looking into a few different DDOS solutions for a client. We need a >> LEGITIMATE company that can simulate some DDOS attacks (the generic + >> specific to the clients business). Anyone have any recommendations? > > i've compiled a fairly comprehensive list is here: > > - http://ddos-mitigator.net/Competitors > > simulating ddos attacks are fairly easy to do, except one does > have to be careful of process and proceedure and the all important > "get out of jail for free" card ( let your local ISP techie's know too ) > > http://DDoS-Simulator.net/Demo > ( wrapper gui around *perf/nc/nmap/*ping command options ) > > ddos mitigation is not a "single thing-a-ma-jig", and should > be multi-layered, different solutions solving different DDoS issues > > http://ddos-solutions.net/Mitigation/#Howto > - how are they attacking > - who is attacking ( script kiddie vs master of deception ) > - what are they attacking > - when are they attacking > - why are they attacking > - ... > > # --------------------------------------------- > # what kind of simulations are you trying to do ?? > # --------------------------------------------- > - volumetric attacks say 10gigabit vs 200gigabit attacks is trivial > - ping flood, udp flood, arp flood, tcp flood, etc, etc > > local appliances with 10/100 gigabit NIC cards should be able to > generate close to 100 gigabit/sec of ddos attacks > > - udp and icmp attacks are harder to mitigate, since those packets > need to be stopped at the ISP .... if it came down the wire to > the local offices, it already used the bandwidth, cpu, memory, > time, people, etc, etc > > - tcp-based ddos attacks are trivial ( imho ) to defend against with > iptables + tarpits > if each tcp connection takes 2K bytes, the DDoS attacker > that is intent on sending large quantity of tcp-based packets > would incur a counter ddos attack using up its own kernel > memory > > 100,000 tcp packet/sec * 2K byte --> 200M /sec of kernel memory > > ?? with tcp timeout of 2 minutes implies they'd need 24TB of > ?? kernel memory to sustain a 100,000 tcp packet/sec attack > > # live demo of tarpit incoming ddos attacks > http://ddos-mitigator.net/cgi-bin/IPtables-GUI.pl > http://target-practice.net/cgi-bin/IPtables-GUI.pl > > # command line options is 100x faster and easier than html > > # to automatically add new incoming ddos attackers > iptables-gui -doadd -addauto > > # to automatically remove inactive ddos attackers > iptables-gui -dodel -deluto > > ssh based solutions are nice but only works on port 22 > http based solutions are nice but only works on port 80 > > there are 65,533 other ports to defend against DDoS attacks > which is defensible with tarpit > > - it is trivial to generate attacks against apache or web browser > - it is trivial to generate attacks against sendmail or mail reader > > - netcat/socat/nc, hping*, nping, etc, etc > - something that you can define source and destination IP# > - something that you can define source and destination port# > > - it is harder to generate the various malformed tcp headers > > - gui to help set tcp header flags and options for nmap/hping > - http://ddos-simulator.net/Demo/ > > - spam, virii and worms seems to be in its own category > > - another important question for your clients is if they are under > any govermental regulations which will limit their choices of solutions > - hippa, pci, sox, etc > > inhouse ddos solutions should not have any governmental compliance > issues > > cloud based ddos solutions and their facilities would have to > comply with the various govermental issues > > both inhouse and cloud based solutions solve some problems > > another 32+ point comparison for inhouse vs cloud based solutions > - http://ddos-mitigator.net/InHouse-vs-Cloud > > thanx > alvin > - http://ddos-mitigator.net > - http://ddos-simulator.net > -- Sincerely yours, Pavel Odintsov From Valdis.Kletnieks at vt.edu Mon Jul 27 20:59:21 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 27 Jul 2015 16:59:21 -0400 Subject: DDOS Simulation In-Reply-To: Your message of "Mon, 27 Jul 2015 23:32:56 +0300." References: <20150727202506.GA12870@Mail.DDoS-Mitigator.net> Message-ID: <116949.1438030761@turing-police.cc.vt.edu> On Mon, 27 Jul 2015 23:32:56 +0300, Pavel Odintsov said: > I would like to recommend MoonGen for generating very high speed > attacks (I have generated up to 56 mpps/40GE with it). OK, I'll bite - what hardware were you using to inject that many packets? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From pavel.odintsov at gmail.com Mon Jul 27 21:02:44 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 28 Jul 2015 00:02:44 +0300 Subject: DDOS Simulation In-Reply-To: <116949.1438030761@turing-police.cc.vt.edu> References: <20150727202506.GA12870@Mail.DDoS-Mitigator.net> <116949.1438030761@turing-police.cc.vt.edu> Message-ID: Hello! It's poor man's traffic generator :) My test lab is i7 2600 with 2 port Intel X520 10GE and Intel Xeon E5 2604 witj 2 port Intel X520 10GE. On Mon, Jul 27, 2015 at 11:59 PM, wrote: > On Mon, 27 Jul 2015 23:32:56 +0300, Pavel Odintsov said: > >> I would like to recommend MoonGen for generating very high speed >> attacks (I have generated up to 56 mpps/40GE with it). > > OK, I'll bite - what hardware were you using to inject that many packets? -- Sincerely yours, Pavel Odintsov From nanogml at Mail.DDoS-Mitigator.net Mon Jul 27 21:36:00 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Mon, 27 Jul 2015 14:36:00 -0700 Subject: DDOS Simulation In-Reply-To: References: <20150727202506.GA12870@Mail.DDoS-Mitigator.net> <116949.1438030761@turing-police.cc.vt.edu> Message-ID: <20150727213600.GA14577@Mail.DDoS-Mitigator.net> hi pavel On 07/28/15 at 12:02am, Pavel Odintsov wrote: > It's poor man's traffic generator :) that's the best kind :-) as long as it gets the job done and you get to control what it does > My test lab is i7 2600 with 2 port Intel X520 10GE and Intel Xeon E5 > 2604 witj 2 port Intel X520 10GE. nice cpu hw trick questions for those thinking of generating ddos traffic for testing - ?? how much memory was needed to run the traffic generator i assume around 1GB of memory for 1gigE interface and i still can purposely run out of memory while some apps are running at 10gigE pci card, you'd probably want at least 12GB - 16GB of memory - some "poor mans apps" to generate traffic ... start w/ nping or hping # generate 1,000 Mbit/sec of junk .. floodig is trivial ... ping -i 0.001 -s 2000 victimIP# nping --data-length 2000 --rate 1000 victimIP# socat iperf ... # # generate udp or icmp or arp or tcp traffic # # add options to generate large-sized packets # add options to generate 10Gbit/sec ( number of packet/sec ) # # play around with tcp headers # add options to send MTU=1501 byte but NOT set DF # add options to send ACK but no request # # add options to spoof source and desitination address and ports # # if the host machine become un-available, you've got a problem # for host in gw dns ntp http smtp for protocol in arp icmp udp tcp nping --protocol [ options ] host.example.com # hping is nice too done done # for bonus arp fun ... attacker# arpspoof gateway victim attacker# arpspoof victim gateway # prevent mitm with: use hard coded arp "/etc/ethers" for linux use OpenSSL certs to flag a warning when "attacker" inserted itself in between gateway and un-aware victim pixie dust alvin - DDoS-Mitigator.net > On Mon, Jul 27, 2015 at 11:59 PM, wrote: > > On Mon, 27 Jul 2015 23:32:56 +0300, Pavel Odintsov said: > > > >> I would like to recommend MoonGen for generating very high speed > >> attacks (I have generated up to 56 mpps/40GE with it). > > > > OK, I'll bite - what hardware were you using to inject that many packets? From lobna_gouda at hotmail.com Mon Jul 27 21:40:49 2015 From: lobna_gouda at hotmail.com (lobna gouda) Date: Mon, 27 Jul 2015 21:40:49 +0000 Subject: DDOS Simulation In-Reply-To: References: , Message-ID: Hello David et Dan, Are you going to perform the DDOS solution yourself, or you are looking for a company to provide a solution for you. Some companies perform an attack simulation for you before buying the product > From: drohan at gmail.com > Date: Mon, 27 Jul 2015 09:31:21 -0700 > Subject: Re: DDOS Simulation > To: dovid at telecurve.com > CC: nanog at nanog.org > > Looking for similar here. > > -Dan > > On Mon, Jul 27, 2015 at 8:32 AM, Dovid Bender wrote: > > > Hi All, > > > > We are looking into a few different DDOS solutions for a client. We need a > > LEGITIMATE company that can simulate some DDOS attacks (the generic + > > specific to the clients business). Anyone have any recommendations? > > > > Regards, > > > > Dovid > > From ammar at fastreturn.net Mon Jul 27 22:06:43 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Tue, 28 Jul 2015 02:06:43 +0400 Subject: DDOS Simulation In-Reply-To: References: Message-ID: I've seen people push close to 10Gbps line rate with 1 byte packets on an Intel card with PF_RING. > On 28 Jul 2015, at 1:40 am, lobna gouda wrote: > > Hello David et Dan, > Are you going to perform the DDOS solution yourself, or you are looking for a company to provide a solution for you. Some companies perform an attack simulation for you before buying the product > >> From: drohan at gmail.com >> Date: Mon, 27 Jul 2015 09:31:21 -0700 >> Subject: Re: DDOS Simulation >> To: dovid at telecurve.com >> CC: nanog at nanog.org >> >> Looking for similar here. >> >> -Dan >> >>> On Mon, Jul 27, 2015 at 8:32 AM, Dovid Bender wrote: >>> >>> Hi All, >>> >>> We are looking into a few different DDOS solutions for a client. We need a >>> LEGITIMATE company that can simulate some DDOS attacks (the generic + >>> specific to the clients business). Anyone have any recommendations? >>> >>> Regards, >>> >>> Dovid > From me at anuragbhatia.com Mon Jul 27 22:06:38 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 28 Jul 2015 03:36:38 +0530 Subject: ATT wireless IPv6 In-Reply-To: <3627BB47-6B49-4F42-9165-45FA19D7EFD3@puck.nether.net> References: <55A6DEDE.2090701@NEEBU.Net> <3627BB47-6B49-4F42-9165-45FA19D7EFD3@puck.nether.net> Message-ID: Hi Jared I am curious on prefix size of routed block. Is that a /64 routed prefix? How well it works with Android tethering? On Thu, Jul 16, 2015 at 4:03 AM, Jared Mauch wrote: > > > On Jul 15, 2015, at 6:29 PM, Jake Khuon wrote: > > > > On 15/07/15 04:54, Jared Mauch wrote: > >> Does anyone know what the story is here? They have some transparent > proxies for IPv4 traffic and I was wondering if they were to be IPv6 > enabled soon or if IPv6 will reach the handset. > > > > Hmmm... I'm seeing my rmnet1 interface on my Galaxy S5 as having an > > address out of the 2600:380:46ae::/38 space which is allocated to AT&T > > Mobility. > > I exchanged a few emails earlier today with someone and it seems to depend > on your APN. If you have the VoLTE APN on your device you can get IPv6, > including when tethering. The APN you want is nxtgenphone. > > If you have a device where you can not edit the APN settings (iPhone) you > can not use the IPv6 enabled VoLTE APN. > > I suspect this will be enabled if they launch VoLTE on the iPhone. > > - Jared -- Anurag Bhatia anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From pavel.odintsov at gmail.com Tue Jul 28 07:15:45 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 28 Jul 2015 10:15:45 +0300 Subject: DDOS Simulation In-Reply-To: <20150727213600.GA14577@Mail.DDoS-Mitigator.net> References: <20150727202506.GA12870@Mail.DDoS-Mitigator.net> <116949.1438030761@turing-police.cc.vt.edu> <20150727213600.GA14577@Mail.DDoS-Mitigator.net> Message-ID: Hello! My machines have 16GB of memory but traffic generator uses about ~1GB of memory for 10GE link. On Tue, Jul 28, 2015 at 12:36 AM, alvin nanog wrote: > > hi pavel > > On 07/28/15 at 12:02am, Pavel Odintsov wrote: >> It's poor man's traffic generator :) > > that's the best kind :-) > as long as it gets the job done and you get to control what it does > >> My test lab is i7 2600 with 2 port Intel X520 10GE and Intel Xeon E5 >> 2604 witj 2 port Intel X520 10GE. > > nice cpu hw > > trick questions for those thinking of generating ddos traffic for testing > > - ?? how much memory was needed to run the traffic generator > > i assume around 1GB of memory for 1gigE interface and i still > can purposely run out of memory while some apps are running > > at 10gigE pci card, > you'd probably want at least 12GB - 16GB of memory > > - some "poor mans apps" to generate traffic ... start w/ nping or hping > > # generate 1,000 Mbit/sec of junk .. floodig is trivial ... > ping -i 0.001 -s 2000 victimIP# > nping --data-length 2000 --rate 1000 victimIP# > socat > iperf ... > # > # generate udp or icmp or arp or tcp traffic > # > # add options to generate large-sized packets > # add options to generate 10Gbit/sec ( number of packet/sec ) > # > # play around with tcp headers > # add options to send MTU=1501 byte but NOT set DF > # add options to send ACK but no request > # > # add options to spoof source and desitination address and ports > > # > # if the host machine become un-available, you've got a problem > # > for host in gw dns ntp http smtp > for protocol in arp icmp udp tcp > nping --protocol [ options ] host.example.com > # hping is nice too > done > done > > # for bonus arp fun ... > attacker# arpspoof gateway victim > attacker# arpspoof victim gateway > > # prevent mitm with: use hard coded arp "/etc/ethers" for linux > > use OpenSSL certs to flag a warning when "attacker" inserted > itself in between gateway and un-aware victim > > pixie dust > alvin > - DDoS-Mitigator.net > >> On Mon, Jul 27, 2015 at 11:59 PM, wrote: >> > On Mon, 27 Jul 2015 23:32:56 +0300, Pavel Odintsov said: >> > >> >> I would like to recommend MoonGen for generating very high speed >> >> attacks (I have generated up to 56 mpps/40GE with it). >> > >> > OK, I'll bite - what hardware were you using to inject that many packets? -- Sincerely yours, Pavel Odintsov From pavel.odintsov at gmail.com Tue Jul 28 07:16:05 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 28 Jul 2015 10:16:05 +0300 Subject: DDOS Simulation In-Reply-To: References: Message-ID: Yep, it's definitely possible. I have done this with netmap/PF_RING/DPDK and SnabbSwitch. On Tue, Jul 28, 2015 at 1:06 AM, Ammar Zuberi wrote: > I've seen people push close to 10Gbps line rate with 1 byte packets on an Intel card with PF_RING. > >> On 28 Jul 2015, at 1:40 am, lobna gouda wrote: >> >> Hello David et Dan, >> Are you going to perform the DDOS solution yourself, or you are looking for a company to provide a solution for you. Some companies perform an attack simulation for you before buying the product >> >>> From: drohan at gmail.com >>> Date: Mon, 27 Jul 2015 09:31:21 -0700 >>> Subject: Re: DDOS Simulation >>> To: dovid at telecurve.com >>> CC: nanog at nanog.org >>> >>> Looking for similar here. >>> >>> -Dan >>> >>>> On Mon, Jul 27, 2015 at 8:32 AM, Dovid Bender wrote: >>>> >>>> Hi All, >>>> >>>> We are looking into a few different DDOS solutions for a client. We need a >>>> LEGITIMATE company that can simulate some DDOS attacks (the generic + >>>> specific to the clients business). Anyone have any recommendations? >>>> >>>> Regards, >>>> >>>> Dovid >> > -- Sincerely yours, Pavel Odintsov From fergdawgster at mykolab.com Tue Jul 28 16:37:54 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 28 Jul 2015 09:37:54 -0700 Subject: Yandex DNS with Sophos antivirus blocking TrendMicro services In-Reply-To: <220821438018632@web27h.yandex.ru> References: <220821438018632@web27h.yandex.ru> Message-ID: <55B7AFE2.5030008@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks for that -- luckily, this issue has been fixed. Cheers, - - ferg On 7/27/2015 10:37 AM, Oleg A. Arkhangelsky wrote: > > > 25.07.2015, 19:21, "Murat Kaipov" : >> Hello Guys. >> >> For 2 day I experience an issue with using my trendmicro >> software. For some reason web check didn't worked. I try to >> investigate this issue and found that yandex dns services >> blocking all trendmicro sites. I use yandex secure dns >> (dns.yandex.ru servers 77.88.8.8 and 77.88.8.2) for my home >> environment, which using Sophos antivirus for threat detection. >> If I change my dns server for another like google dns or some dns >> servers of my home ISP all works fine. >> >> Please if there some guys from yandex, Sophos or trendmicro help >> to resolve this issue. I'm very happy with my TrendMicro >> antivirus system and happy with yandex secure dns, but even >> Sophos or yandex blocking TrendMicro sites I and all peoples who >> use TrendMicro products and yandex dns can't use it anymore. >> > > It will be more efficient, if you report this issue here: > > https://feedback2.yandex.ru/dns/ > > -- wbr, Oleg. > > "Anarchy is about taking complete responsibility for yourself." > Alan Moore. > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlW3r+EACgkQKJasdVTchbLmuAEAhUYZUBE2KtIqoyKZmZmb2svp NTBKe3jCyYdYOfwkr+MBAIgDqQ97YzIgsWPv/aqzzPF7P3NsAC8mD6/VeJhbSJTb =9qfw -----END PGP SIGNATURE----- From dovid at telecurve.com Tue Jul 28 18:31:18 2015 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 28 Jul 2015 14:31:18 -0400 Subject: DDOS Simulation In-Reply-To: References: Message-ID: We are looking for a company that can launch a DDOS attack against the solutions we are testing. I don't want a proof of concept from the company that will be offering DDOS protection since they can simulate an easy attack and then mitigate. I want whom ever we go with to be able to handle what ever is thrown at them. On Mon, Jul 27, 2015 at 5:40 PM, lobna gouda wrote: > Hello David et Dan, > > Are you going to perform the DDOS solution yourself, or you are looking > for a company to provide a solution for you. Some companies perform an > attack simulation for you before buying the product > > > From: drohan at gmail.com > > Date: Mon, 27 Jul 2015 09:31:21 -0700 > > Subject: Re: DDOS Simulation > > To: dovid at telecurve.com > > CC: nanog at nanog.org > > > > > Looking for similar here. > > > > -Dan > > > > On Mon, Jul 27, 2015 at 8:32 AM, Dovid Bender > wrote: > > > > > Hi All, > > > > > > We are looking into a few different DDOS solutions for a client. We > need a > > > LEGITIMATE company that can simulate some DDOS attacks (the generic + > > > specific to the clients business). Anyone have any recommendations? > > > > > > Regards, > > > > > > Dovid > > > > From contact at winterei.se Tue Jul 28 18:41:15 2015 From: contact at winterei.se (Paul S.) Date: Wed, 29 Jul 2015 03:41:15 +0900 Subject: DDOS Simulation In-Reply-To: References: Message-ID: <55B7CCCB.6090705@winterei.se> Seeing as the 'traditional' ways to launch big DDoS attacks are illegal, and you're after a 'legit' company to offer this... Yeah, I don't think you'll get too far. You'll either have to roll your own testsuite on a lan environment, or ... On 29/7/2015 3:31 AM, Dovid Bender wrote: > We are looking for a company that can launch a DDOS attack against the > solutions we are testing. I don't want a proof of concept from the company > that will be offering DDOS protection since they can simulate an easy > attack and then mitigate. I want whom ever we go with to be able to handle > what ever is thrown at them. > > > On Mon, Jul 27, 2015 at 5:40 PM, lobna gouda > wrote: > >> Hello David et Dan, >> >> Are you going to perform the DDOS solution yourself, or you are looking >> for a company to provide a solution for you. Some companies perform an >> attack simulation for you before buying the product >> >>> From: drohan at gmail.com >>> Date: Mon, 27 Jul 2015 09:31:21 -0700 >>> Subject: Re: DDOS Simulation >>> To: dovid at telecurve.com >>> CC: nanog at nanog.org >>> Looking for similar here. >>> >>> -Dan >>> >>> On Mon, Jul 27, 2015 at 8:32 AM, Dovid Bender >> wrote: >>>> Hi All, >>>> >>>> We are looking into a few different DDOS solutions for a client. We >> need a >>>> LEGITIMATE company that can simulate some DDOS attacks (the generic + >>>> specific to the clients business). Anyone have any recommendations? >>>> >>>> Regards, >>>> >>>> Dovid >>>> From nick at flhsi.com Tue Jul 28 20:45:24 2015 From: nick at flhsi.com (Nick Olsen) Date: Tue, 28 Jul 2015 16:45:24 -0400 Subject: Windows 10 Release Message-ID: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Anyone anxious to see what kind of traffic comes from Windows 10 releasing tomorrow? Being a 3-4GB download. Each device is moving more data than any Apple update ever did. Wonder if they'll stage the release as apple appeared to have learned after IOS7 hammered a bunch of networks. Nick Olsen Network Operations (855) FLSPEED x106 From nick at flhsi.com Tue Jul 28 20:52:55 2015 From: nick at flhsi.com (Nick Olsen) Date: Tue, 28 Jul 2015 16:52:55 -0400 Subject: Windows 10 Release In-Reply-To: References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <42698067eecd45ed87e8295482fcfc6e@flhsi.com> Good to know. I was one of those insiders, And it's running on my laptop currently. It got the 10240 build a bit ago. Which removed the "insider preview" water marks, And appears to be the full release version.. So it would appear the "insiders" already have it. Or the ability to get it. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Justin Mckillican" Sent: Tuesday, July 28, 2015 4:49 PM To: nick at flhsi.com, "nanog at nanog.org list" Subject: Re: Windows 10 Release For upgraders I believe only 5 million 'Insiders' that tested Windows 10 will get it tomorrow. The rest of the free upgraders (those from Win7 and Win8) will get it over the next two weeks at different times with the priority going to those that 'reserved' it in Windows Update tool. -justin > On Jul 28, 2015, at 4:45 PM, Nick Olsen wrote: > > Anyone anxious to see what kind of traffic comes from Windows 10 releasing > tomorrow? > > Being a 3-4GB download. Each device is moving more data than any Apple > update ever did. > > Wonder if they'll stage the release as apple appeared to have learned > after IOS7 hammered a bunch of networks. > > Nick Olsen > Network Operations (855) FLSPEED x106 > From kmedcalf at dessus.com Tue Jul 28 21:26:56 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 28 Jul 2015 17:26:56 -0400 Subject: Windows 10 Release In-Reply-To: <42698067eecd45ed87e8295482fcfc6e@flhsi.com> Message-ID: <0165b6a7e2ab8c4b880bf9a526b1bc50@mail.dessus.com> > Good to know. > > I was one of those insiders, And it's running on my laptop currently. It > got the 10240 build a bit ago. Which removed the "insider preview" water > marks, And appears to be the full release version.. So it would appear the > "insiders" already have it. Or the ability to get it. But that of course is for your non-production "messing about with nothing serious and don't mind sending all my passwords and data to microsoft and using a completely insecure microsoft account" installation. Roll-out to "Production" will not occur until tomorrow -- July 29th -- whatever microsoft's definition of July 29 happens to be. Depending on your interpretation of "on" and timezone, release "on" July 29th can commence during any of the 47.999999 hours during which July 29th occurs. > Nick Olsen > Network Operations (855) FLSPEED x106 From niels=nanog at bakker.net Tue Jul 28 22:04:04 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 29 Jul 2015 00:04:04 +0200 Subject: Windows 10 Release In-Reply-To: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <20150728220404.GA4116@excession.tpb.net> * nick at flhsi.com (Nick Olsen) [Tue 28 Jul 2015, 22:46 CEST]: >Being a 3-4GB download. Each device is moving more data than any Apple >update ever did. I'm not so sure of that. The 10.9 install image clocked in at 4.9 GB, and the Mac App Store for 10.10 Yosemite says "Size: 5.67 GB"; http://www.microsoft.com/en-us/windows/features says "3GB download required" in the small print at the bottom. -- Niels. From askoorb+nanog at gmail.com Tue Jul 28 22:08:38 2015 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Tue, 28 Jul 2015 23:08:38 +0100 Subject: Windows 10 Release In-Reply-To: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: Hi, On Tue, Jul 28, 2015 at 9:45 PM, Nick Olsen wrote: > > Anyone anxious to see what kind of traffic comes from Windows 10 releasing > tomorrow? > > Being a 3-4GB download. Each device is moving more data than any Apple > update ever did. > > Wonder if they'll stage the release as apple appeared to have learned > after IOS7 hammered a bunch of networks. I don't have the reference to hand (though I have seen it), but yes. Notifications inviting people to download the upgrade will be rolled out *starting* 29th July to people who have 'reserved' the upgrade - the notification will only appear for everyone over a few days. People who really want to go download the thing manually should be able to from the launch date of course by going to the website. Hopefully this means that the network load should not be too great, as long as they don't 'pick' people to receive the notification by AS number. But, the only way to know for sure is to see what happens tomorrow. Here's hoping it doesn't overload any major links. Alex From nanogml at Mail.DDoS-Mitigator.net Tue Jul 28 22:19:41 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Tue, 28 Jul 2015 15:19:41 -0700 Subject: DDOS Simulation In-Reply-To: References: Message-ID: <20150728221940.GA25835@Mail.DDoS-Mitigator.net> hi dovid On 07/28/15 at 02:31pm, Dovid Bender wrote: > We are looking for a company that can launch a DDOS attack against the > solutions we are testing. I don't want a proof of concept from the company > that will be offering DDOS protection since they can simulate an easy > attack and then mitigate. I want whom ever we go with to be able to handle > what ever is thrown at them. most all ddos simulator folks all sell their own version of a ddos mitigator appliance or ddos cloud services ... both has good and bad ddos mitigation features depending on the type of DDoS attacks you are defending against http://DDoS-Mitigator.net/Competitors - largest folks ( aka probably legit ) are probably akamai/prolexic, arbor networks, fortinet, incapsula, radware, etc as previously noted by others, legit corp will ask you for lots of legal paperwork for their "get out of jail card" for DDoS'ing your servers and all the other ISP's routers along the way that had to transport those gigabyte/terabyte of useless ddos packets imho, most ddos simulator folks will want to know what are you wanting to simulate .... there are easily, say 100,000 attack vectors ... - attack all your IP# - attack all ports on each IP# - various arp flood - various icmp flood - various udp flood - various tcp flood ( trivial to defend ) - attack specific vulnerabilities already found n not patched - there are proably thousands of apps that can be used to launch various DDoS attacks ... - volumetric icmp DDoS attacks and volumetric udp DDoS attacks will most likely take you offline ... almost nothing you can do to stop it, prevent it, block it, etc... your ISP has to do that for you or your ISP's larger peer has to get in there too you will want the ph# of the security guru at the ISP to help you resolve the issue i doubt any ddos mitigation will help you and more importantly, you probably will not want to pay $$$ to the ddos cloud scrubber to be removing xTB of udp or icmp DDoS attacks - if you're thinking of ddos attacks as "anything that is thrown at them" against webservers, mail servers, and ssh servers, that is only 3 ports out of 65,535 possible attacks there is "no such thing as anything that can be thrown at them" defending web servers, mail servers and ssh servers can be "script kiddie" trivially defended ... as long as it is properly patched and maintained and built to be defensible before you ask others to DDoS your servers, have you already patched apache/sendmail/ssh/openssl, kernels, etc, etc ddos attackers will be looking for your weakest link, usually login/pwd from outside wifi access points and home offices, hotel ethernet, etc there is almost zero benefit for volumetric 10TB or 20 TB of DDoS attacks we read about in the papers against large corp. the only defense is to build your own geographically separate colo in each major customer countries in asia, europe, usa, south america, etc usually the purpose of DDoS attacks is to take your servers offline or steal/copy/sniff info or hide in your network or launch other attacks these are easier ( script kiddie ) DDoS attacks and less likely to be noticed by your ISP of incoming "attacks" - sniff login/passwd from outside ( wifi, home office, etc ) - install keyboard sniffers - install other trojans ( virii, worm, etc ) endless list of attacks to simulate pixie dust alvin - http://DDoS-Simulator.net > On Mon, Jul 27, 2015 at 5:40 PM, lobna gouda > wrote: > > > Hello David et Dan, > > > > Are you going to perform the DDOS solution yourself, or you are looking > > for a company to provide a solution for you. Some companies perform an > > attack simulation for you before buying the product > > From rdobbins at arbor.net Tue Jul 28 22:47:04 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 29 Jul 2015 05:47:04 +0700 Subject: DDOS Simulation In-Reply-To: <20150728221940.GA25835@Mail.DDoS-Mitigator.net> References: <20150728221940.GA25835@Mail.DDoS-Mitigator.net> Message-ID: On 29 Jul 2015, at 5:19, alvin nanog wrote: > as previously noted by others, legit corp will ask you for lots of > legal paperwork for their "get out of jail card" for DDoS'ing your > servers > and all the other ISP's routers along the way that had to transport > those gigabyte/terabyte of useless ddos packets No company can provide a 'get out of jail card' for illegal activities, irrespective of how they arrange their paperwork. DDoS testing across the Internet is a Big No-No due to legal considerations, potential liabilities, potential for catastrophic error, etc. Doing it across one's own network which one controls is certainly viable. There are some companies which do that, and which take a belt-and-suspenders approach to ensure that simulated attack traffic doesn't leak, etc. Simulated DDoS attacks and testing of defenses should be part of any real development environment, along with scalability testing in general. Sadly, this is rarely the case. The best way to learn how to defend something is to learn how to attack it. Organizations with substantial Internet properties should develop their own organic capabilities to perform such testing in a safe and responsible manner, as it will also enhance the skills needed to defend said properties. ----------------------------------- Roland Dobbins From lists at sadiqs.com Tue Jul 28 23:20:54 2015 From: lists at sadiqs.com (Sadiq Saif) Date: Tue, 28 Jul 2015 19:20:54 -0400 Subject: Windows 10 Release In-Reply-To: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <55B80E56.5010107@sadiqs.com> On 7/28/2015 16:45, Nick Olsen wrote: > Anyone anxious to see what kind of traffic comes from Windows 10 releasing > tomorrow? > > Being a 3-4GB download. Each device is moving more data than any Apple > update ever did. > > Wonder if they'll stage the release as apple appeared to have learned > after IOS7 hammered a bunch of networks. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > A friend and I noticed that Microsoft has pre-loaded the upgrade data onto machines that have confirmed/"reserved" the upgrade *today*. C:\$Windows.~BT is the directory, hidden folder. -- Sadiq Saif (AS393949) https://staticsafe.ca From cmaurand at xyonet.com Tue Jul 28 23:43:25 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 28 Jul 2015 19:43:25 -0400 Subject: Windows 10 Release In-Reply-To: <20150728220404.GA4116@excession.tpb.net> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> <20150728220404.GA4116@excession.tpb.net> Message-ID: <92CF8900-4301-45E0-838D-D9F28D7838CC@xyonet.com> Microsoft tells me 3.2 GB for win 10 pro 64 bit. On July 28, 2015 6:04:04 PM EDT, Niels Bakker wrote: >* nick at flhsi.com (Nick Olsen) [Tue 28 Jul 2015, 22:46 CEST]: >>Being a 3-4GB download. Each device is moving more data than any Apple > >>update ever did. > >I'm not so sure of that. The 10.9 install image clocked in at 4.9 GB, >and the Mac App Store for 10.10 Yosemite says "Size: 5.67 GB"; >http://www.microsoft.com/en-us/windows/features says "3GB download >required" in the small print at the bottom. > > > -- Niels. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From ESundberg at nitelusa.com Wed Jul 29 00:09:52 2015 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Wed, 29 Jul 2015 00:09:52 +0000 Subject: Windows 10 Release In-Reply-To: <92CF8900-4301-45E0-838D-D9F28D7838CC@xyonet.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> <20150728220404.GA4116@excession.tpb.net> <92CF8900-4301-45E0-838D-D9F28D7838CC@xyonet.com> Message-ID: <495D0934DA46854A9CA758393724D590BBE7CC@NI-MAIL02.nii.ads> Does anyone know if Microsoft will be hosting the downloads from there ASN 8075 or from an CDN Provider like Akamai? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Curtis Maurand Sent: Tuesday, July 28, 2015 6:43 PM To: Niels Bakker ; nanog at nanog.org Subject: Re: Windows 10 Release Microsoft tells me 3.2 GB for win 10 pro 64 bit. On July 28, 2015 6:04:04 PM EDT, Niels Bakker wrote: >* nick at flhsi.com (Nick Olsen) [Tue 28 Jul 2015, 22:46 CEST]: >>Being a 3-4GB download. Each device is moving more data than any Apple > >>update ever did. > >I'm not so sure of that. The 10.9 install image clocked in at 4.9 GB, >and the Mac App Store for 10.10 Yosemite says "Size: 5.67 GB"; >http://www.microsoft.com/en-us/windows/features says "3GB download >required" in the small print at the bottom. > > > -- Niels. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From nanog at ics-il.net Wed Jul 29 00:19:22 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 28 Jul 2015 19:19:22 -0500 (CDT) Subject: Windows 10 Release In-Reply-To: <495D0934DA46854A9CA758393724D590BBE7CC@NI-MAIL02.nii.ads> Message-ID: <1126198946.4632.1438129157014.JavaMail.mhammett@ThunderFuck> According to the article I read... it's pretty much everywhere. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Erik Sundberg" To: "Curtis Maurand" , "Niels Bakker" , nanog at nanog.org Sent: Tuesday, July 28, 2015 7:09:52 PM Subject: RE: Windows 10 Release Does anyone know if Microsoft will be hosting the downloads from there ASN 8075 or from an CDN Provider like Akamai? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Curtis Maurand Sent: Tuesday, July 28, 2015 6:43 PM To: Niels Bakker ; nanog at nanog.org Subject: Re: Windows 10 Release Microsoft tells me 3.2 GB for win 10 pro 64 bit. On July 28, 2015 6:04:04 PM EDT, Niels Bakker wrote: >* nick at flhsi.com (Nick Olsen) [Tue 28 Jul 2015, 22:46 CEST]: >>Being a 3-4GB download. Each device is moving more data than any Apple > >>update ever did. > >I'm not so sure of that. The 10.9 install image clocked in at 4.9 GB, >and the Mac App Store for 10.10 Yosemite says "Size: 5.67 GB"; >http://www.microsoft.com/en-us/windows/features says "3GB download >required" in the small print at the bottom. > > > -- Niels. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From rpug at lp0.org Tue Jul 28 17:24:09 2015 From: rpug at lp0.org (Ryan Pugatch) Date: Tue, 28 Jul 2015 13:24:09 -0400 Subject: DDOS Simulation In-Reply-To: References: Message-ID: <1438104249.2773720.335462665.02614C75@webmail.messagingengine.com> Hi Dovid, I recommend checking out NimbusDDOS. http://www.nimbusddos.com/ I know that they have done exactly this for several notable customers, and also provide insights into impacts (they don't just blindly run the attacks for you, they provide intelligence behind what's happening to help you make sense of what is going on.) Contact me off list if you want me to set up an intro. Ryan On Mon, Jul 27, 2015, at 11:32 AM, Dovid Bender wrote: > Hi All, > > We are looking into a few different DDOS solutions for a client. We need > a > LEGITIMATE company that can simulate some DDOS attacks (the generic + > specific to the clients business). Anyone have any recommendations? > > Regards, > > Dovid From justin at mckill.ca Tue Jul 28 20:49:16 2015 From: justin at mckill.ca (Justin Mckillican) Date: Tue, 28 Jul 2015 16:49:16 -0400 Subject: Windows 10 Release In-Reply-To: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: For upgraders I believe only 5 million 'Insiders' that tested Windows 10 will get it tomorrow. The rest of the free upgraders (those from Win7 and Win8) will get it over the next two weeks at different times with the priority going to those that 'reserved' it in Windows Update tool. -justin > On Jul 28, 2015, at 4:45 PM, Nick Olsen wrote: > > Anyone anxious to see what kind of traffic comes from Windows 10 releasing > tomorrow? > > Being a 3-4GB download. Each device is moving more data than any Apple > update ever did. > > Wonder if they'll stage the release as apple appeared to have learned > after IOS7 hammered a bunch of networks. > > Nick Olsen > Network Operations (855) FLSPEED x106 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4103 bytes Desc: not available URL: From kylemc at zillow.com Tue Jul 28 20:53:25 2015 From: kylemc at zillow.com (Kyle McLerren) Date: Tue, 28 Jul 2015 20:53:25 +0000 Subject: Windows 10 Release In-Reply-To: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <1E3463E6-99DA-4369-A66C-DEA938032F7D@zillow.com> http://www.computerworld.com/article/2943954/microsoft-windows/microsoft-confirms-waves-roll-out-of-windows-10.html On 7/28/15, 1:45 PM, "NANOG on behalf of Nick Olsen" wrote: >Anyone anxious to see what kind of traffic comes from Windows 10 releasing >tomorrow? > > Being a 3-4GB download. Each device is moving more data than any Apple >update ever did. > > Wonder if they'll stage the release as apple appeared to have learned >after IOS7 hammered a bunch of networks. > > Nick Olsen >Network Operations (855) FLSPEED x106 > > From jason at rice.edu Wed Jul 29 00:23:55 2015 From: jason at rice.edu (Jason Bothe) Date: Tue, 28 Jul 2015 19:23:55 -0500 Subject: Windows 10 Release In-Reply-To: <495D0934DA46854A9CA758393724D590BBE7CC@NI-MAIL02.nii.ads> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> <20150728220404.GA4116@excession.tpb.net> <92CF8900-4301-45E0-838D-D9F28D7838CC@xyonet.com> <495D0934DA46854A9CA758393724D590BBE7CC@NI-MAIL02.nii.ads> Message-ID: <43C48A32-F223-4A8C-BD7A-53A09AD38793@rice.edu> We have heard they will be available via 8075. Jason Bothe, Manager of Networking Rice University o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu > On Jul 28, 2015, at 19:09, Erik Sundberg wrote: > > Does anyone know if Microsoft will be hosting the downloads from there ASN 8075 or from an CDN Provider like Akamai? > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Curtis Maurand > Sent: Tuesday, July 28, 2015 6:43 PM > To: Niels Bakker ; nanog at nanog.org > Subject: Re: Windows 10 Release > > Microsoft tells me 3.2 GB for win 10 pro 64 bit. > >> On July 28, 2015 6:04:04 PM EDT, Niels Bakker wrote: >> * nick at flhsi.com (Nick Olsen) [Tue 28 Jul 2015, 22:46 CEST]: >>> Being a 3-4GB download. Each device is moving more data than any Apple >> >>> update ever did. >> >> I'm not so sure of that. The 10.9 install image clocked in at 4.9 GB, >> and the Mac App Store for 10.10 Yosemite says "Size: 5.67 GB"; >> http://www.microsoft.com/en-us/windows/features says "3GB download >> required" in the small print at the bottom. >> >> >> -- Niels. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From mhoppes at indigowireless.com Wed Jul 29 00:54:20 2015 From: mhoppes at indigowireless.com (Matt Hoppes) Date: Tue, 28 Jul 2015 20:54:20 -0400 Subject: Level3 routing issues Message-ID: Is anyone seeing packet loss or routing issues on the Level3 network on the east coast right now? From deleskie at gmail.com Wed Jul 29 01:05:45 2015 From: deleskie at gmail.com (jim deleskie) Date: Tue, 28 Jul 2015 22:05:45 -0300 Subject: DDOS Simulation In-Reply-To: <1438104249.2773720.335462665.02614C75@webmail.messagingengine.com> References: <1438104249.2773720.335462665.02614C75@webmail.messagingengine.com> Message-ID: If anyone offers to "test" your DDoS devices across a network that you do not 100% own, you are risking legal issues. If they offer to test it across your own network, make sure you have in writing from you upper management that they understand the risk and approve it. If you choose to do it anyway then you are taking a LARGE risk. Testing should be in your lab and even then you should understand 100% what is happing to avoid leaking attack traffic into the internet. -jim On Tue, Jul 28, 2015 at 2:24 PM, Ryan Pugatch wrote: > Hi Dovid, > > I recommend checking out NimbusDDOS. http://www.nimbusddos.com/ > > I know that they have done exactly this for several notable customers, > and also provide insights into impacts (they don't just blindly run the > attacks for you, they provide intelligence behind what's happening to > help you make sense of what is going on.) > > Contact me off list if you want me to set up an intro. > > Ryan > > > On Mon, Jul 27, 2015, at 11:32 AM, Dovid Bender wrote: > > Hi All, > > > > We are looking into a few different DDOS solutions for a client. We need > > a > > LEGITIMATE company that can simulate some DDOS attacks (the generic + > > specific to the clients business). Anyone have any recommendations? > > > > Regards, > > > > Dovid > From larrysheldon at cox.net Wed Jul 29 01:25:21 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 28 Jul 2015 20:25:21 -0500 Subject: Windows 10 Release In-Reply-To: References: Message-ID: <55B82B81.503@cox.net> On 7/28/2015 15:45, Nick Olsen wrote: > Wonder if they'll stage the release as apple appeared to have learned > after IOS7 hammered a bunch of networks. Everything I have gotten for my personal machines suggests that it may be months before "my" copies are released. -- sed quis custodiet ipsos custodes? (Juvenal) From brett at the-watsons.org Wed Jul 29 01:28:02 2015 From: brett at the-watsons.org (Brett Watson) Date: Tue, 28 Jul 2015 21:28:02 -0400 Subject: DDOS Simulation In-Reply-To: References: <1438104249.2773720.335462665.02614C75@webmail.messagingengine.com> Message-ID: <12A60E2B-76CE-4190-9FCD-A1DDB44F165C@the-watsons.org> > On Jul 28, 2015, at 9:05 PM, jim deleskie wrote: > > If anyone offers to "test" your DDoS devices across a network that you do > not 100% own, you are risking legal issues. > > If they offer to test it across your own network, make sure you have in > writing from you upper management that they understand the risk and approve > it. > > If you choose to do it anyway then you are taking a LARGE risk. > > > Testing should be in your lab and even then you should understand 100% what > is happing to avoid leaking attack traffic into the internet. in a previous job (we did ddos mitigation) customer asked all the time for simulation, and typically live across the internet. for all the reasons noted, we didn?t do it, but instead would do a lab/POC with pcaps replayed from previous attacks we had mitigated to show the customer how our platform worked, how we handled incident response, etc. agree with all comments about NOT doing it over the internet, that way lies madness. -b From damian at google.com Wed Jul 29 02:06:38 2015 From: damian at google.com (Damian Menscher) Date: Tue, 28 Jul 2015 19:06:38 -0700 Subject: DDOS Simulation In-Reply-To: <1438104249.2773720.335462665.02614C75@webmail.messagingengine.com> References: <1438104249.2773720.335462665.02614C75@webmail.messagingengine.com> Message-ID: Two more options: - http://www.redwolfsecurity.com/#!ddos_testing/cqd6 (not vouching for them, just raising awareness of the options) - Spin up a bunch of VMs at various cloud providers and launch your own attacks against yourself. Note that you should only do this with the permission of the cloud provider(s) as you may hit bottlenecks or trigger automated defenses within their networks. Damian On Tue, Jul 28, 2015 at 10:24 AM, Ryan Pugatch wrote: > Hi Dovid, > > I recommend checking out NimbusDDOS. http://www.nimbusddos.com/ > > I know that they have done exactly this for several notable customers, > and also provide insights into impacts (they don't just blindly run the > attacks for you, they provide intelligence behind what's happening to > help you make sense of what is going on.) > > Contact me off list if you want me to set up an intro. > > Ryan > > > On Mon, Jul 27, 2015, at 11:32 AM, Dovid Bender wrote: > > Hi All, > > > > We are looking into a few different DDOS solutions for a client. We need > > a > > LEGITIMATE company that can simulate some DDOS attacks (the generic + > > specific to the clients business). Anyone have any recommendations? > > > > Regards, > > > > Dovid > From contact at nullivex.com Wed Jul 29 03:06:14 2015 From: contact at nullivex.com (Bryan Tong) Date: Tue, 28 Jul 2015 21:06:14 -0600 Subject: Working with Spamhaus Message-ID: Hello All, SpamHaus has done us the favor of blacklisting all of our prefixes due to the issues with handful of IPs from customers we have removed from our network. They are now being unresponsive on helping us get these listings removed and we have a lot of legitimate customers who are no longer able to send email. If anyone has any advice on how to deal with these people. Please let me know here or off list. Thanks! From mike at m5computersecurity.com Wed Jul 29 03:33:49 2015 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Tue, 28 Jul 2015 20:33:49 -0700 Subject: Working with Spamhaus Message-ID: I know this is going to sound worse than the spirit in which I offer it but... Step one might be to adjust the attitude from "Deal with these people" to something along the lines of "how might we best resolve the issue". No matter who you deal with, you will get much further with a good humble attitude rather than blame. It is my experience that if they list more than a very specific range of IP addresses on your network, you have a real problem. If you have a spammer at the top and bottom of a CIDR block then they may list the range, but I have had them lost two small ranges in the same /24 before... so I know they have very good specificity.? I am sorry I can not offer you any specific steps or contact information to help you expedite the resolution, but I hope you will find some value in this advice.? Perhaps, if your network is small and you control all your mail servers and you really are clean, you can configure thrm to relay through a smart host or SendGrid or etc. Good luck,Mike Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Bryan Tong Date: 07/28/2015 8:06 PM (GMT-07:00) To: nanog at nanog.org Subject: Working with Spamhaus Hello All, SpamHaus has done us the favor of blacklisting all of our prefixes due to the issues with handful of IPs from customers we have removed from our network. They are now being unresponsive on helping us get these listings removed and we have a lot of legitimate customers who are no longer able to send email. If anyone has any advice on how to deal with these people. Please let me know here or off list. Thanks! From contact at nullivex.com Wed Jul 29 03:39:48 2015 From: contact at nullivex.com (Bryan Tong) Date: Tue, 28 Jul 2015 21:39:48 -0600 Subject: Working with Spamhaus In-Reply-To: References: Message-ID: Well, I wouldnt have such a disheartened attitude if they would have been specific or given time to comply. I find listing an entire /17 without cause or a report to back it up an unjust action. I have contacted them through multiple mediums and have found no response. So if someone has had better luck I want to know if I am doing something wrong. I have also been absolutely pleasant with them. My frustration grows as I am ignored. Every network deals with bad apples I dont understand why our good standing customers must also suffer these consequences. Thanks On Tue, Jul 28, 2015 at 9:33 PM, Michael J McCafferty < mike at m5computersecurity.com> wrote: > I know this is going to sound worse than the spirit in which I offer it > but... Step one might be to adjust the attitude from "Deal with these > people" to something along the lines of "how might we best resolve the > issue". > > No matter who you deal with, you will get much further with a good humble > attitude rather than blame. > > It is my experience that if they list more than a very specific range of > IP addresses on your network, you have a real problem. If you have a > spammer at the top and bottom of a CIDR block then they may list the range, > but I have had them lost two small ranges in the same /24 before... so I > know they have very good specificity. > > I am sorry I can not offer you any specific steps or contact information > to help you expedite the resolution, but I hope you will find some value in > this advice. > > Perhaps, if your network is small and you control all your mail servers > and you really are clean, you can configure thrm to relay through a smart > host or SendGrid or etc. > > Good luck, > Mike > > > > Sent from my Verizon Wireless 4G LTE smartphone > > > -------- Original message -------- > From: Bryan Tong > Date: 07/28/2015 8:06 PM (GMT-07:00) > To: nanog at nanog.org > Subject: Working with Spamhaus > > Hello All, > > SpamHaus has done us the favor of blacklisting all of our prefixes due to > the issues with handful of IPs from customers we have removed from our > network. > > They are now being unresponsive on helping us get these listings removed > and we have a lot of legitimate customers who are no longer able to send > email. > > If anyone has any advice on how to deal with these people. Please let me > know here or off list. > > Thanks! > -- eSited LLC (701) 390-9638 From larrysheldon at cox.net Wed Jul 29 03:45:47 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 28 Jul 2015 22:45:47 -0500 Subject: Working with Spamhaus In-Reply-To: References: Message-ID: <55B84C6B.5060106@cox.net> On 7/28/2015 22:06, Bryan Tong wrote: > If anyone has any advice on how to deal with these people. Please let me > know here or off list. Based on years of experience, the very best way is "don't". Don't profit from spam, and as a result don't deal with Spamhaus at all. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Wed Jul 29 03:53:34 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 28 Jul 2015 22:53:34 -0500 Subject: Working with Spamhaus In-Reply-To: References: Message-ID: <55B84E3E.8070105@cox.net> On 7/28/2015 22:39, Bryan Tong wrote: > Well, > > I wouldnt have such a disheartened attitude if they would have been > specific or given time to comply. > > I find listing an entire /17 without cause or a report to back it up an > unjust action. Have you tried the widely known services they provide? http://www.spamhaus.org/lookup/ May I direct your reluctant attention to this, just under the first "lookup" box? "If your IP address is listed on one of our IP blocklists; SBL, XBL or PBL (collectively known as the 'Zen' blocklist), this lookup tool will tell you which one and will give you a link to information on what to do." May I focus your unwilling attention on "this lookup tool will tell you which one and will give you a link to information on what to do."? -- sed quis custodiet ipsos custodes? (Juvenal) From contact at nullivex.com Wed Jul 29 03:57:53 2015 From: contact at nullivex.com (Bryan Tong) Date: Tue, 28 Jul 2015 21:57:53 -0600 Subject: Working with Spamhaus In-Reply-To: <55B84E3E.8070105@cox.net> References: <55B84E3E.8070105@cox.net> Message-ID: Hello, Yes I have followed all of the procedures. I will continue to wait to see if there is any change. Thanks On Tue, Jul 28, 2015 at 9:53 PM, Larry Sheldon wrote: > On 7/28/2015 22:39, Bryan Tong wrote: > >> Well, >> >> I wouldnt have such a disheartened attitude if they would have been >> specific or given time to comply. >> >> I find listing an entire /17 without cause or a report to back it up an >> unjust action. >> > > Have you tried the widely known services they provide? > > http://www.spamhaus.org/lookup/ > > May I direct your reluctant attention to this, just under the first > "lookup" box? > > "If your IP address is listed on one of our IP blocklists; SBL, XBL or PBL > (collectively known as the 'Zen' blocklist), this lookup tool will tell you > which one and will give you a link to information on what to do." > > May I focus your unwilling attention on "this lookup tool will tell you > which one and will give you a link to information on what to do."? > > > > -- > sed quis custodiet ipsos custodes? (Juvenal) > -- eSited LLC (701) 390-9638 From larrysheldon at cox.net Wed Jul 29 04:13:02 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 28 Jul 2015 23:13:02 -0500 Subject: Working with Spamhaus In-Reply-To: References: <55B84E3E.8070105@cox.net> Message-ID: <55B852CE.3040601@cox.net> On 7/28/2015 22:57, Bryan Tong wrote: > Yes I have followed all of the procedures. I will continue to wait to see > if there is any change. Would you please send me the address range in question--I would like to see what they told you to do. -- sed quis custodiet ipsos custodes? (Juvenal) From goemon at anime.net Wed Jul 29 05:24:30 2015 From: goemon at anime.net (goemon at anime.net) Date: Tue, 28 Jul 2015 22:24:30 -0700 (PDT) Subject: Working with Spamhaus In-Reply-To: <55B84C6B.5060106@cox.net> References: <55B84C6B.5060106@cox.net> Message-ID: On Tue, 28 Jul 2015, Larry Sheldon wrote: > On 7/28/2015 22:06, Bryan Tong wrote: >> If anyone has any advice on how to deal with these people. Please let me >> know here or off list. > Based on years of experience, the very best way is "don't". You have to work pretty hard to get a /17 listed. > Don't profit from spam, and as a result don't deal with Spamhaus at all. Yep. -Dan From larrysheldon at cox.net Wed Jul 29 05:29:01 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 29 Jul 2015 00:29:01 -0500 Subject: Working with Spamhaus In-Reply-To: References: <55B84C6B.5060106@cox.net> Message-ID: <55B8649D.3060500@cox.net> On 7/29/2015 00:24, goemon at anime.net wrote: > On Tue, 28 Jul 2015, Larry Sheldon wrote: >> On 7/28/2015 22:06, Bryan Tong wrote: >>> If anyone has any advice on how to deal with these people. Please let me >>> know here or off list. >> Based on years of experience, the very best way is "don't". > > You have to work pretty hard to get a /17 listed. > >> Don't profit from spam, and as a result don't deal with Spamhaus at all. > > Yep. Some days NANOG sounds like NANA-E. -- sed quis custodiet ipsos custodes? (Juvenal) From pavel.odintsov at gmail.com Wed Jul 29 05:31:30 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 29 Jul 2015 08:31:30 +0300 Subject: Working with Spamhaus In-Reply-To: <55B84C6B.5060106@cox.net> References: <55B84C6B.5060106@cox.net> Message-ID: Hello! Completely agree with Larry. I'm enough big hosting provider and we have multiple spam issues every day. But we fix they ASAP before any folks from SpamHaus become angry :) So we still have 1-2 abuses from SpamHaus every few weeks. But we resolve they in few hours and we haven't any issues with blocking or blacklisting. They are very responsive and like us because we do things smoothy :) Actually they really do Internet better. Don't hate they! On Wed, Jul 29, 2015 at 6:45 AM, Larry Sheldon wrote: > On 7/28/2015 22:06, Bryan Tong wrote: > >> If anyone has any advice on how to deal with these people. Please let me >> know here or off list. > > > Based on years of experience, the very best way is "don't". Don't profit > from spam, and as a result don't deal with Spamhaus at all. > > > -- > sed quis custodiet ipsos custodes? (Juvenal) -- Sincerely yours, Pavel Odintsov From mpalmer at hezmatt.org Wed Jul 29 05:37:17 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 29 Jul 2015 15:37:17 +1000 Subject: Working with Spamhaus In-Reply-To: <55B852CE.3040601@cox.net> References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> Message-ID: <20150729053717.GU20260@hezmatt.org> On Tue, Jul 28, 2015 at 11:13:02PM -0500, Larry Sheldon wrote: > On 7/28/2015 22:57, Bryan Tong wrote: > > >Yes I have followed all of the procedures. I will continue to wait to see > >if there is any change. > > Would you please send me the address range in question--I would like to see > what they told you to do. I suspect that http://www.spamhaus.org/query/ip/199.87.233.245 may be part of it (although it indicates a /21 blocked, not a /17). - Matt -- One of the Rules Of Flight is, or should be: Pullout Altitude Is Not A Signed Quantity. -- Anthony de Boer, in the monastery From contact at nullivex.com Wed Jul 29 05:41:08 2015 From: contact at nullivex.com (Bryan Tong) Date: Tue, 28 Jul 2015 23:41:08 -0600 Subject: Working with Spamhaus In-Reply-To: <20150729053717.GU20260@hezmatt.org> References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> Message-ID: Yes that is part of it. There are other blocks they listed as well. On Tue, Jul 28, 2015 at 11:37 PM, Matt Palmer wrote: > On Tue, Jul 28, 2015 at 11:13:02PM -0500, Larry Sheldon wrote: > > On 7/28/2015 22:57, Bryan Tong wrote: > > > > >Yes I have followed all of the procedures. I will continue to wait to > see > > >if there is any change. > > > > Would you please send me the address range in question--I would like to > see > > what they told you to do. > > I suspect that http://www.spamhaus.org/query/ip/199.87.233.245 may be part > of it (although it indicates a /21 blocked, not a /17). > > - Matt > > -- > One of the Rules Of Flight is, or should be: Pullout Altitude Is Not A > Signed Quantity. > -- Anthony de Boer, in the monastery > > -- eSited LLC (701) 390-9638 From larrysheldon at cox.net Wed Jul 29 05:58:45 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 29 Jul 2015 00:58:45 -0500 Subject: Working with Spamhaus In-Reply-To: References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> Message-ID: <55B86B95.1090304@cox.net> On 7/29/2015 00:37, Matt Palmer wrote: > I suspect that http://www.spamhaus.org/query/ip/199.87.233.245 may be part > of it (although it indicates a /21 blocked, not a /17). And the removal instructions for that range (SBL) seems crystal clear to me, but long experience teaches that what is crystal clear to me is often to clear at all to spammers. What is it about Colorado? -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Wed Jul 29 06:03:58 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 29 Jul 2015 01:03:58 -0500 Subject: Working with Spamhaus In-Reply-To: References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> Message-ID: <55B86CCE.1040801@cox.net> On 7/29/2015 00:58, Larry Sheldon wrote: > On 7/29/2015 00:37, Matt Palmer wrote: > >> I suspect that http://www.spamhaus.org/query/ip/199.87.233.245 may be >> part >> of it (although it indicates a /21 blocked, not a /17). > > And the removal instructions for that range (SBL) seems crystal clear to > me, but long experience teaches that what is crystal clear to me is > often to clear at all to spammers. I am surprised that I have not been banned again for talking about spam here, so I'll leave you with this (from the information Matt provided): http://www.spamhaus.org/sbl/query/SBL263089 Has these notations: SBL263068 104.224.252.0/27 esited.com 2015-07-25 Spamming for fake products SBL260293 104.224.197.94 whdot.com 2015-06-25 Spam source @104.224.197.94 SBL257796 104.224.205.144/28 whdot.com 2015-05-27 brand-fraud websites hosted on hacked subdomain SBL253760 104.201.2.88 zeroddos.com 2015-04-16 Blackhat SEO spammer hosting @104.201.2.88 SBL249474 104.232.128.0/19 esited.com 2015-03-09 snowshoe range - CLOUDDDOS TECHNOLOGY CO.,LIMITED (AS22552) SBL244070 104.221.128.0/17 esited.com 2015-01-05 snowshoe range - eSited Solutions SBL244052 104.195.0.0/18 esited.com 2015-01-05 snowshoe range - eSited Solutions (NL-1) SBL241541 104.201.0.0/18 esited.com 2014-12-02 Kuang Ren snowshoe range - ZERO DDOS LLC SBL241495 69.87.192.0/20 d esited.com 2014-12-01 Kuang Ren snowshoe range - eSited Solutions (NL-1) SBL241492 23.249.176.0/20 esited.com 2014-12-01 Kuang Ren snowshoe range - GCHAO LLC SBL241491 66.254.160.0/19 esited.com 2014-12-01 Kuang Ren snowshoe range SBL241489 162.247.232.0/21 esited.com 2014-12-01 Kuang Ren snowshoe range SBL234439 104.167.64.0/19 esited.com 2014-09-14 spam emitters - ZERO DDOS LLC SBL226660 199.87.239.226/31 esited.com 2014-06-27 DNS for spam domains SBL223484 167.88.192.0/20 esited.com 2014-05-26 spam emitters - ZERO DDOS LLC SBL207432 199.87.233.92 esited.com 2013-12-12 spam site - 78high.ss99g.com SBL207431 199.87.239.226 esited.com 2013-12-12 spam redirector at zjjj58.com / s9gg.com Removal Procedure To have record SBL263089 (199.87.232.0/21) removed from the SBL, the Abuse/Security representative of esited.com (or the Internet Service Provider responsible for supplying connectivity to 199.87.232.0/21) needs to contact the SBL Team by email (use this link) to explain how the abuse problem has been terminated (we need to know exactly how the issue has been dealt with and that this abuse problem is fully terminated). If the abuse problem that caused this listing has been terminated we will normally remove the listing from the SBL without delay. It is essential that emails to the SBL Team about this SBL listing include this exact ticket information in the email Subject: If you are a representative of esited.com, you also need to see: Current Live esited.com SBL Listings -- sed quis custodiet ipsos custodes? (Juvenal) From contact at nullivex.com Wed Jul 29 06:16:14 2015 From: contact at nullivex.com (Bryan Tong) Date: Wed, 29 Jul 2015 00:16:14 -0600 Subject: Working with Spamhaus In-Reply-To: <55B86CCE.1040801@cox.net> References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <55B86CCE.1040801@cox.net> Message-ID: Yes Larry, I have followed those instructions without a response. So I was curious what to do when no response is given. I will wait longer and see. Sorry if anything I have done has upset you. Thanks On Wed, Jul 29, 2015 at 12:03 AM, Larry Sheldon wrote: > On 7/29/2015 00:58, Larry Sheldon wrote: > >> On 7/29/2015 00:37, Matt Palmer wrote: >> >> I suspect that http://www.spamhaus.org/query/ip/199.87.233.245 may be >>> part >>> of it (although it indicates a /21 blocked, not a /17). >>> >> >> And the removal instructions for that range (SBL) seems crystal clear to >> me, but long experience teaches that what is crystal clear to me is >> often to clear at all to spammers. >> > > I am surprised that I have not been banned again for talking about spam > here, so I'll leave you with this (from the information Matt provided): > > http://www.spamhaus.org/sbl/query/SBL263089 > > Has these notations: > > SBL263068 104.224.252.0/27 esited.com 2015-07-25 Spamming for fake > products > SBL260293 104.224.197.94 whdot.com 2015-06-25 Spam source @104.224.197.94 > SBL257796 104.224.205.144/28 whdot.com 2015-05-27 brand-fraud websites > hosted on hacked subdomain > SBL253760 104.201.2.88 zeroddos.com 2015-04-16 Blackhat SEO spammer > hosting @104.201.2.88 > SBL249474 104.232.128.0/19 esited.com 2015-03-09 snowshoe range - > CLOUDDDOS TECHNOLOGY CO.,LIMITED (AS22552) > SBL244070 104.221.128.0/17 esited.com 2015-01-05 snowshoe range - eSited > Solutions > SBL244052 104.195.0.0/18 esited.com 2015-01-05 snowshoe range - eSited > Solutions (NL-1) > SBL241541 104.201.0.0/18 esited.com 2014-12-02 Kuang Ren snowshoe range - > ZERO DDOS LLC > SBL241495 69.87.192.0/20 d esited.com 2014-12-01 Kuang Ren snowshoe range > - eSited Solutions (NL-1) > SBL241492 23.249.176.0/20 esited.com 2014-12-01 Kuang Ren snowshoe range > - GCHAO LLC > SBL241491 66.254.160.0/19 esited.com 2014-12-01 Kuang Ren snowshoe range > SBL241489 162.247.232.0/21 esited.com 2014-12-01 Kuang Ren snowshoe range > SBL234439 104.167.64.0/19 esited.com 2014-09-14 spam emitters - ZERO DDOS > LLC > SBL226660 199.87.239.226/31 esited.com 2014-06-27 DNS for spam domains > SBL223484 167.88.192.0/20 esited.com 2014-05-26 spam emitters - ZERO DDOS > LLC > SBL207432 199.87.233.92 esited.com 2013-12-12 spam site - 78high.ss99g.com > SBL207431 199.87.239.226 esited.com 2013-12-12 spam redirector at > zjjj58.com / s9gg.com > > > Removal Procedure > > To have record SBL263089 (199.87.232.0/21) removed from the SBL, the > Abuse/Security representative of esited.com (or the Internet Service > Provider responsible for supplying connectivity to 199.87.232.0/21) needs > to contact the SBL Team by email (use this link) to explain how the abuse > problem has been terminated (we need to know exactly how the issue has been > dealt with and that this abuse problem is fully terminated). If the abuse > problem that caused this listing has been terminated we will normally > remove the listing from the SBL without delay. > > It is essential that emails to the SBL Team about this SBL listing include > this exact ticket information in the email Subject: > > If you are a representative of esited.com, you also need to see: Current > Live esited.com SBL Listings > > > > > > > -- > sed quis custodiet ipsos custodes? (Juvenal) > -- eSited LLC (701) 390-9638 From mpalmer at hezmatt.org Wed Jul 29 06:53:51 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 29 Jul 2015 16:53:51 +1000 Subject: Working with Spamhaus In-Reply-To: References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> Message-ID: <20150729065351.GZ20260@hezmatt.org> On Tue, Jul 28, 2015 at 11:41:08PM -0600, Bryan Tong wrote: > Yes that is part of it. > > There are other blocks they listed as well. Well, http://www.spamhaus.org/sbl/query/SBL263089 has a fair amount of shady stuff going on, and http://www.spamhaus.org/sbl/listings/esited.com gives a pretty decent history of what Spamhaus has been doing. Note the "(escalation)" entries in there, which indicates a lack of interest on esited.com's part in fixing any of the problems. - Matt From list at satchell.net Wed Jul 29 09:25:34 2015 From: list at satchell.net (Stephen Satchell) Date: Wed, 29 Jul 2015 02:25:34 -0700 Subject: Working with Spamhaus In-Reply-To: References: Message-ID: <55B89C0E.8080006@satchell.net> On 07/28/2015 08:06 PM, Bryan Tong wrote: > Hello All, > > SpamHaus has done us the favor of blacklisting all of our prefixes due to > the issues with handful of IPs from customers we have removed from our > network. > > They are now being unresponsive on helping us get these listings removed > and we have a lot of legitimate customers who are no longer able to send > email. > > If anyone has any advice on how to deal with these people. Please let me > know here or off list. > > Thanks! > When I started work for a Web hosting company as a mail admin, the company had a number or entries in the various blocking lists, including the infamous SPEWS list. Job one was finding out just which customers were causing the listings -- make a list, and check it against terminated accounts. A surprising number of those "dead" accounts were still active in one way or another, so I cleaned them up. (Web hosting clients with removed content, but still-active mail accounts.) I then notified each block list know about the terminated accounts, and the associated IP address. Once I finished that task, I started in on the rest of the accounts. One account I terminated because they were selling spammer DNA -- I personally pulled the plugs on that co-located server. Quite a number of Web sites had exploitable mail-out scripts, so I cleaned them up so outsiders couldn't use those sign-up forms to send arbitrary mail. As I worked through the list, I let the block-list owners know what I was doing. I did *not* request de-listing, by the way. My goal in this phase was to show that I was really doing something. As a consequence, several of the BL operators removed the /21 and /19 level blocks. Oh, did I mention that I got my upstreams to do proper SWIP of the address space, and published an abuse@ address for the address ranges? Some customers were doing bulk mail-outs. I worked with those customers to clean up their mailing lists, to throttle their mails to avoid tripping spam alarms, and to properly set up their programs to react properly to DNR and spam-reject. Those that didn't like my clean-up campaign were referred to management for further action. As part of my work, I became active on NANAE, taking advice from many people as to how to clean up my space. One key factor was that I answered every single abuse mail that came in. Every. single. one. The responses were short, describing the corrective action I took. Most of the time, it was yet another open mail-out script that needed to be fixed. But sometimes I got to write back "the abuser has been terminiated." It took about nine months to clean up all the block-list entries. I was also diligent when new entries would pop up -- get the info as to who, and take care of the problem. Management saw the fruit of my labor in the number and quality of new accounts. Big positive. Notice the parallel between mail operations and network operations. Things go MUCH better when we work with each other. All the DNSBL operators want is to know that spam reports will be handled. From rblayzor.bulk at inoc.net Wed Jul 29 11:52:27 2015 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Wed, 29 Jul 2015 07:52:27 -0400 Subject: Level3 routing issues In-Reply-To: References: Message-ID: On Jul 28, 2015, at 8:54 PM, Matt Hoppes wrote: > > Is anyone seeing packet loss or routing issues on the Level3 network on the east coast right now? > > We?ve seen a slew of problems going west out of Level3 in NYC the last couple of nights. Last night was particularly bad to the point we had to shut our Level3 BGP sessions down to route around the issue. -- Robert inoc.net!rblayzor Jabber: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu From Curtis.Starnes at granburyisd.org Wed Jul 29 11:58:39 2015 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Wed, 29 Jul 2015 11:58:39 +0000 Subject: Windows 10 Release In-Reply-To: References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <5d87e99f7e454768bdbad9221f36988e@TEC-MAIL1.granbury.k12.tx.us> I see that everyone can download Windows 10 this morning! There goes my bandwidth. https://www.microsoft.com/en-us/software-download/windows10 Curtis -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin Mckillican Sent: Tuesday, July 28, 2015 3:49 PM To: nick at flhsi.com; nanog at nanog.org list Subject: Re: Windows 10 Release For upgraders I believe only 5 million 'Insiders' that tested Windows 10 will get it tomorrow. The rest of the free upgraders (those from Win7 and Win8) will get it over the next two weeks at different times with the priority going to those that 'reserved' it in Windows Update tool. -justin > On Jul 28, 2015, at 4:45 PM, Nick Olsen wrote: > > Anyone anxious to see what kind of traffic comes from Windows 10 releasing > tomorrow? > > Being a 3-4GB download. Each device is moving more data than any Apple > update ever did. > > Wonder if they'll stage the release as apple appeared to have learned > after IOS7 hammered a bunch of networks. > > Nick Olsen > Network Operations (855) FLSPEED x106 > From khelms at zcorum.com Wed Jul 29 12:20:05 2015 From: khelms at zcorum.com (Scott Helms) Date: Wed, 29 Jul 2015 08:20:05 -0400 Subject: Windows 10 Release In-Reply-To: References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: It's downloading for me right now, though I did reserve my slot. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Jul 28, 2015 at 4:49 PM, Justin Mckillican wrote: > For upgraders I believe only 5 million 'Insiders' that tested Windows 10 > will get it tomorrow. The rest of the free upgraders (those from Win7 and > Win8) will get it over the next two weeks at different times with the > priority going to those that 'reserved' it in Windows Update tool. > > > -justin > > > On Jul 28, 2015, at 4:45 PM, Nick Olsen wrote: > > > > Anyone anxious to see what kind of traffic comes from Windows 10 > releasing > > tomorrow? > > > > Being a 3-4GB download. Each device is moving more data than any Apple > > update ever did. > > > > Wonder if they'll stage the release as apple appeared to have learned > > after IOS7 hammered a bunch of networks. > > > > Nick Olsen > > Network Operations (855) FLSPEED x106 > > > > From larrysheldon at cox.net Wed Jul 29 12:25:32 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 29 Jul 2015 07:25:32 -0500 Subject: Windows 10 Release In-Reply-To: References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <55B8C63C.7000504@cox.net> On 7/29/2015 06:58, STARNES, CURTIS wrote: > I see that everyone can download Windows 10 this morning! > There goes my bandwidth. One of us does not understand how "they" said it was going to be done. -- sed quis custodiet ipsos custodes? (Juvenal) From colinj at gt86car.org.uk Wed Jul 29 12:27:16 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 29 Jul 2015 13:27:16 +0100 Subject: Windows 10 Release In-Reply-To: References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <65591A3F-9107-4B98-BC2C-012B00DA51F2@gt86car.org.uk> 4.0gb in 10mins using home fttc is not bad :) Colin > On 29 Jul 2015, at 13:20, Scott Helms wrote: > > It's downloading for me right now, though I did reserve my slot. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Tue, Jul 28, 2015 at 4:49 PM, Justin Mckillican wrote: > >> For upgraders I believe only 5 million 'Insiders' that tested Windows 10 >> will get it tomorrow. The rest of the free upgraders (those from Win7 and >> Win8) will get it over the next two weeks at different times with the >> priority going to those that 'reserved' it in Windows Update tool. >> >> >> -justin >> >>> On Jul 28, 2015, at 4:45 PM, Nick Olsen wrote: >>> >>> Anyone anxious to see what kind of traffic comes from Windows 10 >> releasing >>> tomorrow? >>> >>> Being a 3-4GB download. Each device is moving more data than any Apple >>> update ever did. >>> >>> Wonder if they'll stage the release as apple appeared to have learned >>> after IOS7 hammered a bunch of networks. >>> >>> Nick Olsen >>> Network Operations (855) FLSPEED x106 >>> >> >> From larrysheldon at cox.net Wed Jul 29 12:28:09 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 29 Jul 2015 07:28:09 -0500 Subject: Windows 10 Release In-Reply-To: References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <55B8C6D9.9000607@cox.net> On 7/29/2015 06:58, STARNES, CURTIS wrote: > I see that everyone can download Windows 10 this morning! > There goes my bandwidth. Just checked this PC--apparently I already have it and am "good to go". I was expecting an email or something. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Wed Jul 29 12:32:37 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 29 Jul 2015 07:32:37 -0500 Subject: Windows 10 Release In-Reply-To: References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <55B8C7E5.7010200@cox.net> On 7/29/2015 07:20, Scott Helms wrote: > It's downloading for me right now, though I did reserve my slot. When I checked a few minutes ago it said my PC had passed the tests--now it says it is downloading. Speed and responsiveness "feels" normal. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Wed Jul 29 13:23:25 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 29 Jul 2015 08:23:25 -0500 Subject: Windows 10 Release In-Reply-To: References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <55B8D3CD.8000706@cox.net> On 7/29/2015 07:32, Larry Sheldon wrote: > On 7/29/2015 07:20, Scott Helms wrote: >> It's downloading for me right now, though I did reserve my slot. > > When I checked a few minutes ago it said my PC had passed the tests--now > it says it is downloading. > > Speed and responsiveness "feels" normal. Screen popped up just now--said something to effect of "Now or later?" I said later (haven't been to been in a while, have three other machines to coordinate with). It offered me later today, tomorrow, or the next day! This may hurt after all. -- sed quis custodiet ipsos custodes? (Juvenal) From colton.conor at gmail.com Wed Jul 29 13:27:16 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 29 Jul 2015 08:27:16 -0500 Subject: DOCSIS CMTS Systems Message-ID: We are servicing more MDU customers that have older buildings. There is no CAT5E installed, so extremely old phone cable or coaxial TV cable seems to be our only inside wire options. There is no easy and inexpensive way to run new cable, so we must deal with what is available. We are very familiar with the VDSL2 offerings to be able to use the phone cable, but know nothing about CMTS solutions available.DOCSIS 3.0 capable modems seem to be much more inexpensive than VDSL2 capable modems. We are looking for recommendations on small CMTS systems for MDU's. I would expect we would want at least DOCSIS 3.0 capabilities, and I assume DOCSIS 3.1 is too new and expensive to deploy on a small scale (think 50 to 200 units per property). We would need the full solution to manage and maintain such an offering. I was thinking something like this might be a good fit: http://www.picodigital.com/product-details.php?ID=miniCMTS200a which is available new for $4500 online. For those of you deploying CMTS systems what do you use and recommend? I am not sure if there is a cable equivalent list to NANOG, but if so please let me know. From khelms at zcorum.com Wed Jul 29 13:38:33 2015 From: khelms at zcorum.com (Scott Helms) Date: Wed, 29 Jul 2015 09:38:33 -0400 Subject: DOCSIS CMTS Systems In-Reply-To: References: Message-ID: Colton, Pico is a decent solution, Harmonic has one too ( http://www.harmonicinc.com/product/cable-edge/nsg-exo). As for cable specific lists, about the closest I know about is the SCTE mailing list. http://www.scte.org/SCTE/Resources/SCTE_Lists.aspx Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Wed, Jul 29, 2015 at 9:27 AM, Colton Conor wrote: > We are servicing more MDU customers that have older buildings. There is no > CAT5E installed, so extremely old phone cable or coaxial TV cable seems to > be our only inside wire options. There is no easy and inexpensive way to > run new cable, so we must deal with what is available. > > We are very familiar with the VDSL2 offerings to be able to use the phone > cable, but know nothing about CMTS solutions available.DOCSIS 3.0 capable > modems seem to be much more inexpensive than VDSL2 capable modems. > > We are looking for recommendations on small CMTS systems for MDU's. I > would expect we would want at least DOCSIS 3.0 capabilities, and I > assume DOCSIS 3.1 is too new and expensive to deploy on a small scale > (think 50 to 200 units per property). We would need the full solution to > manage and maintain such an offering. > > I was thinking something like this might be a good fit: > http://www.picodigital.com/product-details.php?ID=miniCMTS200a which is > available new for $4500 online. > > For those of you deploying CMTS systems what do you use and recommend? > > I am not sure if there is a cable equivalent list to NANOG, but if so > please let me know. > > > > From alejandroacostaalamo at gmail.com Wed Jul 29 14:13:29 2015 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Wed, 29 Jul 2015 09:43:29 -0430 Subject: Windows 10 Release In-Reply-To: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <55B8DF89.6050207@gmail.com> El 7/28/2015 a las 4:15 PM, Nick Olsen escribi?: > Anyone anxious to see what kind of traffic comes from Windows 10 releasing > tomorrow? > > Being a 3-4GB download. Each device is moving more data than any Apple > update ever did. Wow, to download 3-4 GB in a developing country (like mine - Venezuela) where there still 512 kbps -2 Mbps links for home users (and some offices too) it will have a significant impact.. I hope they are considering this in somehow. Imagine more than one Microsoft 10 in a home.., it will never end :-) > > Wonder if they'll stage the release as apple appeared to have learned > after IOS7 hammered a bunch of networks. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > Alejandro Acosta, From frnkblk at iname.com Wed Jul 29 14:49:08 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Wed, 29 Jul 2015 09:49:08 -0500 Subject: DOCSIS CMTS Systems In-Reply-To: References: Message-ID: <000501d0ca0d$bbababc0$33030340$@iname.com> Colton, While we have never tried it ourselves, an option we've looked at in similar situations are these: http://www.ready-links.com/ipc1840c.html http://www.bectechnologies.net/main/EoCoax2310.shtml (up to 31 endpoints) Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Wednesday, July 29, 2015 8:27 AM To: NANOG ; Scott Helms Subject: DOCSIS CMTS Systems We are servicing more MDU customers that have older buildings. There is no CAT5E installed, so extremely old phone cable or coaxial TV cable seems to be our only inside wire options. There is no easy and inexpensive way to run new cable, so we must deal with what is available. We are very familiar with the VDSL2 offerings to be able to use the phone cable, but know nothing about CMTS solutions available.DOCSIS 3.0 capable modems seem to be much more inexpensive than VDSL2 capable modems. We are looking for recommendations on small CMTS systems for MDU's. I would expect we would want at least DOCSIS 3.0 capabilities, and I assume DOCSIS 3.1 is too new and expensive to deploy on a small scale (think 50 to 200 units per property). We would need the full solution to manage and maintain such an offering. I was thinking something like this might be a good fit: http://www.picodigital.com/product-details.php?ID=miniCMTS200a which is available new for $4500 online. For those of you deploying CMTS systems what do you use and recommend? I am not sure if there is a cable equivalent list to NANOG, but if so please let me know. From cmaurand at xyonet.com Wed Jul 29 14:59:16 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 29 Jul 2015 10:59:16 -0400 Subject: DOCSIS CMTS Systems In-Reply-To: <000501d0ca0d$bbababc0$33030340$@iname.com> References: <000501d0ca0d$bbababc0$33030340$@iname.com> Message-ID: <55B8EA44.10301@xyonet.com> Seriously nice solutions...both of them. --Curtis On 7/29/2015 10:49 AM, frnkblk at iname.com wrote: > Colton, > > While we have never tried it ourselves, an option we've looked at in similar situations are these: > http://www.ready-links.com/ipc1840c.html > http://www.bectechnologies.net/main/EoCoax2310.shtml (up to 31 endpoints) > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor > Sent: Wednesday, July 29, 2015 8:27 AM > To: NANOG ; Scott Helms > Subject: DOCSIS CMTS Systems > > We are servicing more MDU customers that have older buildings. There is no > CAT5E installed, so extremely old phone cable or coaxial TV cable seems to > be our only inside wire options. There is no easy and inexpensive way to > run new cable, so we must deal with what is available. > > We are very familiar with the VDSL2 offerings to be able to use the phone > cable, but know nothing about CMTS solutions available.DOCSIS 3.0 capable > modems seem to be much more inexpensive than VDSL2 capable modems. > > We are looking for recommendations on small CMTS systems for MDU's. I would > expect we would want at least DOCSIS 3.0 capabilities, and I assume DOCSIS > 3.1 is too new and expensive to deploy on a small scale (think 50 to 200 > units per property). We would need the full solution to manage and maintain > such an offering. > > I was thinking something like this might be a good fit: > http://www.picodigital.com/product-details.php?ID=miniCMTS200a which is > available new for $4500 online. > > For those of you deploying CMTS systems what do you use and recommend? > > I am not sure if there is a cable equivalent list to NANOG, but if so > please let me know. > > -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From bill at herrin.us Wed Jul 29 15:01:17 2015 From: bill at herrin.us (William Herrin) Date: Wed, 29 Jul 2015 11:01:17 -0400 Subject: Working with Spamhaus In-Reply-To: References: Message-ID: On Tue, Jul 28, 2015 at 11:39 PM, Bryan Tong wrote: > I wouldnt have such a disheartened attitude if they would have been > specific or given time to comply. > > eSited LLC > (701) 390-9638 Hi Brian, eSited has 37 unresolved spam listings with Spamhaus, all documented and some going as far back as 2013. You got a problem boss. In your position, I would start with "This list of customers has been terminated for spamming. The hacks on these customers' servers have been resolved. The following blocks are each used by multiple customers. Can you help me get a better idea which one is spamming so I can end it?" Next, consider blocking outbound tcp port 25 by default and adding exceptions upon customer request. Like a swimming pool, SMTP is an attractive nuisance. You really have to take active steps to avoid trouble. If you have the tools, consider also capturing a day's email outbound from your network and examine one random message for each origin. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From nanogml at Mail.DDoS-Mitigator.net Wed Jul 29 15:24:50 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Wed, 29 Jul 2015 08:24:50 -0700 Subject: DOCSIS CMTS Systems In-Reply-To: <55B8EA44.10301@xyonet.com> References: <000501d0ca0d$bbababc0$33030340$@iname.com> <55B8EA44.10301@xyonet.com> Message-ID: <20150729152450.GA31600@Mail.DDoS-Mitigator.net> hi On 07/29/15 at 10:59am, Curtis Maurand wrote: > Seriously nice solutions...both of them. .. > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor > >Sent: Wednesday, July 29, 2015 8:27 AM > >To: NANOG ; Scott Helms > >Subject: DOCSIS CMTS Systems > > > >We are servicing more MDU customers that have older buildings. There is no > >CAT5E installed, so extremely old phone cable or coaxial TV cable seems to > >be our only inside wire options. There is no easy and inexpensive way to > >run new cable, so we must deal with what is available. is internal corp wifi an option for internal users w/o cat5e ?? - be sure to only allow as many IP# as needed, not the entire 192.168.0.0 pixie dust alvin From frnkblk at iname.com Wed Jul 29 15:30:20 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Wed, 29 Jul 2015 10:30:20 -0500 Subject: DDOS Simulation In-Reply-To: <12A60E2B-76CE-4190-9FCD-A1DDB44F165C@the-watsons.org> References: <1438104249.2773720.335462665.02614C75@webmail.messagingengine.com> <12A60E2B-76CE-4190-9FCD-A1DDB44F165C@the-watsons.org> Message-ID: <000d01d0ca13$7cc06f80$76414e80$@iname.com> If the customer has headroom on a 10G link, what's the harm with running a 1G volumetric DDoS across the Internet? Or if it's application layer, anytime against prescribed lab devices? Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brett Watson Sent: Tuesday, July 28, 2015 8:28 PM To: nanog at nanog.org Subject: Re: DDOS Simulation > On Jul 28, 2015, at 9:05 PM, jim deleskie wrote: > > If anyone offers to "test" your DDoS devices across a network that you do > not 100% own, you are risking legal issues. > > If they offer to test it across your own network, make sure you have in > writing from you upper management that they understand the risk and approve > it. > > If you choose to do it anyway then you are taking a LARGE risk. > > > Testing should be in your lab and even then you should understand 100% what > is happing to avoid leaking attack traffic into the internet. in a previous job (we did ddos mitigation) customer asked all the time for simulation, and typically live across the internet. for all the reasons noted, we didn?t do it, but instead would do a lab/POC with pcaps replayed from previous attacks we had mitigated to show the customer how our platform worked, how we handled incident response, etc. agree with all comments about NOT doing it over the internet, that way lies madness. -b From frnkblk at iname.com Wed Jul 29 15:30:20 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Wed, 29 Jul 2015 10:30:20 -0500 Subject: Windows 10 Release In-Reply-To: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <000e01d0ca13$7d9af100$78d0d300$@iname.com> Some concern expressed here: http://blog.streamingmedia.com/2015/07/windows-10-launch-huge-traffic.html Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Olsen Sent: Tuesday, July 28, 2015 3:45 PM To: nanog at nanog.org Subject: Windows 10 Release Anyone anxious to see what kind of traffic comes from Windows 10 releasing tomorrow? Being a 3-4GB download. Each device is moving more data than any Apple update ever did. Wonder if they'll stage the release as apple appeared to have learned after IOS7 hammered a bunch of networks. Nick Olsen Network Operations (855) FLSPEED x106 From colton.conor at gmail.com Wed Jul 29 15:31:21 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 29 Jul 2015 10:31:21 -0500 Subject: DOCSIS CMTS Systems In-Reply-To: <55B8EA44.10301@xyonet.com> References: <000501d0ca0d$bbababc0$33030340$@iname.com> <55B8EA44.10301@xyonet.com> Message-ID: So the BEC solution I would assume is just standard MOCA or HPNA based as it is max 200Mbps, but the Ready-Links solution claims 1Gbps. Has anyone used the Ready-Links solution? Seem to good to be true. On Wed, Jul 29, 2015 at 9:59 AM, Curtis Maurand wrote: > Seriously nice solutions...both of them. > > --Curtis > > On 7/29/2015 10:49 AM, frnkblk at iname.com wrote: > >> Colton, >> >> While we have never tried it ourselves, an option we've looked at in >> similar situations are these: >> http://www.ready-links.com/ipc1840c.html >> http://www.bectechnologies.net/main/EoCoax2310.shtml (up to 31 endpoints) >> >> Frank >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor >> Sent: Wednesday, July 29, 2015 8:27 AM >> To: NANOG ; Scott Helms >> Subject: DOCSIS CMTS Systems >> >> We are servicing more MDU customers that have older buildings. There is no >> CAT5E installed, so extremely old phone cable or coaxial TV cable seems to >> be our only inside wire options. There is no easy and inexpensive way to >> run new cable, so we must deal with what is available. >> >> We are very familiar with the VDSL2 offerings to be able to use the phone >> cable, but know nothing about CMTS solutions available.DOCSIS 3.0 capable >> modems seem to be much more inexpensive than VDSL2 capable modems. >> >> We are looking for recommendations on small CMTS systems for MDU's. I >> would >> expect we would want at least DOCSIS 3.0 capabilities, and I assume DOCSIS >> 3.1 is too new and expensive to deploy on a small scale (think 50 to 200 >> units per property). We would need the full solution to manage and >> maintain >> such an offering. >> >> I was thinking something like this might be a good fit: >> http://www.picodigital.com/product-details.php?ID=miniCMTS200a which is >> available new for $4500 online. >> >> For those of you deploying CMTS systems what do you use and recommend? >> >> I am not sure if there is a cable equivalent list to NANOG, but if so >> please let me know. >> >> >> > -- > Best Regards > Curtis Maurand > Principal > Xyonet Web Hosting > mailto:cmaurand at xyonet.com > http://www.xyonet.com > > From A.L.M.Buxey at lboro.ac.uk Wed Jul 29 16:54:19 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Wed, 29 Jul 2015 17:54:19 +0100 Subject: Windows 10 Release In-Reply-To: <000e01d0ca13$7d9af100$78d0d300$@iname.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> <000e01d0ca13$7d9af100$78d0d300$@iname.com> Message-ID: <5C9C77A0-0426-4F09-A167-65FB02B33F94@lboro.ac.uk> 'QoS problems are to be expected' . Uh? Don't you put QoS into place just to ensure that the minimum bandwidth you need to ensure critical services (such that your voice traffic is not impeded for example) are NOT affected across your WAN links when there are big globs of data banging around? Surely, If anything, this is the one case and time when the QoS deployment effort can be shown to have value (obviously the policies would already have been validated against saturated links as part of sign off) alan From bob at FiberInternetCenter.com Wed Jul 29 17:06:46 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 29 Jul 2015 10:06:46 -0700 Subject: Working with Spamhaus In-Reply-To: <20150729065351.GZ20260@hezmatt.org> References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> <20150729065351.GZ20260@hezmatt.org> Message-ID: Would be nice to have an RBL service that attended NANOG meetings. Would make for a more trusted RBL we can tell customers to make use. Spamhaus ever attend a NANOG meetings ? Thank You Bob Evans CTO > On Tue, Jul 28, 2015 at 11:41:08PM -0600, Bryan Tong wrote: >> Yes that is part of it. >> >> There are other blocks they listed as well. > > Well, http://www.spamhaus.org/sbl/query/SBL263089 has a fair amount of > shady > stuff going on, and http://www.spamhaus.org/sbl/listings/esited.com gives > a > pretty decent history of what Spamhaus has been doing. Note the > "(escalation)" entries in there, which indicates a lack of interest on > esited.com's part in fixing any of the problems. > > - Matt > > From ops.lists at gmail.com Wed Jul 29 17:14:49 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 29 Jul 2015 10:14:49 -0700 Subject: Working with Spamhaus In-Reply-To: References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> <20150729065351.GZ20260@hezmatt.org> Message-ID: They come to M3AAWG on a regular basis and there?s the M3AAWG hosting SIG that you might want to participate in. NANOG doesn?t always have a mail abuse (and not very many network abuse) session on the agenda, plus just how many people doing routing or DNS seem to even care what their colleagues down the hall in the abuse team are doing or which conferences they attend? I remember a time (under the previous list management) when discussing spam here was deemed OT and non operational - off list warnings, suspensions and such. Ancient history I guess, but still .. ?srs > On 29-Jul-2015, at 10:06 AM, Bob Evans wrote: > > Would be nice to have an RBL service that attended NANOG meetings. > Would make for a more trusted RBL we can tell customers to make use. > Spamhaus ever attend a NANOG meetings ? > Thank You > Bob Evans > CTO From fergdawgster at mykolab.com Wed Jul 29 17:23:07 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 29 Jul 2015 10:23:07 -0700 Subject: Working with Spamhaus In-Reply-To: References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> <20150729065351.GZ20260@hezmatt.org> Message-ID: <55B90BFB.8020303@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I agree with Suresh here -- NANOG used to almost be somewhat hostile to anyone who started discussions regarding anti-abuse and/or security issues which didn't involve routing backbone engineers. A lot of us old-timers took the hint and basically started lurking, not participating in meetings, or simply checked out of NANOG altogether . A lot of time has passed sine those days, so perhaps attitudes have changed a bit with regards to operational anti-abuse issues? - - ferg On 7/29/2015 10:14 AM, Suresh Ramasubramanian wrote: > > > They come to M3AAWG on a regular basis and there?s the M3AAWG > hosting SIG that you might want to participate in. > > NANOG doesn?t always have a mail abuse (and not very many network > abuse) session on the agenda, plus just how many people doing > routing or DNS seem to even care what their colleagues down the > hall in the abuse team are doing or which conferences they attend? > > I remember a time (under the previous list management) when > discussing spam here was deemed OT and non operational - off list > warnings, suspensions and such. Ancient history I guess, but still > .. > > > > ?srs > >> On 29-Jul-2015, at 10:06 AM, Bob Evans >> wrote: >> >> Would be nice to have an RBL service that attended NANOG >> meetings. Would make for a more trusted RBL we can tell customers >> to make use. Spamhaus ever attend a NANOG meetings ? Thank You >> Bob Evans CTO > > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlW5C/oACgkQKJasdVTchbJ3OwD9FhTx7QQ42UGIAjd6e9ajhQ2U Z0I8gOqO32xZACwVaEYBAJwZujweC+fiSk4uSEtgDkIXpbQFWSfvkjpzB96fkI4y =4qS3 -----END PGP SIGNATURE----- From fergdawgster at mykolab.com Wed Jul 29 17:23:39 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 29 Jul 2015 10:23:39 -0700 Subject: Working with Spamhaus In-Reply-To: References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> <20150729065351.GZ20260@hezmatt.org> Message-ID: <55B90C1B.3060802@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I agree with Suresh here -- NANOG used to almost be somewhat hostile to anyone who started discussions regarding anti-abuse and/or security issues which didn't involve routing backbone engineers. A lot of us old-timers took the hint and basically started lurking, not participating in meetings, or simply checked out of NANOG altogether . A lot of time has passed since those days, so perhaps attitudes have changed a bit with regards to operational anti-abuse issues? - - ferg On 7/29/2015 10:14 AM, Suresh Ramasubramanian wrote: > > > They come to M3AAWG on a regular basis and there?s the M3AAWG > hosting SIG that you might want to participate in. > > NANOG doesn?t always have a mail abuse (and not very many network > abuse) session on the agenda, plus just how many people doing > routing or DNS seem to even care what their colleagues down the > hall in the abuse team are doing or which conferences they attend? > > I remember a time (under the previous list management) when > discussing spam here was deemed OT and non operational - off list > warnings, suspensions and such. Ancient history I guess, but > still .. > > > > ?srs > >> On 29-Jul-2015, at 10:06 AM, Bob Evans >> wrote: >> >> Would be nice to have an RBL service that attended NANOG >> meetings. Would make for a more trusted RBL we can tell >> customers to make use. Spamhaus ever attend a NANOG meetings ? >> Thank You Bob Evans CTO > > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlW5DBsACgkQKJasdVTchbIznQD/ac/bMc2uzpkqgFNlMpP9V8Qk yJylbEqt3Nzxt2qFF7ABALwN56oZzdgL4iFFDVh6lHUjJSgcltu9xZIvEv8qbg3c =M2x5 -----END PGP SIGNATURE----- From bob at FiberInternetCenter.com Wed Jul 29 17:37:26 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 29 Jul 2015 10:37:26 -0700 Subject: Working with Spamhaus In-Reply-To: References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> <20150729065351.GZ20260@hezmatt.org> Message-ID: <7c0000ab2a8a16efd3a46d7e24efa9ea.squirrel@66.201.44.180> I see that point - however, spamhaus has become a haus-hold word these days and everyone runs into these issues....its not malware or bots we block from a network level blackhole. Yet it is basic network operations these days to have to deal with someone complaining about their hacked mail server is now fixed yet they cant get mail. We usually tell them the quickest way is to address spamhaus to get it removed and in parallel also move the mail server to a new IP and change the dns and rDNS to the new one. It gets us out of having to help with these RBL issues. When an RBL sends a notice we jump on it and get it to the customer...however, they usually dont send us or the customer anything. Thank You Bob Evans CTO > > > They come to M3AAWG on a regular basis and there???s the M3AAWG hosting > SIG that you might want to participate in. > > NANOG doesn???t always have a mail abuse (and not very many network abuse) > session on the agenda, plus just how many people doing routing or DNS seem > to even care what their colleagues down the hall in the abuse team are > doing or which conferences they attend? > > I remember a time (under the previous list management) when discussing > spam here was deemed OT and non operational - off list warnings, > suspensions and such. Ancient history I guess, but still .. > > > > ???srs > >> On 29-Jul-2015, at 10:06 AM, Bob Evans >> wrote: >> >> Would be nice to have an RBL service that attended NANOG meetings. >> Would make for a more trusted RBL we can tell customers to make use. >> Spamhaus ever attend a NANOG meetings ? >> Thank You >> Bob Evans >> CTO > > From tiernan at tiernanotoole.net Wed Jul 29 14:20:26 2015 From: tiernan at tiernanotoole.net (Tiernan OToole) Date: Wed, 29 Jul 2015 15:20:26 +0100 Subject: Windows 10 Release In-Reply-To: <55B8DF89.6050207@gmail.com> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> <55B8DF89.6050207@gmail.com> Message-ID: <55B8E12A.40609@tiernanotoole.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 You can download an ISO and burn it to install... Guessing if your upgrading multiple machines, that would be the way to go... - --Tiernan On 29/07/2015 15:13, Alejandro Acosta wrote: > El 7/28/2015 a las 4:15 PM, Nick Olsen escribi?: >> Anyone anxious to see what kind of traffic comes from Windows 10 >> releasing tomorrow? >> >> Being a 3-4GB download. Each device is moving more data than any >> Apple update ever did. > > Wow, to download 3-4 GB in a developing country (like mine - > Venezuela) where there still 512 kbps -2 Mbps links for home users > (and some offices too) it will have a significant impact.. I hope > they are considering this in somehow. Imagine more than one > Microsoft 10 in a home.., it will never end :-) > >> >> Wonder if they'll stage the release as apple appeared to have >> learned after IOS7 hammered a bunch of networks. >> >> Nick Olsen Network Operations (855) FLSPEED x106 >> >> > > Alejandro Acosta, > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVuOEqAAoJECWDUKjOk5r1fJsP/AjElUH+ODkEGPQqMg2I5bjU t0lcPzhfrVw7cmiEQK9zgN83NxvkW+DKTBFcopoHkTauvCC7B179dxrL6EcNNOqu ajZAzOCvRHBHPCR6k8BxWC1fjKVXntuMf+SUhL0Y/fGdtwaaAT1jOzPx86aZFFDB 3syDwH13v7SzftGDbZ15B4jjmFwSBp/AI5uS+uYE5SUuQXBLLCuOmVORsDX6u9Eq kzPZr4TcmUxS40fPipaQtaGt4/VFukr6BZD9GrOQInioOOIi1sIpqX1vETIpEXRb nP9eTcAvrlpyPFKZ/m+tYMTshE3iCCXTCHDnCXI1/v2FFPZoJREmOHaFe7ouIz7B 6ZfqLGHZ+atxC/mD9LhkYuxN6NaVDtNLWnBHMGke6A1Q37F/snZqksMyUEcUAl+l lvrVepSsfENEkSoX/VuGQ952NqTqECZ8uEfJcrDts9D6tq9K5bbJRhBMGBW4FQhI NVxviK758rquYrwnh6HZp/DFUxBizZcbsJIwJOVa27v3Jm45srlQOwt4f/FB9mPh o1rX87CsE/+685Rn6VDv4rNOeUsEblg8VTNuktzgAf/BCw5nTjAHYVrytVGPtT8c KKTslmV3XLlzWR6jSSOezHpkEfGARfe5FHek7NT2i/TQhSlJhXdmtaPJC5Ar3pkn AojjK+3RyBm76k0bXzg0 =Imhd -----END PGP SIGNATURE----- From jbaldwin at antinode.net Wed Jul 29 18:27:03 2015 From: jbaldwin at antinode.net (James Baldwin) Date: Wed, 29 Jul 2015 13:27:03 -0500 Subject: Level3 routing issues In-Reply-To: References: Message-ID: Since 7:30AM CDT Friday morning, we've seen strange problems across L3 where around 1-2% of traffic flows are dying. It is interesting behavior in that new flows from the same source to the same destination work, however, in the cases where the traffic is stopped we never receive the SYN-ACK nor any of the retransmits. The destination side continues to receive the SYN retransmits. On Wed, Jul 29, 2015 at 6:52 AM, Robert Blayzor via NANOG wrote: > On Jul 28, 2015, at 8:54 PM, Matt Hoppes > wrote: > > > > Is anyone seeing packet loss or routing issues on the Level3 network on > the east coast right now? > > > > > > > We?ve seen a slew of problems going west out of Level3 in NYC the last > couple of nights. Last night was particularly bad to the point we had to > shut our Level3 BGP sessions down to route around the issue. > > -- > Robert > inoc.net!rblayzor > Jabber: rblayzor.AT.inoc.net > PGP Key: 78BEDCE1 @ pgp.mit.edu > > > > > From jbaldwin at antinode.net Wed Jul 29 18:28:00 2015 From: jbaldwin at antinode.net (James Baldwin) Date: Wed, 29 Jul 2015 13:28:00 -0500 Subject: Level3 routing issues In-Reply-To: References: Message-ID: Edit: It is interesting behavior in that new flows from the same source to the same destination work are successful... On Wed, Jul 29, 2015 at 1:27 PM, James Baldwin wrote: > Since 7:30AM CDT Friday morning, we've seen strange problems across L3 > where around 1-2% of traffic flows are dying. It is interesting behavior in > that new flows from the same source to the same destination work, however, > in the cases where the traffic is stopped we never receive the SYN-ACK nor > any of the retransmits. The destination side continues to receive the SYN > retransmits. > > On Wed, Jul 29, 2015 at 6:52 AM, Robert Blayzor via NANOG > wrote: > >> On Jul 28, 2015, at 8:54 PM, Matt Hoppes >> wrote: >> > >> > Is anyone seeing packet loss or routing issues on the Level3 network on >> the east coast right now? >> > >> > >> >> >> We?ve seen a slew of problems going west out of Level3 in NYC the last >> couple of nights. Last night was particularly bad to the point we had to >> shut our Level3 BGP sessions down to route around the issue. >> >> -- >> Robert >> inoc.net!rblayzor >> Jabber: rblayzor.AT.inoc.net >> PGP Key: 78BEDCE1 @ pgp.mit.edu >> >> >> >> >> > From rpug at lp0.org Wed Jul 29 18:31:43 2015 From: rpug at lp0.org (Ryan Pugatch) Date: Wed, 29 Jul 2015 14:31:43 -0400 Subject: Level3 routing issues In-Reply-To: References: Message-ID: <1438194703.271666.336553401.215A1936@webmail.messagingengine.com> We're actually seeing some problems coming from the Boston area, going to Cisco WebEx. We keep ending up going to Level 3 NY and dying, intermittently. Unfortunately, both of our peers, Level3 and XO, end up going to the same place from Boston. If I go to WebEx from a device in Florida, we end up going via Level3 in Washington DC and are fine. On Wed, Jul 29, 2015, at 07:52 AM, Robert Blayzor via NANOG wrote: > On Jul 28, 2015, at 8:54 PM, Matt Hoppes > wrote: > > > > Is anyone seeing packet loss or routing issues on the Level3 network on the east coast right now? > > > > > > > We?ve seen a slew of problems going west out of Level3 in NYC the last > couple of nights. Last night was particularly bad to the point we had to > shut our Level3 BGP sessions down to route around the issue. > > -- > Robert > inoc.net!rblayzor > Jabber: rblayzor.AT.inoc.net > PGP Key: 78BEDCE1 @ pgp.mit.edu > > > > From ops.lists at gmail.com Wed Jul 29 18:42:19 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 29 Jul 2015 11:42:19 -0700 Subject: Working with Spamhaus In-Reply-To: <7c0000ab2a8a16efd3a46d7e24efa9ea.squirrel@66.201.44.180> References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> <20150729065351.GZ20260@hezmatt.org> <7c0000ab2a8a16efd3a46d7e24efa9ea.squirrel@66.201.44.180> Message-ID: <41F36625-82D1-4BD7-811A-3EB80F08E04D@gmail.com> Er - a couple of ways 1. If you run a farm of mail servers, something like splunk for your logs is kind of necessary. How difficult is it going to be to trigger a splunk alert on whatever looks like an administrative block? Either by a large provider, or by a DNS block list. 2. You can rsync spamhaus and grep for mentions of your ASN, get ISP feedback loops etc. On a larger topic - NANOG and M3AAWG (also RIPE and M3AAWG?s summer meeting in Europe) really ought to collocate or at least be back to back in the same city somewhere down the line - maybe with a day?s worth of joint sessions on topics of mutual interest (malware detection and mitigation, DDoS filtering .. there?s a lot going on in M3AAWG that?s not plain old mail or even messaging) It still won?t solve the larger problem that a lot of routing and DNS folks won?t find it of interest, but well, over the decade ++ I?ve been around M3AAWG I see an ever increasing number of (security focused, mainly) *nog regulars turn up there. ?srs > On 29-Jul-2015, at 10:37 AM, Bob Evans wrote: > > I see that point - however, spamhaus has become a haus-hold word these > days and everyone runs into these issues....its not malware or bots we > block from a network level blackhole. Yet it is basic network operations > these days to have to deal with someone complaining about their hacked > mail server is now fixed yet they cant get mail. We usually tell them the > quickest way is to address spamhaus to get it removed and in parallel also > move the mail server to a new IP and change the dns and rDNS to the new > one. It gets us out of having to help with these RBL issues. > > When an RBL sends a notice we jump on it and get it to the > customer...however, they usually dont send us or the customer anything. From nanogml at Mail.DDoS-Mitigator.net Wed Jul 29 19:38:18 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Wed, 29 Jul 2015 12:38:18 -0700 Subject: DDOS Simulation In-Reply-To: References: <20150728221940.GA25835@Mail.DDoS-Mitigator.net> Message-ID: <20150729193818.GA32446@Mail.DDoS-Mitigator.net> hi roland On 07/29/15 at 05:47am, Roland Dobbins wrote: > > On 29 Jul 2015, at 5:19, alvin nanog wrote: > > >as previously noted by others, legit corp will ask you for lots of > >legal paperwork for their "get out of jail card" for DDoS'ing your > >servers > >and all the other ISP's routers along the way that had to transport > >those gigabyte/terabyte of useless ddos packets > > No company can provide a 'get out of jail card' for illegal activities, > irrespective of how they arrange their paperwork. oopps, maybe a "misunderstanding" ... it's an old "be careful euphomism(sp?) and not meant as "literal get out of jail" ( from monopoly game too ) - it's intended as make sure the corp lawyers are involved that is requesting the ddos simulation/testing ( aka pen testing ) - managers/employee/contractors cannot say or sign anything that binds the company to what the managers said/request - only officers of the company can bind the company that they will not press charges for the "ddos (pen) tests" - po's are usually valid since the CFO is an officer of the company > DDoS testing across the Internet is a Big No-No due to legal considerations, > potential liabilities, potential for catastrophic error, etc. yes, along with all the other isp's involved along the way between "ddos testor" and corp-under-test.com > Doing it across one's own network which one controls is certainly viable. definitely and should be the place to start put your ddos simulator hardware in parallel to your cisco/juniper uplink to the isp and simulate for the next few decades :-) > There are some companies which do that, and which take a belt-and-suspenders > approach to ensure that simulated attack traffic doesn't leak, etc. all computers are under 24x7x365 ddos attacks every minute and they already provide the free "real world" and luckily low level DDoS attacks for free you should figure out how to find those free ddos attacks and how to mitigate the script kiddies already providing the free initial ddos simulation there is no need to pay people to attack your servers ... - tcpdump and wireshark will tell you everything the attackers are doing to your network right now that needs to be defended against # if you are a web server, it is currently under (free) DDoS attack tcpdump -n -l dst host www.example.com and ! dst port 80 # if you are a mail server, it is currently under (free) DDoS attack tcpdump -n -l dst host mail.example.com and ! dst port 25 - a small exercise to clean up the tcpdump output if a mid-level wanna be attacker wants to target your servers, they're just as equally easy to mitigate and prevent and probably sending you 100,000 "ddos packets" per second because they can ( bigger zombie network :-) - you should notice some slow responses from your servers if you are being targeted by "masters of deception" you have no solution other than get local law enforcement involved to track down the originating attackers all ddos mitigations is almost 100% guaranteed to fail a volumetric DDoS attacks .... the DDoS attackrs probably have access to a bigger zombie network than most major corp ... the attackers job is not to get caught and is not ez to be hiding if law enforcement wanted to catch them :-) problem is the attackers have to be bothersome to somebody before they start chasing down the attackers .. the rest of us has to fend for ourself > Simulated DDoS attacks and testing of defenses should be part of any real > development environment, along with scalability testing in general. Sadly, > this is rarely the case. yup :-) > The best way to learn how to defend something is to learn how to attack it. exactly .... you cannot defend against something you don't understand or don't know about that attack vector different folks defintely attack and/or test for different things - get different folks to do the testing if i had to pick only one command for the ddos tests .... i'd simply flood the wire .. everything is now offline ( should be un-responsive ) nping "send 100,000 packets/sec" x 65,000byte/packet 192.168.0.0/16 nping can create all kinds of headaches since you can attack almost anything ... most prototcols, most src/dst ip# and ports by the same premise, if i had to pick ONE ddos mitigation strategy, i'd tarpit all incoming TCP-based ddos attacks which should crash the attacking zombie server under sustained tcp-based ddos attacks > Organizations with substantial Internet properties should develop their own > organic capabilities to perform such testing in a safe and responsible > manner, as it will also enhance the skills needed to defend said properties. > ----------------------------------- > Roland Dobbins yup magic pixie dust alvin - http://DDoS-Mitigator.net - http://DDoS-Simulator.net From rdobbins at arbor.net Wed Jul 29 20:05:28 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 30 Jul 2015 03:05:28 +0700 Subject: DDOS Simulation In-Reply-To: <20150729193818.GA32446@Mail.DDoS-Mitigator.net> References: <20150728221940.GA25835@Mail.DDoS-Mitigator.net> <20150729193818.GA32446@Mail.DDoS-Mitigator.net> Message-ID: <5A733F6C-9D5E-4E19-A18C-B787D9A71A89@arbor.net> On 30 Jul 2015, at 2:38, alvin nanog wrote: > there is no need to pay people to attack your servers ... Unless you don't have the expertise to do it yourself. Again, I advocate an organic defense capability and an organic testing capability, but there are many organizations which unfortunately don't have these, and they must start somewhere. > - tcpdump and wireshark will tell you everything the attackers are > doing to your network right now that needs to be defended against On small, single-homed networks, sure. On networks of any size, this doesn't scale. Flow telemetry scales. > if a mid-level wanna be attacker wants to target your servers, they're > just as equally easy to mitigate and prevent and probably sending you > 100,000 "ddos packets" per second because they can ( bigger zombie > network :-) 100kpps is nothing. Of course, so many servers/services are so brittle, fragile, and non-scalable that most DDoS attacks are overkill by orders of magnitude. > if you are being targeted by "masters of deception" you have no > solution > other than get local law enforcement involved to track down the > originating > attackers I'm not sure who or what 'masters of deception' are in this context, but attribution has nothing to do with DDoS defense. Defending against serious attackers with lots of resources is taking place every minute of every hour of every day. There are many techniques and tools available, most of which have been discussed multiple times on this list over the years. Here's one such example: > all ddos mitigations is almost 100% guaranteed to fail a volumetric > DDoS attacks .... This is incorrect. > the DDoS attackrs probably have access to a bigger zombie > network than most major corp ... This is true, in many cases - and is also not an issue for properly-provisioned, coordinated DDoS defense mechanisms and methodologies. > the attackers job is not to get caught and > is not ez to be hiding if law enforcement wanted to catch them :-) Again, attribution is a completely separate issue. > nping "send 100,000 packets/sec" x 65,000byte/packet 192.168.0.0/16 FYI, 'line-rate' for 64-byte packets at 10gb/sec is ~14.8mpps. > by the same premise, if i had to pick ONE ddos mitigation strategy, > i'd > tarpit all incoming TCP-based ddos attacks which should crash the > attacking zombie server under sustained tcp-based ddos attacks There is no one tactic (this is not a strategy) which can be picked, as any kind of traffic can be used for DDoS attacks. With regards to TCP-based attacks, it's a subset of those which are connection-oriented and are thus susceptible to tarpitting-type techniques. ----------------------------------- Roland Dobbins From jcurran at arin.net Wed Jul 29 20:11:24 2015 From: jcurran at arin.net (John Curran) Date: Wed, 29 Jul 2015 20:11:24 +0000 Subject: Note - ARIN Consultation on proposed Registration Services Agreement Now Open References: <55B931B3.30406@arin.net> Message-ID: NANOGers - To the extent that you are interested in ARIN's Registration Services Agreement, we have just initiated a consultation on a proposed new version of the RSA (and LRSA) as noted in the attached announcement. If you wish to provide any feedback, please do so on the > mailing list between now and 30 August 2015. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [ARIN-consult] Consultation on Registration Services Agreement Now Open Date: July 29, 2015 at 4:04:03 PM EDT To: > ARIN is seeking community input on a new version of the Registration Services Agreement that combines the existing Registration Services Agreement (RSA) and Legacy Registration Services Agreement (LRSA) into a single agreement (?RSA Version 12.0/LRSA Version 4.0?). Following community consultation and finalization, ARIN will provide services to new parties per this latest version of the Registration Services Agreement. Existing holders of Internet number resources will have the opportunity to upgrade to this new version of the Registration Services Agreement or remain with their current Registration Services Agreement. There are notable and substantive changes with this new version incorporating input received from the community on the Registration Services Agreements. These changes include: * Clarifying that the agreement is only applicable to ?Included Number Resources? (i.e. the Internet number resources pursuant to the agreement, not any other number resources that parties may hold under other agreements or no agreement) * Similarly clarifying that the provision wherein a Customer is agreeing that ?Included Number Resources? are not property is only applicable to ?Included Number Resources? in the agreement and remains silent with regard to any other number resources held by the party * Providing uniform service terms and conditions (other than fees) for all customers receiving services from ARIN * Elaborating on the definition of ARIN?s services that are covered by the agreement, including resource certification * Providing a more balanced agreement with respect to term language previously seen as favorable to ARIN The new RSA Version 12.0/LRSA Version 4.0 is available at the following URL: https://www.arin.net/resources/agreements/rsa_draft_ver12.pdf We strongly encourage you to review the current RSA and LRSA against the proposed version of this new agreement and to submit your constructive comments to arin-consult at arin.net. Discussion on arin-consult at arin.net will close on 30 August 2015. ARIN seeks clear direction through community input, so your feedback is important. If you have any questions, please contact us at info at arin.net. Thank you, /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From larrysheldon at cox.net Thu Jul 30 00:44:27 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 29 Jul 2015 19:44:27 -0500 Subject: Windows 10 Release In-Reply-To: References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> Message-ID: <55B9736B.8060506@cox.net> On 7/29/2015 10:30, frnkblk at iname.com wrote: > Some concern expressed here: > http://blog.streamingmedia.com/2015/07/windows-10-launch-huge-traffic.html I have no status above "out-of-work old fart", and it has been a while since I was engaged in anything bigger than my four-PC, three-wiffy, one router network who still does not like Microsoft very much, but it seems clear to me that a lot of Big Disaster Windows 10 Experts have not read anything about what is actually going on. So far, it has not worked here anything like what that article describes. -- sed quis custodiet ipsos custodes? (Juvenal) From randy at psg.com Thu Jul 30 02:12:51 2015 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jul 2015 11:12:51 +0900 Subject: Windows 10 Release In-Reply-To: <5d87e99f7e454768bdbad9221f36988e@TEC-MAIL1.granbury.k12.tx.us> References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com> <5d87e99f7e454768bdbad9221f36988e@TEC-MAIL1.granbury.k12.tx.us> Message-ID: http://www.metzdowd.com/pipermail/cryptography/2015-July/026136.html From jlewis at lewis.org Thu Jul 30 02:24:17 2015 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 29 Jul 2015 22:24:17 -0400 (EDT) Subject: Working with Spamhaus In-Reply-To: References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> <20150729065351.GZ20260@hezmatt.org> Message-ID: On Wed, 29 Jul 2015, Bob Evans wrote: > Would be nice to have an RBL service that attended NANOG meetings. > Would make for a more trusted RBL we can tell customers to make use. How do you know they don't? Most of them keep a low profile due to things like http://www.bizjournals.com/southflorida/stories/2003/05/12/story1.html?page=all ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jgreco at ns.sol.net Thu Jul 30 02:54:43 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 29 Jul 2015 21:54:43 -0500 (CDT) Subject: Windows 10 Release In-Reply-To: Message-ID: <201507300254.t6U2sipA086030@aurora.sol.net> > http://www.metzdowd.com/pipermail/cryptography/2015-July/026136.html Which appears to be about 25% crap, 30% FUD, and the remainder consists of concerns of varying levels of validity. For privacy-minded individuals who are not interested in sharing lots of stuff with Microsoft, there are install-time options to shut most of that off. Don't use "Express Settings." Select "Customize settings" and then turn most of the switches on the next two pages off. The real issue is that lots of people will select the "express settings" and then might have to do more work to undo the decisions made at this step on their behalf. I do think it is rotten that the defaults for the options are all "on." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From randy at psg.com Thu Jul 30 02:38:45 2015 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jul 2015 11:38:45 +0900 Subject: Windows 10 Release In-Reply-To: <201507300254.t6U2sipA086030@aurora.sol.net> References: <201507300254.t6U2sipA086030@aurora.sol.net> Message-ID: >> http://www.metzdowd.com/pipermail/cryptography/2015-July/026136.html > > Which appears to be about 25% crap, 30% FUD, and the remainder consists > of concerns of varying levels of validity. really? read the legal fine print https://edri.org/microsofts-new-small-print-how-your-personal-data-abused/ From ccosta at gaikai.com Thu Jul 30 02:39:12 2015 From: ccosta at gaikai.com (Christopher Costa) Date: Wed, 29 Jul 2015 19:39:12 -0700 Subject: Requesting to speak with a CableOne (AS11492) Contact Message-ID: Hoping to speak with CableOne (AS11492) regarding routing towards Gaikai (AS33353) in the Mississippi region. Please contact me offline. Thanks, Chris Costa Gaikai ccosta at gaikai.com From jgreco at ns.sol.net Thu Jul 30 02:58:38 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 29 Jul 2015 21:58:38 -0500 (CDT) Subject: Windows 10 Release In-Reply-To: <55B8E12A.40609@tiernanotoole.net> Message-ID: <201507300258.t6U2wds0086123@aurora.sol.net> > You can download an ISO and burn it to install... Guessing if your > upgrading multiple machines, that would be the way to go... You don't even need to burn it to install. Just mount the ISO and run setup.exe ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jlewis at lewis.org Thu Jul 30 02:56:08 2015 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 29 Jul 2015 22:56:08 -0400 (EDT) Subject: Working with Spamhaus In-Reply-To: <7c0000ab2a8a16efd3a46d7e24efa9ea.squirrel@66.201.44.180> References: <55B84E3E.8070105@cox.net> <55B852CE.3040601@cox.net> <20150729053717.GU20260@hezmatt.org> <20150729065351.GZ20260@hezmatt.org> <7c0000ab2a8a16efd3a46d7e24efa9ea.squirrel@66.201.44.180> Message-ID: On Wed, 29 Jul 2015, Bob Evans wrote: > I see that point - however, spamhaus has become a haus-hold word these > days and everyone runs into these issues....its not malware or bots we > block from a network level blackhole. Yet it is basic network operations > these days to have to deal with someone complaining about their hacked > mail server is now fixed yet they cant get mail. If their mail server was SBL'd due to being compromised by spammers, they likely can't send mail / get remote mail delivered. They should still be able to "get mail", i.e. receive mail. > We usually tell them the quickest way is to address spamhaus to get it > removed and in parallel also move the mail server to a new IP and change > the dns and rDNS to the new one. It gets us out of having to help with > these RBL issues. That (moving them to another IP) should really be a last resort if the DNSBL(s) they're on are not responsive to being told the issue has been resolved. Moving them without having resolved the issue would be even worse, as it'll make it look like you're complicit with the spammer who compromised the server (since you're helping them get around the DNSBLs). I did that once that I can remember, when one of $work's main SMTP servers was blocked by AOL, and when we reached out to AOL to ask why, their response was basically "Someone from our postmaster group will let you know why we're blocking you. It'll be at least a week before they can get to your ticket." ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jgreco at ns.sol.net Thu Jul 30 03:49:35 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 29 Jul 2015 22:49:35 -0500 (CDT) Subject: Windows 10 Release In-Reply-To: Message-ID: <201507300349.t6U3nZ8K086695@aurora.sol.net> > >> http://www.metzdowd.com/pipermail/cryptography/2015-July/026136.html > > > > Which appears to be about 25% crap, 30% FUD, and the remainder consists > > of concerns of varying levels of validity. > > really? read the legal fine print > > https://edri.org/microsofts-new-small-print-how-your-personal-data-abused/ Again, a lot of crap and FUD mixed in there. It's legalese designed to cover their arses, because they default the options to "On" and assume most people will take the default. You CAN shut off the sharing. The legalese doesn't mean that the information is shared despite the fact that you configured your box not to share it. The real problem is that so many people have outsourced their problems to ${THE_CLOUD} that those of us who run our own services are now in the tiny minority. I'm disappointed (but hardly shocked) to discover that Microsoft doesn't support arbitratry CalDAV or CardDAV services with their built-in apps, for example. I realize I'm probably in another minority here, but as a Windows-hater, I nevertheless find that there's a bunch of stuff I need to do that only really works on Windows. What I really want is an up-to-date version of Windows 98 or maybe XP. I don't need all the Microsoft-added cruft for other things. I don't use their e-mail, or their calendar, or their contacts, or their web browser (usually). Or pretty much any Metro app. I understand why a lot of that crap is there, especially as they now need to try to make Win10 workable and usable on multiple device types, so I don't mind that they added it, and I understand that using any of that crap could mean that ${MICROSOFT_CLOUD} gets involved. Doesn't mean you have to use it! Windows 10 turns out to be fairly useful once you take a hatchet to it and bludgeon out all the stuff obviously intended for the average home user or the average phone user that is just supposed to "magically work." The legal fine print for most software is atrocious these days. This isn't shocking, sadly. I can find egregious crap in lots of license agreements and privacy statements out there. You don't actually *HAVE* to use a Microsoft Account to sign into Windows 10. If you DO sign in using a Microsoft Account, you're going to be hooking your Windows box up to a bunch of cloud services that you might not want or need. For many people, this may actually be the right choice, because how else do you sync things between your desktop, your laptop, your tablet, and your Windows phone? That carries with it a lot of benefits for the average non-techie user, but is a privacy issue as well. If you do that and then don't use any of their apps, because maybe you browse the web with Chrome and you're heavily invested in Google or Yahoo for mail, contacts, and calendar, you're still not sharing the data ... with Microsoft. But that data's still out there in someone's "cloud". I could be very cynical (and yet probably come frighteningly close to the mark) by noting that Microsoft is following in Google's footsteps in amassing a wealth of data about users by providing these add-on cloud services to users, and that the users are slowly becoming the product instead of being the customer, which makes it even more attractive to do the sorts of data collection and mining pioneered by some of those other companies. Yet none of this commits you. You don't have to share information. You don't have to use a Microsoft Account. You don't have to use any of their programs or apps that would share data. Screw them. So, again, I say, the quoted article contains about 25% crap, 30% FUD, and the remainder consists of concerns of varying levels of validity. This isn't the apocalypse. People have willingly been exchanging their privacy for free services on the Internet for many years. Those of us who prefer not to rely on those services are also able to navigate that maze. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From m.hotze at hotze.com Thu Jul 30 12:11:27 2015 From: m.hotze at hotze.com (Martin Hotze) Date: Thu, 30 Jul 2015 12:11:27 +0000 Subject: Windows 10 Release Message-ID: > From: Joe Greco > Subject: Re: Windows 10 Release > > > You can download an ISO and burn it to install... Guessing if your > > upgrading multiple machines, that would be the way to go... > > You don't even need to burn it to install. Just mount the ISO and > run setup.exe I've searched, but have not found anything about it: Are you allowed to redistribute the .iso to the open public? If yes, this might save some smaller networks some bandwidth. Martin From tiernan at tiernanotoole.net Thu Jul 30 13:01:10 2015 From: tiernan at tiernanotoole.net (Tiernan OToole) Date: Thu, 30 Jul 2015 14:01:10 +0100 Subject: Windows 10 Release In-Reply-To: References: Message-ID: <55BA2016.3000706@tiernanotoole.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Not sure about "open public" but you can use that ISO on whatever many machines your licensed to... - --Tiernan On 30/07/2015 13:11, Martin Hotze wrote: >> From: Joe Greco Subject: Re: Windows 10 >> Release >> >>> You can download an ISO and burn it to install... Guessing if >>> your upgrading multiple machines, that would be the way to >>> go... >> >> You don't even need to burn it to install. Just mount the ISO >> and run setup.exe > > I've searched, but have not found anything about it: Are you > allowed to redistribute the .iso to the open public? > > If yes, this might save some smaller networks some bandwidth. > > Martin > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVuiAWAAoJECWDUKjOk5r1bOgP/RVHQd5VpAUCEAG/7wzxZzzZ rEmt6AgZvo2RT3zfyuUyuim3QY5s+x9ZDTniHvEEmxnqHYnVRjcG3eg8uT/uddeF 4hF2QCU6I3bAF33Tm1K2uvBUOcBEMEnyEDOJumxNLlgMpIeEq0xcjemEoYIhG/QY abu6k6q3oQf4fWnaioArK78WApa9Yl1n6HfMl5OLYl3zbteyeyfBxyKG2FOAiTrc r0IhAYzM0ZUw7UC2F6sD3Tx2Hp5lFwvno5nJVXROZF9Hobtswy3dBWJjcEWA/pQ8 T8Jn07gWT3RDhVpcVQ+G1EcqWs/8925qVk4V49EkoOPTmuHPo3RRmmwZMfAgKF07 mvfyOHeh5ATwmRj2sJ+0hVt2/ASk9H94pmzUdxjWy3mSoni7ssR6rLKM1pooVRwP v3cDxFc4f0pVwU4ZFwmmkwVLPpijwDGTpeKCUjqY7XPuXj3lpQoJCK9jY7Vorncs XDHKHVJz/WawNi9CVg4nHIifNXR8qwgBe8bAu2aEmA4Rayx4UY5fVDd/iyskgDmj xkEqBusEWIlmX+LjWG+P2ktb5SSBziMOsZLY9mH5DVtdStpSGTnTSuJ5f1EQVYJg t85Ier8Y20LOB4ikVDb6vsr8NEoKpH9101j2QI+qs/f2BygMxxcZBbUFhk4SHpnO Cx8tGp5G6cCRt4XNbXe1 =lNWD -----END PGP SIGNATURE----- From Curtis.Starnes at granburyisd.org Thu Jul 30 13:14:59 2015 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Thu, 30 Jul 2015 13:14:59 +0000 Subject: Windows 10 Release In-Reply-To: References: Message-ID: <53481fb07e79491381e92a8f7c87fee6@TEC-MAIL1.granbury.k12.tx.us> https://www.microsoft.com/en-us/software-download/windows10 is the download URL. This site launches the Download Tool so the ISO can be downloaded from Microsoft. Curtis -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Martin Hotze Sent: Thursday, July 30, 2015 7:11 AM To: nanog at nanog.org Subject: Re: Windows 10 Release > From: Joe Greco > Subject: Re: Windows 10 Release > > > You can download an ISO and burn it to install... Guessing if your > > upgrading multiple machines, that would be the way to go... > > You don't even need to burn it to install. Just mount the ISO and run > setup.exe I've searched, but have not found anything about it: Are you allowed to redistribute the .iso to the open public? If yes, this might save some smaller networks some bandwidth. Martin From m.hotze at hotze.com Thu Jul 30 13:17:24 2015 From: m.hotze at hotze.com (Martin Hotze) Date: Thu, 30 Jul 2015 13:17:24 +0000 Subject: Windows 10 Release In-Reply-To: <53481fb07e79491381e92a8f7c87fee6@TEC-MAIL1.granbury.k12.tx.us> References: <53481fb07e79491381e92a8f7c87fee6@TEC-MAIL1.granbury.k12.tx.us> Message-ID: > From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org] > https://www.microsoft.com/en-us/software-download/windows10 is the > download URL. > This site launches the Download Tool so the ISO can be downloaded from > Microsoft. Yeah, I know. But is it allowed to redistribute the .iso File(s)? Might help to save downloading some GB ... martin From Curtis.Starnes at granburyisd.org Thu Jul 30 13:19:03 2015 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Thu, 30 Jul 2015 13:19:03 +0000 Subject: Windows 10 Release In-Reply-To: References: <53481fb07e79491381e92a8f7c87fee6@TEC-MAIL1.granbury.k12.tx.us> Message-ID: Not sure about distributing but I would think it would be ok since it is an ISO for upgrading and the site says if it is a new installation a product key would be needed. Curtis -----Original Message----- From: Martin Hotze [mailto:m.hotze at hotze.com] Sent: Thursday, July 30, 2015 8:17 AM To: STARNES, CURTIS ; nanog at nanog.org Subject: RE: Windows 10 Release > From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org] > https://www.microsoft.com/en-us/software-download/windows10 is the > download URL. > This site launches the Download Tool so the ISO can be downloaded from > Microsoft. Yeah, I know. But is it allowed to redistribute the .iso File(s)? Might help to save downloading some GB ... martin From nanog at stefan-neufeind.de Thu Jul 30 13:27:47 2015 From: nanog at stefan-neufeind.de (Stefan Neufeind) Date: Thu, 30 Jul 2015 15:27:47 +0200 Subject: Windows 10 Release In-Reply-To: References: <53481fb07e79491381e92a8f7c87fee6@TEC-MAIL1.granbury.k12.tx.us> Message-ID: <55BA2653.40504@stefan-neufeind.de> Then they might want to show an official MD5/SHA1 on their website for the media. Or maybe simply offer a torrent/magnet-link ... Kind regards, Stefan On 30.07.2015 15:19, STARNES, CURTIS wrote: > Not sure about distributing but I would think it would be ok since it is an ISO for upgrading and the site says if it is a new installation a product key would be needed. > > Curtis > > -----Original Message----- > From: Martin Hotze [mailto:m.hotze at hotze.com] > Sent: Thursday, July 30, 2015 8:17 AM > To: STARNES, CURTIS ; nanog at nanog.org > Subject: RE: Windows 10 Release > >> From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org] > > >> https://www.microsoft.com/en-us/software-download/windows10 is the >> download URL. >> This site launches the Download Tool so the ISO can be downloaded from >> Microsoft. > > Yeah, I know. But is it allowed to redistribute the .iso File(s)? Might help to save downloading some GB ... > > martin From nobody at snovc.com Thu Jul 30 13:34:01 2015 From: nobody at snovc.com (Private Sender) Date: Thu, 30 Jul 2015 06:34:01 -0700 Subject: Working with Spamhaus In-Reply-To: References: Message-ID: <55BA27C9.2050907@snovc.com> If you implement SPF / DKIM / DMARC / ADSP, force your customers to relay their mail through something you control, and show them you are serious about stopping the spam they may work with you then. Otherwise, they just assume you're a spam house. From michael.holstein at csuohio.edu Thu Jul 30 13:59:55 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Thu, 30 Jul 2015 13:59:55 +0000 Subject: Working with Spamhaus In-Reply-To: <55BA27C9.2050907@snovc.com> References: , <55BA27C9.2050907@snovc.com> Message-ID: >If you implement SPF / DKIM / DMARC / ADSP, force your customers to relay Before we went SaaS with email we had lots of spam problems and we also went this route .. you must relay through us and authenticate .. postfix along with the dkim and policyd milters (and SPF in DNS). The policyd one would limit you to X messages in Y hours (per SASL credential), and we would override it for people that had a specific need. That was very effective at limiting the spam damage. I'm sure your needs are different as a commercial provider but we found that hardly anyone sends more than 100 messages a day, and 100 spammy messages isn't enough to get you in trouble, as long as it stops there. We have a /16 where most of our stuff lives and have moved things around a bit .. Spamhaus was pretty easy to deal with, as were the other major players (MS, Google, AOL, Yahoo) by just filling out their postmaster forms. Basically you just need to explain how you are fixing the problem and they usually answer you in less than 24hrs. The only IP addresses we have that I'd consider permanently tainted are the ones we've run TOR exit nodes on. We haven't run TOR in a couple years now but those IPs are still blacklisted so many places they are essentially unusable in any reliable capacity -- something to keep in mind while crafting your TOS. -Michael Holstein -Cleveland State University From Matthew.Black at csulb.edu Thu Jul 30 14:15:34 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Thu, 30 Jul 2015 14:15:34 +0000 Subject: Windows 10 Release In-Reply-To: <201507300258.t6U2wds0086123@aurora.sol.net> References: <55B8E12A.40609@tiernanotoole.net> <201507300258.t6U2wds0086123@aurora.sol.net> Message-ID: Are users required to create any type of Microsoft cloud account (e.g., OneDrive, Office365, et alil) in order to install and use Windows 10? Of Office? Is it possible to simply use Windows 10 without any Microsoft or Google or Yahoo accounts? Is the unique identifier available to advertisers only through IE (or its successor) OR will it also be available through Firefox/Chrome? matthew black california state university, long beach From khelms at zcorum.com Thu Jul 30 14:19:33 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 30 Jul 2015 10:19:33 -0400 Subject: Windows 10 Release In-Reply-To: References: <55B8E12A.40609@tiernanotoole.net> <201507300258.t6U2wds0086123@aurora.sol.net> Message-ID: Since the requirement is that users are upgrading from Win 7, 8, or 8.1 they've already had to create at least a minimal MS ID which means either creating an email account on Outlook.com or providing an existing email address and a password for MS. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Jul 30, 2015 at 10:15 AM, Matthew Black wrote: > Are users required to create any type of Microsoft cloud account (e.g., > OneDrive, Office365, et alil) in order to install and use Windows 10? Of > Office? Is it possible to simply use Windows 10 without any Microsoft or > Google or Yahoo accounts? > > Is the unique identifier available to advertisers only through IE (or its > successor) OR will it also be available through Firefox/Chrome? > > > matthew black > california state university, long beach > From brooks at firestormnetworks.net Thu Jul 30 14:23:26 2015 From: brooks at firestormnetworks.net (Brooks Bridges) Date: Thu, 30 Jul 2015 07:23:26 -0700 Subject: Windows 10 Release In-Reply-To: References: <55B8E12A.40609@tiernanotoole.net> <201507300258.t6U2wds0086123@aurora.sol.net> Message-ID: <55BA335E.6020006@firestormnetworks.net> Just as a point of debate, I've been using Windows 7 for quite some time and I do not, nor have I ever, given MS any email information or have I created a Live account. On 7/30/2015 7:19 AM, Scott Helms wrote: > Since the requirement is that users are upgrading from Win 7, 8, or 8.1 > they've already had to create at least a minimal MS ID which means either > creating an email account on Outlook.com or providing an existing email > address and a password for MS. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Jul 30, 2015 at 10:15 AM, Matthew Black > wrote: > >> Are users required to create any type of Microsoft cloud account (e.g., >> OneDrive, Office365, et alil) in order to install and use Windows 10? Of >> Office? Is it possible to simply use Windows 10 without any Microsoft or >> Google or Yahoo accounts? >> >> Is the unique identifier available to advertisers only through IE (or its >> successor) OR will it also be available through Firefox/Chrome? >> >> >> matthew black >> california state university, long beach >> From aaron at westfield.ma.edu Thu Jul 30 14:25:44 2015 From: aaron at westfield.ma.edu (Childs, Aaron) Date: Thu, 30 Jul 2015 14:25:44 +0000 Subject: Windows 10 Release In-Reply-To: References: <55B8E12A.40609@tiernanotoole.net> <201507300258.t6U2wds0086123@aurora.sol.net> Message-ID: <10B60E2061BA5D42B4B91A06763E2C42B4020694@ex-mbx-v3.ads.wsc.ma.edu> You do not have to create or use a Microsoft account to use Windows 10 or any of the apps (other than the MS Store.) You can continue to log in to Windows using a local account. Aaron Childs Associate Director, Infrastructure Services? Information Technology Services Wilson Hall - 577 Western Ave. Westfield MA 01086 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Black Sent: Thursday, July 30, 2015 10:16 AM To: North American Network Operators' Group (nanog at nanog.org) Subject: RE: Windows 10 Release Are users required to create any type of Microsoft cloud account (e.g., OneDrive, Office365, et alil) in order to install and use Windows 10? Of Office? Is it possible to simply use Windows 10 without any Microsoft or Google or Yahoo accounts? Is the unique identifier available to advertisers only through IE (or its successor) OR will it also be available through Firefox/Chrome? matthew black california state university, long beach From khelms at zcorum.com Thu Jul 30 14:27:08 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 30 Jul 2015 10:27:08 -0400 Subject: Windows 10 Release In-Reply-To: <55BA335E.6020006@firestormnetworks.net> References: <55B8E12A.40609@tiernanotoole.net> <201507300258.t6U2wds0086123@aurora.sol.net> <55BA335E.6020006@firestormnetworks.net> Message-ID: I was just thinking about my remaining Win 7 box _after_ I hit send and I believe you're correct (I have one still to upgrade). Which means users upgrading from 7 to 10 will need to create an ID, but users of 8 and 8.1 will use the one they already have. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Jul 30, 2015 at 10:23 AM, Brooks Bridges < brooks at firestormnetworks.net> wrote: > Just as a point of debate, I've been using Windows 7 for quite some time > and I do not, nor have I ever, given MS any email information or have I > created a Live account. > > On 7/30/2015 7:19 AM, Scott Helms wrote: > >> Since the requirement is that users are upgrading from Win 7, 8, or 8.1 >> they've already had to create at least a minimal MS ID which means either >> creating an email account on Outlook.com or providing an existing email >> address and a password for MS. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Thu, Jul 30, 2015 at 10:15 AM, Matthew Black >> wrote: >> >> Are users required to create any type of Microsoft cloud account (e.g., >>> OneDrive, Office365, et alil) in order to install and use Windows 10? Of >>> Office? Is it possible to simply use Windows 10 without any Microsoft or >>> Google or Yahoo accounts? >>> >>> Is the unique identifier available to advertisers only through IE (or its >>> successor) OR will it also be available through Firefox/Chrome? >>> >>> >>> matthew black >>> california state university, long beach >>> >>> > From justin at mckill.ca Thu Jul 30 14:28:57 2015 From: justin at mckill.ca (Justin Mckillican) Date: Thu, 30 Jul 2015 10:28:57 -0400 Subject: Windows 10 Release In-Reply-To: References: <55B8E12A.40609@tiernanotoole.net> <201507300258.t6U2wds0086123@aurora.sol.net> Message-ID: <21D78956-C508-4C77-986A-6AA035BDC2AF@mckill.ca> Nope. For the upgrade the only piece of information MSFT needed was your email if you chose email notification once the upgrade was ready for you. After it's installed it will ask to finish up the install the 'Express' method which enabled a bunch of things like WIFI password sharing to friends and whatever else or if you chose the manual option like I did you can disable everything. It will also inherit your existing user settings, so if your user is a local one instead of a cloud one it will continue to be that way. It does install One Drive but again, if you never configured it or used it then you'll simply see it in your task bar with the "welcome" or signup screen. -justin > On Jul 30, 2015, at 10:19 AM, Scott Helms wrote: > > Since the requirement is that users are upgrading from Win 7, 8, or 8.1 > they've already had to create at least a minimal MS ID which means either > creating an email account on Outlook.com or providing an existing email > address and a password for MS. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Jul 30, 2015 at 10:15 AM, Matthew Black > wrote: > >> Are users required to create any type of Microsoft cloud account (e.g., >> OneDrive, Office365, et alil) in order to install and use Windows 10? Of >> Office? Is it possible to simply use Windows 10 without any Microsoft or >> Google or Yahoo accounts? >> >> Is the unique identifier available to advertisers only through IE (or its >> successor) OR will it also be available through Firefox/Chrome? >> >> >> matthew black >> california state university, long beach >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4103 bytes Desc: not available URL: From khelms at zcorum.com Thu Jul 30 14:34:33 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 30 Jul 2015 10:34:33 -0400 Subject: Windows 10 Release In-Reply-To: <21D78956-C508-4C77-986A-6AA035BDC2AF@mckill.ca> References: <55B8E12A.40609@tiernanotoole.net> <201507300258.t6U2wds0086123@aurora.sol.net> <21D78956-C508-4C77-986A-6AA035BDC2AF@mckill.ca> Message-ID: Justin, That's true, but it takes effort for people to either set up a local account or change to one, and very few consumers will do that or have. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Jul 30, 2015 at 10:28 AM, Justin Mckillican wrote: > Nope. For the upgrade the only piece of information MSFT needed was your > email if you chose email notification once the upgrade was ready for you. > > After it's installed it will ask to finish up the install the 'Express' > method which enabled a bunch of things like WIFI password sharing to > friends and whatever else or if you chose the manual option like I did you > can disable everything. It will also inherit your existing user settings, > so if your user is a local one instead of a cloud one it will continue to > be that way. > > It does install One Drive but again, if you never configured it or used it > then you'll simply see it in your task bar with the "welcome" or signup > screen. > > > -justin > > > On Jul 30, 2015, at 10:19 AM, Scott Helms wrote: > > > > Since the requirement is that users are upgrading from Win 7, 8, or 8.1 > > they've already had to create at least a minimal MS ID which means either > > creating an email account on Outlook.com or providing an existing email > > address and a password for MS. > > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > http://twitter.com/kscotthelms > > -------------------------------- > > > > On Thu, Jul 30, 2015 at 10:15 AM, Matthew Black > > > wrote: > > > >> Are users required to create any type of Microsoft cloud account (e.g., > >> OneDrive, Office365, et alil) in order to install and use Windows 10? Of > >> Office? Is it possible to simply use Windows 10 without any Microsoft or > >> Google or Yahoo accounts? > >> > >> Is the unique identifier available to advertisers only through IE (or > its > >> successor) OR will it also be available through Firefox/Chrome? > >> > >> > >> matthew black > >> california state university, long beach > >> > > From keiths at neilltech.com Thu Jul 30 16:02:06 2015 From: keiths at neilltech.com (Keith Stokes) Date: Thu, 30 Jul 2015 16:02:06 +0000 Subject: AT&T U-Verse Data Setup Convention Message-ID: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> I?m wondering if some can share their experiences or maybe there?s an AT&T person here who can confirm policy. I work for SaaS provider who requires a source IP to access our system to businesses. Normally we tell the customer to request a ?Static IP? from their provider. That term makes sense to most ISPs. However, we?ve recently worked with an AT&T higher-up tech who told us that every U-Verse modem is locked to an address even when set to DHCP and will not change unless the unit is changed. Ordering a ?Static IP? from them means your devices will individually get public addresses, which isn?t a requirement for us, isn?t quite as easy to add multiple devices and costs our customers more money. Here are my questions: 1. Is it really accurate that the customer?s address is tied to the modem/router? 2. For my curiosity, is this done through a DHCP reservation or is there a hard coded entry somewhere? 3. Do all U-Verse modem/routers behave the same way? This particular unit was a Motorola but the friends I?ve seen with U-Verse use a Cisco unit. --- Keith Stokes From Valdis.Kletnieks at vt.edu Thu Jul 30 16:12:52 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 30 Jul 2015 12:12:52 -0400 Subject: DDOS Simulation In-Reply-To: Your message of "Wed, 29 Jul 2015 12:38:18 -0700." <20150729193818.GA32446@Mail.DDoS-Mitigator.net> References: <20150728221940.GA25835@Mail.DDoS-Mitigator.net> <20150729193818.GA32446@Mail.DDoS-Mitigator.net> Message-ID: <10022.1438272772@turing-police.cc.vt.edu> On Wed, 29 Jul 2015 12:38:18 -0700, alvin nanog said: > On 07/29/15 at 05:47am, Roland Dobbins wrote: > > On 29 Jul 2015, at 5:19, alvin nanog wrote: > > >and all the other ISP's routers along the way that had to transport > > >those gigabyte/terabyte of useless ddos packets > > > > No company can provide a 'get out of jail card' for illegal activities, > > irrespective of how they arrange their paperwork. > > oopps, maybe a "misunderstanding" ... it's an old "be careful euphomism(sp?) > and not meant as "literal get out of jail" ( from monopoly game too ) You may indeed need a "get out of jail" card if one of those "all the other ISPs along the way" decides to make an issue of it. The company you're working with can only promise that *they* won't press charges. What their upstream decides to do is out of their control. > if i had to pick only one command for the ddos tests .... i'd simply > flood the wire .. everything is now offline ( should be un-responsive ) > nping "send 100,000 packets/sec" x 65,000byte/packet 192.168.0.0/16 That will only send out packets as fast as your single pipe can send, which will probably *not* make everything unresponsive. Hint - only (roughly) one out of every 65,635 packets will be pointed at the host at 198.168.5.16, for example - and I would *hope* that said host can handle an added 65K packet every 0.6 seconds or so... Oh, and line speed for a 10G connection is 155K 64K packets per second, so your command won't even fill *one* computer's pipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From cb.list6 at gmail.com Thu Jul 30 16:14:04 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 30 Jul 2015 09:14:04 -0700 Subject: AT&T U-Verse Data Setup Convention In-Reply-To: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> References: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> Message-ID: On Thu, Jul 30, 2015 at 9:02 AM, Keith Stokes wrote: > I?m wondering if some can share their experiences or maybe there?s an AT&T > person here who can confirm policy. > > I work for SaaS provider who requires a source IP to access our system to > businesses. > > That is probably a problematic practice. > Normally we tell the customer to request a ?Static IP? from their > provider. That term makes sense to most ISPs. > > However, we?ve recently worked with an AT&T higher-up tech who told us > that every U-Verse modem is locked to an address even when set to DHCP and > will not change unless the unit is changed. Ordering a ?Static IP? from > them means your devices will individually get public addresses, which isn?t > a requirement for us, isn?t quite as easy to add multiple devices and costs > our customers more money. > > Here are my questions: > > 1. Is it really accurate that the customer?s address is tied to the > modem/router? > > 2. For my curiosity, is this done through a DHCP reservation or is there a > hard coded entry somewhere? > > 3. Do all U-Verse modem/routers behave the same way? This particular unit > was a Motorola but the friends I?ve seen with U-Verse use a Cisco unit. > > --- > > Keith Stokes > > > AT&T addressing has been detailed here in some ways. I am not sure how accurate it is or at what state this has been deployed http://www.networkworld.com/article/2188898/lan-wan/at-t-demands-we-change-our-networks.html But, it is possible that AT&T does not have IPv4 static addresses to assign. From cra at WPI.EDU Thu Jul 30 16:20:09 2015 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 30 Jul 2015 12:20:09 -0400 Subject: AT&T U-Verse Data Setup Convention In-Reply-To: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> References: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> Message-ID: <20150730162009.GU5428@angus.ind.WPI.EDU> People need to really stop using Source IP as an ACL mechanism whereever possible. Have you considered using SSL certs or SSH keys or some other sort of API key instead? I'm mean, do you really want to have to know how the technology of every ISP that every possible SaaS customer may use to access your service is set up? On Thu, Jul 30, 2015 at 04:02:06PM +0000, Keith Stokes wrote: > I?m wondering if some can share their experiences or maybe there?s an AT&T person here who can confirm policy. > > I work for SaaS provider who requires a source IP to access our system to businesses. > > Normally we tell the customer to request a ?Static IP? from their provider. That term makes sense to most ISPs. > > However, we?ve recently worked with an AT&T higher-up tech who told us that every U-Verse modem is locked to an address even when set to DHCP and will not change unless the unit is changed. Ordering a ?Static IP? from them means your devices will individually get public addresses, which isn?t a requirement for us, isn?t quite as easy to add multiple devices and costs our customers more money. > > Here are my questions: > > 1. Is it really accurate that the customer?s address is tied to the modem/router? > > 2. For my curiosity, is this done through a DHCP reservation or is there a hard coded entry somewhere? > > 3. Do all U-Verse modem/routers behave the same way? This particular unit was a Motorola but the friends I?ve seen with U-Verse use a Cisco unit. From Matthew.Black at csulb.edu Thu Jul 30 16:26:21 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Thu, 30 Jul 2015 16:26:21 +0000 Subject: Verizon exiting California Message-ID: Verizon sent me a letter the other day stating that they are selling their landline business to Frontier Communications. It was a very terse letter and as a customer I don't know if it affects me. While stating they aren't exiting the Wireless business, I want to know which parts are being sold off. Just the copper lines, POTS, DSL, FIOS (TV, Internet, phone)? Some clarity would be great. I am a FIOS only customer. Can anyone recall if GTE was blocked from doing the same thing a few decades ago? matthew black california state university, long beach From keiths at neilltech.com Thu Jul 30 16:30:18 2015 From: keiths at neilltech.com (Keith Stokes) Date: Thu, 30 Jul 2015 16:30:18 +0000 Subject: AT&T U-Verse Data Setup Convention In-Reply-To: <20150730162009.GU5428@angus.ind.WPI.EDU> References: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> <20150730162009.GU5428@angus.ind.WPI.EDU> Message-ID: <872FE69E-DB76-41CC-AA45-4DA800326E88@neilltech.com> Access is not the only reason we ask for non-changing source IP addresses. I?m not arguing the long-term sensibility of the approach. It?s arguably a legacy app and has 5000 endpoints that we have to still support until different solutions on our side are complete. That process is outside of my control. On Jul 30, 2015, at 11:20 AM, Chuck Anderson > wrote: People need to really stop using Source IP as an ACL mechanism whereever possible. Have you considered using SSL certs or SSH keys or some other sort of API key instead? I'm mean, do you really want to have to know how the technology of every ISP that every possible SaaS customer may use to access your service is set up? On Thu, Jul 30, 2015 at 04:02:06PM +0000, Keith Stokes wrote: I?m wondering if some can share their experiences or maybe there?s an AT&T person here who can confirm policy. I work for SaaS provider who requires a source IP to access our system to businesses. Normally we tell the customer to request a ?Static IP? from their provider. That term makes sense to most ISPs. However, we?ve recently worked with an AT&T higher-up tech who told us that every U-Verse modem is locked to an address even when set to DHCP and will not change unless the unit is changed. Ordering a ?Static IP? from them means your devices will individually get public addresses, which isn?t a requirement for us, isn?t quite as easy to add multiple devices and costs our customers more money. Here are my questions: 1. Is it really accurate that the customer?s address is tied to the modem/router? 2. For my curiosity, is this done through a DHCP reservation or is there a hard coded entry somewhere? 3. Do all U-Verse modem/routers behave the same way? This particular unit was a Motorola but the friends I?ve seen with U-Verse use a Cisco unit. --- Keith Stokes From nanog at ics-il.net Thu Jul 30 16:30:26 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 30 Jul 2015 11:30:26 -0500 (CDT) Subject: Verizon exiting California In-Reply-To: Message-ID: <70914046.2145.1438273844590.JavaMail.mhammett@ThunderFuck> Everything landline in your area is going. The enterprise and wireless businesses are staying Verizon. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Matthew Black" To: "North American Network Operators' Group (nanog at nanog.org)" Sent: Thursday, July 30, 2015 11:26:21 AM Subject: Verizon exiting California Verizon sent me a letter the other day stating that they are selling their landline business to Frontier Communications. It was a very terse letter and as a customer I don't know if it affects me. While stating they aren't exiting the Wireless business, I want to know which parts are being sold off. Just the copper lines, POTS, DSL, FIOS (TV, Internet, phone)? Some clarity would be great. I am a FIOS only customer. Can anyone recall if GTE was blocked from doing the same thing a few decades ago? matthew black california state university, long beach From Matthew.Black at csulb.edu Thu Jul 30 16:31:33 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Thu, 30 Jul 2015 16:31:33 +0000 Subject: Verizon exiting California In-Reply-To: References: Message-ID: Nevermind. I found a February article detailing the plan. arstechnica: Verizon sells three-state territory, including 1.6 million FiOS users http://arstechnica.com/business/2015/02/verizon-sells-three-state-territory-including-1-6-million-fios-users/ matthew black california state university, long beach -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Black Sent: Thursday, July 30, 2015 9:26 AM To: North American Network Operators' Group (nanog at nanog.org) Subject: Verizon exiting California Verizon sent me a letter the other day stating that they are selling their landline business to Frontier Communications. It was a very terse letter and as a customer I don't know if it affects me. While stating they aren't exiting the Wireless business, I want to know which parts are being sold off. Just the copper lines, POTS, DSL, FIOS (TV, Internet, phone)? Some clarity would be great. I am a FIOS only customer. Can anyone recall if GTE was blocked from doing the same thing a few decades ago? matthew black california state university, long beach From sean at donelan.com Thu Jul 30 16:31:50 2015 From: sean at donelan.com (Sean Donelan) Date: Thu, 30 Jul 2015 12:31:50 -0400 (EDT) Subject: AT&T U-Verse Data Setup Convention In-Reply-To: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> References: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> Message-ID: On Thu, 30 Jul 2015, Keith Stokes wrote: > 1. Is it really accurate that the customer?s address is tied to the > modem/router? AT&T calls it "Sticky IP address." A U-Verse Residential Gateway tends to get the same IP address from DHCP, for months or years, but its not guaranteed. An subnet may change anytime wihout notice for the convience of network engineering, i.e. splitting on a new DSLAM slot, moving equipment in CO's, replacing the RG hardware, DHCP server changes, etc. If a cusomer wants assurance and notification about future IP address changes affecting their IP address assignment, they will need to pay for U-Verse "Static IP address" service. From colton.conor at gmail.com Thu Jul 30 16:31:52 2015 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 30 Jul 2015 11:31:52 -0500 Subject: Verizon exiting California In-Reply-To: References: Message-ID: I would love to see what a copy of the letter they sent out looks like. They are selling all wireline in CA, TX, and FL. So yes, all the products you described. On Thu, Jul 30, 2015 at 11:26 AM, Matthew Black wrote: > Verizon sent me a letter the other day stating that they are selling their > landline business to Frontier Communications. It was a very terse letter > and as a customer I don't know if it affects me. While stating they aren't > exiting the Wireless business, I want to know which parts are being sold > off. Just the copper lines, POTS, DSL, FIOS (TV, Internet, phone)? Some > clarity would be great. I am a FIOS only customer. Can anyone recall if > GTE was blocked from doing the same thing a few decades ago? > > matthew black > california state university, long beach > From jgreco at ns.sol.net Thu Jul 30 16:58:04 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 30 Jul 2015 11:58:04 -0500 (CDT) Subject: Windows 10 Release In-Reply-To: Message-ID: <201507301658.t6UGw4VN000382@aurora.sol.net> > I was just thinking about my remaining Win 7 box _after_ I hit send and I > believe you're correct (I have one still to upgrade). Which means users > upgrading from 7 to 10 will need to create an ID, but users of 8 and 8.1 > will use the one they already have. This is incorrect. While the Win 8{,.1} install process makes it appear as though you need a Microsoft ID, you can actually go into the "create a new Microsoft ID" option and there's a way to proceed without creating a Microsoft ID, which leaves you with all local accounts. It does appear to be designed to make you THINK you need a Microsoft account however. I have a freshly installed Windows 8.1 box here (no Microsoft ID) that I then upgraded to Windows 10, and it also does not have any Microsoft ID attached to it. Activation shows as "Windows 10 Home" and "Windows is activated." There's a beggy-screen on the user account page saying something like "Windows is better when your settings and files automatically sync. Switch to a Microsoft Account now!" So, again, totally optional, but admittedly the path of least resistance has users creating a Microsoft Account or linking to their existing one. You have to trawl around a little to get the better (IMHO) behaviour. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jgreco at ns.sol.net Thu Jul 30 17:02:30 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 30 Jul 2015 12:02:30 -0500 (CDT) Subject: Windows 10 Release In-Reply-To: Message-ID: <201507301702.t6UH2URa000517@aurora.sol.net> > Justin, > > That's true, but it takes effort for people to either set up a local > account or change to one, and very few consumers will do that or have. Wow, then, problem solved, because it's at least twice as hard to get your Microsoft Account set up, configured, and verified. The sticky point is that very few consumers will KNOW that they can avoid the Microsoft account, and most won't take the time to explore the various options and possibilities. This isn't an effort thing. Setting up a local account is fairly effortless. It's a matter of the option being hidden away, because it is in Microsoft's interest to get everyone using the Windows cloud magic. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From fastest963 at gmail.com Thu Jul 30 16:51:15 2015 From: fastest963 at gmail.com (James Hartig) Date: Thu, 30 Jul 2015 12:51:15 -0400 Subject: AT&T U-Verse Data Setup Convention In-Reply-To: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> References: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> Message-ID: I've had AT&T UVerse for 3 years now and it has changed at least twice since I got it. The DHCP address has an expiration of ~7 days and it usually keeps the same address upon renewal but a few times I have noticed that it's changed. I wouldn't trust it to be static forever. -- James Hartig From morrowc.lists at gmail.com Thu Jul 30 17:06:04 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 30 Jul 2015 13:06:04 -0400 Subject: AT&T U-Verse Data Setup Convention In-Reply-To: References: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> Message-ID: On Thu, Jul 30, 2015 at 12:14 PM, Ca By wrote: > On Thu, Jul 30, 2015 at 9:02 AM, Keith Stokes wrote: > >> I?m wondering if some can share their experiences or maybe there?s an AT&T >> person here who can confirm policy. >> >> I work for SaaS provider who requires a source IP to access our system to >> businesses. >> >> > That is probably a problematic practice. > "probably" From robertg at garlic.com Thu Jul 30 17:05:55 2015 From: robertg at garlic.com (Robert Glover) Date: Thu, 30 Jul 2015 10:05:55 -0700 Subject: [BULK] Verizon exiting California In-Reply-To: References: Message-ID: <55BA5973.7070200@garlic.com> On 7/30/2015 9:26 AM, Matthew Black wrote: > Verizon sent me a letter the other day stating that they are selling their landline business to Frontier Communications. It was a very terse letter and as a customer I don't know if it affects me. While stating they aren't exiting the Wireless business, I want to know which parts are being sold off. Just the copper lines, POTS, DSL, FIOS (TV, Internet, phone)? Some clarity would be great. I am a FIOS only customer. Can anyone recall if GTE was blocked from doing the same thing a few decades ago? > > matthew black > california state university, long beach All wireline assets in the Verizon West footprint (California, Texas, and Tampa, FL area) are being aquired by Frontier Here's the Press Release from Frontier: http://investor.frontier.com/releasedetail.cfm?ReleaseID=895055 All wireless assets remain with Verizon. From jason at lixfeld.ca Thu Jul 30 18:28:22 2015 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 30 Jul 2015 14:28:22 -0400 Subject: Mac compatible SFP+/XFP programmer Message-ID: Does anyone know where I might find a SFP+/XFP programmer with a Mac compatible programmer application? Thanks! From youssef at 720.fr Thu Jul 30 18:48:29 2015 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Thu, 30 Jul 2015 20:48:29 +0200 Subject: Mac compatible SFP+/XFP programmer In-Reply-To: References: Message-ID: Hi, Flexoptics seems to do the trick but via a Web browser : https://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html From what I've heard, this thing does the Job. Best regards. > Le 30 juil. 2015 ? 20:28, Jason Lixfeld a ?crit : > > Does anyone know where I might find a SFP+/XFP programmer with a Mac compatible programmer application? > > Thanks! From dan-nanog at drown.org Thu Jul 30 19:18:32 2015 From: dan-nanog at drown.org (Dan Drown) Date: Thu, 30 Jul 2015 14:18:32 -0500 Subject: AT&T U-Verse Data Setup Convention In-Reply-To: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> References: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> Message-ID: <20150730141832.788984lg60anpoqw@mail.drown.org> I have AT&T u-verse small business connection at my office with a static IP setup, and my experience matches with the AT&T tech said. We have a separate router behind the AT&T router. The AT&T router is an Arris (former Motorola) NVG595. Our router has a static IP out of our subnet and does NAT for the office network. As far as I can tell, the u-verse supplied router cannot be replaced with something less sucky. The problem is getting the 802.1x certificate needed to authenticate on the wan port. I dislike AT&T's hardware as it has more limitations than just this, but some of those limitations can be worked around with an additional router downstream of it. Quoting Keith Stokes : > I?m wondering if some can share their experiences or maybe there?s > an AT&T person here who can confirm policy. > > I work for SaaS provider who requires a source IP to access our > system to businesses. > > Normally we tell the customer to request a ?Static IP? from their > provider. That term makes sense to most ISPs. > > However, we?ve recently worked with an AT&T higher-up tech who told > us that every U-Verse modem is locked to an address even when set to > DHCP and will not change unless the unit is changed. Ordering a > ?Static IP? from them means your devices will individually get > public addresses, which isn?t a requirement for us, isn?t quite as > easy to add multiple devices and costs our customers more money. > > Here are my questions: > > 1. Is it really accurate that the customer?s address is tied to the > modem/router? > > 2. For my curiosity, is this done through a DHCP reservation or is > there a hard coded entry somewhere? > > 3. Do all U-Verse modem/routers behave the same way? This particular > unit was a Motorola but the friends I?ve seen with U-Verse use a > Cisco unit. > > --- > > Keith Stokes > > > > > From jtk at cymru.com Thu Jul 30 20:45:52 2015 From: jtk at cymru.com (John Kristoff) Date: Thu, 30 Jul 2015 15:45:52 -0500 Subject: UDP clamped on service provider links In-Reply-To: References: Message-ID: <20150730154552.63a3ecd5@localhost> On Mon, 27 Jul 2015 19:42:46 +0530 Glen Kent wrote: > Is it true that UDP is often subjected to stiffer rate limits than > TCP? Yes, although I'm not sure how widespread this is in most, if even many networks. Probably not very widely deployed today, but restrictions and limitations only seem to expand rather than recede. I've done this, and not just for UDP, in a university environment. I implemented this at time the Slammer worm came out on all the ingress interfaces of user-facing subnets. This was meant as a more general solution to "capacity collapse" rather than strictly as security issue, because we were also struggling with capacity filling apps like Napster at the time, but Slammer was the tipping point. To summarize what we did for aggregate rates from host subnets (these were generally 100 Mb/s IPv4 /24-/25 LANs): ICMP: 2 Mb/s UDP: 10 Mb/s MCAST: 10 Mb/s (separate UDP group) IGMP: 2 Mb/s IPSEC: 10 Mb/s (esp - can't ensure flow control of crypto traffic) GRE: 10 Mb/s Other: 10 Mb/s for everything else except for TCP If traffic was staying local within the campus network, limits did not apply. There were no limits for TCP traffic. We generally did not apply limits to well defined and generally well managed server subnets. We were aware that certain measurement tools might produce misleading results, a trade-off we were willing to accept. As far as I could tell, the limits generally worked well and helped minimize Slammer and more general problems. If ISPs could implement a similar mechanism, I think this could be a reasonable approach today still. Perhaps more necessary than ever before, but a big part of the problem is that the networks where you'd really want to see this sort of thing implemented, won't do it. > Is there a reason why this is often done so? Is this because UDP > is stateless and any script kiddie could launch a DOS attack with a > UDP stream? State, some form of sender verification and that it and most other commonly used protocols besides TCP do not generally react to implicit congestion signals (drops usually). > Given the state of affairs these days how difficult is it going to be > for somebody to launch a DOS attack with some other protocol? There has been ICMP-based attacks and there are, at least in theory if not common in practice, others such as IGMP-based attacks. There have been numerous DoS (single D) attacks with TCP-based services precisely because of weaknesses or difficulties in managing unexpected TCP session behavior. The potential sending capacity of even a small set of hosts from around the globe, UDP, TCP or other protocol, could easily overwhelm many points of aggregation. All it takes is for an attacker to coerce that a sufficient subset of hosts to send the packets. John From chuckchurch at gmail.com Thu Jul 30 20:47:55 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Thu, 30 Jul 2015 16:47:55 -0400 Subject: NANOG isn't for desktop OS licensing support, was: Windows 10 Release Message-ID: <011b01d0cb09$0c63ddc0$252b9940$@gmail.com> I hate to be that guy, but this is getting really outside the scope of NANOG. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Greco Sent: Thursday, July 30, 2015 12:58 PM To: Scott Helms Cc: NANOG Subject: Re: Windows 10 Release > I was just thinking about my remaining Win 7 box _after_ I hit send > and I believe you're correct (I have one still to upgrade). Which > means users upgrading from 7 to 10 will need to create an ID, but > users of 8 and 8.1 will use the one they already have. This is incorrect. While the Win 8{,.1} install process makes it appear as though you need a Microsoft ID, you can actually go into the "create a new Microsoft ID" option and there's a way to proceed without creating a Microsoft ID, which leaves you with all local accounts. It does appear to be designed to make you THINK you need a Microsoft account however. I have a freshly installed Windows 8.1 box here (no Microsoft ID) that I then upgraded to Windows 10, and it also does not have any Microsoft ID attached to it. Activation shows as "Windows 10 Home" and "Windows is activated." There's a beggy-screen on the user account page saying something like "Windows is better when your settings and files automatically sync. Switch to a Microsoft Account now!" So, again, totally optional, but admittedly the path of least resistance has users creating a Microsoft Account or linking to their existing one. You have to trawl around a little to get the better (IMHO) behaviour. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rdobbins at arbor.net Thu Jul 30 20:57:10 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 31 Jul 2015 03:57:10 +0700 Subject: UDP clamped on service provider links In-Reply-To: References: Message-ID: On 27 Jul 2015, at 21:12, Glen Kent wrote: > Given the state of affairs these days how difficult is it going to be > for somebody to launch a DOS attack with some other protocol? ----------------------------------- Roland Dobbins From ted.ietf at gmail.com Thu Jul 30 21:04:20 2015 From: ted.ietf at gmail.com (Ted Hardie) Date: Thu, 30 Jul 2015 14:04:20 -0700 Subject: UDP clamped on service provider links In-Reply-To: <20150730154552.63a3ecd5@localhost> References: <20150730154552.63a3ecd5@localhost> Message-ID: On Thu, Jul 30, 2015 at 1:45 PM, John Kristoff wrote: > On Mon, 27 Jul 2015 19:42:46 +0530 > Glen Kent wrote: > > > > Is there a reason why this is often done so? Is this because UDP > > is stateless and any script kiddie could launch a DOS attack with a > > UDP stream? > > State, some form of sender verification and that it and most other > commonly used protocols besides TCP do not generally react to implicit > congestion signals (drops usually). > > ?Hmmm. The WebRTC ?stack has a pretty explicit form of getting and then maintaining consent; it also rides on top of UDP (SRTP/UDP for media and SCTP/DTLS/UDP for data channels). Because both media and data channels go from peer to peer, it has no preset group of server addresses to white list (the only way I can see to do that would be to force the use of TURN and white list the TURN server, but that would be problematic for performance). How will you support it if the default is to throttle UDP? Clue welcome, Ted From keiths at neilltech.com Thu Jul 30 21:06:51 2015 From: keiths at neilltech.com (Keith Stokes) Date: Thu, 30 Jul 2015 21:06:51 +0000 Subject: AT&T U-Verse Data Setup Convention In-Reply-To: References: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> Message-ID: <2DAF1D76-81EF-44EA-BA97-3580E8D3DF48@neilltech.com> ?Forever? is a long time. We?re shooting for not having to change people?s address multiple times per week while still trying to help them save costs by not paying extra for ?official" static IPs. Changing every 6 months as some have pointed out as their experience is perfectly acceptable to us. On Jul 30, 2015, at 11:51 AM, James Hartig > wrote: I've had AT&T UVerse for 3 years now and it has changed at least twice since I got it. The DHCP address has an expiration of ~7 days and it usually keeps the same address upon renewal but a few times I have noticed that it's changed. I wouldn't trust it to be static forever. -- James Hartig --- Keith Stokes From cb.list6 at gmail.com Thu Jul 30 21:31:59 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 30 Jul 2015 14:31:59 -0700 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> Message-ID: On Thu, Jul 30, 2015 at 2:04 PM, Ted Hardie wrote: > On Thu, Jul 30, 2015 at 1:45 PM, John Kristoff wrote: > > > On Mon, 27 Jul 2015 19:42:46 +0530 > > Glen Kent wrote: > > > > > > > Is there a reason why this is often done so? Is this because UDP > > > is stateless and any script kiddie could launch a DOS attack with a > > > UDP stream? > > > > State, some form of sender verification and that it and most other > > commonly used protocols besides TCP do not generally react to implicit > > congestion signals (drops usually). > > > > > ?Hmmm. The WebRTC ?stack has a pretty explicit form of getting and then > maintaining consent; it also rides on top of UDP (SRTP/UDP for media and > SCTP/DTLS/UDP for data channels). Because both media and data channels go > from peer to peer, it has no preset group of server addresses to white list > (the only way I can see to do that would be to force the use of TURN and > white list the TURN server, but that would be problematic for > performance). How will you support it if the default is to throttle UDP? > > Clue welcome, > > Ted > We will install a middlebox to strip off the UDP and expose the SCTP natively as the transport protocol ! Patent pending! RTCweb made a series of trade offs. Encapsulating SCTP in UDP is one of them... the idea at the time was the this is only WebRTC 1.0, so we'll do a few silly things to ship it early. As i am sure you know :) From nanogml at Mail.DDoS-Mitigator.net Thu Jul 30 21:50:53 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Thu, 30 Jul 2015 14:50:53 -0700 Subject: DDOS Simulation In-Reply-To: <5A733F6C-9D5E-4E19-A18C-B787D9A71A89@arbor.net> References: <20150728221940.GA25835@Mail.DDoS-Mitigator.net> <20150729193818.GA32446@Mail.DDoS-Mitigator.net> <5A733F6C-9D5E-4E19-A18C-B787D9A71A89@arbor.net> Message-ID: <20150730215053.GA13427@Mail.DDoS-Mitigator.net> hi roland - yup... agreed on most all of your points ... - good referral to prev ddos discussions - i'm just saying .. if one cannot defend and know that their ddos mitigation is working on the low level free script kiddie ddos attacks, they should not worry about scaling to gigabit/s, 1terabit/sec or even 100 terabit/s ddos attacks ... one has to start somewhere and grow their ddos mitigation and ddos attacks knowledge ... i happen to need to know how to defend my customers in between the free script kiddies and the types of attacks that make the papers/new start with free (thousands) of ddos attack tools and (hundreds) of free ddos mitigaton tools - i'm fairly certain i can fill any pipe with jibberish data where ddos mitigation might not work as expected .... but when the cops come knocking, the ddos attackers are in deeep kah kah, thus requiring prior legal paperwork of all those directly and indirectly involved have fun alvin On 07/30/15 at 03:05am, Roland Dobbins wrote: > On 30 Jul 2015, at 2:38, alvin nanog wrote: > > >there is no need to pay people to attack your servers ... > > Unless you don't have the expertise to do it yourself. Again, I advocate an > organic defense capability and an organic testing capability, but there are > many organizations which unfortunately don't have these, and they must start > somewhere. > > > - tcpdump and wireshark will tell you everything the attackers are > > doing to your network right now that needs to be defended against > > On small, single-homed networks, sure. On networks of any size, this > doesn't scale. > > Flow telemetry scales. > > >if a mid-level wanna be attacker wants to target your servers, they're > >just as equally easy to mitigate and prevent and probably sending you > >100,000 "ddos packets" per second because they can ( bigger zombie network > >:-) > > 100kpps is nothing. Of course, so many servers/services are so brittle, > fragile, and non-scalable that most DDoS attacks are overkill by orders of > magnitude. > > >if you are being targeted by "masters of deception" you have no solution > >other than get local law enforcement involved to track down the > >originating > >attackers > > I'm not sure who or what 'masters of deception' are in this context, but > attribution has nothing to do with DDoS defense. > > Defending against serious attackers with lots of resources is taking place > every minute of every hour of every day. There are many techniques and > tools available, most of which have been discussed multiple times on this > list over the years. Here's one such example: > > > > >all ddos mitigations is almost 100% guaranteed to fail a volumetric > >DDoS attacks .... > > This is incorrect. > > >the DDoS attackrs probably have access to a bigger zombie > >network than most major corp ... > > This is true, in many cases - and is also not an issue for > properly-provisioned, coordinated DDoS defense mechanisms and methodologies. > > >the attackers job is not to get caught and > >is not ez to be hiding if law enforcement wanted to catch them :-) > > Again, attribution is a completely separate issue. > > > nping "send 100,000 packets/sec" x 65,000byte/packet 192.168.0.0/16 > > FYI, 'line-rate' for 64-byte packets at 10gb/sec is ~14.8mpps. > > >by the same premise, if i had to pick ONE ddos mitigation strategy, i'd > >tarpit all incoming TCP-based ddos attacks which should crash the > >attacking zombie server under sustained tcp-based ddos attacks > > There is no one tactic (this is not a strategy) which can be picked, as any > kind of traffic can be used for DDoS attacks. With regards to TCP-based > attacks, it's a subset of those which are connection-oriented and are thus > susceptible to tarpitting-type techniques. > > ----------------------------------- > Roland Dobbins From jfbeam at gmail.com Thu Jul 30 22:31:29 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 30 Jul 2015 18:31:29 -0400 Subject: AT&T U-Verse Data Setup Convention In-Reply-To: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> References: <5BD14ADA-0315-4A2D-84C5-733DFE9A4B5A@neilltech.com> Message-ID: On Thu, 30 Jul 2015 12:02:06 -0400, Keith Stokes wrote: > 1. Is it really accurate that the customer?s address is tied to the > modem/router? To the 802.1x identity of the device, yes. That's the unit serial number, which (partial) contains the MAC. > 2. For my curiosity, is this done through a DHCP reservation or is there > a hard coded entry somewhere? No. It's just "plain" DHCP. Until the pool is depleted, addresses don't get recycled. So, even if your address were released, it would take days before it would be assigned to someone else. (which DOES happen, btw) Addresses are *NOT* hard coded. You can order (and pay for) a static subnet that is routed to whatever dynamic link address you get. That's the only "static" they offer. > 3. Do all U-Verse modem/routers behave the same way? This particular > unit was a Motorola but the friends I?ve seen with U-Verse use a Cisco > unit. Yes. This is a fundamental part of the network. If you *do* manage to side-step their PoS hardware, your own router will experience the same addressing scheme. From jason at thebaughers.com Fri Jul 31 02:12:18 2015 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 30 Jul 2015 21:12:18 -0500 Subject: UDP clamped on service provider links In-Reply-To: <20150730154552.63a3ecd5@localhost> References: <20150730154552.63a3ecd5@localhost> Message-ID: To bring this discussion to specifics, we've been fighting an issue where our customers are experiencing poor audio quality on SIP calls. The only carrier between our customers and the hosted VoIP provider is Level3. From multiple wiresharks, it appears that a certain percentage of UDP packets - in this case RTP - are getting lost in the Level3 network somewhere. We've got a ticket open with Level3, but haven't gotten far yet. Has anyone else seen Level3 or other carriers rate-limiting UDP and breaking these legitimate services? On Thu, Jul 30, 2015 at 3:45 PM, John Kristoff wrote: > On Mon, 27 Jul 2015 19:42:46 +0530 > Glen Kent wrote: > > > Is it true that UDP is often subjected to stiffer rate limits than > > TCP? > > Yes, although I'm not sure how widespread this is in most, if even many > networks. Probably not very widely deployed today, but restrictions and > limitations only seem to expand rather than recede. > > I've done this, and not just for UDP, in a university environment. I > implemented this at time the Slammer worm came out on all the ingress > interfaces of user-facing subnets. This was meant as a more general > solution to "capacity collapse" rather than strictly as security issue, > because we were also struggling with capacity filling apps like Napster > at the time, but Slammer was the tipping point. To summarize what we > did for aggregate rates from host subnets (these were generally 100 Mb/s > IPv4 /24-/25 LANs): > > ICMP: 2 Mb/s > UDP: 10 Mb/s > MCAST: 10 Mb/s (separate UDP group) > IGMP: 2 Mb/s > IPSEC: 10 Mb/s (esp - can't ensure flow control of crypto traffic) > GRE: 10 Mb/s > Other: 10 Mb/s for everything else except for TCP > > If traffic was staying local within the campus network, limits did not > apply. There were no limits for TCP traffic. We generally did not > apply limits to well defined and generally well managed server subnets. > We were aware that certain measurement tools might produce misleading > results, a trade-off we were willing to accept. > > As far as I could tell, the limits generally worked well and helped > minimize Slammer and more general problems. If ISPs could implement a > similar mechanism, I think this could be a reasonable approach today > still. Perhaps more necessary than ever before, but a big part of the > problem is that the networks where you'd really want to see this sort > of thing implemented, won't do it. > > > Is there a reason why this is often done so? Is this because UDP > > is stateless and any script kiddie could launch a DOS attack with a > > UDP stream? > > State, some form of sender verification and that it and most other > commonly used protocols besides TCP do not generally react to implicit > congestion signals (drops usually). > > > Given the state of affairs these days how difficult is it going to be > > for somebody to launch a DOS attack with some other protocol? > > There has been ICMP-based attacks and there are, at least in theory if > not common in practice, others such as IGMP-based attacks. There have > been numerous DoS (single D) attacks with TCP-based services precisely > because of weaknesses or difficulties in managing unexpected TCP > session behavior. The potential sending capacity of even a small set > of hosts from around the globe, UDP, TCP or other protocol, could > easily overwhelm many points of aggregation. All it takes is for an > attacker to coerce that a sufficient subset of hosts to send the > packets. > > John > From mhoppes at indigowireless.com Fri Jul 31 02:15:59 2015 From: mhoppes at indigowireless.com (Matt Hoppes) Date: Thu, 30 Jul 2015 22:15:59 -0400 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> Message-ID: <0A4F7F83-291A-4A7C-A30B-012133686346@indigowireless.com> No. But I've seen Level3 just have really bad packet loss. > On Jul 30, 2015, at 22:12, Jason Baugher wrote: > > To bring this discussion to specifics, we've been fighting an issue where > our customers are experiencing poor audio quality on SIP calls. The only > carrier between our customers and the hosted VoIP provider is Level3. From > multiple wiresharks, it appears that a certain percentage of UDP packets - > in this case RTP - are getting lost in the Level3 network somewhere. We've > got a ticket open with Level3, but haven't gotten far yet. Has anyone else > seen Level3 or other carriers rate-limiting UDP and breaking these > legitimate services? > >> On Thu, Jul 30, 2015 at 3:45 PM, John Kristoff wrote: >> >> On Mon, 27 Jul 2015 19:42:46 +0530 >> Glen Kent wrote: >> >>> Is it true that UDP is often subjected to stiffer rate limits than >>> TCP? >> >> Yes, although I'm not sure how widespread this is in most, if even many >> networks. Probably not very widely deployed today, but restrictions and >> limitations only seem to expand rather than recede. >> >> I've done this, and not just for UDP, in a university environment. I >> implemented this at time the Slammer worm came out on all the ingress >> interfaces of user-facing subnets. This was meant as a more general >> solution to "capacity collapse" rather than strictly as security issue, >> because we were also struggling with capacity filling apps like Napster >> at the time, but Slammer was the tipping point. To summarize what we >> did for aggregate rates from host subnets (these were generally 100 Mb/s >> IPv4 /24-/25 LANs): >> >> ICMP: 2 Mb/s >> UDP: 10 Mb/s >> MCAST: 10 Mb/s (separate UDP group) >> IGMP: 2 Mb/s >> IPSEC: 10 Mb/s (esp - can't ensure flow control of crypto traffic) >> GRE: 10 Mb/s >> Other: 10 Mb/s for everything else except for TCP >> >> If traffic was staying local within the campus network, limits did not >> apply. There were no limits for TCP traffic. We generally did not >> apply limits to well defined and generally well managed server subnets. >> We were aware that certain measurement tools might produce misleading >> results, a trade-off we were willing to accept. >> >> As far as I could tell, the limits generally worked well and helped >> minimize Slammer and more general problems. If ISPs could implement a >> similar mechanism, I think this could be a reasonable approach today >> still. Perhaps more necessary than ever before, but a big part of the >> problem is that the networks where you'd really want to see this sort >> of thing implemented, won't do it. >> >>> Is there a reason why this is often done so? Is this because UDP >>> is stateless and any script kiddie could launch a DOS attack with a >>> UDP stream? >> >> State, some form of sender verification and that it and most other >> commonly used protocols besides TCP do not generally react to implicit >> congestion signals (drops usually). >> >>> Given the state of affairs these days how difficult is it going to be >>> for somebody to launch a DOS attack with some other protocol? >> >> There has been ICMP-based attacks and there are, at least in theory if >> not common in practice, others such as IGMP-based attacks. There have >> been numerous DoS (single D) attacks with TCP-based services precisely >> because of weaknesses or difficulties in managing unexpected TCP >> session behavior. The potential sending capacity of even a small set >> of hosts from around the globe, UDP, TCP or other protocol, could >> easily overwhelm many points of aggregation. All it takes is for an >> attacker to coerce that a sufficient subset of hosts to send the >> packets. >> >> John >> From jason at thebaughers.com Fri Jul 31 02:18:10 2015 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 30 Jul 2015 21:18:10 -0500 Subject: UDP clamped on service provider links In-Reply-To: <0A4F7F83-291A-4A7C-A30B-012133686346@indigowireless.com> References: <20150730154552.63a3ecd5@localhost> <0A4F7F83-291A-4A7C-A30B-012133686346@indigowireless.com> Message-ID: In one case, when we were having an issue with a SIP trunk, we re-numbered our end to another IP in the same subnet. Same path from A to Z, but the packet loss mysteriously disappeared using the new IP. It sure seems like they are throttling somewhere. On Thu, Jul 30, 2015 at 9:15 PM, Matt Hoppes wrote: > No. But I've seen Level3 just have really bad packet loss. > > > > > On Jul 30, 2015, at 22:12, Jason Baugher wrote: > > > > To bring this discussion to specifics, we've been fighting an issue where > > our customers are experiencing poor audio quality on SIP calls. The only > > carrier between our customers and the hosted VoIP provider is Level3. > From > > multiple wiresharks, it appears that a certain percentage of UDP packets > - > > in this case RTP - are getting lost in the Level3 network somewhere. > We've > > got a ticket open with Level3, but haven't gotten far yet. Has anyone > else > > seen Level3 or other carriers rate-limiting UDP and breaking these > > legitimate services? > > > >> On Thu, Jul 30, 2015 at 3:45 PM, John Kristoff wrote: > >> > >> On Mon, 27 Jul 2015 19:42:46 +0530 > >> Glen Kent wrote: > >> > >>> Is it true that UDP is often subjected to stiffer rate limits than > >>> TCP? > >> > >> Yes, although I'm not sure how widespread this is in most, if even many > >> networks. Probably not very widely deployed today, but restrictions and > >> limitations only seem to expand rather than recede. > >> > >> I've done this, and not just for UDP, in a university environment. I > >> implemented this at time the Slammer worm came out on all the ingress > >> interfaces of user-facing subnets. This was meant as a more general > >> solution to "capacity collapse" rather than strictly as security issue, > >> because we were also struggling with capacity filling apps like Napster > >> at the time, but Slammer was the tipping point. To summarize what we > >> did for aggregate rates from host subnets (these were generally 100 Mb/s > >> IPv4 /24-/25 LANs): > >> > >> ICMP: 2 Mb/s > >> UDP: 10 Mb/s > >> MCAST: 10 Mb/s (separate UDP group) > >> IGMP: 2 Mb/s > >> IPSEC: 10 Mb/s (esp - can't ensure flow control of crypto traffic) > >> GRE: 10 Mb/s > >> Other: 10 Mb/s for everything else except for TCP > >> > >> If traffic was staying local within the campus network, limits did not > >> apply. There were no limits for TCP traffic. We generally did not > >> apply limits to well defined and generally well managed server subnets. > >> We were aware that certain measurement tools might produce misleading > >> results, a trade-off we were willing to accept. > >> > >> As far as I could tell, the limits generally worked well and helped > >> minimize Slammer and more general problems. If ISPs could implement a > >> similar mechanism, I think this could be a reasonable approach today > >> still. Perhaps more necessary than ever before, but a big part of the > >> problem is that the networks where you'd really want to see this sort > >> of thing implemented, won't do it. > >> > >>> Is there a reason why this is often done so? Is this because UDP > >>> is stateless and any script kiddie could launch a DOS attack with a > >>> UDP stream? > >> > >> State, some form of sender verification and that it and most other > >> commonly used protocols besides TCP do not generally react to implicit > >> congestion signals (drops usually). > >> > >>> Given the state of affairs these days how difficult is it going to be > >>> for somebody to launch a DOS attack with some other protocol? > >> > >> There has been ICMP-based attacks and there are, at least in theory if > >> not common in practice, others such as IGMP-based attacks. There have > >> been numerous DoS (single D) attacks with TCP-based services precisely > >> because of weaknesses or difficulties in managing unexpected TCP > >> session behavior. The potential sending capacity of even a small set > >> of hosts from around the globe, UDP, TCP or other protocol, could > >> easily overwhelm many points of aggregation. All it takes is for an > >> attacker to coerce that a sufficient subset of hosts to send the > >> packets. > >> > >> John > >> > From tsands at rackspace.com Fri Jul 31 02:44:37 2015 From: tsands at rackspace.com (Tom Sands) Date: Fri, 31 Jul 2015 02:44:37 +0000 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost>, Message-ID: We have similar problems with UDP 500 and being able to keep IPSEC tunnels up over Level3. It happens quite a bit when there are no signs of TCP or ICMP packet loss. Sent from my iPhone > On Jul 30, 2015, at 9:14 PM, Jason Baugher wrote: > > To bring this discussion to specifics, we've been fighting an issue where > our customers are experiencing poor audio quality on SIP calls. The only > carrier between our customers and the hosted VoIP provider is Level3. From > multiple wiresharks, it appears that a certain percentage of UDP packets - > in this case RTP - are getting lost in the Level3 network somewhere. We've > got a ticket open with Level3, but haven't gotten far yet. Has anyone else > seen Level3 or other carriers rate-limiting UDP and breaking these > legitimate services? > >> On Thu, Jul 30, 2015 at 3:45 PM, John Kristoff wrote: >> >> On Mon, 27 Jul 2015 19:42:46 +0530 >> Glen Kent wrote: >> >>> Is it true that UDP is often subjected to stiffer rate limits than >>> TCP? >> >> Yes, although I'm not sure how widespread this is in most, if even many >> networks. Probably not very widely deployed today, but restrictions and >> limitations only seem to expand rather than recede. >> >> I've done this, and not just for UDP, in a university environment. I >> implemented this at time the Slammer worm came out on all the ingress >> interfaces of user-facing subnets. This was meant as a more general >> solution to "capacity collapse" rather than strictly as security issue, >> because we were also struggling with capacity filling apps like Napster >> at the time, but Slammer was the tipping point. To summarize what we >> did for aggregate rates from host subnets (these were generally 100 Mb/s >> IPv4 /24-/25 LANs): >> >> ICMP: 2 Mb/s >> UDP: 10 Mb/s >> MCAST: 10 Mb/s (separate UDP group) >> IGMP: 2 Mb/s >> IPSEC: 10 Mb/s (esp - can't ensure flow control of crypto traffic) >> GRE: 10 Mb/s >> Other: 10 Mb/s for everything else except for TCP >> >> If traffic was staying local within the campus network, limits did not >> apply. There were no limits for TCP traffic. We generally did not >> apply limits to well defined and generally well managed server subnets. >> We were aware that certain measurement tools might produce misleading >> results, a trade-off we were willing to accept. >> >> As far as I could tell, the limits generally worked well and helped >> minimize Slammer and more general problems. If ISPs could implement a >> similar mechanism, I think this could be a reasonable approach today >> still. Perhaps more necessary than ever before, but a big part of the >> problem is that the networks where you'd really want to see this sort >> of thing implemented, won't do it. >> >>> Is there a reason why this is often done so? Is this because UDP >>> is stateless and any script kiddie could launch a DOS attack with a >>> UDP stream? >> >> State, some form of sender verification and that it and most other >> commonly used protocols besides TCP do not generally react to implicit >> congestion signals (drops usually). >> >>> Given the state of affairs these days how difficult is it going to be >>> for somebody to launch a DOS attack with some other protocol? >> >> There has been ICMP-based attacks and there are, at least in theory if >> not common in practice, others such as IGMP-based attacks. There have >> been numerous DoS (single D) attacks with TCP-based services precisely >> because of weaknesses or difficulties in managing unexpected TCP >> session behavior. The potential sending capacity of even a small set >> of hosts from around the globe, UDP, TCP or other protocol, could >> easily overwhelm many points of aggregation. All it takes is for an >> attacker to coerce that a sufficient subset of hosts to send the >> packets. >> >> John >> From jason at thebaughers.com Fri Jul 31 02:59:42 2015 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 30 Jul 2015 21:59:42 -0500 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> Message-ID: Several months ago we had an issue with a customer whose IPSEC tunnels we manage. One of the tunnels dropped, and after troubleshooting we were able to prove that only udp/500 was being blocked in one direction for one specific source and destination IP. Level3 resolved the issue, but claimed it was due to a "mis-configured NNI" between themselves and Charter. Seems odd that an NNI mis-config could cause something that specific, doesn't it? On Thu, Jul 30, 2015 at 9:44 PM, Tom Sands wrote: > We have similar problems with UDP 500 and being able to keep IPSEC tunnels > up over Level3. It happens quite a bit when there are no signs of TCP or > ICMP packet loss. > > Sent from my iPhone > > > On Jul 30, 2015, at 9:14 PM, Jason Baugher > wrote: > > > > To bring this discussion to specifics, we've been fighting an issue where > > our customers are experiencing poor audio quality on SIP calls. The only > > carrier between our customers and the hosted VoIP provider is Level3. > From > > multiple wiresharks, it appears that a certain percentage of UDP packets > - > > in this case RTP - are getting lost in the Level3 network somewhere. > We've > > got a ticket open with Level3, but haven't gotten far yet. Has anyone > else > > seen Level3 or other carriers rate-limiting UDP and breaking these > > legitimate services? > > > >> On Thu, Jul 30, 2015 at 3:45 PM, John Kristoff wrote: > >> > >> On Mon, 27 Jul 2015 19:42:46 +0530 > >> Glen Kent wrote: > >> > >>> Is it true that UDP is often subjected to stiffer rate limits than > >>> TCP? > >> > >> Yes, although I'm not sure how widespread this is in most, if even many > >> networks. Probably not very widely deployed today, but restrictions and > >> limitations only seem to expand rather than recede. > >> > >> I've done this, and not just for UDP, in a university environment. I > >> implemented this at time the Slammer worm came out on all the ingress > >> interfaces of user-facing subnets. This was meant as a more general > >> solution to "capacity collapse" rather than strictly as security issue, > >> because we were also struggling with capacity filling apps like Napster > >> at the time, but Slammer was the tipping point. To summarize what we > >> did for aggregate rates from host subnets (these were generally 100 Mb/s > >> IPv4 /24-/25 LANs): > >> > >> ICMP: 2 Mb/s > >> UDP: 10 Mb/s > >> MCAST: 10 Mb/s (separate UDP group) > >> IGMP: 2 Mb/s > >> IPSEC: 10 Mb/s (esp - can't ensure flow control of crypto traffic) > >> GRE: 10 Mb/s > >> Other: 10 Mb/s for everything else except for TCP > >> > >> If traffic was staying local within the campus network, limits did not > >> apply. There were no limits for TCP traffic. We generally did not > >> apply limits to well defined and generally well managed server subnets. > >> We were aware that certain measurement tools might produce misleading > >> results, a trade-off we were willing to accept. > >> > >> As far as I could tell, the limits generally worked well and helped > >> minimize Slammer and more general problems. If ISPs could implement a > >> similar mechanism, I think this could be a reasonable approach today > >> still. Perhaps more necessary than ever before, but a big part of the > >> problem is that the networks where you'd really want to see this sort > >> of thing implemented, won't do it. > >> > >>> Is there a reason why this is often done so? Is this because UDP > >>> is stateless and any script kiddie could launch a DOS attack with a > >>> UDP stream? > >> > >> State, some form of sender verification and that it and most other > >> commonly used protocols besides TCP do not generally react to implicit > >> congestion signals (drops usually). > >> > >>> Given the state of affairs these days how difficult is it going to be > >>> for somebody to launch a DOS attack with some other protocol? > >> > >> There has been ICMP-based attacks and there are, at least in theory if > >> not common in practice, others such as IGMP-based attacks. There have > >> been numerous DoS (single D) attacks with TCP-based services precisely > >> because of weaknesses or difficulties in managing unexpected TCP > >> session behavior. The potential sending capacity of even a small set > >> of hosts from around the globe, UDP, TCP or other protocol, could > >> easily overwhelm many points of aggregation. All it takes is for an > >> attacker to coerce that a sufficient subset of hosts to send the > >> packets. > >> > >> John > >> > From cb.list6 at gmail.com Fri Jul 31 03:51:32 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 30 Jul 2015 20:51:32 -0700 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> Message-ID: On Thursday, July 30, 2015, Jason Baugher wrote: > Several months ago we had an issue with a customer whose IPSEC tunnels we > manage. One of the tunnels dropped, and after troubleshooting we were able > to prove that only udp/500 was being blocked in one direction for one > specific source and destination IP. Level3 resolved the issue, but claimed > it was due to a "mis-configured NNI" between themselves and Charter. Seems > odd that an NNI mis-config could cause something that specific, doesn't it? > > NNI is a peering link. Peering links blow up during ddos since they act as a narrow funnel of traffic between networks. So NNI is exactly where udp ddos filters show up most, at least that is my guess > On Thu, Jul 30, 2015 at 9:44 PM, Tom Sands > wrote: > > > We have similar problems with UDP 500 and being able to keep IPSEC > tunnels > > up over Level3. It happens quite a bit when there are no signs of TCP or > > ICMP packet loss. > > > > Sent from my iPhone > > > > > On Jul 30, 2015, at 9:14 PM, Jason Baugher > > > wrote: > > > > > > To bring this discussion to specifics, we've been fighting an issue > where > > > our customers are experiencing poor audio quality on SIP calls. The > only > > > carrier between our customers and the hosted VoIP provider is Level3. > > From > > > multiple wiresharks, it appears that a certain percentage of UDP > packets > > - > > > in this case RTP - are getting lost in the Level3 network somewhere. > > We've > > > got a ticket open with Level3, but haven't gotten far yet. Has anyone > > else > > > seen Level3 or other carriers rate-limiting UDP and breaking these > > > legitimate services? > > > > > >> On Thu, Jul 30, 2015 at 3:45 PM, John Kristoff > wrote: > > >> > > >> On Mon, 27 Jul 2015 19:42:46 +0530 > > >> Glen Kent > wrote: > > >> > > >>> Is it true that UDP is often subjected to stiffer rate limits than > > >>> TCP? > > >> > > >> Yes, although I'm not sure how widespread this is in most, if even > many > > >> networks. Probably not very widely deployed today, but restrictions > and > > >> limitations only seem to expand rather than recede. > > >> > > >> I've done this, and not just for UDP, in a university environment. I > > >> implemented this at time the Slammer worm came out on all the ingress > > >> interfaces of user-facing subnets. This was meant as a more general > > >> solution to "capacity collapse" rather than strictly as security > issue, > > >> because we were also struggling with capacity filling apps like > Napster > > >> at the time, but Slammer was the tipping point. To summarize what we > > >> did for aggregate rates from host subnets (these were generally 100 > Mb/s > > >> IPv4 /24-/25 LANs): > > >> > > >> ICMP: 2 Mb/s > > >> UDP: 10 Mb/s > > >> MCAST: 10 Mb/s (separate UDP group) > > >> IGMP: 2 Mb/s > > >> IPSEC: 10 Mb/s (esp - can't ensure flow control of crypto traffic) > > >> GRE: 10 Mb/s > > >> Other: 10 Mb/s for everything else except for TCP > > >> > > >> If traffic was staying local within the campus network, limits did not > > >> apply. There were no limits for TCP traffic. We generally did not > > >> apply limits to well defined and generally well managed server > subnets. > > >> We were aware that certain measurement tools might produce misleading > > >> results, a trade-off we were willing to accept. > > >> > > >> As far as I could tell, the limits generally worked well and helped > > >> minimize Slammer and more general problems. If ISPs could implement a > > >> similar mechanism, I think this could be a reasonable approach today > > >> still. Perhaps more necessary than ever before, but a big part of the > > >> problem is that the networks where you'd really want to see this sort > > >> of thing implemented, won't do it. > > >> > > >>> Is there a reason why this is often done so? Is this because UDP > > >>> is stateless and any script kiddie could launch a DOS attack with a > > >>> UDP stream? > > >> > > >> State, some form of sender verification and that it and most other > > >> commonly used protocols besides TCP do not generally react to implicit > > >> congestion signals (drops usually). > > >> > > >>> Given the state of affairs these days how difficult is it going to be > > >>> for somebody to launch a DOS attack with some other protocol? > > >> > > >> There has been ICMP-based attacks and there are, at least in theory if > > >> not common in practice, others such as IGMP-based attacks. There have > > >> been numerous DoS (single D) attacks with TCP-based services precisely > > >> because of weaknesses or difficulties in managing unexpected TCP > > >> session behavior. The potential sending capacity of even a small set > > >> of hosts from around the globe, UDP, TCP or other protocol, could > > >> easily overwhelm many points of aggregation. All it takes is for an > > >> attacker to coerce that a sufficient subset of hosts to send the > > >> packets. > > >> > > >> John > > >> > > > From jason at thebaughers.com Fri Jul 31 04:07:43 2015 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 30 Jul 2015 23:07:43 -0500 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> Message-ID: Oh, I'm aware of the function of an NNI. I even accept that a carrier might feel the need to filter bad traffic. I've certainly done so for things like the Moon exploit. What I don't like is arbitrary filtering of traffic and the denial of such filtering by the carrier. On Thu, Jul 30, 2015 at 10:51 PM, Ca By wrote: > > > On Thursday, July 30, 2015, Jason Baugher wrote: > >> Several months ago we had an issue with a customer whose IPSEC tunnels we >> manage. One of the tunnels dropped, and after troubleshooting we were able >> to prove that only udp/500 was being blocked in one direction for one >> specific source and destination IP. Level3 resolved the issue, but claimed >> it was due to a "mis-configured NNI" between themselves and Charter. Seems >> odd that an NNI mis-config could cause something that specific, doesn't >> it? >> >> > NNI is a peering link. > > Peering links blow up during ddos since they act as a narrow funnel of > traffic between networks. > > So NNI is exactly where udp ddos filters show up most, at least that is my > guess > > > >> On Thu, Jul 30, 2015 at 9:44 PM, Tom Sands wrote: >> >> > We have similar problems with UDP 500 and being able to keep IPSEC >> tunnels >> > up over Level3. It happens quite a bit when there are no signs of TCP or >> > ICMP packet loss. >> > >> > Sent from my iPhone >> > >> > > On Jul 30, 2015, at 9:14 PM, Jason Baugher >> > wrote: >> > > >> > > To bring this discussion to specifics, we've been fighting an issue >> where >> > > our customers are experiencing poor audio quality on SIP calls. The >> only >> > > carrier between our customers and the hosted VoIP provider is Level3. >> > From >> > > multiple wiresharks, it appears that a certain percentage of UDP >> packets >> > - >> > > in this case RTP - are getting lost in the Level3 network somewhere. >> > We've >> > > got a ticket open with Level3, but haven't gotten far yet. Has anyone >> > else >> > > seen Level3 or other carriers rate-limiting UDP and breaking these >> > > legitimate services? >> > > >> > >> On Thu, Jul 30, 2015 at 3:45 PM, John Kristoff >> wrote: >> > >> >> > >> On Mon, 27 Jul 2015 19:42:46 +0530 >> > >> Glen Kent wrote: >> > >> >> > >>> Is it true that UDP is often subjected to stiffer rate limits than >> > >>> TCP? >> > >> >> > >> Yes, although I'm not sure how widespread this is in most, if even >> many >> > >> networks. Probably not very widely deployed today, but restrictions >> and >> > >> limitations only seem to expand rather than recede. >> > >> >> > >> I've done this, and not just for UDP, in a university environment. I >> > >> implemented this at time the Slammer worm came out on all the ingress >> > >> interfaces of user-facing subnets. This was meant as a more general >> > >> solution to "capacity collapse" rather than strictly as security >> issue, >> > >> because we were also struggling with capacity filling apps like >> Napster >> > >> at the time, but Slammer was the tipping point. To summarize what we >> > >> did for aggregate rates from host subnets (these were generally 100 >> Mb/s >> > >> IPv4 /24-/25 LANs): >> > >> >> > >> ICMP: 2 Mb/s >> > >> UDP: 10 Mb/s >> > >> MCAST: 10 Mb/s (separate UDP group) >> > >> IGMP: 2 Mb/s >> > >> IPSEC: 10 Mb/s (esp - can't ensure flow control of crypto traffic) >> > >> GRE: 10 Mb/s >> > >> Other: 10 Mb/s for everything else except for TCP >> > >> >> > >> If traffic was staying local within the campus network, limits did >> not >> > >> apply. There were no limits for TCP traffic. We generally did not >> > >> apply limits to well defined and generally well managed server >> subnets. >> > >> We were aware that certain measurement tools might produce misleading >> > >> results, a trade-off we were willing to accept. >> > >> >> > >> As far as I could tell, the limits generally worked well and helped >> > >> minimize Slammer and more general problems. If ISPs could implement >> a >> > >> similar mechanism, I think this could be a reasonable approach today >> > >> still. Perhaps more necessary than ever before, but a big part of >> the >> > >> problem is that the networks where you'd really want to see this sort >> > >> of thing implemented, won't do it. >> > >> >> > >>> Is there a reason why this is often done so? Is this because UDP >> > >>> is stateless and any script kiddie could launch a DOS attack with a >> > >>> UDP stream? >> > >> >> > >> State, some form of sender verification and that it and most other >> > >> commonly used protocols besides TCP do not generally react to >> implicit >> > >> congestion signals (drops usually). >> > >> >> > >>> Given the state of affairs these days how difficult is it going to >> be >> > >>> for somebody to launch a DOS attack with some other protocol? >> > >> >> > >> There has been ICMP-based attacks and there are, at least in theory >> if >> > >> not common in practice, others such as IGMP-based attacks. There >> have >> > >> been numerous DoS (single D) attacks with TCP-based services >> precisely >> > >> because of weaknesses or difficulties in managing unexpected TCP >> > >> session behavior. The potential sending capacity of even a small set >> > >> of hosts from around the globe, UDP, TCP or other protocol, could >> > >> easily overwhelm many points of aggregation. All it takes is for an >> > >> attacker to coerce that a sufficient subset of hosts to send the >> > >> packets. >> > >> >> > >> John >> > >> >> > >> > From randy at psg.com Fri Jul 31 04:42:35 2015 From: randy at psg.com (Randy Bush) Date: Fri, 31 Jul 2015 13:42:35 +0900 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> <0A4F7F83-291A-4A7C-A30B-012133686346@indigowireless.com> Message-ID: > In one case, when we were having an issue with a SIP trunk, we re-numbered > our end to another IP in the same subnet. Same path from A to Z, but the > packet loss mysteriously disappeared using the new IP. lag hash put you on a congested fiber? From jtk at cymru.com Fri Jul 31 12:07:30 2015 From: jtk at cymru.com (John Kristoff) Date: Fri, 31 Jul 2015 07:07:30 -0500 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> <0A4F7F83-291A-4A7C-A30B-012133686346@indigowireless.com> Message-ID: <20150731070730.7bfafbde@localhost> On Thu, 30 Jul 2015 21:18:10 -0500 Jason Baugher wrote: > In one case, when we were having an issue with a SIP trunk, we > re-numbered our end to another IP in the same subnet. Same path from > A to Z, but the packet loss mysteriously disappeared using the new > IP. It sure seems like they are throttling somewhere. Not knowing how you evaluated the two paths, but if MPLS was not considered, it may have perhaps been due in part to ECMP behavior. While not ruling out UDP limits, it is plausible that the changed source IP address resulted in a less congested path to be chosen. John From colton.conor at gmail.com Fri Jul 31 12:43:01 2015 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 31 Jul 2015 07:43:01 -0500 Subject: [BULK] Verizon exiting California In-Reply-To: <55BA5973.7070200@garlic.com> References: <55BA5973.7070200@garlic.com> Message-ID: Word on the street is that Verizon business/enterprise is about to be sold to Centrylink as well. Seems Verizon soon will only be Verizon Wireless. On Thu, Jul 30, 2015 at 12:05 PM, Robert Glover wrote: > On 7/30/2015 9:26 AM, Matthew Black wrote: > >> Verizon sent me a letter the other day stating that they are selling >> their landline business to Frontier Communications. It was a very terse >> letter and as a customer I don't know if it affects me. While stating they >> aren't exiting the Wireless business, I want to know which parts are being >> sold off. Just the copper lines, POTS, DSL, FIOS (TV, Internet, phone)? >> Some clarity would be great. I am a FIOS only customer. Can anyone recall >> if GTE was blocked from doing the same thing a few decades ago? >> >> matthew black >> california state university, long beach >> > > All wireline assets in the Verizon West footprint (California, Texas, and > Tampa, FL area) are being aquired by Frontier > > Here's the Press Release from Frontier: > http://investor.frontier.com/releasedetail.cfm?ReleaseID=895055 > > All wireless assets remain with Verizon. > From nanog at ics-il.net Fri Jul 31 13:27:21 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 31 Jul 2015 08:27:21 -0500 (CDT) Subject: [BULK] Verizon exiting California In-Reply-To: Message-ID: <900471531.5122.1438349265932.JavaMail.mhammett@ThunderFuck> Can anyone else back that up (or refute it)? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Colton Conor" To: "Robert Glover" Cc: "North American Network Operators' Group (nanog at nanog.org)" Sent: Friday, July 31, 2015 7:43:01 AM Subject: Re: [BULK] Verizon exiting California Word on the street is that Verizon business/enterprise is about to be sold to Centrylink as well. Seems Verizon soon will only be Verizon Wireless. On Thu, Jul 30, 2015 at 12:05 PM, Robert Glover wrote: > On 7/30/2015 9:26 AM, Matthew Black wrote: > >> Verizon sent me a letter the other day stating that they are selling >> their landline business to Frontier Communications. It was a very terse >> letter and as a customer I don't know if it affects me. While stating they >> aren't exiting the Wireless business, I want to know which parts are being >> sold off. Just the copper lines, POTS, DSL, FIOS (TV, Internet, phone)? >> Some clarity would be great. I am a FIOS only customer. Can anyone recall >> if GTE was blocked from doing the same thing a few decades ago? >> >> matthew black >> california state university, long beach >> > > All wireline assets in the Verizon West footprint (California, Texas, and > Tampa, FL area) are being aquired by Frontier > > Here's the Press Release from Frontier: > http://investor.frontier.com/releasedetail.cfm?ReleaseID=895055 > > All wireless assets remain with Verizon. > From michael.holstein at csuohio.edu Fri Jul 31 13:40:18 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Fri, 31 Jul 2015 13:40:18 +0000 Subject: Working with Spamhaus In-Reply-To: References: <55BA27C9.2050907@snovc.com> , Message-ID: Le sigh .. Hotmail/Outlook/Live https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us Google/Gmail https://support.google.com/mail/contact/bulk_send_new?rd=1 AOL https://postmaster.aol.com/trouble-ticket Yahoo https://io.help.yahoo.com/contact/index?page=contact&locale=en_US&y=PROD_MAIL_ML# As for SORBS, I'm not aware of anyone that uses it these days because of the extortion thing and the rather ..ahem .. "eccentric" nature of it's owner. Regards, Michael Holstein Cleveland State University ________________________________________ From: Ricky Beam Sent: Thursday, July 30, 2015 6:41 PM To: Michael O Holstein Subject: Re: Working with Spamhaus On Thu, 30 Jul 2015 09:59:55 -0400, Michael O Holstein wrote: > 100 spammy messages isn't enough to get you in trouble, as long as it > stops there. I see you've never had the pleasure of dealing with SORBS. All it takes is *ONE* message - EVER - to be instantly, and forever, listed in their spamtraps list. Getting on the list is automatic and immediate. There are no thresholds or limits; and there's expiration. The only way off that list is to PAY them to remove you. (which makes it illegal in most places. The corporate sharks flipped when I pointed them to that "policy".) > as were the other major players (MS, Google, AOL, Yahoo) by just filling > out their postmaster forms. What "postmaster forms"? Those 4 are the most *impossible* companies with whom I've ever tried to interact. I *know* there are people at Google but I'll be damned if there's a way to reach any of them. From mike-nanog at tiedyenetworks.com Fri Jul 31 14:32:49 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 31 Jul 2015 07:32:49 -0700 Subject: [BULK] Verizon exiting California In-Reply-To: <900471531.5122.1438349265932.JavaMail.mhammett@ThunderFuck> References: <900471531.5122.1438349265932.JavaMail.mhammett@ThunderFuck> Message-ID: <55BB8711.7090607@tiedyenetworks.com> On 07/31/2015 06:27 AM, Mike Hammett wrote: > Can anyone else back that up (or refute it)? > > I am a CLEC operating in California west, and I collocate with verizon. Yes, Verizon is proposing to sell it's wireline assets to Frontier and become effectively an all-wireless carrier. Frontier is going to get a patchwork of ancient switches and poorly maintained outside plant, in rural areas that would require tens of millions of dollars in upgrades for sparely populaed areas it could never turn a profit on. I seriously wonder about the viability of taking on the debt to get those areas and even just maintain them, vz itself has done a very poor job and it presently operates a network where E911 routinely fails along with pots for many, for weeks at a time. And somehow, Verizon has been allowed to skate along without being held to the fire for it's mandated utility / carrier of last resort obligations. I worry that Frontier, with all the new added debt obligations, will not able to swallow this pill. Mike- From morrowc.lists at gmail.com Fri Jul 31 14:35:37 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 31 Jul 2015 10:35:37 -0400 Subject: UDP clamped on service provider links In-Reply-To: <20150731070730.7bfafbde@localhost> References: <20150730154552.63a3ecd5@localhost> <0A4F7F83-291A-4A7C-A30B-012133686346@indigowireless.com> <20150731070730.7bfafbde@localhost> Message-ID: On Fri, Jul 31, 2015 at 8:07 AM, John Kristoff wrote: > On Thu, 30 Jul 2015 21:18:10 -0500 > Jason Baugher wrote: > >> In one case, when we were having an issue with a SIP trunk, we >> re-numbered our end to another IP in the same subnet. Same path from >> A to Z, but the packet loss mysteriously disappeared using the new >> IP. It sure seems like they are throttling somewhere. > > Not knowing how you evaluated the two paths, but if MPLS was not > considered, it may have perhaps been due in part to ECMP behavior. > While not ruling out UDP limits, it is plausible that the changed > source IP address resulted in a less congested path to be chosen. ding! this sounds like the most plausible answer... I wouldn't expect L3 to limit udp/5060/6061/SIP traffic, as a common carrier that also runs a SIP trunking service they: 1) probably know what SIP traffic is 2) don't want to get bitten being seen as preferring their own network offerings over other external ones (or perhaps accidentally impacting actual customers). From morrowc.lists at gmail.com Fri Jul 31 14:38:28 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 31 Jul 2015 10:38:28 -0400 Subject: [BULK] Verizon exiting California In-Reply-To: <55BB8711.7090607@tiedyenetworks.com> References: <900471531.5122.1438349265932.JavaMail.mhammett@ThunderFuck> <55BB8711.7090607@tiedyenetworks.com> Message-ID: On Fri, Jul 31, 2015 at 10:32 AM, Mike wrote: > > I am a CLEC operating in California west, and I collocate with verizon. Yes, > Verizon is proposing to sell it's wireline assets to Frontier and become > effectively an all-wireless carrier. clec functions don't necessarily equate to 'verizon business' work though... nor, typically, does 'wireline assets' (typically this denotes "pstn" or it's equivalent these days). it'd be very funny to see 701 sold to 209 though :) From mel at beckman.org Fri Jul 31 14:57:09 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 31 Jul 2015 14:57:09 +0000 Subject: [BULK] Verizon exiting California In-Reply-To: <55BB8711.7090607@tiedyenetworks.com> References: <900471531.5122.1438349265932.JavaMail.mhammett@ThunderFuck> <55BB8711.7090607@tiedyenetworks.com> Message-ID: <125139F4-EC44-40A5-8AF1-4F46E5F4AEB4@beckman.org> I work on E911 systems and the infrastructure that monitors E911 call distribution and integrity. California E911 is part of a nationwide management system operated out of the DC area. California?s E911 exceeds all the mandated reliability requirements. The most problematic part of E911 is cellular call handling, because of geolocation factors that make calls more complex to dispatch. and that part of the system is staying with Verizon. So your claim that E911 ?routinely fails?for weeks at a time? isn?t borne out by monitoring records, unless you have some unpublished data to share. -mel > On Jul 31, 2015, at 7:32 AM, Mike wrote: > > On 07/31/2015 06:27 AM, Mike Hammett wrote: >> Can anyone else back that up (or refute it)? >> >> > > > I am a CLEC operating in California west, and I collocate with verizon. Yes, Verizon is proposing to sell it's wireline assets to Frontier and become effectively an all-wireless carrier. > > > Frontier is going to get a patchwork of ancient switches and poorly maintained outside plant, in rural areas that would require tens of millions of dollars in upgrades for sparely populaed areas it could never turn a profit on. I seriously wonder about the viability of taking on the debt to get those areas and even just maintain them, vz itself has done a very poor job and it presently operates a network where E911 routinely fails along with pots for many, for weeks at a time. And somehow, Verizon has been allowed to skate along without being held to the fire for it's mandated utility / carrier of last resort obligations. > > I worry that Frontier, with all the new added debt obligations, will not able to swallow this pill. > > Mike- > From nanog at ics-il.net Fri Jul 31 15:00:31 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 31 Jul 2015 10:00:31 -0500 (CDT) Subject: [BULK] Verizon exiting California In-Reply-To: <55BB8711.7090607@tiedyenetworks.com> Message-ID: <712777469.5305.1438354848633.JavaMail.mhammett@ThunderFuck> Well, I meant the VZB network. The landline network transaction is confirmed by their press release. Frontier knows what they're getting into. They bought our Verizon landline operations years ago. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mike" To: nanog at nanog.org Sent: Friday, July 31, 2015 9:32:49 AM Subject: Re: [BULK] Verizon exiting California On 07/31/2015 06:27 AM, Mike Hammett wrote: > Can anyone else back that up (or refute it)? > > I am a CLEC operating in California west, and I collocate with verizon. Yes, Verizon is proposing to sell it's wireline assets to Frontier and become effectively an all-wireless carrier. Frontier is going to get a patchwork of ancient switches and poorly maintained outside plant, in rural areas that would require tens of millions of dollars in upgrades for sparely populaed areas it could never turn a profit on. I seriously wonder about the viability of taking on the debt to get those areas and even just maintain them, vz itself has done a very poor job and it presently operates a network where E911 routinely fails along with pots for many, for weeks at a time. And somehow, Verizon has been allowed to skate along without being held to the fire for it's mandated utility / carrier of last resort obligations. I worry that Frontier, with all the new added debt obligations, will not able to swallow this pill. Mike- From jlmcgraw at gmail.com Fri Jul 31 15:02:34 2015 From: jlmcgraw at gmail.com (Jesse McGraw) Date: Fri, 31 Jul 2015 11:02:34 -0400 Subject: A perl script to assist with summarizing QoS counts on Cisco Catalyst 37xx and 35xx series switches In-Reply-To: References: Message-ID: <55BB8E0A.8090304@gmail.com> https://github.com/jlmcgraw/networkUtilities/blob/master/parseMlsQosInterfaceStatistics.pl I whipped up this perl script as part of some troubleshooting I was doing and I'd thought I send it out to NANOG in case anyone else might find it useful (Note that you may need to install some additional perl libraries, see the setup.sh file in that repository for installing them). I've only tested this with Ubuntu flavors of Linux, your OS might not work out of the bag. What it does is take the output of "show mls qos interface statistics", which lists COS/DSCP/Queue counters by individual interface, from a file and summarize all of those numbers into overall totals. This will (theoretically) give you a more holistic view of the markings of traffic in/out of the switch along with which queues are dropping packets. This will hopefully assist in more intelligent allocation of queue buffers and thresholds etc. If you have any thoughts on improvements or bug fixes I'd love to hear them -Jesse Output should look something like this: 'cos:incoming ( Tag -> Packets )' => { '0' => '13378773318', '6' => 1192965355, '5' => 241414642, '7' => 93307502, '3' => 32812572, '1' => 705042, '4' => 5812 }, 'cos:outgoing ( Tag -> Packets )' => { '0' => '18309565892', '6' => 4725226136, '7' => 2016871236, '5' => 1937646890, '3' => 423068898, '2' => 41422754, '1' => 11665393, '4' => 567635 }, 'dscp:incoming ( Tag -> Packets )' => { '0' => '11778685571', '46' => 2184094729, '26' => 394305418, '40' => 131328936, '48' => 84660939, '18' => 42501678, '24' => 32812572, '12' => 8553900, '56' => 6240271, '10' => 3500510, '44' => 502413, '34' => 463741, '4' => 247044, '52' => 113496, '32' => 103896, '28' => 29765, '53' => 11408, '20' => 243, '49' => 152, '54' => 7, '2' => 6, '50' => 3 }, 'dscp:outgoing ( Tag -> Packets )' => { '0' => '16977173711', '48' => 4360459601, '46' => 1862171624, '26' => 390223766, '40' => 75123620, '18' => 41422531, '24' => 32812591, '56' => 9411197, '12' => 8258740, '10' => 3406653, '52' => 491103, '34' => 463739, '44' => 351642, '4' => 228762, '32' => 103896, '53' => 47290, '28' => 32541, '20' => 223, '49' => 152, '54' => 7, '2' => 6, '50' => 3 }, 'output queues:dropped (queue - threshold)' => { '3-3' => 23391191, '2-2' => 8571412, '2-1' => 1729737, '4-3' => 103134, '2-3' => 1948, '3-1' => 45 }, 'output queues:enqueued (queue - threshold)' => { '3-3' => '14238358295', '2-3' => 7146794945, '4-3' => 3298145116, '1-3' => 1862349561, '2-2' => 1078365695, '2-1' => 230568942, '1-1' => 75476596, '4-1' => 541520, '3-1' => 32559 } Processed 260 interfaces From bdflemin at gmail.com Fri Jul 31 15:08:19 2015 From: bdflemin at gmail.com (Brad Fleming) Date: Fri, 31 Jul 2015 10:08:19 -0500 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> <0A4F7F83-291A-4A7C-A30B-012133686346@indigowireless.com> Message-ID: > >> In one case, when we were having an issue with a SIP trunk, we re-numbered >> our end to another IP in the same subnet. Same path from A to Z, but the >> packet loss mysteriously disappeared using the new IP. > > lag hash put you on a congested fiber? Or perhaps a switch fabric module geeked out and impacted 1/3rd or 1/4th of the flows through the box? We?ve seen that exact scenario more times then I want to admit with our old equipment vendor. From jlewis at lewis.org Fri Jul 31 15:52:04 2015 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 31 Jul 2015 11:52:04 -0400 (EDT) Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> <0A4F7F83-291A-4A7C-A30B-012133686346@indigowireless.com> <20150731070730.7bfafbde@localhost> Message-ID: On Fri, 31 Jul 2015, Christopher Morrow wrote: > On Fri, Jul 31, 2015 at 8:07 AM, John Kristoff wrote: >> On Thu, 30 Jul 2015 21:18:10 -0500 >> Jason Baugher wrote: >> >>> In one case, when we were having an issue with a SIP trunk, we >>> re-numbered our end to another IP in the same subnet. Same path from >>> A to Z, but the packet loss mysteriously disappeared using the new >>> IP. It sure seems like they are throttling somewhere. >> >> Not knowing how you evaluated the two paths, but if MPLS was not >> considered, it may have perhaps been due in part to ECMP behavior. >> While not ruling out UDP limits, it is plausible that the changed >> source IP address resulted in a less congested path to be chosen. > > ding! this sounds like the most plausible answer... I wouldn't expect > L3 to limit udp/5060/6061/SIP traffic, as a common carrier that also > runs a SIP trunking service they: Jason said it was the RTP traffic that was lossy over L3...so that's not UDP/5060, but [at least commonly] UDP/10000:20000. i.e. to a network engineer trying to harden the network against DDoS attacks, just random UDP traffic. Someone writing a stateless UDP filter/policer not thinking about RTP might easily implement a filter that doesn't allow all RTP packets to pass. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From eriks at netideainc.ca Fri Jul 31 15:57:43 2015 From: eriks at netideainc.ca (Eriks Rugelis) Date: Fri, 31 Jul 2015 11:57:43 -0400 Subject: Mac compatible SFP+/XFP programmer In-Reply-To: References: Message-ID: <208B1F28-0A94-4059-9DFE-42176F2812DD@netideainc.ca> A couple of months ago I purchased a Flexbox V3 and a pile of SFP and SFP+ for $dayjob. The parts arrived in less than a week and the Flexbox V3 (and webapp) works well with our Macs. We are a satisfied customer. Eriks --- Eriks Rugelis Sr. Consultant Netidea Inc. T: +1.416.876.0740 > On Jul 30, 2015, at 14:48, Youssef Bengelloun-Zahr wrote: > > Hi, > > Flexoptics seems to do the trick but via a Web browser : > > https://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html > > From what I've heard, this thing does the Job. > > Best regards. > > > >> Le 30 juil. 2015 ? 20:28, Jason Lixfeld a ?crit : >> >> Does anyone know where I might find a SFP+/XFP programmer with a Mac compatible programmer application? >> >> Thanks! > From ted.ietf at gmail.com Fri Jul 31 17:01:04 2015 From: ted.ietf at gmail.com (Ted Hardie) Date: Fri, 31 Jul 2015 10:01:04 -0700 Subject: UDP clamped on service provider links In-Reply-To: References: <20150730154552.63a3ecd5@localhost> Message-ID: On Thu, Jul 30, 2015 at 2:31 PM, Ca By wrote: > > > On Thu, Jul 30, 2015 at 2:04 PM, Ted Hardie wrote: > >> On Thu, Jul 30, 2015 at 1:45 PM, John Kristoff wrote: >> >> > On Mon, 27 Jul 2015 19:42:46 +0530 >> > Glen Kent wrote: >> > >> > >> > > Is there a reason why this is often done so? Is this because UDP >> > > is stateless and any script kiddie could launch a DOS attack with a >> > > UDP stream? >> > >> > State, some form of sender verification and that it and most other >> > commonly used protocols besides TCP do not generally react to implicit >> > congestion signals (drops usually). >> > >> > >> ?Hmmm. The WebRTC ?stack has a pretty explicit form of getting and then >> maintaining consent; it also rides on top of UDP (SRTP/UDP for media and >> SCTP/DTLS/UDP for data channels). Because both media and data channels go >> from peer to peer, it has no preset group of server addresses to white >> list >> (the only way I can see to do that would be to force the use of TURN and >> white list the TURN server, but that would be problematic for >> performance). How will you support it if the default is to throttle UDP? >> >> Clue welcome, >> >> Ted >> > > We will install a middlebox to strip off the UDP and expose the SCTP > natively as the transport protocol ! > > Patent pending! > > ?Yeah, it's SCTP over DTLS over UDP, so stripping the UDP is going to give you: nothing. This may be WAI for some networks, of course.? > RTCweb made a series of trade offs. Encapsulating SCTP in UDP is one of > them... the idea at the time was the this is only WebRTC 1.0, so we'll do a > few silly things to ship it early. As i am sure you know :) > ?All of engineering is trade-off?s. But I'm asking about a different one here: media traffic often runs over udp when RTP/SRTP is involved and with WebRTC some datachannel traffic will as well. John's work in university environment he cited was used fixed limits for all protocols other than TCP, based on the idea that the others either had no congestion control or limited consent. Those issues shouldn't hit WebRTC which has robust consent and some congestion control (circuit breakers at the moment and more soon). How do we balance that out? regards, Ted From cscora at apnic.net Fri Jul 31 18:12:17 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Aug 2015 04:12:17 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201507311812.t6VICHIs003603@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 01 Aug, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 553519 Prefixes after maximum aggregation (per Origin AS): 209389 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 270136 Total ASes present in the Internet Routing Table: 51034 Prefixes per ASN: 10.85 Origin-only ASes present in the Internet Routing Table: 36679 Origin ASes announcing only one prefix: 16170 Transit ASes present in the Internet Routing Table: 6353 Transit-only ASes present in the Internet Routing Table: 174 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 39 Max AS path prepend of ASN ( 12486) 32 Prefixes from unregistered ASNs in the Routing Table: 1159 Unregistered ASNs in the Routing Table: 426 Number of 32-bit ASNs allocated by the RIRs: 10415 Number of 32-bit ASNs visible in the Routing Table: 8002 Prefixes from 32-bit ASNs in the Routing Table: 29602 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 410 Number of addresses announced to Internet: 2791199648 Equivalent to 166 /8s, 94 /16s and 83 /24s Percentage of available address space announced: 75.4 Percentage of allocated address space announced: 75.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.6 Total number of prefixes smaller than registry allocations: 185310 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 136680 Total APNIC prefixes after maximum aggregation: 39845 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 143686 Unique aggregates announced from the APNIC address blocks: 58429 APNIC Region origin ASes present in the Internet Routing Table: 5074 APNIC Prefixes per ASN: 28.32 APNIC Region origin ASes announcing only one prefix: 1198 APNIC Region transit ASes present in the Internet Routing Table: 884 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1571 Number of APNIC addresses announced to Internet: 751597504 Equivalent to 44 /8s, 204 /16s and 119 /24s Percentage of available APNIC address space announced: 87.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179814 Total ARIN prefixes after maximum aggregation: 87974 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182558 Unique aggregates announced from the ARIN address blocks: 85393 ARIN Region origin ASes present in the Internet Routing Table: 16588 ARIN Prefixes per ASN: 11.01 ARIN Region origin ASes announcing only one prefix: 6080 ARIN Region transit ASes present in the Internet Routing Table: 1738 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 578 Number of ARIN addresses announced to Internet: 1103165216 Equivalent to 65 /8s, 192 /16s and 247 /24s Percentage of available ARIN address space announced: 58.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 134321 Total RIPE prefixes after maximum aggregation: 66885 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 140959 Unique aggregates announced from the RIPE address blocks: 87426 RIPE Region origin ASes present in the Internet Routing Table: 17962 RIPE Prefixes per ASN: 7.85 RIPE Region origin ASes announcing only one prefix: 8070 RIPE Region transit ASes present in the Internet Routing Table: 2983 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3894 Number of RIPE addresses announced to Internet: 698726016 Equivalent to 41 /8s, 165 /16s and 182 /24s Percentage of available RIPE address space announced: 101.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 60698 Total LACNIC prefixes after maximum aggregation: 11561 LACNIC Deaggregation factor: 5.25 Prefixes being announced from the LACNIC address blocks: 71801 Unique aggregates announced from the LACNIC address blocks: 33250 LACNIC Region origin ASes present in the Internet Routing Table: 2461 LACNIC Prefixes per ASN: 29.18 LACNIC Region origin ASes announcing only one prefix: 622 LACNIC Region transit ASes present in the Internet Routing Table: 511 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1821 Number of LACNIC addresses announced to Internet: 168845888 Equivalent to 10 /8s, 16 /16s and 98 /24s Percentage of available LACNIC address space announced: 100.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12217 Total AfriNIC prefixes after maximum aggregation: 3075 AfriNIC Deaggregation factor: 3.97 Prefixes being announced from the AfriNIC address blocks: 14105 Unique aggregates announced from the AfriNIC address blocks: 5270 AfriNIC Region origin ASes present in the Internet Routing Table: 740 AfriNIC Prefixes per ASN: 19.06 AfriNIC Region origin ASes announcing only one prefix: 200 AfriNIC Region transit ASes present in the Internet Routing Table: 164 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 138 Number of AfriNIC addresses announced to Internet: 68403712 Equivalent to 4 /8s, 19 /16s and 194 /24s Percentage of available AfriNIC address space announced: 68.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2964 11298 949 Korea Telecom 17974 2702 904 80 PT Telekomunikasi Indonesia 7545 2587 339 137 TPG Telecom Limited 4755 2028 426 225 TATA Communications formerly 4538 1949 4190 71 China Education and Research 9829 1835 1367 179 National Internet Backbone 9808 1582 8717 29 Guangdong Mobile Communicatio 9583 1517 119 570 Sify Limited 4808 1483 2248 469 CNCGROUP IP network China169 9498 1363 335 105 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3180 2961 138 Cox Communications Inc. 6389 2734 3688 51 BellSouth.net Inc. 3356 2554 10710 514 Level 3 Communications, Inc. 18566 2068 381 203 MegaPath Corporation 20115 1874 1847 409 Charter Communications 6983 1751 851 245 EarthLink, Inc. 4323 1608 1022 416 tw telecom holdings, inc. 30036 1579 321 447 Mediacom Communications Corp 701 1403 11376 683 MCI Communications Services, 22561 1376 415 256 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 20940 2055 809 1487 Akamai International B.V. 34984 2047 306 375 TELLCOM ILETISIM HIZMETLERI A 6849 1209 355 21 JSC "Ukrtelecom" 8551 1101 376 52 Bezeq International-Ltd 13188 1068 97 77 TOV "Bank-Inform" 31148 1058 46 26 Freenet Ltd. 8402 971 544 15 OJSC "Vimpelcom" 12479 971 933 77 France Telecom Espana SA 6830 916 2696 469 Liberty Global Operations B.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3321 536 183 Telmex Colombia S.A. 28573 2304 2171 111 NET Servi?os de Comunica??o S 8151 1671 3256 483 Uninet S.A. de C.V. 7303 1635 1009 240 Telecom Argentina S.A. 6147 1444 374 30 Telefonica del Peru S.A.A. 6503 1266 421 55 Axtel, S.A.B. de C.V. 26615 1112 2325 35 Tim Celular S.A. 7738 995 1882 41 Telemar Norte Leste S.A. 3816 955 430 163 COLOMBIA TELECOMUNICACIONES S 11830 924 364 15 Instituto Costarricense de El Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 887 280 26 Link Egypt (Link.NET) 8452 848 1470 14 TE-AS 36903 512 258 99 Office National des Postes et 36992 442 1229 32 ETISALAT MISR 37492 314 175 71 Orange Tunisie 24835 306 146 12 Vodafone Data 3741 252 857 208 Internet Solutions 29571 247 21 13 Cote d'Ivoire Telecom 37054 189 20 7 Data Telecom Service 36947 175 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3321 536 183 Telmex Colombia S.A. 22773 3180 2961 138 Cox Communications Inc. 4766 2964 11298 949 Korea Telecom 6389 2734 3688 51 BellSouth.net Inc. 17974 2702 904 80 PT Telekomunikasi Indonesia 7545 2587 339 137 TPG Telecom Limited 3356 2554 10710 514 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2304 2171 111 NET Servi?os de Comunica??o S 18566 2068 381 203 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3180 3042 Cox Communications Inc. 6389 2734 2683 BellSouth.net Inc. 17974 2702 2622 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2587 2450 TPG Telecom Limited 28573 2304 2193 NET Servi?os de Comunica??o S 3356 2554 2040 Level 3 Communications, Inc. 4766 2964 2015 Korea Telecom 4538 1949 1878 China Education and Research 18566 2068 1865 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 47092 UNALLOCATED 8.8.204.0/24 16410 The Reynolds and Rey 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.34.0/24 31148 Freenet Ltd. 100.66.35.0/24 31148 Freenet Ltd. 100.67.26.0/24 31148 Freenet Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.56.0/22 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.54.116.0/22 23456 32bit Transition AS 27.96.88.0/22 23456 32bit Transition AS 27.100.7.0/24 56096 >>UNKNOWN<< 27.100.24.0/22 23456 32bit Transition AS 27.109.124.0/22 23456 32bit Transition AS 27.111.72.0/22 23456 32bit Transition AS 27.112.120.0/22 23456 32bit Transition AS 27.116.40.0/22 23456 32bit Transition AS Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:13 /10:36 /11:96 /12:263 /13:505 /14:1004 /15:1728 /16:12895 /17:7275 /18:12349 /19:25526 /20:36065 /21:38750 /22:60524 /23:53004 /24:300407 /25:1136 /26:1157 /27:715 /28:14 /29:14 /30:9 /31:0 /32:17 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2374 3180 Cox Communications Inc. 18566 2010 2068 MegaPath Corporation 6389 1619 2734 BellSouth.net Inc. 30036 1400 1579 Mediacom Communications Corp 6983 1397 1751 EarthLink, Inc. 34984 1351 2047 TELLCOM ILETISIM HIZMETLERI A 10620 1194 3321 Telmex Colombia S.A. 11492 1124 1208 CABLE ONE, INC. 22561 1049 1376 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1523 2:690 4:96 5:1882 6:25 8:1384 12:1811 13:14 14:1321 15:17 16:2 17:42 18:22 20:49 23:1259 24:1767 27:1976 31:1571 32:37 33:2 34:4 35:3 36:158 37:2014 38:1038 39:14 40:69 41:2754 42:297 43:1379 44:30 45:891 46:2323 47:51 49:928 50:784 52:12 54:86 55:5 56:6 57:43 58:1352 59:713 60:479 61:1759 62:1380 63:1905 64:4432 65:2260 66:4028 67:2079 68:1062 69:3238 70:1027 71:450 72:1965 74:2598 75:356 76:387 77:1286 78:1167 79:812 80:1363 81:1319 82:854 83:720 84:795 85:1361 86:445 87:1044 88:537 89:1936 90:147 91:5997 92:849 93:2278 94:2033 95:2193 96:423 97:348 98:1021 99:55 100:78 101:847 103:7906 104:2019 105:62 106:340 107:1042 108:626 109:2108 110:1150 111:1450 112:819 113:1105 114:839 115:1265 116:1461 117:1068 118:1804 119:1460 120:451 121:1140 122:2161 123:1842 124:1519 125:1611 128:634 129:399 130:416 131:1225 132:518 133:171 134:406 135:97 136:333 137:327 138:1058 139:150 140:238 141:502 142:663 143:512 144:548 145:125 146:796 147:580 148:1230 149:419 150:567 151:643 152:524 153:254 154:477 155:885 156:425 157:420 158:356 159:1022 160:409 161:665 162:1999 163:441 164:696 165:703 166:299 167:843 168:1242 169:187 170:1473 171:253 172:272 173:1533 174:721 175:696 176:1428 177:3834 178:2172 179:947 180:1935 181:1630 182:1802 183:628 184:758 185:3980 186:2890 187:1772 188:2080 189:1609 190:7705 191:1107 192:8531 193:5652 194:4223 195:3642 196:1999 197:1034 198:5551 199:5508 200:6670 201:3295 202:9503 203:9161 204:4691 205:2838 206:3020 207:2990 208:3983 209:3925 210:3566 211:1919 212:2541 213:2252 214:844 215:71 216:5743 217:1843 218:732 219:468 220:1480 221:816 222:471 223:811 End of report From randy at psg.com Fri Jul 31 19:48:11 2015 From: randy at psg.com (Randy Bush) Date: Sat, 01 Aug 2015 04:48:11 +0900 Subject: Working with Spamhaus In-Reply-To: References: <55BA27C9.2050907@snovc.com> Message-ID: > As for SORBS, I'm not aware of anyone that uses it these days many folk do randy From Valdis.Kletnieks at vt.edu Fri Jul 31 19:54:58 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 31 Jul 2015 15:54:58 -0400 Subject: Working with Spamhaus In-Reply-To: Your message of "Sat, 01 Aug 2015 04:48:11 +0900." References: <55BA27C9.2050907@snovc.com> Message-ID: <25854.1438372498@turing-police.cc.vt.edu> On Sat, 01 Aug 2015 04:48:11 +0900, Randy Bush said: > > As for SORBS, I'm not aware of anyone that uses it these days > > many folk do Many of them your competitors? :) (Sorry, couldn't resist :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jarenangerbauer at gmail.com Fri Jul 31 21:28:34 2015 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Fri, 31 Jul 2015 15:28:34 -0600 Subject: Working with Spamhaus In-Reply-To: References: <55BA27C9.2050907@snovc.com> Message-ID: Hi, As for SORBS, I'm not aware of anyone that uses it these days because of > the extortion thing and the rather ..ahem .. "eccentric" nature of it's > owner. > and > I see you've never had the pleasure of dealing with SORBS. All it takes is > *ONE* message - EVER - to be instantly, and forever, listed in their > spamtraps list. Getting on the list is automatic and immediate. There are > no thresholds or limits; and there's expiration. The only way off that > list is to PAY them to remove you. (which makes it illegal in most places. > The corporate sharks flipped when I pointed them to that "policy".) I work for Proofpoint -- we acquired SORBS back in 2011. There is obviously some incorrect / very outdated information / viewpoints here, so I thought it would make sense to clear the air a bit: Listings can happen a number of different ways, however the vast majority of these can be resolved, either through automatic delisting, or manual delisting (via SORBS support ticket). Additionally, there is NO CHARGE to be delisted. I'm happy to help mitigate any issues -- feel free to hit me up off list -- jangerbauer at proofpoint.com Thanks --Jaren From cidr-report at potaroo.net Fri Jul 31 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 Jul 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201507312200.t6VM00dp072445@wattle.apnic.net> This report has been generated at Fri Jul 31 21:14:46 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-07-15 561972 308324 25-07-15 561940 308367 26-07-15 561948 308309 27-07-15 561810 308356 28-07-15 562237 308578 29-07-15 562339 308849 30-07-15 561310 308826 31-07-15 561435 308694 AS Summary 51298 Number of ASes in routing system 20373 Number of ASes announcing only one prefix 3322 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120757504 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 31Jul15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 561857 308639 253218 45.1% All ASes AS22773 3182 168 3014 94.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2702 80 2622 97.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 35 2438 98.6% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2300 118 2182 94.9% NET Servi?os de Comunica??o S.A.,BR AS6389 2734 709 2025 74.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS9394 2269 315 1954 86.1% CTTNET China TieTong Telecommunications Corporation,CN AS3356 2558 782 1776 69.4% LEVEL3 - Level 3 Communications, Inc.,US AS7545 2698 1004 1694 62.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS10620 3322 1673 1649 49.6% Telmex Colombia S.A.,CO AS4766 2964 1423 1541 52.0% KIXS-AS-KR Korea Telecom,KR AS9808 1582 63 1519 96.0% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1750 248 1502 85.8% ITCDELTA - Earthlink, Inc.,US AS20115 1872 423 1449 77.4% CHARTER-NET-HKY-NC - Charter Communications,US AS4755 2027 708 1319 65.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS9498 1363 119 1244 91.3% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1614 418 1196 74.1% TWTC - tw telecom holdings, inc.,US AS18566 2069 898 1171 56.6% MEGAPATH5-US - MegaPath Corporation,US AS6147 1445 278 1167 80.8% Telefonica del Peru S.A.A.,PE AS7303 1636 529 1107 67.7% Telecom Argentina S.A.,AR AS22561 1375 310 1065 77.5% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS4808 1537 509 1028 66.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS7552 1143 152 991 86.7% VIETEL-AS-AP Viettel Corporation,VN AS26615 1112 132 980 88.1% Tim Celular S.A.,BR AS8402 965 21 944 97.8% CORBINA-AS OJSC "Vimpelcom",RU AS8151 1673 734 939 56.1% Uninet S.A. de C.V.,MX AS7738 995 75 920 92.5% Telemar Norte Leste S.A.,BR AS38285 977 130 847 86.7% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS6849 1206 414 792 65.7% UKRTELNET JSC UKRTELECOM,UA AS24560 1247 459 788 63.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS55430 853 66 787 92.3% STARHUBINTERNET-AS-NGNBN Starhub Internet Pte Ltd,SG Total 55643 12993 42650 76.6% Top 30 total Possible Bogus Routes 14.1.96.0/19 AS20421 LLC-ASPECT-AS LLC Aspect,RU 14.102.176.0/20 AS20421 LLC-ASPECT-AS LLC Aspect,RU 14.192.56.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.54.116.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 27.96.88.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 27.100.7.0/24 AS56096 27.100.24.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 27.109.124.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 27.111.72.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 27.112.120.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 27.116.40.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 27.122.60.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.17.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.126.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 43.246.112.0/20 AS20421 LLC-ASPECT-AS LLC Aspect,RU 59.152.16.0/20 AS20421 LLC-ASPECT-AS LLC Aspect,RU 59.152.64.0/20 AS20421 LLC-ASPECT-AS LLC Aspect,RU 61.14.224.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 64.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.57.192.0/22 AS33321 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.228.160.0/20 AS7233 YAHOO-US - Yahoo,US 66.228.176.0/21 AS17110 YAHOO-US2 - Yahoo,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 69.24.96.0/20 AS26804 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 91.238.83.0/24 AS58060 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 100.64.8.0/24 AS10620 Telmex Colombia S.A.,CO 100.66.34.0/24 AS31148 FREENET-AS Freenet Ltd.,UA 100.66.35.0/24 AS31148 FREENET-AS Freenet Ltd.,UA 100.67.26.0/24 AS31148 FREENET-AS Freenet Ltd.,UA 103.1.220.0/22 AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU 103.5.79.0/24 AS20422 LLC-TEHNOKOM-AS LLC Tehnokom,RU 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.25.144.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.37.188.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.228.8.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.229.152.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.230.124.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.104.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.253.164.0/23 AS13317 106.0.32.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 116.12.32.0/21 AS38555 116.12.32.0/24 AS38555 116.199.200.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.201.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.202.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.203.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.204.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.205.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.206.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.207.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 118.103.160.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 119.42.32.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 170.95.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 177.38.216.0/21 AS26241 -Reserved AS-,ZZ 177.223.96.0/20 AS52726 -Reserved AS-,ZZ 177.223.96.0/21 AS52726 -Reserved AS-,ZZ 177.223.104.0/21 AS52726 -Reserved AS-,ZZ 177.223.105.0/24 AS52726 -Reserved AS-,ZZ 177.223.106.0/24 AS52726 -Reserved AS-,ZZ 177.223.107.0/24 AS52726 -Reserved AS-,ZZ 177.223.108.0/24 AS52726 -Reserved AS-,ZZ 179.60.128.0/20 AS26317 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.52.57.0/24 AS48039 KGT-AS KGT new media,DE 185.52.58.0/24 AS48039 KGT-AS KGT new media,DE 185.111.184.0/24 AS13287 NIXVAL SERVICLEOP SL,ES 185.111.185.0/24 AS13287 NIXVAL SERVICLEOP SL,ES 185.111.186.0/24 AS13287 NIXVAL SERVICLEOP SL,ES 185.111.187.0/24 AS13287 NIXVAL SERVICLEOP SL,ES 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 189.14.112.0/20 AS52720 WEBFOCO TELECOMUNICACOES LTDA,BR 189.14.116.0/22 AS28282 -Reserved AS-,ZZ 189.14.120.0/22 AS28282 -Reserved AS-,ZZ 189.14.124.0/22 AS28282 -Reserved AS-,ZZ 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 192.234.204.0/24 AS14007 SOHOSKYWAY1 - Skyway West,CA 192.236.0.0/24 AS39323 IMONC - ImOn Communications, LLC,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.9.9.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd.,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.103.89.0/24 AS19523 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.59.208.0/20 AS26317 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 201.222.32.0/20 AS20421 LLC-ASPECT-AS LLC Aspect,RU 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.133.208.0/20 AS17440 IDNIC-ID Indonesia Network Information Center,ID 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.160.128.0/19 AS20043 STADIS-LLC-AS LLC Stadis,RU 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.191.160.0/20 AS20421 LLC-ASPECT-AS LLC Aspect,RU 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 31 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 Jul 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201507312200.t6VM013m072468@wattle.apnic.net> BGP Update Report Interval: 23-Jul-15 -to- 30-Jul-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 271611 6.5% 247.4 -- BSNL-NIB National Internet Backbone,IN 2 - AS38197 132507 3.2% 152.3 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 3 - AS22059 129201 3.1% 64600.5 -- -Reserved AS-,ZZ 4 - AS21669 122440 2.9% 122440.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 5 - AS11056 119630 2.9% 119630.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US 6 - AS36947 86349 2.1% 1136.2 -- ALGTEL-AS,DZ 7 - AS54169 81118 1.9% 40559.0 -- MGH-ION-1 - Marin General Hospital,US 8 - AS3709 57313 1.4% 2122.7 -- NET-CITY-SA - City of San Antonio,US 9 - AS24138 52884 1.3% 290.6 -- CRNET_BJ_IDC-CNNIC-AP China Tietong Telecommunication Corporation,CN 10 - AS9583 33748 0.8% 27.5 -- SIFY-AS-IN Sify Limited,IN 11 - AS30295 33202 0.8% 8300.5 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 12 - AS25563 32547 0.8% 10849.0 -- WEBLAND-AS Webland AG,CH 13 - AS24560 31454 0.8% 27.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN 14 - AS8402 27995 0.7% 126.7 -- CORBINA-AS OJSC "Vimpelcom",RU 15 - AS39891 27254 0.7% 22.9 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 16 - AS131090 27046 0.7% 71.6 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 17 - AS59943 26971 0.6% 26971.0 -- RADAR-AS Radar LLC,RU 18 - AS10620 22902 0.6% 9.3 -- Telmex Colombia S.A.,CO 19 - AS45899 21513 0.5% 74.2 -- VNPT-AS-VN VNPT Corp,VN 20 - AS46687 21177 0.5% 605.1 -- AS46687 - BCI Mississippi Broadband,LLC,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS21669 122440 2.9% 122440.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - AS11056 119630 2.9% 119630.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US 3 - AS22059 129201 3.1% 64600.5 -- -Reserved AS-,ZZ 4 - AS54169 81118 1.9% 40559.0 -- MGH-ION-1 - Marin General Hospital,US 5 - AS59943 26971 0.6% 26971.0 -- RADAR-AS Radar LLC,RU 6 - AS262741 13871 0.3% 13871.0 -- CONECTSUL - COMERCIO E SERVICOS LTDA,BR 7 - AS40637 11867 0.3% 11867.0 -- MAILROUTE - MailRoute, Inc.,US 8 - AS40493 11354 0.3% 11354.0 -- FACILITYSOURCEINC - FacilitySource,US 9 - AS25563 32547 0.8% 10849.0 -- WEBLAND-AS Webland AG,CH 10 - AS393588 9534 0.2% 9534.0 -- MUBEA-FLO - Mubea,US 11 - AS30295 33202 0.8% 8300.5 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 12 - AS37590 5015 0.1% 5015.0 -- BCA-ASN,AO 13 - AS33731 4659 0.1% 4659.0 -- -Reserved AS-,ZZ 14 - AS197914 4261 0.1% 4261.0 -- STOCKHO-AS Stockho Hosting SARL,FR 15 - AS38000 6166 0.1% 3083.0 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 16 - AS31357 9035 0.2% 3011.7 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 17 - AS56636 2684 0.1% 2684.0 -- ASVEDARU VEDA Ltd.,RU 18 - AS6316 10264 0.2% 2566.0 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 19 - AS35093 4395 0.1% 2197.5 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 20 - AS3709 57313 1.4% 2122.7 -- NET-CITY-SA - City of San Antonio,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.212.8.0/24 122440 2.8% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - 50.202.59.0/24 119630 2.8% AS11056 -- BERGERMONTAGUE - Berger & Montague, P.C,US 3 - 105.96.0.0/22 85008 1.9% AS36947 -- ALGTEL-AS,DZ 4 - 204.80.242.0/24 81115 1.9% AS54169 -- MGH-ION-1 - Marin General Hospital,US 5 - 64.34.125.0/24 67377 1.6% AS22059 -- -Reserved AS-,ZZ 6 - 76.191.107.0/24 61824 1.4% AS22059 -- -Reserved AS-,ZZ 7 - 185.65.148.0/24 26971 0.6% AS59943 -- RADAR-AS Radar LLC,RU 8 - 61.7.155.0/24 25772 0.6% AS131090 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 9 - 186.208.186.0/24 13871 0.3% AS262741 -- CONECTSUL - COMERCIO E SERVICOS LTDA,BR 10 - 199.89.0.0/21 11867 0.3% AS40637 -- MAILROUTE - MailRoute, Inc.,US 11 - 199.60.236.0/24 11717 0.3% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 12 - 8.17.26.0/24 11354 0.3% AS40493 -- FACILITYSOURCEINC - FacilitySource,US 13 - 199.60.234.0/23 11255 0.3% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 14 - 92.43.216.0/21 11050 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 15 - 185.84.192.0/22 10864 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 16 - 178.174.96.0/19 10633 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 17 - 66.19.194.0/24 10246 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 18 - 199.60.233.0/24 10223 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 19 - 192.58.137.0/24 9534 0.2% AS393588 -- MUBEA-FLO - Mubea,US 20 - 78.140.0.0/18 9031 0.2% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From dgolding at gmail.com Fri Jul 31 22:42:44 2015 From: dgolding at gmail.com (Daniel Golding) Date: Fri, 31 Jul 2015 22:42:44 +0000 Subject: [NANOG-announce] 2015 NANOG Elections General Information Message-ID: Hello NANOG members! We are once again approaching the annual NANOG election and appointment time. In addition to the "call for nominations" message at the opening of the process, the following is an overview and timeline of the actual election process. We encourage those in the community who are not currently NANOG members to consider becoming members of NANOG and to consider standing for a position in our leadership. Through membership and voting, you will be an active participant in directing all NANOG activities. Only NANOG members are eligible to vote and serve in the 2015 election process. *Click here* to become a member today! *At the December 15, 2014, NANOG Board meeting, the Board of Directors voted to extend the term of all current Communications and Program Committee members through February 2016. In early January 2015, all members of the committees agreed to the extension. Therefore, in this 2015 annual election process, there will be no committee member vacancies. * ? Monday, August 3, 2015 the Call for Board Candidate Nominations begin ? Bylaws discussed, proposed changes explored August 10, 2015 ? Board nominations close on September 14, 2015 ? Bylaws amendments posted September 21, 2015 ? *Voting for the 2015 NANOG Board Candidate Elections will begin on Monday, October 5, 2015 at 8am ET and close on Wednesday, October 7, 2015 at 12pm ET.* Only NANOG members in good standing are allowed to vote. ? ***If you are not a member and wish to vote in this election, your membership must be received by 12:00 p.m. Eastern Time on Friday October 2, 2015.*** ? Call for Committee Member Nominations will be on January 1, 2016 ? Committee nominations will close on February 1, 2016 *Why?* If you care about NANOG and think that you would like to take a turn at volunteering your time to help make it better please consider joining as a member and running for a position. If you know someone else that you believe would be interested, nominate them by completing the *Online Process**.* Any questions should be submitted to *elections at nanog.org.* As NANOG continues to evolve, our Board of Directors and Committees will continue to play an increasingly important role in our success. By joining now, you can be an integral part of the process. For more information about the role of a Board of Director or any Committee Member, or to find out more about what's involved in serving, please consult the current NANOG Bylaws or review the information found at https://www.nanog.org/elections/2015/general. If you have any questions, please do not hesitate to contact me. Best regards, *Daniel Golding, ChairFor the NANOG Board of Directors* -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jfbeam at gmail.com Fri Jul 31 23:56:38 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 31 Jul 2015 19:56:38 -0400 Subject: Working with Spamhaus In-Reply-To: References: <55BA27C9.2050907@snovc.com> Message-ID: On Fri, 31 Jul 2015 17:28:34 -0400, Jaren Angerbauer wrote: > I work for Proofpoint -- we acquired SORBS back in 2011. Hint: The Internet has a LONG memory. The liberal and numerous dropping of "for free" makes me laugh. "You" knew the tainted nature of what you were buying. Nobody, to this day, places much trust at all in SORBS. I dare say there isn't anyone on NANOG (certainly any "long hairs") that haven't had at least one interaction with SORBS, most likely due to spamtraps; that number drops to almost zero when you put the word "good" in that sentence. Maybe it's better now under new management; we (the royal we) moved on long ago.