From mark.tinka at seacom.mu Sun Jun 1 09:30:29 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 1 Jun 2014 11:30:29 +0200 Subject: Off Topic Friday In-Reply-To: <5388F3A0.70000@pubnix.net> References: <5388F3A0.70000@pubnix.net> Message-ID: <201406011130.30173.mark.tinka@seacom.mu> On Friday, May 30, 2014 11:09:52 PM Alain Hebert wrote: > If anyone has suggestion for cheap hardware to > simulate a implementation of all the RFC's from the Core > to the CPE. Cisco CSR1000v. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From raaki.88 at gmail.com Sun Jun 1 20:38:01 2014 From: raaki.88 at gmail.com (Rakesh M) Date: Mon, 2 Jun 2014 02:08:01 +0530 Subject: Off Topic Friday In-Reply-To: <201406011130.30173.mark.tinka@seacom.mu> References: <5388F3A0.70000@pubnix.net> <201406011130.30173.mark.tinka@seacom.mu> Message-ID: if you want support for standards and RFC , emulating Major players sounds good. Just like IOS-XRV if you are looking for latest SP emulation, this depends on how much traffic / testing you are looking at. Do you want to integrate it with one of your own routers for routes similar to looking glass or connect it with Traffic Gens ? most of them possible with Standard server PC's with vmware ESX or similar open source VirtualBox products. vyatta may be another option as such. - Rakesh Jncie-sp #02079 On Sun, Jun 1, 2014 at 3:00 PM, Mark Tinka wrote: > On Friday, May 30, 2014 11:09:52 PM Alain Hebert wrote: > > > If anyone has suggestion for cheap hardware to > > simulate a implementation of all the RFC's from the Core > > to the CPE. > > Cisco CSR1000v. > > Mark. > From cgrundemann at gmail.com Sun Jun 1 21:25:04 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 1 Jun 2014 15:25:04 -0600 Subject: New BCOPs in Progress Message-ID: Hail NANOGers! As most of you hopefully know, NANOG now has a BCOP Ad Hoc Committee and we are pushing forward with new BCOPs! http://nanog.org/governance/bcop We currently have three BCOPs in active development: eBGP configuration, shepherd Bill Armstrong Public Peering Exchange update, shepherd Shawn Hsiao Ethernet OAM, shepherd Mark Calkins All three of these nascent BCOPs will be presented in the BCOP Track on Monday: http://nanog.org/meetings/abstract?id=2348 We have also collected a list of Appeals (BCOPs that need to be written): http://bcop.nanog.org/index.php/Appeals If you would like to help out with any of these BCOPs (or others yet to be identified) please join the BCOP mailing list and reach out to the shepherd (if applicable of course): http://mailman.nanog.org/mailman/listinfo/bcop Our committee is brand new and we are still finding and smoothing wrinkles, etc. We would love your help in any capacity. As a BCOP shepherd or SME or just to point out potential pit falls or room for improvement, with the process, the wiki, a BCOP or anything at all really. This is a bottom-up, community led effort and it will only succeed with your help - join us in creating what I believe will be a vital and long-lasting institution! Cheers, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From John_Brzozowski at Cable.Comcast.com Sun Jun 1 22:49:08 2014 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Sun, 1 Jun 2014 22:49:08 +0000 Subject: Hulu contact? Message-ID: If there is anyone from Hulu on the NANOG list can you please contact me unicast? Thanks, John ========================================= John Jason Brzozowski Comcast Cable m) 609-377-6594 o) 484-962-0060 w) www.comcast6.net e) john_brzozowski at cable.comcast.com ========================================= From mark.tinka at seacom.mu Mon Jun 2 06:05:29 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Jun 2014 08:05:29 +0200 Subject: Off Topic Friday In-Reply-To: References: <5388F3A0.70000@pubnix.net> <201406011130.30173.mark.tinka@seacom.mu> Message-ID: <201406020805.29269.mark.tinka@seacom.mu> On Sunday, June 01, 2014 10:38:01 PM Rakesh M wrote: > if you want support for standards and RFC , emulating > Major players sounds good. Just like IOS-XRV if you are > looking for latest SP emulation, this depends on how > much traffic / testing you are looking at. With CSR1000v (and IOS XRv), if all you want is to test features, I think you get up to 2.5Mbps worth of throughput free (I know this about CSR1000v, not sure about IOS XRv). If you want more, you then start to pay. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From plucena at coopergeneral.com Mon Jun 2 11:46:43 2014 From: plucena at coopergeneral.com (Pablo Lucena) Date: Mon, 2 Jun 2014 07:46:43 -0400 Subject: Off Topic Friday In-Reply-To: <201406020805.29269.mark.tinka@seacom.mu> References: <5388F3A0.70000@pubnix.net> <201406011130.30173.mark.tinka@seacom.mu> <201406020805.29269.mark.tinka@seacom.mu> Message-ID: You get a 60 day trial with unlimited bandwidth and full features. After the 60 days are up, your throughput goes down to 2.5 mbps. I recommend running the latest version, IOS-XE 3.12. *Pablo Lucena* On Mon, Jun 2, 2014 at 2:05 AM, Mark Tinka wrote: > On Sunday, June 01, 2014 10:38:01 PM Rakesh M wrote: > > > if you want support for standards and RFC , emulating > > Major players sounds good. Just like IOS-XRV if you are > > looking for latest SP emulation, this depends on how > > much traffic / testing you are looking at. > > With CSR1000v (and IOS XRv), if all you want is to test > features, I think you get up to 2.5Mbps worth of throughput > free (I know this about CSR1000v, not sure about IOS XRv). > > If you want more, you then start to pay. > > Mark. > From randy at psg.com Mon Jun 2 12:10:04 2014 From: randy at psg.com (Randy Bush) Date: Mon, 02 Jun 2014 05:10:04 -0700 Subject: ipmi access Message-ID: so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% of the time i want it blocked off. but that other 1%, i want kvm console, remote media, and dim sum. currently, i just block the ip address chunk into which i put ipmi at the border of the rack. when i want access, i reconfig the acl. bit of a pita. anyone care to share better idea(s)? thanks. randy From lathama at gmail.com Mon Jun 2 12:19:07 2014 From: lathama at gmail.com (Andrew Latham) Date: Mon, 2 Jun 2014 07:19:07 -0500 Subject: ipmi access In-Reply-To: References: Message-ID: I use OpenVPN to access an Admin/sandboxed network with insecure portals, wiki, and ipmi. On Jun 2, 2014 7:13 AM, "Randy Bush" wrote: > so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% > of the time i want it blocked off. but that other 1%, i want kvm > console, remote media, and dim sum. > > currently, i just block the ip address chunk into which i put ipmi at > the border of the rack. when i want access, i reconfig the acl. bit of > a pita. > > anyone care to share better idea(s)? thanks. > > randy > From contact at winterei.se Mon Jun 2 12:23:36 2014 From: contact at winterei.se (Paul S.) Date: Mon, 02 Jun 2014 21:23:36 +0900 Subject: ipmi access In-Reply-To: References: Message-ID: <538C6CC8.1060408@winterei.se> On 6/2/2014 午後 09:19, Andrew Latham wrote: > I use OpenVPN to access an Admin/sandboxed network with insecure portals, > wiki, and ipmi. > On Jun 2, 2014 7:13 AM, "Randy Bush" wrote: > >> so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% >> of the time i want it blocked off. but that other 1%, i want kvm >> console, remote media, and dim sum. >> >> currently, i just block the ip address chunk into which i put ipmi at >> the border of the rack. when i want access, i reconfig the acl. bit of >> a pita. >> >> anyone care to share better idea(s)? thanks. >> >> randy >> Depends. On most ATEN chip based BMC boards from Supermicro, it includes a UI to iptables that works in the same way. You could put it on a public net, allow your stuff and DROP 0.0.0.0/0. But unless you have servers with those, I think the best way to go is putting them on internal IPs and then using some sort of a VPN. From jeroen at massar.ch Mon Jun 2 12:24:21 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 02 Jun 2014 14:24:21 +0200 Subject: ipmi access In-Reply-To: References: Message-ID: <538C6CF5.1000205@massar.ch> On 2014-06-02 14:10, Randy Bush wrote: > so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% > of the time i want it blocked off. but that other 1%, i want kvm > console, remote media, and dim sum. > > currently, i just block the ip address chunk into which i put ipmi at > the border of the rack. when i want access, i reconfig the acl. bit of > a pita. Depends on how many boxes you have at the same location. If you only have one, that is likely the way to go, if you have a few more, use one or multiple (backup :) VMs on the boxes as management access, properly ACL that away, put OpenVPN on it, route the IPMI network on that presto. Of course, the IPMI boxes should always live in their own VLAN where possible, and those VLAN addresses should never be routed publicly or NATted to anything public. With the OpenVPN trick or whatever your VPN tool of choice is, you don't have to NAT mind you. Do note that if you have multiple mgmt/access boxes you should have a floating gateway IP and/or bridge that network onto your VPN. Bridging is typically easier also as it avoids having to configure a default gateway which again avoids all kinds of accidental typos. Do note that the above does not allow you access if the datacenter's switching or routing is borked too heavily, hence a GSM/4G backup USB stick in the management box to allow 'dial in'[*] can be useful too ;) That is of course if there is signal in the datacenter... Greets, Jeroen [*] Cheap variant: get a 4G USB stick with a pre-paid number, set it up so that you can SMS to it, and that based on the SMS (src-number verify etc) it connects to the network and contacts a remote OpenVPN, configures that VPN and voila, you are in. [*] If you don't want extra services like OpenVPN, keep in mind that ACLs keeps baddies out and that one can alternatively do tunneling in a similar method with sshd (and key restrictions to not allow them anything else ;) From randy at psg.com Mon Jun 2 12:26:17 2014 From: randy at psg.com (Randy Bush) Date: Mon, 02 Jun 2014 05:26:17 -0700 Subject: ipmi access In-Reply-To: References: Message-ID: > I use OpenVPN to access an Admin/sandboxed network with insecure portals, > wiki, and ipmi. hmmmm. 'cept when it is the openvpn server's ipmi. but good hack. i may use it, as i already do openvpn. thanks. randy From lathama at gmail.com Mon Jun 2 12:30:42 2014 From: lathama at gmail.com (Andrew Latham) Date: Mon, 2 Jun 2014 07:30:42 -0500 Subject: ipmi access In-Reply-To: References: Message-ID: In addition I will suggest multiple paths (oobm) to the network. IE VPN via second provider network. On Jun 2, 2014 7:26 AM, "Randy Bush" wrote: > > I use OpenVPN to access an Admin/sandboxed network with insecure portals, > > wiki, and ipmi. > > hmmmm. 'cept when it is the openvpn server's ipmi. but good hack. i > may use it, as i already do openvpn. thanks. > > randy > From jeroen at massar.ch Mon Jun 2 12:33:05 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 02 Jun 2014 14:33:05 +0200 Subject: ipmi access In-Reply-To: <538C6CC8.1060408@winterei.se> References: <538C6CC8.1060408@winterei.se> Message-ID: <538C6F01.4070709@massar.ch> On 2014-06-02 14:23, Paul S. wrote: [..] > On most ATEN chip based BMC boards from Supermicro, it includes a UI to > iptables that works in the same way. > > You could put it on a public net, allow your stuff and DROP 0.0.0.0/0. > > But unless you have servers with those, I think the best way to go is > putting them on internal IPs and then using some sort of a VPN. While you are typing the iptables command, do a check of the software versions, typically they are running a decade old kernel and a lot of unpatched software that is exposed. You really do not want to run that on the Interwebs, just the idea of any packet arriving to such a kernel is scary. Relevant good reads: http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn https://plus.google.com/+TobiasDiedrich/posts/Bq44KkBT3vK The first URL references 2.6.17, yes... *2.6.17* is the CURRENT version of the kernel running on most IPMIs out there. http://kernelnewbies.org/Linux_2_6_17 - Released 17 June, 2006 8 years... ouch, yeah, no way that is going to be attached to a public network... Thus please, don't shoot yourself in the foot with that and more importantly don't shoot the rest of the Internet in the foot as they'll receive the packets. Note: the IPMI that Michael describes is on a unrouted VLAN, the access to the OpenVPN port that he runs on the IPMI happens through SSH on a jumpbox which is ACLd away. Greets, Jeroen (who is still awaiting for Zeus4IPMI) From coy.hile at coyhile.com Mon Jun 2 12:35:31 2014 From: coy.hile at coyhile.com (coy.hile at coyhile.com) Date: Mon, 2 Jun 2014 08:35:31 -0400 Subject: ipmi access In-Reply-To: References: Message-ID: <19996587-178B-406D-BFC7-827F7F6A5F20@coyhile.com> Multiple points of entry into the VPN mesh? When you need to muck with concentratorA's ipmi, use b, c, or d. Sent from my iPhone On Jun 2, 2014, at 8:26, Randy Bush wrote: >> I use OpenVPN to access an Admin/sandboxed network with insecure portals, >> wiki, and ipmi. > > hmmmm. 'cept when it is the openvpn server's ipmi. but good hack. i > may use it, as i already do openvpn. thanks. > > randy From contact at winterei.se Mon Jun 2 12:39:14 2014 From: contact at winterei.se (Paul S.) Date: Mon, 02 Jun 2014 21:39:14 +0900 Subject: ipmi access In-Reply-To: <538C6F01.4070709@massar.ch> References: <538C6CC8.1060408@winterei.se> <538C6F01.4070709@massar.ch> Message-ID: <538C7072.20703@winterei.se> True, excellent point as well. Multiple openvpn/ipsec entry points on a internal network is probably the best way to go. On 6/2/2014 午後 09:33, Jeroen Massar wrote: > On 2014-06-02 14:23, Paul S. wrote: > [..] >> On most ATEN chip based BMC boards from Supermicro, it includes a UI to >> iptables that works in the same way. >> >> You could put it on a public net, allow your stuff and DROP 0.0.0.0/0. >> >> But unless you have servers with those, I think the best way to go is >> putting them on internal IPs and then using some sort of a VPN. > While you are typing the iptables command, do a check of the software > versions, typically they are running a decade old kernel and a lot of > unpatched software that is exposed. You really do not want to run that > on the Interwebs, just the idea of any packet arriving to such a kernel > is scary. > > > Relevant good reads: > http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn > https://plus.google.com/+TobiasDiedrich/posts/Bq44KkBT3vK > > The first URL references 2.6.17, yes... *2.6.17* is the CURRENT version > of the kernel running on most IPMIs out there. > > http://kernelnewbies.org/Linux_2_6_17 - Released 17 June, 2006 > > 8 years... ouch, yeah, no way that is going to be attached to a public > network... > > Thus please, don't shoot yourself in the foot with that and more > importantly don't shoot the rest of the Internet in the foot as they'll > receive the packets. > > > Note: the IPMI that Michael describes is on a unrouted VLAN, the access > to the OpenVPN port that he runs on the IPMI happens through SSH on a > jumpbox which is ACLd away. > > Greets, > Jeroen > > (who is still awaiting for Zeus4IPMI) > From ag4ve.us at gmail.com Mon Jun 2 13:21:46 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 2 Jun 2014 09:21:46 -0400 Subject: ipmi access In-Reply-To: References: Message-ID: On Mon, Jun 2, 2014 at 8:26 AM, Randy Bush wrote: >> I use OpenVPN to access an Admin/sandboxed network with insecure portals, >> wiki, and ipmi. > > hmmmm. 'cept when it is the openvpn server's ipmi. but good hack. i > may use it, as i already do openvpn. thanks. > So, kinda the same idea - just put IPMI on another network and use ssh forwards to it. You can have multiple boxes connected in this fashion but the point is to keep it simple and as secure as possible (and IPMI security doesn't really count here :) ). Kinda funny though - I've all of the findings have been for newer IPMI. So, I had (have) an HP DL380g5 and didn't feel like resetting the iLo2 password manually. Well, everything I could find for dumping info from iLo was for iLo3... go figure. (I still wouldn't put it on the net) From cma at cmadams.net Mon Jun 2 13:28:33 2014 From: cma at cmadams.net (Chris Adams) Date: Mon, 2 Jun 2014 08:28:33 -0500 Subject: ipmi access In-Reply-To: References: Message-ID: <20140602132833.GA24011@cmadams.net> Once upon a time, shawn wilson said: > So, kinda the same idea - just put IPMI on another network and use ssh > forwards to it. You can have multiple boxes connected in this fashion > but the point is to keep it simple and as secure as possible (and IPMI > security doesn't really count here :) ). For basic IPMI, SSH forwards will work, but some of the web/Java based KVM-over-IP on IPMI BMCs tend to not work well with that. For IPMI things like power control and serial-over-LAN, I put the IPMI on a separate VLAN (most semi-recent BMCs can handle a VLAN tag) and then just use "ipmitool" on a Linux system connected to the same VLAN (no port-forwarding or VPN required). I only use a VPN-type setup when I need to use a KVM console. -- Chris Adams From alter3d at alter3d.ca Mon Jun 2 14:13:40 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Mon, 02 Jun 2014 10:13:40 -0400 Subject: ipmi access In-Reply-To: References: Message-ID: <538C8694.5030204@alter3d.ca> On 06/02/2014 08:26 AM, Randy Bush wrote: >> I use OpenVPN to access an Admin/sandboxed network with insecure portals, >> wiki, and ipmi. > hmmmm. 'cept when it is the openvpn server's ipmi. but good hack. i > may use it, as i already do openvpn. thanks. > > randy What you can also do if you want to remove the dependence on the OpenVPN server (e.g. smaller networks where the overhead would be high, or to mitigate failures of the OpenVPN server) is to use your existing pattern of whitelisting IPs using ACLs, but instead of modifying the rules all the time, just run a small external server with a static IP, and allow that IP access through all of your ACLs. Amazon EC2 instances are great for this. Assign an Elastic IP (i.e. static IP), and turn the instance on when you need it, shut it down when you're done. If there happens to be a failure at Amazon right at the same time you have a failure... spin up a new instance in a different zone and give it the Elastic IP. No mucking about with ACLs, etc. Costs a few cents to run for whatever length of time it takes to fix your issue, and is reasonably secure (especially if you shut the box off when you're not using it). - Peter From jared at puck.nether.net Mon Jun 2 14:14:50 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 2 Jun 2014 07:14:50 -0700 Subject: ipmi access In-Reply-To: References: Message-ID: My IPMI (super micro) you can put v6 and v4 filters into for protecting the ip space from trusted sources. Has my home static ip ranges and a few intermediary ranges that I also have access to. > On Jun 2, 2014, at 5:10 AM, Randy Bush wrote: > > so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% > of the time i want it blocked off. but that other 1%, i want kvm > console, remote media, and dim sum. > > currently, i just block the ip address chunk into which i put ipmi at > the border of the rack. when i want access, i reconfig the acl. bit of > a pita. > > anyone care to share better idea(s)? thanks. > > randy From jbates at paradoxnetworks.net Mon Jun 2 14:29:41 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Mon, 02 Jun 2014 09:29:41 -0500 Subject: ipmi access In-Reply-To: References: Message-ID: <538C8A55.1030305@paradoxnetworks.net> I keep 2 vpn servers. ACL's at router to ipmi vlan, plus whatever additional security ipmi happens to have. I'm of the belief that vpn servers should be redundant. Kinda silly to lose one and not have access to your network. :) Jack On 6/2/2014 7:10 AM, Randy Bush wrote: > so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% > of the time i want it blocked off. but that other 1%, i want kvm > console, remote media, and dim sum. > > currently, i just block the ip address chunk into which i put ipmi at > the border of the rack. when i want access, i reconfig the acl. bit of > a pita. > > anyone care to share better idea(s)? thanks. > > randy From brak at gameservers.com Mon Jun 2 14:57:17 2014 From: brak at gameservers.com (Brian Rak) Date: Mon, 02 Jun 2014 10:57:17 -0400 Subject: ipmi access In-Reply-To: <538C6F01.4070709@massar.ch> References: <538C6CC8.1060408@winterei.se> <538C6F01.4070709@massar.ch> Message-ID: <538C90CD.5080207@gameservers.com> The kernel is the least of your worries here. This is what you can expect from the Supermicro controllers: Linux Kernel 2.6.17.13 Lighttpd 1.4.32 pcre 8.31 pcre 8.33 msmtp 1.4.16 tree 1.5.2.2 flex 2.5.35 readline 5.2 termcap 1.3.1 BIND 9.8.1-P1 busybox 1.12.0 ntp 4.2.4p4 openssl 0.9.8h openlldp 0.3alpha wide-dhcpv6 20080615 openldap 2.4.11 zlib 1.2.3 glibc 2.3.5 gcc 3.4.4 libxml2 2.6.32 On 6/2/2014 8:33 AM, Jeroen Massar wrote: > On 2014-06-02 14:23, Paul S. wrote: > [..] >> On most ATEN chip based BMC boards from Supermicro, it includes a UI to >> iptables that works in the same way. >> >> You could put it on a public net, allow your stuff and DROP 0.0.0.0/0. >> >> But unless you have servers with those, I think the best way to go is >> putting them on internal IPs and then using some sort of a VPN. > While you are typing the iptables command, do a check of the software > versions, typically they are running a decade old kernel and a lot of > unpatched software that is exposed. You really do not want to run that > on the Interwebs, just the idea of any packet arriving to such a kernel > is scary. > > > Relevant good reads: > http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn > https://plus.google.com/+TobiasDiedrich/posts/Bq44KkBT3vK > > The first URL references 2.6.17, yes... *2.6.17* is the CURRENT version > of the kernel running on most IPMIs out there. > > http://kernelnewbies.org/Linux_2_6_17 - Released 17 June, 2006 > > 8 years... ouch, yeah, no way that is going to be attached to a public > network... > > Thus please, don't shoot yourself in the foot with that and more > importantly don't shoot the rest of the Internet in the foot as they'll > receive the packets. > > > Note: the IPMI that Michael describes is on a unrouted VLAN, the access > to the OpenVPN port that he runs on the IPMI happens through SSH on a > jumpbox which is ACLd away. > > Greets, > Jeroen > > (who is still awaiting for Zeus4IPMI) > From randy at psg.com Mon Jun 2 15:11:18 2014 From: randy at psg.com (Randy Bush) Date: Mon, 02 Jun 2014 08:11:18 -0700 Subject: ipmi access In-Reply-To: References: Message-ID: > My IPMI (super micro) you can put v6 and v4 filters into for > protecting the ip space from trusted sources. cool. can i put in "star alliance?" :) randy From morrowc.lists at gmail.com Mon Jun 2 15:14:42 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 2 Jun 2014 11:14:42 -0400 Subject: ipmi access In-Reply-To: References: Message-ID: On Mon, Jun 2, 2014 at 11:11 AM, Randy Bush wrote: >> My IPMI (super micro) you can put v6 and v4 filters into for >> protecting the ip space from trusted sources. > > cool. can i put in "star alliance?" :) restfulwhois look up for gogoinflight ... done. From charles at thefnf.org Mon Jun 2 15:19:53 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Mon, 02 Jun 2014 10:19:53 -0500 Subject: ipmi access In-Reply-To: References: Message-ID: On 2014-06-02 07:19, Andrew Latham wrote: > I use OpenVPN to access an Admin/sandboxed network with insecure > portals, > wiki, and ipmi. Same here. My entire in band management plane (DRAC (disk/cpu/temperature etc telemetry to my OpenManage/Zenoss server), OpenSSH and 80/443 for backend stuffs) is all behind OpenVPN. Zero outside exposure. Out of band, is a cyclades (acs48) directly on the internet with all my consoles hooked up and it controls daisy chained Cyclades PDUs. I have fairly strong passwords on it, everything is SSH. How important is it to setup ACLs on it? Like say some VPS that's outside my infra and lock the Cyclades down to that? Is that really a much higher level of security? From ag4ve.us at gmail.com Mon Jun 2 16:06:45 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 2 Jun 2014 12:06:45 -0400 Subject: ipmi access In-Reply-To: References: Message-ID: On Mon, Jun 2, 2014 at 10:14 AM, Jared Mauch wrote: > My IPMI (super micro) you can put v6 and v4 filters into for protecting the ip space from trusted sources. Has my home static ip ranges and a few intermediary ranges that I also have access to. > Mmmm, and an ip has never been spoofed and no arp poisoned. And I wonder how good these filters are in their TCP stack implementation - not something I'd trust :) From blake at ispn.net Mon Jun 2 16:14:59 2014 From: blake at ispn.net (Blake Hudson) Date: Mon, 02 Jun 2014 11:14:59 -0500 Subject: ipmi access In-Reply-To: References: Message-ID: <538CA303.4090900@ispn.net> shawn wilson wrote the following on 6/2/2014 11:06 AM: > On Mon, Jun 2, 2014 at 10:14 AM, Jared Mauch wrote: >> My IPMI (super micro) you can put v6 and v4 filters into for protecting the ip space from trusted sources. Has my home static ip ranges and a few intermediary ranges that I also have access to. >> > Mmmm, and an ip has never been spoofed and no arp poisoned. And I > wonder how good these filters are in their TCP stack implementation - > not something I'd trust :) We just reported a bug to Dell regarding their last 2 generations of remote access controllers where the firewall rules only apply to TCP and not to ICMP or UDP. Their first response was to replace the motherboard. Second response was that this is just how they work. Not looking good. We run our IPMI interfaces behind stateless ACLs, accessible from VPN or trusted ranges. --Blake From morrowc.lists at gmail.com Mon Jun 2 16:56:47 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 2 Jun 2014 12:56:47 -0400 Subject: ipmi access In-Reply-To: <538CA303.4090900@ispn.net> References: <538CA303.4090900@ispn.net> Message-ID: On Mon, Jun 2, 2014 at 12:14 PM, Blake Hudson wrote: > We just reported a bug to Dell regarding their last 2 generations of remote > access controllers where the firewall rules only apply to TCP and not to > ICMP or UDP. Their first response was to replace the motherboard. Second > response was that this is just how they work. Not looking good. We run our > IPMI interfaces behind stateless ACLs, accessible from VPN or trusted > ranges. so... as per usual: 1) embedded devices suck rocks 2) no updates or sanity expected anytime soon in same 3) protect yourself, or suffer the consequences seems normal. From brian.peter.dickson at gmail.com Mon Jun 2 17:20:51 2014 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Mon, 2 Jun 2014 13:20:51 -0400 Subject: ipmi access Message-ID: Here's one useful method, which depends on having appropriate subnet and VLAN capabilities. Have all hosts at a given site, have their main interface do dot1q (switch config trunked port). The ipmi interfaces will be on one VLAN (put those ports in that VLAN). The first VLAN is the public routed subnet. The router needs to be configured with this VLAN. The second VLAN is the IPMI, and is NOT CONFIGURED ON THE ROUTER. This second VLAN has only hosts and IMPIs. No connectivity to the world, period. (Be sure IP packet forwarding is disabled on the hosts!) On (some subset of) the hosts' main interface, run suitable remote KVM-ish protocol. For instance, use ssh with X forwarding, and/or VNC (or XVNC), and whatever local IMPI client thing you want (browser). Connecting to ipmi is by IP on the second VLAN (or by name, left as exercise for the reader.) Avoids ACL fiddling, is as secure as your host access method (but no more secure, obviously). YMMV. Brian From shopik at inblock.ru Mon Jun 2 17:32:15 2014 From: shopik at inblock.ru (Nikolay Shopik) Date: Mon, 02 Jun 2014 21:32:15 +0400 Subject: ipmi access In-Reply-To: References: <538CA303.4090900@ispn.net> Message-ID: <538CB51F.6050506@inblock.ru> On 02/06/14 20:56, Christopher Morrow wrote: > so... as per usual: > 1) embedded devices suck rocks > 2) no updates or sanity expected anytime soon in same > 3) protect yourself, or suffer the consequences > > seems normal. So I wonder why vendors don't publish source code of these ipmi firmware in first place? Like supermicro from what we know its 99% is open source stuff. From morrowc.lists at gmail.com Mon Jun 2 17:40:20 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 2 Jun 2014 13:40:20 -0400 Subject: ipmi access In-Reply-To: <538CB51F.6050506@inblock.ru> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> Message-ID: On Mon, Jun 2, 2014 at 1:32 PM, Nikolay Shopik wrote: > > On 02/06/14 20:56, Christopher Morrow wrote: >> >> so... as per usual: >> 1) embedded devices suck rocks >> 2) no updates or sanity expected anytime soon in same >> 3) protect yourself, or suffer the consequences >> >> seems normal. > > > So I wonder why vendors don't publish source code of these ipmi firmware in > first place? Like supermicro from what we know its 99% is open source stuff. it seems that pretty much no one (who pays them money, and complains to them, who does that?) cares? also, supermicro doesn't use something they built for this, they get an outsourced solution. >From poking around some at my limited set of examplar IPMI-like things, there are like 3 vendors. (I'm sure there are more, but... it LOOKS like a very small set is just being sold out as parts to motherboard manufacturers) From jeroen at massar.ch Mon Jun 2 17:39:43 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 02 Jun 2014 19:39:43 +0200 Subject: ipmi access In-Reply-To: <538CB51F.6050506@inblock.ru> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> Message-ID: <538CB6DF.4090703@massar.ch> On 2014-06-02 19:32, Nikolay Shopik wrote: > > On 02/06/14 20:56, Christopher Morrow wrote: >> so... as per usual: >> 1) embedded devices suck rocks >> 2) no updates or sanity expected anytime soon in same >> 3) protect yourself, or suffer the consequences >> >> seems normal. > > So I wonder why vendors don't publish source code of these ipmi firmware > in first place? Like supermicro from what we know its 99% is open source > stuff. Source won't help too much, as upgrading the kernel will require a lot more magic than just that. Also, do you have time to support all the different IPMI boxes out there while your vendor should be doing that work? For the toolchain, see amongst others: http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn Note that the big problem with "embedded" devices (be that an Android phone, your TV set, your dishwasher, an IPMI device, your car or one of thousand "media players") is: they get popped in a box and they will rarely if ever get an update after that. The market has to change to support that, and it likely won't unless the prices for toys are going to go up sky high to be able to pay for somebody doing that work. The Open Source portion only means that you are more aware that you are running some software with horrible bugs in there. Hence: never route them, never make them remotely publicly available. And then start thinking about all the fun new "Cloud Connected" devices... Greets, Jeroen From brak at gameservers.com Mon Jun 2 17:42:45 2014 From: brak at gameservers.com (Brian Rak) Date: Mon, 02 Jun 2014 13:42:45 -0400 Subject: ipmi access In-Reply-To: <538CB51F.6050506@inblock.ru> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> Message-ID: <538CB795.80404@gameservers.com> They do publish it. The problem is, it's not documented, and it takes a bunch of work to get into a usable state. See ftp://ftp.supermicro.com/GPL/SMT/SDK_SMT_X9_317.tar.gz Plus, the firmware environment is pretty hostile. If you flash some bad firmware, your only option is to desolder the IPMI flash chip and program it externally. It cannot be reprogrammed in circuit, and there's no recovery method. On 6/2/2014 1:32 PM, Nikolay Shopik wrote: > > On 02/06/14 20:56, Christopher Morrow wrote: >> so... as per usual: >> 1) embedded devices suck rocks >> 2) no updates or sanity expected anytime soon in same >> 3) protect yourself, or suffer the consequences >> >> seems normal. > > So I wonder why vendors don't publish source code of these ipmi > firmware in first place? Like supermicro from what we know its 99% is > open source stuff. From ag4ve.us at gmail.com Mon Jun 2 17:52:58 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 2 Jun 2014 13:52:58 -0400 Subject: ipmi access In-Reply-To: <538CB51F.6050506@inblock.ru> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> Message-ID: iLo is a value add to HP. DRAC sucks (so I'd replace it and then Dell would have hardware under support with some unknown IPMI). Supermicro, Tyan, etc - idk. Really, it would be nice to have an open card that does this. Even if the card were limited to what you could do with DMA and some serial (i2c and whatnot) cables. I'd use that instead of something else (in this case, mainly because I'd replace the Java console for some VNC solution - but also because of trust). On Mon, Jun 2, 2014 at 1:32 PM, Nikolay Shopik wrote: > > On 02/06/14 20:56, Christopher Morrow wrote: >> >> so... as per usual: >> 1) embedded devices suck rocks >> 2) no updates or sanity expected anytime soon in same >> 3) protect yourself, or suffer the consequences >> >> seems normal. > > > So I wonder why vendors don't publish source code of these ipmi firmware in > first place? Like supermicro from what we know its 99% is open source stuff. From shopik at inblock.ru Mon Jun 2 19:13:42 2014 From: shopik at inblock.ru (Nikolay Shopik) Date: Mon, 02 Jun 2014 23:13:42 +0400 Subject: ipmi access In-Reply-To: <538CB6DF.4090703@massar.ch> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> <538CB6DF.4090703@massar.ch> Message-ID: <538CCCE6.3020405@inblock.ru> On 02.06.2014 21:39, Jeroen Massar wrote: > > Source won't help too much, as upgrading the kernel will require a lot > more magic than just that. > > Also, do you have time to support all the different IPMI boxes out there > while your vendor should be doing that work? Agree, but most IPMI cards we get recently doesn't increase cost of Motherboards (well it does, but not that much as vendor would like to get from you). Especially if you compare prices of MB of 5-7 years ago w/o onboard IPMI. > > For the toolchain, see amongst others: > http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn > > > Note that the big problem with "embedded" devices (be that an Android > phone, your TV set, your dishwasher, an IPMI device, your car or one of > thousand "media players") is: they get popped in a box and they will > rarely if ever get an update after that. As long its not mass product and have different types of all kinds hw, it will be fragmented and will be unsupported right after release. > > The market has to change to support that, and it likely won't unless the > prices for toys are going to go up sky high to be able to pay for > somebody doing that work. Well Dell/HP users pay premium for IPMI, it doesn't change that. From shopik at inblock.ru Mon Jun 2 19:19:56 2014 From: shopik at inblock.ru (Nikolay Shopik) Date: Mon, 02 Jun 2014 23:19:56 +0400 Subject: ipmi access In-Reply-To: References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> Message-ID: <538CCE5C.806@inblock.ru> On 02.06.2014 21:52, shawn wilson wrote: > Really, it would be nice to have an open card that > does this. Even if the card were limited to what you could do with DMA > and some serial (i2c and whatnot) cables. I'd use that instead of > something else (in this case, mainly because I'd replace the Java > console for some VNC solution - but also because of trust). I believe most people need from IPMI is KVM (sometimes serial), and (rarely?) need to mount remote ISO images. Java only used for mouting images. KVM is transfered via VNC protocol iirc. From ag4ve.us at gmail.com Mon Jun 2 19:47:59 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 2 Jun 2014 15:47:59 -0400 Subject: ipmi access In-Reply-To: <538CCE5C.806@inblock.ru> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> <538CCE5C.806@inblock.ru> Message-ID: On Mon, Jun 2, 2014 at 3:19 PM, Nikolay Shopik wrote: > > Java only used for mouting images. KVM is transfered via VNC protocol iirc. They're not re-inventing the wheel, but I think KVM is generally some VNC stream embedded in http(s) which VNC clients can't seem to understand (at least, at a glance, I haven't been able to connect to iLo, DRAC, Spider, or Tyan IPMI from outside the Java app). From morrowc.lists at gmail.com Mon Jun 2 19:49:16 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 2 Jun 2014 15:49:16 -0400 Subject: ipmi access In-Reply-To: <538CCE5C.806@inblock.ru> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> <538CCE5C.806@inblock.ru> Message-ID: On Mon, Jun 2, 2014 at 3:19 PM, Nikolay Shopik wrote: > Java only used for mouting images. KVM is transfered via VNC protocol iirc. hahaha! not on a Dell/drac ;( where it's some goofy key'd (xor'd I think?) vnc bastardization :( From cma at cmadams.net Mon Jun 2 19:52:52 2014 From: cma at cmadams.net (Chris Adams) Date: Mon, 2 Jun 2014 14:52:52 -0500 Subject: ipmi access In-Reply-To: <538CCE5C.806@inblock.ru> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> <538CCE5C.806@inblock.ru> Message-ID: <20140602195252.GB24011@cmadams.net> Once upon a time, Nikolay Shopik said: > I believe most people need from IPMI is KVM (sometimes serial), and > (rarely?) need to mount remote ISO images. > > Java only used for mouting images. KVM is transfered via VNC protocol iirc. In my experience, KVM requires their "special" client (Java), because the protocol isn't _exactly_ VNC. -- Chris Adams From brak at gameservers.com Mon Jun 2 19:54:36 2014 From: brak at gameservers.com (Brian Rak) Date: Mon, 02 Jun 2014 15:54:36 -0400 Subject: ipmi access In-Reply-To: References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> <538CCE5C.806@inblock.ru> Message-ID: <538CD67C.7010806@gameservers.com> On 6/2/2014 3:47 PM, shawn wilson wrote: > On Mon, Jun 2, 2014 at 3:19 PM, Nikolay Shopik wrote: > >> Java only used for mouting images. KVM is transfered via VNC protocol iirc. > They're not re-inventing the wheel, but I think KVM is generally some > VNC stream embedded in http(s) which VNC clients can't seem to > understand (at least, at a glance, I haven't been able to connect to > iLo, DRAC, Spider, or Tyan IPMI from outside the Java app). No, at least on SuperMicro it's a hacked up VNC protocol. It's not embedded in HTTP/HTTPS, it just uses HTTP/HTTPS to fetch the Java app. I say hacked up because it's got a custom auth method, and a whole bunch of undocumented extensions. I looked into implementing support in noVNC for it, but reverse engineering a binary protocol is a bit beyond me. It's also annoying because it claims to be a TightVNC server (and uses TightVNC auth/tunneling)... I was so hopeful that would just work. It looks like they took the TightVNC code, and just made a bunch of changes with no regard for the specification. From jeroen at massar.ch Mon Jun 2 20:56:58 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 02 Jun 2014 22:56:58 +0200 Subject: ipmi access In-Reply-To: <538CD67C.7010806@gameservers.com> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> <538CCE5C.806@inblock.ru> <538CD67C.7010806@gameservers.com> Message-ID: <538CE51A.40902@massar.ch> On 2014-06-02 21:54, Brian Rak wrote: > > On 6/2/2014 3:47 PM, shawn wilson wrote: >> On Mon, Jun 2, 2014 at 3:19 PM, Nikolay Shopik wrote: >> >>> Java only used for mouting images. KVM is transfered via VNC protocol >>> iirc. >> They're not re-inventing the wheel, but I think KVM is generally some >> VNC stream embedded in http(s) which VNC clients can't seem to >> understand (at least, at a glance, I haven't been able to connect to >> iLo, DRAC, Spider, or Tyan IPMI from outside the Java app). > No, at least on SuperMicro it's a hacked up VNC protocol. It's not > embedded in HTTP/HTTPS, it just uses HTTP/HTTPS to fetch the Java app. > > I say hacked up because it's got a custom auth method, and a whole bunch > of undocumented extensions. I looked into implementing support in noVNC > for it, but reverse engineering a binary protocol is a bit beyond me. While there is no spec, there are people who have reversed it: https://github.com/thefloweringash/chicken-aten-ikvm Greets, Jeroen From mpetach at netflight.com Mon Jun 2 21:37:35 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 Jun 2014 14:37:35 -0700 Subject: 2014.06.02 NANOG61 morning notes posted Message-ID: If anyone isn't here in Bellevue today (unlikely, given how packed it is; amazing turnout for this NANOG!) but is curious about notes from this morning, I've put my notes up at http://nanog.cluepon.net/index.php/NANOG61morn2 Thank you Dave Meyer for a great keynote, and kudos to NTT for an awesomely funny kickoff video. And yes, Ren, I'll be your friend now. ;) Thanks everyone! Matt PS--I'm never going to let Dorian come up behind me ever again.... #scarredforlife From mysidia at gmail.com Mon Jun 2 23:42:36 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 2 Jun 2014 18:42:36 -0500 Subject: ipmi access In-Reply-To: References: Message-ID: On Mon, Jun 2, 2014 at 8:21 AM, shawn wilson wrote: [snip] > So, kinda the same idea - just put IPMI on another network and use ssh > forwards to it. You can have multiple boxes connected in this fashion > but the point is to keep it simple and as secure as possible (and IPMI > security doesn't really count here :) ). About that "as secure as possible" bit. If just one server gets compromised that happens to have its IPMI port plugged into this private network; the attacker may be able to pivot into the IPMI network and start unloading IPMI exploits. So caution is definitely advised, about security boundaries: in case a shared IPMI network is used, and this is a case where a Private VLAN (PVLAN-Isolated) could be considered, to ensure devices on the IPMI LAN cannot communicate with one another --- and only devices on a separate dedicated IPMI Management station subnet can interact with the IPMI LAN. -- -JH From mpetach at netflight.com Mon Jun 2 23:48:06 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 Jun 2014 16:48:06 -0700 Subject: 2014.06.02 NANOG61 day 1 afternoon notes Message-ID: I posted my notes from the afternoon session up at http://nanog.cluepon.net/index.php/NANOG61aft2 I am in the security track, but not recording notes, as speakers have asked to be off the record for the discussions. So, I'll resume notes tomorrow morning. Have a wonderful evening everyone! Matt From ag4ve.us at gmail.com Tue Jun 3 01:05:54 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 2 Jun 2014 21:05:54 -0400 Subject: ipmi access In-Reply-To: References: Message-ID: On Mon, Jun 2, 2014 at 7:42 PM, Jimmy Hess wrote: > On Mon, Jun 2, 2014 at 8:21 AM, shawn wilson wrote: [snip] >> So, kinda the same idea - just put IPMI on another network and use ssh >> forwards to it. You can have multiple boxes connected in this fashion >> but the point is to keep it simple and as secure as possible (and IPMI >> security doesn't really count here :) ). > > About that "as secure as possible" bit. If just one server gets > compromised that happens to have its IPMI port plugged into this > private network; the attacker may be able to pivot into the IPMI > network and start unloading IPMI exploits. > Generally, I worry about workstations with access being compromised more than I do about a server running sshd and routing traffic. But obviously, if someone gets access, they can cause play foosball with your stuff. > So caution is definitely advised, about security boundaries: in case > a shared IPMI network is used, and this is a case where a Private > VLAN (PVLAN-Isolated) could be considered, to ensure devices on > the IPMI LAN cannot communicate with one another --- and only > devices on a separate dedicated IPMI Management station subnet can > interact with the IPMI LAN. > I can't really argue against the proper use of vlans (and that surely wasn't my point). I was merely saying that you can use ssh as a simpler solution (and possibly a more secure one since there's not a conduit to broadcast to/from) than a vpn. That's it. From jcurran at arin.net Tue Jun 3 07:13:45 2014 From: jcurran at arin.net (John Curran) Date: Tue, 3 Jun 2014 07:13:45 +0000 Subject: =?Windows-1252?Q?Request_for_Community_Input_=96_Enhancing_ICANN_Accounta?= =?Windows-1252?Q?bility?= References: <538CCA90.2080705@arin.net> Message-ID: <1CD78601-F4C1-47A6-8CAC-B6B324F3FD09@corp.arin.net> NANOG Folks - There is a fairly important ICANN consultation going on which seeks input from the Internet community regarding ICANN's accountability mechanisms and the desirability of any potential enhancements (this is context of ICANN operating in the absence of a contractual relationship with the US Government.) This topic has the potential for significant impact on the administration of both Internet DNS names and IP addresses, so those who have strong views in these matters might want to provide input accordingly (See the attached message to PPML providing pointers to the consultation) The RIRs, as coordinated via the NRO, have a draft response (attached) and input on that is welcome as well. ICANN extended the deadline to the end of this week, which provides this opportunity to obtain additional community input. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-ppml] Request for Community Input – Enhancing ICANN Accountability Date: June 2, 2014 at 12:03:44 PM PDT To: > ICANN issued a call for community input regarding its continuing accountability in the future in the absence of a contractual relationship with the U.S. Government. https://www.icann.org/public-comments/enhancing-accountability-2014-05-06-en The Executive Council of the Number Resource Organization (NRO) has drafted a response on behalf of the five Regional Internet Registry (RIR) communities. (See below) ARIN welcomes your feedback on this draft, and we will be accepting input through 4 June 2014. Please send your comments to info at arin.net. The community may also participate directly by providing feedback directly to ICANN as described here: https://www.icann.org/resources/pages/enhancing-accountability-2014-05-06-en Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) *** ICANN call for public comments on Enhancing ICANN’s Accountability Response from the Number Resource Organization (NRO) DRAFT ONLY - 29 May 2014 The NRO thanks ICANN for the opportunity to comment on means for improving its accountability, and we provide the following responses to the questions contained in the call for comments: https://www.icann.org/public-comments/enhancing-accountability-2014-05-06-en 1. What issues does the community identify as being core to strengthening ICANN’s overall accountability in the absence of its historical contractual relationship to the US government? Regarding ICANN's accountability with respect to IP addressing functions, we believe that the ASO structure provides a necessary and sufficient separation between policy formation and policy implementation. Global IP addressing policy is developed by the RIR communities and passed via the ASO to ICANN, in accordance with the ASO MoU; while policy is implemented by the IANA in the form of services delivered to the RIRs under specific service agreements. While these existing mechanisms have proven successful over the past 10 years, we believe than a review is appropriate at this time, prior to the expected NTIA transition, along with reviews by each of the RIRs of their own accountability mechanisms. Notwishstanding any improvements needed, these agreements must clearly define appropriate dispute resolution, escalation and arbitration procedures. We note that there is no agreement or expectation of any role for the USG NTIA in these processes; therefore we do not view the historical contractual relationship between ICANN and the US government as an accountability mechanism, and neither do we consider the NTIA's role as a source of ICANN’s accountability with respect to Internet number resources. In the hypothetical case that IANA had ever failed to provide number allocation services to any RIR in accordance to existing policies and agreements, we would have not relied upon the US government to solve this issue. Rather we would have worked transparently with ICANN, in accordance to the terms of existing agreements, to address the issue. The NRO is committed to continue to work with ICANN to strengthen escalation and dispute resolution mechanisms to allow the parties to work better in any hypothetical case of failed expectations. 2. What should be the guiding principles to ensure that the notion of accountability is understood and accepted globally? What are the consequences if the ICANN Board is not being accountable to the community? Is there anything that should be added to the Working Group’s mandate? The NRO does not believe that the contract with the US government should be replaced with a similar mechanism at a global level, therefore a guiding principle is specifically not to create any "superior" structure or organisation; rather ICANN's accountability should be defined in terms of transparent agreements with ICANN stakeholders, in which roles and responsibilities, and dispute resolution and arbitration mechanisms are fully defined. We believe that a failure by ICANN to abide clearly by established accountability mechanisms, and in particular by defined dispute resolution and arbitration mechanisms should have clear consequences, and therefore that arbitration mechanisms should be binding. Furthermore, they must be implementable and effective upon ICANN, regardless of its final structure or locale. The guiding principles for defining or strengthening these accountability mechanisms should be: that they are transparent, implementable and open to improvement; and that they operate in the interests of the open, stable and secure operation of the Internet. 3. Do the Affirmation of Commitments and the values expressed therein need to evolve to support global acceptance of ICANN’s accountability and so, how? The NRO believes that the Affirmation of Commitments is a good umbrella covering higher-level issues that may not be specifically included in existing contracts, MoUs, accountability frameworks and documents that govern ICANN’s relationships with its different stakeholder groups. While the most important accountability of ICANN is with its respective stakeholders and community, the Affirmation of Commitments and its evolution could support wider trust in ICANN’s ongoing operations at the international level. We believe that this evolution could take the form of a new affirmation into which many more stakeholder communities, including Governments, would enter. 4. What are the means by which the Community is assured that ICANN is meeting its accountability commitments? The current contracts, MoUs, accountability frameworks and documents that ICANN currently has with different parts of its community provide certain levels of accountability. These documents can evolve and improve however this should be an ongoing process which continues beyond the end of NTIA’s role, and throughout the entire lifetime of ICANN. 5. Are there other mechanisms that would better ensure that ICANN lives up to its commitments? If ICANN can in time be incorporated as an international organization under international law, this may provide the ICANN community with additional mechanisms to solve disputes through mediation, arbitration or judicial avenues; and added confidence in the ability to serve stakeholders uniformly across the globe. While we would like this possibility to be actively explored by ICANN, we do not believe it is a necessary prerequisite to any of the other measures described in this response, but welcome continued engagement with the global stakeholder community on this topic. 6. What additional comments would you like to share that could be of use to the ICANN Accountability Working Group? The NRO notes the present clarity of responsibility that exists with respect ICANN's roles in administration of Internet protocol identifiers for the IETF and Internet number resources for the Internet address community, and suggests that it might helpful for the ICANN Accountability Working Group to examine these successes in its efforts. The NRO expects to contribute and work together with the ICANN Accountability Working Group, and other stakeholders in the ICANN community, to improve mechanisms for enhancing accountability in the years to come. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From jcurran at arin.net Tue Jun 3 16:29:02 2014 From: jcurran at arin.net (John Curran) Date: Tue, 3 Jun 2014 16:29:02 +0000 Subject: ARIN PPC Agenda for NANOG 61 Now Available References: <53862166.1050407@arin.net> Message-ID: <9B513B8C-7F89-4C83-A0A0-8B6BAF5AB9C3@corp.arin.net> NANOG 61 Attendees - The ARIN Public Policy consultation is now starting in the Evergreen Ballroom. /John Begin forwarded message: From: ARIN > Subject: [arin-announce] ARIN PPC Agenda for NANOG 61 Now Available Date: May 28, 2014 at 10:48:22 AM PDT To: > Don't forget to mark your calendar and join us for ARIN's Public Policy Consultation (PPC), which will be held during NANOG 61 in Bellevue, Washington on Tuesday, 3 June 2014, from 9:30 - 1:00 PM. The policy consultation is part of ARIN's Policy Development Process, and it is an open public discussion of Internet number resource policy. Registered NANOG 61 attendees do not need to register to participate in this session. If you plan to attend and are not registered for NANOG you must register for the ARIN PPC at the https://www.arin.net/ppcregister There is no registration fee for this ARIN session, and it does not provide you entry to any other NANOG programming or social events. Current policy proposals up for discussion at this meeting are: * Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks * Draft Policy ARIN-2014-1: Out of Region Use * Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements * Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations * Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] * Draft Policy ARIN-2014-8: Alignment of 8.3 Needs Requirements to Reality of Business * Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements * Draft Policy ARIN-2014-11: Improved Registry Accuracy Proposal * Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy * Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 * Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers * Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers * Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update * Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate Text available at: https://www.arin.net/policy/proposals/ or in the PPC Discussion Guide: https://www.arin.net/ppcnanog61 ARIN will offer a webcast, live transcript, and Jabber chat options for remote participants. Registered remote participants can submit comments and questions to the discussions during the meeting. Details are available at: https://www.arin.net/ppcremote Register to attend in person or remotely today! Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From mpetach at netflight.com Wed Jun 4 01:03:26 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 3 Jun 2014 18:03:26 -0700 Subject: 2014.06.03 NANOG61 DNS session notes up Message-ID: sorry, I'm terribly behind today. I had thought I was going to have time to put together a lightning talk presentation about our IPsec solution, but today's been so hectic I didn't have a chance to pull slides together. maybe next time. ^_^; Instead, you get notes from the DNS track this morning. :) http://nanog.cluepon.net/index.php/NANOG61dns3 (rest of notes are already done but i'm late for my next meeting so i have to dash, and will post the rest after the meetings and socials) Matt From mpetach at netflight.com Wed Jun 4 08:42:25 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 4 Jun 2014 01:42:25 -0700 Subject: 2014.06.03 NANOG61 day 2 afternoon notes Message-ID: Notes from the afternoon session today are up. :) http://nanog.cluepon.net/index.php/NANOG61aft3 Matt From achatz at forthnet.gr Wed Jun 4 13:52:19 2014 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Wed, 04 Jun 2014 16:52:19 +0300 Subject: real-time traffic engineering/management solutions Message-ID: <538F2493.4090206@forthnet.gr> I'm having a look at real-time traffic engineering/management solutions that include visibility/analysis/control and offer the following basic characteristics: 1) take into account * links utilization/threshold/deviation * link price * packet delay/loss * physical/logical topology 2) and offer real-time automatic ingress/egress traffic adjustment using * netconf & bgp to change localpref/med/aspath/community attributes (mandatory) * SDN/Openflow/I2RS/PCEP technologies (optional) 3) considering only IP traffic (MPLS can be optional), especially on external links used for peering and transit by tier-1/2 providers. Do you have any personal experience regarding the above features? >From my personal search Cisco offers Quantum/WAE (inc MATE) which seem very limited in real-time functionality and Huawei offers RR+ which seems interesting but unknown to many people (and maybe not compatible with all vendor routers). Any other idea or commercial option? Offline answers would be good too. -- Tassos From jwbensley at gmail.com Wed Jun 4 16:14:26 2014 From: jwbensley at gmail.com (James Bensley) Date: Wed, 4 Jun 2014 17:14:26 +0100 Subject: real-time traffic engineering/management solutions In-Reply-To: <538F2493.4090206@forthnet.gr> References: <538F2493.4090206@forthnet.gr> Message-ID: I haven't used it and have no experiance with it, I've simply "seen it around" - Noction may be what you're looking for: http://www.noction.com/ Cheers, James. From richard.hesse at weebly.com Wed Jun 4 17:34:46 2014 From: richard.hesse at weebly.com (Richard Hesse) Date: Wed, 4 Jun 2014 10:34:46 -0700 Subject: real-time traffic engineering/management solutions In-Reply-To: References: <538F2493.4090206@forthnet.gr> Message-ID: I'll wholeheartedly endorse Noction's IRP. It works really well, and Noction is very quick to respond to both bugs and feature requests. -richard On Wed, Jun 4, 2014 at 9:14 AM, James Bensley wrote: > I haven't used it and have no experiance with it, I've simply "seen it > around" - Noction may be what you're looking for: > http://www.noction.com/ > > Cheers, > James. > From contact at winterei.se Wed Jun 4 17:39:46 2014 From: contact at winterei.se (Paul S.) Date: Thu, 05 Jun 2014 02:39:46 +0900 Subject: real-time traffic engineering/management solutions In-Reply-To: <538F2493.4090206@forthnet.gr> References: <538F2493.4090206@forthnet.gr> Message-ID: <538F59E2.1020503@winterei.se> Two 'established' options are, 0. Noction IRP (As mentioned) 1. Internap FCP Everyone appears to either be using one of these, or have gone full custom. On 6/4/2014 午後 10:52, Tassos Chatzithomaoglou wrote: > I'm having a look at real-time traffic engineering/management solutions that include visibility/analysis/control and offer the following basic characteristics: > > 1) take into account > > * links utilization/threshold/deviation > * link price > * packet delay/loss > * physical/logical topology > > > 2) and offer real-time automatic ingress/egress traffic adjustment using > > * netconf & bgp to change localpref/med/aspath/community attributes (mandatory) > * SDN/Openflow/I2RS/PCEP technologies (optional) > > > 3) considering only IP traffic (MPLS can be optional), especially on external links used for peering and transit by tier-1/2 providers. > > Do you have any personal experience regarding the above features? > > From my personal search Cisco offers Quantum/WAE (inc MATE) which seem very limited in real-time functionality and Huawei offers RR+ which seems interesting but unknown to many people (and maybe not compatible with all vendor routers). > > Any other idea or commercial option? Offline answers would be good too. > > > -- > Tassos > From kemp at network-services.uoregon.edu Wed Jun 4 18:12:04 2014 From: kemp at network-services.uoregon.edu (John Kemp) Date: Wed, 04 Jun 2014 11:12:04 -0700 Subject: real-time traffic engineering/management solutions In-Reply-To: <538F59E2.1020503@winterei.se> References: <538F2493.4090206@forthnet.gr> <538F59E2.1020503@winterei.se> Message-ID: <538F6174.40007@network-services.uoregon.edu> I believe ThousandEyes would be another example. /jgk On 6/4/14 10:39 AM, Paul S. wrote: > Two 'established' options are, > > 0. Noction IRP (As mentioned) > 1. Internap FCP > > Everyone appears to either be using one of these, or have gone full > custom. > > On 6/4/2014 午後 10:52, Tassos Chatzithomaoglou wrote: >> I'm having a look at real-time traffic engineering/management >> solutions that include visibility/analysis/control and offer the >> following basic characteristics: >> >> 1) take into account >> >> * links utilization/threshold/deviation >> * link price >> * packet delay/loss >> * physical/logical topology >> >> >> 2) and offer real-time automatic ingress/egress traffic adjustment using >> >> * netconf & bgp to change localpref/med/aspath/community >> attributes (mandatory) >> * SDN/Openflow/I2RS/PCEP technologies (optional) >> >> >> 3) considering only IP traffic (MPLS can be optional), especially on >> external links used for peering and transit by tier-1/2 providers. >> >> Do you have any personal experience regarding the above features? >> >> From my personal search Cisco offers Quantum/WAE (inc MATE) which >> seem very limited in real-time functionality and Huawei offers RR+ >> which seems interesting but unknown to many people (and maybe not >> compatible with all vendor routers). >> >> Any other idea or commercial option? Offline answers would be good too. >> >> >> -- >> Tassos >> > From warren at kumari.net Wed Jun 4 19:15:47 2014 From: warren at kumari.net (Warren Kumari) Date: Wed, 4 Jun 2014 12:15:47 -0700 Subject: Does anyone know Jared's birthday? Message-ID: Yup, I did think it was worth asking the entire list. W From bmanning at isi.edu Wed Jun 4 19:19:21 2014 From: bmanning at isi.edu (manning bill) Date: Wed, 4 Jun 2014 12:19:21 -0700 Subject: Does anyone know Jared's birthday? In-Reply-To: References: Message-ID: did you ask Jared? /bill Neca eos omnes. Deus suos agnoscet. On 4June2014Wednesday, at 12:15, Warren Kumari wrote: > Yup, I did think it was worth asking the entire list. > > W From warren at kumari.net Wed Jun 4 19:24:36 2014 From: warren at kumari.net (Warren Kumari) Date: Wed, 4 Jun 2014 12:24:36 -0700 Subject: Does anyone know Jared's birthday? In-Reply-To: References: Message-ID: On Wednesday, June 4, 2014, manning bill wrote: > did you ask Jared? > > Yup. And he updated it on Facebook to throw us off the scent... W > /bill > Neca eos omnes. Deus suos agnoscet. > > On 4June2014Wednesday, at 12:15, Warren Kumari > wrote: > > > Yup, I did think it was worth asking the entire list. > > > > W > > From Brian_Field at cable.comcast.com Wed Jun 4 21:16:02 2014 From: Brian_Field at cable.comcast.com (Field, Brian) Date: Wed, 4 Jun 2014 21:16:02 +0000 Subject: HOpen-- hybrid-open router architecture prezo Message-ID: Folks, Not sure what happened re the wrong slides for my talk today. The NANOG folks have indicated that the right set of slides for my talk today will be up on the NANOG web site in the next week or so. Until then, I’ve put them on dropbox for folks who might be interested in accessing the material in the near term: https://www.dropbox.com/s/9q5muh23ru5cwda/HOpen%20arch%20and%20vision%20NANOG%20june%202014%20--%205-30-2014%20v004.pdf Feel free to ping with questions, comments, etc. Thanks Brian From brunner at nic-naa.net Wed Jun 4 22:19:01 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 04 Jun 2014 15:19:01 -0700 Subject: AmazonAWS contact Message-ID: <538F9B55.9030807@nic-naa.net> Could someone from Amazon Web Services contact me off list? I'm getting root login attempts from one of your assets and abuse@ hasn't been responsive today. Tia, Eric From bmanning at isi.edu Wed Jun 4 22:30:03 2014 From: bmanning at isi.edu (manning bill) Date: Wed, 4 Jun 2014 15:30:03 -0700 Subject: Does anyone know Jared's birthday? In-Reply-To: References: Message-ID: well then. you could just use that date then and it should be alright… /bill Neca eos omnes. Deus suos agnoscet. On 4June2014Wednesday, at 12:24, Warren Kumari wrote: > > > On Wednesday, June 4, 2014, manning bill wrote: > did you ask Jared? > > > Yup. > > And he updated it on Facebook to throw us off the scent... > > W > > > /bill > Neca eos omnes. Deus suos agnoscet. > > On 4June2014Wednesday, at 12:15, Warren Kumari wrote: > > > Yup, I did think it was worth asking the entire list. > > > > W > From nanog at hostleasing.net Wed Jun 4 22:35:22 2014 From: nanog at hostleasing.net (Randy Epstein) Date: Wed, 04 Jun 2014 18:35:22 -0400 Subject: Does anyone know Jared's birthday? In-Reply-To: References: Message-ID: Jared Mauch? July 23rd. Randy On 6/4/14, 6:30 PM, "manning bill" wrote: >well then. you could just use that date then and it should be alrightŠ > >/bill >Neca eos omnes. Deus suos agnoscet. > >On 4June2014Wednesday, at 12:24, Warren Kumari wrote: > >> >> >> On Wednesday, June 4, 2014, manning bill wrote: >> did you ask Jared? >> >> >> Yup. >> >> And he updated it on Facebook to throw us off the scent... >> >> W >> >> >> /bill >> Neca eos omnes. Deus suos agnoscet. >> >> On 4June2014Wednesday, at 12:15, Warren Kumari >>wrote: >> >> > Yup, I did think it was worth asking the entire list. >> > >> > W >> > From pawel.rybczyk at border6.com Wed Jun 4 15:05:05 2014 From: pawel.rybczyk at border6.com (Pawel Rybczyk) Date: Wed, 04 Jun 2014 17:05:05 +0200 Subject: real-time traffic engineering/management solutions In-Reply-To: <538F2493.4090206@forthnet.gr> References: <538F2493.4090206@forthnet.gr> Message-ID: <538F35A1.4050302@border6.com> Hi Tassos, My name is Pawel and I represent Border 6. We develop a traffic engineering platform for real-time route optimization and reporting on top of BGP. Our main use case is optimizing transits and IX connectivity. Do not hesitate to contact me directly for more details, or provide me your phone number - I'll be happy to call you at your convenience. Pawel Rybczyk pawel.rybczyk at border6.com www.border6.com office: +48 22 242 89 51 ext. 103 mobile: +48 664 300 375 On 06/04/2014 03:52 PM, Tassos Chatzithomaoglou wrote: > I'm having a look at real-time traffic engineering/management solutions that include visibility/analysis/control and offer the following basic characteristics: > > 1) take into account > > * links utilization/threshold/deviation > * link price > * packet delay/loss > * physical/logical topology > > > 2) and offer real-time automatic ingress/egress traffic adjustment using > > * netconf & bgp to change localpref/med/aspath/community attributes (mandatory) > * SDN/Openflow/I2RS/PCEP technologies (optional) > > > 3) considering only IP traffic (MPLS can be optional), especially on external links used for peering and transit by tier-1/2 providers. > > Do you have any personal experience regarding the above features? > > From my personal search Cisco offers Quantum/WAE (inc MATE) which seem very limited in real-time functionality and Huawei offers RR+ which seems interesting but unknown to many people (and maybe not compatible with all vendor routers). > > Any other idea or commercial option? Offline answers would be good too. > > > -- > Tassos > -------------- next part -------------- A non-text attachment was scrubbed... Name: pawel_rybczyk.vcf Type: text/x-vcard Size: 296 bytes Desc: not available URL: From mpalmer at hezmatt.org Wed Jun 4 23:11:29 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 5 Jun 2014 09:11:29 +1000 Subject: AmazonAWS contact In-Reply-To: <538F9B55.9030807@nic-naa.net> References: <538F9B55.9030807@nic-naa.net> Message-ID: <20140604231129.GJ32039@hezmatt.org> On Wed, Jun 04, 2014 at 03:19:01PM -0700, Eric Brunner-Williams wrote: > Could someone from Amazon Web Services contact me off list? I'm getting > root login attempts from one of your assets You and the rest of the Internet. Who would have thought that giving anything[1] than can scrape up a valid CC number 20 machines, a phat pipe, and ever-changing IP addresses would be an invitation to abuse? - Matt [1] If nobody has written automation to take stolen CC numbers directly from carder forums, open accounts with them on AWS, and then do their worstest until they get shut down, I'll be very surprised. -- If you are a trauma surgeon and someone dies on your table, [...] everyone would know you "did your best". When someone does something truly stupid with their system and it dies and you can't resuscitate it, you must be incompetent or an idiot. -- Julian Macassey, in the Monastery From mpetach at netflight.com Wed Jun 4 23:13:20 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 4 Jun 2014 16:13:20 -0700 Subject: 2014.06.04 NANOG61 day 3 notes Message-ID: Morning and afternoon notes are both up at http://nanog.cluepon.net/index.php/NANOG61morn4 and http://nanog.cluepon.net/index.php/NANOG61aft4 been another action-packed (well, meeting-packed) day, so apologies for the updates having to wait until the end of the day like this. Awesome conference--huge kudos to everyone who made this a success. Thank you--you totally rock! Matt From chaim.rieger at gmail.com Wed Jun 4 23:21:46 2014 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 04 Jun 2014 16:21:46 -0700 Subject: Does anyone know Jared's birthday? In-Reply-To: References: Message-ID: Jared wasn't born, he just became.. therefore no birthday applies On June 4, 2014 12:15:47 PM PDT, Warren Kumari wrote: >Yup, I did think it was worth asking the entire list. > >W -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From richard at pedantictheory.com Wed Jun 4 23:40:04 2014 From: richard at pedantictheory.com (Richard Porter) Date: Wed, 4 Jun 2014 16:40:04 -0700 Subject: Does anyone know Jared's birthday? In-Reply-To: References: Message-ID: <3BB32697-8E5C-4F88-B8FF-F8BFE3683AEC@pedantictheory.com> I do not claim to know Jared but suggest that on this list? He was not born, perhaps routed into existence? (please direct all boos, hisses and flames for that bad pun right at me :) On Jun 4, 2014, at 4:21 PM, Chaim Rieger wrote: > Jared wasn't born, he just became.. therefore no birthday applies > > On June 4, 2014 12:15:47 PM PDT, Warren Kumari wrote: >> Yup, I did think it was worth asking the entire list. >> >> W > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From surfer at mauigateway.com Thu Jun 5 01:09:08 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 4 Jun 2014 18:09:08 -0700 Subject: Does anyone know Jared's birthday? Message-ID: <20140604180908.4B95A42A@m0048141.ppops.net> > On June 4, 2014 12:15:47 PM PDT, Warren Kumari wrote: >> Yup, I did think it was worth asking the entire list. He has got to be cringing right about now... ;-) scott From jason at biel-tech.com Thu Jun 5 01:12:11 2014 From: jason at biel-tech.com (Jason Biel) Date: Wed, 4 Jun 2014 20:12:11 -0500 Subject: Does anyone know Jared's birthday? In-Reply-To: <20140604180908.4B95A42A@m0048141.ppops.net> References: <20140604180908.4B95A42A@m0048141.ppops.net> Message-ID: He went to Jared?? On Wed, Jun 4, 2014 at 8:09 PM, Scott Weeks wrote: > > > > > On June 4, 2014 12:15:47 PM PDT, Warren Kumari > wrote: > >> Yup, I did think it was worth asking the entire list. > > > He has got to be cringing right about now... ;-) > > scott > -- Jason From lists at mrqueue.com Thu Jun 5 01:26:29 2014 From: lists at mrqueue.com (Mr. Queue) Date: Wed, 04 Jun 2014 20:26:29 -0500 Subject: Does anyone know Jared's birthday? In-Reply-To: References: Message-ID: <538FC745.20508@mrqueue.com> On 6/4/2014 2:15 PM, Warren Kumari wrote: > Yup, I did think it was worth asking the entire list. Week from today, or when the time is appropriate could someone fill us in? Off list is fine. From jay at west.net Thu Jun 5 01:40:06 2014 From: jay at west.net (Jay Hennigan) Date: Wed, 04 Jun 2014 18:40:06 -0700 Subject: Does anyone know Jared's birthday? In-Reply-To: <538FC745.20508@mrqueue.com> References: <538FC745.20508@mrqueue.com> Message-ID: <538FCA76.9010902@west.net> Is someone going to bake him a cake? The last NANOG cake I remember was this one. Quite delicious, too. http://www.datacenterknowledge.com/wp-content/uploads/2009/10/Hurricane-Cake.jpg From rdrake at direcpath.com Thu Jun 5 03:25:55 2014 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 4 Jun 2014 23:25:55 -0400 Subject: ipmi access In-Reply-To: <538CB795.80404@gameservers.com> References: <538CA303.4090900@ispn.net> <538CB51F.6050506@inblock.ru> <538CB795.80404@gameservers.com> Message-ID: <538FE343.4080702@direcpath.com> On 6/2/2014 1:42 PM, Brian Rak wrote: > They do publish it. The problem is, it's not documented, and it takes > a bunch of work to get into a usable state. See > ftp://ftp.supermicro.com/GPL/SMT/SDK_SMT_X9_317.tar.gz > > Plus, the firmware environment is pretty hostile. If you flash some > bad firmware, your only option is to desolder the IPMI flash chip and > program it externally. It cannot be reprogrammed in circuit, and > there's no recovery method. There is a market here for first or third parties to make money, or for open source people to hack a new firmware into existence. Since HP charges a yearly license fee for their ILO, it should remain secured until they stop support for that platform. People would probably revolt if supermicro started charging for something that has been free though. The ideal situation would be if they continued to provide what they do for free and upsold some extra features. Maybe the ability to group manage thousands of boxes, but you can already pretty much do that with the CLI impi tools. It's unfortunate that free means complete security nightmare. From jared at puck.nether.net Thu Jun 5 03:29:47 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 4 Jun 2014 20:29:47 -0700 Subject: Does anyone know Jared's birthday? In-Reply-To: <538FC745.20508@mrqueue.com> References: <538FC745.20508@mrqueue.com> Message-ID: The answers you want are: 1) it was not worth the whole list 2) warren wants to hassle me on my birthday at IETF. If you are there, please do say hello in person. Everyone else, sorry for the noise and hope you are entertained. Jared Mauch > On Jun 4, 2014, at 6:26 PM, "Mr. Queue" wrote: > >> On 6/4/2014 2:15 PM, Warren Kumari wrote: >> Yup, I did think it was worth asking the entire list. > > Week from today, or when the time is appropriate could someone fill us > in? Off list is fine. From LarrySheldon at cox.net Thu Jun 5 03:49:02 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 04 Jun 2014 22:49:02 -0500 Subject: Does anyone know Jared's birthday? In-Reply-To: References: <538FC745.20508@mrqueue.com> Message-ID: <538FE8AE.6060203@cox.net> On 6/4/2014 10:29 PM, Jared Mauch wrote: > The answers you want are: > > 1) it was not worth the whole list > 2) warren wants to hassle me on my birthday at IETF. If you are there, please do say hello in person. > > Everyone else, sorry for the noise and hope you are entertained. %^) -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From surfer at mauigateway.com Thu Jun 5 04:27:26 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 4 Jun 2014 21:27:26 -0700 Subject: Does anyone know Jared's birthday? Message-ID: <20140604212726.4B95BE4E@m0048141.ppops.net> --- jared at puck.nether.net wrote: From: Jared Mauch ...hope you are entertained. ---------------------------------------- Yes. :-) scott From achatz at forthnet.gr Thu Jun 5 09:45:41 2014 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 05 Jun 2014 12:45:41 +0300 Subject: real-time traffic engineering/management solutions In-Reply-To: <538F2493.4090206@forthnet.gr> References: <538F2493.4090206@forthnet.gr> Message-ID: <53903C45.9060605@forthnet.gr> From richard at bennett.com Fri Jun 6 17:29:30 2014 From: richard at bennett.com (richard at bennett.com) Date: Fri, 6 Jun 2014 17:29:30 +0000 (UTC) Subject: richard@bennett.com has shared Cable companies astroturfing support against FCC Title II regulation | Electronista Message-ID: <845831298.6687.1402075770367.JavaMail.share@slave-134.wh.gwallet.com> Cable companies astroturfing support against FCC Title II regulation | Electronista http://www.electronista.com/articles/14/06/06/one.group.hired.known.false.grassroots.campaign.generator.to.sink.measure/#sUBFuKpvB3FAOPyL.03 --- richard at bennett.com shared this using Po.st: http://www.po.st From cscora at apnic.net Fri Jun 6 18:10:15 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Jun 2014 04:10:15 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201406061810.s56IAFnu015720@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, LacNOG, TRNOG, 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 07 Jun, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 397690 Prefixes after maximum aggregation: 149932 Deaggregation factor: 2.65 Unique aggregates announced to Internet: 198863 Total ASes present in the Internet Routing Table: 41820 Prefixes per ASN: 9.51 Origin-only ASes present in the Internet Routing Table: 31178 Origin ASes announcing only one prefix: 15269 Transit ASes present in the Internet Routing Table: 5744 Transit-only ASes present in the Internet Routing Table: 375 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1355 Unregistered ASNs in the Routing Table: 357 Number of 32-bit ASNs allocated by the RIRs: 6795 Number of 32-bit ASNs visible in the Routing Table: 4898 Prefixes from 32-bit ASNs in the Routing Table: 16497 Number of bogon 32-bit ASNs visible in the Routing Table: 189 Special use prefixes present in the Routing Table: 13 Prefixes being announced from unallocated address space: 292 Number of addresses announced to Internet: 2359161540 Equivalent to 140 /8s, 157 /16s and 242 /24s Percentage of available address space announced: 63.7 Percentage of allocated address space announced: 63.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.6 Total number of prefixes smaller than registry allocations: 146784 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 76674 Total APNIC prefixes after maximum aggregation: 19223 APNIC Deaggregation factor: 3.99 Prefixes being announced from the APNIC address blocks: 79129 Unique aggregates announced from the APNIC address blocks: 31503 APNIC Region origin ASes present in the Internet Routing Table: 3334 APNIC Prefixes per ASN: 23.73 APNIC Region origin ASes announcing only one prefix: 877 APNIC Region transit ASes present in the Internet Routing Table: 744 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 19 Number of APNIC region 32-bit ASNs visible in the Routing Table: 902 Number of APNIC addresses announced to Internet: 578465088 Equivalent to 34 /8s, 122 /16s and 173 /24s Percentage of available APNIC address space announced: 67.6 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-63999, 131072-133631 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: 127334 Total ARIN prefixes after maximum aggregation: 61196 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 128625 Unique aggregates announced from the ARIN address blocks: 60916 ARIN Region origin ASes present in the Internet Routing Table: 13478 ARIN Prefixes per ASN: 9.54 ARIN Region origin ASes announcing only one prefix: 5586 ARIN Region transit ASes present in the Internet Routing Table: 1517 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 19 Number of ARIN region 32-bit ASNs visible in the Routing Table: 98 Number of ARIN addresses announced to Internet: 952701696 Equivalent to 56 /8s, 201 /16s and 19 /24s Percentage of available ARIN address space announced: 50.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, 393216-394239 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: 111757 Total RIPE prefixes after maximum aggregation: 57339 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 116566 Unique aggregates announced from the RIPE address blocks: 74504 RIPE Region origin ASes present in the Internet Routing Table: 16937 RIPE Prefixes per ASN: 6.88 RIPE Region origin ASes announcing only one prefix: 8090 RIPE Region transit ASes present in the Internet Routing Table: 2817 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2663 Number of RIPE addresses announced to Internet: 610071428 Equivalent to 36 /8s, 92 /16s and 243 /24s Percentage of available RIPE address space announced: 88.7 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-202239 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: 53757 Total LACNIC prefixes after maximum aggregation: 9603 LACNIC Deaggregation factor: 5.60 Prefixes being announced from the LACNIC address blocks: 60731 Unique aggregates announced from the LACNIC address blocks: 27436 LACNIC Region origin ASes present in the Internet Routing Table: 2069 LACNIC Prefixes per ASN: 29.35 LACNIC Region origin ASes announcing only one prefix: 511 LACNIC Region transit ASes present in the Internet Routing Table: 435 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1200 Number of LACNIC addresses announced to Internet: 159177472 Equivalent to 9 /8s, 124 /16s and 219 /24s Percentage of available LACNIC address space announced: 94.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 11622 Total AfriNIC prefixes after maximum aggregation: 2549 AfriNIC Deaggregation factor: 4.56 Prefixes being announced from the AfriNIC address blocks: 12347 Unique aggregates announced from the AfriNIC address blocks: 4244 AfriNIC Region origin ASes present in the Internet Routing Table: 711 AfriNIC Prefixes per ASN: 17.37 AfriNIC Region origin ASes announcing only one prefix: 205 AfriNIC Region transit ASes present in the Internet Routing Table: 149 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 35 Number of AfriNIC addresses announced to Internet: 56136448 Equivalent to 3 /8s, 88 /16s and 147 /24s Percentage of available AfriNIC address space announced: 55.8 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 17974 2532 876 67 PT Telekomunikasi Indonesia 7545 1673 227 28 TPG Telecom Limited 9829 1591 1275 30 National Internet Backbone 4755 1342 315 125 TATA Communications formerly 4766 1191 8538 584 Korea Telecom 7552 1189 1082 12 Viettel Corporation 9498 1149 281 66 BHARTI Airtel Ltd. 24560 1133 395 170 Bharti Airtel Ltd., Telemedia 4788 839 466 39 TM Net, Internet Service Prov 4808 814 1673 216 CNCGROUP IP network China169 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 6389 2462 3474 43 BellSouth.net Inc. 22773 2457 2914 97 Cox Communications Inc. 18566 1901 367 148 MegaPath Corporation 20115 1693 1686 561 Charter Communications 30036 1417 310 543 Mediacom Communications Corp 701 1312 9248 633 MCI Communications Services, 11492 1210 218 407 CABLE ONE, INC. 1785 1207 402 80 PaeTec Communications, Inc. 7011 1086 287 657 Frontier Communications of Am 22394 1048 5254 296 Cellco Partnership DBA Verizo 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 8402 1390 540 15 OJSC "Vimpelcom" 20940 1371 532 1015 Akamai International B.V. 34984 1230 195 146 TELLCOM ILETISIM HIZMETLERI A 13188 1031 100 28 TOV "Bank-Inform" 31148 969 43 18 Freenet Ltd. 8551 923 349 36 Bezeq International-Ltd 6849 795 351 24 JSC "Ukrtelecom" 12479 707 786 51 France Telecom Espana SA 6830 608 2116 376 Liberty Global Operations B.V 9198 579 344 28 JSC Kazakhtelecom 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 28573 3811 2015 98 NET Servi�os de Comunica��o S 10620 2828 458 198 Telmex Colombia S.A. 18881 2034 1036 22 Global Village Telecom 7303 1700 1145 230 Telecom Argentina S.A. 8151 1388 2945 394 Uninet S.A. de C.V. 6503 1079 430 59 Axtel, S.A.B. de C.V. 7738 979 1882 41 Telemar Norte Leste S.A. 26615 862 2325 35 Tim Celular S.A. 27947 831 125 46 Telconet S.A 3816 793 322 131 COLOMBIA TELECOMUNICACIONES S 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 36998 1114 240 6 Sudanese Mobile Telephone (ZA 24863 923 276 24 Link Egypt (Link.NET) 6713 632 719 32 Office National des Postes et 8452 580 954 11 TE-AS 24835 290 140 8 Vodafone Data 36992 272 735 19 ETISALAT MISR 3741 246 920 207 Internet Solutions 37054 240 19 6 Data Telecom Service 29571 201 20 15 Cote d'Ivoire Telecom 12258 176 27 67 MWEB CONNECT (PROPRIETARY) LI 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 28573 3811 2015 98 NET Servi�os de Comunica��o S 10620 2828 458 198 Telmex Colombia S.A. 17974 2532 876 67 PT Telekomunikasi Indonesia 6389 2462 3474 43 BellSouth.net Inc. 22773 2457 2914 97 Cox Communications Inc. 18881 2034 1036 22 Global Village Telecom 18566 1901 367 148 MegaPath Corporation 7303 1700 1145 230 Telecom Argentina S.A. 20115 1693 1686 561 Charter Communications 7545 1673 227 28 TPG Telecom Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 2828 2630 Telmex Colombia S.A. 17974 2532 2465 PT Telekomunikasi Indonesia 6389 2462 2419 BellSouth.net Inc. 22773 2457 2360 Cox Communications Inc. 18881 2034 2012 Global Village Telecom 18566 1901 1753 MegaPath Corporation 7545 1673 1645 TPG Telecom Limited 9829 1591 1561 National Internet Backbone 7303 1700 1470 Telecom Argentina S.A. 8402 1390 1375 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 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 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications 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.88.0.0/16 6697 Republican Unitary Telecommun 100.89.0.0/16 6697 Republican Unitary Telecommun 100.90.0.0/16 6697 Republican Unitary Telecommun 100.91.0.0/16 6697 Republican Unitary Telecommun 100.92.0.0/16 6697 Republican Unitary Telecommun 100.93.0.0/16 6697 Republican Unitary Telecommun 100.94.0.0/16 6697 Republican Unitary Telecommun 100.95.0.0/16 6697 Republican Unitary Telecommun 100.96.0.0/14 6697 Republican Unitary Telecommun 100.104.0.0/13 6697 Republican Unitary Telecommun Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.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:15 /9:11 /10:27 /11:83 /12:240 /13:436 /14:869 /15:1497 /16:11451 /17:5877 /18:9665 /19:19267 /20:28782 /21:31717 /22:45168 /23:38639 /24:202510 /25:492 /26:652 /27:254 /28:11 /29:12 /30:5 /31:1 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 1863 1901 MegaPath Corporation 22773 1750 2457 Cox Communications Inc. 6389 1427 2462 BellSouth.net Inc. 30036 1256 1417 Mediacom Communications Corp 11492 1175 1210 CABLE ONE, INC. 8402 1090 1390 OJSC "Vimpelcom" 36998 1080 1114 Sudanese Mobile Telephone (ZA 10620 991 2828 Telmex Colombia S.A. 28573 957 3811 NET Servi�os de Comunica��o S 31148 914 969 Freenet Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1130 2:664 3:3 4:15 5:951 6:19 8:702 12:1843 13:3 14:1012 15:13 16:2 17:35 18:21 20:39 23:872 24:1745 25:1 27:1769 31:1503 32:43 33:2 34:5 36:138 37:1588 38:950 39:7 40:204 41:3235 42:256 43:29 44:11 45:1 46:2081 47:22 49:702 50:940 52:12 54:48 55:5 57:28 58:1225 59:605 60:411 61:1549 62:1251 63:1953 64:4360 65:2293 66:4171 67:2060 68:1057 69:3344 70:858 71:436 72:2019 74:2649 75:325 76:404 77:1701 78:854 79:708 80:1296 81:1150 82:753 83:759 84:732 85:1312 86:461 87:1178 88:486 89:1834 90:141 91:5670 92:697 93:1756 94:2040 95:1540 96:524 97:362 98:1083 99:49 100:53 101:815 103:5028 104:2 105:542 106:170 107:625 108:588 109:2038 110:974 111:1305 112:662 113:840 114:865 115:1127 116:1104 117:945 118:1411 119:1379 120:386 121:824 122:2039 123:1334 124:1436 125:1464 128:569 129:345 130:348 131:664 132:407 133:163 134:320 135:74 136:260 137:267 138:357 139:167 140:215 141:380 142:569 143:430 144:510 145:104 146:630 147:475 148:912 149:363 150:169 151:711 152:438 153:219 154:298 155:492 156:342 157:336 158:244 159:901 160:327 161:556 162:1505 163:244 164:690 165:605 166:279 167:628 168:1055 169:124 170:1436 171:188 172:19 173:1610 174:699 175:603 176:1391 177:3129 178:2027 179:656 180:1767 181:1146 182:1575 183:525 184:721 185:1730 186:2868 187:1574 188:2008 189:1454 190:7513 191:352 192:7314 193:5501 194:4014 195:3511 196:1401 197:657 198:5073 199:5500 200:6278 201:917 End of report From jra at baylink.com Fri Jun 6 21:31:03 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 6 Jun 2014 17:31:03 -0400 (EDT) Subject: NTIA cedes root zone control Message-ID: <27314139.3188.1402090263001.JavaMail.root@benjamin.baylink.com> In one of the worst written stories I've ever seen in Ars, it's announced that -- in one of the best take-out-the-trash moments in Internet history (make the announcement not only on a Friday, but *during a NANOG*) -- NTIA is ceding control of the root DNS zone. The article very carefully does not say *to whom*; though it implies that it's ICANN. If that's the case, then I'm not sure there's actually, y'know, *news* here. But... http://arstechnica.com/tech-policy/2014/03/in-sudden-announcement-us-to-give-up-control-of-dns-root-zone/ 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 rwebb at ropeguru.com Fri Jun 6 21:50:11 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Fri, 06 Jun 2014 17:50:11 -0400 Subject: NTIA cedes root zone control In-Reply-To: <27314139.3188.1402090263001.JavaMail.root@benjamin.baylink.com> References: <27314139.3188.1402090263001.JavaMail.root@benjamin.baylink.com> Message-ID: <53923793.4030102@ropeguru.com> Why is that dated Mar ch 14, 2014?? Robert On 06/06/2014 05:31 PM, Jay Ashworth wrote: > In one of the worst written stories I've ever seen in Ars, it's announced > that -- in one of the best take-out-the-trash moments in Internet history > (make the announcement not only on a Friday, but *during a NANOG*) -- NTIA > is ceding control of the root DNS zone. > > The article very carefully does not say *to whom*; though it implies that > it's ICANN. > > If that's the case, then I'm not sure there's actually, y'know, *news* > here. But... > > http://arstechnica.com/tech-policy/2014/03/in-sudden-announcement-us-to-give-up-control-of-dns-root-zone/ > > Cheers, > -- jra > From jra at baylink.com Fri Jun 6 21:54:16 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 6 Jun 2014 17:54:16 -0400 (EDT) Subject: NTIA cedes root zone control In-Reply-To: <53923793.4030102@ropeguru.com> Message-ID: <27895376.3388.1402091656737.JavaMail.root@benjamin.baylink.com> Well, crap. My apologies, all, for not checking the damn dateline; I won't tell you what popped that story up in front of me, cause I'd be too embarrassed. And I don't think BCP38 was gonna help me here. :-} Have a nice weekend... ----- Original Message ----- > From: "Robert Webb" > To: "Jay Ashworth" , "NANOG" > Sent: Friday, June 6, 2014 5:50:11 PM > Subject: Re: NTIA cedes root zone control > Why is that dated Mar ch 14, 2014?? > > Robert > > On 06/06/2014 05:31 PM, Jay Ashworth wrote: > > In one of the worst written stories I've ever seen in Ars, it's > > announced > > that -- in one of the best take-out-the-trash moments in Internet > > history > > (make the announcement not only on a Friday, but *during a NANOG*) > > -- NTIA > > is ceding control of the root DNS zone. > > > > The article very carefully does not say *to whom*; though it implies > > that > > it's ICANN. > > > > If that's the case, then I'm not sure there's actually, y'know, > > *news* > > here. But... > > > > http://arstechnica.com/tech-policy/2014/03/in-sudden-announcement-us-to-give-up-control-of-dns-root-zone/ > > > > 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 cidr-report at potaroo.net Fri Jun 6 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Jun 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201406062200.s56M00SM096661@wattle.apnic.net> This report has been generated at Fri Jun 6 21:13:56 2014 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 30-05-14 502889 283047 31-05-14 502961 283069 01-06-14 502836 283134 02-06-14 502943 283080 03-06-14 502793 283382 04-06-14 503177 282897 05-06-14 503436 283062 06-06-14 503988 282999 AS Summary 47312 Number of ASes in routing system 19226 Number of ASes announcing only one prefix 3785 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120305408 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'). --- 06Jun14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 504288 282992 221296 43.9% All ASes AS28573 3785 164 3621 95.7% NET Servi�os de Comunica��o S.A.,BR AS6389 2956 72 2884 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2795 248 2547 91.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2938 931 2007 68.3% KIXS-AS-KR Korea Telecom,KR AS18881 2034 39 1995 98.1% Global Village Telecom,BR AS1785 2198 474 1724 78.4% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2871 1378 1493 52.0% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS7303 1769 443 1326 75.0% Telecom Argentina S.A.,AR AS4755 1857 585 1272 68.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4323 1643 426 1217 74.1% TWTC - tw telecom holdings, inc.,US AS7545 2258 1060 1198 53.1% TPG-INTERNET-AP TPG Telecom Limited,AU AS22773 2517 1395 1122 44.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS7552 1259 163 1096 87.1% VIETEL-AS-AP Viettel Corporation,VN AS36998 1114 37 1077 96.7% SDN-MOBITEL,SD AS22561 1308 241 1067 81.6% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1339 307 1032 77.1% ITCDELTA - Earthlink, Inc.,US AS9829 1645 710 935 56.8% BSNL-NIB National Internet Backbone,IN AS4788 1060 149 911 85.9% TMNET-AS-AP TM Net, Internet Service Provider,MY AS9808 1004 156 848 84.5% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS24560 1158 333 825 71.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4808 1222 404 818 66.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS7738 979 189 790 80.7% Telemar Norte Leste S.A.,BR AS18101 942 186 756 80.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS26615 863 109 754 87.4% Tim Celular S.A.,BR AS8151 1422 680 742 52.2% Uninet S.A. de C.V.,MX AS701 1448 734 714 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS11492 1222 516 706 57.8% CABLEONE - CABLE ONE, INC.,US AS855 760 58 702 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS4780 1033 349 684 66.2% SEEDNET Digital United Inc.,TW Total 51446 13101 38345 74.5% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.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.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -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 43.252.104.0/22 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID 43.252.104.0/24 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID 43.252.105.0/24 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID 43.252.106.0/24 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID 43.252.107.0/24 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -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 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 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 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 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.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -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.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 100.88.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.89.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.90.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.91.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.92.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.93.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.94.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.95.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.96.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.104.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.112.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.120.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.124.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.92.0/22 AS13269 103.18.92.0/24 AS13269 103.18.94.0/24 AS13269 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.23.48.0/24 AS56194 103.23.49.0/24 AS56194 103.23.50.0/24 AS56194 103.23.51.0/24 AS56194 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.249.132.0/22 AS18097 DCN D.C.N. Corporation,JP 104.36.184.0/22 AS4891 FERRI-3 - Ferric Systems, LLC,US 104.36.224.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 104.36.232.0/21 AS54755 DWW-AS - Desert Winds Wireless Inc,US 104.36.240.0/21 AS23175 POGOZONE - PogoZone,US 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 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 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 148.163.0.0/18 AS53755 IOFLOOD - Input Output Flood LLC,US 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 173.213.208.0/22 AS54040 -Reserved AS-,ZZ 173.213.212.0/24 AS54040 -Reserved AS-,ZZ 173.213.213.0/24 AS54040 -Reserved AS-,ZZ 173.213.214.0/23 AS54040 -Reserved AS-,ZZ 173.213.216.0/21 AS54040 -Reserved AS-,ZZ 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 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.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,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.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,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.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,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 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 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.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 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.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 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.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 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.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT 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 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 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.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 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.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech 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.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.146.36.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 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.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 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.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 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 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 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.192.0/20 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.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 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.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 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 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 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 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.9.40.0/24 AS56194 202.9.41.0/24 AS56194 202.9.42.0/24 AS56194 202.9.43.0/24 AS56194 202.9.44.0/24 AS56194 202.9.45.0/24 AS56194 202.9.46.0/24 AS56194 202.9.47.0/24 AS56194 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 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.10.94.0/23 AS30097 NUWAVE - NuWave,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.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 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.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,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.128.0/24 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.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.73.112.0/24 AS19231 -Reserved AS-,ZZ 208.73.113.0/24 AS19231 -Reserved AS-,ZZ 208.73.114.0/24 AS19231 -Reserved AS-,ZZ 208.73.115.0/24 AS19231 -Reserved AS-,ZZ 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.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 209.17.224.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.225.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.226.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.227.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.228.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.229.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.230.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.231.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.232.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.233.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.234.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.235.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.236.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.237.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.238.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.239.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.240.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.241.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.242.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.243.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.244.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.245.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.246.0/24 AS14846 CGNOGE - NBC Internet,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,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 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,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.178.96.0/21 AS17035 -Reserved AS-,ZZ 216.178.104.0/21 AS17035 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 Jun 6 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Jun 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201406062200.s56M02GL096675@wattle.apnic.net> BGP Update Report Interval: 29-May-14 -to- 05-Jun-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 127640 5.5% 75.2 -- BSNL-NIB National Internet Backbone,IN 2 - AS8402 42898 1.8% 93.1 -- CORBINA-AS OJSC "Vimpelcom",RU 3 - AS23752 25027 1.1% 305.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - AS28573 24975 1.1% 11.6 -- NET Servi�os de Comunica��o S.A.,BR 5 - AS7579 22331 0.9% 181.6 -- INTERNEX-AS-AP InterNex Australia Pty Ltd,AU 6 - AS41691 20675 0.9% 1033.8 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 7 - AS18025 20474 0.9% 455.0 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network,PH 8 - AS45899 18345 0.8% 51.4 -- VNPT-AS-VN VNPT Corp,VN 9 - AS24863 16914 0.7% 19.8 -- LINKdotNET-AS,EG 10 - AS6713 16195 0.7% 39.6 -- IAM-AS,MA 11 - AS9155 15919 0.7% 48.4 -- QNET QualityNet General Trading & Contracting Co.,KW 12 - AS26615 15530 0.7% 22.7 -- Tim Celular S.A.,BR 13 - AS4775 15442 0.7% 214.5 -- GLOBE-TELECOM-AS Globe Telecoms,PH 14 - AS8452 14355 0.6% 20.0 -- TE-AS TE-AS,EG 15 - AS18403 14272 0.6% 28.6 -- FPT-AS-AP The Corporation for Financing & Promoting Technology,VN 16 - AS14287 13368 0.6% 1909.7 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 17 - AS31148 12110 0.5% 11.9 -- FREENET-AS Freenet Ltd.,UA 18 - AS45464 11734 0.5% 434.6 -- NEXTWEB-AS-AP Room 201, TGU Bldg,PH 19 - AS14259 11361 0.5% 1262.3 -- Gtd Internet S.A.,CL 20 - AS647 10994 0.5% 79.7 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS60345 5597 0.2% 2798.5 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 2 - AS45590 2539 0.1% 2539.0 -- HGCINTNET-AS-AP Hutch Connect,HK 3 - AS14287 13368 0.6% 1909.7 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 4 - AS18135 8858 0.4% 1771.6 -- BTV BTV Cable television,JP 5 - AS54465 7926 0.3% 1585.2 -- QPM-AS-1 - QuickPlay Media Inc.,US 6 - AS14259 11361 0.5% 1262.3 -- Gtd Internet S.A.,CL 7 - AS20943 1133 0.1% 1133.0 -- NETNOD-LUL NETNOD Internet Exchange i Sverige AB,SE 8 - AS2167 5656 0.2% 1131.2 -- HPES - Hewlett-Packard Company,US 9 - AS41691 20675 0.9% 1033.8 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 10 - AS3 871 0.0% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 11 - AS26661 3113 0.1% 778.2 -- JCPS-ASN - Jeffco Public Schools,US 12 - AS48068 774 0.0% 774.0 -- VISONIC Visonic Ltd,IL 13 - AS33076 768 0.0% 768.0 -- ISC-F-AS - Internet Systems Consortium, Inc.,US 14 - AS37447 2917 0.1% 729.2 -- OASIS-SPRL,CD 15 - AS2 1282 0.1% 691.0 -- UDEL-DCN - University of Delaware,US 16 - AS40632 594 0.0% 594.0 -- FGLIFE-COLO1 - Fidelity & Guaranty Life,US 17 - AS47451 563 0.0% 563.0 -- DOMEN D.O.O."Domen" Drustvo za Proizvodnju,Promet i Usluge - Podgorica,ME 18 - AS37609 2775 0.1% 555.0 -- ROKETELKOM-AS,CD 19 - AS8382 528 0.0% 528.0 -- IRTEL-AS OJSC Rostelecom,RU 20 - AS52879 4437 0.2% 493.0 -- ABM INFORMATICA E TELECOM,BR TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 20338 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 202.70.64.0/21 12031 0.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.88.0/21 11753 0.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 192.58.232.0/24 10745 0.4% AS6629 -- NOAA-AS - NOAA,US 5 - 42.83.48.0/20 8837 0.3% AS18135 -- BTV BTV Cable television,JP 6 - 205.247.12.0/24 8193 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 7 - 206.152.15.0/24 7917 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 8 - 120.28.62.0/24 7723 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 9 - 222.127.0.0/24 7278 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 10 - 177.54.145.0/24 4351 0.2% AS4 -- ISI-AS - University of Southern California,US 11 - 78.109.192.0/20 4311 0.2% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 12 - 84.205.66.0/24 3117 0.1% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC),EU 13 - 5.160.10.0/24 2804 0.1% AS60345 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 14 - 78.158.184.0/24 2793 0.1% AS60345 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 15 - 208.78.116.0/22 2678 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 16 - 208.73.244.0/22 2678 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 17 - 216.162.0.0/20 2673 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 18 - 208.88.232.0/22 2665 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 19 - 208.70.20.0/22 2664 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 20 - 197.157.211.0/24 2586 0.1% AS37447 -- OASIS-SPRL,CD 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 bmanning at isi.edu Fri Jun 6 22:05:37 2014 From: bmanning at isi.edu (manning bill) Date: Fri, 6 Jun 2014 15:05:37 -0700 Subject: NTIA cedes root zone control In-Reply-To: <27314139.3188.1402090263001.JavaMail.root@benjamin.baylink.com> References: <27314139.3188.1402090263001.JavaMail.root@benjamin.baylink.com> Message-ID: <69B947EB-9BCD-471C-AD92-0E022494F987@isi.edu> er… this is no longer news… back in -MAY-… it was: http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions /bill Neca eos omnes. Deus suos agnoscet. On 6June2014Friday, at 14:31, Jay Ashworth wrote: > In one of the worst written stories I've ever seen in Ars, it's announced > that -- in one of the best take-out-the-trash moments in Internet history > (make the announcement not only on a Friday, but *during a NANOG*) -- NTIA > is ceding control of the root DNS zone. > > The article very carefully does not say *to whom*; though it implies that > it's ICANN. > > If that's the case, then I'm not sure there's actually, y'know, *news* > here. But... > > http://arstechnica.com/tech-policy/2014/03/in-sudden-announcement-us-to-give-up-control-of-dns-root-zone/ > > 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 richard at bennett.com Fri Jun 6 22:48:58 2014 From: richard at bennett.com (Richard Bennett) Date: Fri, 06 Jun 2014 15:48:58 -0700 Subject: richard@bennett.com has shared Cable companies astroturfing support against FCC Title II regulation | Electronista In-Reply-To: <845831298.6687.1402075770367.JavaMail.share@slave-134.wh.gwallet.com> References: <845831298.6687.1402075770367.JavaMail.share@slave-134.wh.gwallet.com> Message-ID: <5392455A.8040609@bennett.com> Dear NANOG, I didn't send this. Sorry to disappoint the speculators. Richard On 6/6/14, 10:29 AM, richard at bennett.com wrote: > Cable companies astroturfing support against FCC Title II regulation | Electronista http://www.electronista.com/articles/14/06/06/one.group.hired.known.false.grassroots.campaign.generator.to.sink.measure/#sUBFuKpvB3FAOPyL.03 > --- > richard at bennett.com shared this using Po.st: http://www.po.st -- Richard Bennett Visiting Fellow, American Enterprise Institute Center for Internet, Communications, and Technology Policy Editor, High Tech Forum From patrick at ianai.net Fri Jun 6 23:39:31 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 6 Jun 2014 19:39:31 -0400 Subject: richard@bennett.com has shared Cable companies astroturfing support against FCC Title II regulation | Electronista In-Reply-To: <5392455A.8040609@bennett.com> References: <845831298.6687.1402075770367.JavaMail.share@slave-134.wh.gwallet.com> <5392455A.8040609@bennett.com> Message-ID: <72AC7BF8-B831-4F0B-81BE-BA75C4E85AE0@ianai.net> Any particular reason you wouldn't send such a thing? It is interesting, operationally relevant, and timely. -- TTFN, patrick On Jun 06, 2014, at 18:48 , Richard Bennett wrote: > Dear NANOG, > > I didn't send this. Sorry to disappoint the speculators. > > Richard > > On 6/6/14, 10:29 AM, richard at bennett.com wrote: >> Cable companies astroturfing support against FCC Title II regulation | Electronista http://www.electronista.com/articles/14/06/06/one.group.hired.known.false.grassroots.campaign.generator.to.sink.measure/#sUBFuKpvB3FAOPyL.03 >> --- >> richard at bennett.com shared this using Po.st: http://www.po.st > > -- > Richard Bennett > Visiting Fellow, American Enterprise Institute > Center for Internet, Communications, and Technology Policy > Editor, High Tech Forum > From richard at bennett.com Sat Jun 7 00:03:53 2014 From: richard at bennett.com (Richard Bennett) Date: Fri, 06 Jun 2014 17:03:53 -0700 Subject: richard@bennett.com has shared Cable companies astroturfing support against FCC Title II regulation | Electronista In-Reply-To: <72AC7BF8-B831-4F0B-81BE-BA75C4E85AE0@ianai.net> References: <845831298.6687.1402075770367.JavaMail.share@slave-134.wh.gwallet.com> <5392455A.8040609@bennett.com> <72AC7BF8-B831-4F0B-81BE-BA75C4E85AE0@ianai.net> Message-ID: <539256E9.5010204@bennett.com> Is there any reason you would? On 6/6/14, 4:39 PM, Patrick W. Gilmore wrote: > Any particular reason you wouldn't send such a thing? It is interesting, operationally relevant, and timely. > -- Richard Bennett Visiting Fellow, American Enterprise Institute Center for Internet, Communications, and Technology Policy Editor, High Tech Forum From patrick at ianai.net Sat Jun 7 00:06:44 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 6 Jun 2014 20:06:44 -0400 Subject: richard@bennett.com has shared Cable companies astroturfing support against FCC Title II regulation | Electronista In-Reply-To: <539256E9.5010204@bennett.com> References: <845831298.6687.1402075770367.JavaMail.share@slave-134.wh.gwallet.com> <5392455A.8040609@bennett.com> <72AC7BF8-B831-4F0B-81BE-BA75C4E85AE0@ianai.net> <539256E9.5010204@bennett.com> Message-ID: I believe I listed 3. And there are multiple times I have posted similar items in the past. Just curious about the "speculators" thing. But I think we're off-topic, so apologies to the audience for extra email in their inboxes. I've sent reply-to to my personal address to avoid this blowing up (although I don't know if mailman will respect that). -- TTFN, patrick On Jun 06, 2014, at 20:03 , Richard Bennett wrote: > Is there any reason you would? > > On 6/6/14, 4:39 PM, Patrick W. Gilmore wrote: >> Any particular reason you wouldn't send such a thing? It is interesting, operationally relevant, and timely. >> > > -- > Richard Bennett > Visiting Fellow, American Enterprise Institute > Center for Internet, Communications, and Technology Policy > Editor, High Tech Forum > From richard at bennett.com Sat Jun 7 00:24:47 2014 From: richard at bennett.com (Richard Bennett) Date: Fri, 06 Jun 2014 17:24:47 -0700 Subject: richard@bennett.com has shared Cable companies astroturfing support against FCC Title II regulation | Electronista In-Reply-To: References: <845831298.6687.1402075770367.JavaMail.share@slave-134.wh.gwallet.com> <5392455A.8040609@bennett.com> <72AC7BF8-B831-4F0B-81BE-BA75C4E85AE0@ianai.net> <539256E9.5010204@bennett.com> Message-ID: <53925BCF.70707@bennett.com> I wanted the NANOG community to know that someone is impersonating me. I don't send off-topic links from dodgy blogs to email lists. I now have a pretty good idea as to who the impersonator is; it seems that Gilmore has too much time on his hands. RB On 6/6/14, 5:06 PM, Patrick W. Gilmore wrote: > I believe I listed 3. > > And there are multiple times I have posted similar items in the past. > > Just curious about the "speculators" thing. But I think we're off-topic, so apologies to the audience for extra email in their inboxes. I've sent reply-to to my personal address to avoid this blowing up (although I don't know if mailman will respect that). > -- Richard Bennett Visiting Fellow, American Enterprise Institute Center for Internet, Communications, and Technology Policy Editor, High Tech Forum From patrick at ianai.net Sat Jun 7 00:36:56 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 6 Jun 2014 20:36:56 -0400 Subject: richard@bennett.com has shared Cable companies astroturfing support against FCC Title II regulation | Electronista In-Reply-To: <53925BCF.70707@bennett.com> References: <845831298.6687.1402075770367.JavaMail.share@slave-134.wh.gwallet.com> <5392455A.8040609@bennett.com> <72AC7BF8-B831-4F0B-81BE-BA75C4E85AE0@ianai.net> <539256E9.5010204@bennett.com> <53925BCF.70707@bennett.com> Message-ID: <837E37AA-81E5-4435-AB8C-0185E2CBFAE2@ianai.net> Richard: While you & I don't have the best relationship ever, I would not - and did not - do anything of the sort. I'm a little more, let's say, blunt about my displeasures. You don't have to believe me, but those are the facts. Also, just to be clear again, I have zero problem with pointing out the impersonation, I was questioning the "speculators" part. I.e. You implied you would not send that, and I wondered why you wouldn't. But since you think it is off-topic (and I did not), that's a perfectly valid reason not to send such posts. Thank you for clearing it up. -- TTFN, patrick On Jun 06, 2014, at 20:24 , Richard Bennett wrote: > I wanted the NANOG community to know that someone is impersonating me. I don't send off-topic links from dodgy blogs to email lists. > > I now have a pretty good idea as to who the impersonator is; it seems that Gilmore has too much time on his hands. > > RB > > On 6/6/14, 5:06 PM, Patrick W. Gilmore wrote: >> I believe I listed 3. >> >> And there are multiple times I have posted similar items in the past. >> >> Just curious about the "speculators" thing. But I think we're off-topic, so apologies to the audience for extra email in their inboxes. I've sent reply-to to my personal address to avoid this blowing up (although I don't know if mailman will respect that). >> > > -- > Richard Bennett > Visiting Fellow, American Enterprise Institute > Center for Internet, Communications, and Technology Policy > Editor, High Tech Forum > From alan at clegg.com Sat Jun 7 00:37:19 2014 From: alan at clegg.com (Alan Clegg) Date: Fri, 06 Jun 2014 17:37:19 -0700 Subject: richard@bennett.com has shared Cable companies astroturfing support against FCC Title II regulation | Electronista In-Reply-To: <53925BCF.70707@bennett.com> References: <845831298.6687.1402075770367.JavaMail.share@slave-134.wh.gwallet.com> <5392455A.8040609@bennett.com> <72AC7BF8-B831-4F0B-81BE-BA75C4E85AE0@ianai.net> <539256E9.5010204@bennett.com> <53925BCF.70707@bennett.com> Message-ID: <53925EBF.3050808@clegg.com> On 6/6/14, 5:24 PM, Richard Bennett wrote: > I wanted the NANOG community to know that someone is impersonating me. I > don't send off-topic links from dodgy blogs to email lists. > > I now have a pretty good idea as to who the impersonator is; it seems > that Gilmore has too much time on his hands. http://i949.photobucket.com/albums/ad335/justpolitics/8531.jpg AlanC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 600 bytes Desc: OpenPGP digital signature URL: From bzs at world.std.com Sat Jun 7 04:54:33 2014 From: bzs at world.std.com (Barry Shein) Date: Sat, 7 Jun 2014 00:54:33 -0400 Subject: NTIA cedes root zone control In-Reply-To: <27314139.3188.1402090263001.JavaMail.root@benjamin.baylink.com> References: <27314139.3188.1402090263001.JavaMail.root@benjamin.baylink.com> Message-ID: <21394.39689.993966.763509@world.std.com> And the seventh seal is broken... -- -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 blake.mailinglist at pfankuch.me Sat Jun 7 14:14:32 2014 From: blake.mailinglist at pfankuch.me (Blake Pfankuch - Mailing List) Date: Sat, 7 Jun 2014 14:14:32 +0000 Subject: go daddy email administrator Message-ID: Can I have a go daddy email admin shoot me a message off list? Support will not work with me because I am not a customer, and it appears my corporate email domain is being throttled due to volume. We are not a mass mail sender, however we send several thousand emails a day based on the size and nature of our business. Thanks, Blake From randy at psg.com Sat Jun 7 16:49:23 2014 From: randy at psg.com (Randy Bush) Date: Sat, 07 Jun 2014 09:49:23 -0700 Subject: NTIA cedes root zone control In-Reply-To: <53923793.4030102@ropeguru.com> References: <27314139.3188.1402090263001.JavaMail.root@benjamin.baylink.com> <53923793.4030102@ropeguru.com> Message-ID: >> (make the announcement not only on a Friday, but *during a NANOG*) dunno where this rubbish came from, but nanog was mon-wed randy From dgucker at choopa.com Sat Jun 7 17:12:16 2014 From: dgucker at choopa.com (David Gucker) Date: Sat, 07 Jun 2014 13:12:16 -0400 Subject: AS7162 contacts? Message-ID: <539347F0.5010704@choopa.com> Anyone have a way to get in touch with AS7162? They don't respond to whois listed email addresses. David Gucker From paul at paulstewart.org Sun Jun 8 15:11:57 2014 From: paul at paulstewart.org (Paul Stewart) Date: Sun, 08 Jun 2014 11:11:57 -0400 Subject: World Cup Streaming Message-ID: Hey folks One part of capacity planning that is always challenging at times with various providers I have worked with is determining the traffic levels required for upcoming events such as World Cup. Obviously there is speculation and it varies dependent on the provider, their geography, and size of eyeball/downstream eyeball customers. Is there any resources out there other than news articles that provide for a reasonable estimation as to how much impact World Cup will have for example? I’ve heard offline from some folks that put World Cup at greater traffic levels than the recent Olympics for example but have no way to know if that is a pure guess or an educated estimate. I am assuming that the CDN’s involved have some pretty accurate ideas on what to expect but in the past I have not been able to get feedback from them with any specific estimations. Thanks, Paul From rubensk at gmail.com Sun Jun 8 16:57:07 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 8 Jun 2014 13:57:07 -0300 Subject: World Cup Streaming In-Reply-To: References: Message-ID: Sports events have their rights sold on per country basis; this leads to some fragmentation of those numbers as network X has the rights for country 1, network Y for country 2, and they account their numbers separate even if they use the same CDN. Considering Soccer (or Football as we non-US call it) is not so popular in the US, my guess (not an estimate) is for traffic levels for the US network that carries the World Cup online to not be as high as Summer and/or Winter Olympics. What we have pretty good educated estimates is for 2014 World Cup streaming to Brazil to be higher in volume than what was seen in the Olympics streaming to the US. Rubens On Sun, Jun 8, 2014 at 12:11 PM, Paul Stewart wrote: > Hey folks > > One part of capacity planning that is always challenging at times with > various providers I have worked with is determining the traffic levels > required for upcoming events such as World Cup. Obviously there is > speculation and it varies dependent on the provider, their geography, and > size of eyeball/downstream eyeball customers. > > Is there any resources out there other than news articles that provide for > a > reasonable estimation as to how much impact World Cup will have for > example? > I’ve heard offline from some folks that put World Cup at greater traffic > levels than the recent Olympics for example but have no way to know if that > is a pure guess or an educated estimate. > > I am assuming that the CDN’s involved have some pretty accurate ideas on > what to expect but in the past I have not been able to get feedback from > them with any specific estimations. > > Thanks, > > Paul > > > > From jduncan at juniper.net Sun Jun 8 17:19:09 2014 From: jduncan at juniper.net (Jim Duncan) Date: Sun, 8 Jun 2014 17:19:09 +0000 Subject: Does anyone know Jared's birthday? In-Reply-To: References: <538FC745.20508@mrqueue.com>, Message-ID: Jared, I regret I won't be at anything other than FIRST in the near future, so I can't say it to you in person, but I do think this is worth sending to the whole list: Birthdays are when we tell people, "We're glad you're here." And we're glad you're here. All of us. Even some who don't know it yet. Thank you. Happy Birthday, whenever it is! Jim -- James N. Duncan, CISSP Security Engineer, Juniper Secure Development Lifecycle (SDL) Program E-mail: jduncan at juniper.net Mobile: +1 919 608 0748 PGP key fingerprint: E09E EA55 DA28 1399 75EB D6A2 7092 9A9C 6DC3 1821 -------- Original message -------- From: Jared Mauch Date:2014/06/04 23:33 (GMT-05:00) To: "Mr. Queue" Cc: nanog at nanog.org Subject: Re: Does anyone know Jared's birthday? The answers you want are: 1) it was not worth the whole list 2) warren wants to hassle me on my birthday at IETF. If you are there, please do say hello in person. Everyone else, sorry for the noise and hope you are entertained. Jared Mauch > On Jun 4, 2014, at 6:26 PM, "Mr. Queue" wrote: > >> On 6/4/2014 2:15 PM, Warren Kumari wrote: >> Yup, I did think it was worth asking the entire list. > > Week from today, or when the time is appropriate could someone fill us > in? Off list is fine. From paul at paulstewart.org Sun Jun 8 17:48:39 2014 From: paul at paulstewart.org (Paul Stewart) Date: Sun, 08 Jun 2014 13:48:39 -0400 Subject: World Cup Streaming In-Reply-To: References: Message-ID: Thank you. I’m actually based in Canada and there is a strong following of Soccer here :) Akamai will be doing the streaming here (not sure about the US or other countries). I have reached out to them in the past to ask questions about anticipated volumes and they never answer with details. Thanks, Paul From: Rubens Kuhl Date: Sunday, June 8, 2014 at 12:57 PM To: Paul Stewart Cc: Nanog Subject: Re: World Cup Streaming > > Sports events have their rights sold on per country basis; this leads to some > fragmentation of those numbers as network X has the rights for country 1, > network Y for country 2, and they account their numbers separate even if they > use the same CDN. > > Considering Soccer (or Football as we non-US call it) is not so popular in the > US, my guess (not an estimate) is for traffic levels for the US network that > carries the World Cup online to not be as high as Summer and/or Winter > Olympics. > > What we have pretty good educated estimates is for 2014 World Cup streaming to > Brazil to be higher in volume than what was seen in the Olympics streaming to > the US. > > Rubens > > > > > > > > On Sun, Jun 8, 2014 at 12:11 PM, Paul Stewart wrote: >> Hey folks >> >> One part of capacity planning that is always challenging at times with >> various providers I have worked with is determining the traffic levels >> required for upcoming events such as World Cup. Obviously there is >> speculation and it varies dependent on the provider, their geography, and >> size of eyeball/downstream eyeball customers. >> >> Is there any resources out there other than news articles that provide for a >> reasonable estimation as to how much impact World Cup will have for example? >> I’ve heard offline from some folks that put World Cup at greater traffic >> levels than the recent Olympics for example but have no way to know if that >> is a pure guess or an educated estimate. >> >> I am assuming that the CDN’s involved have some pretty accurate ideas on >> what to expect but in the past I have not been able to get feedback from >> them with any specific estimations. >> >> Thanks, >> >> Paul >> >> >> > From starthir at gmail.com Sun Jun 8 21:48:51 2014 From: starthir at gmail.com (Alvaro Pereira) Date: Sun, 8 Jun 2014 15:48:51 -0600 Subject: World Cup Streaming In-Reply-To: References: Message-ID: In Canada, the last Winter Olympic Games were streamed from olympics.cbc.ca (hosted by Akamai), which helped us find which upstream provider we would be getting the content from. Does anyone know which hostname will be used for the cbc.ca World Cup streaming? Thanks, Alvaro Pereira On Sun, Jun 8, 2014 at 11:48 AM, Paul Stewart wrote: > Thank you. > > I’m actually based in Canada and there is a strong following of Soccer here > :) > > Akamai will be doing the streaming here (not sure about the US or other > countries). I have reached out to them in the past to ask questions about > anticipated volumes and they never answer with details. > > Thanks, > Paul > > > From: Rubens Kuhl > Date: Sunday, June 8, 2014 at 12:57 PM > To: Paul Stewart > Cc: Nanog > Subject: Re: World Cup Streaming > > > > > Sports events have their rights sold on per country basis; this leads to > some > > fragmentation of those numbers as network X has the rights for country 1, > > network Y for country 2, and they account their numbers separate even if > they > > use the same CDN. > > > > Considering Soccer (or Football as we non-US call it) is not so popular > in the > > US, my guess (not an estimate) is for traffic levels for the US network > that > > carries the World Cup online to not be as high as Summer and/or Winter > > Olympics. > > > > What we have pretty good educated estimates is for 2014 World Cup > streaming to > > Brazil to be higher in volume than what was seen in the Olympics > streaming to > > the US. > > > > Rubens > > > > > > > > > > > > > > > > On Sun, Jun 8, 2014 at 12:11 PM, Paul Stewart > wrote: > >> Hey folks > >> > >> One part of capacity planning that is always challenging at times with > >> various providers I have worked with is determining the traffic levels > >> required for upcoming events such as World Cup. Obviously there is > >> speculation and it varies dependent on the provider, their geography, > and > >> size of eyeball/downstream eyeball customers. > >> > >> Is there any resources out there other than news articles that provide > for a > >> reasonable estimation as to how much impact World Cup will have for > example? > >> I’ve heard offline from some folks that put World Cup at greater traffic > >> levels than the recent Olympics for example but have no way to know if > that > >> is a pure guess or an educated estimate. > >> > >> I am assuming that the CDN’s involved have some pretty accurate ideas on > >> what to expect but in the past I have not been able to get feedback from > >> them with any specific estimations. > >> > >> Thanks, > >> > >> Paul > >> > >> > >> > > > > > From LarrySheldon at cox.net Sun Jun 8 23:17:07 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 08 Jun 2014 18:17:07 -0500 Subject: Does anyone know Jared's birthday? In-Reply-To: References: <538FC745.20508@mrqueue.com>, Message-ID: <5394EEF3.4080909@cox.net> If you know the birth date, you can find the birth day here: http://www.searchforancestors.com/utility/dayofweek.html -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From fkittred at gwi.net Mon Jun 9 00:31:39 2014 From: fkittred at gwi.net (Fletcher Kittredge) Date: Sun, 8 Jun 2014 20:31:39 -0400 Subject: World Cup Streaming In-Reply-To: References: Message-ID: There are three reasons to expect US viewing will be significantly higher than in World Cups past: 1. The WC will be in the same time zone as most of the US viewing audience; 2. While the USA team will not win, they are good enough they may make multiple rounds. 3. British (English) humor is popular in the US. Very four years, the "Three Lions" comedy troupe put on a performance that has them rolling in the aisles. With cult performers Rooney, Gerrard, Welbeck, and Hart, hijinks will ensue and fun will be had by all![1] 1. Except the English, who will be bitter and depressed. But they are happiest being bitter and depressed. On Sun, Jun 8, 2014 at 12:57 PM, Rubens Kuhl wrote: > Sports events have their rights sold on per country basis; this leads to > some fragmentation of those numbers as network X has the rights for country > 1, network Y for country 2, and they account their numbers separate even if > they use the same CDN. > > Considering Soccer (or Football as we non-US call it) is not so popular in > the US, my guess (not an estimate) is for traffic levels for the US network > that carries the World Cup online to not be as high as Summer and/or Winter > Olympics. > > What we have pretty good educated estimates is for 2014 World Cup streaming > to Brazil to be higher in volume than what was seen in the Olympics > streaming to the US. > > Rubens > > > > > > > > On Sun, Jun 8, 2014 at 12:11 PM, Paul Stewart > wrote: > > > Hey folks > > > > One part of capacity planning that is always challenging at times with > > various providers I have worked with is determining the traffic levels > > required for upcoming events such as World Cup. Obviously there is > > speculation and it varies dependent on the provider, their geography, and > > size of eyeball/downstream eyeball customers. > > > > Is there any resources out there other than news articles that provide > for > > a > > reasonable estimation as to how much impact World Cup will have for > > example? > > I’ve heard offline from some folks that put World Cup at greater traffic > > levels than the recent Olympics for example but have no way to know if > that > > is a pure guess or an educated estimate. > > > > I am assuming that the CDN’s involved have some pretty accurate ideas on > > what to expect but in the past I have not been able to get feedback from > > them with any specific estimations. > > > > Thanks, > > > > Paul > > > > > > > > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From chris at nifry.com Mon Jun 9 09:59:40 2014 From: chris at nifry.com (Chris Russell) Date: Mon, 09 Jun 2014 10:59:40 +0100 Subject: World Cup Streaming In-Reply-To: References: Message-ID: > 3. British (English) humor is popular in the US. Very four > years, the > "Three Lions" comedy troupe put on a performance that has them > rolling in > the aisles. With cult performers Rooney, Gerrard, Welbeck, and > Hart, > hijinks will ensue and fun will be had by all![1] > > 1. Except the English, who will be bitter and depressed. But they > are > happiest being bitter and depressed. As a Limey, touche sir, touche. Rooney is the 2960G of football, plenty of potential but you know he won't quite cut it in the enterprise space. With that said, the hair transplant may provide additional buffer space for balls delivered with higher MTU. Chris From Anshuman.Kanwar at citrix.com Mon Jun 9 14:58:14 2014 From: Anshuman.Kanwar at citrix.com (Anshuman Kanwar) Date: Mon, 9 Jun 2014 14:58:14 +0000 Subject: Linkedin Operations Contact ? Message-ID: <4352BB7D6A228446AE13B8E07652A500924660@SJCPEX01CL01.citrite.net> Looking to get in touch with the LinkedIn Ops team. Could one you kindly respond 1-1 ? Thanks, -ansh Ansh Kanwar Senior Director, Technical Operations T: +1 805 690 5714 | M: +1 805 448 1890 | F: +1 805 879 3722 Skype: ansh_kanwar | AS: 16815 anshuman.kanwar at citrix.com [Description: Description: Description: cid:4A46DE88-037B-420B-B411-732B97826E8D at ad.corp.expertcity.com] Powering mobile workstyles and cloud services -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1332 bytes Desc: image002.jpg URL: From dmburgess at linktechs.net Mon Jun 9 16:38:12 2014 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 9 Jun 2014 11:38:12 -0500 Subject: L3/HE/Inbound Pathing Question Message-ID: <50710E9A7E64454C974049FC998EB65501B23D69@03-exchange.lti.local> I have ran into this a few times, and have not found a solution: L3 à HEà --- blended Provider A --- > Customer Cogent -- > Customer Cogent of course is cheaper, and customer wishes to use the blended provder more as backup and/or have most of the inbound traffic coming in the cheaper path (cogent). The issue appears to be L3 and HE specifically (of course they make up a good chunk of inbound traffic) always prefers their customer peers, so even if we advertise any prefix to the blended, those companies (l3/he) always choose to come in though the customer peer and then to my customer. Any thoughts on how to get around this, and still have some kind of route in the blended provider for failover? Off list is fine.. Thanks in advance. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace From alumbis at gmail.com Mon Jun 9 18:30:48 2014 From: alumbis at gmail.com (Pete Lumbis) Date: Mon, 9 Jun 2014 14:30:48 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: The doc on how to adjust the 6500/7600 TCAM space was just published. http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis wrote: > There is currently a doc for the ASR9k. We're working on getting on for > 6500 as well. > > > http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.html > > > > > On Tue, May 6, 2014 at 1:34 PM, wrote: > >> I would like to see Cisco send something out... >> >> -----Original Message----- >> From: "Drew Weaver" >> Sent: ‎5/‎6/‎2014 11:42 AM >> To: "'nanog at nanog.org'" >> Subject: Getting pretty close to default IPv4 route maximum for >> 6500/7600routers. >> >> Hi all, >> >> I am wondering if maybe we should make some kind of concerted effort to >> remind folks about the IPv4 routing table inching closer and closer to the >> 512K route mark. >> >> We are at about 94/95% right now of 512K. >> >> For most of us, the 512K route mark is arbitrary but for a lot of folks >> who may still be running 6500/7600 or other routers which are by default >> configured to crash and burn after 512K routes; it may be a valuable public >> service. >> >> Even if you don't have this scenario in your network today; chances are >> you connect to someone who connects to someone who connects to someone >> (etc...) that does. >> >> In case anyone wants to check on a 6500, you can run: show platform >> hardware capacity pfc and then look under L3 Forwarding Resources. >> >> Just something to think about before it becomes a story the community >> talks about for the next decade. >> >> -Drew >> >> > From contact at nullivex.com Mon Jun 9 18:39:20 2014 From: contact at nullivex.com (Bryan Tong) Date: Mon, 9 Jun 2014 12:39:20 -0600 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: Just had to do this on my router last week. Came in a few mornings ago and we were software switching, yay! On Mon, Jun 9, 2014 at 12:30 PM, Pete Lumbis wrote: > The doc on how to adjust the 6500/7600 TCAM space was just published. > > > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html > > > On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis wrote: > > > There is currently a doc for the ASR9k. We're working on getting on for > > 6500 as well. > > > > > > > http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.html > > > > > > > > > > On Tue, May 6, 2014 at 1:34 PM, wrote: > > > >> I would like to see Cisco send something out... > >> > >> -----Original Message----- > >> From: "Drew Weaver" > >> Sent: ‎5/‎6/‎2014 11:42 AM > >> To: "'nanog at nanog.org'" > >> Subject: Getting pretty close to default IPv4 route maximum for > >> 6500/7600routers. > >> > >> Hi all, > >> > >> I am wondering if maybe we should make some kind of concerted effort to > >> remind folks about the IPv4 routing table inching closer and closer to > the > >> 512K route mark. > >> > >> We are at about 94/95% right now of 512K. > >> > >> For most of us, the 512K route mark is arbitrary but for a lot of folks > >> who may still be running 6500/7600 or other routers which are by default > >> configured to crash and burn after 512K routes; it may be a valuable > public > >> service. > >> > >> Even if you don't have this scenario in your network today; chances are > >> you connect to someone who connects to someone who connects to someone > >> (etc...) that does. > >> > >> In case anyone wants to check on a 6500, you can run: show platform > >> hardware capacity pfc and then look under L3 Forwarding Resources. > >> > >> Just something to think about before it becomes a story the community > >> talks about for the next decade. > >> > >> -Drew > >> > >> > > > -- eSited LLC (701) 390-9638 From jay at west.net Mon Jun 9 19:09:39 2014 From: jay at west.net (Jay Hennigan) Date: Mon, 09 Jun 2014 12:09:39 -0700 Subject: L3/HE/Inbound Pathing Question In-Reply-To: <50710E9A7E64454C974049FC998EB65501B23D69@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB65501B23D69@03-exchange.lti.local> Message-ID: <53960673.90400@west.net> On 6/9/14 9:38 AM, Dennis Burgess wrote: > I have ran into this a few times, and have not found a solution: > > L3 à > > HEà --- blended Provider A --- > Customer > > Cogent -- > Customer > > Cogent of course is cheaper, and customer wishes to use the blended provder more as backup and/or have most of the inbound traffic coming in the cheaper path (cogent). The issue appears to be L3 and HE specifically (of course they make up a good chunk of inbound traffic) always prefers their customer peers, so even if we advertise any prefix to the blended, those companies (l3/he) always choose to come in though the customer peer and then to my customer. > > Any thoughts on how to get around this, and still have some kind of route in the blended provider for failover? Off list is fine.. Thanks in advance. Advertise a community to the other providers to localpref your prefixes down to the point of being a backup. 3356:70 should work for Level 3, you will need to talk to HE and/or your blended provider for what to use (and whether they support it). -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jlewis at lewis.org Mon Jun 9 19:09:46 2014 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 9 Jun 2014 15:09:46 -0400 (EDT) Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: Why, in your example, do you bias the split so heavily toward IPv4 that the router won't be able to handle a current full v6 table? I've been using mls cef maximum-routes ip 768 which is probably still a little too liberal for IPv6 FIB TCAM maximum routes : ======================= Current :- ------- IPv4 - 768k MPLS - 16k (default) IPv6 + IP Multicast - 120k (default) given that a full v6 table is around 17k routes today. A more important question though is how many 6500/7600 routers will fully survive the reload required to affect this change? I've lost a blade (presumably to the bad memory issue) each time I've rebooted a 6500 to apply this. On Mon, 9 Jun 2014, Pete Lumbis wrote: > The doc on how to adjust the 6500/7600 TCAM space was just published. > > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html > > > On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis wrote: > >> There is currently a doc for the ASR9k. We're working on getting on for >> 6500 as well. >> >> >> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.html >> >> >> >> >> On Tue, May 6, 2014 at 1:34 PM, wrote: >> >>> I would like to see Cisco send something out... >>> >>> -----Original Message----- >>> From: "Drew Weaver" >>> Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM >>> To: "'nanog at nanog.org'" >>> Subject: Getting pretty close to default IPv4 route maximum for >>> 6500/7600routers. >>> >>> Hi all, >>> >>> I am wondering if maybe we should make some kind of concerted effort to >>> remind folks about the IPv4 routing table inching closer and closer to the >>> 512K route mark. >>> >>> We are at about 94/95% right now of 512K. >>> >>> For most of us, the 512K route mark is arbitrary but for a lot of folks >>> who may still be running 6500/7600 or other routers which are by default >>> configured to crash and burn after 512K routes; it may be a valuable public >>> service. >>> >>> Even if you don't have this scenario in your network today; chances are >>> you connect to someone who connects to someone who connects to someone >>> (etc...) that does. >>> >>> In case anyone wants to check on a 6500, you can run: show platform >>> hardware capacity pfc and then look under L3 Forwarding Resources. >>> >>> Just something to think about before it becomes a story the community >>> talks about for the next decade. >>> >>> -Drew >>> >>> >> > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From contact at nullivex.com Mon Jun 9 19:27:21 2014 From: contact at nullivex.com (Bryan Tong) Date: Mon, 9 Jun 2014 13:27:21 -0600 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: The IPv6 table will not be as big as the v4 table even after full acceptance. Given that most providers will be advertising a single /32 and then rest will be some /48 routes for multi-homed scenarios. My router looks like this FIB TCAM maximum routes : ======================= Current :- ------- IPv4 - 600k MPLS - 32k IPv6 - 160k IP multicast - 32k Probably a little heavy on MPLS considering we dont use it. With the current level of exhaustion I dont think IPv4 will make it past 600k. We are currently seeing 520,000 routes. There are currently 107M IPs left globally. If those all went to /21's that would require 26,255 prefixes. If those all went to /22's that would require 52,510 prefixes. If those all went to /24's that would require 105,021 prefixes. So even the most conservative maximum should be no more than 626K On Mon, Jun 9, 2014 at 1:09 PM, Jon Lewis wrote: > Why, in your example, do you bias the split so heavily toward IPv4 that > the router won't be able to handle a current full v6 table? I've been using > > > mls cef maximum-routes ip 768 > > which is probably still a little too liberal for IPv6 > > FIB TCAM maximum routes : > ======================= > Current :- > ------- > IPv4 - 768k > MPLS - 16k (default) > IPv6 + IP Multicast - 120k (default) > > given that a full v6 table is around 17k routes today. > > A more important question though is how many 6500/7600 routers will fully > survive the reload required to affect this change? I've lost a blade > (presumably to the bad memory issue) each time I've rebooted a 6500 to > apply this. > > > On Mon, 9 Jun 2014, Pete Lumbis wrote: > > The doc on how to adjust the 6500/7600 TCAM space was just published. >> >> http://www.cisco.com/c/en/us/support/docs/switches/ >> catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html >> >> >> On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis wrote: >> >> There is currently a doc for the ASR9k. We're working on getting on for >>> 6500 as well. >>> >>> >>> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000- >>> series-aggregation-services-routers/116999-problem-line-card-00.html >>> >>> >>> >>> >>> On Tue, May 6, 2014 at 1:34 PM, wrote: >>> >>> I would like to see Cisco send something out... >>>> >>>> -----Original Message----- >>>> From: "Drew Weaver" >>>> Sent: яя5/яя6/яя2014 11:42 AM >>>> To: "'nanog at nanog.org'" >>>> Subject: Getting pretty close to default IPv4 route maximum for >>>> 6500/7600routers. >>>> >>>> Hi all, >>>> >>>> I am wondering if maybe we should make some kind of concerted effort to >>>> remind folks about the IPv4 routing table inching closer and closer to >>>> the >>>> 512K route mark. >>>> >>>> We are at about 94/95% right now of 512K. >>>> >>>> For most of us, the 512K route mark is arbitrary but for a lot of folks >>>> who may still be running 6500/7600 or other routers which are by default >>>> configured to crash and burn after 512K routes; it may be a valuable >>>> public >>>> service. >>>> >>>> Even if you don't have this scenario in your network today; chances are >>>> you connect to someone who connects to someone who connects to someone >>>> (etc...) that does. >>>> >>>> In case anyone wants to check on a 6500, you can run: show platform >>>> hardware capacity pfc and then look under L3 Forwarding Resources. >>>> >>>> Just something to think about before it becomes a story the community >>>> talks about for the next decade. >>>> >>>> -Drew >>>> >>>> >>>> >>> >> > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > -- eSited LLC (701) 390-9638 From jvanoppen at spectrumnet.us Mon Jun 9 19:27:47 2014 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 9 Jun 2014 19:27:47 +0000 Subject: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: It is generally much better to do the following: mls cef maximum-routes ipv6 90 mls cef maximum-routes ip-multicast 1 This will leave v4 and mpls in one big pool, puts v6 to something useful for quite a while and steals all of the multicast space which is not really used on most deployments. This gives us the following (which is pretty great for IP backbone purposes in dual stack): #show mls cef maximum-routes FIB TCAM maximum routes : ======================= Current :- ------- IPv4 + MPLS - 832k (default) IPv6 - 90k IP multicast - 1k John -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jon Lewis Sent: Monday, June 09, 2014 12:10 PM To: Pete Lumbis Cc: nanog at nanog.org Subject: Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers. Why, in your example, do you bias the split so heavily toward IPv4 that the router won't be able to handle a current full v6 table? I've been using mls cef maximum-routes ip 768 which is probably still a little too liberal for IPv6 FIB TCAM maximum routes : ======================= Current :- ------- IPv4 - 768k MPLS - 16k (default) IPv6 + IP Multicast - 120k (default) given that a full v6 table is around 17k routes today. A more important question though is how many 6500/7600 routers will fully survive the reload required to affect this change? I've lost a blade (presumably to the bad memory issue) each time I've rebooted a 6500 to apply this. On Mon, 9 Jun 2014, Pete Lumbis wrote: > The doc on how to adjust the 6500/7600 TCAM space was just published. > > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie > s-switches/117712-problemsolution-cat6500-00.html > > > On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis wrote: > >> There is currently a doc for the ASR9k. We're working on getting on >> for >> 6500 as well. >> >> >> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-agg >> regation-services-routers/116999-problem-line-card-00.html >> >> >> >> >> On Tue, May 6, 2014 at 1:34 PM, wrote: >> >>> I would like to see Cisco send something out... >>> >>> -----Original Message----- >>> From: "Drew Weaver" >>> Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM >>> To: "'nanog at nanog.org'" >>> Subject: Getting pretty close to default IPv4 route maximum for >>> 6500/7600routers. >>> >>> Hi all, >>> >>> I am wondering if maybe we should make some kind of concerted effort >>> to remind folks about the IPv4 routing table inching closer and >>> closer to the 512K route mark. >>> >>> We are at about 94/95% right now of 512K. >>> >>> For most of us, the 512K route mark is arbitrary but for a lot of >>> folks who may still be running 6500/7600 or other routers which are >>> by default configured to crash and burn after 512K routes; it may be >>> a valuable public service. >>> >>> Even if you don't have this scenario in your network today; chances >>> are you connect to someone who connects to someone who connects to >>> someone >>> (etc...) that does. >>> >>> In case anyone wants to check on a 6500, you can run: show platform >>> hardware capacity pfc and then look under L3 Forwarding Resources. >>> >>> Just something to think about before it becomes a story the >>> community talks about for the next decade. >>> >>> -Drew >>> >>> >> > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From contact at nullivex.com Mon Jun 9 19:37:11 2014 From: contact at nullivex.com (Bryan Tong) Date: Mon, 9 Jun 2014 13:37:11 -0600 Subject: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: John, great point! Regardless, shouldn't need more than 626K to make it to v6 and we wont need as many for v6. That was one of the problems that v6 was designed to address. On Mon, Jun 9, 2014 at 1:27 PM, John van Oppen wrote: > It is generally much better to do the following: > > mls cef maximum-routes ipv6 90 > mls cef maximum-routes ip-multicast 1 > > This will leave v4 and mpls in one big pool, puts v6 to something useful > for quite a while and steals all of the multicast space which is not really > used on most deployments. > > > This gives us the following (which is pretty great for IP backbone > purposes in dual stack): > > #show mls cef maximum-routes > FIB TCAM maximum routes : > ======================= > Current :- > ------- > IPv4 + MPLS - 832k (default) > IPv6 - 90k > IP multicast - 1k > > > John > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jon Lewis > Sent: Monday, June 09, 2014 12:10 PM > To: Pete Lumbis > Cc: nanog at nanog.org > Subject: Re: Getting pretty close to default IPv4 route maximum for > 6500/7600routers. > > Why, in your example, do you bias the split so heavily toward IPv4 that > the router won't be able to handle a current full v6 table? I've been using > > mls cef maximum-routes ip 768 > > which is probably still a little too liberal for IPv6 > > FIB TCAM maximum routes : > ======================= > Current :- > ------- > IPv4 - 768k > MPLS - 16k (default) > IPv6 + IP Multicast - 120k (default) > > given that a full v6 table is around 17k routes today. > > A more important question though is how many 6500/7600 routers will fully > survive the reload required to affect this change? I've lost a blade > (presumably to the bad memory issue) each time I've rebooted a 6500 to > apply this. > > On Mon, 9 Jun 2014, Pete Lumbis wrote: > > > The doc on how to adjust the 6500/7600 TCAM space was just published. > > > > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie > > s-switches/117712-problemsolution-cat6500-00.html > > > > > > On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis wrote: > > > >> There is currently a doc for the ASR9k. We're working on getting on > >> for > >> 6500 as well. > >> > >> > >> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-agg > >> regation-services-routers/116999-problem-line-card-00.html > >> > >> > >> > >> > >> On Tue, May 6, 2014 at 1:34 PM, wrote: > >> > >>> I would like to see Cisco send something out... > >>> > >>> -----Original Message----- > >>> From: "Drew Weaver" > >>> Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM > >>> To: "'nanog at nanog.org'" > >>> Subject: Getting pretty close to default IPv4 route maximum for > >>> 6500/7600routers. > >>> > >>> Hi all, > >>> > >>> I am wondering if maybe we should make some kind of concerted effort > >>> to remind folks about the IPv4 routing table inching closer and > >>> closer to the 512K route mark. > >>> > >>> We are at about 94/95% right now of 512K. > >>> > >>> For most of us, the 512K route mark is arbitrary but for a lot of > >>> folks who may still be running 6500/7600 or other routers which are > >>> by default configured to crash and burn after 512K routes; it may be > >>> a valuable public service. > >>> > >>> Even if you don't have this scenario in your network today; chances > >>> are you connect to someone who connects to someone who connects to > >>> someone > >>> (etc...) that does. > >>> > >>> In case anyone wants to check on a 6500, you can run: show platform > >>> hardware capacity pfc and then look under L3 Forwarding Resources. > >>> > >>> Just something to think about before it becomes a story the > >>> community talks about for the next decade. > >>> > >>> -Drew > >>> > >>> > >> > > > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are _________ > http://www.lewis.org/~jlewis/pgp for PGP public key_________ > -- eSited LLC (701) 390-9638 From jvanoppen at spectrumnet.us Mon Jun 9 19:38:15 2014 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 9 Jun 2014 19:38:15 +0000 Subject: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: Yep, exactly… the problem is the carving suggested by most kills the fact that MPLS and v4 are pooled, which on a larger network is very nice, especially if using 6PE where each v6 route may need an MPLS route too. From: Bryan Tong [mailto:contact at nullivex.com] Sent: Monday, June 09, 2014 12:37 PM To: John van Oppen Cc: nanog at nanog.org Subject: Re: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers. John, great point! Regardless, shouldn't need more than 626K to make it to v6 and we wont need as many for v6. That was one of the problems that v6 was designed to address. On Mon, Jun 9, 2014 at 1:27 PM, John van Oppen > wrote: It is generally much better to do the following: mls cef maximum-routes ipv6 90 mls cef maximum-routes ip-multicast 1 This will leave v4 and mpls in one big pool, puts v6 to something useful for quite a while and steals all of the multicast space which is not really used on most deployments. This gives us the following (which is pretty great for IP backbone purposes in dual stack): #show mls cef maximum-routes FIB TCAM maximum routes : ======================= Current :- ------- IPv4 + MPLS - 832k (default) IPv6 - 90k IP multicast - 1k John -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jon Lewis Sent: Monday, June 09, 2014 12:10 PM To: Pete Lumbis Cc: nanog at nanog.org Subject: Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers. Why, in your example, do you bias the split so heavily toward IPv4 that the router won't be able to handle a current full v6 table? I've been using mls cef maximum-routes ip 768 which is probably still a little too liberal for IPv6 FIB TCAM maximum routes : ======================= Current :- ------- IPv4 - 768k MPLS - 16k (default) IPv6 + IP Multicast - 120k (default) given that a full v6 table is around 17k routes today. A more important question though is how many 6500/7600 routers will fully survive the reload required to affect this change? I've lost a blade (presumably to the bad memory issue) each time I've rebooted a 6500 to apply this. On Mon, 9 Jun 2014, Pete Lumbis wrote: > The doc on how to adjust the 6500/7600 TCAM space was just published. > > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie > s-switches/117712-problemsolution-cat6500-00.html > > > On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis > wrote: > >> There is currently a doc for the ASR9k. We're working on getting on >> for >> 6500 as well. >> >> >> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-agg >> regation-services-routers/116999-problem-line-card-00.html >> >> >> >> >> On Tue, May 6, 2014 at 1:34 PM, > wrote: >> >>> I would like to see Cisco send something out... >>> >>> -----Original Message----- >>> From: "Drew Weaver" > >>> Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM >>> To: "'nanog at nanog.org'" > >>> Subject: Getting pretty close to default IPv4 route maximum for >>> 6500/7600routers. >>> >>> Hi all, >>> >>> I am wondering if maybe we should make some kind of concerted effort >>> to remind folks about the IPv4 routing table inching closer and >>> closer to the 512K route mark. >>> >>> We are at about 94/95% right now of 512K. >>> >>> For most of us, the 512K route mark is arbitrary but for a lot of >>> folks who may still be running 6500/7600 or other routers which are >>> by default configured to crash and burn after 512K routes; it may be >>> a valuable public service. >>> >>> Even if you don't have this scenario in your network today; chances >>> are you connect to someone who connects to someone who connects to >>> someone >>> (etc...) that does. >>> >>> In case anyone wants to check on a 6500, you can run: show platform >>> hardware capacity pfc and then look under L3 Forwarding Resources. >>> >>> Just something to think about before it becomes a story the >>> community talks about for the next decade. >>> >>> -Drew >>> >>> >> > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- eSited LLC (701) 390-9638 From contact at nullivex.com Mon Jun 9 20:17:57 2014 From: contact at nullivex.com (Bryan Tong) Date: Mon, 9 Jun 2014 14:17:57 -0600 Subject: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: I botched those numbers. Let me fix. According to this countdown: http://inetcore.com/project/ipv4ec/index_en.html we have 6.41 /8's left. So that is 107,541,955 IPs. CIDR - Prefixes ----------------- /20 - 26,255.36 /21 - 52,510.72 /22 - 105,021.44 /23 - 210,042.88 /24 - 420,085.76 My apologies for my erroneous math, I was off one number making the table. Johns solution to combine MPLS and IPv4 is the best solution. I would implement it if I hadn't already rebooted a few days ago. From clinton at scripty.com Mon Jun 9 23:58:13 2014 From: clinton at scripty.com (Clinton Work) Date: Mon, 09 Jun 2014 17:58:13 -0600 Subject: World Cup Streaming In-Reply-To: References: Message-ID: <1402358293.23890.126960829.4C8D83B4@webmail.messagingengine.com> CBC in Canada has just released details about their World Cup app. http://mobilesyrup.com/2014/06/09/cbcs-fifa-world-cup-2014-app-offers-live-matches-multi-angle-replays-scores-news-and-bios/ I heard that some of the broadcasters had privacy agreements with Akamai which is why they wouldn't share event traffic predictions. I reached out to Akamai before the 2014 Winter Olympics and they wouldn't share anything. -- Clinton Work Airdrie, AB On Sun, Jun 8, 2014, at 03:48 PM, Alvaro Pereira wrote: > In Canada, the last Winter Olympic Games were streamed from > olympics.cbc.ca > (hosted by Akamai), which helped us find which upstream provider we would > be getting the content from. > > Does anyone know which hostname will be used for the cbc.ca World Cup > streaming? > > Thanks, > > Alvaro Pereira > > > On Sun, Jun 8, 2014 at 11:48 AM, Paul Stewart > wrote: > > > Thank you. > > > > I’m actually based in Canada and there is a strong following of Soccer here > > :) > > > > Akamai will be doing the streaming here (not sure about the US or other > > countries). I have reached out to them in the past to ask questions about > > anticipated volumes and they never answer with details. > > > > Thanks, > > Paul > > > > > > From: Rubens Kuhl > > Date: Sunday, June 8, 2014 at 12:57 PM > > To: Paul Stewart > > Cc: Nanog > > Subject: Re: World Cup Streaming > > > > > > > > Sports events have their rights sold on per country basis; this leads to > > some > > > fragmentation of those numbers as network X has the rights for country 1, > > > network Y for country 2, and they account their numbers separate even if > > they > > > use the same CDN. > > > > > > Considering Soccer (or Football as we non-US call it) is not so popular > > in the > > > US, my guess (not an estimate) is for traffic levels for the US network > > that > > > carries the World Cup online to not be as high as Summer and/or Winter > > > Olympics. > > > > > > What we have pretty good educated estimates is for 2014 World Cup > > streaming to > > > Brazil to be higher in volume than what was seen in the Olympics > > streaming to > > > the US. > > > > > > Rubens > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jun 8, 2014 at 12:11 PM, Paul Stewart > > wrote: > > >> Hey folks > > >> > > >> One part of capacity planning that is always challenging at times with > > >> various providers I have worked with is determining the traffic levels > > >> required for upcoming events such as World Cup. Obviously there is > > >> speculation and it varies dependent on the provider, their geography, > > and > > >> size of eyeball/downstream eyeball customers. > > >> > > >> Is there any resources out there other than news articles that provide > > for a > > >> reasonable estimation as to how much impact World Cup will have for > > example? > > >> I’ve heard offline from some folks that put World Cup at greater traffic > > >> levels than the recent Olympics for example but have no way to know if > > that > > >> is a pure guess or an educated estimate. > > >> > > >> I am assuming that the CDN’s involved have some pretty accurate ideas on > > >> what to expect but in the past I have not been able to get feedback from > > >> them with any specific estimations. > > >> > > >> Thanks, > > >> > > >> Paul > > >> > > >> > > >> > > > > > > > > > -- Clinton Work Airdrie, AB From refresh.lsong at gmail.com Tue Jun 10 03:00:41 2014 From: refresh.lsong at gmail.com (Song Li) Date: Tue, 10 Jun 2014 11:00:41 +0800 Subject: question about bogon prefix Message-ID: <539674D9.7070501@gmail.com> Hi everyone, I found many ISP announced bogon prefix, for example: OriginAS Announcement Description AS7018 172.116.0.0/24 unallocated AS209 209.193.112.0/20 unallocated my question is why the tier1 and other ISP announce these unallocated bogon prefixes, and another interesting question is: If I am ISP, can I announce the same bogon prefix(172.116.0.0/24) with AS7018 announced? Will this result in prefix hijacking? Thanks! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From morrowc.lists at gmail.com Tue Jun 10 03:14:42 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Jun 2014 23:14:42 -0400 Subject: question about bogon prefix In-Reply-To: <539674D9.7070501@gmail.com> References: <539674D9.7070501@gmail.com> Message-ID: On Mon, Jun 9, 2014 at 11:00 PM, Song Li wrote: > Hi everyone, > > I found many ISP announced bogon prefix, for example: sad, right? > OriginAS Announcement Description > AS7018 172.116.0.0/24 unallocated > AS209 209.193.112.0/20 unallocated > > my question is why the tier1 and other ISP announce these unallocated bogon OSS is hard. > prefixes, and another interesting question is: > > If I am ISP, can I announce the same bogon prefix(172.116.0.0/24) with > AS7018 announced? Will this result in prefix hijacking? > technically you are probably hijacking a hijack :( or something like that. > Thanks! > > -- > Song Li > Room 4-204, FIT Building, > Network Security, > Department of Electronic Engineering, > Tsinghua University, Beijing 100084, China > Tel:( +86) 010-62446440 > E-mail: refresh.lsong at gmail.com From rdrake at direcpath.com Tue Jun 10 04:57:23 2014 From: rdrake at direcpath.com (Robert Drake) Date: Tue, 10 Jun 2014 00:57:23 -0400 Subject: question about bogon prefix In-Reply-To: <539674D9.7070501@gmail.com> References: <539674D9.7070501@gmail.com> Message-ID: <53969033.6030307@direcpath.com> On 6/9/2014 11:00 PM, Song Li wrote: > Hi everyone, > > I found many ISP announced bogon prefix, for example: > > OriginAS Announcement Description > AS7018 172.116.0.0/24 unallocated > AS209 209.193.112.0/20 unallocated > > my question is why the tier1 and other ISP announce these unallocated > bogon prefixes, and another interesting question is: > You could also ask why are other providers accepting the route, since I could announce 209.193.112.0/20 from my router and my upstream would reject it. Of course, those two ASNs have a huge number of routes so they probably aren't filtered as closely by their peers. But.. even if you're hyper diligent and blocking bogon routes, you'll need to ask yourself why it's not in the bogon list: curl -s http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt | grep 209.193 It's also not on http://www.cymru.com/BGP/bogons.html but 172.116.0.0/24 is. Now, according to this: http://myip.ms/view/ip_addresses/3519115264/209.193.112.0_209.193.112.255 It belongs to the Franciscan Health System. The one IP that is in DNS seems to back this up (it's called mercyvpn.org) Whois Record created: 04 Jan 2005 Whois Record updated: 24 Feb 2012 My guess is one of two things. Maybe they renumbered out of the /20 but left a VPN server up and haven't managed to migrate off it yet, but they have asked to return the block.. or, they forgot to pay their bill to ARIN and the block has been removed from whois but Qwest isn't as diligent because they're still being paid. I've CC'd the technical contact listed in the old whois information so maybe he can get things corrected. > If I am ISP, can I announce the same bogon prefix(172.116.0.0/24) with > AS7018 announced? Will this result in prefix hijacking? > > Thanks! > I can find nothing on google that offers any legitimacy for 172.116.0.0/24, but it is has been announced for 2 years so maybe there is some squatters rights at least. It doesn't appear to be a spam source and I don't think any hosts are up on it right now. Maybe it's a test route that never got removed. It makes me sad that nobody at ATT reads the CIDR report. They've only got a couple of bogon announcements so it would be trivial for them to either acknowledge them and claim legitimacy or clean them up. From brandon at bitradius.com Tue Jun 10 05:35:24 2014 From: brandon at bitradius.com (Brandon Lehmann) Date: Tue, 10 Jun 2014 05:35:24 +0000 Subject: L3/HE/Inbound Pathing Question In-Reply-To: <53960673.90400@west.net> References: <50710E9A7E64454C974049FC998EB65501B23D69@03-exchange.lti.local> <53960673.90400@west.net> Message-ID: <15AE4040AA24964AAE3DA9F2DE04C4F5012D9D61ED@W2K8-EX.corp.bitradius.com> If you're not familiar with how you can engineer traffic on L3's network take a peek at http://www.scn.rain.com/~neighorn/PDF/Traffic_Engineering_with_BGP_and_Level 3.pdf (slightly outdated but still useful) As far as HE is concerned, when I asked them about communities a few weeks ago all they could offer was a blackhole community. However, as Jay said, you're likely at the mercy of the blended provider and what they support. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Hennigan > Sent: Monday, June 09, 2014 3:10 PM > To: nanog at nanog.org > Subject: Re: L3/HE/Inbound Pathing Question > > On 6/9/14 9:38 AM, Dennis Burgess wrote: > > I have ran into this a few times, and have not found a solution: > > > > L3 à > > > > HEà --- blended Provider A --- > Customer > > > > Cogent -- > Customer > > > > Cogent of course is cheaper, and customer wishes to use the blended > provder more as backup and/or have most of the inbound traffic coming > in the cheaper path (cogent). The issue appears to be L3 and HE > specifically (of course they make up a good chunk of inbound traffic) > always prefers their customer peers, so even if we advertise any prefix > to the blended, those companies (l3/he) always choose to come in though > the customer peer and then to my customer. > > > > Any thoughts on how to get around this, and still have some kind of > route in the blended provider for failover? Off list is fine.. > Thanks in advance. > > Advertise a community to the other providers to localpref your prefixes > down to the point of being a backup. > > 3356:70 should work for Level 3, you will need to talk to HE and/or > your blended provider for what to use (and whether they support it). > > > -- > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ Your local > telephone and internet company - 805 884-6323 - WB6RDV -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6328 bytes Desc: not available URL: From aj at jonesy.com.au Tue Jun 10 05:48:08 2014 From: aj at jonesy.com.au (Andrew Jones) Date: Tue, 10 Jun 2014 15:48:08 +1000 Subject: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: <0b214a987b20192a26851c1409ed9575@jonesy.com.au> Even if the first numbers were correctly calculated, they don't allow for further deaggregation of already advertised prefixes, which shouldn't be underestimated as the commercial value of each address increases... On 10.06.2014 06:17, Bryan Tong wrote: > I botched those numbers. > > Let me fix. > > According to this countdown: > http://inetcore.com/project/ipv4ec/index_en.html we have 6.41 /8's > left. So > that is 107,541,955 IPs. > > CIDR - Prefixes > ----------------- > /20 - 26,255.36 > /21 - 52,510.72 > /22 - 105,021.44 > /23 - 210,042.88 > /24 - 420,085.76 > > My apologies for my erroneous math, I was off one number making the > table. > > Johns solution to combine MPLS and IPv4 is the best solution. I would > implement it if I hadn't already rebooted a few days ago. From nanog at hostleasing.net Tue Jun 10 07:07:01 2014 From: nanog at hostleasing.net (Randy Epstein) Date: Tue, 10 Jun 2014 03:07:01 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: On the RSP720-10GE at least, it seems that IPv4 and MPLS are not shared. Am I correct or am I missing something? FIB TCAM maximum routes : ======================= Current :- ------- IPv4 - 768k MPLS - 64k IPv6 + IP Multicast - 96k (default) Randy On 6/9/14, 3:27 PM, "John van Oppen" wrote: >It is generally much better to do the following: > >mls cef maximum-routes ipv6 90 >mls cef maximum-routes ip-multicast 1 > >This will leave v4 and mpls in one big pool, puts v6 to something useful >for quite a while and steals all of the multicast space which is not >really used on most deployments. > > >This gives us the following (which is pretty great for IP backbone >purposes in dual stack): > >#show mls cef maximum-routes >FIB TCAM maximum routes : >======================= >Current :- >------- > IPv4 + MPLS - 832k (default) > IPv6 - 90k > IP multicast - 1k > > >John > > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jon Lewis >Sent: Monday, June 09, 2014 12:10 PM >To: Pete Lumbis >Cc: nanog at nanog.org >Subject: Re: Getting pretty close to default IPv4 route maximum for >6500/7600routers. > >Why, in your example, do you bias the split so heavily toward IPv4 that >the router won't be able to handle a current full v6 table? I've been >using > >mls cef maximum-routes ip 768 > >which is probably still a little too liberal for IPv6 > >FIB TCAM maximum routes : >======================= >Current :- >------- > IPv4 - 768k > MPLS - 16k (default) > IPv6 + IP Multicast - 120k (default) > >given that a full v6 table is around 17k routes today. > >A more important question though is how many 6500/7600 routers will fully >survive the reload required to affect this change? I've lost a blade >(presumably to the bad memory issue) each time I've rebooted a 6500 to >apply this. > >On Mon, 9 Jun 2014, Pete Lumbis wrote: > >> The doc on how to adjust the 6500/7600 TCAM space was just published. >> >> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie >> s-switches/117712-problemsolution-cat6500-00.html >> >> >> On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis wrote: >> >>> There is currently a doc for the ASR9k. We're working on getting on >>> for >>> 6500 as well. >>> >>> >>> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-agg >>> regation-services-routers/116999-problem-line-card-00.html >>> >>> >>> >>> >>> On Tue, May 6, 2014 at 1:34 PM, wrote: >>> >>>> I would like to see Cisco send something out... >>>> >>>> -----Original Message----- >>>> From: "Drew Weaver" >>>> Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM >>>> To: "'nanog at nanog.org'" >>>> Subject: Getting pretty close to default IPv4 route maximum for >>>> 6500/7600routers. >>>> >>>> Hi all, >>>> >>>> I am wondering if maybe we should make some kind of concerted effort >>>> to remind folks about the IPv4 routing table inching closer and >>>> closer to the 512K route mark. >>>> >>>> We are at about 94/95% right now of 512K. >>>> >>>> For most of us, the 512K route mark is arbitrary but for a lot of >>>> folks who may still be running 6500/7600 or other routers which are >>>> by default configured to crash and burn after 512K routes; it may be >>>> a valuable public service. >>>> >>>> Even if you don't have this scenario in your network today; chances >>>> are you connect to someone who connects to someone who connects to >>>> someone >>>> (etc...) that does. >>>> >>>> In case anyone wants to check on a 6500, you can run: show platform >>>> hardware capacity pfc and then look under L3 Forwarding Resources. >>>> >>>> Just something to think about before it becomes a story the >>>> community talks about for the next decade. >>>> >>>> -Drew >>>> >>>> >>> >> > >---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are _________ >http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jvanoppen at spectrumnet.us Tue Jun 10 07:12:42 2014 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Tue, 10 Jun 2014 07:12:42 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> , Message-ID: On the sup 720 they become unshared if you carve v4 away from the default separately, that is why I carve the other two instead. From nanog at hostleasing.net Tue Jun 10 07:19:37 2014 From: nanog at hostleasing.net (Randy Epstein) Date: Tue, 10 Jun 2014 03:19:37 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: Ah. I had to ³no mls cef max ip² and ³no mls def max mpls² for it to share. They were previously adjusted separately. :) Thanks. On 6/10/14, 3:12 AM, "John van Oppen" wrote: >On the sup 720 they become unshared if you carve v4 away from the default >separately, that is why I carve the other two instead. From bzeeb-lists at lists.zabbadoz.net Tue Jun 10 09:41:31 2014 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue, 10 Jun 2014 09:41:31 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: <0b214a987b20192a26851c1409ed9575@jonesy.com.au> References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> <0b214a987b20192a26851c1409ed9575@jonesy.com.au> Message-ID: On 10 Jun 2014, at 05:48 , Andrew Jones wrote: > Even if the first numbers were correctly calculated, they don’t allow for further deaggregation of already advertised prefixes, which shouldn't be underestimated as the commercial value of each address increases... IPv4 addresses have little commercial value anymore and IPv6 is basically free. The only people who still haven’t realised don’t have enough money to spend on IPv4 to keep themselves alive for another decade. — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From saku at ytti.fi Tue Jun 10 10:10:21 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 10 Jun 2014 13:10:21 +0300 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> <0b214a987b20192a26851c1409ed9575@jonesy.com.au> Message-ID: <20140610101021.GA18623@pob.ytti.fi> On (2014-06-10 09:41 +0000), Bjoern A. Zeeb wrote: > IPv4 addresses have little commercial value anymore and IPv6 is basically free. The only people who still haven’t realised don’t have enough money to spend on IPv4 to keep themselves alive for another decade. Wishing how markets should be and how markets are in this instance are divergent. -- ++ytti From bzeeb-lists at lists.zabbadoz.net Tue Jun 10 10:28:20 2014 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue, 10 Jun 2014 10:28:20 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: <20140610101021.GA18623@pob.ytti.fi> References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> <0b214a987b20192a26851c1409ed9575@jonesy.com.au> <20140610101021.GA18623@pob.ytti.fi> Message-ID: On 10 Jun 2014, at 10:10 , Saku Ytti wrote: > On (2014-06-10 09:41 +0000), Bjoern A. Zeeb wrote: > >> IPv4 addresses have little commercial value anymore and IPv6 is basically free. The only people who still haven’t realised don’t have enough money to spend on IPv4 to keep themselves alive for another decade. > > Wishing how markets should be and how markets are in this instance are > divergent. You mean it’s more likely people acquire/merge with other companies for IP space then go through transfer? https://www.arin.net/knowledge/statistics/ — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From saku at ytti.fi Tue Jun 10 10:41:59 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 10 Jun 2014 13:41:59 +0300 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <0b214a987b20192a26851c1409ed9575@jonesy.com.au> <20140610101021.GA18623@pob.ytti.fi> Message-ID: <20140610104159.GA29282@pob.ytti.fi> On (2014-06-10 10:28 +0000), Bjoern A. Zeeb wrote: > You mean it’s more likely people acquire/merge with other companies for IP space then go through transfer? https://www.arin.net/knowledge/statistics/ I mean that demand for IPv4 addresses will continue to foreseeable future, if you are offering content, and there is difference between reach for IPv6 and IPv4+IPv6, you're going to want to acquire some IPv4 addresses to avoid giving your competition an unfair advantage. How will this reflect to price, you imply price of IPv4 address is going to decrease, I expect it's not reached peak yet, due to still having RIR availability which sets natural limit to price. -- ++ytti From rubensk at gmail.com Tue Jun 10 13:21:33 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 10 Jun 2014 10:21:33 -0300 Subject: End of IPv4 addresses in LAC region Message-ID: It has been just announced in LAC network operator mailing lists that the LAC region just crossed the /10 boundary, triggering exhaustion policies that now only allow assignments of /22 IP address blocks, either for initial assignments or additional requests. Next in line, ARIN region. Is February 2015 still the most likely guess ? Rubens From ttauber at 1-4-5.net Tue Jun 10 13:26:39 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Tue, 10 Jun 2014 09:26:39 -0400 Subject: question about bogon prefix In-Reply-To: <53969033.6030307@direcpath.com> References: <539674D9.7070501@gmail.com> <53969033.6030307@direcpath.com> Message-ID: On Tue, Jun 10, 2014 at 12:57 AM, Robert Drake wrote: > > > My guess is one of two things. Maybe they renumbered out of the /20 but > left a VPN server up and haven't managed to migrate off it yet, but they > have asked to return the block.. or, they forgot to pay their bill to ARIN > and the block has been removed from whois but Qwest isn't as diligent > because they're still being paid. > This brings up a good point which came to mind recently. What process(es) do folks use for cases where an address block and/or ASN seems no longer have whois info associated (eg. where authorization to use may have been revoked)? Do the RIRs have a process for notifying the community or at least the upstream providers that something has changed? Thanks for insight from the community. Tony From blake at ispn.net Tue Jun 10 17:04:14 2014 From: blake at ispn.net (Blake Hudson) Date: Tue, 10 Jun 2014 12:04:14 -0500 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: <53973A8E.9010602@ispn.net> I haven't seen anyone bring up this point yet, but I feel like I'm missing something... I receive a full BGP table from several providers. They send me ~490k *prefixes* each. However, my router shows ~332k *subnets* in the routing table. As I understand it, the BGP table contains duplicate information (for example a supernet is announced as well as all subnets within that supernet) or excess information (prefix is announced as two /17's instead of a single /16) and can otherwise be summarized to save space in the RIB. It appears to me that the weekly CIDR report shows similar numbers: Recent Table History Date Prefixes CIDR Agg 30-05-14 502889 283047 31-05-14 502961 283069 01-06-14 502836 283134 02-06-14 502943 283080 03-06-14 502793 283382 04-06-14 503177 282897 05-06-14 503436 283062 06-06-14 503988 282999 In this case, does the 512k limit of the 6500/7600 refer to the RIB or the FIB? And does it even matter since the BGP prefix table can automatically be reduced to ~300k routes? Thanks, --Blake Drew Weaver wrote the following on 5/6/2014 10:39 AM: > Hi all, > > I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. > > We are at about 94/95% right now of 512K. > > For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. > > Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. > > In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. > > Just something to think about before it becomes a story the community talks about for the next decade. > > -Drew > From lukasz at bromirski.net Tue Jun 10 17:15:54 2014 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Tue, 10 Jun 2014 19:15:54 +0200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <53973A8E.9010602@ispn.net> References: <53973A8E.9010602@ispn.net> Message-ID: Hi Blake, On 10 Jun 2014, at 19:04, Blake Hudson wrote: > In this case, does the 512k limit of the 6500/7600 refer to the RIB or the FIB? And does it even matter since the BGP prefix table can automatically be reduced to ~300k routes? Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for 1M IPv4 prefixes. You can find more information here: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html And yes, you’re right - no matter how many neighbors you have, the FIB will only contain best paths, so it will be closer to 500k entries in total rather than N times number of neighbours. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From joelja at bogus.com Tue Jun 10 17:33:56 2014 From: joelja at bogus.com (joel jaeggli) Date: Tue, 10 Jun 2014 10:33:56 -0700 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <53973A8E.9010602@ispn.net> Message-ID: <53974184.9030804@bogus.com> On 6/10/14, 10:15 AM, Łukasz Bromirski wrote: > Hi Blake, > > On 10 Jun 2014, at 19:04, Blake Hudson wrote: > >> In this case, does the 512k limit of the 6500/7600 refer to the RIB or the FIB? And does it even matter since the BGP prefix table can automatically be reduced to ~300k routes? > > Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 > Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for > 1M IPv4 prefixes. > > You can find more information here: > > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html > > And yes, you’re right - no matter how many neighbors you have, the FIB > will only contain best paths, so it will be closer to 500k entries in > total rather than N times number of neighbours. Until you add multi-as multipath and addpath and a couple VRFs and all of sudden FIB budget blows up. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 286 bytes Desc: OpenPGP digital signature URL: From blake at ispn.net Tue Jun 10 17:39:48 2014 From: blake at ispn.net (Blake Hudson) Date: Tue, 10 Jun 2014 12:39:48 -0500 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <53973A8E.9010602@ispn.net> Message-ID: <539742E4.70108@ispn.net> Łukasz Bromirski wrote the following on 6/10/2014 12:15 PM: > Hi Blake, > > On 10 Jun 2014, at 19:04, Blake Hudson wrote: > >> In this case, does the 512k limit of the 6500/7600 refer to the RIB or the FIB? And does it even matter since the BGP prefix table can automatically be reduced to ~300k routes? > Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 > Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for > 1M IPv4 prefixes. > > You can find more information here: > > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html > > And yes, you’re right - no matter how many neighbors you have, the FIB > will only contain best paths, so it will be closer to 500k entries in > total rather than N times number of neighbours. > Please correct me if I'm wrong, but if the BGP table contains ~500k prefixes, which are then summarized into ~300k routes (RIB), and the FIB contains only the "best path" entries from the RIB, wouldn't the FIB be at or below 300k? --Blake From danny at danysek.cz Tue Jun 10 17:54:29 2014 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 10 Jun 2014 19:54:29 +0200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <53973A8E.9010602@ispn.net> References: <53973A8E.9010602@ispn.net> Message-ID: <53974655.4080206@danysek.cz> Hello, On 10.6.2014 19:04, Blake Hudson wrote: > I haven't seen anyone bring up this point yet, but I feel like I'm > missing something... > I receive a full BGP table from several providers. They send me ~490k > *prefixes* each. However, my router shows ~332k *subnets* in the routing > table. As I understand it, the BGP table contains duplicate information > (for example a supernet is announced as well as all subnets within that > supernet) or excess information (prefix is announced as two /17's > instead of a single /16) and can otherwise be summarized to save space > in the RIB. many people deaggregate their address space purposely, including large networks like Google, Akamai, Netflix etc. Full list for analysis like "who does that" is available at http://www.cidr-report.org/as2.0/aggr.html These days also some people split their allocated aggregatable space (PA) with different routing policies for each subnet, substituting old PI addresses (at least in RIPE region). Technically nothing blocks this and politically - it's up to each, what accepts. But some unreachable subnet means problems with customers... There's no summarization in hardware/software from RIB to FIB. From the vendor perspective, they would like to sell you new hardware with larger TCAMs/etc, of course... :-) With regards, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4240 bytes Desc: S/MIME Cryptographic Signature URL: From lukasz at bromirski.net Tue Jun 10 18:07:35 2014 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Tue, 10 Jun 2014 20:07:35 +0200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <539742E4.70108@ispn.net> References: <53973A8E.9010602@ispn.net> <539742E4.70108@ispn.net> Message-ID: On 10 Jun 2014, at 19:39, Blake Hudson wrote: >> And yes, you’re right - no matter how many neighbors you have, the FIB >> will only contain best paths, so it will be closer to 500k entries in >> total rather than N times number of neighbours. > Please correct me if I'm wrong, but if the BGP table contains ~500k prefixes, which are then summarized into ~300k routes (RIB), and the FIB contains only the "best path" entries from the RIB, wouldn't the FIB be at or below 300k? Because you need to do your own summarization or ask your upstreams to do it for you. Until then, most of transit accepts loosely prefixes in exact length but also longer (i.e. /24 but also both /25s). You’ll see more and more deaggregation with the rise of smaller entities fighting for chance to do some traffic engineering, so be prepared to constant rise of prefixes overall. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From joelja at bogus.com Tue Jun 10 18:10:53 2014 From: joelja at bogus.com (joel jaeggli) Date: Tue, 10 Jun 2014 11:10:53 -0700 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <539742E4.70108@ispn.net> References: <53973A8E.9010602@ispn.net> <539742E4.70108@ispn.net> Message-ID: <53974A2D.6060407@bogus.com> On 6/10/14, 10:39 AM, Blake Hudson wrote: > > Łukasz Bromirski wrote the following on 6/10/2014 12:15 PM: >> Hi Blake, >> >> On 10 Jun 2014, at 19:04, Blake Hudson wrote: >> >>> In this case, does the 512k limit of the 6500/7600 refer to the RIB >>> or the FIB? And does it even matter since the BGP prefix table can >>> automatically be reduced to ~300k routes? >> Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 >> Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for >> 1M IPv4 prefixes. >> >> You can find more information here: >> >> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html >> >> >> And yes, you’re right - no matter how many neighbors you have, the FIB >> will only contain best paths, so it will be closer to 500k entries in >> total rather than N times number of neighbours. >> > > Please correct me if I'm wrong, but if the BGP table contains ~500k > prefixes, which are then summarized into ~300k routes (RIB), Unlikely, just because prefixes could be cidr aggregated doesn't mean they are. the more specifics exist for a reason, in the case of deaggrates with no covering anouncement, well not much you're doing with those. your rib should be the sum of all received routes that you did not filter. > and the FIB > contains only the "best path" entries from the RIB, wouldn't the FIB be > at or below 300k? a live example of rib size from a router with two transit providers. bird> show route count 979842 of 979842 routes for 490932 networks a live example of rib size from a router with one ibgp peer with addpath and three upstream transit providers bird> show route count 1471242 of 1471242 routes for 491977 networks > > --Blake > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 286 bytes Desc: OpenPGP digital signature URL: From blake at ispn.net Tue Jun 10 18:36:09 2014 From: blake at ispn.net (Blake Hudson) Date: Tue, 10 Jun 2014 13:36:09 -0500 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <53974A2D.6060407@bogus.com> References: <53973A8E.9010602@ispn.net> <539742E4.70108@ispn.net> <53974A2D.6060407@bogus.com> Message-ID: <53975019.1040206@ispn.net> joel jaeggli wrote the following on 6/10/2014 1:10 PM: > On 6/10/14, 10:39 AM, Blake Hudson wrote: >> Łukasz Bromirski wrote the following on 6/10/2014 12:15 PM: >>> Hi Blake, >>> >>> On 10 Jun 2014, at 19:04, Blake Hudson wrote: >>> >>>> In this case, does the 512k limit of the 6500/7600 refer to the RIB >>>> or the FIB? And does it even matter since the BGP prefix table can >>>> automatically be reduced to ~300k routes? >>> Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 >>> Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for >>> 1M IPv4 prefixes. >>> >>> You can find more information here: >>> >>> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html >>> >>> >>> And yes, you’re right - no matter how many neighbors you have, the FIB >>> will only contain best paths, so it will be closer to 500k entries in >>> total rather than N times number of neighbours. >>> >> Please correct me if I'm wrong, but if the BGP table contains ~500k >> prefixes, which are then summarized into ~300k routes (RIB), > Unlikely, just because prefixes could be cidr aggregated doesn't mean > they are. the more specifics exist for a reason, in the case of > deaggrates with no covering anouncement, well not much you're doing with > those. > > your rib should be the sum of all received routes that you did not filter. On the couple Cisco platforms I have available with full tables, Cisco summarizes BGP by default. Since this thread is talking about Cisco gear, I think it's more topical than results from BIRD. One example from a non-transit AS: ASR#sh ip route sum IP routing table name is default (0x0) IP routing table maximum-paths is 32 Route Source Networks Subnets Replicates Overhead Memory (bytes) connected 0 10 0 600 1800 static 1 2 0 180 540 application 0 0 0 0 0 bgp xxxxx 164817 330796 0 29736780 89210340 External: 495613 Internal: 0 Local: 0 internal 5799 20123680 Total 170617 330808 0 29737560 109336360 >> and the FIB >> contains only the "best path" entries from the RIB, wouldn't the FIB be >> at or below 300k? > a live example of rib size from a router with two transit providers. > > bird> show route count > 979842 of 979842 routes for 490932 networks > > a live example of rib size from a router with one ibgp peer with addpath > and three upstream transit providers > > bird> show route count > 1471242 of 1471242 routes for 491977 networks > > The RIB counts and memory used by the RIB seem to be nearly identical between a Cisco router with 3 full BGP feeds and another with 1 BGP feed. The differences seem to lie in the memory used by BGP for prefix tracking. If your router has multiple routing tables, or your installing multiple routes for the same prefix in the RIB, then I can understand why your RIB will be larger. These are nice features, but certainly not a requirement for everyone. --Blake From mark.tinka at seacom.mu Tue Jun 10 19:18:38 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 10 Jun 2014 21:18:38 +0200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <539742E4.70108@ispn.net> Message-ID: <201406102118.42526.mark.tinka@seacom.mu> On Tuesday, June 10, 2014 08:07:35 PM Łukasz Bromirski wrote: > Because you need to do your own summarization or ask your > upstreams to do it for you. Until then, most of transit > accepts loosely prefixes in exact length but also longer > (i.e. /24 but also both /25s). A couple of major service providers today permit announcements of any length, provided they are registered in an IRR that they use to build filters. Of course, there are no guarantees that prefixes typically longer than general industry practice permits will see the light of day beyond their network. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mpetach at netflight.com Wed Jun 11 00:03:09 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 10 Jun 2014 17:03:09 -0700 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <53975019.1040206@ispn.net> References: <53973A8E.9010602@ispn.net> <539742E4.70108@ispn.net> <53974A2D.6060407@bogus.com> <53975019.1040206@ispn.net> Message-ID: On Tue, Jun 10, 2014 at 11:36 AM, Blake Hudson wrote: > > joel jaeggli wrote the following on 6/10/2014 1:10 PM: > > On 6/10/14, 10:39 AM, Blake Hudson wrote: >> >>> Łukasz Bromirski wrote the following on 6/10/2014 12:15 PM: >>> >>>> Hi Blake, >>>> >>>> On 10 Jun 2014, at 19:04, Blake Hudson wrote: >>>> >>>> In this case, does the 512k limit of the 6500/7600 refer to the RIB >>>>> or the FIB? And does it even matter since the BGP prefix table can >>>>> automatically be reduced to ~300k routes? >>>>> >>>> Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 >>>> Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for >>>> 1M IPv4 prefixes. >>>> >>>> You can find more information here: >>>> >>>> http://www.cisco.com/c/en/us/support/docs/switches/ >>>> catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html >>>> >>>> >>>> And yes, you’re right - no matter how many neighbors you have, the FIB >>>> will only contain best paths, so it will be closer to 500k entries in >>>> total rather than N times number of neighbours. >>>> >>>> Please correct me if I'm wrong, but if the BGP table contains ~500k >>> prefixes, which are then summarized into ~300k routes (RIB), >>> >> Unlikely, just because prefixes could be cidr aggregated doesn't mean >> they are. the more specifics exist for a reason, in the case of >> deaggrates with no covering anouncement, well not much you're doing with >> those. >> >> your rib should be the sum of all received routes that you did not filter. >> > On the couple Cisco platforms I have available with full tables, Cisco > summarizes BGP by default. Since this thread is talking about Cisco gear, I > think it's more topical than results from BIRD. > > One example from a non-transit AS: > ASR#sh ip route sum > IP routing table name is default (0x0) > > IP routing table maximum-paths is 32 > Route Source Networks Subnets Replicates Overhead Memory > (bytes) > connected 0 10 0 600 1800 > static 1 2 0 180 540 > application 0 0 0 0 0 > bgp xxxxx 164817 330796 0 29736780 89210340 > External: 495613 Internal: 0 Local: 0 > internal 5799 20123680 > Total 170617 330808 0 29737560 109336360 > > I'm not sure you're reading that correctly. 164817+330796 = 495613 That is, the BGP routing table size is the union of the "Networks" and the "Subnets"; it's not magically doing any summarization for you. Matt From eoosting at netuf.net Wed Jun 11 00:30:11 2014 From: eoosting at netuf.net (Eric Oosting) Date: Tue, 10 Jun 2014 20:30:11 -0400 Subject: NANOG 62 and a new tool for presentation submissions Message-ID: Today we began an upgrade to the site/tool located at pc.nanog.org, known as the pc tool, which is designed to allow the community to propose talks for the next NANOG. The new site has some of the latest fads in web 2.0 web design and buzzwords, for instance we've decided to use a programming language with silent "d" in the name. Don't worry, it's somewhere short of having tag clouds. We hope you like it. Or at least, we hope not too many of you despise it. Please hold of on any talk submissions for a few days while we migrate the data from the old tool to the new. The NANOG Program Committee will issue the NANOG61 call for presentations shortly, marking the availability of the new tool. Thanks, -e -- Eric Oosting Network Architect eoosting at netuf.net | 404-941-6678 From randy at psg.com Wed Jun 11 00:54:08 2014 From: randy at psg.com (Randy Bush) Date: Tue, 10 Jun 2014 17:54:08 -0700 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: as many people will be hitting the wall on all sorts of platforms, perhaps it's wiki time. or have i just missed it? randy From tony at wicks.co.nz Wed Jun 11 01:44:36 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Wed, 11 Jun 2014 13:44:36 +1200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <007901cf6a47$2005ff80$6011fe80$@wicks.co.nz> References: <536969E5.6080608@cox.net> <007901cf6a47$2005ff80$6011fe80$@wicks.co.nz> Message-ID: <019a01cf8516$b3e09b90$1ba1d2b0$@wicks.co.nz> My 2c: The obvious thing for me is if people are running a full ipv4 route table on a box only just capable of handling one single table of that size, then really now is the time to asses if you really need to hold that table or just drop to default +internal+peers. If you have multiple up streams and you are using the route tables to do your route selection then great, but that means you need at least 1M capability now, and really 2+ should be your target. In my experience people running a full table on a small capability box normally don't actually need to carry it, or they just need a bigger box. From jvanoppen at spectrumnet.us Wed Jun 11 05:14:34 2014 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Wed, 11 Jun 2014 05:14:34 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <019a01cf8516$b3e09b90$1ba1d2b0$@wicks.co.nz> References: <536969E5.6080608@cox.net> <007901cf6a47$2005ff80$6011fe80$@wicks.co.nz> <019a01cf8516$b3e09b90$1ba1d2b0$@wicks.co.nz> Message-ID: FIB is not the same as RIB... Perfectly happy 6509, many paths, only one full table in the FIB: BGP router identifier XXX , local AS number 11404 BGP table version is 40916063, main routing table version 40916063 494649 network entries using 71229456 bytes of memory 886903 path entries using 70952240 bytes of memory 29 multipath network entries and 58 multipath paths -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tony Wicks Sent: Tuesday, June 10, 2014 6:45 PM To: 'nanog' Subject: RE: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. My 2c: The obvious thing for me is if people are running a full ipv4 route table on a box only just capable of handling one single table of that size, then really now is the time to asses if you really need to hold that table or just drop to default +internal+peers. If you have multiple up streams and you are using the route tables to do your route selection then great, but that means you need at least 1M capability now, and really 2+ should be your target. In my experience people running a full table on a small capability box normally don't actually need to carry it, or they just need a bigger box. From saku at ytti.fi Wed Jun 11 06:28:07 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 11 Jun 2014 09:28:07 +0300 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <539742E4.70108@ispn.net> References: <53973A8E.9010602@ispn.net> <539742E4.70108@ispn.net> Message-ID: <20140611062807.GA21771@pob.ytti.fi> On (2014-06-10 12:39 -0500), Blake Hudson wrote: > Please correct me if I'm wrong, but if the BGP table contains ~500k > prefixes, which are then summarized into ~300k routes (RIB), and the FIB > contains only the "best path" entries from the RIB, wouldn't the FIB be at > or below 300k? There is nothing to summarize away from global BGP table, if you have number showing less, it's probably counter bug or misinterpretation. Global BGP table, single BGP feed, will take same amount of RIB and FIB. You can see your FIB use in 'show plat hard capa pfc': #show platform hardware capacity pfc Module FIB TCAM usage: Total Used %Used 2 72 bits (IPv4, MPLS, EoM) 884736 712819 81% 144 bits (IP mcast, IPv6) 81920 19235 23% You're probably bit better off than I am :) -- ++ytti From mysidia at gmail.com Wed Jun 11 09:07:22 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 11 Jun 2014 04:07:22 -0500 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <20140611062807.GA21771@pob.ytti.fi> References: <53973A8E.9010602@ispn.net> <539742E4.70108@ispn.net> <20140611062807.GA21771@pob.ytti.fi> Message-ID: On Wed, Jun 11, 2014 at 1:28 AM, Saku Ytti wrote: > On (2014-06-10 12:39 -0500), Blake Hudson wrote: > There is nothing to summarize away from global BGP table, if you have number > showing less, it's probably counter bug or misinterpretation. > Global BGP table, single BGP feed, will take same amount of RIB and FIB. [snip] That depends.... if by "summarize" they mean filter prefixes longer than say /22, or otherwise...: discard extraneous prefixes from networks that were allocated a /16 network but chose to deaggregate and advertise every /24 ------ choosing to accept only the /16 advertisement instead of installing these extra /24 routes in the FIB, then there are plenty of entries to "summarize" away. -- -JH From blake at ispn.net Wed Jun 11 13:53:02 2014 From: blake at ispn.net (Blake Hudson) Date: Wed, 11 Jun 2014 08:53:02 -0500 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <53973A8E.9010602@ispn.net> <539742E4.70108@ispn.net> <53974A2D.6060407@bogus.com> <53975019.1040206@ispn.net> Message-ID: <53985F3E.2010609@ispn.net> Matthew Petach wrote the following on 6/10/2014 7:03 PM: > > On the couple Cisco platforms I have available with full tables, Cisco > summarizes BGP by default. Since this thread is talking about Cisco > gear, I think it's more topical than results from BIRD. > > > One example from a non-transit AS: > ASR#sh ip route sum > IP routing table name is default (0x0) > > IP routing table maximum-paths is 32 > Route Source Networks Subnets Replicates Overhead > Memory (bytes) > connected 0 10 0 600 1800 > static 1 2 0 180 540 > application 0 0 0 0 0 > bgp xxxxx 164817 330796 0 29736780 89210340 > External: 495613 Internal: 0 Local: 0 > internal 5799 20123680 > Total 170617 330808 0 29737560 109336360 > > > > I'm not sure you're reading that correctly. > 164817+330796 = 495613 > > That is, the BGP routing table size is the > union of the "Networks" and the "Subnets"; > it's not magically doing any summarization > for you. > > Matt > > Thank you Matt for directly addressing my question. My interpretation, which seems likely incorrect, was that smaller announcements could be discarded if there was a covering prefix (that otherwise matched the same AS path and other BGP metrics) and that many smaller prefix announcements could be bundled (again, assuming that all BGP metrics were the same between the prefixes). The numbers I was seeing in my routers for subnets coincided closely with the cidr-report's summzarization numbers http://www.cidr-report.org/as2.0/aggr.html, and I assumed the two used the same logic (not magic) to calculate how to reduce routes without losing any routing functionality. Your explanation that I was simply interpreting the numbers incorrectly seems the most logical now that I look again. Thanks, --Blake From stucchi-lists at glevia.com Wed Jun 11 15:14:50 2014 From: stucchi-lists at glevia.com (Massimiliano Stucchi) Date: Wed, 11 Jun 2014 17:14:50 +0200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> <0b214a987b20192a26851c1409ed9575@jonesy.com.au> <20140610101021.GA18623@pob.ytti.fi> Message-ID: <5398726A.5080408@glevia.com> On 10/06/14 12:28, Bjoern A. Zeeb wrote: > You mean it’s more likely people acquire/merge with other companies for IP space then go through transfer? https://www.arin.net/knowledge/statistics/ You have to consider that most likely there will be an increase in de-aggregation due to: - The RIRs allocating smaller and smaller address space to every member, even smaller than a /24; - The RIRs allocating from smaller, fragmented allocations received from IANA. This means that it would also be possible - in theory - for example, to receive an allocation for a /22, sparse in two, non-contiguous, /23s (or a similar situation). - The holders of large parts of address space monetizing via transfers, thus fragmenting even more. Ciao! -- Max From koalafil at gmail.com Wed Jun 11 15:48:19 2014 From: koalafil at gmail.com (Filiz Yilmaz) Date: Wed, 11 Jun 2014 17:48:19 +0200 Subject: Call for Presentations RIPE 69 Message-ID: Dear colleagues, Please find the CFP for RIPE 69 in London below. The deadline for submissions is 31 August 2014. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards Filiz Yilmaz RIPE PC Chair http://www.ripe.net/ripe/meetings/ripe-meetings/pc --------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 69 will take place from 3- November 2014 in London, UK. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 69. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: • IPv6 deployment • Managing IPv4 scarcity in operations • Commercial transactions of IPv4 addresses • Data centre technologies • Network and DNS operations • Internet governance and regulatory practices • Network and routing security • Content delivery • Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe69.ripe.net/submit-topic/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for “lightning talks”, which are selected immediately before or during the conference. The following general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 31 August 2014, using the meeting submission system at https://ripe69.ripe.net/submit-topic/guidelines/. Proposals submitted after this date will be considered on a space-available basis. - Lightning talks should also be submitted using the meeting submission system (https://ripe69.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice – in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format at https://ripe69.ripe.net/submit-topic/presentation-formats/ - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. --------------------- From psirt at cisco.com Wed Jun 11 16:03:36 2014 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 11 Jun 2014 12:03:36 -0400 Subject: Cisco Security Advisory: Cisco IOS XR Software IPv6 Malformed Packet Denial of Service Vulnerability Message-ID: <201406111203.17.ipv6@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS XR Software IPv6 Malformed Packet Denial of Service Vulnerability Advisory ID: cisco-sa-20140611-ipv6 Revision 1.0 For Public Release 2014 June 11 16:00 UTC (GMT) Summary ======= A vulnerability in the parsing of malformed Internet Protocol version 6 (IPv6) packets in Cisco IOS XR Software for ASR 9000 Series Aggregation Services Routers could allow an unauthenticated, remote attacker to cause a lockup and eventual reload of a Network Processor (NP) chip and a line card processing traffic. Only Trident-based line cards on Cisco ASR 9000 Series Aggregation Services Routers are affected by this vulnerability. The vulnerability is due to insufficient logic in parsing malformed IPv6 packets. An attacker could exploit this vulnerability by sending a stream of malformed IPv6 packets to the affected device. An exploit could allow the attacker to cause a lockup and eventual reload of an NP chip and a line card, leading to a denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. There are no workarounds that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140611-ipv6 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTmF6XAAoJEIpI1I6i1Mx39ewP/05Z15cOVZKPHsTZQ0nk10Mf LuR8znSVolxIOJl3KWw7Liorml2kAy5mP9lQuMq2AKy/ifDb1CkBRGhpSXAJys9l MHrlg2Bvkm2+oacv8L9m1GLMCzOREc5ItvjXeEjZIzkaM4RrPvTSI79YOxYFjAIK jnrfdk2s9IBTvedB5bib5cpVal7X5T5E7TL0eIizpJzhSrzd/opsVeITOzcqoniU 9L7F5tQJ7RrhMipRKBFrDNp49u0MB3FgiLL+PvR2Qd4ErKmuUsA4MwAsh20krshi e3XVhYgVzqdodVSdphZeAA753yFJYD+ot8rzxW28MoaBfLC7jl23eEUsmAVZ5BO+ /xJ2S1rvHxQhAqaWSOo3dOOHspGtFk7/ZqMAIoKM+w/qx6O6IyY4SgdEYaKLWMDw H+7ya7XXCHfx3BRz9mlnfE7yNrmG+/P95rtyW4zuLuCOwAm/vm+xasj2E2Uts7VV iSLXlH7MNB3PjBkHXomMkvmLaDF5PvbKhlKoinMmJpDhKT286Jjn9RiDGaiVJdH4 rHNjTTVFoYsXLYnHrtpybfYLWmd9OMRYp/nVh75gzm7IvPnN6CCCl8LaHNOq1hcH 4V62x5LrN95yDR83n+weZouWlWcLMVU/aKIlSiN0O0+8/7dOmbgMjjtf8nvkBB6n 0fff2LUlieosr03ZacDo =rfKB -----END PGP SIGNATURE----- From jcurran at arin.net Wed Jun 11 11:06:29 2014 From: jcurran at arin.net (John Curran) Date: Wed, 11 Jun 2014 11:06:29 +0000 Subject: Bogus routes with regional free pool depletion (was: Re: The Cidr Report) In-Reply-To: <201406062200.s56M00SM096661@wattle.apnic.net> References: <201406062200.s56M00SM096661@wattle.apnic.net> Message-ID: <2A402A6E-CE69-4280-8B1C-1D13AE81A1BC@arin.net> Folks - As noted in a prior message to the "nanog" mailing list, it is quite likely that some of the address blocks listed in this CIDR report under the heading "Possible Bogus Routes" will shortly be issued to requesters. In the case of unassigned blocks in the ARIN free pool, this is expected to be in the second half of this year (2014). If you are currently sourcing routes for one of these address blocks, it may be prudent to start reviewing the basis for doing so, as any issuance would likely result in unexpected operational impacts once put into use by the recipient. If there is some confusion regarding the registration status of one of these blocks, then having the current party making use of the block raise the issue with the respective RIR would be a wise proactive measure. FYI, /John John Curran President and CEO ARIN On Jun 6, 2014, at 6:00 PM, cidr-report at potaroo.net wrote: > ... > Possible Bogus Routes > > 27.100.7.0/24 AS56096 > 41.73.1.0/24 AS37004 -Reserved AS-,ZZ > 41.73.2.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.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US > 41.78.236.0/24 AS37290 -Reserved AS-,ZZ > 41.78.237.0/24 AS37290 -Reserved AS-,ZZ > 41.78.238.0/24 AS37290 -Reserved AS-,ZZ > 41.78.239.0/24 AS37290 -Reserved AS-,ZZ > 41.189.96.0/20 AS37000 -Reserved AS-,ZZ > 41.190.72.0/24 AS37451 CongoTelecom,CG > 41.190.73.0/24 AS37451 CongoTelecom,CG > 41.190.74.0/24 AS37451 CongoTelecom,CG > 41.190.75.0/24 AS37451 CongoTelecom,CG > 41.191.108.0/22 AS37004 -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 > 43.252.104.0/22 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID > 43.252.104.0/24 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID > 43.252.105.0/24 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID > 43.252.106.0/24 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID > 43.252.107.0/24 AS45305 LDP-AS-ID Lintas Data Prima, PT,ID > 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 64.25.16.0/23 AS19535 -Reserved AS-,ZZ > 64.25.20.0/24 AS19535 -Reserved AS-,ZZ > 64.25.21.0/24 AS19535 -Reserved AS-,ZZ > 64.25.22.0/24 AS19535 -Reserved AS-,ZZ > 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US > 64.111.160.0/20 AS40551 -Reserved AS-,ZZ > 64.111.160.0/24 AS40551 -Reserved AS-,ZZ > 64.111.161.0/24 AS40551 -Reserved AS-,ZZ > 64.111.162.0/24 AS40551 -Reserved AS-,ZZ > 64.111.167.0/24 AS40551 -Reserved AS-,ZZ > 64.111.169.0/24 AS40551 -Reserved AS-,ZZ > 64.111.170.0/24 AS40551 -Reserved AS-,ZZ > 64.111.171.0/24 AS40551 -Reserved AS-,ZZ > 64.111.172.0/24 AS40551 -Reserved AS-,ZZ > 64.111.173.0/24 AS40551 -Reserved AS-,ZZ > 64.111.174.0/24 AS40551 -Reserved AS-,ZZ > 64.111.175.0/24 AS40551 -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 > 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US > 66.55.96.0/23 AS17203 -Reserved AS-,ZZ > 66.55.98.0/24 AS17203 -Reserved AS-,ZZ > 66.55.99.0/24 AS17203 -Reserved AS-,ZZ > 66.55.100.0/22 AS17203 -Reserved AS-,ZZ > 66.55.102.0/23 AS17203 -Reserved AS-,ZZ > 66.55.104.0/21 AS17203 -Reserved AS-,ZZ > 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 > 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT > 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US > 74.112.100.0/22 AS16764 -Reserved AS-,ZZ > 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.115.124.0/23 AS46540 -Reserved AS-,ZZ > 74.118.132.0/22 AS5117 -Reserved AS-,ZZ > 74.120.212.0/23 AS32326 -Reserved AS-,ZZ > 74.120.214.0/23 AS32326 -Reserved AS-,ZZ > 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US > 77.243.80.0/24 AS42597 -Reserved AS-,ZZ > 77.243.81.0/24 AS42597 -Reserved AS-,ZZ > 77.243.88.0/24 AS42597 -Reserved AS-,ZZ > 77.243.91.0/24 AS42597 -Reserved AS-,ZZ > 77.243.94.0/24 AS42597 -Reserved AS-,ZZ > 77.243.95.0/24 AS42597 -Reserved AS-,ZZ > 80.250.32.0/22 AS37106 ODUA-AS,NG > 85.202.160.0/20 AS44404 -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.199.90.0/24 AS44330 -Reserved AS-,ZZ > 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE > 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT > 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB > 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 93.190.10.0/24 AS47254 -Reserved AS-,ZZ > 95.215.140.0/22 AS48949 -Reserved AS-,ZZ > 100.88.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.89.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.90.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.91.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.92.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.93.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.94.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.95.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.96.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.104.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.112.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.120.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 100.124.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY > 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN > 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP > 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN > 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP > 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK > 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK > 103.18.92.0/22 AS13269 > 103.18.92.0/24 AS13269 > 103.18.94.0/24 AS13269 > 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP > 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP > 103.23.48.0/24 AS56194 > 103.23.49.0/24 AS56194 > 103.23.50.0/24 AS56194 > 103.23.51.0/24 AS56194 > 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP > 103.249.132.0/22 AS18097 DCN D.C.N. Corporation,JP > 104.36.184.0/22 AS4891 FERRI-3 - Ferric Systems, LLC,US > 104.36.224.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US > 104.36.232.0/21 AS54755 DWW-AS - Desert Winds Wireless Inc,US > 104.36.240.0/21 AS23175 POGOZONE - PogoZone,US > 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU > 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK > 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 > 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN > 124.158.28.0/22 AS45857 > 148.163.0.0/18 AS53755 IOFLOOD - Input Output Flood LLC,US > 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP > 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US > 172.85.0.0/24 AS29571 CITelecom-AS,CI > 172.85.1.0/24 AS29571 CITelecom-AS,CI > 172.85.2.0/24 AS29571 CITelecom-AS,CI > 172.85.3.0/24 AS29571 CITelecom-AS,CI > 172.86.0.0/24 AS29571 CITelecom-AS,CI > 172.86.1.0/24 AS29571 CITelecom-AS,CI > 172.86.2.0/24 AS29571 CITelecom-AS,CI > 172.87.0.0/24 AS29571 CITelecom-AS,CI > 172.88.0.0/24 AS29571 CITelecom-AS,CI > 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN > 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 173.213.208.0/22 AS54040 -Reserved AS-,ZZ > 173.213.212.0/24 AS54040 -Reserved AS-,ZZ > 173.213.213.0/24 AS54040 -Reserved AS-,ZZ > 173.213.214.0/23 AS54040 -Reserved AS-,ZZ > 173.213.216.0/21 AS54040 -Reserved AS-,ZZ > 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO > 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ > 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ > 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN > 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO > 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR > 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.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,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.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,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.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,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 AS3322 -Reserved AS-,ZZ > 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE > 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB > 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE > 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.84.187.0/24 AS16276 OVH OVH SAS,FR > 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB > 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO > 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.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO > 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO > 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.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US > 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT > 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO > 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.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB > 193.223.103.0/24 AS3248 SIL-AT 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 > 193.243.166.0/24 AS44093 -Reserved AS-,ZZ > 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 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.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB > 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.60.88.0/21 AS5089 NTL Virgin Media Limited,GB > 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB > 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE > 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech 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.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR > 194.146.36.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR > 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE > 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE > 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.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO > 195.39.252.0/23 AS29004 -Reserved AS-,ZZ > 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE > 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO > 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.2.224.0/22 AS24863 LINKdotNET-AS,EG > 196.3.182.0/24 AS37004 -Reserved AS-,ZZ > 196.3.183.0/24 AS37004 -Reserved AS-,ZZ > 196.13.201.0/24 AS2018 TENET-1,ZA > 196.13.202.0/24 AS2018 TENET-1,ZA > 196.13.203.0/24 AS2018 TENET-1,ZA > 196.13.204.0/24 AS2018 TENET-1,ZA > 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 > 196.45.0.0/21 AS26625 -Reserved AS-,ZZ > 196.45.10.0/24 AS26625 -Reserved AS-,ZZ > 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US > 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.192.0/20 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.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA > 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA > 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK > 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 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.116.200.0/21 AS22830 -Reserved AS-,ZZ > 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US > 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 > 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US > 200.58.248.0/21 AS27849 > 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 > 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR > 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR > 202.9.40.0/24 AS56194 > 202.9.41.0/24 AS56194 > 202.9.42.0/24 AS56194 > 202.9.43.0/24 AS56194 > 202.9.44.0/24 AS56194 > 202.9.45.0/24 AS56194 > 202.9.46.0/24 AS56194 > 202.9.47.0/24 AS56194 > 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK > 202.58.113.0/24 AS19161 -Reserved AS-,ZZ > 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN > 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG > 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN > 203.142.219.0/24 AS45149 > 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.10.94.0/23 AS30097 NUWAVE - NuWave,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.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US > 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB > 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA > 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.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,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.128.0/24 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.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US > 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.73.112.0/24 AS19231 -Reserved AS-,ZZ > 208.73.113.0/24 AS19231 -Reserved AS-,ZZ > 208.73.114.0/24 AS19231 -Reserved AS-,ZZ > 208.73.115.0/24 AS19231 -Reserved AS-,ZZ > 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.234.0/24 AS33131 -Reserved AS-,ZZ > 208.84.237.0/24 AS33131 -Reserved AS-,ZZ > 208.84.238.0/24 AS33131 -Reserved AS-,ZZ > 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US > 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US > 209.17.224.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.225.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.226.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.227.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.228.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.229.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.230.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.231.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.232.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.233.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.234.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.235.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.236.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.237.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.238.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.239.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.240.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.241.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.242.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.243.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.244.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.245.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.246.0/24 AS14846 CGNOGE - NBC Internet,US > 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US > 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US > 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US > 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,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 > 212.119.32.0/19 AS12550 -Reserved AS-,ZZ > 213.184.64.0/24 AS13071 -Reserved AS-,ZZ > 213.184.65.0/24 AS13071 -Reserved AS-,ZZ > 213.184.66.0/24 AS13071 -Reserved AS-,ZZ > 213.184.67.0/24 AS13071 -Reserved AS-,ZZ > 213.184.68.0/24 AS13071 -Reserved AS-,ZZ > 213.184.69.0/24 AS13071 -Reserved AS-,ZZ > 213.184.70.0/24 AS13071 -Reserved AS-,ZZ > 213.184.71.0/24 AS13071 -Reserved AS-,ZZ > 213.184.72.0/24 AS13071 -Reserved AS-,ZZ > 213.184.73.0/24 AS13071 -Reserved AS-,ZZ > 213.184.74.0/24 AS13071 -Reserved AS-,ZZ > 213.184.75.0/24 AS13071 -Reserved AS-,ZZ > 213.184.76.0/24 AS13071 -Reserved AS-,ZZ > 213.184.77.0/24 AS13071 -Reserved AS-,ZZ > 213.184.78.0/24 AS13071 -Reserved AS-,ZZ > 213.255.128.0/20 AS24863 LINKdotNET-AS,EG > 213.255.144.0/20 AS24863 LINKdotNET-AS,EG > 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US > 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US > 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,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.178.96.0/21 AS17035 -Reserved AS-,ZZ > 216.178.104.0/21 AS17035 -Reserved AS-,ZZ > 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US > > > Please see http://www.cidr-report.org for the full report From goemon at anime.net Wed Jun 11 20:00:58 2014 From: goemon at anime.net (goemon at anime.net) Date: Wed, 11 Jun 2014 13:00:58 -0700 (PDT) Subject: yahoo.fr is no longer interested in your abuse reports. Message-ID: Looks like they've finally completely blocked off their abuse mailboxes. ----- The following addresses had permanent fatal errors ----- (reason: 554 Message not allowed - [298]) ----- Transcript of session follows ----- ... while talking to mx-eu.mail.am0.yahoodns.net.: >>> DATA <<< 554 Message not allowed - [298] 554 5.0.0 Service unavailable -Dan From blake at ispn.net Wed Jun 11 20:41:51 2014 From: blake at ispn.net (Blake Hudson) Date: Wed, 11 Jun 2014 15:41:51 -0500 Subject: yahoo.fr is no longer interested in your abuse reports. In-Reply-To: References: Message-ID: <5398BF0F.8040606@ispn.net> goemon at anime.net wrote the following on 6/11/2014 3:00 PM: > Looks like they've finally completely blocked off their abuse mailboxes. > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 Message not allowed - [298]) > > ----- Transcript of session follows ----- > ... while talking to mx-eu.mail.am0.yahoodns.net.: >>>> DATA > <<< 554 Message not allowed - [298] > 554 5.0.0 Service unavailable > > -Dan May just be you... or transient, seems OK to me: # telnet mx-eu.mail.am0.yahoodns.net 25 Trying 188.125.69.79... Connected to mx-eu.mail.am0.yahoodns.net. Escape character is '^]'. 220 mta1157.mail.ir2.yahoo.com ESMTP ready ehlo ispn.net 250-mta1157.mail.ir2.yahoo.com 250-PIPELINING 250-SIZE 41943040 250-8BITMIME 250 STARTTLS mail from: 250 sender ok rcpt to: 250 recipient ok data 354 go ahead test . 250 ok Wed Jun 11 20:40:00 2014: ql 0, qr 93206887 From goemon at anime.net Wed Jun 11 20:41:05 2014 From: goemon at anime.net (goemon at anime.net) Date: Wed, 11 Jun 2014 13:41:05 -0700 (PDT) Subject: yahoo.fr is no longer interested in your abuse reports. In-Reply-To: <5398BF0F.8040606@ispn.net> References: <5398BF0F.8040606@ispn.net> Message-ID: It's the content. They're spamfiltering their abuse mailbox. -Dan On Wed, 11 Jun 2014, Blake Hudson wrote: > > goemon at anime.net wrote the following on 6/11/2014 3:00 PM: >> Looks like they've finally completely blocked off their abuse mailboxes. >> >> ----- The following addresses had permanent fatal errors ----- >> >> (reason: 554 Message not allowed - [298]) >> >> ----- Transcript of session follows ----- >> ... while talking to mx-eu.mail.am0.yahoodns.net.: >>>>> DATA >> <<< 554 Message not allowed - [298] >> 554 5.0.0 Service unavailable >> >> -Dan > > May just be you... or transient, seems OK to me: > > # telnet mx-eu.mail.am0.yahoodns.net 25 > Trying 188.125.69.79... > Connected to mx-eu.mail.am0.yahoodns.net. > Escape character is '^]'. > 220 mta1157.mail.ir2.yahoo.com ESMTP ready > ehlo ispn.net > 250-mta1157.mail.ir2.yahoo.com > 250-PIPELINING > 250-SIZE 41943040 > 250-8BITMIME > 250 STARTTLS > mail from: > 250 sender ok > rcpt to: > 250 recipient ok > data > 354 go ahead > test > . > 250 ok Wed Jun 11 20:40:00 2014: ql 0, qr 93206887 > > From chk at pobox.com Wed Jun 11 21:28:33 2014 From: chk at pobox.com (Harald Koch) Date: Wed, 11 Jun 2014 17:28:33 -0400 Subject: yahoo.fr is no longer interested in your abuse reports. In-Reply-To: References: <5398BF0F.8040606@ispn.net> Message-ID: On 11 June 2014 16:41, wrote: > It's the content. > > They're spamfiltering their abuse mailbox. > As supporting evidence I offer the fact that this entire conversation ended up in my (Google) Junk folder. -- Harald From jhellenthal at dataix.net Wed Jun 11 21:32:25 2014 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 11 Jun 2014 17:32:25 -0400 Subject: yahoo.fr is no longer interested in your abuse reports. In-Reply-To: References: <5398BF0F.8040606@ispn.net> Message-ID: RoJlx100 -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jun 11, 2014, at 17:28, Harald Koch wrote: > >> On 11 June 2014 16:41, wrote: >> >> It's the content. >> >> They're spamfiltering their abuse mailbox. > > > As supporting evidence I offer the fact that this entire conversation ended > up in my (Google) Junk folder. > > -- > Harald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6118 bytes Desc: not available URL: From contact at nullivex.com Thu Jun 12 02:52:31 2014 From: contact at nullivex.com (Bryan Tong) Date: Wed, 11 Jun 2014 20:52:31 -0600 Subject: No route to weather.gov Message-ID: Im wondering if anyone else is seeing strangeness. |------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | DD-WRT - 29 | 7 | 5 | 1 | 1 | 1 | 1 | | No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 | | 69.146.239.53 - 0 | 16 | 16 | 9 | 18 | 58 | 17 | | host-69-144-126-216.static.bresnan.net - 0 | 16 | 16 | 19 | 30 | 58 | 23 | |host-72-175-111-150.bln-mt.client.bresna - 0 | 16 | 16 | 14 | 27 | 57 | 15 | | No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 | -- eSited LLC (701) 390-9638 From jared at puck.nether.net Thu Jun 12 02:55:05 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 11 Jun 2014 22:55:05 -0400 Subject: No route to weather.gov In-Reply-To: References: Message-ID: <36C3046E-F403-450A-8CAE-9D780F4C9345@puck.nether.net> I have no issues reaching AKAMAI(weather.gov) - jared On Jun 11, 2014, at 10:52 PM, Bryan Tong wrote: > Im wondering if anyone else is seeing strangeness. > > |------------------------------------------------------------------------------------------| > | WinMTR statistics > | > | Host - % | Sent | Recv | Best | > Avrg | Wrst | Last | > |------------------------------------------------|------|------|------|------|------|------| > | DD-WRT - 29 | 7 | 5 | 1 | > 1 | 1 | 1 | > | No response from host - 100 | 3 | 0 | 0 | > 0 | 0 | 0 | > | 69.146.239.53 - 0 | 16 | 16 | 9 | > 18 | 58 | 17 | > | host-69-144-126-216.static.bresnan.net - 0 | 16 | 16 | 19 | > 30 | 58 | 23 | > |host-72-175-111-150.bln-mt.client.bresna - 0 | 16 | 16 | 14 | > 27 | 57 | 15 | > | No response from host - 100 | 3 | 0 | 0 | > 0 | 0 | 0 | > | No response from host - 100 | 3 | 0 | 0 | > 0 | 0 | 0 | > | No response from host - 100 | 3 | 0 | 0 | > 0 | 0 | 0 | > | No response from host - 100 | 3 | 0 | 0 | > 0 | 0 | 0 | > -- > eSited LLC > (701) 390-9638 From will at willscorner.net Thu Jun 12 03:05:15 2014 From: will at willscorner.net (Will Dean) Date: Wed, 11 Jun 2014 23:05:15 -0400 Subject: No route to weather.gov In-Reply-To: References: Message-ID: <539918EB.6080809@willscorner.net> I also can't reach weather.gov. traceroute to weather.gov (204.227.127.201), 64 hops max, 72 byte packets 1 192.168.124.1 (192.168.124.1) 0.315 ms 0.140 ms 0.134 ms 2 ge-2-2-0-32767-sur01.michiganave.dc.bad.comcast.net (50.202.87.153) 0.383 ms 0.359 ms 0.339 ms 3 ae-19-0-ar04.whitemarsh.md.bad.comcast.net (68.85.114.133) 29.131 ms 22.402 ms 3.160 ms 4 * * * 5 * * * will$ telnet weather.gov 80 Trying 204.227.127.201... telnet: connect to address 204.227.127.201: Operation timed out telnet: Unable to connect to remote host www.weather.gov has an A record for Akamai which is reachable. will$ telnet www.weather.gov 80 Trying 23.3.108.190... Connected to a895.g.akamai.net. Escape character is '^]'. -- Will From geraint at koding.com Thu Jun 12 03:11:07 2014 From: geraint at koding.com (Geraint Jones) Date: Wed, 11 Jun 2014 20:11:07 -0700 Subject: No route to weather.gov In-Reply-To: <539918EB.6080809@willscorner.net> References: <539918EB.6080809@willscorner.net> Message-ID: AS32878 appears to have disappeared. On Wed, Jun 11, 2014 at 8:05 PM, Will Dean wrote: > I also can't reach weather.gov. > > traceroute to weather.gov (204.227.127.201), 64 hops max, 72 byte packets > 1 192.168.124.1 (192.168.124.1) 0.315 ms 0.140 ms 0.134 ms > 2 ge-2-2-0-32767-sur01.michiganave.dc.bad.comcast.net (50.202.87.153) > 0.383 ms 0.359 ms 0.339 ms > 3 ae-19-0-ar04.whitemarsh.md.bad.comcast.net (68.85.114.133) 29.131 ms > 22.402 ms 3.160 ms > 4 * * * > 5 * * * > > will$ telnet weather.gov 80 > Trying 204.227.127.201... > telnet: connect to address 204.227.127.201: Operation timed out > telnet: Unable to connect to remote host > > www.weather.gov has an A record for Akamai which is reachable. > > will$ telnet www.weather.gov 80 > Trying 23.3.108.190... > Connected to a895.g.akamai.net. > Escape character is '^]'. > > > -- Will > From hslabbert at stargate.ca Thu Jun 12 03:13:34 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Wed, 11 Jun 2014 20:13:34 -0700 Subject: No route to weather.gov In-Reply-To: <36C3046E-F403-450A-8CAE-9D780F4C9345@puck.nether.net> References: <36C3046E-F403-450A-8CAE-9D780F4C9345@puck.nether.net> Message-ID: <20140612031334.GA1871@stargate.ca> No luck from here. weather.gov resolves as 204.227.127.201 for me, and I have no routes for that IP. However, www.weather.gov is a CNAME for www.weather.gov.edgesuite.net. which in turn is canonical for a895.g.akamai.net. for me. That resolves to 216.23.154.72 & 216.23.154.75, which heads to a cache in one of our upstreams. -- Hugo Stargate On Wed 2014-Jun-11 22:55:05 -0400, Jared Mauch wrote: >I have no issues reaching AKAMAI(weather.gov) > >- jared > >On Jun 11, 2014, at 10:52 PM, Bryan Tong wrote: > >> Im wondering if anyone else is seeing strangeness. >> >> |------------------------------------------------------------------------------------------| >> | WinMTR statistics >> | >> | Host - % | Sent | Recv | Best | >> Avrg | Wrst | Last | >> |------------------------------------------------|------|------|------|------|------|------| >> | DD-WRT - 29 | 7 | 5 | 1 | >> 1 | 1 | 1 | >> | No response from host - 100 | 3 | 0 | 0 | >> 0 | 0 | 0 | >> | 69.146.239.53 - 0 | 16 | 16 | 9 | >> 18 | 58 | 17 | >> | host-69-144-126-216.static.bresnan.net - 0 | 16 | 16 | 19 | >> 30 | 58 | 23 | >> |host-72-175-111-150.bln-mt.client.bresna - 0 | 16 | 16 | 14 | >> 27 | 57 | 15 | >> | No response from host - 100 | 3 | 0 | 0 | >> 0 | 0 | 0 | >> | No response from host - 100 | 3 | 0 | 0 | >> 0 | 0 | 0 | >> | No response from host - 100 | 3 | 0 | 0 | >> 0 | 0 | 0 | >> | No response from host - 100 | 3 | 0 | 0 | >> 0 | 0 | 0 | >> -- >> eSited LLC >> (701) 390-9638 > From gary.buhrmaster at gmail.com Thu Jun 12 03:17:37 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 12 Jun 2014 03:17:37 +0000 Subject: No route to weather.gov In-Reply-To: References: Message-ID: On Thu, Jun 12, 2014 at 2:52 AM, Bryan Tong wrote: > Im wondering if anyone else is seeing strangeness. I have no trouble accessing www.weather.gov. (akamai CDM based). weather.gov, on the other hand, seems inaccessible (noaa.gov supported). From jeff-kell at utc.edu Thu Jun 12 03:18:28 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 11 Jun 2014 23:18:28 -0400 Subject: No route to weather.gov In-Reply-To: <20140612031334.GA1871@stargate.ca> References: <36C3046E-F403-450A-8CAE-9D780F4C9345@puck.nether.net> <20140612031334.GA1871@stargate.ca> Message-ID: <53991C04.9010803@utc.edu> On 6/11/2014 11:13 PM, Hugo Slabbert wrote: > No luck from here. > > weather.gov resolves as 204.227.127.201 for me, and I have no routes > for that IP. Likewise here, and we have various views. > UTC-Border#show ip route 204.227.127.201 > % Network not in table BGP path falls back to default route... > UTC-Border#show ip bgp 204.227.127.201 > BGP routing table entry for 0.0.0.0/0, version 671407710 > Paths: (4 available, best #4, table Default-IP-Routing-Table) > Multipath: eBGP Jeff From bryan at digitalocean.com Thu Jun 12 04:16:47 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Thu, 12 Jun 2014 00:16:47 -0400 Subject: S3, US Standard Problems? Message-ID: Is anyone else noticing a lot of problems with Amazon S3 US Standard problems. We're seeing a lot of customer complaints of connects then hangs/timesout mid transfer... Mostly coming from connections originating in the NYC area or from europe passing through nyc on it's way. Bryan Socha Network Engineer DigitalOcean From contact at nullivex.com Thu Jun 12 04:30:56 2014 From: contact at nullivex.com (Bryan Tong) Date: Wed, 11 Jun 2014 22:30:56 -0600 Subject: No route to weather.gov In-Reply-To: <53991C04.9010803@utc.edu> References: <36C3046E-F403-450A-8CAE-9D780F4C9345@puck.nether.net> <20140612031334.GA1871@stargate.ca> <53991C04.9010803@utc.edu> Message-ID: Also the main forecast.weather.gov seems to be okay. $ ping forecast.weather.gov PING a1380.g.akamai.net (64.208.159.26): 56 data bytes 64 bytes from 64.208.159.26: icmp_seq=0 ttl=50 time=1009 ms 64 bytes from 64.208.159.26: icmp_seq=1 ttl=50 time=100 ms 64 bytes from 64.208.159.26: icmp_seq=2 ttl=50 time=83 ms |------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | DD-WRT - 0 | 14 | 14 | 0 | 0 | 1 | 0 | | No response from host - 100 | 2 | 0 | 0 | 0 | 0 | 0 | | 69.146.239.53 - 0 | 14 | 14 | 14 | 107 | 501 | 53 | |host-69-144-130-180.bzm-mt.client.bresna - 0 | 14 | 14 | 19 | 110 | 502 | 52 | |host-72-175-111-150.bln-mt.client.bresna - 0 | 14 | 14 | 14 | 110 | 502 | 57 | | 69.146.239.255 - 0 | 14 | 14 | 24 | 114 | 502 | 53 | | seawafh1cr5-XE-4-3-0-U0.int.bresnan.net - 0 | 9 | 9 | 55 | 172 | 503 | 59 | | blnmtdc2dr5-GE-4-0-3-U0.int.bresnan.net - 0 | 14 | 14 | 55 | 145 | 502 | 70 | | 12.90.77.21 - 10 | 10 | 9 | 50 | 157 | 503 | 50 | | 12.122.111.114 - 0 | 14 | 14 | 57 | 162 | 505 | 60 | | cr81.st0wa.ip.att.net - 0 | 9 | 9 | 60 | 201 | 504 | 60 | | 12.122.82.9 - 10 | 10 | 9 | 56 | 218 | 506 | 270 | | te8-4-10G.ar1.PAO2.gblx.net - 0 | 14 | 14 | 63 | 167 | 504 | 69 | | ae0-30G.scr1.SEA1.gblx.net - 10 | 10 | 9 | 50 | 192 | 504 | 89 | | po3-40G.ar5.LAX1.gblx.net - 0 | 14 | 14 | 70 | 175 | 505 | 84 | | 64.208.159.26 - 0 | 14 | 14 | 74 | 176 | 505 | 86 | |________________________________________________|______|______|______|______|______|______| On Wed, Jun 11, 2014 at 9:18 PM, Jeff Kell wrote: > On 6/11/2014 11:13 PM, Hugo Slabbert wrote: > > No luck from here. > > > > weather.gov resolves as 204.227.127.201 for me, and I have no routes > > for that IP. > > Likewise here, and we have various views. > > > UTC-Border#show ip route 204.227.127.201 > > % Network not in table > > BGP path falls back to default route... > > > UTC-Border#show ip bgp 204.227.127.201 > > BGP routing table entry for 0.0.0.0/0, version 671407710 > > Paths: (4 available, best #4, table Default-IP-Routing-Table) > > Multipath: eBGP > > Jeff > -- eSited LLC (701) 390-9638 From mark.tinka at seacom.mu Thu Jun 12 05:30:30 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 12 Jun 2014 07:30:30 +0200 Subject: No route to weather.gov In-Reply-To: References: Message-ID: <201406120730.30703.mark.tinka@seacom.mu> On Thursday, June 12, 2014 05:17:37 AM Gary Buhrmaster wrote: > I have no trouble accessing www.weather.gov. > (akamai CDM based). weather.gov, on the other hand, > seems inaccessible (noaa.gov supported). Same thing here from Africa. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bryan at digitalocean.com Thu Jun 12 06:57:58 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Thu, 12 Jun 2014 02:57:58 -0400 Subject: S3, US Standard Problems? In-Reply-To: References: Message-ID: Can someone from aws contact me off list. we think we found where the issue might be. Thanks, Bryan Socha Network Engineer DigitalOcean On Thu, Jun 12, 2014 at 12:16 AM, Bryan Socha wrote: > Is anyone else noticing a lot of problems with Amazon S3 US Standard > problems. We're seeing a lot of customer complaints of connects then > hangs/timesout mid transfer... > > Mostly coming from connections originating in the NYC area or from europe > passing through nyc on it's way. > > Bryan Socha > Network Engineer > DigitalOcean > > From owen at delong.com Thu Jun 12 13:39:17 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Jun 2014 06:39:17 -0700 Subject: S3, US Standard Problems? In-Reply-To: References: Message-ID: I still can’t get to them from 2620:0:930::/48. But this is not a new problem. It has persisted as long as I can remember. Owen On Jun 11, 2014, at 9:16 PM, Bryan Socha wrote: > Is anyone else noticing a lot of problems with Amazon S3 US Standard > problems. We're seeing a lot of customer complaints of connects then > hangs/timesout mid transfer... > > Mostly coming from connections originating in the NYC area or from europe > passing through nyc on it's way. > > Bryan Socha > Network Engineer > DigitalOcean From rwebb at ropeguru.com Thu Jun 12 15:26:51 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Thu, 12 Jun 2014 11:26:51 -0400 Subject: Peak Servers Contact Message-ID: Anyone at peak servers on this list? I am seeing major latency and packetloss inside your network to both of my vps servers. Please contact off list. Robert From hasservalve at gmail.com Thu Jun 12 15:58:08 2014 From: hasservalve at gmail.com (hasser css) Date: Thu, 12 Jun 2014 17:58:08 +0200 Subject: Time Warner IPv6 Reverse DNS? Message-ID: Some IPv6 email is not working well for me on my TWC Internet connection due to their IPv6 block not having PTR records. Is it possible for me to delegate my IPv6 range to my own DNS server, or something similar? I have talked to level 3 support and they were pretty much clueless, so I decide to ask here if anyone has insight or similar issues in the past. Thanks! From rwebb at ropeguru.com Thu Jun 12 16:06:47 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Thu, 12 Jun 2014 12:06:47 -0400 Subject: Time Warner IPv6 Reverse DNS? In-Reply-To: References: Message-ID: If your IPv6 subnet is being allocated by TW, then it is up to them whether or not to allow the customer to manage their own rDNS. I have not asked about IPv6 with Comcast Business, but I know with IPv4 IP blcks, they will turn the request around pretty quickly once asked. Robert On Thu, 12 Jun 2014 17:58:08 +0200 hasser css wrote: > Some IPv6 email is not working well for me on my TWC Internet >connection > due to their IPv6 block not having PTR records. > > Is it possible for me to delegate my IPv6 range to my own DNS >server, or > something similar? I have talked to level 3 support and they were >pretty > much clueless, so I decide to ask here if anyone has insight or >similar > issues in the past. > > Thanks! From source_route at yahoo.com Thu Jun 12 16:25:20 2014 From: source_route at yahoo.com (Philip Lavine) Date: Thu, 12 Jun 2014 09:25:20 -0700 (PDT) Subject: Help with Confederation-RR-MPBGP Message-ID: <1402590320.65337.YahooMailNeo@web122505.mail.ne1.yahoo.com> To all, I am studying for a certain vendors test, and need some guidance on best practices. Lets say you have a MPLS VPN with 4 PE routers. Is it more efficient to use RR or Confederation? Thank you, Philip From druciaki at gmail.com Thu Jun 12 14:16:51 2014 From: druciaki at gmail.com (Thiago Druciaki Casagrande) Date: Thu, 12 Jun 2014 11:16:51 -0300 Subject: IFIP LANC 2014 In-cooperation with ACM - DEADLINE EXTENDED TO JULY 02, 2014 Message-ID: [Apologies if you receive multiple copies] ====================================================== * IFIP LANC 2014* * The 8th Latin America Networking Conference 2014 (LANC 2014)* * In-cooperation with ACM* http://lanc2014.ufpa.br/ 18-19 September, 2014 Montevideo – Uruguay Collocated with CLEI 2014 The IFIP Latin America Networking Conference 2014 is in-cooperation with ACM and will provide an international technical forum for experts from industry and academia everywhere in the world, but especially from the Latin American countries, to exchange ideas and present results of ongoing research in networking. LANC 2014 is organized jointly with CLEI (Centro Latinoamericano de Estudio em Informatica) 2014 - http://clei.org/clei2014/ . --------------------------------------------------------------------------- *IMPORTANT DATES* - Full and Short Paper Submission: July 02, 2014 (extended deadline) - Notification of acceptance: August 07 - Camera-ready copy: August 20 --------------------------------------------------------------------------- Topics include, but are not limited to: NETWORKS and COMMUNICATION SYSTEMS - Cloud computing - Delay/Disruption-tolerant networks - Green and Energy-efficient communications - Internet based applications - Low cost access networks - Multimedia networking systems - National ICT infrastructures for education - Network and service management - Network performance evaluation - Network security - Optical communications - Peer-to-peer and overlay networks - Protocols - Quality of Service (QoS) and Quality of Experience (QoE) in communication systems - Routing and switching - Smart grid communications - Social Multimedia Networking - Software Defined Networks - Web infrastructure - Wireless, mobile, ad-hoc, and sensor networks - Cyber-physical systems and the Internet of things - Dynamic spectrum management - Implementation and experimental testbeds - Cognitive radio networking - Cross layer design and optimization Submission of papers that cover solutions of specific network problems of this region of the world is especially encouraged. *PAPER SUBMISSION* The submission is now open: Only original papers (written in English) not published or under review elsewhere can be submitted - full papers (up to 8 pages including references) and short papers (4 pages up to 1 additional page). Templates can be downloaded from the ACM website ( http://www.acm.org/sigs/publications/proceedings-templates / The LaTeX2e - Tighter Alternate style is preferable to the Strict one). Papers should be uploaded electronically, ONLY in PDF format, to the Easychair website: https://www.easychair.org/conferences/?conf=lanc2014 *REVIEW PROCESS* All submitted papers will have at least three reviews. Acceptance will be based on originality, quality, relevance and the practical value of the work. *PROCEEDINGS* All accepted papers will be published in the* ACM* Digital Library. There will be a special issue of the CLEI electronic journal ( http://www.clei.cl/cleiej) devoted to extended versions of a selection of the papers presented at LANC 2014. *Travel Support* IFIP TC6 Student Travel Grant Programme Under the IFIP TC6 Student Travel Grant Programme, students or young researchers from an IFIP member country may apply for partial funding to assist them towards paying their travel and accommodation costs when attending the 8th Latin America Networking Conference 2014. Young researchers are researchers who have not yet completed their studies up to, and including a doctoral degree. Such persons would normally not be older than 35 years on the 15th September 2014. An Awards Committee reviews the application and awards a grant where the applicant would not otherwise have the resources to attend a conference or workshop, with benefits to both the student and the symposium. Grants are for the applicants travel and lodging expenses only and will not exceed 500 U$ per grant. The maximum of the grant is fixed and any claims in excess of 500 U$ will not be considered. *VENUE* For more information about travel, hotels, etc. please visit CLEI 2014 web site (http://clei.org/clei2014/) *General Co-Chair* Eduardo Cerqueira, Federal University of Para, BR *Steering Committee* Ana Pont, U. Politécnica Valencia, ES David R. Oran, CISCO, US Ernst L. Leiss, U. of Houston, US Hector Cancela, U. de la República, UY Ramón Cáceres, AT&T Labs, US Rodrigo Santos, U. Nacional del Sur, AR *Technical Program Committee Co-Chairs* Aldri Santos, Federal University of Paraná, BR Eduardo Grampin, UDELAR, UY *Organizing Committee* Hector Cancela, UDELAR, UY *Technical Program Committee (TBD)* Aldri Santos, UFPR, BR Ariel Sabiguero, UDELAR, UY Artur Ziviani, LNCC, BR Augusto Neto, UFC, BR David Oran, CISCO, US Edjair Mota, UFAM, BR Edmundo Monteiro University of Coimbra, PT Eduardo Cerqueira, UFPA, BR Eduardo Grampin, UDELAR, UY Enrique Carrera, ESPE, EC Francisco Quiles, UCLM, ES Francisco Valera, UC3M, ES Harry Perros, NCSU, US Javier Baliosian, UDELAR, UY José Piquer, UCH, CL José Salinas, UPV, ES Jussara M. Almeida, UFMG, BR Lisandro Zambenedetti Granville, UFRGS, BR Marcelo Bagnulo Braun, UC3M, ES Maria Dolores Baños, UPCT, ES Maria Elena Villapol, UCV, VE Marília Curado, University of Coimbra, PT Marinho P. Barcellos, UFRGS, BR Michele Nogueira, UFPR, BR Mikolaj Leszczuk, AGH, PL Pablo Belzarena, UDELAR, UY Pablo Rodríguez-bocca, UDELAR, UY Ronaldo A. Ferreira UFMS, BR Sherali Zeadally, University of Kentucky, US Siraj A. Shaikh, Coventry University, UK Xavi Masip, UPC, ES Yutaka Takahashi, Kyoto University, JP From Valdis.Kletnieks at vt.edu Thu Jun 12 16:39:53 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 12 Jun 2014 12:39:53 -0400 Subject: Help with Confederation-RR-MPBGP In-Reply-To: Your message of "Thu, 12 Jun 2014 09:25:20 -0700." <1402590320.65337.YahooMailNeo@web122505.mail.ne1.yahoo.com> References: <1402590320.65337.YahooMailNeo@web122505.mail.ne1.yahoo.com> Message-ID: <7092.1402591193@turing-police.cc.vt.edu> On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said: > need some guidance on best practices What the vendor says is best practices, or what people in the trenches say? > Is it more efficient to use RR or Confederation? If option A is 2% more "efficient" than option B, but takes 10% longer to deploy and causes 3% more SLA payouts to your customers when the added complexity causes a whoopsie, how much more work could you have gotten done in the time you spent in an uncomfortable meeting explaining to upper management why the whoopsie happened? (Sorry, it's been that sort of week :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From phiber at phiber.org Thu Jun 12 16:55:42 2014 From: phiber at phiber.org (Christopher Rogers) Date: Thu, 12 Jun 2014 09:55:42 -0700 Subject: routing issues to AWS via 2914(NTT) Message-ID: Could an IP engineer from AWS (16509/14618) and one from NTT (2914) kindly contact me off-list? AS18888 is having some major reachability issues to you via 2914. Several of our applications and users are reporting problems trying to reach various aws hosted services such as netflix and twilio. I'm seeing almost 50% packet loss when transiting to you via 2914. Forcing traffic onto 3356 clears the issue right up. I've had to effectively shift all my ingress traffic off 2914 and de-pref aws as-path to force egress to other transit. We're a customer of 2914, but not AWS. I've got a ticket open with 2914, and they've reached out to AWS, but it's been two days now and we haven't been getting any traction on this. thanks! -chris From m.hallgren at free.fr Thu Jun 12 21:43:19 2014 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 12 Jun 2014 23:43:19 +0200 Subject: Help with Confederation-RR-MPBGP In-Reply-To: <7092.1402591193@turing-police.cc.vt.edu> References: <1402590320.65337.YahooMailNeo@web122505.mail.ne1.yahoo.com> <7092.1402591193@turing-police.cc.vt.edu> Message-ID: <539A1EF7.7090704@free.fr> Le 12/06/2014 18:39, Valdis.Kletnieks at vt.edu a écrit : > On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said: >> need some guidance on best practices > > What the vendor says is best practices, or what people in the trenches say? > >> Is it more efficient to use RR or Confederation? > > If option A is 2% more "efficient" than option B, but takes 10% longer to > deploy and causes 3% more SLA payouts to your customers when the added > complexity causes a whoopsie, how much more work could you have gotten done in > the time you spent in an uncomfortable meeting explaining to upper management > why the whoopsie happened? > > (Sorry, it's been that sort of week :) :-) Now, Philip, I think along the same path as Vladis: it depends... What does your physical or layer 2 network look like? How do you expect packets to move around inside, and in and out, of that topology? You need policing? How much and of what, etc, etc...? I'm quite often a fan of confed's, if the network is young thus ``easy'' migration, but there are scenarios... Please provide more detail to this mail thread or one-to-one if you prefer. Cheers, mh > From bryan at digitalocean.com Fri Jun 13 05:48:33 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Fri, 13 Jun 2014 01:48:33 -0400 Subject: S3, US Standard Problems? In-Reply-To: References: Message-ID: The problem we are seeing we had to route around. There is a problem in NYC between NTT(2914) and Amazon. Bryan Socha Network Engineer DigitalOcean On Thu, Jun 12, 2014 at 9:39 AM, Owen DeLong wrote: > I still can’t get to them from 2620:0:930::/48. > > But this is not a new problem. It has persisted as long as I can remember. > > Owen > > On Jun 11, 2014, at 9:16 PM, Bryan Socha wrote: > > > Is anyone else noticing a lot of problems with Amazon S3 US Standard > > problems. We're seeing a lot of customer complaints of connects then > > hangs/timesout mid transfer... > > > > Mostly coming from connections originating in the NYC area or from europe > > passing through nyc on it's way. > > > > Bryan Socha > > Network Engineer > > DigitalOcean > > From bryan at digitalocean.com Fri Jun 13 05:50:24 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Fri, 13 Jun 2014 01:50:24 -0400 Subject: routing issues to AWS via 2914(NTT) In-Reply-To: References: Message-ID: Amazon hasn't reached out to us either... If you have other providers, use a combination of local-preference and the customer communitiy strings with ntt to prepend around the circuit(s) in nyc with the issue. Just check your routing table, we found many going through ntt to amazon and took awhile to get everything working as desired. Bryan Socha Network Engineer DigitalOcean On Thu, Jun 12, 2014 at 12:55 PM, Christopher Rogers wrote: > Could an IP engineer from AWS (16509/14618) and one from NTT (2914) kindly > contact me off-list? AS18888 is having some major reachability issues to > you via 2914. Several of our applications and users are reporting problems > trying to reach various aws hosted services such as netflix and twilio. > I'm seeing almost 50% packet loss when transiting to you via 2914. > Forcing traffic onto 3356 clears the issue right up. I've had to > effectively shift all my ingress traffic off 2914 and de-pref aws as-path > to force egress to other transit. > > We're a customer of 2914, but not AWS. I've got a ticket open with 2914, > and they've reached out to AWS, but it's been two days now and we haven't > been getting any traction on this. > > thanks! > > -chris > From rsk at gsp.org Fri Jun 13 08:31:02 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 13 Jun 2014 04:31:02 -0400 Subject: yahoo.fr is no longer interested in your abuse reports. In-Reply-To: References: Message-ID: <20140613083102.GA29155@gsp.org> On Wed, Jun 11, 2014 at 01:00:58PM -0700, goemon at anime.net wrote: > Looks like they've finally completely blocked off their abuse mailboxes. That's not a problem. Now that Yahoo has deployed DMARC, all the spam, phishing, carding, stalking, kiddie porn, fraud, and other choice bits of unpleasantness that they've either emitted or provided dropboxes for over the past many years have disappeared completely and permanently. You will never need to report any kind of abuse to them ever again. ---rsk From david at mailplus.nl Fri Jun 13 08:58:33 2014 From: david at mailplus.nl (David Hofstee) Date: Fri, 13 Jun 2014 10:58:33 +0200 Subject: yahoo.fr is no longer interested in your abuse reports. In-Reply-To: <20140613083102.GA29155@gsp.org> References: <20140613083102.GA29155@gsp.org> Message-ID: <78C35D6C1A82D243B830523B4193CF5F75B8B35124@SBS1.blinker.local> Yahoo.fr has the p=none policy: $ dig txt _dmarc.yahoo.fr +short "v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc-yahoo-rua at yahoo-inc.com\;" So there might be some abuse still there ;-). David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Rich Kulawiec Verzonden: Friday, June 13, 2014 10:31 AM Aan: nanog at nanog.org Onderwerp: Re: yahoo.fr is no longer interested in your abuse reports. On Wed, Jun 11, 2014 at 01:00:58PM -0700, goemon at anime.net wrote: > Looks like they've finally completely blocked off their abuse mailboxes. That's not a problem. Now that Yahoo has deployed DMARC, all the spam, phishing, carding, stalking, kiddie porn, fraud, and other choice bits of unpleasantness that they've either emitted or provided dropboxes for over the past many years have disappeared completely and permanently. You will never need to report any kind of abuse to them ever again. ---rsk From pauldotwall at gmail.com Fri Jun 13 11:44:51 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Fri, 13 Jun 2014 11:44:51 +0000 Subject: routing issues to AWS via 2914(NTT) In-Reply-To: References: Message-ID: Amazon peers at many key exchanges, with dozens of hosting shops (where customers might share mutual infrastructure) like yours: https://www.peeringdb.com/view.php?asn=16509 Rather than play the blame game with third-party transit providers, why not hit them up for some sessions? Drive Slow, Paul Wall On Fri, Jun 13, 2014 at 5:50 AM, Bryan Socha wrote: > Amazon hasn't reached out to us either... > > If you have other providers, use a combination of local-preference and the > customer communitiy strings with ntt to prepend around the circuit(s) in > nyc with the issue. Just check your routing table, we found many going > through ntt to amazon and took awhile to get everything working as desired. > > Bryan Socha > Network Engineer > DigitalOcean > > On Thu, Jun 12, 2014 at 12:55 PM, Christopher Rogers > wrote: > >> Could an IP engineer from AWS (16509/14618) and one from NTT (2914) kindly >> contact me off-list? AS18888 is having some major reachability issues to >> you via 2914. Several of our applications and users are reporting problems >> trying to reach various aws hosted services such as netflix and twilio. >> I'm seeing almost 50% packet loss when transiting to you via 2914. >> Forcing traffic onto 3356 clears the issue right up. I've had to >> effectively shift all my ingress traffic off 2914 and de-pref aws as-path >> to force egress to other transit. >> >> We're a customer of 2914, but not AWS. I've got a ticket open with 2914, >> and they've reached out to AWS, but it's been two days now and we haven't >> been getting any traction on this. >> >> thanks! >> >> -chris >> From bryan at digitalocean.com Fri Jun 13 13:28:12 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Fri, 13 Jun 2014 09:28:12 -0400 Subject: routing issues to AWS via 2914(NTT) In-Reply-To: References: Message-ID: I don't think anyone is blaming anyone, just trying to pass on information where we see a problem. We routed around it no problem. Bryan Socha On Fri, Jun 13, 2014 at 7:44 AM, Paul WALL wrote: > Amazon peers at many key exchanges, with dozens of hosting shops > (where customers might share mutual infrastructure) like yours: > > https://www.peeringdb.com/view.php?asn=16509 > > Rather than play the blame game with third-party transit providers, > why not hit them up for some sessions? > > Drive Slow, > Paul Wall > > On Fri, Jun 13, 2014 at 5:50 AM, Bryan Socha > wrote: > > Amazon hasn't reached out to us either... > > > > If you have other providers, use a combination of local-preference and > the > > customer communitiy strings with ntt to prepend around the circuit(s) in > > nyc with the issue. Just check your routing table, we found many going > > through ntt to amazon and took awhile to get everything working as > desired. > > > > Bryan Socha > > Network Engineer > > DigitalOcean > > > > On Thu, Jun 12, 2014 at 12:55 PM, Christopher Rogers > > wrote: > > > >> Could an IP engineer from AWS (16509/14618) and one from NTT (2914) > kindly > >> contact me off-list? AS18888 is having some major reachability issues > to > >> you via 2914. Several of our applications and users are reporting > problems > >> trying to reach various aws hosted services such as netflix and twilio. > >> I'm seeing almost 50% packet loss when transiting to you via 2914. > >> Forcing traffic onto 3356 clears the issue right up. I've had to > >> effectively shift all my ingress traffic off 2914 and de-pref aws > as-path > >> to force egress to other transit. > >> > >> We're a customer of 2914, but not AWS. I've got a ticket open with > 2914, > >> and they've reached out to AWS, but it's been two days now and we > haven't > >> been getting any traction on this. > >> > >> thanks! > >> > >> -chris > >> > From Lee at asgard.org Fri Jun 13 14:39:52 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 13 Jun 2014 10:39:52 -0400 Subject: Time Warner IPv6 Reverse DNS? In-Reply-To: References: Message-ID: We've corresponded offline. I documented the difficulties in providing reverse DNS for IPv6 residential users in http://tools.ietf.org/html/draft-howard-isp-ip6rdns-06 It's a long-expired draft, which never found sufficient support from a WG or AD. I've been meaning to rewrap it as a BCOP, but lack cycles. Lee On 6/12/14 11:58 AM, "hasser css" wrote: >Some IPv6 email is not working well for me on my TWC Internet connection >due to their IPv6 block not having PTR records. > >Is it possible for me to delegate my IPv6 range to my own DNS server, or >something similar? I have talked to level 3 support and they were pretty >much clueless, so I decide to ask here if anyone has insight or similar >issues in the past. > >Thanks! > From jlewis at lewis.org Fri Jun 13 14:54:32 2014 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 13 Jun 2014 10:54:32 -0400 (EDT) Subject: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: On Mon, 9 Jun 2014, John van Oppen wrote: > It is generally much better to do the following: > > mls cef maximum-routes ipv6 90 > mls cef maximum-routes ip-multicast 1 > > This will leave v4 and mpls in one big pool, puts v6 to something useful for quite a while and steals all of the multicast space which is not really used on most deployments. > > This gives us the following (which is pretty great for IP backbone purposes in dual stack): > > #show mls cef maximum-routes > FIB TCAM maximum routes : > ======================= > Current :- > ------- > IPv4 + MPLS - 832k (default) > IPv6 - 90k > IP multicast - 1k I was just looking at / thinking about this again, and though I don't disagree that doing the split your way is probably better, I think it's a moot point. I strongly suspect these boxes will run out of RAM before they're able to utilize another 256k routing slots with multiple full v4 tables. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nick at foobar.org Fri Jun 13 15:01:16 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 13 Jun 2014 16:01:16 +0100 Subject: FW: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: <539B123C.1040807@foobar.org> On 13/06/2014 15:54, Jon Lewis wrote: > I was just looking at / thinking about this again, and though I don't > disagree that doing the split your way is probably better, I think it's a > moot point. I strongly suspect these boxes will run out of RAM before > they're able to utilize another 256k routing slots with multiple full v4 > tables. to a certain extent that depends on what software you're using. 12.x seems to be a good bit more memory efficient than 15.x on the sup720. Otherwise yeah, RP memory is the next critical limiting factor on these boxes, assuming if you can live with the crippling convergence times with large numbers of prefixes. Nick From james.cutler at consultant.com Fri Jun 13 15:26:22 2014 From: james.cutler at consultant.com (James R Cutler) Date: Fri, 13 Jun 2014 11:26:22 -0400 Subject: Time Warner IPv6 Reverse DNS? In-Reply-To: References: Message-ID: On Jun 13, 2014, at 10:39 AM, Lee Howard wrote: > We've corresponded offline. > > I documented the difficulties in providing reverse DNS for IPv6 > residential users in http://tools.ietf.org/html/draft-howard-isp-ip6rdns-06 > It's a long-expired draft, which never found sufficient support from a WG > or AD. I've been meaning to rewrap it as a BCOP, but lack cycles. > > Lee > > On 6/12/14 11:58 AM, "hasser css" wrote: > >> Some IPv6 email is not working well for me on my TWC Internet connection >> due to their IPv6 block not having PTR records. >> >> Is it possible for me to delegate my IPv6 range to my own DNS server, or >> something similar? I have talked to level 3 support and they were pretty >> much clueless, so I decide to ask here if anyone has insight or similar >> issues in the past. >> >> Thanks! >> > > This exchange brings to mind several questions (and comments): 1. Should not RFC 1033 be considered “Historic”? I note that iPv6 was only a faint longing and otherwise undefined at that time. 2. What is the real rdns business requirement for residential customers? I have difficulty finding anything but SMTP servers needing rdns entries. Practical end-to-end security should be independent of media and addressing. 3. Would this question be better posed on the “mailop” mailing list (if SMTP service is the issue) or perhaps dns-operations at mail.dns-oarc.net? Since “hasser css” did not explain his business requirement for rdns, it really difficult to provide advice. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From joelja at bogus.com Fri Jun 13 15:57:40 2014 From: joelja at bogus.com (joel jaeggli) Date: Fri, 13 Jun 2014 08:57:40 -0700 Subject: Time Warner IPv6 Reverse DNS? In-Reply-To: References: Message-ID: <539B1F74.8070300@bogus.com> On 6/13/14, 8:26 AM, James R Cutler wrote: > On Jun 13, 2014, at 10:39 AM, Lee Howard wrote: > >> We've corresponded offline. >> >> I documented the difficulties in providing reverse DNS for IPv6 >> residential users in http://tools.ietf.org/html/draft-howard-isp-ip6rdns-06 >> It's a long-expired draft, which never found sufficient support from a WG >> or AD. I've been meaning to rewrap it as a BCOP, but lack cycles. >> >> Lee >> >> On 6/12/14 11:58 AM, "hasser css" wrote: >> >>> Some IPv6 email is not working well for me on my TWC Internet connection >>> due to their IPv6 block not having PTR records. >>> >>> Is it possible for me to delegate my IPv6 range to my own DNS server, or >>> something similar? I have talked to level 3 support and they were pretty >>> much clueless, so I decide to ask here if anyone has insight or similar >>> issues in the past. >>> >>> Thanks! >>> >> >> > This exchange brings to mind several questions (and comments): > > 1. Should not RFC 1033 be considered “Historic”? > I note that iPv6 was only a faint longing and otherwise undefined at that time. > > 2. What is the real rdns business requirement for residential customers? > I have difficulty finding anything but SMTP servers needing rdns entries. > Practical end-to-end security should be independent of media and addressing. I would like an authoritative nameserver to give me as quickly is possible. imho lame delegation of reverse is way worse then not having a ptr. > 3. Would this question be better posed on the “mailop” mailing list (if SMTP service is the issue) or perhaps dns-operations at mail.dns-oarc.net? > > Since “hasser css” did not explain his business requirement for rdns, it really difficult to provide advice. > > > James R. Cutler > James.cutler at consultant.com > PGP keys at http://pgp.mit.edu > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 286 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Fri Jun 13 16:41:36 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 13 Jun 2014 12:41:36 -0400 Subject: S3, US Standard Problems? In-Reply-To: References: Message-ID: <04C1BE6F-4544-4235-ACCB-5B2137576C01@puck.nether.net> If you are still seeing problems can you please contact me with details? I’ve seen some things done and am looking for confirmation it’s fixed. (or still broken). - Jared On Jun 13, 2014, at 1:48 AM, Bryan Socha wrote: > The problem we are seeing we had to route around. There is a problem in > NYC between NTT(2914) and Amazon. > > > Bryan Socha > Network Engineer > DigitalOcean > > > > On Thu, Jun 12, 2014 at 9:39 AM, Owen DeLong wrote: > >> I still can’t get to them from 2620:0:930::/48. >> >> But this is not a new problem. It has persisted as long as I can remember. >> >> Owen >> >> On Jun 11, 2014, at 9:16 PM, Bryan Socha wrote: >> >>> Is anyone else noticing a lot of problems with Amazon S3 US Standard >>> problems. We're seeing a lot of customer complaints of connects then >>> hangs/timesout mid transfer... >>> >>> Mostly coming from connections originating in the NYC area or from europe >>> passing through nyc on it's way. >>> >>> Bryan Socha >>> Network Engineer >>> DigitalOcean >> >> From bryan at digitalocean.com Fri Jun 13 17:52:48 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Fri, 13 Jun 2014 13:52:48 -0400 Subject: S3, US Standard Problems? In-Reply-To: <04C1BE6F-4544-4235-ACCB-5B2137576C01@puck.nether.net> References: <04C1BE6F-4544-4235-ACCB-5B2137576C01@puck.nether.net> Message-ID: It appears to be fixed. Feel free to test from us if you want to look closer at a test. Thanks, Bryan Socha Network Engineer DigitalOcean On Fri, Jun 13, 2014 at 12:41 PM, Jared Mauch wrote: > If you are still seeing problems can you please contact me with details? > I’ve seen some things done and am looking for confirmation it’s fixed. (or > still broken). > > - Jared > > On Jun 13, 2014, at 1:48 AM, Bryan Socha wrote: > > > The problem we are seeing we had to route around. There is a problem > in > > NYC between NTT(2914) and Amazon. > > > > > > Bryan Socha > > Network Engineer > > DigitalOcean > > > > > > > > On Thu, Jun 12, 2014 at 9:39 AM, Owen DeLong wrote: > > > >> I still can’t get to them from 2620:0:930::/48. > >> > >> But this is not a new problem. It has persisted as long as I can > remember. > >> > >> Owen > >> > >> On Jun 11, 2014, at 9:16 PM, Bryan Socha > wrote: > >> > >>> Is anyone else noticing a lot of problems with Amazon S3 US Standard > >>> problems. We're seeing a lot of customer complaints of connects then > >>> hangs/timesout mid transfer... > >>> > >>> Mostly coming from connections originating in the NYC area or from > europe > >>> passing through nyc on it's way. > >>> > >>> Bryan Socha > >>> Network Engineer > >>> DigitalOcean > >> > >> > > From cscora at apnic.net Fri Jun 13 18:15:31 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Jun 2014 04:15:31 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201406131815.s5DIFVYV031808@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, LacNOG, TRNOG, 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 14 Jun, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 499331 Prefixes after maximum aggregation: 194746 Deaggregation factor: 2.56 Unique aggregates announced to Internet: 245869 Total ASes present in the Internet Routing Table: 47040 Prefixes per ASN: 10.62 Origin-only ASes present in the Internet Routing Table: 35870 Origin ASes announcing only one prefix: 16315 Transit ASes present in the Internet Routing Table: 6100 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1744 Unregistered ASNs in the Routing Table: 446 Number of 32-bit ASNs allocated by the RIRs: 6833 Number of 32-bit ASNs visible in the Routing Table: 5070 Prefixes from 32-bit ASNs in the Routing Table: 17381 Number of bogon 32-bit ASNs visible in the Routing Table: 227 Special use prefixes present in the Routing Table: 13 Prefixes being announced from unallocated address space: 403 Number of addresses announced to Internet: 2693600260 Equivalent to 160 /8s, 141 /16s and 20 /24s Percentage of available address space announced: 72.8 Percentage of allocated address space announced: 72.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.6 Total number of prefixes smaller than registry allocations: 173133 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 119415 Total APNIC prefixes after maximum aggregation: 35307 APNIC Deaggregation factor: 3.38 Prefixes being announced from the APNIC address blocks: 122523 Unique aggregates announced from the APNIC address blocks: 51116 APNIC Region origin ASes present in the Internet Routing Table: 4949 APNIC Prefixes per ASN: 24.76 APNIC Region origin ASes announcing only one prefix: 1224 APNIC Region transit ASes present in the Internet Routing Table: 872 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 984 Number of APNIC addresses announced to Internet: 733995392 Equivalent to 43 /8s, 191 /16s and 225 /24s Percentage of available APNIC address space announced: 85.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-63999, 131072-133631 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: 168758 Total ARIN prefixes after maximum aggregation: 83829 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 170405 Unique aggregates announced from the ARIN address blocks: 79377 ARIN Region origin ASes present in the Internet Routing Table: 16295 ARIN Prefixes per ASN: 10.46 ARIN Region origin ASes announcing only one prefix: 6108 ARIN Region transit ASes present in the Internet Routing Table: 1681 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 118 Number of ARIN addresses announced to Internet: 1076665600 Equivalent to 64 /8s, 44 /16s and 157 /24s Percentage of available ARIN address space announced: 57.0 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, 393216-394239 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: 124168 Total RIPE prefixes after maximum aggregation: 62780 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 128774 Unique aggregates announced from the RIPE address blocks: 81293 RIPE Region origin ASes present in the Internet Routing Table: 17710 RIPE Prefixes per ASN: 7.27 RIPE Region origin ASes announcing only one prefix: 8258 RIPE Region transit ASes present in the Internet Routing Table: 2878 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2716 Number of RIPE addresses announced to Internet: 658057092 Equivalent to 39 /8s, 57 /16s and 39 /24s Percentage of available RIPE address space announced: 95.7 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-202239 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: 57509 Total LACNIC prefixes after maximum aggregation: 10139 LACNIC Deaggregation factor: 5.67 Prefixes being announced from the LACNIC address blocks: 64514 Unique aggregates announced from the LACNIC address blocks: 29362 LACNIC Region origin ASes present in the Internet Routing Table: 2102 LACNIC Prefixes per ASN: 30.69 LACNIC Region origin ASes announcing only one prefix: 522 LACNIC Region transit ASes present in the Internet Routing Table: 438 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1215 Number of LACNIC addresses announced to Internet: 165444096 Equivalent to 9 /8s, 220 /16s and 122 /24s Percentage of available LACNIC address space announced: 98.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 11992 Total AfriNIC prefixes after maximum aggregation: 2654 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 12712 Unique aggregates announced from the AfriNIC address blocks: 4365 AfriNIC Region origin ASes present in the Internet Routing Table: 718 AfriNIC Prefixes per ASN: 17.70 AfriNIC Region origin ASes announcing only one prefix: 203 AfriNIC Region transit ASes present in the Internet Routing Table: 153 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 37 Number of AfriNIC addresses announced to Internet: 56658688 Equivalent to 3 /8s, 96 /16s and 139 /24s Percentage of available AfriNIC address space announced: 56.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 2935 11591 922 Korea Telecom 17974 2793 899 72 PT Telekomunikasi Indonesia 7545 2260 320 116 TPG Telecom Limited 4755 1859 396 198 TATA Communications formerly 9829 1647 1307 32 National Internet Backbone 9583 1304 101 537 Sify Limited 9498 1264 314 85 BHARTI Airtel Ltd. 7552 1245 1098 14 Viettel Corporation 4808 1222 2156 364 CNCGROUP IP network China169 24560 1162 398 190 Bharti Airtel Ltd., Telemedia 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 6389 2958 3688 53 BellSouth.net Inc. 22773 2533 2937 136 Cox Communications Inc. 7029 2251 1905 299 Windstream Communications Inc 18566 2047 379 178 MegaPath Corporation 20115 1710 1694 570 Charter Communications 4323 1634 1073 415 tw telecom holdings, inc. 701 1445 11189 732 MCI Communications Services, 30036 1424 311 549 Mediacom Communications Corp 6983 1368 818 314 ITC^Deltacom 22561 1309 402 233 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 34984 1709 264 274 TELLCOM ILETISIM HIZMETLERI A 20940 1384 534 1024 Akamai International B.V. 8402 1365 544 16 OJSC "Vimpelcom" 13188 1031 100 28 TOV "Bank-Inform" 31148 1018 45 21 Freenet Ltd. 8551 954 370 40 Bezeq International-Ltd 6849 823 357 28 JSC "Ukrtelecom" 6830 769 2334 428 Liberty Global Operations B.V 12479 726 795 57 France Telecom Espana SA 9198 575 344 28 JSC Kazakhtelecom 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 28573 3781 2019 99 NET Servi�os de Comunica��o S 10620 2883 466 198 Telmex Colombia S.A. 18881 2037 1036 22 Global Village Telecom 7303 1764 1177 230 Telecom Argentina S.A. 8151 1420 2961 405 Uninet S.A. de C.V. 6503 1139 434 61 Axtel, S.A.B. de C.V. 7738 979 1882 41 Telemar Norte Leste S.A. 27947 888 130 51 Telconet S.A 26615 857 2325 35 Tim Celular S.A. 3816 829 340 138 COLOMBIA TELECOMUNICACIONES S 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 36998 1114 240 6 Sudanese Mobile Telephone (ZA 24863 901 280 25 Link Egypt (Link.NET) 6713 638 727 33 Office National des Postes et 8452 592 958 13 TE-AS 36992 300 783 24 ETISALAT MISR 24835 295 144 9 Vodafone Data 3741 250 921 213 Internet Solutions 37054 244 19 6 Data Telecom Service 29571 225 22 17 Cote d'Ivoire Telecom 15706 187 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 28573 3781 2019 99 NET Servi�os de Comunica��o S 6389 2958 3688 53 BellSouth.net Inc. 4766 2935 11591 922 Korea Telecom 10620 2883 466 198 Telmex Colombia S.A. 17974 2793 899 72 PT Telekomunikasi Indonesia 22773 2533 2937 136 Cox Communications Inc. 7545 2260 320 116 TPG Telecom Limited 7029 2251 1905 299 Windstream Communications Inc 18566 2047 379 178 MegaPath Corporation 18881 2037 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2958 2905 BellSouth.net Inc. 17974 2793 2721 PT Telekomunikasi Indonesia 10620 2883 2685 Telmex Colombia S.A. 22773 2533 2397 Cox Communications Inc. 7545 2260 2144 TPG Telecom Limited 18881 2037 2015 Global Village Telecom 4766 2935 2013 Korea Telecom 7029 2251 1952 Windstream Communications Inc 18566 2047 1869 MegaPath Corporation 4755 1859 1661 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 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 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications 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.88.0.0/16 6697 Republican Unitary Telecommun 100.89.0.0/16 6697 Republican Unitary Telecommun 100.90.0.0/16 6697 Republican Unitary Telecommun 100.91.0.0/16 6697 Republican Unitary Telecommun 100.92.0.0/16 6697 Republican Unitary Telecommun 100.93.0.0/16 6697 Republican Unitary Telecommun 100.94.0.0/16 6697 Republican Unitary Telecommun 100.95.0.0/16 6697 Republican Unitary Telecommun 100.96.0.0/14 6697 Republican Unitary Telecommun 100.104.0.0/13 6697 Republican Unitary Telecommun Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.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:12 /10:30 /11:90 /12:258 /13:488 /14:980 /15:1701 /16:12997 /17:6907 /18:11691 /19:24597 /20:34614 /21:37125 /22:53314 /23:46750 /24:265605 /25:805 /26:905 /27:392 /28:13 /29:19 /30:8 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 22773 1779 2533 Cox Communications Inc. 6389 1694 2958 BellSouth.net Inc. 30036 1261 1424 Mediacom Communications Corp 11492 1188 1233 CABLE ONE, INC. 7029 1138 2251 Windstream Communications Inc 36998 1080 1114 Sudanese Mobile Telephone (ZA 6983 1074 1368 ITC^Deltacom 8402 1072 1365 OJSC "Vimpelcom" 34984 1038 1709 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1127 2:666 3:3 4:15 5:974 6:19 8:711 12:1845 13:4 14:1025 15:13 16:2 17:36 18:21 20:37 23:891 24:1742 27:1772 31:1485 32:43 33:2 34:5 36:136 37:1842 38:953 39:7 40:204 41:3219 42:257 43:56 44:11 45:9 46:2095 47:22 49:726 50:946 52:12 54:47 55:8 57:28 58:1223 59:606 60:415 61:1553 62:1268 63:1953 64:4359 65:2289 66:4167 67:2064 68:1059 69:3344 70:859 71:438 72:2020 74:2643 75:326 76:406 77:1689 78:854 79:708 80:1320 81:1201 82:750 83:754 84:782 85:1315 86:518 87:1179 88:476 89:1827 90:141 91:5679 92:698 93:1779 94:2063 95:1576 96:528 97:358 98:1083 99:49 100:66 101:826 103:5054 104:15 105:543 106:172 107:627 108:593 109:2099 110:972 111:1310 112:663 113:849 114:880 115:1131 116:1104 117:949 118:1416 119:1388 120:383 121:826 122:2045 123:1342 124:1422 125:1465 128:565 129:342 130:348 131:665 132:412 133:163 134:320 135:74 136:259 137:296 138:364 139:168 140:216 141:385 142:567 143:427 144:503 145:104 146:638 147:473 148:905 149:363 150:167 151:711 152:443 153:219 154:294 155:495 156:352 157:337 158:244 159:911 160:329 161:560 162:1524 163:254 164:690 165:605 166:280 167:628 168:1057 169:125 170:1438 171:189 172:19 173:1610 174:700 175:605 176:1384 177:3178 178:2027 179:651 180:1772 181:1156 182:1579 183:524 184:722 185:1738 186:2874 187:1609 188:2063 189:1517 190:7494 191:368 192:7354 193:5511 194:4022 195:3517 196:1416 197:668 198:5088 199:5515 200:6273 201:2667 202:9091 203:8892 204:4585 205:2675 206:2959 207:2975 208:3990 209:3723 210:3091 211:1702 212:2299 213:2090 214:897 215:86 216:5572 217:1686 218:599 219:330 220:1282 221:620 222:353 223:603 End of report From r.engehausen at gmail.com Fri Jun 13 19:39:42 2014 From: r.engehausen at gmail.com (Roy) Date: Fri, 13 Jun 2014 12:39:42 -0700 Subject: IPV6 and Charter Cable Message-ID: <539B537E.2010606@gmail.com> Does Charter Cable have IPV6 for businesses yet? If so can someone point me in the right direction. Their NOC seems to be clueless on their IPV6 plans From mpalmer at hezmatt.org Fri Jun 13 21:28:29 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 14 Jun 2014 07:28:29 +1000 Subject: routing issues to AWS via 2914(NTT) In-Reply-To: References: Message-ID: <20140613212829.GY8158@hezmatt.org> On Fri, Jun 13, 2014 at 11:44:51AM +0000, Paul WALL wrote: > Amazon peers at many key exchanges, with dozens of hosting shops > (where customers might share mutual infrastructure) like yours: > > https://www.peeringdb.com/view.php?asn=16509 > > Rather than play the blame game with third-party transit providers, > why not hit them up for some sessions? That'll only get you peering connectivity into the local region. To get fully-peered with AWS, and be able to avoid third-party transit providers entirely, you're going to have to be in a *lot* of places. Not saying that AWS is a bad peer (from experience, I know they're fine to deal with) but it isn't as cut-and-dried as saying "don't blame transit providers, just peer!". - Matt -- A few minutes ago I attempted to give a flying fsck, but the best I could do was to watch it skitter across the floor. -- Anthony de Boer, ASR From cidr-report at potaroo.net Fri Jun 13 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Jun 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201406132200.s5DM002q076255@wattle.apnic.net> This report has been generated at Fri Jun 13 21:13:55 2014 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 06-06-14 503988 283058 07-06-14 504175 283106 08-06-14 504267 283254 09-06-14 504261 283277 10-06-14 504250 283436 11-06-14 504807 283824 12-06-14 505124 284100 13-06-14 505414 283778 AS Summary 47338 Number of ASes in routing system 19209 Number of ASes announcing only one prefix 3771 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120370944 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'). --- 13Jun14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 505548 284113 221435 43.8% All ASes AS28573 3771 150 3621 96.0% NET Servi�os de Comunica��o S.A.,BR AS6389 2956 72 2884 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2794 246 2548 91.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2935 931 2004 68.3% KIXS-AS-KR Korea Telecom,KR AS18881 2037 41 1996 98.0% Global Village Telecom,BR AS7029 2350 446 1904 81.0% WINDSTREAM - Windstream Communications Inc,US AS10620 2883 1381 1502 52.1% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS7303 1769 443 1326 75.0% Telecom Argentina S.A.,AR AS4755 1859 586 1273 68.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2277 1049 1228 53.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1645 427 1218 74.0% TWTC - tw telecom holdings, inc.,US AS22773 2528 1418 1110 43.9% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS7552 1269 171 1098 86.5% VIETEL-AS-AP Viettel Corporation,VN AS36998 1114 37 1077 96.7% SDN-MOBITEL,SD AS22561 1309 242 1067 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1368 315 1053 77.0% ITCDELTA - Earthlink, Inc.,US AS9829 1647 731 916 55.6% BSNL-NIB National Internet Backbone,IN AS4788 1060 147 913 86.1% TMNET-AS-AP TM Net, Internet Service Provider,MY AS9808 1011 162 849 84.0% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS24560 1162 334 828 71.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4808 1227 411 816 66.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS7738 979 193 786 80.3% Telemar Norte Leste S.A.,BR AS18101 941 185 756 80.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS8151 1429 683 746 52.2% Uninet S.A. de C.V.,MX AS11492 1233 498 735 59.6% CABLEONE - CABLE ONE, INC.,US AS701 1446 733 713 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS855 764 58 706 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS6147 823 126 697 84.7% Telefonica del Peru S.A.A.,PE AS26615 863 167 696 80.6% Tim Celular S.A.,BR Total 51496 12948 38548 74.9% Top 30 total Possible Bogus Routes 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.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.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -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 45.64.80.0/24 AS59325 IXSFORALLINC-AS-AP IXSFORALL, INC.,PH 45.64.81.0/24 AS59325 IXSFORALLINC-AS-AP IXSFORALL, INC.,PH 45.64.82.0/24 AS59325 IXSFORALLINC-AS-AP IXSFORALL, INC.,PH 45.64.83.0/24 AS59325 IXSFORALLINC-AS-AP IXSFORALL, INC.,PH 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 64.253.224.0/19 AS20428 -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 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 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 69.57.64.0/20 AS20428 -Reserved AS-,ZZ 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 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.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -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.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 100.88.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.89.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.90.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.91.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.92.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.93.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.94.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.95.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.96.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.104.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.112.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.120.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.124.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.92.0/22 AS13269 103.18.92.0/24 AS13269 103.18.94.0/24 AS13269 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.23.48.0/24 AS56194 103.23.49.0/24 AS56194 103.23.50.0/24 AS56194 103.23.51.0/24 AS56194 103.233.182.0/24 AS13309 F1SOFT-NP F-1 Soft International Pvt Ltd,NP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.249.132.0/22 AS18097 DCN D.C.N. Corporation,JP 104.37.52.0/22 AS20205 AMPLEX - Amplex Electric, Inc.,US 104.139.0.0/16 AS10796 SCRR-10796 - Time Warner Cable Internet LLC,US 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 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 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 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.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,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.104.61.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,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.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,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 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 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.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.46.0/24 AS24802 -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.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 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.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 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.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT 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 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 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.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 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.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech 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.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.146.36.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 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.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 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 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 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 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 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.192.0/20 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.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 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.101.104.0/24 AS54508 M5ROCHESTER - M5 Networks, Inc.,US 199.101.105.0/24 AS18649 M5-NETWORKS - M5 Networks, Inc.,US 199.101.107.0/24 AS18649 M5-NETWORKS - M5 Networks, Inc.,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 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 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 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 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.9.40.0/24 AS56194 202.9.41.0/24 AS56194 202.9.42.0/24 AS56194 202.9.43.0/24 AS56194 202.9.44.0/24 AS56194 202.9.45.0/24 AS56194 202.9.46.0/24 AS56194 202.9.47.0/24 AS56194 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 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.10.94.0/23 AS30097 NUWAVE - NuWave,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.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 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.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 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.128.0/24 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.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,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.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 208.86.72.0/21 AS36371 -Reserved AS-,ZZ 208.95.192.0/21 AS18649 M5-NETWORKS - M5 Networks, Inc.,US 208.95.193.0/24 AS36371 -Reserved AS-,ZZ 208.95.195.0/24 AS36371 -Reserved AS-,ZZ 208.95.196.0/24 AS36371 -Reserved AS-,ZZ 208.95.199.0/24 AS36371 -Reserved AS-,ZZ 209.90.192.0/19 AS20428 -Reserved AS-,ZZ 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,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 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.157.160.0/19 AS20428 -Reserved AS-,ZZ 216.157.172.0/24 AS20428 -Reserved AS-,ZZ 216.157.173.0/24 AS20428 -Reserved AS-,ZZ 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 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 Jun 13 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Jun 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201406132200.s5DM029X076273@wattle.apnic.net> BGP Update Report Interval: 05-Jun-14 -to- 12-Jun-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 138352 5.2% 145.6 -- BSNL-NIB National Internet Backbone,IN 2 - AS26615 93521 3.5% 134.8 -- Tim Celular S.A.,BR 3 - AS31148 58271 2.2% 57.1 -- FREENET-AS Freenet Ltd.,UA 4 - AS14287 38386 1.4% 6397.7 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 5 - AS29571 36730 1.4% 256.9 -- CITelecom-AS,CI 6 - AS8402 34862 1.3% 122.8 -- CORBINA-AS OJSC "Vimpelcom",RU 7 - AS18004 29506 1.1% 347.1 -- WIRELESSNET-ID-AP WIRELESSNET AS,ID 8 - AS28573 24775 0.9% 6.4 -- NET Servi�os de Comunica��o S.A.,BR 9 - AS23752 22684 0.8% 257.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 10 - AS41691 20834 0.8% 1041.7 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 11 - AS7643 20005 0.8% 116.3 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT),VN 12 - AS45899 19088 0.7% 53.6 -- VNPT-AS-VN VNPT Corp,VN 13 - AS3816 18718 0.7% 35.0 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 14 - AS4775 15079 0.6% 307.7 -- GLOBE-TELECOM-AS Globe Telecoms,PH 15 - AS17974 14694 0.6% 14.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 16 - AS1452 13298 0.5% 72.7 -- DNIC-ASBLK-01451-01456 - Headquarters, USAISC,US 17 - AS7029 12438 0.5% 5.0 -- WINDSTREAM - Windstream Communications Inc,US 18 - AS11830 11821 0.4% 30.5 -- Instituto Costarricense de Electricidad y Telecom.,CR 19 - AS6849 11757 0.4% 19.0 -- UKRTELNET JSC UKRTELECOM,UA 20 - AS647 11040 0.4% 99.5 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54465 8431 0.3% 8431.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 2 - AS14287 38386 1.4% 6397.7 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 3 - AS45590 3282 0.1% 3282.0 -- HGCINTNET-AS-AP Hutch Connect,HK 4 - AS26661 8826 0.3% 2942.0 -- JCPS-ASN - Jeffco Public Schools,US 5 - AS60345 4649 0.2% 2324.5 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 6 - AS2167 10650 0.4% 2130.0 -- HPES - Hewlett-Packard Company,US 7 - AS42472 1795 0.1% 1795.0 -- SMARTEN-AS AS Smarten Logistics,EE 8 - AS6629 8652 0.3% 1730.4 -- NOAA-AS - NOAA,US 9 - AS60599 1203 0.1% 1203.0 -- WEBKOMPAS-AS Emelyanov Valentin Petrovich,RU 10 - AS41691 20834 0.8% 1041.7 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 11 - AS18135 6905 0.3% 986.4 -- BTV BTV Cable television,JP 12 - AS24705 941 0.0% 941.0 -- COMGW The Communication Gateway Ltd,GB 13 - AS61337 1871 0.1% 935.5 -- ECOM-AS Electronic Communities Ltd.,GB 14 - AS59462 900 0.0% 900.0 -- VTK-AS VTK Ltd,RU 15 - AS24683 838 0.0% 838.0 -- OSU-AS State Educational Institution of Higher Professional Education Orenburg State University,RU 16 - AS37447 3124 0.1% 781.0 -- OASIS-SPRL,CD 17 - AS40622 722 0.0% 722.0 -- LONGBOWCAP - Longbow Capital Partners, L.P.,US 18 - AS18379 704 0.0% 704.0 -- CSMNAP-AS-AP CSMNAP-ASN,ID 19 - AS58115 10642 0.4% 591.2 -- DATALABS-AS DATALABS Ltd,RU 20 - AS7868 1176 0.0% 588.0 -- DATA-LIFE - Data Life Associates, Inc.,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 20663 0.7% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 202.70.64.0/21 10917 0.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.88.0/21 10899 0.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 192.58.232.0/24 8611 0.3% AS6629 -- NOAA-AS - NOAA,US 5 - 206.152.15.0/24 8431 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 6 - 205.247.12.0/24 8112 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 7 - 216.162.0.0/20 7698 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 8 - 208.73.244.0/22 7690 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 9 - 208.70.20.0/22 7686 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 10 - 208.78.116.0/22 7668 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 11 - 208.88.232.0/22 7634 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 12 - 120.28.62.0/24 7533 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 13 - 222.127.0.0/24 7236 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 14 - 42.83.48.0/20 6893 0.2% AS18135 -- BTV BTV Cable television,JP 15 - 177.54.145.0/24 5578 0.2% AS4 -- ISI-AS - University of Southern California,US 16 - 46.53.64.0/19 4258 0.1% AS24814 -- SCS-AS Syrian Computer Society, scs,SY AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY 17 - 112.137.16.0/20 3282 0.1% AS45590 -- HGCINTNET-AS-AP Hutch Connect,HK 18 - 78.109.192.0/20 3260 0.1% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 19 - 166.149.142.0/24 3114 0.1% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 20 - 199.96.189.0/24 2942 0.1% AS26661 -- JCPS-ASN - Jeffco Public Schools,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 robertg at garlic.com Fri Jun 13 23:28:21 2014 From: robertg at garlic.com (Robert Glover) Date: Fri, 13 Jun 2014 16:28:21 -0700 Subject: IPV6 and Charter Cable In-Reply-To: <539B537E.2010606@gmail.com> References: <539B537E.2010606@gmail.com> Message-ID: <539B8915.3010803@garlic.com> HA! I've been bugging Charter for 2 years. There was a "beta" program that they metioned on NANOG a while back that I tried to get on-board wth. That never came to fruition.. As of 2 months ago, they are still not offering IPv6.... On 6/13/2014 12:39 PM, Roy wrote: > Does Charter Cable have IPV6 for businesses yet? If so can someone > point me in the right direction. Their NOC seems to be clueless on > their IPV6 plans > From joelja at bogus.com Sat Jun 14 02:29:37 2014 From: joelja at bogus.com (joel jaeggli) Date: Fri, 13 Jun 2014 19:29:37 -0700 Subject: routing issues to AWS via 2914(NTT) In-Reply-To: <20140613212829.GY8158@hezmatt.org> References: <20140613212829.GY8158@hezmatt.org> Message-ID: <539BB391.6020306@bogus.com> On 6/13/14, 2:28 PM, Matt Palmer wrote: > On Fri, Jun 13, 2014 at 11:44:51AM +0000, Paul WALL wrote: >> Amazon peers at many key exchanges, with dozens of hosting shops >> (where customers might share mutual infrastructure) like yours: >> >> https://www.peeringdb.com/view.php?asn=16509 >> >> Rather than play the blame game with third-party transit providers, >> why not hit them up for some sessions? > > That'll only get you peering connectivity into the local region. To get > fully-peered with AWS, and be able to avoid third-party transit providers > entirely, you're going to have to be in a *lot* of places. > > Not saying that AWS is a bad peer (from experience, I know they're fine to > deal with) but it isn't as cut-and-dried as saying "don't blame transit > providers, just peer!". just peer in IAD, SEA and SJC, and AMS, and SIN. problem solved, yup. > - Matt > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 286 bytes Desc: OpenPGP digital signature URL: From dhill+nanog at mindcry.org Fri Jun 13 20:00:48 2014 From: dhill+nanog at mindcry.org (David Hill) Date: Fri, 13 Jun 2014 16:00:48 -0400 Subject: IPV6 and Charter Cable In-Reply-To: <539B537E.2010606@gmail.com> References: <539B537E.2010606@gmail.com> Message-ID: <20140613200047.GB18702@306043821c6db2072454758752e2802553141a9587427a5e> On Fri, Jun 13, 2014 at 12:39:42PM -0700, Roy wrote: > Does Charter Cable have IPV6 for businesses yet? If so can someone > point me in the right direction. Their NOC seems to be clueless on > their IPV6 plans I have the same issue; no one can give me an answer on when. They had a link on their business website stating you could sign up for "beta" testing. When I asked my sales rep to sign me up, I received a call back stating they weren't doing beta testing and that they were going to remove the link from their website. http://www.prnewswire.com/news-releases/charter-prepares-for-world-ipv6-day-122445413.html ... "Charter will provide more information on IPv6 deployment as we approach full deployment in 2012." 2 years later and as far as I know, they haven't started deployment. As far as I know, they are only providing 6rd. http://www.myaccount.charter.com/customers/Support.aspx?SupportArticleID=2665#ipv6prep - David From richard at mesh.net Sat Jun 14 15:40:02 2014 From: richard at mesh.net (Richard Strittmatter) Date: Sat, 14 Jun 2014 15:40:02 +0000 Subject: IPV6 and Charter Cable In-Reply-To: <20140613200047.GB18702@306043821c6db2072454758752e2802553141a9587427a5e> References: <539B537E.2010606@gmail.com> <20140613200047.GB18702@306043821c6db2072454758752e2802553141a9587427a5e> Message-ID: We just turned up another BGP IPV4 circuit with them the other day, when I pressed for IPV6, I was told "End of year we might have it ready for deployment". Richard Strittmatter richard at mesh.net -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hill Sent: Friday, June 13, 2014 3:01 PM To: nanog at nanog.org Subject: Re: IPV6 and Charter Cable On Fri, Jun 13, 2014 at 12:39:42PM -0700, Roy wrote: > Does Charter Cable have IPV6 for businesses yet? If so can someone > point me in the right direction. Their NOC seems to be clueless on > their IPV6 plans I have the same issue; no one can give me an answer on when. They had a link on their business website stating you could sign up for "beta" testing. When I asked my sales rep to sign me up, I received a call back stating they weren't doing beta testing and that they were going to remove the link from their website. http://www.prnewswire.com/news-releases/charter-prepares-for-world-ipv6-day-122445413.html ... "Charter will provide more information on IPv6 deployment as we approach full deployment in 2012." 2 years later and as far as I know, they haven't started deployment. As far as I know, they are only providing 6rd. http://www.myaccount.charter.com/customers/Support.aspx?SupportArticleID=2665#ipv6prep - David From mikeal.clark at gmail.com Sat Jun 14 17:01:24 2014 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Sat, 14 Jun 2014 12:01:24 -0500 Subject: Can anyone check this routing against Charter in WI? Message-ID: Hoping someone auditing the list can provide some insight or a back channel support option. I started having some good latency spikes last night, which have continued this morning, so I finally took a look at things and I am seeing a lot more routing than I expected. Support is telling me this is normal but I don't remember this many replies on traceroute. My speeds are about 1/5 the normal as well this morning and seeing some dropped packets even using a test sight inside Charter's network. This is just business cable so my support options are pretty limited. 4 10 ms 14 ms 13 ms dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] 5 18 ms 11 ms 17 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com [96.34.30.17] 6 12 ms 11 ms 11 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com [96.34.24.56] 7 17 ms 11 ms 11 ms dtr02fdulwi-bue-3.fdul.wi.charter.com [96.34.30.19] 8 13 ms 18 ms 18 ms dtr01fdulwi-bue-1.fdul.wi.charter.com [96.34.19.144] 9 19 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com [96.34.20.8] 10 30 ms 22 ms 35 ms crr02euclwi-bue-6.eucl.wi.charter.com [96.34.22.240] 11 23 ms 22 ms 43 ms bbr02euclwi-bue-4.eucl.wi.charter.com [96.34.2.6] 12 22 ms 34 ms 19 ms bbr01euclwi-bue-5.eucl.wi.charter.com [96.34.0.6] 13 34 ms 30 ms 38 ms bbr01stcdmn-tge-0-0-0-3.stcd.mn.charter.com [96.34.0.115] 14 42 ms 43 ms 52 ms 65.46.47.77 15 78 ms 78 ms 92 ms ae1d0.mcr2.minneapolis-mn.us.xo.net [216.156.1.86] 16 93 ms 82 ms 82 ms vb1711.rar3.denver-co.us.xo.net [216.156.0.173] 17 81 ms 95 ms 82 ms te-3-0-0.rar3.sanjose-ca.us.xo.net [207.88.12.58] 18 83 ms 82 ms 98 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226] 19 81 ms 78 ms 78 ms 216.156.84.6.ptr.us.xo.net [216.156.84.6] 20 77 ms 78 ms 88 ms xe-2-2-0-955.jnrt-edge02.prod1.netflix.com [69.53.225.30] 21 86 ms 78 ms 78 ms te1-8.csrt-agg02.prod1.netflix.com [69.53.225.10] 22 79 ms 78 ms 82 ms www.trynetflix.com [69.53.236.17] 4 12 ms 11 ms 8 ms dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] 5 17 ms 10 ms 12 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com [96.34.30.17] 6 11 ms 9 ms 15 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com [96.34.24.56] 7 15 ms 18 ms 18 ms dtr02fdulwi-bue-3.fdul.wi.charter.com [96.34.30.19] 8 16 ms 14 ms 11 ms dtr01fdulwi-bue-1.fdul.wi.charter.com [96.34.19.144] 9 20 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com [96.34.20.8] 10 22 ms 22 ms 18 ms crr02euclwi-bue-6.eucl.wi.charter.com [96.34.22.240] 11 18 ms 22 ms 22 ms bbr02euclwi-bue-4.eucl.wi.charter.com [96.34.2.6] 12 35 ms 30 ms 31 ms bbr01chcgil-bue-1.chcg.il.charter.com [96.34.0.9] 13 27 ms 27 ms 27 ms prr01chcgil-bue-2.chcg.il.charter.com [96.34.3.9] 14 27 ms 27 ms 27 ms 96-34-152-30.static.unas.mo.charter.com [96.34.152.30] 15 29 ms 32 ms 27 ms 209.85.244.1 16 27 ms 27 ms 28 ms 209.85.254.238 17 54 ms 40 ms 40 ms 209.85.248.214 18 38 ms 40 ms 38 ms 216.239.43.217 19 * * * Request timed out. 20 44 ms 40 ms 40 ms google-public-dns-a.google.com [8.8.8.8] From shawnl at up.net Sat Jun 14 17:04:58 2014 From: shawnl at up.net (Shawn L) Date: Sat, 14 Jun 2014 13:04:58 -0400 Subject: Can anyone check this routing against Charter in WI? In-Reply-To: References: Message-ID: It seems ok from here traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 4 dtr02rhnlwi-bue-1.rhnl.wi.charter.com (96.34.16.250) 20.843 ms 21.236 ms 21.616 ms 5 crr02euclwi-bue-7.eucl.wi.charter.com (96.34.17.32) 27.662 ms 36.047 ms 35.623 ms 6 bbr02euclwi-bue-4.eucl.wi.charter.com (96.34.2.6) 29.236 ms 20.299 ms 22.945 ms 7 bbr01chcgil-bue-1.chcg.il.charter.com (96.34.0.9) 42.318 ms 41.481 ms 41.870 ms 8 prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9) 38.591 ms 39.788 ms 39.778 ms 9 96-34-152-30.static.unas.mo.charter.com (96.34.152.30) 38.984 ms 38.960 ms 39.340 ms 10 209.85.244.3 (209.85.244.3) 37.632 ms 209.85.244.1 (209.85.244.1) 37.215 ms 36.797 ms 11 209.85.254.238 (209.85.254.238) 44.062 ms 72.14.237.133 (72.14.237.133) 44.463 ms 209.85.254.240 (209.85.254.240) 47.027 ms 12 72.14.238.104 (72.14.238.104) 49.036 ms 72.14.232.141 (72.14.232.141) 52.766 ms 209.85.248.214 (209.85.248.214) 50.605 ms 13 216.239.46.193 (216.239.46.193) 47.927 ms 47.469 ms 216.239.43.217 (216.239.43.217) 49.303 ms 14 * * * 15 google-public-dns-a.google.com (8.8.8.8) 51.746 ms 52.841 ms 48.300 ms On Sat, Jun 14, 2014 at 1:01 PM, Mikeal Clark wrote: > Hoping someone auditing the list can provide some insight or a back > channel support option. > > I started having some good latency spikes last night, which have > continued this morning, so I finally took a look at things and I am > seeing a lot more routing than I expected. Support is telling me this > is normal but I don't remember this many replies on traceroute. My > speeds are about 1/5 the normal as well this morning and seeing some > dropped packets even using a test sight inside Charter's network. > This is just business cable so my support options are pretty limited. > > 4 10 ms 14 ms 13 ms > dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] > 5 18 ms 11 ms 17 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com > [96.34.30.17] > 6 12 ms 11 ms 11 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com > [96.34.24.56] > 7 17 ms 11 ms 11 ms dtr02fdulwi-bue-3.fdul.wi.charter.com > [96.34.30.19] > 8 13 ms 18 ms 18 ms dtr01fdulwi-bue-1.fdul.wi.charter.com > [96.34.19.144] > 9 19 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com > [96.34.20.8] > 10 30 ms 22 ms 35 ms crr02euclwi-bue-6.eucl.wi.charter.com > [96.34.22.240] > 11 23 ms 22 ms 43 ms bbr02euclwi-bue-4.eucl.wi.charter.com > [96.34.2.6] > 12 22 ms 34 ms 19 ms bbr01euclwi-bue-5.eucl.wi.charter.com > [96.34.0.6] > 13 34 ms 30 ms 38 ms > bbr01stcdmn-tge-0-0-0-3.stcd.mn.charter.com [96.34.0.115] > 14 42 ms 43 ms 52 ms 65.46.47.77 > 15 78 ms 78 ms 92 ms ae1d0.mcr2.minneapolis-mn.us.xo.net > [216.156.1.86] > 16 93 ms 82 ms 82 ms vb1711.rar3.denver-co.us.xo.net > [216.156.0.173] > 17 81 ms 95 ms 82 ms te-3-0-0.rar3.sanjose-ca.us.xo.net > [207.88.12.58] > 18 83 ms 82 ms 98 ms 207.88.14.226.ptr.us.xo.net > [207.88.14.226] > 19 81 ms 78 ms 78 ms 216.156.84.6.ptr.us.xo.net [216.156.84.6] > 20 77 ms 78 ms 88 ms > xe-2-2-0-955.jnrt-edge02.prod1.netflix.com [69.53.225.30] > 21 86 ms 78 ms 78 ms te1-8.csrt-agg02.prod1.netflix.com > [69.53.225.10] > 22 79 ms 78 ms 82 ms www.trynetflix.com [69.53.236.17] > > 4 12 ms 11 ms 8 ms > dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] > 5 17 ms 10 ms 12 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com > [96.34.30.17] > 6 11 ms 9 ms 15 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com > [96.34.24.56] > 7 15 ms 18 ms 18 ms dtr02fdulwi-bue-3.fdul.wi.charter.com > [96.34.30.19] > 8 16 ms 14 ms 11 ms dtr01fdulwi-bue-1.fdul.wi.charter.com > [96.34.19.144] > 9 20 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com > [96.34.20.8] > 10 22 ms 22 ms 18 ms crr02euclwi-bue-6.eucl.wi.charter.com > [96.34.22.240] > 11 18 ms 22 ms 22 ms bbr02euclwi-bue-4.eucl.wi.charter.com > [96.34.2.6] > 12 35 ms 30 ms 31 ms bbr01chcgil-bue-1.chcg.il.charter.com > [96.34.0.9] > 13 27 ms 27 ms 27 ms prr01chcgil-bue-2.chcg.il.charter.com > [96.34.3.9] > 14 27 ms 27 ms 27 ms > 96-34-152-30.static.unas.mo.charter.com [96.34.152.30] > 15 29 ms 32 ms 27 ms 209.85.244.1 > 16 27 ms 27 ms 28 ms 209.85.254.238 > 17 54 ms 40 ms 40 ms 209.85.248.214 > 18 38 ms 40 ms 38 ms 216.239.43.217 > 19 * * * Request timed out. > 20 44 ms 40 ms 40 ms google-public-dns-a.google.com [8.8.8.8] > From mikeal.clark at gmail.com Sat Jun 14 17:45:22 2014 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Sat, 14 Jun 2014 12:45:22 -0500 Subject: Can anyone check this routing against Charter in WI? In-Reply-To: References: Message-ID: Thanks Shawn. That is more along the lines of what I expected to see. On Sat, Jun 14, 2014 at 12:04 PM, Shawn L wrote: > It seems ok from here > > traceroute 8.8.8.8 > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets > > 4 dtr02rhnlwi-bue-1.rhnl.wi.charter.com (96.34.16.250) 20.843 ms 21.236 > ms 21.616 ms > 5 crr02euclwi-bue-7.eucl.wi.charter.com (96.34.17.32) 27.662 ms 36.047 > ms 35.623 ms > 6 bbr02euclwi-bue-4.eucl.wi.charter.com (96.34.2.6) 29.236 ms 20.299 > ms 22.945 ms > 7 bbr01chcgil-bue-1.chcg.il.charter.com (96.34.0.9) 42.318 ms 41.481 > ms 41.870 ms > 8 prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9) 38.591 ms 39.788 > ms 39.778 ms > 9 96-34-152-30.static.unas.mo.charter.com (96.34.152.30) 38.984 ms > 38.960 ms 39.340 ms > 10 209.85.244.3 (209.85.244.3) 37.632 ms 209.85.244.1 (209.85.244.1) > 37.215 ms 36.797 ms > 11 209.85.254.238 (209.85.254.238) 44.062 ms 72.14.237.133 > (72.14.237.133) 44.463 ms 209.85.254.240 (209.85.254.240) 47.027 ms > 12 72.14.238.104 (72.14.238.104) 49.036 ms 72.14.232.141 (72.14.232.141) > 52.766 ms 209.85.248.214 (209.85.248.214) 50.605 ms > 13 216.239.46.193 (216.239.46.193) 47.927 ms 47.469 ms 216.239.43.217 > (216.239.43.217) 49.303 ms > 14 * * * > 15 google-public-dns-a.google.com (8.8.8.8) 51.746 ms 52.841 ms 48.300 > ms > > > > On Sat, Jun 14, 2014 at 1:01 PM, Mikeal Clark > wrote: > >> Hoping someone auditing the list can provide some insight or a back >> channel support option. >> >> I started having some good latency spikes last night, which have >> continued this morning, so I finally took a look at things and I am >> seeing a lot more routing than I expected. Support is telling me this >> is normal but I don't remember this many replies on traceroute. My >> speeds are about 1/5 the normal as well this morning and seeing some >> dropped packets even using a test sight inside Charter's network. >> This is just business cable so my support options are pretty limited. >> >> 4 10 ms 14 ms 13 ms >> dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] >> 5 18 ms 11 ms 17 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com >> [96.34.30.17] >> 6 12 ms 11 ms 11 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com >> [96.34.24.56] >> 7 17 ms 11 ms 11 ms dtr02fdulwi-bue-3.fdul.wi.charter.com >> [96.34.30.19] >> 8 13 ms 18 ms 18 ms dtr01fdulwi-bue-1.fdul.wi.charter.com >> [96.34.19.144] >> 9 19 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com >> [96.34.20.8] >> 10 30 ms 22 ms 35 ms crr02euclwi-bue-6.eucl.wi.charter.com >> [96.34.22.240] >> 11 23 ms 22 ms 43 ms bbr02euclwi-bue-4.eucl.wi.charter.com >> [96.34.2.6] >> 12 22 ms 34 ms 19 ms bbr01euclwi-bue-5.eucl.wi.charter.com >> [96.34.0.6] >> 13 34 ms 30 ms 38 ms >> bbr01stcdmn-tge-0-0-0-3.stcd.mn.charter.com [96.34.0.115] >> 14 42 ms 43 ms 52 ms 65.46.47.77 >> 15 78 ms 78 ms 92 ms ae1d0.mcr2.minneapolis-mn.us.xo.net >> [216.156.1.86] >> 16 93 ms 82 ms 82 ms vb1711.rar3.denver-co.us.xo.net >> [216.156.0.173] >> 17 81 ms 95 ms 82 ms te-3-0-0.rar3.sanjose-ca.us.xo.net >> [207.88.12.58] >> 18 83 ms 82 ms 98 ms 207.88.14.226.ptr.us.xo.net >> [207.88.14.226] >> 19 81 ms 78 ms 78 ms 216.156.84.6.ptr.us.xo.net [216.156.84.6] >> 20 77 ms 78 ms 88 ms >> xe-2-2-0-955.jnrt-edge02.prod1.netflix.com [69.53.225.30] >> 21 86 ms 78 ms 78 ms te1-8.csrt-agg02.prod1.netflix.com >> [69.53.225.10] >> 22 79 ms 78 ms 82 ms www.trynetflix.com [69.53.236.17] >> >> 4 12 ms 11 ms 8 ms >> dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] >> 5 17 ms 10 ms 12 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com >> [96.34.30.17] >> 6 11 ms 9 ms 15 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com >> [96.34.24.56] >> 7 15 ms 18 ms 18 ms dtr02fdulwi-bue-3.fdul.wi.charter.com >> [96.34.30.19] >> 8 16 ms 14 ms 11 ms dtr01fdulwi-bue-1.fdul.wi.charter.com >> [96.34.19.144] >> 9 20 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com >> [96.34.20.8] >> 10 22 ms 22 ms 18 ms crr02euclwi-bue-6.eucl.wi.charter.com >> [96.34.22.240] >> 11 18 ms 22 ms 22 ms bbr02euclwi-bue-4.eucl.wi.charter.com >> [96.34.2.6] >> 12 35 ms 30 ms 31 ms bbr01chcgil-bue-1.chcg.il.charter.com >> [96.34.0.9] >> 13 27 ms 27 ms 27 ms prr01chcgil-bue-2.chcg.il.charter.com >> [96.34.3.9] >> 14 27 ms 27 ms 27 ms >> 96-34-152-30.static.unas.mo.charter.com [96.34.152.30] >> 15 29 ms 32 ms 27 ms 209.85.244.1 >> 16 27 ms 27 ms 28 ms 209.85.254.238 >> 17 54 ms 40 ms 40 ms 209.85.248.214 >> 18 38 ms 40 ms 38 ms 216.239.43.217 >> 19 * * * Request timed out. >> 20 44 ms 40 ms 40 ms google-public-dns-a.google.com [8.8.8.8] >> From sethm at rollernet.us Sat Jun 14 21:27:05 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 14 Jun 2014 14:27:05 -0700 Subject: IPV6 and Charter Cable In-Reply-To: <539B537E.2010606@gmail.com> References: <539B537E.2010606@gmail.com> Message-ID: <539CBE29.8010000@rollernet.us> On 6/13/14, 12:39, Roy wrote: > Does Charter Cable have IPV6 for businesses yet? If so can someone > point me in the right direction. Their NOC seems to be clueless on > their IPV6 plans I have native IPv6 with BGP on Charter (AS20115) since January 2013. Coax is probably still "no". ~Seth From r.engehausen at gmail.com Sat Jun 14 23:31:36 2014 From: r.engehausen at gmail.com (Roy) Date: Sat, 14 Jun 2014 16:31:36 -0700 Subject: IPV6 and Charter Cable In-Reply-To: <539CBE29.8010000@rollernet.us> References: <539B537E.2010606@gmail.com> <539CBE29.8010000@rollernet.us> Message-ID: <539CDB58.5050103@gmail.com> On 6/14/2014 2:27 PM, Seth Mattinen wrote: > On 6/13/14, 12:39, Roy wrote: >> Does Charter Cable have IPV6 for businesses yet? If so can someone >> point me in the right direction. Their NOC seems to be clueless on >> their IPV6 plans > > > I have native IPv6 with BGP on Charter (AS20115) since January 2013. > > Coax is probably still "no". > > ~Seth > My clients are both on Charter Business fiber circuits. I am on the West Coast From rdekema at gmail.com Mon Jun 16 00:10:33 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Sun, 15 Jun 2014 20:10:33 -0400 Subject: Can anyone check this routing against Charter in WI? In-Reply-To: References: Message-ID: Are you still seeing odd routing with Charter in Wisconsin? Charter's routing in Michigan seems to be going pretty crazy at the moment as well. The following traceroute is from a Charter residential line* in Kalamazoo MI to a Comcast business (DOCSIS) line in Ypsilanti MI, by way of several unknown hops, some of which are in RFC 1918 space, Sprintlink possibly in Fort Worth TX, another unknown hop, then Comcast Dallas TX, Comcast Marietta GA, Comcast Ashburn VA, then finally Comcast MI. Needless to say, this is not the normal route: http://pastebin.com/9CKmea6M Tracing the same route but in the other direction also yields odd results. The route proceeds normally to a Comcast ibone router in 350 E. Cermak (Chicago IL), but the very next hop after that router is the public IP of the Charter service in Kalamazoo MI as follows: http://pastebin.com/VCCgnUsn For what it's worth, if anyone could explain to me what might cause that behavior (between hops 8 and 9), I would really appreciate the knowledge. The routing between that same Charter residential service and a Merit/Michnet endpoint in southeast Michigan is also odd, taking a detour through Virginia [xe-8-3-0.1018.asbn0.tr-cps.internet2.edu (198.71.47.25)], which it does not normally do. The routing in that case does appear to be the same regardless of which side you initiate the traceroute from. Cheers, Rusty Dekema * The Charter residential line's IP address is currently reverse resolving to a Charter DHCP pool in Bay City, MI, which is over 100 miles from Kalamazoo. This is also unusual. The Charter service in question is now and has always been located in Kalamazoo MI. On Sat, Jun 14, 2014 at 1:01 PM, Mikeal Clark wrote: > Hoping someone auditing the list can provide some insight or a back > channel support option. > > I started having some good latency spikes last night, which have > continued this morning, so I finally took a look at things and I am > seeing a lot more routing than I expected. Support is telling me this > is normal but I don't remember this many replies on traceroute. My > speeds are about 1/5 the normal as well this morning and seeing some > dropped packets even using a test sight inside Charter's network. > This is just business cable so my support options are pretty limited. > > 4 10 ms 14 ms 13 ms > dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] > 5 18 ms 11 ms 17 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com > [96.34.30.17] > 6 12 ms 11 ms 11 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com > [96.34.24.56] > 7 17 ms 11 ms 11 ms dtr02fdulwi-bue-3.fdul.wi.charter.com > [96.34.30.19] > 8 13 ms 18 ms 18 ms dtr01fdulwi-bue-1.fdul.wi.charter.com > [96.34.19.144] > 9 19 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com > [96.34.20.8] > 10 30 ms 22 ms 35 ms crr02euclwi-bue-6.eucl.wi.charter.com > [96.34.22.240] > 11 23 ms 22 ms 43 ms bbr02euclwi-bue-4.eucl.wi.charter.com > [96.34.2.6] > 12 22 ms 34 ms 19 ms bbr01euclwi-bue-5.eucl.wi.charter.com > [96.34.0.6] > 13 34 ms 30 ms 38 ms > bbr01stcdmn-tge-0-0-0-3.stcd.mn.charter.com [96.34.0.115] > 14 42 ms 43 ms 52 ms 65.46.47.77 > 15 78 ms 78 ms 92 ms ae1d0.mcr2.minneapolis-mn.us.xo.net > [216.156.1.86] > 16 93 ms 82 ms 82 ms vb1711.rar3.denver-co.us.xo.net > [216.156.0.173] > 17 81 ms 95 ms 82 ms te-3-0-0.rar3.sanjose-ca.us.xo.net > [207.88.12.58] > 18 83 ms 82 ms 98 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226 > ] > 19 81 ms 78 ms 78 ms 216.156.84.6.ptr.us.xo.net [216.156.84.6] > 20 77 ms 78 ms 88 ms > xe-2-2-0-955.jnrt-edge02.prod1.netflix.com [69.53.225.30] > 21 86 ms 78 ms 78 ms te1-8.csrt-agg02.prod1.netflix.com > [69.53.225.10] > 22 79 ms 78 ms 82 ms www.trynetflix.com [69.53.236.17] > > 4 12 ms 11 ms 8 ms > dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] > 5 17 ms 10 ms 12 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com > [96.34.30.17] > 6 11 ms 9 ms 15 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com > [96.34.24.56] > 7 15 ms 18 ms 18 ms dtr02fdulwi-bue-3.fdul.wi.charter.com > [96.34.30.19] > 8 16 ms 14 ms 11 ms dtr01fdulwi-bue-1.fdul.wi.charter.com > [96.34.19.144] > 9 20 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com > [96.34.20.8] > 10 22 ms 22 ms 18 ms crr02euclwi-bue-6.eucl.wi.charter.com > [96.34.22.240] > 11 18 ms 22 ms 22 ms bbr02euclwi-bue-4.eucl.wi.charter.com > [96.34.2.6] > 12 35 ms 30 ms 31 ms bbr01chcgil-bue-1.chcg.il.charter.com > [96.34.0.9] > 13 27 ms 27 ms 27 ms prr01chcgil-bue-2.chcg.il.charter.com > [96.34.3.9] > 14 27 ms 27 ms 27 ms > 96-34-152-30.static.unas.mo.charter.com [96.34.152.30] > 15 29 ms 32 ms 27 ms 209.85.244.1 > 16 27 ms 27 ms 28 ms 209.85.254.238 > 17 54 ms 40 ms 40 ms 209.85.248.214 > 18 38 ms 40 ms 38 ms 216.239.43.217 > 19 * * * Request timed out. > 20 44 ms 40 ms 40 ms google-public-dns-a.google.com [8.8.8.8] > From mikeal.clark at gmail.com Mon Jun 16 00:20:54 2014 From: mikeal.clark at gmail.com (Michael Clark) Date: Sun, 15 Jun 2014 19:20:54 -0500 Subject: Can anyone check this routing against Charter in WI? In-Reply-To: References: Message-ID: Well my routing isn't nearly that bad. I haven't been able to get confirmation but support said they are probably just routing around a problem and they can't get any direct feedback form network engineers. I should get an update tomorrow hopefully. I'm also seeing some bandwidth issues on charters internal network. Something must be going on. Best to have up and go get some Bells :) Sent from my iPhone > On Jun 15, 2014, at 7:10 PM, Rusty Dekema wrote: > > Are you still seeing odd routing with Charter in Wisconsin? Charter's routing in Michigan seems to be going pretty crazy at the moment as well. > > The following traceroute is from a Charter residential line* in Kalamazoo MI to a Comcast business (DOCSIS) line in Ypsilanti MI, by way of several unknown hops, some of which are in RFC 1918 space, Sprintlink possibly in Fort Worth TX, another unknown hop, then Comcast Dallas TX, Comcast Marietta GA, Comcast Ashburn VA, then finally Comcast MI. Needless to say, this is not the normal route: > > http://pastebin.com/9CKmea6M > > Tracing the same route but in the other direction also yields odd results. The route proceeds normally to a Comcast ibone router in 350 E. Cermak (Chicago IL), but the very next hop after that router is the public IP of the Charter service in Kalamazoo MI as follows: > > http://pastebin.com/VCCgnUsn > > For what it's worth, if anyone could explain to me what might cause that behavior (between hops 8 and 9), I would really appreciate the knowledge. > > The routing between that same Charter residential service and a Merit/Michnet endpoint in southeast Michigan is also odd, taking a detour through Virginia [xe-8-3-0.1018.asbn0.tr-cps.internet2.edu (198.71.47.25)], which it does not normally do. The routing in that case does appear to be the same regardless of which side you initiate the traceroute from. > > Cheers, > Rusty Dekema > > > * The Charter residential line's IP address is currently reverse resolving to a Charter DHCP pool in Bay City, MI, which is over 100 miles from Kalamazoo. This is also unusual. The Charter service in question is now and has always been located in Kalamazoo MI. > > > > >> On Sat, Jun 14, 2014 at 1:01 PM, Mikeal Clark wrote: >> Hoping someone auditing the list can provide some insight or a back >> channel support option. >> >> I started having some good latency spikes last night, which have >> continued this morning, so I finally took a look at things and I am >> seeing a lot more routing than I expected. Support is telling me this >> is normal but I don't remember this many replies on traceroute. My >> speeds are about 1/5 the normal as well this morning and seeing some >> dropped packets even using a test sight inside Charter's network. >> This is just business cable so my support options are pretty limited. >> >> 4 10 ms 14 ms 13 ms >> dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] >> 5 18 ms 11 ms 17 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com >> [96.34.30.17] >> 6 12 ms 11 ms 11 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com >> [96.34.24.56] >> 7 17 ms 11 ms 11 ms dtr02fdulwi-bue-3.fdul.wi.charter.com >> [96.34.30.19] >> 8 13 ms 18 ms 18 ms dtr01fdulwi-bue-1.fdul.wi.charter.com >> [96.34.19.144] >> 9 19 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com >> [96.34.20.8] >> 10 30 ms 22 ms 35 ms crr02euclwi-bue-6.eucl.wi.charter.com >> [96.34.22.240] >> 11 23 ms 22 ms 43 ms bbr02euclwi-bue-4.eucl.wi.charter.com >> [96.34.2.6] >> 12 22 ms 34 ms 19 ms bbr01euclwi-bue-5.eucl.wi.charter.com >> [96.34.0.6] >> 13 34 ms 30 ms 38 ms >> bbr01stcdmn-tge-0-0-0-3.stcd.mn.charter.com [96.34.0.115] >> 14 42 ms 43 ms 52 ms 65.46.47.77 >> 15 78 ms 78 ms 92 ms ae1d0.mcr2.minneapolis-mn.us.xo.net >> [216.156.1.86] >> 16 93 ms 82 ms 82 ms vb1711.rar3.denver-co.us.xo.net [216.156.0.173] >> 17 81 ms 95 ms 82 ms te-3-0-0.rar3.sanjose-ca.us.xo.net >> [207.88.12.58] >> 18 83 ms 82 ms 98 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226] >> 19 81 ms 78 ms 78 ms 216.156.84.6.ptr.us.xo.net [216.156.84.6] >> 20 77 ms 78 ms 88 ms >> xe-2-2-0-955.jnrt-edge02.prod1.netflix.com [69.53.225.30] >> 21 86 ms 78 ms 78 ms te1-8.csrt-agg02.prod1.netflix.com >> [69.53.225.10] >> 22 79 ms 78 ms 82 ms www.trynetflix.com [69.53.236.17] >> >> 4 12 ms 11 ms 8 ms >> dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] >> 5 17 ms 10 ms 12 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com >> [96.34.30.17] >> 6 11 ms 9 ms 15 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com >> [96.34.24.56] >> 7 15 ms 18 ms 18 ms dtr02fdulwi-bue-3.fdul.wi.charter.com >> [96.34.30.19] >> 8 16 ms 14 ms 11 ms dtr01fdulwi-bue-1.fdul.wi.charter.com >> [96.34.19.144] >> 9 20 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com >> [96.34.20.8] >> 10 22 ms 22 ms 18 ms crr02euclwi-bue-6.eucl.wi.charter.com >> [96.34.22.240] >> 11 18 ms 22 ms 22 ms bbr02euclwi-bue-4.eucl.wi.charter.com >> [96.34.2.6] >> 12 35 ms 30 ms 31 ms bbr01chcgil-bue-1.chcg.il.charter.com >> [96.34.0.9] >> 13 27 ms 27 ms 27 ms prr01chcgil-bue-2.chcg.il.charter.com >> [96.34.3.9] >> 14 27 ms 27 ms 27 ms >> 96-34-152-30.static.unas.mo.charter.com [96.34.152.30] >> 15 29 ms 32 ms 27 ms 209.85.244.1 >> 16 27 ms 27 ms 28 ms 209.85.254.238 >> 17 54 ms 40 ms 40 ms 209.85.248.214 >> 18 38 ms 40 ms 38 ms 216.239.43.217 >> 19 * * * Request timed out. >> 20 44 ms 40 ms 40 ms google-public-dns-a.google.com [8.8.8.8] > From jhellenthal at dataix.net Mon Jun 16 01:15:45 2014 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sun, 15 Jun 2014 21:15:45 -0400 Subject: Can anyone check this routing against Charter in WI? In-Reply-To: References: Message-ID: No particular issues from where I'm at. Route - #1: 12.1 ms IP Address: 172.31.32.1 Hostname: gateway.dataix.local - #2: 5.2 ms IP Address: 192.168.1.1 - #3: 11.5 ms IP Address: 10.155.64.1 - #4: 14.0 ms IP Address: 96.34.34.206 Hostname: dtr02hlldmi-tge-0-1-1-2.hlld.mi.charter.com Country Name: United States Country Code: US - #5: 16.6 ms IP Address: 96.34.32.30 Hostname: crr02aldlmi-bue-12.aldl.mi.charter.com Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: California City: San Francisco Latitude: 37.775 Longitude: -122.419 - #6: 20.3 ms IP Address: 96.34.2.10 Hostname: bbr01aldlmi-bue-2.aldl.mi.charter.com Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: California City: San Francisco Latitude: 37.775 Longitude: -122.419 - #7: 23.7 ms IP Address: 96.34.0.99 Hostname: bbr01chcgil-bue-4.chcg.il.charter.com Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: California City: San Francisco Latitude: 37.775 Longitude: -122.419 - #8: 19.9 ms IP Address: 96.34.3.114 Hostname: prr02chcgil-bue-3.chcg.il.charter.com Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: California City: San Francisco Latitude: 37.775 Longitude: -122.419 - #9: 154.7 ms IP Address: 23.30.206.169 Hostname: be-204-pe04.350ecermak.il.ibone.comcast.net AS Number: AS7922 AS Name: Comcast Cable Communications, Inc. Country Name: United States Country Code: US - #10: 27.5 ms IP Address: 68.86.83.53 Hostname: he-3-1-0-0-cr01.350ecermak.il.ibone.comcast.net AS Number: AS7922 AS Name: Comcast Cable Communications, Inc. Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: California City: San Francisco Latitude: 37.775 Longitude: -122.419 - #11: 26.1 ms IP Address: 68.86.94.242 Hostname: he-0-12-0-0-ar01.pontiac.mi.michigan.comcast.net AS Number: AS7922 AS Name: Comcast Cable Communications, Inc. Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: California City: San Francisco Latitude: 37.775 Longitude: -122.419 - #12: 29.0 ms IP Address: 162.151.20.173 Hostname: te-0-8-0-7-ar01.taylor.mi.michigan.comcast.net AS Number: AS7922 AS Name: Comcast Cable Communications, Inc. Country Name: United States Country Code: US - #13: 26.9 ms IP Address: 68.85.223.185 Hostname: te-7-1-ur02.ypwest.mi.michigan.comcast.net AS Number: AS7922 AS Name: Comcast Cable Communications, Inc. Country Name: United States Country Code: US -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jun 15, 2014, at 20:20, Michael Clark wrote: > > Well my routing isn't nearly that bad. I haven't been able to get confirmation but support said they are probably just routing around a problem and they can't get any direct feedback form network engineers. > > I should get an update tomorrow hopefully. I'm also seeing some bandwidth issues on charters internal network. Something must be going on. > > Best to have up and go get some Bells :) > > Sent from my iPhone > >> On Jun 15, 2014, at 7:10 PM, Rusty Dekema wrote: >> >> Are you still seeing odd routing with Charter in Wisconsin? Charter's routing in Michigan seems to be going pretty crazy at the moment as well. >> >> The following traceroute is from a Charter residential line* in Kalamazoo MI to a Comcast business (DOCSIS) line in Ypsilanti MI, by way of several unknown hops, some of which are in RFC 1918 space, Sprintlink possibly in Fort Worth TX, another unknown hop, then Comcast Dallas TX, Comcast Marietta GA, Comcast Ashburn VA, then finally Comcast MI. Needless to say, this is not the normal route: >> >> http://pastebin.com/9CKmea6M >> >> Tracing the same route but in the other direction also yields odd results. The route proceeds normally to a Comcast ibone router in 350 E. Cermak (Chicago IL), but the very next hop after that router is the public IP of the Charter service in Kalamazoo MI as follows: >> >> http://pastebin.com/VCCgnUsn >> >> For what it's worth, if anyone could explain to me what might cause that behavior (between hops 8 and 9), I would really appreciate the knowledge. >> >> The routing between that same Charter residential service and a Merit/Michnet endpoint in southeast Michigan is also odd, taking a detour through Virginia [xe-8-3-0.1018.asbn0.tr-cps.internet2.edu (198.71.47.25)], which it does not normally do. The routing in that case does appear to be the same regardless of which side you initiate the traceroute from. >> >> Cheers, >> Rusty Dekema >> >> >> * The Charter residential line's IP address is currently reverse resolving to a Charter DHCP pool in Bay City, MI, which is over 100 miles from Kalamazoo. This is also unusual. The Charter service in question is now and has always been located in Kalamazoo MI. >> >> >> >> >>> On Sat, Jun 14, 2014 at 1:01 PM, Mikeal Clark wrote: >>> Hoping someone auditing the list can provide some insight or a back >>> channel support option. >>> >>> I started having some good latency spikes last night, which have >>> continued this morning, so I finally took a look at things and I am >>> seeing a lot more routing than I expected. Support is telling me this >>> is normal but I don't remember this many replies on traceroute. My >>> speeds are about 1/5 the normal as well this morning and seeing some >>> dropped packets even using a test sight inside Charter's network. >>> This is just business cable so my support options are pretty limited. >>> >>> 4 10 ms 14 ms 13 ms >>> dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] >>> 5 18 ms 11 ms 17 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com >>> [96.34.30.17] >>> 6 12 ms 11 ms 11 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com >>> [96.34.24.56] >>> 7 17 ms 11 ms 11 ms dtr02fdulwi-bue-3.fdul.wi.charter.com >>> [96.34.30.19] >>> 8 13 ms 18 ms 18 ms dtr01fdulwi-bue-1.fdul.wi.charter.com >>> [96.34.19.144] >>> 9 19 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com >>> [96.34.20.8] >>> 10 30 ms 22 ms 35 ms crr02euclwi-bue-6.eucl.wi.charter.com >>> [96.34.22.240] >>> 11 23 ms 22 ms 43 ms bbr02euclwi-bue-4.eucl.wi.charter.com >>> [96.34.2.6] >>> 12 22 ms 34 ms 19 ms bbr01euclwi-bue-5.eucl.wi.charter.com >>> [96.34.0.6] >>> 13 34 ms 30 ms 38 ms >>> bbr01stcdmn-tge-0-0-0-3.stcd.mn.charter.com [96.34.0.115] >>> 14 42 ms 43 ms 52 ms 65.46.47.77 >>> 15 78 ms 78 ms 92 ms ae1d0.mcr2.minneapolis-mn.us.xo.net >>> [216.156.1.86] >>> 16 93 ms 82 ms 82 ms vb1711.rar3.denver-co.us.xo.net [216.156.0.173] >>> 17 81 ms 95 ms 82 ms te-3-0-0.rar3.sanjose-ca.us.xo.net >>> [207.88.12.58] >>> 18 83 ms 82 ms 98 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226] >>> 19 81 ms 78 ms 78 ms 216.156.84.6.ptr.us.xo.net [216.156.84.6] >>> 20 77 ms 78 ms 88 ms >>> xe-2-2-0-955.jnrt-edge02.prod1.netflix.com [69.53.225.30] >>> 21 86 ms 78 ms 78 ms te1-8.csrt-agg02.prod1.netflix.com >>> [69.53.225.10] >>> 22 79 ms 78 ms 82 ms www.trynetflix.com [69.53.236.17] >>> >>> 4 12 ms 11 ms 8 ms >>> dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] >>> 5 17 ms 10 ms 12 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com >>> [96.34.30.17] >>> 6 11 ms 9 ms 15 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com >>> [96.34.24.56] >>> 7 15 ms 18 ms 18 ms dtr02fdulwi-bue-3.fdul.wi.charter.com >>> [96.34.30.19] >>> 8 16 ms 14 ms 11 ms dtr01fdulwi-bue-1.fdul.wi.charter.com >>> [96.34.19.144] >>> 9 20 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com >>> [96.34.20.8] >>> 10 22 ms 22 ms 18 ms crr02euclwi-bue-6.eucl.wi.charter.com >>> [96.34.22.240] >>> 11 18 ms 22 ms 22 ms bbr02euclwi-bue-4.eucl.wi.charter.com >>> [96.34.2.6] >>> 12 35 ms 30 ms 31 ms bbr01chcgil-bue-1.chcg.il.charter.com >>> [96.34.0.9] >>> 13 27 ms 27 ms 27 ms prr01chcgil-bue-2.chcg.il.charter.com >>> [96.34.3.9] >>> 14 27 ms 27 ms 27 ms >>> 96-34-152-30.static.unas.mo.charter.com [96.34.152.30] >>> 15 29 ms 32 ms 27 ms 209.85.244.1 >>> 16 27 ms 27 ms 28 ms 209.85.254.238 >>> 17 54 ms 40 ms 40 ms 209.85.248.214 >>> 18 38 ms 40 ms 38 ms 216.239.43.217 >>> 19 * * * Request timed out. >>> 20 44 ms 40 ms 40 ms google-public-dns-a.google.com [8.8.8.8] >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6118 bytes Desc: not available URL: From gdendy at equinix.com Tue Jun 17 04:31:58 2014 From: gdendy at equinix.com (Greg Dendy) Date: Mon, 16 Jun 2014 21:31:58 -0700 Subject: NANOG 62 - Baltimore - Call For Presentations is Open! Message-ID: <180F02C2-7158-4843-A43D-4CF7AA941A20@equinix.com> NANOG Community- Thanks for helping to make NANOG 61 in Bellevue such a smashing success as the most attended meeting ever, on the 20th anniversary of the first meeting! NANOG will hold its 62nd meeting in Baltimore, MD on October 6-8, 2014, hosted by EdgeConneX. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 62 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet, . Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. Key dates to track if you wish to submit a presentation: * Presentation Abstracts and Draft Slides Due: August 4, 2014 * Topic List Posted: August 18, 2014 * Slides Due: September 1, 2014 * Agenda Published: September 15, 2014 NANOG 62 submissions are welcome on the Program Committee Site or email me if you have questions. Looking forward to seeing everyone in Baltimore! Thanks, Greg Dendy Chair, Program Committee North American Network Operator Group (NANOG) From cb.list6 at gmail.com Tue Jun 17 14:06:49 2014 From: cb.list6 at gmail.com (Ca By) Date: Tue, 17 Jun 2014 07:06:49 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: Message-ID: I have not tried it out, this makes it look like DO beat Azure to market on ipv6 http://venturebeat.com/2014/06/17/digitalocean-ipv6/ Speaking of Azure and ip adresses http://www.pcworld.com/article/2363580/need-to-move-to-ipv6-highlighted-as-microsoft-runs-out-of-us-address-space.html From rwebb at ropeguru.com Tue Jun 17 14:35:17 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 17 Jun 2014 10:35:17 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: Message-ID: Not impressed at all. DO customers have been asking for IPv6 for around two years now with responses of, "It's coming". Now they are getting press because they are rollingit our ONLY in their Singapore market which is its newest data center. Those of us here in the US are still getting the same ole, "It's coming" responses. There are other VPS's out there that are already givinf IPv6 addresses. I have two with www.peakservers.com where I get one IPv4 and 8 IPv6 addresses. On Tue, 17 Jun 2014 07:06:49 -0700 Ca By wrote: > I have not tried it out, this makes it look like DO beat Azure to >market > on ipv6 > > http://venturebeat.com/2014/06/17/digitalocean-ipv6/ > > Speaking of Azure and ip adresses > > http://www.pcworld.com/article/2363580/need-to-move-to-ipv6-highlighted-as-microsoft-runs-out-of-us-address-space.html From jared at puck.nether.net Tue Jun 17 15:17:41 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Jun 2014 11:17:41 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: Message-ID: <882EF713-A8A7-483A-8446-9576A29AADA2@puck.nether.net> I think that's a bit harsh. I congratulate them for getting the first step done in the process of making it available for all customers. Jared Mauch > On Jun 17, 2014, at 10:35 AM, "rwebb at ropeguru.com" wrote: > > Not impressed at all. DO customers have been asking for IPv6 for around two years now with responses of, "It's coming". Now they are getting press because they are rollingit our ONLY in their Singapore market which is its newest data center. Those of us here in the US are still getting the same ole, "It's coming" responses. > > There are other VPS's out there that are already givinf IPv6 addresses. I have two with www.peakservers.com where I get one IPv4 and 8 IPv6 addresses. > > On Tue, 17 Jun 2014 07:06:49 -0700 > Ca By wrote: >> I have not tried it out, this makes it look like DO beat Azure to market >> on ipv6 >> http://venturebeat.com/2014/06/17/digitalocean-ipv6/ >> Speaking of Azure and ip adresses >> http://www.pcworld.com/article/2363580/need-to-move-to-ipv6-highlighted-as-microsoft-runs-out-of-us-address-space.html From dhubbard at dino.hostasaurus.com Tue Jun 17 15:20:43 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 17 Jun 2014 11:20:43 -0400 Subject: Credit to Digital Ocean for ipv6 offering References: Message-ID: Yep, same with Linode, they've had IPv6 live in their locations for a couple years now. I spun up an ipv6-enabled VM about 18 months ago and have had no issues since. David -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of rwebb at ropeguru.com Sent: Tuesday, June 17, 2014 10:35 AM To: Ca By; nanog at nanog.org Subject: Re: Credit to Digital Ocean for ipv6 offering Not impressed at all. DO customers have been asking for IPv6 for around two years now with responses of, "It's coming". Now they are getting press because they are rollingit our ONLY in their Singapore market which is its newest data center. Those of us here in the US are still getting the same ole, "It's coming" responses. There are other VPS's out there that are already givinf IPv6 addresses. I have two with www.peakservers.com where I get one IPv4 and 8 IPv6 addresses. On Tue, 17 Jun 2014 07:06:49 -0700 Ca By wrote: > I have not tried it out, this makes it look like DO beat Azure to >market on ipv6 > > http://venturebeat.com/2014/06/17/digitalocean-ipv6/ > > Speaking of Azure and ip adresses > > http://www.pcworld.com/article/2363580/need-to-move-to-ipv6-highlighte > d-as-microsoft-runs-out-of-us-address-space.html From rwebb at ropeguru.com Tue Jun 17 15:26:16 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 17 Jun 2014 11:26:16 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <882EF713-A8A7-483A-8446-9576A29AADA2@puck.nether.net> References: <882EF713-A8A7-483A-8446-9576A29AADA2@puck.nether.net> Message-ID: I don't think it is harsh when they lead their customers on with no progress. https://www.digitalocean.com/community/questions/is-ipv6-available digitalocean.uservoice.com/forums/136585-digital-ocean/suggestions/2639897-ipv6-addresses Take note of the original post dates and the responses. Original questions were in 2012 with responses of Q4 2012 to Q1 2013. Robert On Tue, 17 Jun 2014 11:17:41 -0400 Jared Mauch wrote: > I think that's a bit harsh. I congratulate them for getting the >first step done in the process of making it available for all >customers. > > Jared Mauch > >> On Jun 17, 2014, at 10:35 AM, "rwebb at ropeguru.com" >> wrote: >> >> Not impressed at all. DO customers have been asking for IPv6 for >>around two years now with responses of, "It's coming". Now they are >>getting press because they are rollingit our ONLY in their Singapore >>market which is its newest data center. Those of us here in the US >>are still getting the same ole, "It's coming" responses. >> >> There are other VPS's out there that are already givinf IPv6 >>addresses. I have two with www.peakservers.com where I get one IPv4 >>and 8 IPv6 addresses. >> >> On Tue, 17 Jun 2014 07:06:49 -0700 >> Ca By wrote: >>> I have not tried it out, this makes it look like DO beat Azure to >>>market >>> on ipv6 >>> http://venturebeat.com/2014/06/17/digitalocean-ipv6/ >>> Speaking of Azure and ip adresses >>> http://www.pcworld.com/article/2363580/need-to-move-to-ipv6-highlighted-as-microsoft-runs-out-of-us-address-space.html From seitz at bsd-unix.net Tue Jun 17 16:30:50 2014 From: seitz at bsd-unix.net (Bryan Seitz) Date: Tue, 17 Jun 2014 12:30:50 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: Message-ID: <20140617163050.GB67158@bsd-unix.net> On Tue, Jun 17, 2014 at 10:35:17AM -0400, rwebb at ropeguru.com wrote: > Not impressed at all. DO customers have been asking for IPv6 for > around two years now with responses of, "It's coming". Now they are > getting press because they are rollingit our ONLY in their Singapore > market which is its newest data center. Those of us here in the US are > still getting the same ole, "It's coming" responses. > > There are other VPS's out there that are already givinf IPv6 > addresses. I have two with www.peakservers.com where I get one IPv4 > and 8 IPv6 addresses. > > On Tue, 17 Jun 2014 07:06:49 -0700 > Ca By wrote: > > I have not tried it out, this makes it look like DO beat Azure to > >market > > on ipv6 > > > > http://venturebeat.com/2014/06/17/digitalocean-ipv6/ > > > > Speaking of Azure and ip adresses > > > > http://www.pcworld.com/article/2363580/need-to-move-to-ipv6-highlighted-as-microsoft-runs-out-of-us-address-space.html Agreed as well. It isn't hard to dual stack, maybe they bought some junk gear that has issues in the older datacenters? :) Howevveeerrr.... they are also the cheapest thing going (other than Vultr.com) so you also get what you pay for :) -- Bryan G. Seitz From jared at puck.nether.net Tue Jun 17 16:31:08 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Jun 2014 12:31:08 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <882EF713-A8A7-483A-8446-9576A29AADA2@puck.nether.net> Message-ID: <42474EAD-E76F-41F1-81B5-DC2598BCD983@puck.nether.net> On Jun 17, 2014, at 11:26 AM, rwebb at ropeguru.com wrote: > I don't think it is harsh when they lead their customers on with no progress. > > https://www.digitalocean.com/community/questions/is-ipv6-available > > digitalocean.uservoice.com/forums/136585-digital-ocean/suggestions/2639897-ipv6-addresses > > Take note of the original post dates and the responses. Original questions were in 2012 with responses of Q4 2012 to Q1 2013. Sure, I've seen the same thing with OpenSRS and others with things like IPv6 glue and DS records for DNSSEC, but when they make it public/supportable, I still congratulate the engineers who made it happen. Could they have done it harder/better/faster/stronger [1]? Sure. We've been doing IPv6 for over a decade as a commercial service. I still am happy when networks get IPv6 enabled. There's a long road, and Digital Ocean is just one party that needs to make things happen. Wayport/attwifi, TWCable, and even Comcast who is a leader here in the USA could do more but it's all gated on internal criteria that I'm not aware of. - Jared - Jared [1] - http://www.najle.com/idaft/idaft/ From jared at puck.nether.net Tue Jun 17 16:37:44 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Jun 2014 12:37:44 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <20140617163050.GB67158@bsd-unix.net> References: <20140617163050.GB67158@bsd-unix.net> Message-ID: <355AA19A-CE54-4874-9A79-CCBCA9A9D055@puck.nether.net> On Jun 17, 2014, at 12:30 PM, Bryan Seitz wrote: > Agreed as well. It isn't hard to dual stack, maybe they bought some junk gear that has issues in the older datacenters? :) We all have junk kicking around that we wish we didn't have. > Howevveeerrr.... they are also the cheapest thing going (other than Vultr.com) so you also get what you pay for :) Even Facebook who has talked publicly about their IPv6 deployments and issues they have encountered has faced major hurdles in operation of networking and host behaviors. (start on page 11) http://www.internetsociety.org/deploy360/wp-content/uploads/2014/04/WorldIPv6Congress-IPv6_LH-v2.pdf - Jared From drc at virtualized.org Tue Jun 17 17:08:30 2014 From: drc at virtualized.org (David Conrad) Date: Tue, 17 Jun 2014 10:08:30 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: Message-ID: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> On Jun 17, 2014, at 7:35 AM, rwebb at ropeguru.com wrote: > There are other VPS's out there that are already givinf IPv6 addresses. Yep, I use rootbsd.net and arpnetworks.com and have been happy with both. > I have two with www.peakservers.com where I get one IPv4 and 8 IPv6 addresses. Wait. What? Do you mean 8 /64s? Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rwebb at ropeguru.com Tue Jun 17 17:14:04 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 17 Jun 2014 13:14:04 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> Message-ID: >> There are other VPS's out there that are already givinf IPv6 >>addresses. > > Yep, I use rootbsd.net and arpnetworks.com and have been happy with >both. > >> I have two with www.peakservers.com where I get one IPv4 and 8 IPv6 >>addresses. > > Wait. What? Do you mean 8 /64s? No, 8 individual IPv6 addresses. There have also been reports from some DO users of HE tunnels being blocked. Not sure what the status of that is. From Valdis.Kletnieks at vt.edu Tue Jun 17 17:25:37 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 17 Jun 2014 13:25:37 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: Your message of "Tue, 17 Jun 2014 13:14:04 -0400." References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> Message-ID: <5166.1403025937@turing-police.cc.vt.edu> On Tue, 17 Jun 2014 13:14:04 -0400, "rwebb at ropeguru.com" said: > No, 8 individual IPv6 addresses. Wow. Harsh. I burn more than that just in my living room. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rwebb at ropeguru.com Tue Jun 17 17:29:09 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 17 Jun 2014 13:29:09 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <5166.1403025937@turing-police.cc.vt.edu> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> Message-ID: On Tue, 17 Jun 2014 13:25:37 -0400 Valdis.Kletnieks at vt.edu wrote: > On Tue, 17 Jun 2014 13:14:04 -0400, "rwebb at ropeguru.com" said: > >> No, 8 individual IPv6 addresses. > > Wow. Harsh. I burn more than that just in my living room. I don't think that is too harsh as all 8 are assigned to a single server. So if I have three VPS's, I have 24 total addresses. From bryan at digitalocean.com Tue Jun 17 17:52:00 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Tue, 17 Jun 2014 13:52:00 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> Message-ID: > There have also been reports from some DO users of HE tunnels being blocked. Not sure what the status of that is. It was all rumors. All the tunnel providers have been never blocked us or anyone who wanted to previously add a tunnel to our virtual servers. HE has been generously peering with us for both ipv6 transport and their 6to4 nats for awhile. There was a misunderstanding with SiXXS when we first started to announce v6 addresses, once cleared up it wasn't a customer offering things went back to normal. And it wasn't blocked, they just didn't allow people to get tunnels for our ipv4 addresses and 1 or 2 got caught it having their tunnels removed when they went to switch the ip they were connected to. If you know of other examples, it's not being reported to us and please let us know so we can look into it. > Those of us here in the US are still getting the same ole, "It's coming" responses. There will be something in the US and EU with v6 in a reasonable amount of time (although I'm sure not fast enough for some people). we're not listing a date because we got stuck behind some scale and non-technical things that delayed it in the past. A more in depth answer is we're migrating our backend code to a newer revision and it was faster to not try to support v6 on both revisions and concentrate on the migration and v6 (and other coming features) on the newer version. It's just faster to get it rolled out everywhere going this direction. Bryan Socha Network Engineer DigitalOcean From alan at clegg.com Tue Jun 17 18:25:17 2014 From: alan at clegg.com (Alan Clegg) Date: Tue, 17 Jun 2014 14:25:17 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> Message-ID: <53A0880D.7070603@clegg.com> On 6/17/14, 1:29 PM, rwebb at ropeguru.com wrote: > On Tue, 17 Jun 2014 13:25:37 -0400 > Valdis.Kletnieks at vt.edu wrote: >> On Tue, 17 Jun 2014 13:14:04 -0400, "rwebb at ropeguru.com" said: >> >>> No, 8 individual IPv6 addresses. >> >> Wow. Harsh. I burn more than that just in my living room. > > I don't think that is too harsh as all 8 are assigned to a single > server. So if I have three VPS's, I have 24 total addresses. This is a joke, right? AlanC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: OpenPGP digital signature URL: From mpetach at netflight.com Tue Jun 17 19:19:51 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 17 Jun 2014 12:19:51 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <53A0880D.7070603@clegg.com> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <53A0880D.7070603@clegg.com> Message-ID: On Tue, Jun 17, 2014 at 11:25 AM, Alan Clegg wrote: > On 6/17/14, 1:29 PM, rwebb at ropeguru.com wrote: > > On Tue, 17 Jun 2014 13:25:37 -0400 > > Valdis.Kletnieks at vt.edu wrote: > >> On Tue, 17 Jun 2014 13:14:04 -0400, "rwebb at ropeguru.com" said: > >> > >>> No, 8 individual IPv6 addresses. > >> > >> Wow. Harsh. I burn more than that just in my living room. > > > > I don't think that is too harsh as all 8 are assigned to a single > > server. So if I have three VPS's, I have 24 total addresses. > > This is a joke, right? > > AlanC > > Addresses are a scarce resource; one shouldn't waste them needlessly. I'm sure if more addresses are needed, customers can purchase additional IPs on a monthly basis. Matt From ml at kenweb.org Tue Jun 17 19:38:30 2014 From: ml at kenweb.org (ML) Date: Tue, 17 Jun 2014 15:38:30 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <53A0880D.7070603@clegg.com> Message-ID: <53A09936.9030004@kenweb.org> On 6/17/2014 3:19 PM, Matthew Petach wrote: > On Tue, Jun 17, 2014 at 11:25 AM, Alan Clegg wrote: > >> On 6/17/14, 1:29 PM, rwebb at ropeguru.com wrote: >>> On Tue, 17 Jun 2014 13:25:37 -0400 >>> Valdis.Kletnieks at vt.edu wrote: >>>> On Tue, 17 Jun 2014 13:14:04 -0400, "rwebb at ropeguru.com" said: >>>> >>>>> No, 8 individual IPv6 addresses. >>>> Wow. Harsh. I burn more than that just in my living room. >>> I don't think that is too harsh as all 8 are assigned to a single >>> server. So if I have three VPS's, I have 24 total addresses. >> This is a joke, right? >> >> AlanC >> >> > Addresses are a scarce resource; one shouldn't > waste them needlessly. > > I'm sure if more addresses are needed, customers > can purchase additional IPs on a monthly basis. > > Matt It's offered at a low low price of $.00000000000001 per IPv6 address[1]. [1] /64 minimum of course. From drc at virtualized.org Tue Jun 17 19:46:41 2014 From: drc at virtualized.org (David Conrad) Date: Tue, 17 Jun 2014 12:46:41 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> Message-ID: <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> Robert, On Jun 17, 2014, at 10:29 AM, rwebb at ropeguru.com wrote: > On Tue, 17 Jun 2014 13:25:37 -0400 > Valdis.Kletnieks at vt.edu wrote: >> On Tue, 17 Jun 2014 13:14:04 -0400, "rwebb at ropeguru.com" said: >>> No, 8 individual IPv6 addresses. >> Wow. Harsh. I burn more than that just in my living room. > I don't think that is too harsh as all 8 are assigned to a single server. So if I have three VPS's, I have 24 total addresses. In the case of my 3 VPS's, I've received /64s from both RootBSD.net and Arp Networks or 55,340,232,221,128,654,848 addresses. I'm not sure I see a rationale for assigning 8 addresses. That is, I could understand assigning a single address or a /64 but 8 addresses? I'd think that'd be more complicated/error prone than either the /128 or /64 options. A bit odd. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Grzegorz at Janoszka.pl Tue Jun 17 19:55:50 2014 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Tue, 17 Jun 2014 21:55:50 +0200 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> Message-ID: <53A09D46.7000507@Janoszka.pl> On 2014-06-17 21:46, David Conrad wrote: >>>> No, 8 individual IPv6 addresses. >>> Wow. Harsh. I burn more than that just in my living room. >> I don't think that is too harsh as all 8 are assigned to a single server. So if I have three VPS's, I have 24 total addresses. > In the case of my 3 VPS's, I've received /64s from both RootBSD.net and Arp Networks or 55,340,232,221,128,654,848 addresses. I'm not sure I see a rationale for assigning 8 addresses. That is, I could understand assigning a single address or a /64 but 8 addresses? I'd think that'd be more complicated/error prone than either the /128 or /64 options. A bit odd. There are still applications that break with subnet smaller than /64, so all VPS providers probably have to use /64 addressing. /64 for one customer seems to be too much, on the other side 8 IP's can be not enough in some cases. I think 65536 out of shared /64 for one server can be enough. You can easily automate provisioning and reverse DNS assuming you assign /112 for each server. If you block SLAAC and provide connectivity to only the static IP's, your abuse folks should appreciate it (yes, I know you can spoof v6). -- Grzegorz Janoszka From drc at virtualized.org Tue Jun 17 20:13:19 2014 From: drc at virtualized.org (David Conrad) Date: Tue, 17 Jun 2014 13:13:19 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <53A09D46.7000507@Janoszka.pl> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> Message-ID: On Jun 17, 2014, at 12:55 PM, Grzegorz Janoszka wrote: > There are still applications that break with subnet smaller than /64, so all VPS providers probably have to use /64 addressing. Wouldn't that argue for /64s? > /64 for one customer seems to be too much, In what way? What are you trying to protect against? It can't be address exhaustion (there are 2,305,843,009,213,693,952 possible /64s in the currently used format specifier. If there are 1,000,000,000 customer assignments every day of the year, the current format specifier will last over 6 million years). Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jra at baylink.com Tue Jun 17 20:20:10 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 17 Jun 2014 16:20:10 -0400 (EDT) Subject: Ars Technica on IPv4 exhaustion Message-ID: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> Here's what the general public is hearing: http://arstechnica.com/information-technology/2014/06/with-the-americas-running-out-of-ipv4-its-official-the-internet-is-full/ And yes, I checked the dateline this time. :-) 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 j at arpa.com Tue Jun 17 20:22:07 2014 From: j at arpa.com (jamie rishaw) Date: Tue, 17 Jun 2014 15:22:07 -0500 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> Message-ID: +1+1+1 re living room On Jun 17, 2014 12:32 PM, "rwebb at ropeguru.com" wrote: > On Tue, 17 Jun 2014 13:25:37 -0400 > Valdis.Kletnieks at vt.edu wrote: > >> On Tue, 17 Jun 2014 13:14:04 -0400, "rwebb at ropeguru.com" said: >> >> No, 8 individual IPv6 addresses. >>> >> >> Wow. Harsh. I burn more than that just in my living room. >> > > I don't think that is too harsh as all 8 are assigned to a single server. > So if I have three VPS's, I have 24 total addresses. > From Grzegorz at Janoszka.pl Tue Jun 17 20:36:49 2014 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Tue, 17 Jun 2014 22:36:49 +0200 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> Message-ID: <53A0A6E1.9050906@Janoszka.pl> On 2014-06-17 22:13, David Conrad wrote: > On Jun 17, 2014, at 12:55 PM, Grzegorz Janoszka wrote: >> There are still applications that break with subnet smaller than /64, so all VPS providers probably have to use /64 addressing. > > Wouldn't that argue for /64s? /64 netmask, but not /64 for a customer. There are application which break if provided with /80 or /120, but I am not aware of an application requesting /64 for itself. >> /64 for one customer seems to be too much, > > In what way? What are you trying to protect against? It can't be address exhaustion (there are 2,305,843,009,213,693,952 possible /64s in the currently used format specifier. If there are 1,000,000,000 customer assignments every day of the year, the current format specifier will last over 6 million years). Too much hassle, like too big config of your router. If you have 1000 customers in a subnet, you would have to have 1000 separate gateway IP's on your router interface plus 1000 local /64 routes. -- Grzegorz Janoszka From jeroen at massar.ch Tue Jun 17 21:13:12 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Tue, 17 Jun 2014 23:13:12 +0200 Subject: Applications that break when not using /64 In-Reply-To: <53A0A6E1.9050906@Janoszka.pl> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> Message-ID: <53A0AF68.4050909@massar.ch> On 2014-06-17 22:36, Grzegorz Janoszka wrote: > On 2014-06-17 22:13, David Conrad wrote: >> On Jun 17, 2014, at 12:55 PM, Grzegorz Janoszka >> wrote: >>> There are still applications that break with subnet smaller than /64, >>> so all VPS providers probably have to use /64 addressing. >> >> Wouldn't that argue for /64s? > > /64 netmask, but not /64 for a customer. There are application which > break if provided with /80 or /120, but I am not aware of an application > requesting /64 for itself. Except for SLAAC that requires a /64 due to it using EUI-48 to make up the address, which "applications" are these, as those applications are broken by design. An application (unless it is a protocol like SLAAC or something else similarly low-level) does not need to know about prefix sizes nor routing tables. Thus, can you please identify these applications so that we can hammer on the developers of those applications and fix that problem? >>> /64 for one customer seems to be too much, >> >> In what way? What are you trying to protect against? It can't be >> address exhaustion (there are 2,305,843,009,213,693,952 possible /64s >> in the currently used format specifier. If there are 1,000,000,000 >> customer assignments every day of the year, the current format >> specifier will last over 6 million years). > > Too much hassle, like too big config of your router. If you have 1000 > customers in a subnet, you would have to have 1000 separate gateway IP's > on your router interface plus 1000 local /64 routes. Wow, you really stuff all the customers in the same VLAN and thus the same routed IP.... lots of fun those other customers will have with that, especially as a lot of folks simply do not know that IPv6 is already there and has been enabled in their distribution, applications and kernels for many many years... As for "why" VPSs are doing the limited number of IPs per VM, simply: https://www.youtube.com/watch?v=YcXMhwF4EtQ And if you want more, you can buy more... hence if you want more, vote with your money and take your business elsewhere... Greets, Jeroen From owen at delong.com Tue Jun 17 21:09:21 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 17 Jun 2014 14:09:21 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <53A09D46.7000507@Janoszka.pl> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> Message-ID: <12D5B136-F7B7-42E6-B478-38FC96C7477E@delong.com> On Jun 17, 2014, at 12:55 , Grzegorz Janoszka wrote: > On 2014-06-17 21:46, David Conrad wrote: >>>>> No, 8 individual IPv6 addresses. >>>> Wow. Harsh. I burn more than that just in my living room. >>> I don't think that is too harsh as all 8 are assigned to a single server. So if I have three VPS's, I have 24 total addresses. >> In the case of my 3 VPS's, I've received /64s from both RootBSD.net and Arp Networks or 55,340,232,221,128,654,848 addresses. I'm not sure I see a rationale for assigning 8 addresses. That is, I could understand assigning a single address or a /64 but 8 addresses? I'd think that'd be more complicated/error prone than either the /128 or /64 options. A bit odd. > > There are still applications that break with subnet smaller than /64, so all VPS providers probably have to use /64 addressing. > > /64 for one customer seems to be too much, on the other side 8 IP's can be not enough in some cases. I think 65536 out of shared /64 for one server can be enough. You can easily automate provisioning and reverse DNS assuming you assign /112 for each server. > If you block SLAAC and provide connectivity to only the static IP's, your abuse folks should appreciate it (yes, I know you can spoof v6). There's no problem with assigning at least a /64 per customer even for VPSs. There are plenty of /64s to go around. Please stop trying to push the IPv4 scarcity mentality into IPv6. Subnet where it makes sense to subnet and assign a /64 to each subnet, whether it has 2 hosts or 2,000 hosts does not matter. In reality, the difference in waste between a /64 with 2,000 hosts on it and a subnet with 2 hosts on it is less than 0.00001%. Owen From owen at delong.com Tue Jun 17 21:13:56 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 17 Jun 2014 14:13:56 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <53A0A6E1.9050906@Janoszka.pl> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> Message-ID: <09E0A884-4DEC-4A23-8130-7E443FC3F38C@delong.com> On Jun 17, 2014, at 13:36 , Grzegorz Janoszka wrote: > On 2014-06-17 22:13, David Conrad wrote: >> On Jun 17, 2014, at 12:55 PM, Grzegorz Janoszka wrote: >>> There are still applications that break with subnet smaller than /64, so all VPS providers probably have to use /64 addressing. >> >> Wouldn't that argue for /64s? > > /64 netmask, but not /64 for a customer. There are application which break if provided with /80 or /120, but I am not aware of an application requesting /64 for itself. > >>> /64 for one customer seems to be too much, >> >> In what way? What are you trying to protect against? It can't be address exhaustion (there are 2,305,843,009,213,693,952 possible /64s in the currently used format specifier. If there are 1,000,000,000 customer assignments every day of the year, the current format specifier will last over 6 million years). > > Too much hassle, like too big config of your router. If you have 1000 customers in a subnet, you would have to have 1000 separate gateway IP's on your router interface plus 1000 local /64 routes. > > -- > Grzegorz Janoszka This is actually pretty easy. If I were structuring a VPS environment, then I'd put a /56 or possibly a /52, depending on the number of virtuals expected on each physical server. Then, for each customer who got a VPS on that server, I'd create a bridge interface with a /64 assigned to that customer. Each VPS on that physical server that belonged to the same customer would get put on the same /64. The router would route the /56 or /52 to the physical server. The hypervisor would have connected routes for the subordinate /64s and provide RAs to give default to the various VPSs. Very low maintenance, pretty straight forward and simple. Why would you ever put multiple customers in the same subnet in IPv6? That's just asking for trouble if you ask me. Owen From cma at cmadams.net Tue Jun 17 21:26:47 2014 From: cma at cmadams.net (Chris Adams) Date: Tue, 17 Jun 2014 16:26:47 -0500 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <09E0A884-4DEC-4A23-8130-7E443FC3F38C@delong.com> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> <09E0A884-4DEC-4A23-8130-7E443FC3F38C@delong.com> Message-ID: <20140617212647.GA24963@cmadams.net> Once upon a time, Owen DeLong said: > The router would route the /56 or /52 to the physical server. The hypervisor would have connected routes for the subordinate /64s and provide RAs to give default to the various VPSs. Doing anything that ties networks to physical servers is a poor design for a VPS environment. That would mean that any VM migration requires customers to renumber (so no live migration allowed at all). -- Chris Adams From Lee at asgard.org Tue Jun 17 21:41:23 2014 From: Lee at asgard.org (Lee Howard) Date: Tue, 17 Jun 2014 17:41:23 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> Message-ID: On 6/17/14 4:20 PM, "Jay Ashworth" wrote: >Here's what the general public is hearing: But only while they still have IPv4 addresses: ~$ dig AAAA arstechnica.com +short ~$ > > >http://arstechnica.com/information-technology/2014/06/with-the-americas-ru >nning-out-of-ipv4-its-official-the-internet-is-full/ Can't tech news sites *please* run dual stack while they're spouting end-of-IPv4 stories? Lee From jared at puck.nether.net Tue Jun 17 21:48:13 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Jun 2014 17:48:13 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> Message-ID: <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> On Jun 17, 2014, at 5:41 PM, Lee Howard wrote: > > > On 6/17/14 4:20 PM, "Jay Ashworth" wrote: > >> Here's what the general public is hearing: > > But only while they still have IPv4 addresses: > ~$ dig AAAA arstechnica.com +short > ~$ > > > >> >> >> http://arstechnica.com/information-technology/2014/06/with-the-americas-ru >> nning-out-of-ipv4-its-official-the-internet-is-full/ > > > Can't tech news sites *please* run dual stack while they're spouting > end-of-IPv4 stories? I would love to see a few more properties do IPv6 by default, such as ARS, Twitter and a few others. After posting some links and being a log stalker last night the first 3 hits from non-bots were from users on IPv6 enabled networks. It does ring a bit hollow that these sites haven't gotten there when others (Google, Facebook) have already shown you can publish AAAA records with no adverse public impact. Making IPv6 available by default for users would be an excellent step. People like AT&T who control the 'attwifi' ssid could do NAT66 at their sites and provide similar service to the masses. With chains like Hilton, McDonalds, etc.. all having this available, it would push IPv6 very far almost immediately with no adverse impact compared to users IPv4 experience. - Jared From Valdis.Kletnieks at vt.edu Tue Jun 17 21:53:04 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 17 Jun 2014 17:53:04 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: Your message of "Tue, 17 Jun 2014 16:26:47 -0500." <20140617212647.GA24963@cmadams.net> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> <09E0A884-4DEC-4A23-8130-7E443FC3F38C@delong.com> <20140617212647.GA24963@cmadams.net> Message-ID: <19301.1403041984@turing-police.cc.vt.edu> On Tue, 17 Jun 2014 16:26:47 -0500, Chris Adams said: > Doing anything that ties networks to physical servers is a poor design > for a VPS environment. That would mean that any VM migration requires > customers to renumber (so no live migration allowed at all). Why? Two hypervisors tossing a subnet route to a VM back and forth is *exactly* the same problem as two routers using VRRP to toss a subnet route back and forth. And somehow, we all manage to do that *all the time* without machines on the subnet having to renumber. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mpetach at netflight.com Tue Jun 17 22:02:32 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 17 Jun 2014 15:02:32 -0700 Subject: Applications that break when not using /64 In-Reply-To: <53A0AF68.4050909@massar.ch> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> <53A0AF68.4050909@massar.ch> Message-ID: On Tue, Jun 17, 2014 at 2:13 PM, Jeroen Massar wrote: > On 2014-06-17 22:36, Grzegorz Janoszka wrote: > > On 2014-06-17 22:13, David Conrad wrote: > >> On Jun 17, 2014, at 12:55 PM, Grzegorz Janoszka > >> wrote: > >>> There are still applications that break with subnet smaller than /64, > >>> so all VPS providers probably have to use /64 addressing. > >> > >> Wouldn't that argue for /64s? > > > > /64 netmask, but not /64 for a customer. There are application which > > break if provided with /80 or /120, but I am not aware of an application > > requesting /64 for itself. > > Except for SLAAC that requires a /64 due to it using EUI-48 to make up > the address, which "applications" are these, as those applications are > broken by design. > > An application (unless it is a protocol like SLAAC or something else > similarly low-level) does not need to know about prefix sizes nor > routing tables. > > Thus, can you please identify these applications so that we can hammer > on the developers of those applications and fix that problem? > I tried to configure my FreeBSD box at home to use a /120 subnet mask. It consistently crashed with a kernel panic. I eventually gave up and just configured it with a /64. Not really an application per se, but since the OS died, I couldn't actually tell if the applications were happy or not. :( Matt From jeroen at massar.ch Tue Jun 17 22:03:22 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 18 Jun 2014 00:03:22 +0200 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> Message-ID: <53A0BB2A.9040200@massar.ch> On 2014-06-17 23:48, Jared Mauch wrote: > > On Jun 17, 2014, at 5:41 PM, Lee Howard wrote: [..] >> Can't tech news sites *please* run dual stack while they're >> spouting end-of-IPv4 stories? > > > > I would love to see a few more properties do IPv6 by default, such as > ARS, Twitter and a few others. After posting some links and being a > log stalker last night the first 3 hits from non-bots were from users > on IPv6 enabled networks. [..] I tried to give Slashdot the hint some 11+ years ago... http://news.slashdot.org/story/03/02/12/2036205/slashdot-over-ipv6 They still didn't get that hint... then again slashdot is way passed its prime. But even sites like Reddit don't have AAAAs. I guess now that it is 2014 and the address space is really as good as gone some sites will finally start buying IPv6 enabled equipment and start learning what the problems might be in their codebase, router equipment and most expensively: staff training. Oh well, they can't claim they where not told anything... Greets, Jeroen From jeroen at massar.ch Tue Jun 17 22:04:44 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 18 Jun 2014 00:04:44 +0200 Subject: Applications that break when not using /64 In-Reply-To: References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> <53A0AF68.4050909@massar.ch> Message-ID: <53A0BB7C.3050900@massar.ch> On 2014-06-18 00:02, Matthew Petach wrote: [..] > I tried to configure my FreeBSD box at home to > use a /120 subnet mask. It consistently crashed > with a kernel panic. Where is the bug report? I am fairly confident that that really should not be an issue, with the BSD stack being one of the oldest IPv6 stacks around (thank you itojun and the rest of KAME!) Greets, Jeroen From andrew.fried at gmail.com Tue Jun 17 22:12:06 2014 From: andrew.fried at gmail.com (Andrew Fried) Date: Tue, 17 Jun 2014 18:12:06 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> Message-ID: <53A0BD36.5060703@gmail.com> IPv6 will never become the defacto standard until the vast majority of users have access to IPv6 connectivity. Everything I have at the colo is dual stacked, but I can't reach my own systems via IPv6 because my business class Verizon Fios connection is IPv4 *only*. Yes, Comcast is in the process of rolling out IPv6, but my Comcast circuit in Washington DC is IPv4 only. And I'd suspect that everyone with Time Warner, AT&T, Cox, etc are all in the same boat. Whether the reason for the lack of IPv6 deployment is laziness or an intentional omission on the part of large ISPs to protect their income from leasing IPv4 addresses doesn't matter to the vast majority of the end users; they simply can't access IPv6 via IPv4 only networks, without using some kludgy, complicated tunneling protocols. Andy -- Andrew Fried andrew.fried at gmail.com On 6/17/14, 5:48 PM, Jared Mauch wrote: > > On Jun 17, 2014, at 5:41 PM, Lee Howard wrote: > >> >> >> On 6/17/14 4:20 PM, "Jay Ashworth" wrote: >> >>> Here's what the general public is hearing: >> >> But only while they still have IPv4 addresses: >> ~$ dig AAAA arstechnica.com +short >> ~$ >> >> >> >>> >>> >>> http://arstechnica.com/information-technology/2014/06/with-the-americas-ru >>> nning-out-of-ipv4-its-official-the-internet-is-full/ >> >> >> Can't tech news sites *please* run dual stack while they're spouting >> end-of-IPv4 stories? > > > > I would love to see a few more properties do IPv6 by default, such as ARS, Twitter and a few others. After posting some links and being a log stalker last night the first 3 hits from non-bots were from users on IPv6 enabled networks. > > It does ring a bit hollow that these sites haven't gotten there when others (Google, Facebook) have already shown you can publish AAAA records with no adverse public impact. Making IPv6 available by default for users would be an excellent step. People like AT&T who control the 'attwifi' ssid could do NAT66 at their sites and provide similar service to the masses. With chains like Hilton, McDonalds, etc.. all having this available, it would push IPv6 very far almost immediately with no adverse impact compared to users IPv4 experience. > > - Jared > From johnl at iecc.com Tue Jun 17 22:39:32 2014 From: johnl at iecc.com (John Levine) Date: 17 Jun 2014 22:39:32 -0000 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: Message-ID: <20140617223932.51558.qmail@joyce.lan> In article you write: >+1+1+1 re living room My cable company assigns my home network a /50. I can figure out what to do with two of the /64s (wired and wireless networks), but I'm currently stumped on the other 16,382 of them. R's, John >On Jun 17, 2014 12:32 PM, "rwebb at ropeguru.com" wrote: > >> On Tue, 17 Jun 2014 13:25:37 -0400 >> Valdis.Kletnieks at vt.edu wrote: >> >>> On Tue, 17 Jun 2014 13:14:04 -0400, "rwebb at ropeguru.com" said: >>> >>> No, 8 individual IPv6 addresses. >>>> >>> >>> Wow. Harsh. I burn more than that just in my living room. >>> >> >> I don't think that is too harsh as all 8 are assigned to a single server. >> So if I have three VPS's, I have 24 total addresses. From bmanning at isi.edu Tue Jun 17 22:45:11 2014 From: bmanning at isi.edu (manning bill) Date: Tue, 17 Jun 2014 15:45:11 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <20140617223932.51558.qmail@joyce.lan> References: <20140617223932.51558.qmail@joyce.lan> Message-ID: announce them so folks can use the space as darknets… /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 17June2014Tuesday, at 15:39, John Levine wrote: > In article you write: >> +1+1+1 re living room > > My cable company assigns my home network a /50. I can figure out what > to do with two of the /64s (wired and wireless networks), but I'm > currently stumped on the other 16,382 of them. > > R's, > John > > > >> On Jun 17, 2014 12:32 PM, "rwebb at ropeguru.com" wrote: >> >>> On Tue, 17 Jun 2014 13:25:37 -0400 >>> Valdis.Kletnieks at vt.edu wrote: >>> >>>> On Tue, 17 Jun 2014 13:14:04 -0400, "rwebb at ropeguru.com" said: >>>> >>>> No, 8 individual IPv6 addresses. >>>>> >>>> >>>> Wow. Harsh. I burn more than that just in my living room. >>>> >>> >>> I don't think that is too harsh as all 8 are assigned to a single server. >>> So if I have three VPS's, I have 24 total addresses. > > From jra at baylink.com Tue Jun 17 23:07:20 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 17 Jun 2014 19:07:20 -0400 (EDT) Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> Message-ID: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > It does ring a bit hollow that these sites haven't gotten there when > others (Google, Facebook) have already shown you can publish AAAA > records with no adverse public impact. "no" adverse impact? Seems to me I've seen a few threads go by the last few years that suggested that there were a few pathological cases where having the 4A record was worse than not... 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 marka at isc.org Tue Jun 17 23:24:02 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 18 Jun 2014 09:24:02 +1000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: Your message of "Tue, 17 Jun 2014 19:07:20 -0400." <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> Message-ID: <20140617232402.0FC23185D08F@rock.dv.isc.org> In message <32832593.4076.1403046439981.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Jared Mauch" > > > It does ring a bit hollow that these sites haven't gotten there when > > others (Google, Facebook) have already shown you can publish AAAA > > records with no adverse public impact. > > "no" adverse impact? > > Seems to me I've seen a few threads go by the last few years that suggested > that there were a few pathological cases where having the 4A record was What's this "4A" garbage? > worse than not... See the red line. https://www.google.com/intl/en/ipv6/statistics.html Additionally Google and FaceBook have basically forced the client side to fix their broken network configurations by publishing AAAA records to everyone. It only takes one or two big sites to force this issue which they have done. You are nowhere near the bleeding edge by publishing AAAA records today. Mark > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DI > I > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 127 > 4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mpetach at netflight.com Tue Jun 17 23:31:56 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 17 Jun 2014 16:31:56 -0700 Subject: Applications that break when not using /64 In-Reply-To: <53A0BB7C.3050900@massar.ch> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> <53A0AF68.4050909@massar.ch> <53A0BB7C.3050900@massar.ch> Message-ID: On Tue, Jun 17, 2014 at 3:04 PM, Jeroen Massar wrote: > On 2014-06-18 00:02, Matthew Petach wrote: > [..] > > I tried to configure my FreeBSD box at home to > > use a /120 subnet mask. It consistently crashed > > with a kernel panic. > > Where is the bug report? > > I am fairly confident that that really should not be an issue, with the > BSD stack being one of the oldest IPv6 stacks around (thank you itojun > and the rest of KAME!) > > Greets, > Jeroen > > Didn't file a bug report; just used it as proof of why a bigger IPv6 allocation was needed, and worked around the problem that way. If you're curious, I can change /etc/rc.conf.local back and recreate the problem. Not sure who I'd file the bug with, though. Matt From jared at puck.nether.net Wed Jun 18 00:41:55 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Jun 2014 20:41:55 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <20140617232402.0FC23185D08F@rock.dv.isc.org> References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> <20140617232402.0FC23185D08F@rock.dv.isc.org> Message-ID: <1ACF3587-2724-4A25-9042-95C7266F25B3@puck.nether.net> On Jun 17, 2014, at 7:24 PM, Mark Andrews wrote: > > In message <32832593.4076.1403046439981.JavaMail.root at benjamin.baylink.com>, Ja > y Ashworth writes: >> ----- Original Message ----- >>> From: "Jared Mauch" >> >>> It does ring a bit hollow that these sites haven't gotten there when >>> others (Google, Facebook) have already shown you can publish AAAA >>> records with no adverse public impact. >> >> "no" adverse impact? >> >> Seems to me I've seen a few threads go by the last few years that suggested >> that there were a few pathological cases where having the 4A record was > > What's this "4A" garbage? > >> worse than not... > > See the red line. https://www.google.com/intl/en/ipv6/statistics.html > > Additionally Google and FaceBook have basically forced the client > side to fix their broken network configurations by publishing AAAA > records to everyone. It only takes one or two big sites to force > this issue which they have done. > > You are nowhere near the bleeding edge by publishing AAAA records today. What I do find interesting (and without any data) is why some folks have removed IPv6, eg: http://xkcd.com/865/ But there is no AAAA for it anymore. My simple rant is: it's 2014, if you don't at least have IPv6 on for your edge facing your ISP and your allocation, you're doing it wrong. - Jared From owen at delong.com Wed Jun 18 00:46:30 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 17 Jun 2014 17:46:30 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 17, 2014, at 16:07 , Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jared Mauch" > >> It does ring a bit hollow that these sites haven't gotten there when >> others (Google, Facebook) have already shown you can publish AAAA >> records with no adverse public impact. > > "no" adverse impact? > > Seems to me I've seen a few threads go by the last few years that suggested > that there were a few pathological cases where having the 4A record was > worse than not... Yes, currently less than 0.05% of end users and usually because they have misconfigured systems that think they have IPv6 access when they really don't. One could make a valid argument that this is no worse than systems with misconfigured IPv4 who cannot reach Google at all even if they don't publish AAAA records because their IPv4 is so badly misconfigured that it doesn't work either. I suspect it may well be approximately the same fraction of systems, though it may take longer to notice/resolve the IPv6 issues than the IPv4 ones. Owen From jared at puck.nether.net Wed Jun 18 01:00:47 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Jun 2014 21:00:47 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> Message-ID: <90939D16-04DF-479C-AACB-27926A65B170@puck.nether.net> On Jun 17, 2014, at 8:46 PM, Owen DeLong wrote: > One could make a valid argument that this is no worse than systems with misconfigured IPv4 who cannot reach Google at all even if they don't publish AAAA records because their IPv4 is so badly misconfigured that it doesn't work either. I suspect it may well be approximately the same fraction of systems, though it may take longer to notice/resolve the IPv6 issues than the IPv4 ones. At the last RIPE i had some troubles with my IPv4 while my IPv6 worked fine. Folks internally grumbled about fixing IPv6 hosts because those with IPv6 are in the minority, but that is a diminishing view and honestly people who keep repeating that will slowly undercut themselves out of relevance. - jared From frnkblk at iname.com Wed Jun 18 03:43:27 2014 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 17 Jun 2014 22:43:27 -0500 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <1ACF3587-2724-4A25-9042-95C7266F25B3@puck.nether.net> References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> <20140617232402.0FC23185D08F@rock.dv.isc.org> <1ACF3587-2724-4A25-9042-95C7266F25B3@puck.nether.net> Message-ID: <003801cf8aa7$79a6a690$6cf3f3b0$@iname.com> These sites used to be dual-stacked: www.cablelabs.com (over 180 days ago via ipv6.cablelabs.com) www.att.net (over 44 days ago) www.charter.com (over 151 days) www.globalcrossing.com (over 802 days) www.timewarnercable.com (over 593 days) and www.t-online.de has been broken for over 33 days. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch Sent: Tuesday, June 17, 2014 7:42 PM To: Mark Andrews Cc: NANOG Subject: Re: Ars Technica on IPv4 exhaustion On Jun 17, 2014, at 7:24 PM, Mark Andrews wrote: > > In message <32832593.4076.1403046439981.JavaMail.root at benjamin.baylink.com>, Ja > y Ashworth writes: >> ----- Original Message ----- >>> From: "Jared Mauch" >> >>> It does ring a bit hollow that these sites haven't gotten there when >>> others (Google, Facebook) have already shown you can publish AAAA >>> records with no adverse public impact. >> >> "no" adverse impact? >> >> Seems to me I've seen a few threads go by the last few years that suggested >> that there were a few pathological cases where having the 4A record was > > What's this "4A" garbage? > >> worse than not... > > See the red line. https://www.google.com/intl/en/ipv6/statistics.html > > Additionally Google and FaceBook have basically forced the client > side to fix their broken network configurations by publishing AAAA > records to everyone. It only takes one or two big sites to force > this issue which they have done. > > You are nowhere near the bleeding edge by publishing AAAA records today. What I do find interesting (and without any data) is why some folks have removed IPv6, eg: http://xkcd.com/865/ But there is no AAAA for it anymore. My simple rant is: it's 2014, if you don't at least have IPv6 on for your edge facing your ISP and your allocation, you're doing it wrong. - Jared From mark.tinka at seacom.mu Wed Jun 18 10:07:34 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jun 2014 12:07:34 +0200 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <53A09D46.7000507@Janoszka.pl> References: <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> Message-ID: <201406181207.34578.mark.tinka@seacom.mu> On Tuesday, June 17, 2014 09:55:50 PM Grzegorz Janoszka wrote: > There are still applications that break with subnet > smaller than /64, so all VPS providers probably have to > use /64 addressing. Which ones? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Wed Jun 18 10:08:48 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jun 2014 12:08:48 +0200 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <53A0A6E1.9050906@Janoszka.pl> References: <53A0A6E1.9050906@Janoszka.pl> Message-ID: <201406181208.48292.mark.tinka@seacom.mu> On Tuesday, June 17, 2014 10:36:49 PM Grzegorz Janoszka wrote: > There are > application which break if provided with /80 or /120, Which ones? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Grzegorz at Janoszka.pl Wed Jun 18 10:31:49 2014 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Wed, 18 Jun 2014 12:31:49 +0200 Subject: Applications that break when not using /64 In-Reply-To: <53A0AF68.4050909@massar.ch> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> <53A0AF68.4050909@massar.ch> Message-ID: <53A16A95.4090405@Janoszka.pl> On 17/06/14 23:13 , Jeroen Massar wrote: > Thus, can you please identify these applications so that we can hammer > on the developers of those applications and fix that problem? I haven't done extensive testing. I have just tried to divide a /64 into smaller subnets and to run Debian and Windows on it (as Matthew Petach did with his FreeBSD). I think I have tried /112 or /120. Debian was mostly fine, just one torrent or newsgroups client couldn't do v6 (can't recall which one), with Windows it was a different story and basically nothing really worked. It was some time ago and I haven't tried Windows 7 SP1, maybe it has been fixed till now. Does anyone have Windows with IPv6 and netmask > /64? -- Grzegorz Janoszka From md1clv at md1clv.com Wed Jun 18 10:35:23 2014 From: md1clv at md1clv.com (Daniel Ankers) Date: Wed, 18 Jun 2014 11:35:23 +0100 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <20140617223932.51558.qmail@joyce.lan> References: <20140617223932.51558.qmail@joyce.lan> Message-ID: On 17 June 2014 23:39, John Levine wrote: > In article obDVrw at mail.gmail.com> you write: > >+1+1+1 re living room > > My cable company assigns my home network a /50. I can figure out what > to do with two of the /64s (wired and wireless networks), but I'm > currently stumped on the other 16,382 of them. > > R's, > John I've got a /56 which I'm then delegating /60s from - so, for example, I've got a laptop which I run things like Virtualbox and Docker on. This laptop has a /60 and it can hand out /64s for virtual networks. I figure that with the larger allocations to homes or offices the question isn't "how do I allocate all of these" but "how do I delegate chunks of this in a hierarchical manner." Dan From jeroen at massar.ch Wed Jun 18 10:39:21 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 18 Jun 2014 12:39:21 +0200 Subject: Applications that break when not using /64 In-Reply-To: <53A16A95.4090405@Janoszka.pl> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> <53A0AF68.4050909@massar.ch> <53A16A95.4090405@Janoszka.pl> Message-ID: <53A16C59.3050506@massar.ch> On 2014-06-18 12:31, Grzegorz Janoszka wrote: > On 17/06/14 23:13 , Jeroen Massar wrote: >> Thus, can you please identify these applications so that we can hammer >> on the developers of those applications and fix that problem? > > I haven't done extensive testing. I have just tried to divide a /64 into > smaller subnets and to run Debian and Windows on it (as Matthew Petach > did with his FreeBSD). I think I have tried /112 or /120. Debian was > mostly fine, just one torrent or newsgroups client couldn't do v6 (can't > recall which one), with Windows it was a different story and basically > nothing really worked. Why would a torrent client care about the prefix length? But anyway, you had some random application that nobody uses that was broken, seems to be a problem with that specific application, not anything else. > It was some time ago and I haven't tried Windows 7 SP1, maybe it has > been fixed till now. Does anyone have Windows with IPv6 and netmask > /64? I've only played with the NT4, Win2k, XP, and Vista stacks, and these work fine in every scenario (/64 SLAAC, or /128 static config). Hence you'll need to provide a lot more details than "it didn't work"... Greets, Jeroen From saku at ytti.fi Wed Jun 18 10:53:00 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 18 Jun 2014 13:53:00 +0300 Subject: Applications that break when not using /64 In-Reply-To: <53A0AF68.4050909@massar.ch> References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> <53A0AF68.4050909@massar.ch> Message-ID: <20140618105300.GA23458@pob.ytti.fi> On (2014-06-17 23:13 +0200), Jeroen Massar wrote: > Except for SLAAC that requires a /64 due to it using EUI-48 to make up > the address, which "applications" are these, as those applications are > broken by design. Strictly speaking SLAAC standard does not care about network size, you could specify standard using SLAAC for arbitrary media with arbitrary network size. In Ethernet EUI-64 is used, but that is not hard technical limitation, infact Cisco IOS happily will accept any prefix size in Ethernet and SLAAC will work fine. SLAAC never makes any guarantees of uniqueness which implies network can be arbitrarily small, as some other method (DAD) is needed for uniqueness guarantees. -- ++ytti From simon at per.reau.lt Wed Jun 18 11:19:01 2014 From: simon at per.reau.lt (Simon Perreault) Date: Wed, 18 Jun 2014 05:19:01 -0600 Subject: Applications that break when not using /64 In-Reply-To: References: <01DC8684-7868-4535-9DB1-177E032706E3@virtualized.org> <5166.1403025937@turing-police.cc.vt.edu> <35DBEB1C-BCFD-4778-963C-208BF77219E6@virtualized.org> <53A09D46.7000507@Janoszka.pl> <53A0A6E1.9050906@Janoszka.pl> <53A0AF68.4050909@massar.ch> <53A0BB7C.3050900@massar.ch> Message-ID: <53A175A5.80007@per.reau.lt> Le 2014-06-17 17:31, Matthew Petach a écrit : > Not sure who I'd > file the bug with, though. bz at freebsd.org (Looking at Bjoern with an evil grin...) Simon From rwebb at ropeguru.com Wed Jun 18 13:44:34 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Wed, 18 Jun 2014 09:44:34 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <882EF713-A8A7-483A-8446-9576A29AADA2@puck.nether.net> Message-ID: On Tue, 17 Jun 2014 11:26:16 -0400 "rwebb at ropeguru.com" wrote: > I don't think it is harsh when they lead their customers on with no >progress. > > https://www.digitalocean.com/community/questions/is-ipv6-available > > digitalocean.uservoice.com/forums/136585-digital-ocean/suggestions/2639897-ipv6-addresses > > Take note of the original post dates and the responses. Original >questions were in 2012 with responses of Q4 2012 to Q1 2013. > > > > Robert To add on to this, it appears that DO now considers the request for IPv6 as now being "COMPLETE" because they have rolled it out in a single DC in Singapore, when the request was made by a lot of people BEFORE the Singapore DC was ever avaiable. Great lack of respect to your customer base.... http://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2639897-ipv6-addresses From Jason_Livingood at cable.comcast.com Wed Jun 18 14:16:13 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 18 Jun 2014 14:16:13 +0000 Subject: BITAG Announces Next Technical Review on Interconnection Message-ID: May be of interest to folks here Begin forwarded message: From: "Kaleb A. Sieh" > Subject: BITAG Announces Next Technical Review on Interconnection Date: June 18, 2014 at 8:44:24 AM EDT Today, the Broadband Internet Technical Advisory Group (BITAG) announced its next technical review focused on the topic of Internet Network Interconnection. This topic was submitted jointly by two of BITAG’s members, CenturyLink and the Center for Democracy & Technology, and the review will result in a report with an anticipated publication date in November 2014. The Internet is a complex “network of networks” linked together in a variety of ways and by a variety of technologies. In order for end users connected to one network to access data and services connected to another network, these networks must “interconnect” with each other, either directly or indirectly. Internet network interconnection, also often referred to as “peering” or “transit”, is an increasingly important topic as the Internet ecosystem faces a dynamic growth period characterized by rapidly increasing demand, changing technologies and product offerings, and significant shifts in data traffic patterns. But there is little public information about Internet interconnection available to those not intimately involved with operating networks – including consumers, journalists and regulators. With this report, BITAG’s Technical Working Group (TWG) aims to provide an informative contribution to the ongoing discussion surrounding Internet network interconnection. Some topics likely to be covered in the report include: (1) the history of Internet network interconnection, along with a brief historical review of network interconnection in other industries and contexts; (2) how Internet traffic is managed between networks; and (3) the evolving nature of Internet data traffic patterns. Jason Weil, Principal Engineer at Time Warner Cable, and Joseph Lorenzo Hall, Chief Technologist at the Center for Democracy & Technology, will be the lead editors of the report on this topic. Douglas Sicker, Executive Director of BITAG, Chair of BITAG’s Technical Working Group, Department Head of Engineering and Public Policy and a professor of Computer Science at Carnegie Mellon University, and on leave from the University of Colorado Boulder, where he is an Endowed Professor of Computer Science and Telecommunications, will chair the review itself. For more information on the topic, please see the attached press release – which is also available on the BITAG website at www.bitag.org. Below is more info on BITAG and its structure/processes. Feel free to contact me with any questions, comments, or other needs. Kind regards, Kaleb Kaleb A. Sieh Deputy Director House Counsel Broadband Internet Technical Advisory Group (BITAG) ksieh at bitag.org ________________________________ About BITAG. BITAG is a non-profit, multi-stakeholder organization focused on bringing together engineers and technical experts in a Technical Working Group (TWG) to develop consensus on broadband network management practices and other related technical issues that can affect users' Internet experience, including the impact to and from applications, content and devices that utilize the Internet. * Mission. BITAG's mission includes: (a) educating policymakers on such technical issues; (b) addressing specific technical matters in an effort to minimize related policy disputes; and (c) serving as a sounding board for new ideas and network management practices. Specific TWG functions can include: (i) identifying "best practices" by broadband providers and other entities; (ii) providing technical guidance to industry and to the public; and /or (iii) issuing advisory opinions on the technical issues that may underlie disputes concerning broadband network management practices. * BITAG Reports. BITAG TWG reports focus primarily on technical issues, especially those with the potential to be construed as anti-competitive, discriminatory, or otherwise motivated by non-technical factors. While the reports may touch on a broad range of questions associated with a particular network management practice, the reports are not intended to address or analyze in a comprehensive fashion the economic, legal, regulatory or public policy issues that the practice may raise. About BITAG's Technical Review Process. BITAG's core substantive work is performed through its Technical Working Group (TWG), which was formed with the core principles of being: technically driven, balanced, open, efficient, independent, and flexible. The TWG reviews technical issues brought to it through Review Requests submitted by both Members and non-Members, or through a majority vote of the TWG engineers themselves. * Committees. Each individual technical review is taken up by a committee of the TWG that is composed of engineers and other technical experts representing a broad cross section of the Internet ecosystem. * Consensus-based. TWG committees operate on a consensus-basis, with balanced backstop voting procedures so that when consensus cannot be achieved, each Member category has an equal say in the work product regardless of the composition of the committee. * Expeditious — 120-day "shot clock". BITAG was structured to work as expeditiously as possible, with each technical committee operating under a 120-day "shot clock" during which the respective technical review and report must be completed. From mark.tinka at seacom.mu Wed Jun 18 14:51:01 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jun 2014 16:51:01 +0200 Subject: Applications that break when not using /64 In-Reply-To: <53A16A95.4090405@Janoszka.pl> References: <53A0AF68.4050909@massar.ch> <53A16A95.4090405@Janoszka.pl> Message-ID: <201406181651.04066.mark.tinka@seacom.mu> On Wednesday, June 18, 2014 12:31:49 PM Grzegorz Janoszka wrote: > I haven't done extensive testing. I have just tried to > divide a /64 into smaller subnets and to run Debian and > Windows on it (as Matthew Petach did with his FreeBSD). > I think I have tried /112 or /120. Debian was mostly > fine, just one torrent or newsgroups client couldn't do > v6 (can't recall which one), with Windows it was a > different story and basically nothing really worked. That's interesting. I've run /112's on OpenSUSE, FreeBSD (from 7.0 up to 10), Windows 7, Windows 8 and Mac OS X (since Tiger) and haven't had any issues worth remembering. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From efbatey at gmail.com Wed Jun 18 15:33:08 2014 From: efbatey at gmail.com (Everett F Batey II Gi) Date: Wed, 18 Jun 2014 08:33:08 -0700 Subject: Client on OS X, Browsers ALL fail DNS Lookup off net Hosts, SMTP+shell OK Message-ID: <49662DAE-DE5E-4563-A417-ACD3EB60DFB5@gmail.com> Newly evolved problems (network has been good for years, no recent known upgrades, config changes): Clients on MAC OS X, Browsers ALL (FFox, Opera, Safari, Chrome) fail DNS Lookups for non-local web servers, BUT: SMTP mail, POP, IMAP and shell commands (ping, trace route) fully OK AND: www.google.com and a very few .orgs resolve on web browsers. Connected via TWBC: RCWE, 13820 Sunrise Valley Drive, Herndon, Allocations for this OrgID serve Road Runner commercial customers out of the Honolulu, HI, Kansas City, KS, Orange, CA and San Diego, CA RDCs. (Probably Orange Co, CA) No, MAC has no nsswitch.conf .. to there. MAC HACKED ( ) DNS HACKED ( ) ISP FAILED fwdg DNS ( ) OTHER IDEA, START POINT ____ Thnx — VR, Ev / efbatey at gmail.com / +1-805-616-2471 From niels=nanog at bakker.net Wed Jun 18 15:40:15 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 18 Jun 2014 17:40:15 +0200 Subject: Client on OS X, Browsers ALL fail DNS Lookup off net Hosts, SMTP+shell OK In-Reply-To: <49662DAE-DE5E-4563-A417-ACD3EB60DFB5@gmail.com> References: <49662DAE-DE5E-4563-A417-ACD3EB60DFB5@gmail.com> Message-ID: <20140618154015.GA21878@excession.tpb.net> I'm sorry, this is NANOG, not your local helpdesk. HTH, HAND, -- Niels. * efbatey at gmail.com (Everett F Batey II Gi) [Wed 18 Jun 2014, 17:34 CEST]: >Newly evolved problems > (network has been good for years, no recent known upgrades, config changes): > Clients on MAC OS X, > Browsers ALL (FFox, Opera, Safari, Chrome) fail DNS Lookups for non-local web servers, > BUT: SMTP mail, POP, IMAP and shell commands (ping, trace route) fully OK > AND: www.google.com and a very few .orgs resolve on web browsers. > Connected via TWBC: RCWE, 13820 Sunrise Valley Drive, Herndon, Allocations for this OrgID serve Road Runner commercial customers out of the Honolulu, HI, Kansas City, KS, Orange, CA and San Diego, CA RDCs. (Probably Orange Co, CA) > No, MAC has no nsswitch.conf .. to there. > MAC HACKED ( ) DNS HACKED ( ) ISP FAILED fwdg DNS ( ) > OTHER IDEA, START POINT ____ Thnx > >— > VR, Ev / efbatey at gmail.com / +1-805-616-2471 > From nick at foobar.org Wed Jun 18 15:42:57 2014 From: nick at foobar.org (Nick Hilliard) Date: Wed, 18 Jun 2014 16:42:57 +0100 Subject: Client on OS X, Browsers ALL fail DNS Lookup off net Hosts, SMTP+shell OK In-Reply-To: <20140618154015.GA21878@excession.tpb.net> References: <49662DAE-DE5E-4563-A417-ACD3EB60DFB5@gmail.com> <20140618154015.GA21878@excession.tpb.net> Message-ID: <53A1B381.5070503@foobar.org> The Internet is down. Didn't you hear? Nick On 18/06/2014 16:40, Niels Bakker wrote: > I'm sorry, this is NANOG, not your local helpdesk. > > HTH, HAND, > > > -- Niels. > > * efbatey at gmail.com (Everett F Batey II Gi) [Wed 18 Jun 2014, 17:34 CEST]: >> Newly evolved problems >> (network has been good for years, no recent known upgrades, config >> changes): >> Clients on MAC OS X, >> Browsers ALL (FFox, Opera, Safari, Chrome) fail DNS Lookups for >> non-local web servers, >> BUT: SMTP mail, POP, IMAP and shell commands (ping, trace route) >> fully OK >> AND: www.google.com and a very few .orgs resolve on web browsers. >> Connected via TWBC: RCWE, 13820 Sunrise Valley Drive, Herndon, >> Allocations for this OrgID serve Road Runner commercial customers out of >> the Honolulu, HI, Kansas City, KS, Orange, CA and San Diego, CA RDCs. >> (Probably Orange Co, CA) >> No, MAC has no nsswitch.conf .. to there. >> MAC HACKED ( ) DNS HACKED ( ) ISP FAILED fwdg DNS ( ) >> OTHER IDEA, START POINT ____ Thnx >> >> — >> VR, Ev / efbatey at gmail.com / +1-805-616-2471 >> From beckman at angryox.com Wed Jun 18 15:44:02 2014 From: beckman at angryox.com (Peter Beckman) Date: Wed, 18 Jun 2014 11:44:02 -0400 Subject: Client on OS X, Browsers ALL fail DNS Lookup off net Hosts, SMTP+shell OK In-Reply-To: <49662DAE-DE5E-4563-A417-ACD3EB60DFB5@gmail.com> References: <49662DAE-DE5E-4563-A417-ACD3EB60DFB5@gmail.com> Message-ID: 1. It could be that DNS is working fine but port 80/443 is blocked or filtered when you leave the local LAN. New Firewall? Proxy authentication required? 2. The DNS server (cat /etc/resolv.conf) that the Mac hosts are pointed to can resolve internal but cannot reach external DNS hosts due to the upstream blocking DNS due to DNS amplification attacks (or bonehead admin). 3. Your resolver has a static configuration pointed to an upstream DNS server, and it has stopped responding and no backups are available. 4. Your resolver has a static configuration pointed to an upstream DNS server, and the primary DNS upstream server is offline and you aren't waiting 60 seconds for it to fail to the next DNS server. That's my off-the-cuff assessment. On Wed, 18 Jun 2014, Everett F Batey II Gi wrote: > Newly evolved problems > (network has been good for years, no recent known upgrades, config changes): > Clients on MAC OS X, > Browsers ALL (FFox, Opera, Safari, Chrome) fail DNS Lookups for non-local web servers, > BUT: SMTP mail, POP, IMAP and shell commands (ping, trace route) fully OK > AND: www.google.com and a very few .orgs resolve on web browsers. > Connected via TWBC: RCWE, 13820 Sunrise Valley Drive, Herndon, Allocations for this OrgID serve Road Runner commercial customers out of the Honolulu, HI, Kansas City, KS, Orange, CA and San Diego, CA RDCs. (Probably Orange Co, CA) > No, MAC has no nsswitch.conf .. to there. > MAC HACKED ( ) DNS HACKED ( ) ISP FAILED fwdg DNS ( ) > OTHER IDEA, START POINT ____ Thnx > > — > VR, Ev / efbatey at gmail.com / +1-805-616-2471 > > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From contact at winterei.se Wed Jun 18 15:47:38 2014 From: contact at winterei.se (Paul S.) Date: Thu, 19 Jun 2014 00:47:38 +0900 Subject: Client on OS X, Browsers ALL fail DNS Lookup off net Hosts, SMTP+shell OK In-Reply-To: <53A1B381.5070503@foobar.org> References: <49662DAE-DE5E-4563-A417-ACD3EB60DFB5@gmail.com> <20140618154015.GA21878@excession.tpb.net> <53A1B381.5070503@foobar.org> Message-ID: <53A1B49A.2030201@winterei.se> Oh lord... On 6/19/2014 午前 12:42, Nick Hilliard wrote: > The Internet is down. Didn't you hear? > > Nick > > On 18/06/2014 16:40, Niels Bakker wrote: >> I'm sorry, this is NANOG, not your local helpdesk. >> >> HTH, HAND, >> >> >> -- Niels. >> >> * efbatey at gmail.com (Everett F Batey II Gi) [Wed 18 Jun 2014, 17:34 CEST]: >>> Newly evolved problems >>> (network has been good for years, no recent known upgrades, config >>> changes): >>> Clients on MAC OS X, >>> Browsers ALL (FFox, Opera, Safari, Chrome) fail DNS Lookups for >>> non-local web servers, >>> BUT: SMTP mail, POP, IMAP and shell commands (ping, trace route) >>> fully OK >>> AND: www.google.com and a very few .orgs resolve on web browsers. >>> Connected via TWBC: RCWE, 13820 Sunrise Valley Drive, Herndon, >>> Allocations for this OrgID serve Road Runner commercial customers out of >>> the Honolulu, HI, Kansas City, KS, Orange, CA and San Diego, CA RDCs. >>> (Probably Orange Co, CA) >>> No, MAC has no nsswitch.conf .. to there. >>> MAC HACKED ( ) DNS HACKED ( ) ISP FAILED fwdg DNS ( ) >>> OTHER IDEA, START POINT ____ Thnx >>> >>> — >>> VR, Ev / efbatey at gmail.com / +1-805-616-2471 >>> From johnl at iecc.com Wed Jun 18 16:07:51 2014 From: johnl at iecc.com (John Levine) Date: 18 Jun 2014 16:07:51 -0000 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: Message-ID: <20140618160751.59276.qmail@joyce.lan> >> My cable company assigns my home network a /50. I can figure out what >> to do with two of the /64s (wired and wireless networks), but I'm >> currently stumped on the other 16,382 of them. ... >I figure that with the larger allocations to homes or offices the question >isn't "how do I allocate all of these" but "how do I delegate chunks of >this in a hierarchical manner." Or even, how do I allocate them at all. My D-Link wifi router can pick up a /64 and route it to its own LAN (wired and wifi bridged) and that's about it for IPv6 other than port filters to enable some inbound connections. It runs Linux so I suppose I could put dd-wrt onto it, but that's more fun than I have time for this week. From youssef at 720.fr Wed Jun 18 06:59:22 2014 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Wed, 18 Jun 2014 08:59:22 +0200 Subject: 012 Smile Telecom (AS9116) peering contact Message-ID: Dear All, I'm looking for a valid peering contact for 012 Smile Telecom AS9116 (aka Golden-Lines/Internet-Gold/012 Smile Communications). Their public peering contact isn't working. If one their peering admins is watching, please contact me privatly. Best regards. -- Youssef BENGELLOUN-ZAHR From mail at martingeddes.com Wed Jun 18 09:41:23 2014 From: mail at martingeddes.com (Martin Geddes) Date: Wed, 18 Jun 2014 10:41:23 +0100 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <53A0BD36.5060703@gmail.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> Message-ID: "IPv6 will never become the defacto standard until the vast majority of users have access to IPv6 connectivity." It may never become the defacto standard, period. Nearly 20 years to reach 2% penetration is a strong hint that the costs outweigh the benefits. IP's global addressing system is broken from the outset. See John Day's presentation "Surviving Networking’s Dark Ages - or How in the Hell Do You Lose a Layer!?" (or, indeed, lots of them at once.) It's really all about scopes, not layers - the TCP/IP architecture is divided up the wrong way, and it will never be fixed. It's an escaped 1970s lab experiment that was able to extract the statistical multiplexing gain faster than rivals, but on a performance and security "buy now, pay later" basis. If you want to see a viable alternative approach, read my post "Network architecture research: TCP/IP vs RINA" for an introduction. That said, I'm not expecting anyone to immediately resign their membership of the Seven Layer Adventists as a result. Yes, the Internet's intellectual foundations are rotten - but that is too much anxiety and dissonance for most people to cope with. May all your intentional semantics become operational, Martin On 17 June 2014 23:12, Andrew Fried wrote: > IPv6 will never become the defacto standard until the vast majority of > users have access to IPv6 connectivity. > > Everything I have at the colo is dual stacked, but I can't reach my own > systems via IPv6 because my business class Verizon Fios connection is > IPv4 *only*. Yes, Comcast is in the process of rolling out IPv6, but my > Comcast circuit in Washington DC is IPv4 only. And I'd suspect that > everyone with Time Warner, AT&T, Cox, etc are all in the same boat. > > Whether the reason for the lack of IPv6 deployment is laziness or an > intentional omission on the part of large ISPs to protect their income > from leasing IPv4 addresses doesn't matter to the vast majority of the > end users; they simply can't access IPv6 via IPv4 only networks, > without using some kludgy, complicated tunneling protocols. > > Andy > > -- > Andrew Fried > andrew.fried at gmail.com > > On 6/17/14, 5:48 PM, Jared Mauch wrote: > > > > On Jun 17, 2014, at 5:41 PM, Lee Howard wrote: > > > >> > >> > >> On 6/17/14 4:20 PM, "Jay Ashworth" wrote: > >> > >>> Here's what the general public is hearing: > >> > >> But only while they still have IPv4 addresses: > >> ~$ dig AAAA arstechnica.com +short > >> ~$ > >> > >> > >> > >>> > >>> > >>> > http://arstechnica.com/information-technology/2014/06/with-the-americas-ru > >>> nning-out-of-ipv4-its-official-the-internet-is-full/ > >> > >> > >> Can't tech news sites *please* run dual stack while they're spouting > >> end-of-IPv4 stories? > > > > > > > > I would love to see a few more properties do IPv6 by default, such as > ARS, Twitter and a few others. After posting some links and being a log > stalker last night the first 3 hits from non-bots were from users on IPv6 > enabled networks. > > > > It does ring a bit hollow that these sites haven't gotten there when > others (Google, Facebook) have already shown you can publish AAAA records > with no adverse public impact. Making IPv6 available by default for users > would be an excellent step. People like AT&T who control the 'attwifi' > ssid could do NAT66 at their sites and provide similar service to the > masses. With chains like Hilton, McDonalds, etc.. all having this > available, it would push IPv6 very far almost immediately with no adverse > impact compared to users IPv4 experience. > > > > - Jared > > > From gp+nanog at gparent.net Wed Jun 18 14:01:01 2014 From: gp+nanog at gparent.net (gp) Date: Wed, 18 Jun 2014 14:01:01 +0000 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <882EF713-A8A7-483A-8446-9576A29AADA2@puck.nether.net> Message-ID: <9eaaef436ff726cde00a091f0a554131@gparent.net> Of course, one could also read the giant paragraph written by the CEO and see exactly what's going on, including the info about the other data centers and the new ones coming up. I love how people whine that operators don't deploy IPv6 quickly enough, and they cry even harder when it's actually being deployed because it's not perfect and everywhere on the first day. Really, give it a break. On 2014-06-18 13:44, rwebb at ropeguru.com wrote: > On Tue, 17 Jun 2014 11:26:16 -0400 > "rwebb at ropeguru.com" wrote: >> I don't think it is harsh when they lead their customers on with no >> progress. >> >> https://www.digitalocean.com/community/questions/is-ipv6-available >> >> digitalocean.uservoice.com/forums/136585-digital-ocean/suggestions/2639897-ipv6-addresses >> >> Take note of the original post dates and the responses. Original >> questions were in 2012 with responses of Q4 2012 to Q1 2013. >> >> >> >> Robert > > To add on to this, it appears that DO now considers the request for > IPv6 as now being "COMPLETE" because they have rolled it out in a > single DC in Singapore, when the request was made by a lot of people > BEFORE the Singapore DC was ever avaiable. > > Great lack of respect to your customer base.... > > http://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2639897-ipv6-addresses From hank at efes.iucc.ac.il Wed Jun 18 16:29:43 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 18 Jun 2014 19:29:43 +0300 Subject: 012 Smile Telecom (AS9116) peering contact Message-ID: <20140618162946.C0B1256C2B@doar.tau.ac.il> Try ISP_NITUR at 012.net.   They recently merged with another ISP and many addresses stopped working.  This one still works and should hopefully lead to someone with a clue there. Hank On Jun 18, 2014 9:59 AM, Youssef Bengelloun-Zahr wrote: > > Dear All, > > I'm looking for a valid peering contact for 012 Smile Telecom AS9116 (aka > Golden-Lines/Internet-Gold/012 Smile Communications). Their public peering > contact isn't working. > > If one their peering admins is watching, please contact me privatly. > > Best regards. > > > > -- > Youssef BENGELLOUN-ZAHR From source_route at yahoo.com Wed Jun 18 16:31:38 2014 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 18 Jun 2014 09:31:38 -0700 Subject: Help with Confederation-RR-MPBGP In-Reply-To: <539A1EF7.7090704@free.fr> References: <1402590320.65337.YahooMailNeo@web122505.mail.ne1.yahoo.com> <7092.1402591193@turing-police.cc.vt.edu> <539A1EF7.7090704@free.fr> Message-ID: <1403109098.19558.YahooMailNeo@web122502.mail.ne1.yahoo.com> I guess my question is (sorry MPLS speak ahead) with 4 PE's on the edge running MP-BGP and ISIS & 4 P's in the core running ISIS, is it best practice to confederate or use a route reflector and make the PE's clients. Basically I want to know what an ISP would do, not a test in a LAB. On Thursday, June 12, 2014 2:45 PM, Michael Hallgren wrote:   Le 12/06/2014 18:39, Valdis.Kletnieks at vt.edu a écrit : > On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said: >> need some guidance on best practices > > What the vendor says is best practices, or what people in the trenches say? > >> Is it more efficient to use RR or Confederation? > > If option A is 2% more "efficient" than option B, but takes 10% longer to > deploy and causes 3% more SLA payouts to your customers when the added > complexity causes a whoopsie, how much more work could you have gotten done in > the time you spent in an uncomfortable meeting explaining to upper management > why the whoopsie happened? > > (Sorry, it's been that sort of week :) :-) Now, Philip, I think along the same path as Vladis: it depends... What does your physical or layer 2 network look like? How do you expect packets to move around inside, and in and out, of that topology? You need policing? How much and of what, etc, etc...? I'm quite often a fan of confed's, if the network is young thus ``easy'' migration, but there are scenarios... Please provide more detail to this mail thread or one-to-one if you prefer. Cheers, mh > From niels=nanog at bakker.net Wed Jun 18 16:56:17 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 18 Jun 2014 18:56:17 +0200 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> Message-ID: <20140618165617.GB21878@excession.tpb.net> * mail at martingeddes.com (Martin Geddes) [Wed 18 Jun 2014, 18:17 CEST]: >It may never become the defacto standard, period. Nearly 20 years to reach >2% penetration is a strong hint that the costs outweigh the benefits. Never before have we run out of IPv4 address space, so this time may well be different, now that an actual need for change is developing. [..] >their membership of the Seven Layer Adventists as a result. Yes, the Nobody outside academia considers the OSI model a valid representation of the Internet. -- Niels. From youssef at 720.fr Wed Jun 18 17:26:42 2014 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Wed, 18 Jun 2014 19:26:42 +0200 Subject: 012 Smile Telecom (AS9116) peering contact In-Reply-To: <20140618162946.C0B1256C2B@doar.tau.ac.il> References: <20140618162946.C0B1256C2B@doar.tau.ac.il> Message-ID: <70103BAA-2B87-4023-9B03-A7AF00499FF9@720.fr> Hello Hank, Many thanks for the hint. Best regards. > Le 18 juin 2014 à 18:29, Hank Nussbacher a écrit : > > Try ISP_NITUR at 012.net. They recently merged with another ISP and many addresses stopped working. This one still works and should hopefully lead to someone with a clue there. > > Hank > >> On Jun 18, 2014 9:59 AM, Youssef Bengelloun-Zahr wrote: >> >> Dear All, >> >> I'm looking for a valid peering contact for 012 Smile Telecom AS9116 (aka >> Golden-Lines/Internet-Gold/012 Smile Communications). Their public peering >> contact isn't working. >> >> If one their peering admins is watching, please contact me privatly. >> >> Best regards. >> >> >> >> -- >> Youssef BENGELLOUN-ZAHR From owen at delong.com Wed Jun 18 17:40:08 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2014 10:40:08 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <20140618165617.GB21878@excession.tpb.net> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <20140618165617.GB21878@excession.tpb.net> Message-ID: <253C41A3-70C4-4319-8D0A-8BD016BEC372@delong.com> On Jun 18, 2014, at 09:56 , Niels Bakker wrote: > * mail at martingeddes.com (Martin Geddes) [Wed 18 Jun 2014, 18:17 CEST]: >> It may never become the defacto standard, period. Nearly 20 years to reach >> 2% penetration is a strong hint that the costs outweigh the benefits. The 2% number is also not particularly meaningful. Traffic levels as measured by Google are closer to 4%, but even that doesn't tell the whole story. The total deployment of IPv6 is probably much closer to 15-25% globally. The astonishingly lower traffic figures are a result of the following likely factors: 1. They represent the intersection of client AND servers that are IPv6 enabled. 2. They are further reduced by happy eyeballs often preferring IPv4 even when IPv6 would work. 3. End user and enterprise adoption is lagging, even where IPv6 could be fully deployed in minutes without any harm. > Never before have we run out of IPv4 address space, so this time may well be different, now that an actual need for change is developing. Indeed. A time is coming when new content and services will be unable to be deployed on IPv4 due to lack of number resources. Once that starts to occur, IPv6 becomes the only viable alternative. The question at this point is not whether IPv6 will become the de facto standard, but how much pain we will inflict on the general public in that transition process. If we deploy IPv6 ubiquitously before we reach that point, then the pain of transition can be minimized. If we fail to do so, then the transition will be abrupt, painful, and very disruptive. Unfortunately, this is a classic recipe for the tragedy of the commons. We must all act in our mutual best interest deploying IPv6, or, we will all suffer together. Sadly, those who deploy IPv6 later will suffer the least at first and what happens in the long run remains to be seen. Owen From seth.mos at dds.nl Wed Jun 18 17:45:30 2014 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 18 Jun 2014 19:45:30 +0200 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> Message-ID: <7C7B3A12-C0E8-4995-B330-45F0DF00FD83@dds.nl> Op 18 jun. 2014, om 11:41 heeft Martin Geddes het volgende geschreven: > "IPv6 will never become the defacto standard until the vast majority of > users have access to IPv6 connectivity." > > It may never become the defacto standard, period. Nearly 20 years to reach > 2% penetration is a strong hint that the costs outweigh the benefits. To be fair, it is only now that there is considerable leverage to actually use IPv6 outside of a academic scope. Our company is ready now, and it’s just a commercial retailer. I know we are way ahead of the curve but I didn’t find it all that hard. I see a lot of people crying foul, still, but IPv6 capable equipment is readily available now, and, it is up to you if you find it worthwhile to purchase. The worldwide IPv6 transit network is complete and most ISPs can actually deliver on IPv6 if you push them for it and don’t let them ship you off with „we can’t do it yet”. As such we’ve had IPv6 at work since 2012, and we got to talk to engineers and it wasn’t really that much of a problem. Also, the free BGP tunnel from HE.net really is a lifesaver in getting at least backup peering in place, and that worked fine for over a year. > IP's global addressing system is broken from the outset. See John Day's > presentation "Surviving Networking’s Dark Ages - or How in the Hell Do You > Lose a Layer!?" > (or, > indeed, lots of them at once.) I don’t know, 64 bits for the networks, and 64 bits for the hosts seems fine, although to be fair, a 96/32 split could have worked too, more about networks and aggregated routes, less about hosts. It’s also really good that there is a „absolute split” at 64 bits to designate the network prefix part. That makes network identifying a lot easier. I suppose that is where the shorter network prefix is coming from, it’s easier to remember. > It's really all about scopes, not layers - the TCP/IP architecture is > divided up the wrong way, and it will never be fixed. It's an escaped 1970s > lab experiment that was able to extract the statistical multiplexing gain > faster than rivals, but on a performance and security "buy now, pay later" > basis. I like that IPv6 is close enough to IPv4 that I can just run with it. That’s not a drawback. If you understand classless subnetting you can work with Ipv6. > May all your intentional semantics become operational, > Martin I didn’t find it all that hard to become operational. Not everything I have at work does IPv6, but that’s not really a requirement, is it? I don’t care enough for backwards compatability with IPv4, actually, I’m really glad it isn’t so failure states are much easier to diagnose. I can see how IPv4.2 SP2 would have subtle issues with IPv4.3 SP1, but there is a hot fix for that, but not for your model. SOL. Not very different if I must say. Cheers, Seth > > On 17 June 2014 23:12, Andrew Fried wrote: > >> IPv6 will never become the defacto standard until the vast majority of >> users have access to IPv6 connectivity. >> >> Everything I have at the colo is dual stacked, but I can't reach my own >> systems via IPv6 because my business class Verizon Fios connection is >> IPv4 *only*. Yes, Comcast is in the process of rolling out IPv6, but my >> Comcast circuit in Washington DC is IPv4 only. And I'd suspect that >> everyone with Time Warner, AT&T, Cox, etc are all in the same boat. >> >> Whether the reason for the lack of IPv6 deployment is laziness or an >> intentional omission on the part of large ISPs to protect their income >> from leasing IPv4 addresses doesn't matter to the vast majority of the >> end users; they simply can't access IPv6 via IPv4 only networks, >> without using some kludgy, complicated tunneling protocols. >> >> Andy >> >> -- >> Andrew Fried >> andrew.fried at gmail.com >> >> On 6/17/14, 5:48 PM, Jared Mauch wrote: >>> >>> On Jun 17, 2014, at 5:41 PM, Lee Howard wrote: >>> >>>> >>>> >>>> On 6/17/14 4:20 PM, "Jay Ashworth" wrote: >>>> >>>>> Here's what the general public is hearing: >>>> >>>> But only while they still have IPv4 addresses: >>>> ~$ dig AAAA arstechnica.com +short >>>> ~$ >>>> >>>> >>>> >>>>> >>>>> >>>>> >> http://arstechnica.com/information-technology/2014/06/with-the-americas-ru >>>>> nning-out-of-ipv4-its-official-the-internet-is-full/ >>>> >>>> >>>> Can't tech news sites *please* run dual stack while they're spouting >>>> end-of-IPv4 stories? >>> >>> >>> >>> I would love to see a few more properties do IPv6 by default, such as >> ARS, Twitter and a few others. After posting some links and being a log >> stalker last night the first 3 hits from non-bots were from users on IPv6 >> enabled networks. >>> >>> It does ring a bit hollow that these sites haven't gotten there when >> others (Google, Facebook) have already shown you can publish AAAA records >> with no adverse public impact. Making IPv6 available by default for users >> would be an excellent step. People like AT&T who control the 'attwifi' >> ssid could do NAT66 at their sites and provide similar service to the >> masses. With chains like Hilton, McDonalds, etc.. all having this >> available, it would push IPv6 very far almost immediately with no adverse >> impact compared to users IPv4 experience. >>> >>> - Jared >>> >> From owen at delong.com Wed Jun 18 18:05:32 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2014 11:05:32 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <20140618160751.59276.qmail@joyce.lan> References: <20140618160751.59276.qmail@joyce.lan> Message-ID: <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> On Jun 18, 2014, at 09:07 , John Levine wrote: >>> My cable company assigns my home network a /50. I can figure out what >>> to do with two of the /64s (wired and wireless networks), but I'm >>> currently stumped on the other 16,382 of them. ... > >> I figure that with the larger allocations to homes or offices the question >> isn't "how do I allocate all of these" but "how do I delegate chunks of >> this in a hierarchical manner." > > Or even, how do I allocate them at all. My D-Link wifi router can > pick up a /64 and route it to its own LAN (wired and wifi bridged) and > that's about it for IPv6 other than port filters to enable some > inbound connections. > > It runs Linux so I suppose I could put dd-wrt onto it, but that's more > fun than I have time for this week. Yes, but let's please not make network design decisions based on the limitations built into one of the cheapest routers on the market intended for the lowest of the lowest common denominators. There are many other examples of CPE that can make use of properly sized prefixes (/48 per end site) and there is no reason not to deploy these. I find the /50 particularly odd as it's not a nibble boundary and very close to /48. It's almost certain this is an operator who fails to grasp that they could have easily gotten a larger allocation from their RIR if they just asked for it and provided the appropriate justification in terms of giving /48s to their customers. OTOH, it's far better than those ridiculous providers that are screwing over their customers with /56s or even worse, /60s. Sad, really. Owen From owen at delong.com Wed Jun 18 18:17:29 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2014 11:17:29 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <7C7B3A12-C0E8-4995-B330-45F0DF00FD83@dds.nl> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <7C7B3A12-C0E8-4995-B330-45F0DF00FD83@dds.nl> Message-ID: <3BC1E2A4-5503-4499-BE87-133EF61458CC@delong.com> A thought exercise for folks that think we need more network bits or fewer host bits or whatever... If you went from 64/64 to 96/32, what would you do with all those additional network numbers? Would you still assign /48s to end-sites or would you move that down to /80? If you'd move that to /80, then do you really expect a need for more than 281,474,976,710,656 end sites? Consider this... The world population is 7.1 billion, and expected 10.1 billion by 2100 (UN estimates). Let's figure each person needs an end site for their place of business, their two cars, their home, their vacation home, and just for good measure, let's double that to be ultra-conservative. That's 10 end-sites per person or 101 billion end sites. 281,474 billion - 101 billion = 281,373 billion remaining /48s. Of course, since we're giving ISPs /32s, let's assume that each ISP serves only 256 customers and that we therefore have a 256x inefficiency. That means we would burn up 25,856 /48 equivalents, leaving only 255,618 extra /48s lying around. Owen On Jun 18, 2014, at 10:45 , Seth Mos wrote: > > Op 18 jun. 2014, om 11:41 heeft Martin Geddes het volgende geschreven: > >> "IPv6 will never become the defacto standard until the vast majority of >> users have access to IPv6 connectivity." >> >> It may never become the defacto standard, period. Nearly 20 years to reach >> 2% penetration is a strong hint that the costs outweigh the benefits. > > To be fair, it is only now that there is considerable leverage to actually use IPv6 outside of a academic scope. Our company is ready now, and it’s just a commercial retailer. I know we are way ahead of the curve but I didn’t find it all that hard. > > I see a lot of people crying foul, still, but IPv6 capable equipment is readily available now, and, it is up to you if you find it worthwhile to purchase. The worldwide IPv6 transit network is complete and most ISPs can actually deliver on IPv6 if you push them for it and don’t let them ship you off with „we can’t do it yet”. > > As such we’ve had IPv6 at work since 2012, and we got to talk to engineers and it wasn’t really that much of a problem. Also, the free BGP tunnel from HE.net really is a lifesaver in getting at least backup peering in place, and that worked fine for over a year. > >> IP's global addressing system is broken from the outset. See John Day's >> presentation "Surviving Networking’s Dark Ages - or How in the Hell Do You >> Lose a Layer!?" >> (or, >> indeed, lots of them at once.) > > I don’t know, 64 bits for the networks, and 64 bits for the hosts seems fine, although to be fair, a 96/32 split could have worked too, more about networks and aggregated routes, less about hosts. It’s also really good that there is a „absolute split” at 64 bits to designate the network prefix part. That makes network identifying a lot easier. I suppose that is where the shorter network prefix is coming from, it’s easier to remember. > >> It's really all about scopes, not layers - the TCP/IP architecture is >> divided up the wrong way, and it will never be fixed. It's an escaped 1970s >> lab experiment that was able to extract the statistical multiplexing gain >> faster than rivals, but on a performance and security "buy now, pay later" >> basis. > > I like that IPv6 is close enough to IPv4 that I can just run with it. That’s not a drawback. If you understand classless subnetting you can work with Ipv6. > >> May all your intentional semantics become operational, >> Martin > > I didn’t find it all that hard to become operational. Not everything I have at work does IPv6, but that’s not really a requirement, is it? > > I don’t care enough for backwards compatability with IPv4, actually, I’m really glad it isn’t so failure states are much easier to diagnose. I can see how IPv4.2 SP2 would have subtle issues with IPv4.3 SP1, but there is a hot fix for that, but not for your model. SOL. > > Not very different if I must say. > > Cheers, > Seth > > > >> >> On 17 June 2014 23:12, Andrew Fried wrote: >> >>> IPv6 will never become the defacto standard until the vast majority of >>> users have access to IPv6 connectivity. >>> >>> Everything I have at the colo is dual stacked, but I can't reach my own >>> systems via IPv6 because my business class Verizon Fios connection is >>> IPv4 *only*. Yes, Comcast is in the process of rolling out IPv6, but my >>> Comcast circuit in Washington DC is IPv4 only. And I'd suspect that >>> everyone with Time Warner, AT&T, Cox, etc are all in the same boat. >>> >>> Whether the reason for the lack of IPv6 deployment is laziness or an >>> intentional omission on the part of large ISPs to protect their income >>> from leasing IPv4 addresses doesn't matter to the vast majority of the >>> end users; they simply can't access IPv6 via IPv4 only networks, >>> without using some kludgy, complicated tunneling protocols. >>> >>> Andy >>> >>> -- >>> Andrew Fried >>> andrew.fried at gmail.com >>> >>> On 6/17/14, 5:48 PM, Jared Mauch wrote: >>>> >>>> On Jun 17, 2014, at 5:41 PM, Lee Howard wrote: >>>> >>>>> >>>>> >>>>> On 6/17/14 4:20 PM, "Jay Ashworth" wrote: >>>>> >>>>>> Here's what the general public is hearing: >>>>> >>>>> But only while they still have IPv4 addresses: >>>>> ~$ dig AAAA arstechnica.com +short >>>>> ~$ >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>> http://arstechnica.com/information-technology/2014/06/with-the-americas-ru >>>>>> nning-out-of-ipv4-its-official-the-internet-is-full/ >>>>> >>>>> >>>>> Can't tech news sites *please* run dual stack while they're spouting >>>>> end-of-IPv4 stories? >>>> >>>> >>>> >>>> I would love to see a few more properties do IPv6 by default, such as >>> ARS, Twitter and a few others. After posting some links and being a log >>> stalker last night the first 3 hits from non-bots were from users on IPv6 >>> enabled networks. >>>> >>>> It does ring a bit hollow that these sites haven't gotten there when >>> others (Google, Facebook) have already shown you can publish AAAA records >>> with no adverse public impact. Making IPv6 available by default for users >>> would be an excellent step. People like AT&T who control the 'attwifi' >>> ssid could do NAT66 at their sites and provide similar service to the >>> masses. With chains like Hilton, McDonalds, etc.. all having this >>> available, it would push IPv6 very far almost immediately with no adverse >>> impact compared to users IPv4 experience. >>>> >>>> - Jared >>>> >>> From Lee at asgard.org Wed Jun 18 18:25:54 2014 From: Lee at asgard.org (Lee Howard) Date: Wed, 18 Jun 2014 14:25:54 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <53A0BD36.5060703@gmail.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> Message-ID: On 6/17/14 6:12 PM, "Andrew Fried" wrote: >IPv6 will never become the defacto standard until the vast majority of >users have access to IPv6 connectivity. How many users have access to IPv6 connectivity? Since this is NANOG, let's talk about North America. Canada is way behind, just 0.4% deployment. The U.S. is one of the top countries, in both number of users and number of top web sites. Three of the big four U.S. ISPs have double-digit deployment. It's not the "vast majority" yet, because: 1. Older modems don't support IPv6 (older than, what, 2008?). As those churn, counts will rise. 2. Older gateways, especially consumer-owned retail devices, don't support IPv6. Churn would help, if new retail gateways supported IPv6. 3. The <10% of people with MacOS use IPv6 half the time (more or less) that it's available. I can't find statements right now, but I think those big three are all >90% deployed, if you don't count rolling trucks to replace modems. The >number of IPv6-capable users is several times higher than the number of >people actually using IPv6, and I don't know why. Verizon Wireless and T-Mobile have great IPv6 deployments, too, maybe a couple more years for older handsets to age out. Still, >50% of VzW LTE devices use IPv6 now. > >Everything I have at the colo is dual stacked, but I can't reach my own >systems via IPv6 because my business class Verizon Fios connection is >IPv4 *only*. Well there's your problem. > Yes, Comcast is in the process of rolling out IPv6, but my >Comcast circuit in Washington DC is IPv4 only. And I'd suspect that >everyone with Time Warner, AT&T, Cox, etc are all in the same boat. I think all of those companies offer IPv6 on their business-only services (e.g., fiber, ethernet, etc.). For access methods shared with residential users (i.e., DOCSIS, DSL), it's not rolled out yet. . . RSN. > >Whether the reason for the lack of IPv6 deployment is laziness or an >intentional omission on the part of large ISPs to protect their income >from leasing IPv4 addresses ISPs want to protect their income by continuing to turn up services. Lee >Andrew Fried >andrew.fried at gmail.com > >On 6/17/14, 5:48 PM, Jared Mauch wrote: >> >> On Jun 17, 2014, at 5:41 PM, Lee Howard wrote: >> >>> >>> >>> On 6/17/14 4:20 PM, "Jay Ashworth" wrote: >>> >>>> Here's what the general public is hearing: >>> >>> But only while they still have IPv4 addresses: >>> ~$ dig AAAA arstechnica.com +short >>> ~$ >>> >>> >>> >>>> >>>> >>>> >>>>http://arstechnica.com/information-technology/2014/06/with-the-americas >>>>-ru >>>> nning-out-of-ipv4-its-official-the-internet-is-full/ >>> >>> >>> Can't tech news sites *please* run dual stack while they're spouting >>> end-of-IPv4 stories? >> >> >> >> I would love to see a few more properties do IPv6 by default, such as >>ARS, Twitter and a few others. After posting some links and being a log >>stalker last night the first 3 hits from non-bots were from users on >>IPv6 enabled networks. >> >> It does ring a bit hollow that these sites haven't gotten there when >>others (Google, Facebook) have already shown you can publish AAAA >>records with no adverse public impact. Making IPv6 available by default >>for users would be an excellent step. People like AT&T who control the >>'attwifi' ssid could do NAT66 at their sites and provide similar service >>to the masses. With chains like Hilton, McDonalds, etc.. all having >>this available, it would push IPv6 very far almost immediately with no >>adverse impact compared to users IPv4 experience. >> >> - Jared >> > From dhubbard at dino.hostasaurus.com Wed Jun 18 18:28:59 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 18 Jun 2014 14:28:59 -0400 Subject: Opinions on Fortinet vs Palo Alto for 20+ Gbit firewalls? Message-ID: Just curious if anyone has working experience with Fortinet or Palo Alto in a layer 2 transparent bridging, asymmetric routing, dual stack, 20+ Gbit/sec, redundant firewall scenario? Would love opinions, pros/cons from real world experience, etc? Only thing I can really find is some criticism on Fortinet's IPS throughput figures that can be as much as half what they claim depending on the mix of signatures enabled. Thanks, David From johnl at iecc.com Wed Jun 18 18:44:58 2014 From: johnl at iecc.com (John R. Levine) Date: 18 Jun 2014 14:44:58 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: > I find the /50 particularly odd as it's not a nibble boundary and very > close to /48. It's almost certain this is an operator who fails to grasp > that they could have easily gotten a larger allocation from their RIR if > they just asked for it and provided the appropriate justification in > terms of giving /48s to their customers. OTOH, it's far better than > those ridiculous providers that are screwing over their customers with > /56s or even worse, /60s. It's Time-Warner, and they are not ignorant. I think they're experimenting. They are still working out bugs in their internal routing, since my v6 routes have an annoying habit of disappearing inside their network if I don't do a ping that passes through them every couple of minutes. Also, it may not actuallly be a /50. That's what their rwhois says, but I haven't done a tcpdump so I don't know what size they're actually offering me. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From trejrco at gmail.com Wed Jun 18 18:49:28 2014 From: trejrco at gmail.com (TJ) Date: Wed, 18 Jun 2014 14:49:28 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> Message-ID: On Wed, Jun 18, 2014 at 2:25 PM, Lee Howard wrote: > > Verizon Wireless and T-Mobile have great IPv6 deployments, too, maybe a > couple more years for older handsets to age out. Still, >50% of VzW LTE > devices use IPv6 now. > ISTR that every VZW LTE device is IPv6 ready/capable/connected, and that it is ~%50 of the _traffic_ that is IPv6 today. > > > >Everything I have at the colo is dual stacked, but I can't reach my own > >systems via IPv6 because my business class Verizon Fios connection is > >IPv4 *only*. > > Well there's your problem. > Yeah, Verizon and VZW are not the same animal ... FiOS *needs* to get their IPv6 house in order. Anyone have any information on that front ...? > > Yes, Comcast is in the process of rolling out IPv6, but my > >Comcast circuit in Washington DC is IPv4 only. And I'd suspect that > >everyone with Time Warner, AT&T, Cox, etc are all in the same boat. > > I think all of those companies offer IPv6 on their business-only services > (e.g., fiber, ethernet, etc.). For access methods shared with residential > users (i.e., DOCSIS, DSL), it's not rolled out yet. . . RSN. I believe Comcast has completed something like 90%+ of their IPv6 rollout, nationwide. Maybe more ... *(My residential circuit and business circuit, in different parts of Northern VA, are both native IPv6 out of the box.)* /TJ From danieldagan at gmail.com Wed Jun 18 18:26:48 2014 From: danieldagan at gmail.com (Daniel Dagan) Date: Wed, 18 Jun 2014 21:26:48 +0300 Subject: 012 Smile Telecom (AS9116) peering contact In-Reply-To: <70103BAA-2B87-4023-9B03-A7AF00499FF9@720.fr> References: <20140618162946.C0B1256C2B@doar.tau.ac.il> <70103BAA-2B87-4023-9B03-A7AF00499FF9@720.fr> Message-ID: Hi, I am with the relevant network team, feel free to contact off-list BR, Daniel Sent from my iPhone On 18 ביונ 2014, at 20:26, Youssef Bengelloun-Zahr wrote: > Hello Hank, > > Many thanks for the hint. > > Best regards. > > > >> Le 18 juin 2014 à 18:29, Hank Nussbacher a écrit : >> >> Try ISP_NITUR at 012.net. They recently merged with another ISP and many addresses stopped working. This one still works and should hopefully lead to someone with a clue there. >> >> Hank >> >>> On Jun 18, 2014 9:59 AM, Youssef Bengelloun-Zahr wrote: >>> >>> Dear All, >>> >>> I'm looking for a valid peering contact for 012 Smile Telecom AS9116 (aka >>> Golden-Lines/Internet-Gold/012 Smile Communications). Their public peering >>> contact isn't working. >>> >>> If one their peering admins is watching, please contact me privatly. >>> >>> Best regards. >>> >>> >>> >>> -- >>> Youssef BENGELLOUN-ZAHR From owen at delong.com Wed Jun 18 19:38:23 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2014 12:38:23 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> Message-ID: <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> > 2. Older gateways, especially consumer-owned retail devices, don't support > IPv6. Churn would help, if new retail gateways supported IPv6. Several do now. What are $CABLECO, $CE_STORES, etc. doing to make sure consumers choose these or at least realize the consequences of failing to choose them? Owen From wesley.george at twcable.com Wed Jun 18 19:42:01 2014 From: wesley.george at twcable.com (George, Wes) Date: Wed, 18 Jun 2014 15:42:01 -0400 Subject: Help with Confederation-RR-MPBGP In-Reply-To: <1403109098.19558.YahooMailNeo@web122502.mail.ne1.yahoo.com> References: <1402590320.65337.YahooMailNeo@web122505.mail.ne1.yahoo.com> <7092.1402591193@turing-police.cc.vt.edu> <539A1EF7.7090704@free.fr> <1403109098.19558.YahooMailNeo@web122502.mail.ne1.yahoo.com> Message-ID: On 6/18/14, 12:31 PM, "Philip Lavine" wrote: >I guess my question is, is it best practice to confederate or use a route >reflector > >Basically I want to know what an ISP would do, not a test in a LAB. One data point that you may find useful: If you find out later that you’ve chosen incorrectly the first time around, it is FAR easier to change *from* RRs *to* Confeds than it is to do the opposite. The AS migration tools that you’d normally use to handle moving routers from one ASN to another don’t work to migrate routers from a confed ASN to a normal iBGP ASN setup, probably because the BGP machinery doesn’t know what to do with the union of the changes those things make to BGP’s default behavior, so you’re stuck with trying to find the least bad flag day way to handle renumbering ASNs out of a confed. Doing it without major traffic impact is pretty difficult since most of the options involve nuking BGP and rebuilding it to punt routers from one ASN to another, and doing this on multiple routers simultaneously in order to minimize the time when BGP is offline on multiple devices due to ASN mismatches. Size of network of course matters when considering whether this is really a potential issue for you, but since you’re asking in terms of what an ISP would do vs what works in a lab, considering large scale rather than today’s scale when determining the exit strategy is pretty important. 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 Lee at asgard.org Wed Jun 18 19:49:33 2014 From: Lee at asgard.org (Lee Howard) Date: Wed, 18 Jun 2014 15:49:33 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: On 6/18/14 2:44 PM, "John R. Levine" wrote: >> I find the /50 particularly odd as it's not a nibble boundary and very >> close to /48. It's almost certain this is an operator who fails to >>grasp >> that they could have easily gotten a larger allocation from their RIR >>if >> they just asked for it and provided the appropriate justification in >> terms of giving /48s to their customers. OTOH, it's far better than >> those ridiculous providers that are screwing over their customers with >> /56s or even worse, /60s. > >It's Time-Warner, and they are not ignorant. I think they're >experimenting. They are still working out bugs in their internal >routing, >since my v6 routes have an annoying habit of disappearing inside their >network if I don't do a ping that passes through them every couple of >minutes. > >Also, it may not actuallly be a /50. That's what their rwhois says, but >I haven't done a tcpdump so I don't know what size they're actually >offering me. It's either a /64 or a /56 or a misconfiguration. Lee From Lee at asgard.org Wed Jun 18 19:57:49 2014 From: Lee at asgard.org (Lee Howard) Date: Wed, 18 Jun 2014 15:57:49 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> Message-ID: On 6/18/14 3:38 PM, "Owen DeLong" wrote: > >> 2. Older gateways, especially consumer-owned retail devices, don't >>support >> IPv6. Churn would help, if new retail gateways supported IPv6. > >Several do now. What are $CABLECO, $CE_STORES, etc. doing to make sure >consumers choose these or at least realize the consequences of failing to >choose them? http://www.timewarnercable.com/en/residential-home/support/topics/internet/ buy-your-modem.html http://mydeviceinfo.comcast.net/ http://www.businesswire.com/news/home/20140107006526/en/CEA-Selects-Safe-Dr iving-IPv6-Implementation-Standards#.U6HuqS_9q_s However, I also don't think consumer education is the answer: http://www.wleecoyote.com/blog/consumeraction.htm Summary: Until it is perfectly clear why a consumer needs IPv6, and what they need to do about it, consumer education will only cause fear and frustration, which will not be helpful. This is a technology problem, not a feature problem, and consumers shouldn't have to select which Internet to be on. Lee From owen at delong.com Wed Jun 18 20:09:16 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Jun 2014 13:09:16 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> Message-ID: > > However, I also don't think consumer education is the answer: > http://www.wleecoyote.com/blog/consumeraction.htm > Summary: Until it is perfectly clear why a consumer needs IPv6, and what > they need to do about it, consumer education will only cause fear and > frustration, which will not be helpful. This is a technology problem, not > a feature problem, and consumers shouldn't have to select which Internet > to be on. > > Lee > Short of consumer education, how do you expect to resolve the issue where $CONSUMER walks into $BIG_BOX_CE_STORE and says "I need a router, what's the cheapest one you have?" Whereupon $TEENAGER_MAKING_MINIMUM_WAGE who likely doesn't know DOCSIS 2 from DOCSIS 3, has no idea what IP actually is, and thinks that Data is an android from Star Trek says "Here, this Linksys thing is only $30." Unless/until we either get the stores to pull the IPv4-only stuff off their shelves or educate consumers, the continued deployment of additional incapable equipment will be a continuing problem. As bad as the situation is for cablemodems and residential gateways, at least there, an educated consumer can make a good choice. Now, consider DVRs, BluRay players, Receiver/Amplifiers, Televisions, etc. where there are, currently, no IPv6 capable choices available to the best of my knowledge. Owen From m.hallgren at free.fr Wed Jun 18 20:25:46 2014 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 18 Jun 2014 22:25:46 +0200 Subject: Help with Confederation-RR-MPBGP In-Reply-To: <1403109098.19558.YahooMailNeo@web122502.mail.ne1.yahoo.com> References: <1402590320.65337.YahooMailNeo@web122505.mail.ne1.yahoo.com> <7092.1402591193@turing-police.cc.vt.edu> <539A1EF7.7090704@free.fr> <1403109098.19558.YahooMailNeo@web122502.mail.ne1.yahoo.com> Message-ID: <53A1F5CA.10204@free.fr> Le 18/06/2014 18:31, Philip Lavine a écrit : > I guess my question is (sorry MPLS speak ahead) No harm, me I've always rather consifered MPLS as a service provider (like VPN, etc). > with 4 PE's on the edge running MP-BGP and ISIS & 4 P's in the > core running ISIS, is it best practice to confederate or use a route > reflector and make the PE's clients. MP-BGP for VPN, I guess? Or am I missing something in your case? If so, you use MPLS for services, right? Where do you hook up to 'the Internet'? This aside, I'd go the confederation way (only?) in case I see a potential future need to do amounts of by destination routing also within my network. I'd find it nicer than rushing down the RSVP lane (pending SR :-)) Makes some sense to you? > > Basically I want to know what an ISP would do, not a test in a LAB. > > Me, rarely had a lab for these kind of things, but quite often networks :-) Cheers, mh > > On Thursday, June 12, 2014 2:45 PM, Michael Hallgren > wrote: > > > > Le 12/06/2014 18:39, Valdis.Kletnieks at vt.edu > a écrit : > > > On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said: > >> need some guidance on best practices > > > > What the vendor says is best practices, or what people in the trenches > say? > > > >> Is it more efficient to use RR or Confederation? > > > > If option A is 2% more "efficient" than option B, but takes 10% > longer to > > deploy and causes 3% more SLA payouts to your customers when the added > > complexity causes a whoopsie, how much more work could you have gotten > done in > > the time you spent in an uncomfortable meeting explaining to upper > management > > why the whoopsie happened? > > > > (Sorry, it's been that sort of week :) > > > :-) > > Now, Philip, I think along the same path as Vladis: it depends... What > does > your physical or layer 2 network look like? How do you expect packets to > move around inside, and in and out, of that topology? You need policing? > How much and of what, etc, etc...? > > I'm quite often a fan of confed's, if the network is young thus ``easy'' > migration, but there are scenarios... Please provide more detail to this > mail > thread or one-to-one if you prefer. > > Cheers, > > mh > > > > > > > From mark.tinka at seacom.mu Wed Jun 18 21:10:15 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jun 2014 23:10:15 +0200 Subject: Help with Confederation-RR-MPBGP In-Reply-To: <1403109098.19558.YahooMailNeo@web122502.mail.ne1.yahoo.com> References: <1402590320.65337.YahooMailNeo@web122505.mail.ne1.yahoo.com> <539A1EF7.7090704@free.fr> <1403109098.19558.YahooMailNeo@web122502.mail.ne1.yahoo.com> Message-ID: <201406182310.15967.mark.tinka@seacom.mu> On Wednesday, June 18, 2014 06:31:38 PM Philip Lavine wrote: > I guess my question is (sorry MPLS speak ahead) with 4 > PE's on the edge running MP-BGP and ISIS & 4 P's in the > core running ISIS, is it best practice to confederate or > use a route reflector and make the PE's clients. > > Basically I want to know what an ISP would do, not a test > in a LAB. Route reflector. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bzs at world.std.com Wed Jun 18 21:15:03 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 18 Jun 2014 17:15:03 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> Message-ID: <21410.343.738034.2737@world.std.com> Not to mix this up but one of the main reasons I attended ICANN meetings over several years was an interest in the IPv4/IPv6 transition. To say interest was sparse is an under, er, over statement. There was a good session on legacy IPs, a topic more than marginally related, in Toronto in fall 2012, a few people here were there. Really, I can list them like that. I'd sit in on the "ISP" sessions, for years, but when they weren't talking about how to fill out travel reimbursement reports (Brussels) they were mostly talking about site takedowns for intellectual property violations and similar, very similar, trademark issues and domains, etc. In a nutshell the whole TLD thing and other registry/registrar and closely related business issues so dominated discussions it drowned everything else out about 99%. If I'd bring it up, shouldn't we be discussing what we can do as an organization about IPv4/IPv6?, I'd usually get a 1,000 mile stare like who let this guy in? I remember once being cut off with "oh, CGN will solve that (Sydney)." I realize RIRs are more directly involved in many ways but this should be, in my opinion, a high-priority global internet governance policy issue with RIRs implementing or enjoying the results, not driving the issue, or only as much as they can. Then again vis a vis ICANN you can say this about almost any issue not directly related to registry/registrar business matters. TL;DR: I think there's an exposure and public awareness problem, even with those who are chartered with being interested. -- -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 joelja at bogus.com Wed Jun 18 21:47:49 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 18 Jun 2014 14:47:49 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> Message-ID: <53A20905.1040509@bogus.com> On 6/18/14, 1:09 PM, Owen DeLong wrote: >> >> However, I also don't think consumer education is the answer: >> http://www.wleecoyote.com/blog/consumeraction.htm Summary: Until it >> is perfectly clear why a consumer needs IPv6, and what they need to >> do about it, consumer education will only cause fear and >> frustration, which will not be helpful. This is a technology >> problem, not a feature problem, and consumers shouldn't have to >> select which Internet to be on. >> >> Lee >> > > Short of consumer education, how do you expect to resolve the issue > where $CONSUMER walks into $BIG_BOX_CE_STORE and says "I need a > router, what's the cheapest one you have?" The $39.95 dlink on the endcap at frys and the $140 one with 802.11ac beam forming atennas and gig-e run the same v6 stack... > Whereupon $TEENAGER_MAKING_MINIMUM_WAGE who likely doesn't know > DOCSIS 2 from DOCSIS 3, has no idea what IP actually is, and thinks > that Data is an android from Star Trek says "Here, this Linksys thing > is only $30." the software stack isn't the source of price discrimination. > Unless/until we either get the stores to pull the IPv4-only stuff off > their shelves or educate consumers, the continued deployment of > additional incapable equipment will be a continuing problem. As bad > as the situation is for cablemodems and residential gateways, at > least there, an educated consumer can make a good choice. Now, > consider DVRs, BluRay players, Receiver/Amplifiers, Televisions, etc. > where there are, currently, no IPv6 capable choices available to the > best of my knowledge. this stuff ages out of the network or doesn't require ipv4 for the entirety of it's useful service life. turns out for example that smart-tv's generally aren't (smart). Your appletv does support v6 as do many of those android sticks even if they're sufficiently inexpensive enough to be disposable. > Owen > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 286 bytes Desc: OpenPGP digital signature URL: From matthew at matthew.at Wed Jun 18 21:43:18 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 18 Jun 2014 14:43:18 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> Message-ID: <3BA39514-DD73-4FC5-A309-481530F2C003@matthew.at> My Apple TV appears to use IPv6, but since there's no UI for it (last I checked) I had to disable SLAAC on that subnet to keep it from trying to use my slow connection. So in my book, "some" v6 support is actually worse than "none" Matthew Kaufman (Sent from my iPhone) On Jun 18, 2014, at 1:09 PM, Owen DeLong wrote: >> >> However, I also don't think consumer education is the answer: >> http://www.wleecoyote.com/blog/consumeraction.htm >> Summary: Until it is perfectly clear why a consumer needs IPv6, and what >> they need to do about it, consumer education will only cause fear and >> frustration, which will not be helpful. This is a technology problem, not >> a feature problem, and consumers shouldn't have to select which Internet >> to be on. >> >> Lee > > Short of consumer education, how do you expect to resolve the issue where $CONSUMER walks into $BIG_BOX_CE_STORE and says "I need a router, what's the cheapest one you have?" > > Whereupon $TEENAGER_MAKING_MINIMUM_WAGE who likely doesn't know DOCSIS 2 from DOCSIS 3, has no idea what IP actually is, and thinks that Data is an android from Star Trek says "Here, this Linksys thing is only $30." > > Unless/until we either get the stores to pull the IPv4-only stuff off their shelves or educate consumers, the continued deployment of additional incapable equipment will be a continuing problem. As bad as the situation is for cablemodems and residential gateways, at least there, an educated consumer can make a good choice. Now, consider DVRs, BluRay players, Receiver/Amplifiers, Televisions, etc. where there are, currently, no IPv6 capable choices available to the best of my knowledge. > > Owen > From wesley.george at twcable.com Wed Jun 18 23:02:15 2014 From: wesley.george at twcable.com (George, Wes) Date: Wed, 18 Jun 2014 19:02:15 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> Message-ID: On 6/18/14, 4:09 PM, "Owen DeLong" wrote: >> >>Now, consider DVRs, BluRay players, Receiver/Amplifiers, Televisions, >>etc. where there are, currently, no IPv6 capable choices available to >>the best of my knowledge. I think this thread exemplifies a problem among the IPv6 early adopters who like to whine about the rate of adoption: the best of (y)our knowledge is likely stale, because things are changing constantly. People are fond of trotting out the same arguments they’ve been making for years about who is at fault for IPv6’s weak adoption without actually verifying that the issue still exists or is as bad as last time they looked i.e. ISP deployment levels, level of support in equipment, etc. Not saying that all the problems are solved, or that they didn’t contribute to the issue in the past, but the “guy walks into a big box store” tale of woe might be a bit exaggerated now. The problem now is that because IPv6 isn’t a feature most customers ask for, a product’s support for it (or lack thereof) is not consistently published in the vendor specs. For example: in ~September 2013 I was pleasantly surprised to find (via some colleagues observing it in the UI) that a number of current Sony TVs and BluRay players do in fact support IPv6, but at the time, it wasn’t listed as a feature on their model info on the site. Haven’t checked to see if it’s there now. @sonysupportusa on twitter has been helpful when asked questions about specific models’ IPv6 support, but as I told them, there’s really no substitute for having the info on the site. It’s not complete *cough* PS4 *cough* but they’re getting there. Similarly, Belkin’s home routers appear to support IPv6, but that doesn’t appear in the specs or features list on their site when I just checked it. I support a recommendation to consumer retailers to start requiring IPv6 support in the stuff that they sell, but unfortunately I don’t have very good data on how large of a request that actually is. 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 marka at isc.org Wed Jun 18 23:01:42 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 19 Jun 2014 09:01:42 +1000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: Your message of "Wed, 18 Jun 2014 13:09:16 -0700." References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> Message-ID: <20140618230142.329381876235@rock.dv.isc.org> In message , Owen DeLong write s: > >=20 > > However, I also don't think consumer education is the answer: > > http://www.wleecoyote.com/blog/consumeraction.htm > > Summary: Until it is perfectly clear why a consumer needs IPv6, and = > what > > they need to do about it, consumer education will only cause fear and > > frustration, which will not be helpful. This is a technology problem, = > not > > a feature problem, and consumers shouldn't have to select which = > Internet > > to be on. > >=20 > > Lee > >=20 > > Short of consumer education, how do you expect to resolve the issue = > where $CONSUMER walks into $BIG_BOX_CE_STORE and says "I need a router, = > what's the cheapest one you have?" > > Whereupon $TEENAGER_MAKING_MINIMUM_WAGE who likely doesn't know DOCSIS 2 = > from DOCSIS 3, has no idea what IP actually is, and thinks that Data is = > an android from Star Trek says "Here, this Linksys thing is only $30." > > Unless/until we either get the stores to pull the IPv4-only stuff off = > their shelves or educate consumers, the continued deployment of = > additional incapable equipment will be a continuing problem. As bad as = > the situation is for cablemodems and residential gateways, at least = > there, an educated consumer can make a good choice. Now, consider DVRs, = > BluRay players, Receiver/Amplifiers, Televisions, etc. where there are, = > currently, no IPv6 capable choices available to the best of my = > knowledge. > > Owen IPv6 is out there but you only seem get it in the quad radio boxes along with the corresponding price tag. We are already seeing reports of consumers complaining because they can't get a unshared IPv4 address when they move providers from DSL to Fibre and it breaks what they were doing on the DSL line. In this case it was DS-Lite providing the shared address but CGN or NAT64+DNS64 would also be a problem. The NAS box was no longer reachable because the other side was IPv4 only. I suspect this is the start of a long line of complaints because ISP's have been too slow in delivering IPv6 to *everyone* so that people are isolated from each other protocol wise. Note it is not like you have not been told for years that this day is coming. Mark -- 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 Wed Jun 18 23:26:35 2014 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 19 Jun 2014 09:26:35 +1000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> Message-ID: <1403133995.3347.167.camel@karl> On Wed, 2014-06-18 at 19:02 -0400, George, Wes wrote: > Similarly, Belkin’s home routers appear to support IPv6, but that doesn’t > appear in the specs or features list on their site when I just checked it. There's also an issue of what "IPv6 support" actually means. A few years ago it meant "has IPv6 printed on the box" :-) Now it means - what? For wireless or IPv4 support in such devices, the whole side of the box is covered with RFC numbers and protocol names (or the marketing names thereof). Even RIP gets a mention! But on the matter of what exactly the IPv6 support is, the box is often silent or very terse. Which makes buying a home device for use in an IPv6 environment very tricky - essentially you have to either spend hours researching, or you have to make sure the store will accept the product back if it doesn't work as you need it to. Someone who knows exactly what they are talking about can ask e.g., "does it support DHCPv6-PD?", but that's effectively impossible for most people - they can't articulate the actual features needed, they just want it to "just work". Sigh, one of many barriers still to fall... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From md1clv at md1clv.com Wed Jun 18 23:37:04 2014 From: md1clv at md1clv.com (Daniel Ankers) Date: Thu, 19 Jun 2014 00:37:04 +0100 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: On 18 June 2014 19:05, Owen DeLong wrote: > OTOH, it's far better than those ridiculous providers that are screwing > over their customers with /56s or even worse, /60s. > > Sad, really. > > Owen > > Is giving a /56 to residential customers REALLY "screwing them over"? It may be a failure of imagination on my part, but I'm struggling to come up with use cases for the home which would take up even 10% of the networks available in a /56. And if the vast, vast majority of home users will never come close to needing the whole of a /56 then I don't see why every home should be given a /48. Dan From james.cutler at consultant.com Wed Jun 18 23:52:46 2014 From: james.cutler at consultant.com (James R Cutler) Date: Wed, 18 Jun 2014 19:52:46 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: <3BCE4914-3952-43E1-886A-F1C710969B84@consultant.com> On Jun 18, 2014, at 7:37 PM, Daniel Ankers wrote: > On 18 June 2014 19:05, Owen DeLong wrote: > >> OTOH, it's far better than those ridiculous providers that are screwing >> over their customers with /56s or even worse, /60s. >> >> Sad, really. >> >> Owen >> >> > Is giving a /56 to residential customers REALLY "screwing them over"? > > It may be a failure of imagination on my part, but I'm struggling to come > up with use cases for the home which would take up even 10% of the networks > available in a /56. And if the vast, vast majority of home users will > never come close to needing the whole of a /56 then I don't see why every > home should be given a /48. > > Dan Responding to Dan, The costs incurred in managing variable subnetting based on user type have been clearly demonstrated in almost two decades of IPv4 networking. If I can assign a /48 to each and every customer (not considered a large enterprise) then my deployment costs plummet because I do NOT need to spend engineering time on address assignment. I only need to get out my Network Engineer’s binary knife to slice the address pie once. The same front office that takes the order can at the same time assign the IPv6 Prefix - sort of like Ma Bell does with phone numbers. Since one of my goals as a network provider is to be competitive in price, minimizing extraneous labor costs helps me to still make a modest profit. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gary.buhrmaster at gmail.com Wed Jun 18 23:57:32 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 18 Jun 2014 23:57:32 +0000 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: On Wed, Jun 18, 2014 at 11:37 PM, Daniel Ankers wrote: > On 18 June 2014 19:05, Owen DeLong wrote: > >> OTOH, it's far better than those ridiculous providers that are screwing >> over their customers with /56s or even worse, /60s. >> >> Sad, really. >> >> Owen >> >> > Is giving a /56 to residential customers REALLY "screwing them over"? Maybe, maybe not (it is, as much else, about perceptions) but /60 certainly seems to be "screwing them over", and a /56 is the minimum would should see (with the ability to request at least up to a /48) IMHO. HIPnet ( http://tools.ietf.org/html/draft-grundemann-homenet-hipnet ) suggests that a /56 is the minimum one should expect in order to support multiple sub-delegations within the residence. Some $CABLECOs$ appear to be delegating only a /60 to residential customers (even though some of those same $CABLECOs$ have participated in the project; I guess that just proves the left hand and the right hand do not talk). Gary From mark.tinka at seacom.mu Thu Jun 19 05:45:41 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jun 2014 07:45:41 +0200 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> Message-ID: <201406190745.45600.mark.tinka@seacom.mu> On Thursday, June 19, 2014 01:02:15 AM George, Wes wrote: > For example: in ~September 2013 I was pleasantly > surprised to find (via some colleagues observing it in > the UI) that a number of current Sony TVs and BluRay > players do in fact support IPv6, but at the time, it > wasn’t listed as a feature on their model info on the > site. Haven’t checked to see if it’s there now. > @sonysupportusa on twitter has been helpful when asked > questions about specific models’ IPv6 support, but as I > told them, there’s really no substitute for having the > info on the site. It’s not complete *cough* PS4 *cough* > but they’re getting there. > Similarly, Belkin’s home routers appear to support IPv6, > but that doesn’t appear in the specs or features list on > their site when I just checked it. Perhaps the folk at Sony and Belkin "think" IPv6 is mainstream and not worth making a big fuss over :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From owen at delong.com Thu Jun 19 10:52:29 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2014 03:52:29 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: On Jun 18, 2014, at 4:37 PM, Daniel Ankers wrote: > On 18 June 2014 19:05, Owen DeLong wrote: > OTOH, it's far better than those ridiculous providers that are screwing over their customers with /56s or even worse, /60s. > > Sad, really. > > Owen > > > Is giving a /56 to residential customers REALLY "screwing them over"? > > It may be a failure of imagination on my part, but I'm struggling to come up with use cases for the home which would take up even 10% of the networks available in a /56. And if the vast, vast majority of home users will never come close to needing the whole of a /56 then I don't see why every home should be given a /48. > > Dan Yes… It’s not about the number of subnets, it’s about having enough bits wide to automate a hierarchy. 8 bits only allows 1x8 or 2x4, while 16 bits allows significantly more flexibility in topology. Owen From owen at delong.com Thu Jun 19 11:01:21 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2014 04:01:21 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <21410.343.738034.2737@world.std.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <21410.343.738034.2737@world.std.com> Message-ID: ICANN != a good sampling of number resource issues or concerns. As you noticed, the whole mess with domain names and their IP issues is the monetary tail that wags the ICANN dog. ICANN barely pays attention to number resources and when they do, it’s primarily to do whatever has been agreed upon by the policy processes in the various RIRs. This is actually a good thing and we should seek to preserve this fact after ICANN loses its “adult supervision”. Owen On Jun 18, 2014, at 2:15 PM, Barry Shein wrote: > > Not to mix this up but one of the main reasons I attended ICANN > meetings over several years was an interest in the IPv4/IPv6 > transition. > > To say interest was sparse is an under, er, over statement. > > There was a good session on legacy IPs, a topic more than marginally > related, in Toronto in fall 2012, a few people here were there. > > Really, I can list them like that. > > I'd sit in on the "ISP" sessions, for years, but when they weren't > talking about how to fill out travel reimbursement reports (Brussels) > they were mostly talking about site takedowns for intellectual > property violations and similar, very similar, trademark issues and > domains, etc. > > In a nutshell the whole TLD thing and other registry/registrar and > closely related business issues so dominated discussions it drowned > everything else out about 99%. > > If I'd bring it up, shouldn't we be discussing what we can do as an > organization about IPv4/IPv6?, I'd usually get a 1,000 mile stare like > who let this guy in? I remember once being cut off with "oh, CGN will > solve that (Sydney)." > > I realize RIRs are more directly involved in many ways but this should > be, in my opinion, a high-priority global internet governance policy > issue with RIRs implementing or enjoying the results, not driving the > issue, or only as much as they can. > > Then again vis a vis ICANN you can say this about almost any issue not > directly related to registry/registrar business matters. > > > TL;DR: I think there's an exposure and public awareness problem, even > with those who are chartered with being interested. > > > -- > -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 owen at delong.com Thu Jun 19 11:13:41 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2014 04:13:41 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> Message-ID: <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> On Jun 18, 2014, at 4:02 PM, George, Wes wrote: > > On 6/18/14, 4:09 PM, "Owen DeLong" wrote: > >>> >>> Now, consider DVRs, BluRay players, Receiver/Amplifiers, Televisions, >>> etc. where there are, currently, no IPv6 capable choices available to >>> the best of my knowledge. > > I think this thread exemplifies a problem among the IPv6 early adopters > who like to whine about the rate of adoption: the best of (y)our knowledge > is likely stale, because things are changing constantly. People are fond > of trotting out the same arguments they’ve been making for years about who > is at fault for IPv6’s weak adoption without actually verifying that the > issue still exists or is as bad as last time they looked i.e. ISP > deployment levels, level of support in equipment, etc. Not saying that all > the problems are solved, or that they didn’t contribute to the issue in > the past, but the “guy walks into a big box store” tale of woe might be a > bit exaggerated now. I actually tend to pay pretty close attention to the current state of these things. Do you know of any of the above devices that are IPv6 capable? Nobody anywhere earlier in the thread has offered one. Note I left gaming consoles out of the picture because there is now one on the market which does support IPv6 and another which I believe is likely to support it reasonably soon. So while your argument has some legitimacy and I’ve seen many people do it, I don’t think it quite applies to my statement. > The problem now is that because IPv6 isn’t a feature most customers ask > for, a product’s support for it (or lack thereof) is not consistently > published in the vendor specs. Sure, but that argument seems to support my idea that consumer education is now necessary. > For example: in ~September 2013 I was pleasantly surprised to find (via > some colleagues observing it in the UI) that a number of current Sony TVs > and BluRay players do in fact support IPv6, but at the time, it wasn’t > listed as a feature on their model info on the site. Haven’t checked to > see if it’s there now. Interesting… I will look into that. FWIW, my conversations with Sony presages support over their 800 number in December had them telling me that there were no Sony products that supported IPv6 at this time, but that they were considering putting it on their road map. I will admit that I am lazy enough that once a vendor tells me they don’t support something, I don’t dig too much deeper to try and prove them wrong. > @sonysupportusa on twitter has been helpful when asked questions about > specific models’ IPv6 support, but as I told them, there’s really no > substitute for having the info on the site. It’s not complete *cough* PS4 > *cough* but they’re getting there. > Similarly, Belkin’s home routers appear to support IPv6, but that doesn’t > appear in the specs or features list on their site when I just checked it. Yes, many of the home gateways are starting to have undocumented IPv6 support and that situation is rapidly improving. Notice I also did not mention home gateways as a “no vendor support” issue. > I support a recommendation to consumer retailers to start requiring IPv6 > support in the stuff that they sell, but unfortunately I don’t have very > good data on how large of a request that actually is. In my experience, retailers will sell whatever flies off the shelves without regard to whether it’s good for the consumer or not. As such, I believe it’s more of a consumer education issue if we want to effect real change in behavior at this point. Owen From Lee at asgard.org Thu Jun 19 12:53:44 2014 From: Lee at asgard.org (Lee Howard) Date: Thu, 19 Jun 2014 08:53:44 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <003801cf8aa7$79a6a690$6cf3f3b0$@iname.com> References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> <20140617232402.0FC23185D08F@rock.dv.isc.org> <1ACF3587-2724-4A25-9042-95C7266F25B3@puck.nether.net> <003801cf8aa7$79a6a690$6cf3f3b0$@iname.com> Message-ID: On 6/17/14 11:43 PM, "Frank Bulk" wrote: >These sites used to be dual-stacked: >www.cablelabs.com (over 180 days ago via ipv6.cablelabs.com) >www.att.net (over 44 days ago) >www.charter.com (over 151 days) >www.globalcrossing.com (over 802 days) >www.timewarnercable.com (over 593 days) Check that one again. Surprised you didn't mention www.bing.com. Lee From Lee at asgard.org Thu Jun 19 14:02:22 2014 From: Lee at asgard.org (Lee Howard) Date: Thu, 19 Jun 2014 10:02:22 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> Message-ID: > > > >> I support a recommendation to consumer retailers to start requiring IPv6 >> support in the stuff that they sell, but unfortunately I don¹t have very >> good data on how large of a request that actually is. > >In my experience, retailers will sell whatever flies off the shelves >without >regard to whether it¹s good for the consumer or not. As such, I believe >it¹s >more of a consumer education issue if we want to effect real change in >behavior >at this point. What would you tell consumers? Lee > >Owen > > > From Lee at asgard.org Thu Jun 19 14:04:31 2014 From: Lee at asgard.org (Lee Howard) Date: Thu, 19 Jun 2014 10:04:31 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <1403133995.3347.167.camel@karl> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <1403133995.3347.167.camel@karl> Message-ID: On 6/18/14 7:26 PM, "Karl Auer" wrote: >On Wed, 2014-06-18 at 19:02 -0400, George, Wes wrote: >> Similarly, Belkin¹s home routers appear to support IPv6, but that >>doesn¹t >> appear in the specs or features list on their site when I just checked >>it. > >There's also an issue of what "IPv6 support" actually means. A few years >ago it meant "has IPv6 printed on the box" :-) Now it means - what? For gateways, the IPv6 CE Router is the spec to seek. For other electronics, the CEA is working on a spec, keep an eye out. Lee From mhuff at ox.com Thu Jun 19 14:52:58 2014 From: mhuff at ox.com (Matthew Huff) Date: Thu, 19 Jun 2014 14:52:58 +0000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> <20140617232402.0FC23185D08F@rock.dv.isc.org> <1ACF3587-2724-4A25-9042-95C7266F25B3@puck.nether.net> <003801cf8aa7$79a6a690$6cf3f3b0$@iname.com> Message-ID: Doesn't surprise me at all. Another thing I've seen lately is number of software (especially system management software) after being certified/tested with IPv6 no longer function when IPv6 is enabled. At least one vendor that broke IPv6 with a recent patch told me they only tested it once for IPv6 compatibility to get the marketing folks off their neck. After that, they no longer test with IPv6 since they don't have IPv6 internally. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lee Howard Sent: Thursday, June 19, 2014 8:54 AM To: Frank Bulk; 'Jared Mauch' Cc: NANOG Subject: Re: Ars Technica on IPv4 exhaustion On 6/17/14 11:43 PM, "Frank Bulk" wrote: >These sites used to be dual-stacked: >www.cablelabs.com (over 180 days ago via ipv6.cablelabs.com) >www.att.net (over 44 days ago) >www.charter.com (over 151 days) >www.globalcrossing.com (over 802 days) >www.timewarnercable.com (over 593 days) Check that one again. Surprised you didn't mention www.bing.com. Lee From lists at sadiqs.com Thu Jun 19 00:16:01 2014 From: lists at sadiqs.com (Sadiq Saif) Date: Wed, 18 Jun 2014 20:16:01 -0400 Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> Message-ID: <53A22BC1.6040500@sadiqs.com> On 6/18/2014 14:25, Lee Howard wrote: > Canada is way behind, just 0.4% deployment. Any Canadian ISP folk in here want to shine a light on this dearth of residential IPv6 connectivity? Is there any progress being made on this front? -- Sadiq Saif From earthurs at legacyinmate.com Thu Jun 19 01:13:50 2014 From: earthurs at legacyinmate.com (Edward Arthurs) Date: Wed, 18 Jun 2014 18:13:50 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <20140618230142.329381876235@rock.dv.isc.org> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> Message-ID: <02f701cf8b5b$bb477160$31d65420$@com> There are several obstacles to overcome, IMHO 1. The companies at the mid size and smaller levels have to invest in newer equipment that handles IPV6. 2. The network Admins at the above mentioned companies need to learn IPV6, most will want there company to pay the bill for this. 3. The vendors that make said equipment should lower the cost of said equipment to prompt said companies into purchasing said equipment. There is a huge difference between IPV4 and IPV6 and there will be a lot of network admins that simply do not want to learn or change there network. Thank You Edward Arthurs Manager of Network Installations Legacy Inmate Communications Legacy Contact Center Legacy Long Distance Intl. Inc 10833 Valley View Street Suite 150 Cypress, California 90630-5040 Office 1-800-577-5534 ext. 207 Direct 1-800-956-1595 Fax 1-714-827-7545 E-Mail: earthurs at legacyinmate.com E-Mail: legacyinstall at gmail.com This e-mail (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. If you received this e-mail in error, please delete it from your system without copying it and notify sender by reply e-mail, so that our records can be corrected. No trees were harmed as a result of this e-mail; however, many electrons were severely inconvenienced. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews Sent: Wednesday, June 18, 2014 4:02 PM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: Ars Technica on IPv4 exhaustion In message , Owen DeLong write s: > >=20 > > However, I also don't think consumer education is the answer: > > http://www.wleecoyote.com/blog/consumeraction.htm > > Summary: Until it is perfectly clear why a consumer needs IPv6, and > >= > what > > they need to do about it, consumer education will only cause fear > > and frustration, which will not be helpful. This is a technology > > problem, = > not > > a feature problem, and consumers shouldn't have to select which = > Internet > > to be on. > >=20 > > Lee > >=20 > > Short of consumer education, how do you expect to resolve the issue = > where $CONSUMER walks into $BIG_BOX_CE_STORE and says "I need a > router, = what's the cheapest one you have?" > > Whereupon $TEENAGER_MAKING_MINIMUM_WAGE who likely doesn't know DOCSIS > 2 = from DOCSIS 3, has no idea what IP actually is, and thinks that > Data is = an android from Star Trek says "Here, this Linksys thing is only $30." > > Unless/until we either get the stores to pull the IPv4-only stuff off > = their shelves or educate consumers, the continued deployment of = > additional incapable equipment will be a continuing problem. As bad as > = the situation is for cablemodems and residential gateways, at least > = there, an educated consumer can make a good choice. Now, consider > DVRs, = BluRay players, Receiver/Amplifiers, Televisions, etc. where > there are, = currently, no IPv6 capable choices available to the best > of my = knowledge. > > Owen IPv6 is out there but you only seem get it in the quad radio boxes along with the corresponding price tag. We are already seeing reports of consumers complaining because they can't get a unshared IPv4 address when they move providers from DSL to Fibre and it breaks what they were doing on the DSL line. In this case it was DS-Lite providing the shared address but CGN or NAT64+DNS64 would also be a problem. The NAS box was no longer reachable because the other side was IPv4 only. I suspect this is the start of a long line of complaints because ISP's have been too slow in delivering IPv6 to *everyone* so that people are isolated from each other protocol wise. Note it is not like you have not been told for years that this day is coming. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Curtis.Starnes at granburyisd.org Thu Jun 19 12:18:36 2014 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Thu, 19 Jun 2014 07:18:36 -0500 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: On 18 June 2014 19:05, Daniel Ankers replied: >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Ankers >Sent: Wednesday, June 18, 2014 6:37 PM >To: Owen DeLong; nanog at nanog.org list >Subject: Re: Credit to Digital Ocean for ipv6 offering > >On 18 June 2014 19:05, Owen DeLong wrote: > >> OTOH, it's far better than those ridiculous providers that are >> screwing over their customers with /56s or even worse, /60s. >> > >Sad, really. >> >> Owen >> >> >Is giving a /56 to residential customers REALLY "screwing them over"? > >It may be a failure of imagination on my part, but I'm struggling to come up with use cases for the home which would take up even 10% of the networks >available in a /56. And if the vast, vast majority of home users will never come close to needing the whole of a /56 then I don't see why every home should be >given a /48. > >Dan I have to agree with Dan on this one, Look at the numbers (especially for small to mid-sized business and residential): /56 = 256 /64's subnets /60 = 16 /64's subnets http://www.sixscape.com/joomla/sixscape/index.php/ipv6-training-certification/ipv6-forum-official-certification/ipv6-forum-network-engineer-silver/network-engineer-silver-ipv6-subnetting/ipv6-subnetting-general-subnetting At 18,446,744,073,709,551,616 per /64, that is a lot of address. Right now I cannot get IPv6 at home so I will take getting "screwed" with a /56 or /60 and be estatic about it. Curtis From bh at tronstar.com Thu Jun 19 15:27:18 2014 From: bh at tronstar.com (Brian Hartsfield) Date: Thu, 19 Jun 2014 11:27:18 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> Message-ID: For consumers I think I would phrase it more as the "next generation internet" and you need IPv6 in order to be able to connect to it and that eventually some sites you want to connect to may not be accessible over the current internet. Something like that. I am going to be real interested to see how the media handles the situation when ARIN runs out of IPv4 addresses. I could really see some big doom and gloom stories hit some of the mainstream media when that occurs. While it isn't the end of the world when ARIN runs out, it is still significant and I personally think that moment is going to be what starts to spur more CIOs to start asking questions about IPv6 and if their organization is ready (and the answer likely being no) -- Brian Hartsfield CCNA, CCDA AIM: kd4aej Twitter: Krandor1 Facebook: http://www.facebook.com/brian.hartsfield Linkedin: http://www.linkedin.com/in/brianhartsfield On Thu, Jun 19, 2014 at 10:02 AM, Lee Howard wrote: > > > > > > > >> I support a recommendation to consumer retailers to start requiring IPv6 > >> support in the stuff that they sell, but unfortunately I don¹t have very > >> good data on how large of a request that actually is. > > > >In my experience, retailers will sell whatever flies off the shelves > >without > >regard to whether it¹s good for the consumer or not. As such, I believe > >it¹s > >more of a consumer education issue if we want to effect real change in > >behavior > >at this point. > > What would you tell consumers? > > Lee > > > > >Owen > > > > > > > > > From johnl at iecc.com Thu Jun 19 17:13:41 2014 From: johnl at iecc.com (John Levine) Date: 19 Jun 2014 17:13:41 -0000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: Message-ID: <20140619171341.68106.qmail@joyce.lan> >Short of consumer education, how do you expect to resolve the issue where $CONSUMER walks into $BIG_BOX_CE_STORE >and says "I need a router, what's the cheapest one you have?" By making the answer "the cheapest is this FooTronics, but you're better off with this MegaBar. The FooTronics doesn't do IPv6 so it can't do X." Until there is an X that consumers care about, don't hold your breath. I can tell you from experience that the only practical effect of IPv6 on my home cable service is to make things periodically slow and flaky when T-W's internal routing flakes. Wahoo. I only leave it turned on because I know people at T-W who are using the problem reports to debug it. R's, John From morrowc.lists at gmail.com Thu Jun 19 17:14:07 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Jun 2014 13:14:07 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <02f701cf8b5b$bb477160$31d65420$@com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> Message-ID: On Wed, Jun 18, 2014 at 9:13 PM, Edward Arthurs wrote: > There are several obstacles to overcome, IMHO > 1. The companies at the mid size and smaller levels have to invest in newer > equipment that handles IPV6. if they have gear made in the last 7yrs it's likely already got the right bits for v6 support, right? > 2. The network Admins at the above mentioned companies need to learn IPV6, > most will want there company to pay the bill for this. for a large majority of the use cases it's just "configure that other family on the interface" and done. > 3. The vendors that make said equipment should lower the cost of said > equipment to prompt said companies into purchasing said equipment. the equipment in question does both v4 and v6 ... so why lower pricing? (also, see 'if made in the last 7 yrs, it's already done and you probably don't have to upgrade') > There is a huge difference between IPV4 and IPV6 and there will be a lot of 'huge difference' ... pls quantify this. (unless you just mean colons instead of periods and letters in the address along with numbers) From Valdis.Kletnieks at vt.edu Thu Jun 19 17:19:24 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Jun 2014 13:19:24 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: Your message of "Thu, 19 Jun 2014 07:18:36 -0500." References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: <7770.1403198364@turing-police.cc.vt.edu> On Thu, 19 Jun 2014 07:18:36 -0500, "STARNES, CURTIS" said: > At 18,446,744,073,709,551,616 per /64, that is a lot of address. > Right now I cannot get IPv6 at home so I will take getting "screwed" with a /56 or /60 and be estatic about it. My WNDR3800 running cerowrt is quite able to use up the /60 Comcast hands me (it burns 6 /64s by default the instant you turn it on, and can burn more if you start doing VLAN'ing or other config stuff). If I had a second one that wanted to auto-delegate via PD, I'd need a /56 and be screwed with just the /60. Fortunately for my home networking needs, none of my 3.9 cats are particularly internet-savvy.... -------------- 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 Thu Jun 19 17:34:24 2014 From: Lee at asgard.org (Lee Howard) Date: Thu, 19 Jun 2014 13:34:24 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> Message-ID: From: Brian Hartsfield Date: Thursday, June 19, 2014 11:27 AM To: Lee Howard Cc: Owen DeLong , Wesley George , "nanog at nanog.org" Subject: Re: Ars Technica on IPv4 exhaustion > For consumers I think I would phrase it more as the "next generation internet" > and you need IPv6 in order to be able to connect to it and that eventually > some sites you want to connect to may not be accessible over the current > internet. Something like that. Ah, it's running Internet-As-A-Service in the Cloud using a Client-Server architecture with time sharing. There's nothing there but buzzwords. First figure out what consumers actually get for it. Only after you know why they want it can you then figure out how to market it. Generally what you're looking for is "good, fast, cheap," only more so than IPv4. Lee > > I am going to be real interested to see how the media handles the situation > when ARIN runs out of IPv4 addresses. I could really see some big doom and > gloom stories hit some of the mainstream media when that occurs. While it > isn't the end of the world when ARIN runs out, it is still significant and I > personally think that moment is going to be what starts to spur more CIOs to > start asking questions about IPv6 and if their organization is ready (and the > answer likely being no) > > -- > Brian Hartsfield CCNA, CCDA > AIM: kd4aej Twitter: Krandor1 > Facebook: http://www.facebook.com/brian.hartsfield > Linkedin: http://www.linkedin.com/in/brianhartsfield > > > On Thu, Jun 19, 2014 at 10:02 AM, Lee Howard wrote: >>> > >>> > >>> > >>>> >> I support a recommendation to consumer retailers to start requiring IPv6 >>>> >> support in the stuff that they sell, but unfortunately I don¹t have very >>>> >> good data on how large of a request that actually is. >>> > >>> >In my experience, retailers will sell whatever flies off the shelves >>> >without >>> >regard to whether it¹s good for the consumer or not. As such, I believe >>> >it¹s >>> >more of a consumer education issue if we want to effect real change in >>> >behavior >>> >at this point. >> >> What would you tell consumers? >> >> Lee >> >>> > >>> >Owen >>> > >>> > >>> > >> >> > From streiner at cluebyfour.org Thu Jun 19 14:55:06 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 19 Jun 2014 10:55:06 -0400 (EDT) Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> Message-ID: On Thu, 19 Jun 2014, Brian Hartsfield wrote: > I am going to be real interested to see how the media handles the situation > when ARIN runs out of IPv4 addresses. I could really see some big doom > and gloom stories hit some of the mainstream media when that occurs. While > it isn't the end of the world when ARIN runs out, it is still significant > and I personally think that moment is going to be what starts to spur more > CIOs to start asking questions about IPv6 and if their organization is > ready (and the answer likely being no) IPv4 doom and gloom is just more irresponsible/un-informed journalism. ARIN getting close to running out of IPv4 addresses is not news. That this would eventually happen has been known for a very long time. Entities choosing to keep their heads in the sand and ignore that fact is another matter altogether. Were there (m)any "OMG WE'RE OUT OF IP ADDRESSES!!!1!111" articles when APNIC throttled final assignments down to one /22 per organization after they dipped into their last /8? Were there (m)any when RIPE got down to their last /8 jms From wmaton at ottix.net Thu Jun 19 17:45:17 2014 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Thu, 19 Jun 2014 13:45:17 -0400 (EDT) Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: <53A22BC1.6040500@sadiqs.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: On Wed, 18 Jun 2014, Sadiq Saif wrote: > On 6/18/2014 14:25, Lee Howard wrote: >> Canada is way behind, just 0.4% deployment. > > Any Canadian ISP folk in here want to shine a light on this dearth of > residential IPv6 connectivity? > > Is there any progress being made on this front? Teksavvy does it (tunnel I believe) if you ask. Otherwise it's the usual: - 'why do we need this?'; - 'It costs money to upgrade for something low-demand'; - 'What's the market?'; - 'I don't have time'; - 'Aw gee do I have to??' wfms From deleskie at gmail.com Thu Jun 19 17:48:39 2014 From: deleskie at gmail.com (jim deleskie) Date: Thu, 19 Jun 2014 14:48:39 -0300 Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: Those all sounds like legit business questions. -jim On Thu, Jun 19, 2014 at 2:45 PM, William F. Maton Sotomayor < wmaton at ottix.net> wrote: > On Wed, 18 Jun 2014, Sadiq Saif wrote: > > On 6/18/2014 14:25, Lee Howard wrote: >> >>> Canada is way behind, just 0.4% deployment. >>> >> >> Any Canadian ISP folk in here want to shine a light on this dearth of >> residential IPv6 connectivity? >> >> Is there any progress being made on this front? >> > > Teksavvy does it (tunnel I believe) if you ask. > > Otherwise it's the usual: > > - 'why do we need this?'; > - 'It costs money to upgrade for something low-demand'; > - 'What's the market?'; > - 'I don't have time'; > - 'Aw gee do I have to??' > > wfms > From bzs at world.std.com Thu Jun 19 17:51:06 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 19 Jun 2014 13:51:06 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <21410.343.738034.2737@world.std.com> Message-ID: <21411.8970.191029.86423@world.std.com> On June 19, 2014 at 04:01 owen at delong.com (Owen DeLong) wrote: > ICANN != a good sampling of number resource issues or concerns. > > As you noticed, the whole mess with domain names and their IP issues > is the monetary tail that wags the ICANN dog. ICANN barely pays attention > to number resources and when they do, it�s primarily to do whatever has > been agreed upon by the policy processes in the various RIRs. > > This is actually a good thing and we should seek to preserve this fact > after ICANN loses its �adult supervision�. Really. You're really completely discounting ICANN in having any leadership or participative role in the IPv4/IPv6 transition? Interesting. -- -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 streiner at cluebyfour.org Thu Jun 19 15:11:45 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 19 Jun 2014 11:11:45 -0400 (EDT) Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> Message-ID: On Thu, 19 Jun 2014, Christopher Morrow wrote: >> 2. The network Admins at the above mentioned companies need to learn IPV6, >> most will want there company to pay the bill for this. > > for a large majority of the use cases it's just "configure that other > family on the interface" and done. In the simplest cases, yes. Throw things that often exist in mid to large sized enterprises, like firewalls, DHCP servers, load balancers, log analyzers, etc, having to upgrade $XYZ to get IPv6 support or fix bugs, and there's a bit more to it. These are not insurmountable problems, but administrative/political/financial inertia is a real thing in many shops. >> 3. The vendors that make said equipment should lower the cost of said >> equipment to prompt said companies into purchasing said equipment. > > the equipment in question does both v4 and v6 ... so why lower pricing? > (also, see 'if made in the last 7 yrs, it's already done and you > probably don't have to upgrade') There could be problems with things like DHCPv6, depending on how the user's ISP provisions service. SLAAC 'just works' for the most part, but if the FooTronics 1000 an all-in-one router/firewall/wireless AP/printer/ belt sander/toaster from $BIGBOXSTORE doesn't come with firewall settings that let IPv6 work just out of the box, or at least have a big, shiny "Make IPv6 work" button, support calls will be generated. ISPs and FooTronics both hate support calls. Again, playing devil's advocate here. I just don't look forward to dealing with support calls from customers who bought kit from vendors who slammed in IPv6 support as quickly and cheaply as possible. jms From earthurs at legacyinmate.com Thu Jun 19 17:53:20 2014 From: earthurs at legacyinmate.com (Edward Arthurs) Date: Thu, 19 Jun 2014 10:53:20 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> Message-ID: <044a01cf8be7$5bf605f0$13e211d0$@com> Thank You for responding. If mid to small companies have equipment made in the last 7 years, they will not need to replace equipment. Most net admins at the mid to small companies have no idea about IPV6. Cost is a major consideration at the mid to small size companies, if they need to upgrade equipment. The difference between IPV4 and IPV6 for someone not familiar is huge, 1. There is a totally new format dotted decimal to colon. 2. The 32 bit to 128 bit is/or can be quite challenging for some net admins. Thank You -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Thursday, June 19, 2014 10:14 AM To: Edward Arthurs Cc: nanog list Subject: Re: Ars Technica on IPv4 exhaustion On Wed, Jun 18, 2014 at 9:13 PM, Edward Arthurs wrote: > There are several obstacles to overcome, IMHO 1. The companies at the > mid size and smaller levels have to invest in newer equipment that > handles IPV6. if they have gear made in the last 7yrs it's likely already got the right bits for v6 support, right? > 2. The network Admins at the above mentioned companies need to learn > IPV6, most will want there company to pay the bill for this. for a large majority of the use cases it's just "configure that other family on the interface" and done. > 3. The vendors that make said equipment should lower the cost of said > equipment to prompt said companies into purchasing said equipment. the equipment in question does both v4 and v6 ... so why lower pricing? (also, see 'if made in the last 7 yrs, it's already done and you probably don't have to upgrade') > There is a huge difference between IPV4 and IPV6 and there will be a > lot of 'huge difference' ... pls quantify this. (unless you just mean colons instead of periods and letters in the address along with numbers) From gabe at teksavvy.ca Thu Jun 19 17:56:04 2014 From: gabe at teksavvy.ca (Gabriel Blanchard) Date: Thu, 19 Jun 2014 13:56:04 -0400 Subject: Canada and IPv6 In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: <53A32434.6000200@teksavvy.ca> On 14-06-19 01:45 PM, William F. Maton Sotomayor wrote: > On Wed, 18 Jun 2014, Sadiq Saif wrote: > >> On 6/18/2014 14:25, Lee Howard wrote: >>> Canada is way behind, just 0.4% deployment. >> >> Any Canadian ISP folk in here want to shine a light on this dearth of >> residential IPv6 connectivity? >> >> Is there any progress being made on this front? > > Teksavvy does it (tunnel I believe) if you ask. > We offer IPv6 over DSL and it's native, but it's opt-in at the moment. I have the ability to enable it for all our DSL users but we're holding off due to training issues more than anything. -Gabe From morrowc.lists at gmail.com Thu Jun 19 17:57:24 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Jun 2014 13:57:24 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <21411.8970.191029.86423@world.std.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <21410.343.738034.2737@world.std.com> <21411.8970.191029.86423@world.std.com> Message-ID: On Thu, Jun 19, 2014 at 1:51 PM, Barry Shein wrote: > > Really. You're really completely discounting ICANN in having any > leadership or participative role in the IPv4/IPv6 transition? > What leadership position have you seen them take ASIDE from marketing (in the last 2-3 yrs, but most of that has been ISOC not ICANN directly) in the last 5 yrs or so? -chris From Valdis.Kletnieks at vt.edu Thu Jun 19 17:57:12 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Jun 2014 13:57:12 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: Your message of "Thu, 19 Jun 2014 13:51:06 -0400." <21411.8970.191029.86423@world.std.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <21410.343.738034.2737@world.std.com> <21411.8970.191029.86423@world.std.com> Message-ID: <9913.1403200632@turing-police.cc.vt.edu> On Thu, 19 Jun 2014 13:51:06 -0400, Barry Shein said: > Really. You're really completely discounting ICANN in having any > leadership or participative role in the IPv4/IPv6 transition? Haven't seen any yet. Probably because you can't make money with IP addresses like you can with TLD's.... (Now where's my Nomex overalls? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From md1clv at md1clv.com Thu Jun 19 18:02:45 2014 From: md1clv at md1clv.com (Daniel Ankers) Date: Thu, 19 Jun 2014 19:02:45 +0100 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: On 19 June 2014 13:18, STARNES, CURTIS wrote: > > I have to agree with Dan on this one, > Look at the numbers (especially for small to mid-sized business and > residential): > > /56 = 256 /64's subnets > /60 = 16 /64's subnets > > http://www.sixscape.com/joomla/sixscape/index.php/ipv6-training-certification/ipv6-forum-official-certification/ipv6-forum-network-engineer-silver/network-engineer-silver-ipv6-subnetting/ipv6-subnetting-general-subnetting > > At 18,446,744,073,709,551,616 per /64, that is a lot of address. > Right now I cannot get IPv6 at home so I will take getting "screwed" with > a /56 or /60 and be estatic about it. > > Curtis > One of the key things with IPv6 (IMHO) is to stop thinking about addresses, and instead just think about networks. Judging by Owen's earlier mail I may not have that quite right and the key might even be to think about hierarchies - in either case counting the number of individual addresses is something we just don't need to do any more. Dan From laszlo at heliacal.net Thu Jun 19 18:04:35 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Thu, 19 Jun 2014 18:04:35 +0000 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: On Jun 19, 2014, at 12:18 PM, "STARNES, CURTIS" wrote: > > At 18,446,744,073,709,551,616 per /64, that is a lot of address. > Right now I cannot get IPv6 at home so I will take getting "screwed" with a /56 or /60 and be estatic about it. > > Curtis > > > Would be nice if everyone kept it simple and just stuck to /48s though. It's complicated enough without everyone deploying different prefix sizes. Even the /64 net/host split isn't standard enough. Think of something like DHCP - if there's an understanding that it's 'standard' then you can build software/hardware around this assumption and provide an easy to use system, without forcing the user to make sub-netting decisions. Making software that works with this necessarily has to involve a complex UI and if certain unusual combinations don't work then people cry that it doesn't support IPv6. The way that it's standard to receive one IPv4 address by DHCP and you can just plug in a laptop, imagine if in a few years it was standard to receive a /48 IPv6 prefix on the local router and end user devices can request as many /64s as they want. You could assign a /64 to each app on your cell phone or computer.. and this could happen automatically when possible. Maybe an app wants many /64s, that's fine too. We've gotten used to multiplexing everything onto a single overloaded address because it's a scarce resource. In IPv6 addresses are not scarce and in time this can be leveraged to simplify applications. Yes, you can overload a single address, we do it all the time in IPv4 with proxies and NATs. There are even hacks for having multiple SSL websites on one IPv4 address. These things came about because the addresses are scarce but it's not correct to use the same justifications in IPv6 where the unique addresses are practically unlimited. If we have to assume that /64s might be scarce and they have to be manually managed, then applications end up having to ask that question and configuration becomes complex. If we know we can get at least a few hundred of them dynamically anywhere we go, then we only have to bother the user when we run out, and things 'just work'. -Laszlo From Valdis.Kletnieks at vt.edu Thu Jun 19 18:04:39 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Jun 2014 14:04:39 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: Your message of "Thu, 19 Jun 2014 10:53:20 -0700." <044a01cf8be7$5bf605f0$13e211d0$@com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> Message-ID: <10424.1403201079@turing-police.cc.vt.edu> On Thu, 19 Jun 2014 10:53:20 -0700, "Edward Arthurs" said: > If mid to small companies have equipment made in the last 7 years, they will > not need to replace equipment. > Most net admins at the mid to small companies have no idea about IPV6. In other words, upgrading or replacing liveware is more expensive than getting the hardware upgraded.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Thu Jun 19 18:07:16 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Jun 2014 14:07:16 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> Message-ID: On Thu, Jun 19, 2014 at 11:11 AM, Justin M. Streiner wrote: > On Thu, 19 Jun 2014, Christopher Morrow wrote: > >>> 2. The network Admins at the above mentioned companies need to learn >>> IPV6, >>> most will want there company to pay the bill for this. >> >> >> for a large majority of the use cases it's just "configure that other >> family on the interface" and done. > > > In the simplest cases, yes. Throw things that often exist in mid to large > sized enterprises, like firewalls, DHCP servers, load balancers, log sure thing, except that the poster did not talk about mid/large enterprises, his point was about small ones... where v6 probably doesn't matter for things listed except firewalls. > analyzers, etc, having to upgrade $XYZ to get IPv6 support or fix bugs, and > there's a bit more to it. These are not insurmountable problems, but > administrative/political/financial inertia is a real thing in many shops. > > >>> 3. The vendors that make said equipment should lower the cost of said >>> equipment to prompt said companies into purchasing said equipment. >> >> >> the equipment in question does both v4 and v6 ... so why lower pricing? >> (also, see 'if made in the last 7 yrs, it's already done and you >> probably don't have to upgrade') > > > There could be problems with things like DHCPv6, depending on how the user's > ISP provisions service. SLAAC 'just works' for the most part, but if the > FooTronics 1000 an all-in-one router/firewall/wireless AP/printer/ > belt sander/toaster from $BIGBOXSTORE doesn't come with firewall settings > that let IPv6 work just out of the box, or at least have a big, shiny "Make > IPv6 work" button, support calls will be generated. ISPs and FooTronics > both hate support calls. sure. > Again, playing devil's advocate here. I just don't look forward to dealing > with support calls from customers who bought kit from vendors who slammed in > IPv6 support as quickly and cheaply as possible. yup. I sort of don't think the arguement about 'business connections' is even relevant though. I'd bet that the vast majority of connections to the 'net are actually consumer ones... Fixing those shoudl be the goal for the ISP side, so they can continue to grow customer bases without worrying about CGN and other associated expenses. Once you solve out the consumer problems the business link ones should 'just work'. Whether the enterprise wants to upgrade/install/side-step into v6 is not relevant. From md1clv at md1clv.com Thu Jun 19 18:07:48 2014 From: md1clv at md1clv.com (Daniel Ankers) Date: Thu, 19 Jun 2014 19:07:48 +0100 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: <7770.1403198364@turing-police.cc.vt.edu> References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> <7770.1403198364@turing-police.cc.vt.edu> Message-ID: On 19 June 2014 18:19, wrote: > > My WNDR3800 running cerowrt is quite able to use up the /60 Comcast hands me > (it burns 6 /64s by default the instant you turn it on, and can burn more > if > you start doing VLAN'ing or other config stuff). > > How does it use those 6 /64s? That seems to be getting towards the interesting times where the way devices work with v6 is very different to how they would have worked with v6 From morrowc.lists at gmail.com Thu Jun 19 18:22:29 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Jun 2014 14:22:29 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <044a01cf8be7$5bf605f0$13e211d0$@com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> Message-ID: On Thu, Jun 19, 2014 at 1:53 PM, Edward Arthurs wrote: > The difference between IPV4 and IPV6 for someone not familiar is huge, > 1. There is a totally new format dotted decimal to colon. > 2. The 32 bit to 128 bit is/or can be quite challenging for some net admins. these seem like the smallest of v6 problems, actually... and I would bet: http://getipv6.info would be helpful (eventually when small/mid-sized businesses start trying to transition) From jfbeam at gmail.com Thu Jun 19 18:27:39 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 19 Jun 2014 14:27:39 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <3BC1E2A4-5503-4499-BE87-133EF61458CC@delong.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <7C7B3A12-C0E8-4995-B330-45F0DF00FD83@dds.nl> <3BC1E2A4-5503-4499-BE87-133EF61458CC@delong.com> Message-ID: On Wed, 18 Jun 2014 14:17:29 -0400, Owen DeLong wrote: > Let's figure each person needs an end site for their place of business, > their two cars, their home, their vacation home, and just for good > measure, let's double that to be ultra-conservative. That's 10 end-sites > per person or 101 billion end sites. Can we stop with the lame "every person, and their dog!" numbering plans. The same MISTAKE has been repeated so many times in recent history you'd think people would know better. It's the exact same wrong-think that was applied to the 32bit IPv4 addressing in an era where there were a few dozen computers worldwide. (also that IPv4 was an "experiment" that was never imagined to be this big.) We're smart enough to mis-manage *any* resource. It's just a matter of "when" that it'll be back to haunt us. ("not within my lifetime" seems to be a very popular compromise.) From earthurs at legacyinmate.com Thu Jun 19 18:32:28 2014 From: earthurs at legacyinmate.com (Edward Arthurs) Date: Thu, 19 Jun 2014 11:32:28 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> Message-ID: <049501cf8bec$d3b85750$7b2905f0$@com> You are correct, but this is the tip of the iceberg as other configurations will need to come into play as pointed out by several people on this thread. This learning curve is not impossible, if the net admin really applies his/her self to learning it. Thank You -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Thursday, June 19, 2014 11:22 AM To: Edward Arthurs Cc: nanog list Subject: Re: Ars Technica on IPv4 exhaustion On Thu, Jun 19, 2014 at 1:53 PM, Edward Arthurs wrote: > The difference between IPV4 and IPV6 for someone not familiar is huge, > 1. There is a totally new format dotted decimal to colon. > 2. The 32 bit to 128 bit is/or can be quite challenging for some net admins. these seem like the smallest of v6 problems, actually... and I would bet: http://getipv6.info would be helpful (eventually when small/mid-sized businesses start trying to transition) From alter3d at alter3d.ca Thu Jun 19 18:34:54 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Thu, 19 Jun 2014 14:34:54 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> <7770.1403198364@turing-police.cc.vt.edu> Message-ID: <53A32D4E.4060109@alter3d.ca> On 06/19/2014 02:07 PM, Daniel Ankers wrote: > On 19 June 2014 18:19, wrote: > >> > My WNDR3800 running cerowrt is quite able to use up the /60 Comcast hands me >> (it burns 6 /64s by default the instant you turn it on, and can burn more >> if >> you start doing VLAN'ing or other config stuff). >> >> > How does it use those 6 /64s? That seems to be getting towards the > interesting times where the way devices work with v6 is very different to > how they would have worked with v6 - Public IP - DMZ IP - Management IP - Russian backdoor IP - Chinese backdoor IP - NSA backdoor IP :) From jcurran at arin.net Thu Jun 19 18:35:55 2014 From: jcurran at arin.net (John Curran) Date: Thu, 19 Jun 2014 18:35:55 +0000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> Message-ID: <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> On Jun 19, 2014, at 11:27 AM, Brian Hartsfield wrote: > ... While it isn't the end of the world when ARIN runs out, it is still significant > and I personally think that moment is going to be what starts to spur more CIOs to > start asking questions about IPv6 and if their organization is ready (and the answer > likely being no) Brian - Any suggestions on how ARIN should reach those CIO's in the meantime? (so as to reduce the number who experience such surprise) We've done some attempts at outreach to that community, and have advice from PR firms, etc., but I'm interested in a more "real world" perspective on getting their attention before we hit the wall... Thanks! /John John Curran President and CEO ARIN From james.cutler at consultant.com Thu Jun 19 18:41:47 2014 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 19 Jun 2014 14:41:47 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> Message-ID: On Jun 19, 2014, at 2:02 PM, Daniel Ankers wrote: > One of the key things with IPv6 (IMHO) is to stop thinking about addresses, > and instead just think about networks. Judging by Owen's earlier mail I > may not have that quite right and the key might even be to think about > hierarchies - in either case counting the number of individual addresses is > something we just don't need to do any more. > > Dan s/think about networks/think about subnetworks (colloquial: LAN Segments)/ With IPv6, the number of hosts in a subnet is (should be) no longer a driver for addressing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lost at l-w.ca Thu Jun 19 16:45:49 2014 From: lost at l-w.ca (William Astle) Date: Thu, 19 Jun 2014 10:45:49 -0600 Subject: Canada and IPv6 In-Reply-To: <53A22BC1.6040500@sadiqs.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: <53A313BD.4080001@l-w.ca> On 14-06-18 06:16 PM, Sadiq Saif wrote: > On 6/18/2014 14:25, Lee Howard wrote: >> Canada is way behind, just 0.4% deployment. > > Any Canadian ISP folk in here want to shine a light on this dearth of > residential IPv6 connectivity? For that matter, how about on the other side of the equation. Why is it that certain large networks operating data centres in Canada do not provide IPv6 to all of said data centres? (I'm looking at you, AS701.) From chk at pobox.com Thu Jun 19 18:48:50 2014 From: chk at pobox.com (Harald Koch) Date: Thu, 19 Jun 2014 14:48:50 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> <7770.1403198364@turing-police.cc.vt.edu> Message-ID: On 19 June 2014 14:07, Daniel Ankers wrote: > > How does it use those 6 /64s? That seems to be getting towards the > interesting times where the way devices work with v6 is very different to > how they would have worked with v6 > Bridging between (slow) 802.11 and (fast) ethernet is hard to do right, so CeroWRT configures all interfaces as separate LANs and routes between them instead. It does this on the IPv4 side too; it's not specific to IPv6. This breaks a lot of things (like Apple Bonjour), so I'm not convinced it's a *useful* technique for home networks. -- Harald From morrowc.lists at gmail.com Thu Jun 19 18:50:30 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Jun 2014 14:50:30 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <049501cf8bec$d3b85750$7b2905f0$@com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> <049501cf8bec$d3b85750$7b2905f0$@com> Message-ID: On Thu, Jun 19, 2014 at 2:32 PM, Edward Arthurs wrote: > You are correct, but this is the tip of the iceberg as other configurations will need to come into play as pointed out by several people on this thread. > This learning curve is not impossible, if the net admin really applies his/her self to learning it. > I'd still say that for uptake across the board the mid/small business (and even large business) isn't relevant. The numbers of these are so small as to be insignificant to the problem. Solving the problem for end-users seems like where ISP folk should spend their time, and really it's in their best interest to do that so they can keep expanding their customer base as ipv4 resources become less available in their networks and globally. From bh at tronstar.com Thu Jun 19 19:02:14 2014 From: bh at tronstar.com (Brian Hartsfield) Date: Thu, 19 Jun 2014 15:02:14 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> Message-ID: That is a good question and I wish I had a good answer. I'm trying to beat the drums where I work for IPv6 and it is tough because nobody has thought about it and in our situation I actuallly have a good case. We develop mobile apps and with the amount of IPv6 VZW and T-mobile are doing having at least IPv6 to the load balancer at least needs to be thought about. It is just tough because most organizations have just not been thinking about IPv6 at all and it is going to take "something" to get it on their radar. -- Brian Hartsfield CCNA, CCDA AIM: kd4aej Twitter: Krandor1 Facebook: http://www.facebook.com/brian.hartsfield Linkedin: http://www.linkedin.com/in/brianhartsfield On Thu, Jun 19, 2014 at 2:35 PM, John Curran wrote: > On Jun 19, 2014, at 11:27 AM, Brian Hartsfield wrote: > > > ... While it isn't the end of the world when ARIN runs out, it is still > significant > > and I personally think that moment is going to be what starts to spur > more CIOs to > > start asking questions about IPv6 and if their organization is ready > (and the answer > > likely being no) > > Brian - > > Any suggestions on how ARIN should reach those CIO's in the meantime? > (so as to reduce the number who experience such surprise) We've done > some attempts at outreach to that community, and have advice from PR > firms, etc., but I'm interested in a more "real world" perspective on > getting their attention before we hit the wall... > > Thanks! > /John > > John Curran > President and CEO > ARIN > > From streiner at cluebyfour.org Thu Jun 19 16:21:12 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 19 Jun 2014 12:21:12 -0400 (EDT) Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <7C7B3A12-C0E8-4995-B330-45F0DF00FD83@dds.nl> <3BC1E2A4-5503-4499-BE87-133EF61458CC@delong.com> Message-ID: On Thu, 19 Jun 2014, Ricky Beam wrote: > Can we stop with the lame "every person, and their dog!" numbering plans. The > same MISTAKE has been repeated so many times in recent history you'd think > people would know better. It's the exact same wrong-think that was applied to > the 32bit IPv4 addressing in an era where there were a few dozen computers > worldwide. (also that IPv4 was an "experiment" that was never imagined to be > this big.) How much IPv6 space would you propose an ISP provisions for each of its residential users? jms From bzs at world.std.com Thu Jun 19 19:59:34 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 19 Jun 2014 15:59:34 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <21410.343.738034.2737@world.std.com> <21411.8970.191029.86423@world.std.com> Message-ID: <21411.16678.353049.420269@world.std.com> But I thought ICANN was supposed to be the new and future nexus for all things internet governance? On June 19, 2014 at 13:57 morrowc.lists at gmail.com (Christopher Morrow) wrote: > On Thu, Jun 19, 2014 at 1:51 PM, Barry Shein wrote: > > > > Really. You're really completely discounting ICANN in having any > > leadership or participative role in the IPv4/IPv6 transition? > > > > What leadership position have you seen them take ASIDE from marketing > (in the last 2-3 yrs, but most of that has been ISOC not ICANN > directly) in the last 5 yrs or so? > > -chris -- -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 Valdis.Kletnieks at vt.edu Thu Jun 19 20:04:14 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Jun 2014 16:04:14 -0400 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: Your message of "Thu, 19 Jun 2014 19:07:48 +0100." References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> <7770.1403198364@turing-police.cc.vt.edu> Message-ID: <16670.1403208254@turing-police.cc.vt.edu> On Thu, 19 Jun 2014 19:07:48 +0100, Daniel Ankers said: > How does it use those 6 /64s? That seems to be getting towards the > interesting times where the way devices work with v6 is very different to > how they would have worked with v6 If I remember right, it's: Private net on the 2.4ghz radio Guest net on the 2.4ghz radio Private net on the 5ghz radio Guest net on the 5ghz radio Private net on the wired Ethernet Guest net on the wired Ethernet (It's a Linux kernel, 'ip link show' reports 22 interfaces. Yowza. ;) -------------- 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 Thu Jun 19 20:05:14 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Jun 2014 16:05:14 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: Your message of "Thu, 19 Jun 2014 15:59:34 -0400." <21411.16678.353049.420269@world.std.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <21410.343.738034.2737@world.std.com> <21411.8970.191029.86423@world.std.com> <21411.16678.353049.420269@world.std.com> Message-ID: <16777.1403208314@turing-police.cc.vt.edu> On Thu, 19 Jun 2014 15:59:34 -0400, Barry Shein said: > But I thought ICANN was supposed to be the new and future nexus for > all things internet governance? Oh, come on Barry. This isn't your first rodeo, and I know you're *way* too smart to believe that press releases align with reality... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jfbeam at gmail.com Thu Jun 19 20:27:41 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 19 Jun 2014 16:27:41 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> Message-ID: On Thu, 19 Jun 2014 14:35:55 -0400, John Curran wrote: > Any suggestions on how ARIN should reach those CIO's in the meantime? Refuse additional IPv4 assignments to those who have not deployed IPv6. And not just been assigned a v6 block, but actually running IPv6 to every customer who asks. (hard to police, sure.) NONE of my ISPs have been able to provide IPv6 over the last decade. That includes Verizon (aka UUNet), and AT&T (the not-Uverse-AT&T) who didn't get past the sales call when they made it clear we "aren't big enough to be connected to that gear." TWTC: No. Earthlink (ITC^D): No. TWC: No. (but my home connection is seeing RAs, but DHCPv6 instantly answers "no prefixes") AT&T Uverse (business): 6rd, not static, not available everywhere, and doesn't work every day. (also, those fools are eating protocol 41 at the border, so tunnels don't work.) And those are just the ISPs I directly deal with. That list gets longer if I include my employer's various ISPs around the globe. Heck, even the checkpoint in Hong Kong doesn't have IPv6. From Lee at asgard.org Thu Jun 19 20:27:46 2014 From: Lee at asgard.org (Lee Howard) Date: Thu, 19 Jun 2014 16:27:46 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> <049501cf8bec$d3b85750$7b2905f0$@com> Message-ID: On 6/19/14 2:50 PM, "Christopher Morrow" wrote: >On Thu, Jun 19, 2014 at 2:32 PM, Edward Arthurs > wrote: >> You are correct, but this is the tip of the iceberg as other >>configurations will need to come into play as pointed out by several >>people on this thread. >> This learning curve is not impossible, if the net admin really applies >>his/her self to learning it. >> > >I'd still say that for uptake across the board the mid/small business >(and even large business) isn't relevant. The numbers of these are so >small as to be insignificant to the problem. > >Solving the problem for end-users seems like where ISP folk should >spend their time, and really it's in their best interest to do that so >they can keep expanding their customer base as ipv4 resources become >less available in their networks and globally. How does IPv6 to end users make IPv4 unnecessary for growth, if enterprises and content providers haven't deployed IPv6? Lee From morrowc.lists at gmail.com Thu Jun 19 20:30:47 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Jun 2014 16:30:47 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> <049501cf8bec$d3b85750$7b2905f0$@com> Message-ID: On Thu, Jun 19, 2014 at 4:27 PM, Lee Howard wrote: > > How does IPv6 to end users make IPv4 unnecessary for growth, if > enterprises and content providers haven't deployed IPv6? content folk are mostly getting v6 done already, right? (minus AWS/etc which are on-plan to deploy as near as I can tell) I don't think enterprise folk matter here, they'll get to v6 when they have enough problems related to v4 content reachability... and when they try the ISP network ought to be prepared to deal with them. which content providers (large-ish ones) are lagging still? -chris From jfbeam at gmail.com Thu Jun 19 20:57:40 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 19 Jun 2014 16:57:40 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <7C7B3A12-C0E8-4995-B330-45F0DF00FD83@dds.nl> <3BC1E2A4-5503-4499-BE87-133EF61458CC@delong.com> Message-ID: On Thu, 19 Jun 2014 12:21:12 -0400, Justin M. Streiner wrote: > How much IPv6 space would you propose an ISP provisions for each of its > residential users? A single /64 would, currently, be sufficient for 99% of households. The link can be /128, /127, /64, whatever -- between ISP and CPE doesn't matter to the customer. (maybe to their equipment) As this is being done via DHCPv6-PD, it's a simple matter to ask for more space (typically /60) in the rare cases the customer needs it. And in a decade when 16 LANs isn't enough, allow /56's. If it weren't for stupid SLAAC and it's nanolathed-in-diamond prefix===64 requirement, we could start out - day one - with more reasonable sizes. Give everyone their own entire internet (::/96) to carve up as they wish. It's not like anything even on the whiteboard today can handle a fraction of that many devices in a single LAN. From jcurran at arin.net Thu Jun 19 21:02:42 2014 From: jcurran at arin.net (John Curran) Date: Thu, 19 Jun 2014 21:02:42 +0000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> Message-ID: <115E60CB-47B7-41A4-BE8D-79F88E281DBB@arin.net> On Jun 19, 2014, at 4:27 PM, Ricky Beam wrote: > On Thu, 19 Jun 2014 14:35:55 -0400, John Curran wrote: >> Any suggestions on how ARIN should reach those CIO's in the meantime? > > Refuse additional IPv4 assignments to those who have not deployed IPv6. And not just been assigned a v6 block, but actually running IPv6 to every customer who asks. (hard to police, sure.) > ... Ricky - You should consider submitting this as policy proposal Thanks! /John John Curran President and CEO ARIN From Lee at asgard.org Thu Jun 19 21:24:02 2014 From: Lee at asgard.org (Lee Howard) Date: Thu, 19 Jun 2014 17:24:02 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> <049501cf8bec$d3b85750$7b2905f0$@com> Message-ID: On 6/19/14 4:30 PM, "Christopher Morrow" wrote: >On Thu, Jun 19, 2014 at 4:27 PM, Lee Howard wrote: >> >> How does IPv6 to end users make IPv4 unnecessary for growth, if >> enterprises and content providers haven't deployed IPv6? > >content folk are mostly getting v6 done already, right? (minus AWS/etc >which are on-plan to deploy as near as I can tell) >I don't think enterprise folk matter here, they'll get to v6 when they >have enough problems related to v4 content reachability... and when >they try the ISP network ought to be prepared to deal with them. 7.94% Google hits in the U.S. come from IPv6 addresses. http://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-ad option 7.29% of web sites have a working AAAA. http://www.employees.org/~dwing/aaaa-stats/ > >which content providers (large-ish ones) are lagging still? https://www.vyncke.org/ipv6status/detailed.php?country=us Microsoft: live.com, Bing, MSN, microsoft.com Twitter Amazon LinkedIn WordPress eBay, PayPal Pinterest Instagram Ask.com Tumblr IMDB Craigs List Imgur Reddit CNN Disney, Go, ESPN GoDaddy HuffPo WordPress Adobe Vimeo Flickr Dropbox CNet BuzzFeed NYTimes Most porn sites (one has a dead AAAA). The web site of any TV channel, or any bank. Not to mention the million web pages at hosting providers. Lee From Lee at asgard.org Thu Jun 19 21:40:26 2014 From: Lee at asgard.org (Lee Howard) Date: Thu, 19 Jun 2014 17:40:26 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <115E60CB-47B7-41A4-BE8D-79F88E281DBB@arin.net> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> <115E60CB-47B7-41A4-BE8D-79F88E281DBB@arin.net> Message-ID: On 6/19/14 5:02 PM, "John Curran" wrote: >On Jun 19, 2014, at 4:27 PM, Ricky Beam wrote: > >> On Thu, 19 Jun 2014 14:35:55 -0400, John Curran >>wrote: >>> Any suggestions on how ARIN should reach those CIO's in the meantime? >> >> Refuse additional IPv4 assignments to those who have not deployed IPv6. >>And not just been assigned a v6 block, but actually running IPv6 to >>every customer who asks. (hard to police, sure.) >> ... > >Ricky - > > You should consider submitting this as policy proposal > I support the idea of new policy proposals, but by the time this made it through a policy cycle, ARIN would have run out of unallocated IPv4 addresses. A similar constraint could be applied to recipients of IPv4 transfers; the community would want to consider that very carefully. Would there be a similar constraint for CDNs, hosting companies, and cloud providers? btw, Ricky, if you want support in getting your proposal submitted, John will team you up with somebody on the superlative Advisory Council https://www.arin.net/about_us/ac.html, many of whom are watching this list. Lee From randy at psg.com Thu Jun 19 22:14:40 2014 From: randy at psg.com (Randy Bush) Date: Fri, 20 Jun 2014 07:14:40 +0900 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> Message-ID: > Any suggestions on how ARIN should reach those CIO's in the meantime? > (so as to reduce the number who experience such surprise) We've done > some attempts at outreach to that community, and have advice from PR > firms, etc., but I'm interested in a more "real world" perspective on > getting their attention before we hit the wall... for one, stop the scare tactics, "hitting the wall," etc. and cut the tea party fanaticism. how you acquire ipv4 space is likely to change and how much it costs you is very likely to change, and not for the better. they hear "the world is coming to an end" so often that they ignore it. they are very sensitive to "costs will go up." get geoff to do a one pager and see it is circulated randy From owen at delong.com Thu Jun 19 22:29:00 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2014 15:29:00 -0700 Subject: Credit to Digital Ocean for ipv6 offering In-Reply-To: References: <20140618160751.59276.qmail@joyce.lan> <7F41602E-5D3B-4218-A4FE-571F2D6233B6@delong.com> <7770.1403198364@turing-police.cc.vt.edu> Message-ID: <1E0E462F-F09D-4B08-8C77-CDE7C0FE8170@delong.com> On Jun 19, 2014, at 11:48 , Harald Koch wrote: > On 19 June 2014 14:07, Daniel Ankers wrote: > >> >> How does it use those 6 /64s? That seems to be getting towards the >> interesting times where the way devices work with v6 is very different to >> how they would have worked with v6 >> > > Bridging between (slow) 802.11 and (fast) ethernet is hard to do right, so > CeroWRT configures all interfaces as separate LANs and routes between them > instead. It does this on the IPv4 side too; it's not specific to IPv6. > > This breaks a lot of things (like Apple Bonjour), so I'm not convinced it's > a *useful* technique for home networks. > Bonjour can be fixed for the IPv6 environment simply by changing it's packets to be sent to ff05::... instead of ff02::... I presume that the CeroWRT (and any other properly functioning router) can be configured so that ff05:: packets are delivered to all interfaces within the site however the administrator defines "within the site". Owen From owen at delong.com Thu Jun 19 22:47:10 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2014 15:47:10 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> Message-ID: <4C91045B-6C3C-4383-88EE-BE52376BBF15@delong.com> On Jun 19, 2014, at 07:02 , Lee Howard wrote: >> >> >> >>> I support a recommendation to consumer retailers to start requiring IPv6 >>> support in the stuff that they sell, but unfortunately I don¹t have very >>> good data on how large of a request that actually is. >> >> In my experience, retailers will sell whatever flies off the shelves >> without >> regard to whether it¹s good for the consumer or not. As such, I believe >> it¹s >> more of a consumer education issue if we want to effect real change in >> behavior >> at this point. > > What would you tell consumers? I'm not entirely sure. I'm the first to admit that direct to consumer communications are not my specialty and that guidance/input from others that are more expert is welcome. Often the first step is identifying the problem and coming to consensus that consumer education is a vital part of the solution. Things I'd like to see get communicated to consumers: 1. The current addressing scheme for the internet is out of numbers and change is necessary. 2. Change has been in the works for several years, but has now reached the point where you (consumers) can benefit by paying attention and making intelligent and informed purchasing decisions. 3. There's plenty of vested interest out there that will happily take your money and leave you only on the old internet. Therefore, it is important to pay attention when choosing network equipment and other network-attached electronics. 4. New general purpose computers (desktop/laptop/tablet) are generally all compatible with the new protocol. 5. Only some routers/gateways/modems currently have IPv6 support. Ideally, it would be nice if the UNH/IOL and/or CEA could come up with a meaningful definition of IPv6 support and a logo to go with it that we could tell consumers to look for on the box. Ideally, this would be a set of standards that users of the logo agree to abide by rather than a fee-based testing regime that excludes smaller players. Obviously this is in a very rough form, but Lee's question is a legitimate one and deserves an answer. Hopefully in our collective talent pool, we can find ways to improve upon what I will say is a beginning straw man at best. Owen From owen at delong.com Thu Jun 19 22:52:45 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2014 15:52:45 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <21411.8970.191029.86423@world.std.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <21410.343.738034.2737@world.std.com> <21411.8970.191029.86423@world.std.com> Message-ID: On Jun 19, 2014, at 10:51 , Barry Shein wrote: > > On June 19, 2014 at 04:01 owen at delong.com (Owen DeLong) wrote: >> ICANN != a good sampling of number resource issues or concerns. >> >> As you noticed, the whole mess with domain names and their IP issues >> is the monetary tail that wags the ICANN dog. ICANN barely pays attention >> to number resources and when they do, it’s primarily to do whatever has >> been agreed upon by the policy processes in the various RIRs. >> >> This is actually a good thing and we should seek to preserve this fact >> after ICANN loses its “adult supervision”. > > Really. You're really completely discounting ICANN in having any > leadership or participative role in the IPv4/IPv6 transition? No. They have some role. They just don't have any leadership role and are not a point to apply any meaningful pressure. Owen From owen at delong.com Thu Jun 19 22:55:17 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2014 15:55:17 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <044a01cf8be7$5bf605f0$13e211d0$@com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> Message-ID: <43456EA1-0C1A-481C-A0D6-8E106BE5F555@delong.com> On Jun 19, 2014, at 10:53 , Edward Arthurs wrote: > Thank You for responding. > If mid to small companies have equipment made in the last 7 years, they will not need to replace equipment. > Most net admins at the mid to small companies have no idea about IPV6. > Cost is a major consideration at the mid to small size companies, if they need to upgrade equipment. > The difference between IPV4 and IPV6 for someone not familiar is huge, > 1. There is a totally new format dotted decimal to colon. > 2. The 32 bit to 128 bit is/or can be quite challenging for some net admins. I can get most network admins over both of those hurdles (and the other more meaningful ones) in a 45 minute training session. Yes, I've done so many times, so I know it works. For those with more complex needs, a two-day training course can take someone from marginally proficient in IPv4 to reasonably proficient in IPv6 for both Network and Systems administration. With a small amount of conceptual knowledge, the differences between IPv4 and IPv6 become very very small. Owen From owen at delong.com Thu Jun 19 22:58:44 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2014 15:58:44 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <7C7B3A12-C0E8-4995-B330-45F0DF00FD83@dds.nl> <3BC1E2A4-5503-4499-BE87-133EF61458CC@delong.com> Message-ID: <517FAD6D-4E88-4CE7-A32E-CCD554FE0613@delong.com> On Jun 19, 2014, at 11:27 , Ricky Beam wrote: > On Wed, 18 Jun 2014 14:17:29 -0400, Owen DeLong wrote: >> Let's figure each person needs an end site for their place of business, their two cars, their home, their vacation home, and just for good measure, let's double that to be ultra-conservative. That's 10 end-sites per person or 101 billion end sites. > > Can we stop with the lame "every person, and their dog!" numbering plans. The same MISTAKE has been repeated so many times in recent history you'd think people would know better. It's the exact same wrong-think that was applied to the 32bit IPv4 addressing in an era where there were a few dozen computers worldwide. (also that IPv4 was an "experiment" that was never imagined to be this big.) > > We're smart enough to mis-manage *any* resource. It's just a matter of "when" that it'll be back to haunt us. ("not within my lifetime" seems to be a very popular compromise.) I'm more going for not within the useful lifetime of the protocol. I figure we'll be lucky if IPv6 doesn't hit some non-address-size related scaling limit in less than 50 years. As such, I figure a conservative protocol lifetime of 100 years is not unreasonable. If you read the rest of my post, you would realize that I wasn't arguing to give out addresses to every person and their dog, but instead arguing that trying to shift bits to the right would be costly and pointless because there are more than enough bits on the left site already. If you can provide any sort of math to back up a claim to the contrary, then let's see it. If all you've got is we have grossly underestimated demand in the past, then I say sure, but we've so grossly overprovided for our estimate of demand in this case that it's unlikely to be an issue in any probable lifetime of the protocol. Owen From bross at pobox.com Thu Jun 19 23:09:09 2014 From: bross at pobox.com (Brandon Ross) Date: Thu, 19 Jun 2014 19:09:09 -0400 (EDT) Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <517FAD6D-4E88-4CE7-A32E-CCD554FE0613@delong.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <7C7B3A12-C0E8-4995-B330-45F0DF00FD83@dds.nl> <3BC1E2A4-5503-4499-BE87-133EF61458CC@delong.com> <517FAD6D-4E88-4CE7-A32E-CCD554FE0613@delong.com> Message-ID: On Thu, 19 Jun 2014, Owen DeLong wrote: > If you read the rest of my post, you would realize that I wasn't arguing > to give out addresses to every person and their dog, but instead arguing > that trying to shift bits to the right would be costly and pointless > because there are more than enough bits on the left site already. Perhaps we should discuss this in a different way... Ricky, if you were to design a new protocol today such that you can give out addresses, at will without having to be conservative with the goal of minimizing human factor costs, and _guarantee_ that you will not run out of addresses in the useful life of the protocol, how big would that address space need to be? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From kauer at biplane.com.au Thu Jun 19 23:23:27 2014 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 20 Jun 2014 09:23:27 +1000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <43456EA1-0C1A-481C-A0D6-8E106BE5F555@delong.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> <43456EA1-0C1A-481C-A0D6-8E106BE5F555@delong.com> Message-ID: <1403220207.3347.359.camel@karl> On Thu, 2014-06-19 at 15:55 -0700, Owen DeLong wrote: > With a small amount of conceptual knowledge, the differences between > IPv4 and IPv6 become very very small. True story: At a previous employer, a local admin had pushed his network over 250-odd PCs and wanted more addresses. So we extended his /24 to a /23. All coordinated - it was after work on a Friday, he was going to renumber everything. This was before DHCP had been fully deployed, and he had a lot of statically configured machines. He rang the next day in a bit of a flap, because "the new addresses don't work!" We pressed for more info. "They all work fine up to 254", he said, "but from 255 up they aren't even accepted by the configuration untility! I've tried all the way up to 300!" He wasn't dumb - far from it - he'd just never been outside a /24 before, so had never needed to understand what the numbers *meant*. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From universe at truemetal.org Thu Jun 19 23:41:34 2014 From: universe at truemetal.org (Markus) Date: Fri, 20 Jun 2014 01:41:34 +0200 Subject: CARISIRT: Yet Another BMC Vulnerability Message-ID: <53A3752E.7010400@truemetal.org> http://blog.cari.net/carisirt-yet-another-bmc-vulnerability-and-some-added-extras/ = simple telnet commands displays passwords of BMCs. Damn Supermicro, please hire some new programmers! :( From owen at delong.com Thu Jun 19 23:04:30 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Jun 2014 16:04:30 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <21411.16678.353049.420269@world.std.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <21410.343.738034.2737@world.std.com> <21411.8970.191029.86423@world.std.com> <21411.16678.353049.420269@world.std.com> Message-ID: It depends on how you define Nexus. Currently the way number resource policy works is that global policy requires an identical policy be put through the policy development process in each of the 5 regional internet registries and adopted by all 5. It is then sent to the ASO AC (an elected body representing the 5 RIRs and their communities to ICANN) who validates that the 5 RIR policy processes were, in fact, followed and that identical (or nearly identical) policy was passed by each. If any differences need to be resolved, the ASO AC works with the RIRs in question to get those resolved through the policy processes. Once all 5 RIR communities have agreed on a common policy, the ASO AC ratifies it and sends it to the ICANN board for a final ratification. Once the ICANN board ratifies it, it is global policy. Generally, these policies are limited to the ones which govern how the RIRs interact with IANA to receive and/or return number resources that are managed by the RIRs. This particular mechanism has worked quite well for many years. It would be a shame to see ICANN take a more active (destructive) role in the process. Owen On Jun 19, 2014, at 12:59 , Barry Shein wrote: > > But I thought ICANN was supposed to be the new and future nexus for > all things internet governance? > > On June 19, 2014 at 13:57 morrowc.lists at gmail.com (Christopher Morrow) wrote: >> On Thu, Jun 19, 2014 at 1:51 PM, Barry Shein wrote: >>> >>> Really. You're really completely discounting ICANN in having any >>> leadership or participative role in the IPv4/IPv6 transition? >>> >> >> What leadership position have you seen them take ASIDE from marketing >> (in the last 2-3 yrs, but most of that has been ISOC not ICANN >> directly) in the last 5 yrs or so? >> >> -chris > > -- > -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 LarrySheldon at cox.net Thu Jun 19 23:46:11 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 19 Jun 2014 18:46:11 -0500 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> Message-ID: <53A37643.4020106@cox.net> On 6/19/2014 5:14 PM, Randy Bush wrote: > ........................................................ and cut the > tea party fanaticism. What might this mean in this context (IP) and environment (NANOG)? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mpalmer at hezmatt.org Fri Jun 20 00:08:26 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 20 Jun 2014 10:08:26 +1000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <53A37643.4020106@cox.net> References: <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <64BD60BE-5A18-4DCE-9625-F02E2622A43A@arin.net> <53A37643.4020106@cox.net> Message-ID: <20140620000826.GO15750@hezmatt.org> On Thu, Jun 19, 2014 at 06:46:11PM -0500, Larry Sheldon wrote: > On 6/19/2014 5:14 PM, Randy Bush wrote: > > >........................................................ and cut the > >tea party fanaticism. > > What might this mean in this context (IP) and environment (NANOG)? Death to the lemon wedge heretics! - Matt From coy.hile at coyhile.com Fri Jun 20 01:42:04 2014 From: coy.hile at coyhile.com (Coy Hile) Date: Thu, 19 Jun 2014 21:42:04 -0400 Subject: CARISIRT: Yet Another BMC Vulnerability In-Reply-To: <53A3752E.7010400@truemetal.org> References: <53A3752E.7010400@truemetal.org> Message-ID: On Jun 19, 2014, at 7:41 PM, Markus wrote: > http://blog.cari.net/carisirt-yet-another-bmc-vulnerability-and-some-added-extras/ > > = simple telnet commands displays passwords of BMCs. Damn Supermicro, please hire some new programmers! :( > And here I was hoping it would be something useful like a vulnerability that would put BMC (the company) out of business! Don’t get my hopes up like that! More reason that one shouldn’t make his OOB net generally accessible. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2251 bytes Desc: not available URL: From gary.buhrmaster at gmail.com Fri Jun 20 02:41:07 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 20 Jun 2014 02:41:07 +0000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <4C91045B-6C3C-4383-88EE-BE52376BBF15@delong.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <4C91045B-6C3C-4383-88EE-BE52376BBF15@delong.com> Message-ID: On Thu, Jun 19, 2014 at 10:47 PM, Owen DeLong wrote: ..... > Ideally, it would be nice if the UNH/IOL and/or CEA could come up with a meaningful definition of IPv6 support and a logo to go with it that we could tell consumers to look for on the box. Ideally, this would be a set of standards that users of the logo agree to abide by rather than a fee-based testing regime that excludes smaller players. You mean something like the IPv6 Ready logo at http://www.ipv6ready.org ? From morrowc.lists at gmail.com Fri Jun 20 03:13:10 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Jun 2014 23:13:10 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> <049501cf8bec$d3b85750$7b2905f0$@com> Message-ID: On Thu, Jun 19, 2014 at 5:24 PM, Lee Howard wrote: > > > On 6/19/14 4:30 PM, "Christopher Morrow" wrote: > >>On Thu, Jun 19, 2014 at 4:27 PM, Lee Howard wrote: >>> >>> How does IPv6 to end users make IPv4 unnecessary for growth, if >>> enterprises and content providers haven't deployed IPv6? >> >>content folk are mostly getting v6 done already, right? (minus AWS/etc >>which are on-plan to deploy as near as I can tell) >>I don't think enterprise folk matter here, they'll get to v6 when they >>have enough problems related to v4 content reachability... and when >>they try the ISP network ought to be prepared to deal with them. > > > 7.94% Google hits in the U.S. come from IPv6 addresses. > http://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-ad > option > 7.29% of web sites have a working AAAA. > http://www.employees.org/~dwing/aaaa-stats/ > > > >> >>which content providers (large-ish ones) are lagging still? > > https://www.vyncke.org/ipv6status/detailed.php?country=us > > Microsoft: live.com, Bing, MSN, microsoft.com that's a bummer I had thought they were doing v6 :( (same for twitter actually) So, I was focusing on the end-user (Consumer) set because given enough migration there that should push more application folk in the right direction. I think ipv6 still suffers from the chicken/egg problem: 1) users aren't asking so isps aren't selling/doing 1b) ISPs still ahve v4 or a solution (they think) to no-more-v4 and can keep rolling new customers out 2) content places have no one they can't reach today because there's v4 to everyone that they care about 3) both sides still playing chicken. oh well, see you on this same conversation in another 18 months time? From alejandroacostaalamo at gmail.com Fri Jun 20 03:47:11 2014 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Thu, 19 Jun 2014 23:17:11 -0430 Subject: Canada and IPv6 In-Reply-To: <53A22BC1.6040500@sadiqs.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: <53A3AEBF.40108@gmail.com> Not residential IPv6 connectivity but today I got this news: http://www.ourmidland.com/prweb/cirrushosting-to-support-ipv-on-canadian-vps-and-cloud-hosting/article_4d28a39c-1c3f-5209-939b-10d8cf310564.html El 6/18/2014 7:46 PM, Sadiq Saif escribió: > On 6/18/2014 14:25, Lee Howard wrote: >> Canada is way behind, just 0.4% deployment. > > Any Canadian ISP folk in here want to shine a light on this dearth of > residential IPv6 connectivity? > > Is there any progress being made on this front? > From bzs at world.std.com Fri Jun 20 05:17:19 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 20 Jun 2014 01:17:19 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <21410.343.738034.2737@world.std.com> <21411.8970.191029.86423@world.std.com> <21411.16678.353049.420269@world.std.com> Message-ID: <21411.50143.476516.361334@world.std.com> Well my suggestion was less in the realm of imposing changes in policy and more in the realm of providing resources (even if just as a nexus) and fora to help promote IPv6 adoption, brainstorm the problem. There is a cross-disciplinary aspect to this, it's not only a network engineering and operational issue, or only incidentally. -- -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 wmaton at ottix.net Fri Jun 20 10:48:18 2014 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Fri, 20 Jun 2014 06:48:18 -0400 (EDT) Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: On Thu, 19 Jun 2014, jim deleskie wrote: > Those all sounds like legit business questions.   Yup. On the otherhand at the other end of the customer spectrum: http://www.tbs-sct.gc.ca/it-ti/ipv6/ipv6tb-eng.asp > -jim > > > On Thu, Jun 19, 2014 at 2:45 PM, William F. Maton Sotomayor wrote: > On Wed, 18 Jun 2014, Sadiq Saif wrote: > > On 6/18/2014 14:25, Lee Howard wrote: > Canada is way behind, just 0.4% deployment. > > > Any Canadian ISP folk in here want to shine a light on this dearth of > residential IPv6 connectivity? > > Is there any progress being made on this front? > > > Teksavvy does it (tunnel I believe) if you ask. > > Otherwise it's the usual: > > - 'why do we need this?'; > - 'It costs money to upgrade for something low-demand'; > - 'What's the market?'; > - 'I don't have time'; > - 'Aw gee do I have to??' > > wfms > > > > wfms From erik.soosalu at calyxinc.com Fri Jun 20 12:30:16 2014 From: erik.soosalu at calyxinc.com (Erik Soosalu) Date: Fri, 20 Jun 2014 08:30:16 -0400 Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: <53A22BC1.6040500@sadiqs.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: <0B224A2FE01CC54C860290D42474BF6006066701@exchange.nff.local> Well, I was just looking at my Bell Canada "Fibe" (IPTV/Internet) setup last nite and the gear Bell provides doesn't do IPv6 at all (not even an option). This gear is about 3 years old, so my hopes for them aren't very good... Thanks, Erik -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sadiq Saif Sent: Wednesday, June 18, 2014 8:16 PM To: nanog at nanog.org Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) On 6/18/2014 14:25, Lee Howard wrote: > Canada is way behind, just 0.4% deployment. Any Canadian ISP folk in here want to shine a light on this dearth of residential IPv6 connectivity? Is there any progress being made on this front? -- Sadiq Saif From jra at baylink.com Fri Jun 20 13:12:03 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 20 Jun 2014 09:12:03 -0400 (EDT) Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <3BA39514-DD73-4FC5-A309-481530F2C003@matthew.at> Message-ID: <27233620.4246.1403269923703.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Kaufman" > My Apple TV appears to use IPv6, but since there's no UI for it (last > I checked) I had to disable SLAAC on that subnet to keep it from > trying to use my slow connection. > > So in my book, "some" v6 support is actually worse than "none" I believe I recall suggesting that a couple days ago, and having Mark Andrews slap me around for it... 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 jacques.latour at cira.ca Fri Jun 20 13:24:22 2014 From: jacques.latour at cira.ca (Jacques Latour) Date: Fri, 20 Jun 2014 13:24:22 +0000 Subject: Canada and IPv6 (& DNSSEC) Message-ID: At .ca, we see a very low IPv6 adoption rate in .ca domains and slow progression rate. See last ~3 years trends at www.cira.ca/radarv6 Just as an indicator, we have 316 .ca domains with IPv6 glue records :-( *** Can the major Canadian ISP reply back with their plans/timelines/costs on IPv6 offerings for commercial and residential services? CIRA could compile this info somewhere for reference. *** BTW, while at it, we have a lot of work to do for DNSSEC validation in Canada; some stats filtered with more than 4000 clients as measured early 2014 by APNIC, Geoff Huston. (thanks Geoff!) Canada is #96 :-( AS Name Rank ASN Total End Clients % DNSSEC validation ------------------------------------------------------------ ------- ------- ---------------------- --------------------------- TEKSAVVY-TOR TekSavvy Solutions Inc. Toronto 156 5645 4804 82.56 COGECOWAVE - Cogeco Cable 923 7992 5424 17.02 ROGERS-CABLE - Rogers Cable Communications Inc. 3115 812 28884 1.39 SHAW - Shaw Communications Inc. 3270 6327 29083 1.18 ASN852 - TELUS Communications Inc. 3497 852 22994 0.93 VIDEOTRON - Videotron Telecom Ltee 3512 5769 9669 0.91 BACOM - Bell Canada 3517 577 28392 0.9 CANET-ASN-4 - Bell Aliant Regional Communications 3753 855 4053 0.64 Jack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alejandro Acosta Sent: June-19-14 11:47 PM To: nanog at nanog.org Subject: Re: Canada and IPv6 Not residential IPv6 connectivity but today I got this news: http://www.ourmidland.com/prweb/cirrushosting-to-support-ipv-on-canadian-vps-and-cloud-hosting/article_4d28a39c-1c3f-5209-939b-10d8cf310564.html El 6/18/2014 7:46 PM, Sadiq Saif escribió: > On 6/18/2014 14:25, Lee Howard wrote: >> Canada is way behind, just 0.4% deployment. > > Any Canadian ISP folk in here want to shine a light on this dearth of > residential IPv6 connectivity? > > Is there any progress being made on this front? > From Jean-Francois.Dube at videotron.com Fri Jun 20 14:12:30 2014 From: Jean-Francois.Dube at videotron.com (Jean-Francois.Dube at videotron.com) Date: Fri, 20 Jun 2014 10:12:30 -0400 Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: <53A22BC1.6040500@sadiqs.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: Videotron (AS5769) is offering 6RD (RFC5969) to all residential customers, if their gear supports it. (DHCP option 212) (But our MGMT still calls it beta for now.) JF Jean-François Dubé Technicien, Opérations Réseau IP Ingénierie Exploitation des Réseaux Vidéotron "NANOG" a écrit sur 2014-06-18 20:16:01 : > De : Sadiq Saif > A : nanog at nanog.org, > Date : 2014-06-19 12:43 > Objet : Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) > Envoyé par : "NANOG" > > On 6/18/2014 14:25, Lee Howard wrote: > > Canada is way behind, just 0.4% deployment. > > Any Canadian ISP folk in here want to shine a light on this dearth of > residential IPv6 connectivity? > > Is there any progress being made on this front? > > -- > Sadiq Saif From gabe at teksavvy.ca Fri Jun 20 14:22:17 2014 From: gabe at teksavvy.ca (Gabriel Blanchard) Date: Fri, 20 Jun 2014 14:22:17 +0000 Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: <907f350843684b90943fca3032d0fbe5@EX2013N1.chatham.teksavvy.ca> 6rd is in my opinion a band-aid solution, I don't see the point of offering IPv6 if it requires IPv4. native IPv6 should be offered where possible. We offer native IPv6 to all our DSL customers but only on an opt-in basis, we're although unfortunately unable to offer IPv6 over Cable since we still depend on a certain incumbent... -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois.Dube at videotron.com Sent: Friday, June 20, 2014 10:13 AM To: lists at sadiqs.com Cc: nanog at nanog.org; NANOG Subject: RE: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) Videotron (AS5769) is offering 6RD (RFC5969) to all residential customers, if their gear supports it. (DHCP option 212) (But our MGMT still calls it beta for now.) JF Jean-François Dubé Technicien, Opérations Réseau IP Ingénierie Exploitation des Réseaux Vidéotron "NANOG" a écrit sur 2014-06-18 20:16:01 : > De : Sadiq Saif > A : nanog at nanog.org, > Date : 2014-06-19 12:43 > Objet : Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) Envoyé > par : "NANOG" > > On 6/18/2014 14:25, Lee Howard wrote: > > Canada is way behind, just 0.4% deployment. > > Any Canadian ISP folk in here want to shine a light on this dearth of > residential IPv6 connectivity? > > Is there any progress being made on this front? > > -- > Sadiq Saif From Jean-Francois.Dube at videotron.com Fri Jun 20 14:50:51 2014 From: Jean-Francois.Dube at videotron.com (Jean-Francois.Dube at videotron.com) Date: Fri, 20 Jun 2014 10:50:51 -0400 Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: <907f350843684b90943fca3032d0fbe5@EX2013N1.chatham.teksavvy.ca> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> <907f350843684b90943fca3032d0fbe5@EX2013N1.chatham.teksavvy.ca> Message-ID: There are obviously layer 8-9-10 issues to deal with as well before native IPv6 can be deployed. Being a IP NOC grunt, I keep my focus on layer 1-7. JF Jean-François Dubé Technicien, Opérations Réseau IP Ingénierie Exploitation des Réseaux Vidéotron "NANOG" a écrit sur 2014-06-20 10:22:17 : > De : Gabriel Blanchard > A : "nanog at nanog.org" , > Date : 2014-06-20 10:24 > Objet : RE: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) > Envoyé par : "NANOG" > > 6rd is in my opinion a band-aid solution, I don't see the point of > offering IPv6 if it requires IPv4. native IPv6 should be offered > where possible. > > We offer native IPv6 to all our DSL customers but only on an opt-in > basis, we're although unfortunately unable to offer IPv6 over Cable > since we still depend on a certain incumbent... > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean- > Francois.Dube at videotron.com > Sent: Friday, June 20, 2014 10:13 AM > To: lists at sadiqs.com > Cc: nanog at nanog.org; NANOG > Subject: RE: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) > > Videotron (AS5769) is offering 6RD (RFC5969) to all residential > customers, if their gear supports it. (DHCP option 212) > > (But our MGMT still calls it beta for now.) > > JF > > Jean-François Dubé > Technicien, Opérations Réseau IP > Ingénierie Exploitation des Réseaux > Vidéotron > > "NANOG" a écrit sur 2014-06-18 20:16:01 : > > > De : Sadiq Saif > > A : nanog at nanog.org, > > Date : 2014-06-19 12:43 > > Objet : Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) Envoyé > > par : "NANOG" > > > > On 6/18/2014 14:25, Lee Howard wrote: > > > Canada is way behind, just 0.4% deployment. > > > > Any Canadian ISP folk in here want to shine a light on this dearth of > > residential IPv6 connectivity? > > > > Is there any progress being made on this front? > > > > -- > > Sadiq Saif From johnl at iecc.com Fri Jun 20 15:09:18 2014 From: johnl at iecc.com (John Levine) Date: 20 Jun 2014 15:09:18 -0000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <27233620.4246.1403269923703.JavaMail.root@benjamin.baylink.com> Message-ID: <20140620150918.77151.qmail@joyce.lan> >> So in my book, "some" v6 support is actually worse than "none" That has been my experience. The eyeballs are not happy. R's, John From vristevs at ramapo.edu Fri Jun 20 17:45:00 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Fri, 20 Jun 2014 13:45:00 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <044a01cf8be7$5bf605f0$13e211d0$@com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> Message-ID: <53A4731C.6030307@ramapo.edu> I think it depends on the environment. Many small to midsized colleges use some type of NAC for their dorms. Some of the most popular ones don't have support for IPv6. I know there are more, but here are a few: NetReg (and it's commercial variants such as Infoblox Authenticated DHCP) ImpulsePoint Safeconnect Nomadix Gateway (used in many hotel guest networks) Cisco Clean Access when Inline mode (product is EOL but could explain why many schools couldn't do IPv6 in the dorms over the years) In my specific case, we couldn't use 802.1x for wired ports until recently so we've always had to depend an IP based solution for NAC. In a dorm setting, where a lot of the wired hosts don't support 802.1x(Roku,printers,Bluray players) , options are limited . With newer switches supporting mac-address based authentication (MAB in Cisco world, Mac-Radius in Juniper), we can start planning for IPv6 in our dorms in at least a limited deployment. On 6/19/2014 1:53 PM, Edward Arthurs wrote: > Thank You for responding. > If mid to small companies have equipment made in the last 7 years, they will not need to replace equipment. > Most net admins at the mid to small companies have no idea about IPV6. > Cost is a major consideration at the mid to small size companies, if they need to upgrade equipment. > The difference between IPV4 and IPV6 for someone not familiar is huge, > 1. There is a totally new format dotted decimal to colon. > 2. The 32 bit to 128 bit is/or can be quite challenging for some net admins. > > Thank You > > -----Original Message----- > From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow > Sent: Thursday, June 19, 2014 10:14 AM > To: Edward Arthurs > Cc: nanog list > Subject: Re: Ars Technica on IPv4 exhaustion > > On Wed, Jun 18, 2014 at 9:13 PM, Edward Arthurs wrote: >> There are several obstacles to overcome, IMHO 1. The companies at the >> mid size and smaller levels have to invest in newer equipment that >> handles IPV6. > if they have gear made in the last 7yrs it's likely already got the right bits for v6 support, right? > >> 2. The network Admins at the above mentioned companies need to learn >> IPV6, most will want there company to pay the bill for this. > for a large majority of the use cases it's just "configure that other family on the interface" and done. > >> 3. The vendors that make said equipment should lower the cost of said >> equipment to prompt said companies into purchasing said equipment. > the equipment in question does both v4 and v6 ... so why lower pricing? > (also, see 'if made in the last 7 yrs, it's already done and you probably don't have to upgrade') > >> There is a huge difference between IPV4 and IPV6 and there will be a >> lot of > 'huge difference' ... pls quantify this. (unless you just mean colons instead of periods and letters in the address along with numbers) > From cscora at apnic.net Fri Jun 20 18:11:22 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Jun 2014 04:11:22 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201406201811.s5KIBMpn012661@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, LacNOG, TRNOG, 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 21 Jun, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 500142 Prefixes after maximum aggregation: 195076 Deaggregation factor: 2.56 Unique aggregates announced to Internet: 246641 Total ASes present in the Internet Routing Table: 47078 Prefixes per ASN: 10.62 Origin-only ASes present in the Internet Routing Table: 35900 Origin ASes announcing only one prefix: 16317 Transit ASes present in the Internet Routing Table: 6097 Transit-only ASes present in the Internet Routing Table: 173 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1758 Unregistered ASNs in the Routing Table: 458 Number of 32-bit ASNs allocated by the RIRs: 6875 Number of 32-bit ASNs visible in the Routing Table: 5081 Prefixes from 32-bit ASNs in the Routing Table: 17602 Number of bogon 32-bit ASNs visible in the Routing Table: 256 Special use prefixes present in the Routing Table: 13 Prefixes being announced from unallocated address space: 401 Number of addresses announced to Internet: 2695212164 Equivalent to 160 /8s, 165 /16s and 172 /24s Percentage of available address space announced: 72.8 Percentage of allocated address space announced: 72.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.6 Total number of prefixes smaller than registry allocations: 173092 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 119875 Total APNIC prefixes after maximum aggregation: 35406 APNIC Deaggregation factor: 3.39 Prefixes being announced from the APNIC address blocks: 123023 Unique aggregates announced from the APNIC address blocks: 51316 APNIC Region origin ASes present in the Internet Routing Table: 4956 APNIC Prefixes per ASN: 24.82 APNIC Region origin ASes announcing only one prefix: 1224 APNIC Region transit ASes present in the Internet Routing Table: 866 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 985 Number of APNIC addresses announced to Internet: 733773440 Equivalent to 43 /8s, 188 /16s and 126 /24s Percentage of available APNIC address space announced: 85.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-63999, 131072-133631 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: 169112 Total ARIN prefixes after maximum aggregation: 83993 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 170818 Unique aggregates announced from the ARIN address blocks: 79633 ARIN Region origin ASes present in the Internet Routing Table: 16303 ARIN Prefixes per ASN: 10.48 ARIN Region origin ASes announcing only one prefix: 6108 ARIN Region transit ASes present in the Internet Routing Table: 1687 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 123 Number of ARIN addresses announced to Internet: 1077063936 Equivalent to 64 /8s, 50 /16s and 177 /24s Percentage of available ARIN address space announced: 57.0 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, 393216-394239 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: 124078 Total RIPE prefixes after maximum aggregation: 62752 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 128701 Unique aggregates announced from the RIPE address blocks: 81550 RIPE Region origin ASes present in the Internet Routing Table: 17714 RIPE Prefixes per ASN: 7.27 RIPE Region origin ASes announcing only one prefix: 8256 RIPE Region transit ASes present in the Internet Routing Table: 2874 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2716 Number of RIPE addresses announced to Internet: 658270340 Equivalent to 39 /8s, 60 /16s and 104 /24s Percentage of available RIPE address space announced: 95.7 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-202239 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: 57307 Total LACNIC prefixes after maximum aggregation: 10229 LACNIC Deaggregation factor: 5.60 Prefixes being announced from the LACNIC address blocks: 64433 Unique aggregates announced from the LACNIC address blocks: 29402 LACNIC Region origin ASes present in the Internet Routing Table: 2107 LACNIC Prefixes per ASN: 30.58 LACNIC Region origin ASes announcing only one prefix: 524 LACNIC Region transit ASes present in the Internet Routing Table: 440 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1219 Number of LACNIC addresses announced to Internet: 165961856 Equivalent to 9 /8s, 228 /16s and 96 /24s Percentage of available LACNIC address space announced: 98.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 12057 Total AfriNIC prefixes after maximum aggregation: 2659 AfriNIC Deaggregation factor: 4.53 Prefixes being announced from the AfriNIC address blocks: 12766 Unique aggregates announced from the AfriNIC address blocks: 4386 AfriNIC Region origin ASes present in the Internet Routing Table: 719 AfriNIC Prefixes per ASN: 17.76 AfriNIC Region origin ASes announcing only one prefix: 205 AfriNIC Region transit ASes present in the Internet Routing Table: 155 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 38 Number of AfriNIC addresses announced to Internet: 57427200 Equivalent to 3 /8s, 108 /16s and 69 /24s Percentage of available AfriNIC address space announced: 57.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 2932 11591 921 Korea Telecom 17974 2800 899 72 PT Telekomunikasi Indonesia 7545 2279 320 118 TPG Telecom Limited 4755 1860 396 199 TATA Communications formerly 9829 1612 1307 32 National Internet Backbone 9583 1303 101 536 Sify Limited 9498 1266 314 85 BHARTI Airtel Ltd. 7552 1243 1098 14 Viettel Corporation 4808 1224 2152 366 CNCGROUP IP network China169 24560 1162 398 190 Bharti Airtel Ltd., Telemedia 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 6389 2957 3688 53 BellSouth.net Inc. 22773 2567 2938 138 Cox Communications Inc. 7029 2255 1905 303 Windstream Communications Inc 18566 2047 379 178 MegaPath Corporation 20115 1714 1700 571 Charter Communications 4323 1633 1073 414 tw telecom holdings, inc. 30036 1464 320 566 Mediacom Communications Corp 701 1444 11188 731 MCI Communications Services, 6983 1382 818 314 ITC^Deltacom 22561 1307 402 233 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 34984 1709 264 274 TELLCOM ILETISIM HIZMETLERI A 20940 1403 545 1039 Akamai International B.V. 8402 1374 544 16 OJSC "Vimpelcom" 13188 1031 100 28 TOV "Bank-Inform" 31148 1017 45 20 Freenet Ltd. 8551 945 370 40 Bezeq International-Ltd 6849 824 359 29 JSC "Ukrtelecom" 6830 771 2335 429 Liberty Global Operations B.V 12479 730 795 57 France Telecom Espana SA 9198 576 344 28 JSC Kazakhtelecom 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 28573 3764 2019 99 NET Servi�os de Comunica��o S 10620 2898 469 201 Telmex Colombia S.A. 18881 2047 1036 22 Global Village Telecom 7303 1769 1179 231 Telecom Argentina S.A. 8151 1439 2971 419 Uninet S.A. de C.V. 6503 1140 434 60 Axtel, S.A.B. de C.V. 7738 979 1882 41 Telemar Norte Leste S.A. 27947 890 130 51 Telconet S.A 26615 862 2325 35 Tim Celular S.A. 3816 825 341 147 COLOMBIA TELECOMUNICACIONES S 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 36998 1114 240 6 Sudanese Mobile Telephone (ZA 24863 940 280 26 Link Egypt (Link.NET) 6713 648 732 35 Office National des Postes et 8452 589 958 13 TE-AS 24835 306 144 9 Vodafone Data 36992 300 783 24 ETISALAT MISR 3741 250 921 213 Internet Solutions 37054 243 19 6 Data Telecom Service 29571 225 22 17 Cote d'Ivoire Telecom 15706 187 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 28573 3764 2019 99 NET Servi�os de Comunica��o S 6389 2957 3688 53 BellSouth.net Inc. 4766 2932 11591 921 Korea Telecom 10620 2898 469 201 Telmex Colombia S.A. 17974 2800 899 72 PT Telekomunikasi Indonesia 22773 2567 2938 138 Cox Communications Inc. 7545 2279 320 118 TPG Telecom Limited 7029 2255 1905 303 Windstream Communications Inc 18566 2047 379 178 MegaPath Corporation 18881 2047 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2957 2904 BellSouth.net Inc. 17974 2800 2728 PT Telekomunikasi Indonesia 10620 2898 2697 Telmex Colombia S.A. 22773 2567 2429 Cox Communications Inc. 7545 2279 2161 TPG Telecom Limited 18881 2047 2025 Global Village Telecom 4766 2932 2011 Korea Telecom 7029 2255 1952 Windstream Communications Inc 18566 2047 1869 MegaPath Corporation 4755 1860 1661 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 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 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications 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.88.0.0/16 6697 Republican Unitary Telecommun 100.89.0.0/16 6697 Republican Unitary Telecommun 100.90.0.0/16 6697 Republican Unitary Telecommun 100.91.0.0/16 6697 Republican Unitary Telecommun 100.92.0.0/16 6697 Republican Unitary Telecommun 100.93.0.0/16 6697 Republican Unitary Telecommun 100.94.0.0/16 6697 Republican Unitary Telecommun 100.95.0.0/16 6697 Republican Unitary Telecommun 100.96.0.0/14 6697 Republican Unitary Telecommun 100.104.0.0/13 6697 Republican Unitary Telecommun Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.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:12 /10:30 /11:90 /12:258 /13:489 /14:982 /15:1701 /16:13000 /17:6939 /18:11691 /19:24674 /20:34579 /21:37111 /22:53559 /23:46902 /24:265933 /25:814 /26:911 /27:398 /28:13 /29:18 /30:8 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 22773 1812 2567 Cox Communications Inc. 6389 1694 2957 BellSouth.net Inc. 30036 1301 1464 Mediacom Communications Corp 11492 1203 1251 CABLE ONE, INC. 7029 1143 2255 Windstream Communications Inc 6983 1088 1382 ITC^Deltacom 36998 1080 1114 Sudanese Mobile Telephone (ZA 8402 1056 1374 OJSC "Vimpelcom" 34984 1038 1709 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1132 2:670 3:3 4:15 5:991 6:19 8:714 12:1828 13:4 14:1049 15:14 16:2 17:37 18:21 20:36 23:930 24:1756 27:1766 31:1488 32:43 33:2 34:5 36:136 37:1838 38:957 39:7 40:204 41:3210 42:257 43:70 44:12 45:20 46:2072 47:23 49:725 50:939 52:12 54:47 55:6 57:29 58:1229 59:605 60:412 61:1561 62:1257 63:1951 64:4369 65:2292 66:4175 67:2067 68:1063 69:3353 70:866 71:439 72:2017 74:2639 75:326 76:407 77:1688 78:859 79:702 80:1312 81:1201 82:753 83:755 84:743 85:1313 86:433 87:1179 88:468 89:1822 90:139 91:5691 92:703 93:1772 94:2066 95:1561 96:531 97:358 98:1091 99:49 100:66 101:830 103:5155 104:23 105:543 106:172 107:634 108:595 109:2021 110:984 111:1338 112:668 113:848 114:895 115:1134 116:1107 117:947 118:1419 119:1393 120:392 121:825 122:2057 123:1339 124:1434 125:1481 128:593 129:342 130:348 131:666 132:417 133:164 134:321 135:74 136:260 137:285 138:364 139:165 140:216 141:388 142:568 143:443 144:508 145:100 146:638 147:476 148:907 149:364 150:174 151:711 152:441 153:219 154:299 155:500 156:353 157:337 158:243 159:911 160:326 161:553 162:1536 163:262 164:690 165:617 166:284 167:629 168:1057 169:124 170:1437 171:193 172:23 173:1615 174:708 175:604 176:1365 177:3233 178:2043 179:686 180:1780 181:1218 182:1582 183:524 184:729 185:1757 186:2844 187:1607 188:2114 189:1487 190:7312 191:362 192:7373 193:5516 194:4027 195:3521 196:1420 197:678 198:5087 199:5518 200:6274 201:2596 202:9116 203:8912 204:4591 205:2660 206:2971 207:2984 208:3981 209:3736 210:3107 211:1717 212:2297 213:2094 214:896 215:87 216:5591 217:1693 218:597 219:330 220:1281 221:625 222:353 223:602 End of report From Lee at asgard.org Fri Jun 20 19:53:16 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 20 Jun 2014 15:53:16 -0400 Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> Message-ID: I notice an IETF meeting in Toronto one month hence. If Canadian operators (and content providers) were interested in talking about their common problems, it might be convenient to schedule some time adjacent to that meeting. Lee On 6/20/14 10:12 AM, "Jean-Francois.Dube at videotron.com" wrote: >Videotron (AS5769) is offering 6RD (RFC5969) to all residential >customers, >if their gear supports it. (DHCP option 212) > >(But our MGMT still calls it beta for now.) > >JF > >Jean-François Dubé >Technicien, Opérations Réseau IP >Ingénierie Exploitation des Réseaux >Vidéotron > >"NANOG" a écrit sur 2014-06-18 20:16:01 : > >> De : Sadiq Saif >> A : nanog at nanog.org, >> Date : 2014-06-19 12:43 >> Objet : Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) >> Envoyé par : "NANOG" >> >> On 6/18/2014 14:25, Lee Howard wrote: >> > Canada is way behind, just 0.4% deployment. >> >> Any Canadian ISP folk in here want to shine a light on this dearth of >> residential IPv6 connectivity? >> >> Is there any progress being made on this front? >> >> -- >> Sadiq Saif > From Lee at asgard.org Fri Jun 20 20:03:07 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 20 Jun 2014 16:03:07 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> <049501cf8bec$d3b85750$7b2905f0$@com> Message-ID: On 6/19/14 11:13 PM, "Christopher Morrow" wrote: >On Thu, Jun 19, 2014 at 5:24 PM, Lee Howard wrote: >> >> >> On 6/19/14 4:30 PM, "Christopher Morrow" >>wrote: >> >So, I was focusing on the end-user (Consumer) set because given enough >migration there that should push more application folk in the right >direction. Why? Some content providers have said that they think IPv4 runout is an ISP problem. As long as users have IPv4, there's no reason for them to move. What percentage of eyeballs would need to be dual-stack for app folk to decide to support IPv6? > >I think ipv6 still suffers from the chicken/egg problem: > 1) users aren't asking so isps aren't selling/doing > 1b) ISPs still ahve v4 or a solution (they think) to no-more-v4 and >can keep rolling new customers out I simply don't think this is the case anymore, at least in the U.S. IPv6 deployment to users is huge, and will automatically snowball as old CPE cycles out. Mid-sized operators will be coming up this year. Half of mobile is done. I don't know of any U.S. ISP or wireless carrier that is planning to use the address market or CGN as their exhaustion strategy. > 2) content places have no one they can't reach today because there's >v4 to everyone that they care about > 3) both sides still playing chicken. > >oh well, see you on this same conversation in another 18 months time? I've said this several times, so for the record, here's my prediction: After ARIN runs out, and it may be 1-3 years after ARIN runs out, ISPs will incur the rising costs of IPv4 (through CGN or the address market). Eventually, costs will be so high that they offer IPv6 at a lower price, either for paid peering or to consumers. At that point, content providers will have a financial reason to migrate, and will painfully find that by the time they can do so, they will have already lost the users. To be clear, some content providers support IPv6, and some ISPs support IPv6. It's everybody else we need to move. And until they do, the Internet will be more expensive, or fragmented, or both. Also for the record: My prediction does not reflect any knowledge of any specific company's plan. Lee From owen at delong.com Fri Jun 20 20:17:35 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Jun 2014 13:17:35 -0700 Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: <907f350843684b90943fca3032d0fbe5@EX2013N1.chatham.teksavvy.ca> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> <907f350843684b90943fca3032d0fbe5@EX2013N1.chatham.teksavvy.ca> Message-ID: <0B5F40F8-E260-4527-8110-D1A12A47DA4E@delong.com> The point is that you can offer IPv6 to a lot of people using various instatntiations of 100.64.0.0/10 but using globally unique IPv6 addresses providing them full true internet access without NAT. Yes, 6rd is a stopgap, but 6rd stopgap is better than multi-natted IPv4 only. Owen On Jun 20, 2014, at 07:22 , Gabriel Blanchard wrote: > 6rd is in my opinion a band-aid solution, I don't see the point of offering IPv6 if it requires IPv4. native IPv6 should be offered where possible. > > We offer native IPv6 to all our DSL customers but only on an opt-in basis, we're although unfortunately unable to offer IPv6 over Cable since we still depend on a certain incumbent... > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois.Dube at videotron.com > Sent: Friday, June 20, 2014 10:13 AM > To: lists at sadiqs.com > Cc: nanog at nanog.org; NANOG > Subject: RE: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) > > Videotron (AS5769) is offering 6RD (RFC5969) to all residential customers, if their gear supports it. (DHCP option 212) > > (But our MGMT still calls it beta for now.) > > JF > > Jean-François Dubé > Technicien, Opérations Réseau IP > Ingénierie Exploitation des Réseaux > Vidéotron > > "NANOG" a écrit sur 2014-06-18 20:16:01 : > >> De : Sadiq Saif >> A : nanog at nanog.org, >> Date : 2014-06-19 12:43 >> Objet : Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) Envoyé >> par : "NANOG" >> >> On 6/18/2014 14:25, Lee Howard wrote: >>> Canada is way behind, just 0.4% deployment. >> >> Any Canadian ISP folk in here want to shine a light on this dearth of >> residential IPv6 connectivity? >> >> Is there any progress being made on this front? >> >> -- >> Sadiq Saif From betty at newnog.org Fri Jun 20 21:01:44 2014 From: betty at newnog.org (Betty Burke ) Date: Fri, 20 Jun 2014 17:01:44 -0400 Subject: [NANOG-announce] 2014 Postel Scholarship Announcment 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 2014 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 the 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 6-8, 2014, in Baltimore, Maryland USA, 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 4, 2014, and the awardees will be informed by July 21, 2014. 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 Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jean-francois.tremblay at viagenie.ca Fri Jun 20 20:45:28 2014 From: jean-francois.tremblay at viagenie.ca (JF Tremblay) Date: Fri, 20 Jun 2014 16:45:28 -0400 Subject: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) In-Reply-To: <0B5F40F8-E260-4527-8110-D1A12A47DA4E@delong.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A22BC1.6040500@sadiqs.com> <907f350843684b90943fca3032d0fbe5@EX2013N1.chatham.teksavvy.ca> <0B5F40F8-E260-4527-8110-D1A12A47DA4E@delong.com> Message-ID: <48341FEF-FA7B-41E9-AB3E-6F4197106AAD@viagenie.ca> I concur with Owen here. 6RD is a band-aid, but a pretty effective one to introduce IPv6 to the staff and management in your organization. When you get to native deployment, your engineering and ops staff no longer freak out when they see some IPv6 config. They can even debug ISIS and the IPv6 RR without calling you in the middle of the night! On the management side, they actually see IPv6 traffic in the nice monthly graphs, so they’ll remember to put it in the next RFP and even not to cut it from the next budget, if you’re lucky. And 6RD performance is quite good when implemented properly (2-3% hit on bandwidth, 1 ms in latency). What hurts are CPEs with bad implementations (bad option 212 implementation or no MTU reduction). /JF On Jun 20, 2014, at 4:17 PM, Owen DeLong wrote: > The point is that you can offer IPv6 to a lot of people using various instatntiations of 100.64.0.0/10 but using globally unique IPv6 addresses providing them full true internet access without NAT. > > Yes, 6rd is a stopgap, but 6rd stopgap is better than multi-natted IPv4 only. > > Owen > > On Jun 20, 2014, at 07:22 , Gabriel Blanchard wrote: > >> 6rd is in my opinion a band-aid solution, I don't see the point of offering IPv6 if it requires IPv4. native IPv6 should be offered where possible. >> >> We offer native IPv6 to all our DSL customers but only on an opt-in basis, we're although unfortunately unable to offer IPv6 over Cable since we still depend on a certain incumbent... >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois.Dube at videotron.com >> Sent: Friday, June 20, 2014 10:13 AM >> To: lists at sadiqs.com >> Cc: nanog at nanog.org; NANOG >> Subject: RE: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) >> >> Videotron (AS5769) is offering 6RD (RFC5969) to all residential customers, if their gear supports it. (DHCP option 212) >> >> (But our MGMT still calls it beta for now.) >> >> JF >> >> Jean-François Dubé >> Technicien, Opérations Réseau IP >> Ingénierie Exploitation des Réseaux >> Vidéotron >> >> "NANOG" a écrit sur 2014-06-18 20:16:01 : >> >>> De : Sadiq Saif >>> A : nanog at nanog.org, >>> Date : 2014-06-19 12:43 >>> Objet : Canada and IPv6 (was: Ars Technica on IPv4 exhaustion) Envoyé >>> par : "NANOG" >>> >>> On 6/18/2014 14:25, Lee Howard wrote: >>>> Canada is way behind, just 0.4% deployment. >>> >>> Any Canadian ISP folk in here want to shine a light on this dearth of >>> residential IPv6 connectivity? >>> >>> Is there any progress being made on this front? >>> >>> -- >>> Sadiq Saif > From cidr-report at potaroo.net Fri Jun 20 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Jun 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201406202200.s5KM00sc078784@wattle.apnic.net> This report has been generated at Fri Jun 20 21:13:58 2014 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 13-06-14 505414 283965 14-06-14 505438 284131 15-06-14 505547 284290 16-06-14 505639 284236 17-06-14 505649 284718 18-06-14 506105 284633 19-06-14 506550 284600 20-06-14 506090 284693 AS Summary 47405 Number of ASes in routing system 19226 Number of ASes announcing only one prefix 3766 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120370688 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'). --- 20Jun14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 506289 284793 221496 43.7% All ASes AS28573 3766 176 3590 95.3% NET Servi�os de Comunica��o S.A.,BR AS6389 2952 80 2872 97.3% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2800 250 2550 91.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS18881 2047 39 2008 98.1% Global Village Telecom,BR AS4766 2924 927 1997 68.3% KIXS-AS-KR Korea Telecom,KR AS7029 2360 464 1896 80.3% WINDSTREAM - Windstream Communications Inc,US AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS10620 2898 1468 1430 49.3% Telmex Colombia S.A.,CO AS7303 1774 433 1341 75.6% Telecom Argentina S.A.,AR AS7545 2298 999 1299 56.5% TPG-INTERNET-AP TPG Telecom Limited,AU AS4755 1862 585 1277 68.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4323 1644 426 1218 74.1% TWTC - tw telecom holdings, inc.,US AS22773 2562 1454 1108 43.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS7552 1269 171 1098 86.5% VIETEL-AS-AP Viettel Corporation,VN AS36998 1114 37 1077 96.7% SDN-MOBITEL,SD AS6983 1382 315 1067 77.2% ITCDELTA - Earthlink, Inc.,US AS22561 1307 242 1065 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS4788 1039 153 886 85.3% TMNET-AS-AP TM Net, Internet Service Provider,MY AS9808 1039 162 877 84.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS24560 1162 334 828 71.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS9829 1609 783 826 51.3% BSNL-NIB National Internet Backbone,IN AS4808 1224 412 812 66.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS11492 1251 472 779 62.3% CABLEONE - CABLE ONE, INC.,US AS7738 979 212 767 78.3% Telemar Norte Leste S.A.,BR AS18101 942 186 756 80.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS26615 862 113 749 86.9% Tim Celular S.A.,BR AS8151 1448 700 748 51.7% Uninet S.A. de C.V.,MX AS701 1445 732 713 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS855 766 58 708 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS4780 1038 350 688 66.3% SEEDNET Digital United Inc.,TW Total 51810 13298 38512 74.3% Top 30 total Possible Bogus Routes 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.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.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -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 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 64.253.224.0/19 AS20428 -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 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 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 69.57.64.0/20 AS20428 -Reserved AS-,ZZ 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 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.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -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.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 100.88.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.89.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.90.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.91.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.92.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.93.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.94.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.95.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.96.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.104.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.112.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.120.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.124.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.140.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.141.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.142.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.143.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 JPNIC-ASBLOCK-AP JPNIC,JP 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.92.0/22 AS13269 103.18.92.0/24 AS13269 103.18.94.0/24 AS13269 103.18.248.0/22 AS18097 JPNIC-ASBLOCK-AP JPNIC,JP 103.19.0.0/22 AS18097 JPNIC-ASBLOCK-AP JPNIC,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 JPNIC-JP-ASN-BLOCK Japan Network Information Center,JP 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 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 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 163.47.23.0/24 AS2907 JPNIC-2BYTE-ASBLOCK-AP for assignment to JPNIC members,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.61.140.0/22 AS60198 NODEMAX NodeMax Limited,GB 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 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.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,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.104.61.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,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.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,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 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 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.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 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.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 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.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 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.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT 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 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 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.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 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.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech 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.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.146.36.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 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.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 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 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 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 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 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.192.0/20 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.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 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.101.104.0/24 AS54508 M5ROCHESTER - M5 Networks, Inc.,US 199.101.105.0/24 AS18649 M5-NETWORKS - M5 Networks, Inc.,US 199.101.107.0/24 AS18649 M5-NETWORKS - M5 Networks, Inc.,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 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 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 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 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 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.10.94.0/23 AS30097 NUWAVE - NuWave,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.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 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.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 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.128.0/24 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.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,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.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 208.86.72.0/21 AS36371 -Reserved AS-,ZZ 208.95.192.0/21 AS18649 M5-NETWORKS - M5 Networks, Inc.,US 208.95.193.0/24 AS36371 -Reserved AS-,ZZ 208.95.195.0/24 AS36371 -Reserved AS-,ZZ 208.95.196.0/24 AS36371 -Reserved AS-,ZZ 208.95.199.0/24 AS36371 -Reserved AS-,ZZ 209.90.192.0/19 AS20428 -Reserved AS-,ZZ 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,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 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.157.160.0/19 AS20428 -Reserved AS-,ZZ 216.157.172.0/24 AS20428 -Reserved AS-,ZZ 216.157.173.0/24 AS20428 -Reserved AS-,ZZ 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 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 Jun 20 22:00:12 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Jun 2014 22:00:12 GMT Subject: BGP Update Report Message-ID: <201406202200.s5KM0C8n078823@wattle.apnic.net> BGP Update Report Interval: 12-Jun-14 -to- 19-Jun-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS47331 170567 6.8% 66.2 -- TTNET TTNet A.S.,TR 2 - AS9829 106400 4.3% 111.8 -- BSNL-NIB National Internet Backbone,IN 3 - AS26615 81963 3.3% 169.3 -- Tim Celular S.A.,BR 4 - AS17222 70092 2.8% 209.2 -- Mundivox do Brasil Ltda,BR 5 - AS8402 36434 1.5% 73.2 -- CORBINA-AS OJSC "Vimpelcom",RU 6 - AS31148 33238 1.3% 32.6 -- FREENET-AS Freenet Ltd.,UA 7 - AS28573 22947 0.9% 6.1 -- NET Servi�os de Comunica��o S.A.,BR 8 - AS14287 22808 0.9% 3801.3 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 9 - AS23752 21667 0.9% 433.3 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 10 - AS41691 20601 0.8% 664.5 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 11 - AS7552 18151 0.7% 12.1 -- VIETEL-AS-AP Viettel Corporation,VN 12 - AS4775 15278 0.6% 268.0 -- GLOBE-TELECOM-AS Globe Telecoms,PH 13 - AS36998 15139 0.6% 13.6 -- SDN-MOBITEL,SD 14 - AS35819 13848 0.6% 33.7 -- MOBILY-AS Etihad Etisalat Company (Mobily),SA 15 - AS23693 13355 0.5% 107.7 -- TELKOMSEL-ASN-ID PT. Telekomunikasi Selular,ID 16 - AS53169 12910 0.5% 806.9 -- Tche Turbo Provedor de Internet LTDA,BR 17 - AS9121 11965 0.5% 39.4 -- TTNET Turk Telekomunikasyon Anonim Sirketi,TR 18 - AS647 11403 0.5% 92.0 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US 19 - AS17557 11329 0.5% 101.2 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 20 - AS10620 10746 0.4% 4.8 -- Telmex Colombia S.A.,CO TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54465 8511 0.3% 8511.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 2 - AS6459 8239 0.3% 8239.0 -- TRANSBEAM - I-2000, Inc.,US 3 - AS14287 22808 0.9% 3801.3 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 4 - AS45590 3262 0.1% 3262.0 -- HGCINTNET-AS-AP Hutch Connect,HK 5 - AS60345 6141 0.2% 3070.5 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 6 - AS26661 8328 0.3% 2776.0 -- JCPS-ASN - Jeffco Public Schools,US 7 - AS33377 3411 0.1% 1705.5 -- FHLBC - Federal Home Loan Bank of Chicago,US 8 - AS6629 8247 0.3% 1649.4 -- NOAA-AS - NOAA,US 9 - AS18135 9230 0.4% 1318.6 -- BTV BTV Cable television,JP 10 - AS58228 2630 0.1% 1315.0 -- IT-TELECOM-AS LLC "IT Telecom",RU 11 - AS7453 2575 0.1% 1287.5 -- ACCELERATION - ACCELERATED DATA WORKS, INC.,US 12 - AS57201 1017 0.0% 1017.0 -- EDF-AS Estonian Defence Forces,EE 13 - AS46972 921 0.0% 921.0 -- NORTHSTAR - NORTH STAR COMPANIES,US 14 - AS18379 879 0.0% 879.0 -- CSMNAP-AS-AP CSMNAP-ASN,ID 15 - AS24311 826 0.0% 826.0 -- CNGI-CMNETV6-AS-AP China Mobile Communications Corporation IPv6 network,CN 16 - AS53169 12910 0.5% 806.9 -- Tche Turbo Provedor de Internet LTDA,BR 17 - AS37447 3028 0.1% 757.0 -- OASIS-SPRL,CD 18 - AS8875 1457 0.1% 728.5 -- SINMA-ASN sinma GmbH,DE 19 - AS24814 4971 0.2% 710.1 -- SCS-AS Syrian Computer Society, scs,SY 20 - AS25516 4220 0.2% 703.3 -- INIT-AS init AG fuer digitale Kommunikation,DE TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 20332 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 121.52.145.0/24 11308 0.4% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 3 - 202.70.64.0/21 10667 0.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 202.70.88.0/21 10473 0.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 5 - 42.83.48.0/20 9206 0.3% AS18135 -- BTV BTV Cable television,JP 6 - 177.190.112.0/22 8987 0.3% AS53169 -- Tche Turbo Provedor de Internet LTDA,BR 7 - 206.152.15.0/24 8511 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 8 - 205.247.12.0/24 8239 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 9 - 192.58.232.0/24 8158 0.3% AS6629 -- NOAA-AS - NOAA,US 10 - 120.28.62.0/24 7699 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 11 - 222.127.0.0/24 7249 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 12 - 46.53.64.0/19 5660 0.2% AS24814 -- SCS-AS Syrian Computer Society, scs,SY AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY 13 - 177.54.145.0/24 4943 0.2% AS4 -- ISI-AS - University of Southern California,US AS28666 -- HOSTLOCATION LTDA,BR 14 - 216.162.0.0/20 4572 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 15 - 208.78.116.0/22 4568 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 16 - 208.73.244.0/22 4568 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 17 - 208.88.232.0/22 4550 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 18 - 208.70.20.0/22 4542 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 19 - 221.183.16.0/23 3595 0.1% AS24311 -- CNGI-CMNETV6-AS-AP China Mobile Communications Corporation IPv6 network,CN AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN 20 - 177.190.112.0/20 3557 0.1% AS53169 -- Tche Turbo Provedor de Internet LTDA,BR 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 jra at baylink.com Sat Jun 21 15:10:35 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 21 Jun 2014 11:10:35 -0400 (EDT) Subject: BCP38.info welcomes dts Message-ID: <20594431.4326.1403363435017.JavaMail.root@benjamin.baylink.com> I'm happy to welcome the *other* author of BCP38, Daniel Senie, to our panel of contributors at the BCP38.info wiki. If you haven't visited the wiki... well, are you BCP38 compliant? :-) If you haven't contributed -- especially if you work on networks larger than mine -- well, here's your monthly reminder to sign up for an account* and help us (and the Entire World) out. Cheers, -- jra * Yes, we are using manual signup because the wikispammers are getting smart. -- 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 jra at baylink.com Sat Jun 21 15:50:53 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 21 Jun 2014 11:50:53 -0400 (EDT) Subject: [VoiceOps] High Quality, Reliable Voice via the Internet / SIPNOC In-Reply-To: <513777D7-718A-4177-AD14-576542C80B20@gmail.com> Message-ID: <18987134.4336.1403365853316.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "PE" > But isn't congestion caused by bytes and not number of packets? So, by > that argument, larger packets will fill the queue faster than smaller > and thus have a higher propensity to drop? And when it does, it is a > bigger chunk of audio so it could actually reduce quality rather than > improve it. Not necessarily. There's *lots* of gear out there that will move 100mb/s all day long with no problems, but if you smack it with too many 50-byte packets per second, it will have a nervous breakdown. Probably less so than formerly, but I suspect there's still a lot that isn't perfect. 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 mpetach at netflight.com Sat Jun 21 17:58:40 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 21 Jun 2014 10:58:40 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <20140618230142.329381876235@rock.dv.isc.org> <02f701cf8b5b$bb477160$31d65420$@com> <044a01cf8be7$5bf605f0$13e211d0$@com> <049501cf8bec$d3b85750$7b2905f0$@com> Message-ID: On Thu, Jun 19, 2014 at 2:24 PM, Lee Howard wrote: > > > On 6/19/14 4:30 PM, "Christopher Morrow" wrote: > > >On Thu, Jun 19, 2014 at 4:27 PM, Lee Howard wrote: > > > >which content providers (large-ish ones) are lagging still? > > https://www.vyncke.org/ipv6status/detailed.php?country=us > > [...] > > Tumblr > Flickr > I'll own up to those, and will start engaging with the devs internally on what is needed to get them dual-stacked. Lee > Thanks! Matt From frnkblk at iname.com Sat Jun 21 19:20:09 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 21 Jun 2014 14:20:09 -0500 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> <20140617232402.0FC23185D08F@rock.dv.isc.org> <1ACF3587-2724-4A25-9042-95C7266F25B3@puck.nether.net> <003801cf8aa7$79a6a690$6cf3f3b0$@iname.com> Message-ID: <009c01cf8d85$d0fea5b0$72fbf110$@iname.com> Communicating off-list regarding TWC. Yes, I had forgotten about Bing. I actually never monitored that host, and no use considering there's no IPv6 on there now. Donley said that Cablelabs moved to a new hosting provider that (at that time) did not support IPv6. I'll chase Charter down again. Fessler was chasing down www.att.net, but I've not received an update on this (BCCing him this message). Frank -----Original Message----- From: Lee Howard [mailto:Lee at asgard.org] Sent: Thursday, June 19, 2014 7:54 AM To: Frank Bulk; 'Jared Mauch' Cc: NANOG Subject: Re: Ars Technica on IPv4 exhaustion On 6/17/14 11:43 PM, "Frank Bulk" wrote: >These sites used to be dual-stacked: >www.cablelabs.com (over 180 days ago via ipv6.cablelabs.com) >www.att.net (over 44 days ago) >www.charter.com (over 151 days) >www.globalcrossing.com (over 802 days) >www.timewarnercable.com (over 593 days) Check that one again. Surprised you didn't mention www.bing.com. Lee From itg at itechgeek.com Sat Jun 21 21:15:24 2014 From: itg at itechgeek.com (ITechGeek) Date: Sat, 21 Jun 2014 17:15:24 -0400 Subject: Temporary IP allocations In-Reply-To: References: Message-ID: Does anyone know if ARIN has the equivalent of this? http://www.ripe.net/ripe/docs/ripe-587 Abstract This document outlines policies for temporary direct assignments of IPv4/IPv6 address space and Autonomous System (AS) Numbers in the RIPE NCC service region. From jcurran at arin.net Sat Jun 21 21:48:37 2014 From: jcurran at arin.net (John Curran) Date: Sat, 21 Jun 2014 21:48:37 +0000 Subject: Temporary IP allocations In-Reply-To: References: Message-ID: <6925468E-81B5-49DA-A32B-4B3BD425B7A4@arin.net> On Jun 21, 2014, at 10:15 PM, ITechGeek wrote: > Does anyone know if ARIN has the equivalent of this? > http://www.ripe.net/ripe/docs/ripe-587 ARIN has policy for "EXPERIMENTAL INTERNET RESOURCE ALLOCATIONS" which is similar; please do not hesitate to contact me if you have any questions about this policy. Thanks! /John John Curran President and CEO ARIN From frnkblk at iname.com Sat Jun 21 21:49:11 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 21 Jun 2014 16:49:11 -0500 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <4C91045B-6C3C-4383-88EE-BE52376BBF15@delong.com> Message-ID: <00a601cf8d9a$a35461d0$e9fd2570$@iname.com> I'm looking for a new consumer router to offer our customers that has GigE ports and supports IEEE 802.11ac, and all the products that our reseller and their partners have suggested don't have IPv6 Ready certification or the vendor can't confirm they meet RIPE's 554 document. D-Link has a long list of approved products, but I chose to stop using their products for other reasons. If any can recommend a mid-range consumer router that you think would meet our needs, please drop me a note off-list. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gary Buhrmaster Sent: Thursday, June 19, 2014 9:41 PM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: Ars Technica on IPv4 exhaustion On Thu, Jun 19, 2014 at 10:47 PM, Owen DeLong wrote: ..... > Ideally, it would be nice if the UNH/IOL and/or CEA could come up with a meaningful definition of IPv6 support and a logo to go with it that we could tell consumers to look for on the box. Ideally, this would be a set of standards that users of the logo agree to abide by rather than a fee-based testing regime that excludes smaller players. You mean something like the IPv6 Ready logo at http://www.ipv6ready.org ? From faisal at snappytelecom.net Sun Jun 22 02:08:59 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sun, 22 Jun 2014 02:08:59 +0000 (GMT) Subject: HiCap Internet Service Provider in Dominican Republic ? In-Reply-To: <404465090.785278.1403402887388.JavaMail.root@snappytelecom.net> Message-ID: <767825745.785279.1403402939598.JavaMail.root@snappytelecom.net> Hello, Anyone here knows who can provide Fat pipe Internet (IP Transit) in the Dominican Republic ? Please contact me off list. Thanks. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net From wesley.george at twcable.com Sun Jun 22 21:58:00 2014 From: wesley.george at twcable.com (George, Wes) Date: Sun, 22 Jun 2014 17:58:00 -0400 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <009c01cf8d85$d0fea5b0$72fbf110$@iname.com> References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> <20140617232402.0FC23185D08F@rock.dv.isc.org> <1ACF3587-2724-4A25-9042-95C7266F25B3@puck.nether.net> <003801cf8aa7$79a6a690$6cf3f3b0$@iname.com> <009c01cf8d85$d0fea5b0$72fbf110$@iname.com> Message-ID: On 6/21/14, 3:20 PM, "Frank Bulk" wrote: >Donley said that Cablelabs moved to a new hosting provider that (at that >time) did not support IPv6. Www.cablelabs.com does have a AAAA, it's just that cablelabs.com doesn't. Unfortunately all too common. We're also leaning on them to be more complete in their IPv6 support. Wes George 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 owen at delong.com Mon Jun 23 01:41:24 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Jun 2014 18:41:24 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <00a601cf8d9a$a35461d0$e9fd2570$@iname.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <39E5837B-337A-40A1-A458-1FA9C9BEC1FD@delong.com> <747CB16C-1401-420D-9201-51CE3D9622EB@delong.com> <4C91045B-6C3C-4383-88EE-BE52376BBF15@delong.com> <00a601cf8d9a$a35461d0$e9fd2570$@iname.com> Message-ID: <4C377FA3-9D6D-4838-8313-EC0D23BB767B@delong.com> This looks somewhat promising: http://www.downloads.netgear.com/files/GDC/R7000/R7000_DS_vA_19Mar14.pdf ~$200 If you want something cheaper, this: http://www.downloads.netgear.com/files/GDC/R6300V2/R6300v2_DS_20Jun13.pdf is about $100. I haven’t tried either of these myself yet, but other Netgear home products with IPv6 support have worked reasonably well in my experience and these are newer generation and do list IPv6 support in their data sheets. There may be cheaper models. I haven’t done any sort of thorough investigation. Of course the Apple Airport Express and Airport Extreme models also have 802.11ac support and known good IPv6 implementations. Owen On Jun 21, 2014, at 2:49 PM, Frank Bulk wrote: > I'm looking for a new consumer router to offer our customers that has GigE ports and supports IEEE 802.11ac, and all the products that our reseller and their partners have suggested don't have IPv6 Ready certification or the vendor can't confirm they meet RIPE's 554 document. D-Link has a long list of approved products, but I chose to stop using their products for other reasons. If any can recommend a mid-range consumer router that you think would meet our needs, please drop me a note off-list. > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gary Buhrmaster > Sent: Thursday, June 19, 2014 9:41 PM > To: Owen DeLong > Cc: nanog at nanog.org > Subject: Re: Ars Technica on IPv4 exhaustion > > On Thu, Jun 19, 2014 at 10:47 PM, Owen DeLong wrote: > ..... >> Ideally, it would be nice if the UNH/IOL and/or CEA could come up with a meaningful definition of IPv6 support and a logo to go with it that we could tell consumers to look for on the box. Ideally, this would be a set of standards that users of the logo agree to abide by rather than a fee-based testing regime that excludes smaller players. > > You mean something like the IPv6 Ready logo at http://www.ipv6ready.org ? > From nanog at bitfreak.org Mon Jun 23 01:41:06 2014 From: nanog at bitfreak.org (Darren Pilgrim) Date: Sun, 22 Jun 2014 18:41:06 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> Message-ID: <53A785B2.8020103@bitfreak.org> On 6/18/2014 11:49 AM, TJ wrote: > Yeah, Verizon and VZW are not the same animal ... FiOS *needs* to get their > IPv6 house in order. > Anyone have any information on that front ...? For FiOS, the ONTs do transparent muckery at the IP level and aren't yet capable of equivalent IPv6 muckery. Verizon is also quite confident they don't actually have to do anything about it. Instead, they'll just roll out 6RD relays like Qwest/Centurylink did. You didn't REALLY need a 1480 MTU, did you? For Comcast business services, the SMC box on my demarc panel isn't IPv6 capable and neither are any of Comcast's other business CPE. From owen at delong.com Mon Jun 23 01:56:01 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Jun 2014 18:56:01 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <53A785B2.8020103@bitfreak.org> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> Message-ID: On Jun 22, 2014, at 6:41 PM, Darren Pilgrim wrote: > On 6/18/2014 11:49 AM, TJ wrote: >> Yeah, Verizon and VZW are not the same animal ... FiOS *needs* to get their >> IPv6 house in order. >> Anyone have any information on that front ...? > > For FiOS, the ONTs do transparent muckery at the IP level and aren't yet capable of equivalent IPv6 muckery. Verizon is also quite confident they don't actually have to do anything about it. Instead, they'll just roll out 6RD relays like Qwest/Centurylink did. You didn't REALLY need a 1480 MTU, did you? > > For Comcast business services, the SMC box on my demarc panel isn't IPv6 capable and neither are any of Comcast's other business CPE. Not true. The Netgear CCB tried to install here just a couple of days ago is IPv6 capable. Unfortunately, it breaks IPv4 by not being capable of bridge mode and insisting on NATing everything inside unless you subscribe to static IPv4 addresses from Comcast. OTOH, you can supply your own Motorola Surfboard DOCSIS 3 modem and it works just fine with Comcast Business. Owen From nanog at bitfreak.org Mon Jun 23 02:07:19 2014 From: nanog at bitfreak.org (Darren Pilgrim) Date: Sun, 22 Jun 2014 19:07:19 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> Message-ID: <53A78BD7.1010500@bitfreak.org> On 6/22/2014 6:56 PM, Owen DeLong wrote: > On Jun 22, 2014, at 6:41 PM, Darren Pilgrim > wrote: >> For Comcast business services, the SMC box on my demarc panel isn't >> IPv6 capable and neither are any of Comcast's other business CPE. > > Not true. The Netgear CCB tried to install here just a couple of days > ago is IPv6 capable. Unfortunately, it breaks IPv4 by not being > capable of bridge mode and insisting on NATing everything inside > unless you subscribe to static IPv4 addresses from Comcast. What's the model number? The Comcast techs here are quite insistent that none of the CPE capable of routed subnets are able to do IPv6. > OTOH, you can supply your own Motorola Surfboard DOCSIS 3 modem and > it works just fine with Comcast Business. Have you tried using that with a routed subnet? From owen at delong.com Mon Jun 23 02:16:10 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Jun 2014 19:16:10 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <53A78BD7.1010500@bitfreak.org> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> <53A78BD7.1010500@bitfreak.org> Message-ID: <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> On Jun 22, 2014, at 7:07 PM, Darren Pilgrim wrote: > On 6/22/2014 6:56 PM, Owen DeLong wrote: >> On Jun 22, 2014, at 6:41 PM, Darren Pilgrim >> wrote: >>> For Comcast business services, the SMC box on my demarc panel isn't >>> IPv6 capable and neither are any of Comcast's other business CPE. >> >> Not true. The Netgear CCB tried to install here just a couple of days >> ago is IPv6 capable. Unfortunately, it breaks IPv4 by not being >> capable of bridge mode and insisting on NATing everything inside >> unless you subscribe to static IPv4 addresses from Comcast. > > What's the model number? The Comcast techs here are quite insistent that none of the CPE capable of routed subnets are able to do IPv6. > >> OTOH, you can supply your own Motorola Surfboard DOCSIS 3 modem and >> it works just fine with Comcast Business. > > Have you tried using that with a routed subnet? Not sure what you mean by “routed subnet”. I’ve got a router hooked up to it and everything on my internal network(s) is behind that router, so I’m using it with routed subnets by my definition of that term. If you have some specific way of setting up your services that’s different from that, you’d need to be specific before I could usefully comment. Owen From frnkblk at iname.com Mon Jun 23 02:20:05 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 22 Jun 2014 21:20:05 -0500 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: References: <32832593.4076.1403046439981.JavaMail.root@benjamin.baylink.com> <20140617232402.0FC23185D08F@rock.dv.isc.org> <1ACF3587-2724-4A25-9042-95C7266F25B3@puck.nether.net> <003801cf8aa7$79a6a690$6cf3f3b0$@iname.com> <009c01cf8d85$d0fea5b0$72fbf110$@iname.com> Message-ID: <000f01cf8e89$a5ac9b10$f105d130$@iname.com> They have one on www.cablelabs.com, but it's not reachable: root at nagios:/home/fbulk# dig AAAA www.cablelabs.com +short 2620:0:2b10:101::3 root at nagios:/home/fbulk# wget -6 www.cablelabs.com --2014-06-22 21:17:31-- http://www.cablelabs.com/ Resolving www.cablelabs.com... 2620:0:2b10:101::3 Connecting to www.cablelabs.com|2620:0:2b10:101::3|:80... failed: Network is unreachable. root at nagios:/home/fbulk# It's been so long that I had forgotten that I had suggested they remove the AAAA while they don't actually have IPv6 connectivity. Perhaps they want to see how well Happy Eyeballs works. =) Frank -----Original Message----- From: George, Wes [mailto:wesley.george at twcable.com] Sent: Sunday, June 22, 2014 4:58 PM To: Frank Bulk Cc: NANOG; Donley, Chris (Cable Labs) Subject: Re: Ars Technica on IPv4 exhaustion On 6/21/14, 3:20 PM, "Frank Bulk" wrote: >Donley said that Cablelabs moved to a new hosting provider that (at that >time) did not support IPv6. Www.cablelabs.com does have a AAAA, it's just that cablelabs.com doesn't. Unfortunately all too common. We're also leaning on them to be more complete in their IPv6 support. Wes George 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 nanog at bitfreak.org Mon Jun 23 02:22:10 2014 From: nanog at bitfreak.org (Darren Pilgrim) Date: Sun, 22 Jun 2014 19:22:10 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> <53A78BD7.1010500@bitfreak.org> <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> Message-ID: <53A78F52.1040107@bitfreak.org> On 6/22/2014 7:16 PM, Owen DeLong wrote: > On Jun 22, 2014, at 7:07 PM, Darren Pilgrim wrote: >> On 6/22/2014 6:56 PM, Owen DeLong wrote: >>> OTOH, you can supply your own Motorola Surfboard DOCSIS 3 modem and >>> it works just fine with Comcast Business. >> >> Have you tried using that with a routed subnet? > > Not sure what you mean by “routed subnet”. Comcast gives you a block of non-RFC1918 addresses. From andris at hpl.hp.com Mon Jun 23 02:28:46 2014 From: andris at hpl.hp.com (Kalnozols, Andris) Date: Sun, 22 Jun 2014 19:28:46 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> <53A78BD7.1010500@bitfreak.org> <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> Message-ID: <53A790DE.7070800@hpl.hp.com> On 6/22/2014 7:16 PM, Owen DeLong wrote: > > On Jun 22, 2014, at 7:07 PM, Darren Pilgrim wrote: > >> On 6/22/2014 6:56 PM, Owen DeLong wrote: >>> On Jun 22, 2014, at 6:41 PM, Darren Pilgrim >>> wrote: >>>> For Comcast business services, the SMC box on my demarc panel isn't >>>> IPv6 capable and neither are any of Comcast's other business CPE. >>> >>> Not true. The Netgear CCB tried to install here just a couple of days >>> ago is IPv6 capable. Unfortunately, it breaks IPv4 by not being >>> capable of bridge mode and insisting on NATing everything inside >>> unless you subscribe to static IPv4 addresses from Comcast. >> >> What's the model number? The Comcast techs here are quite insistent >> that none of the CPE capable of routed subnets are able to do IPv6. >> >>> OTOH, you can supply your own Motorola Surfboard DOCSIS 3 modem and >>> it works just fine with Comcast Business. >> >> Have you tried using that with a routed subnet? > > Not sure what you mean by “routed subnet”. > > I’ve got a router hooked up to it and everything on my internal network(s) > is behind that router, so I’m using it with routed subnets by my definition > of that term. If you have some specific way of setting up your services > that’s different from that, you’d need to be specific before I could usefully > comment. My experience as a Comcast Business customer with a /29 IPv4 subnet was that swapping out the SMC modem/router for an IPV6-capable Motorola DOCSIS 3 modem meant that I could no longer have the /29. Andris From frnkblk at iname.com Mon Jun 23 02:32:48 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 22 Jun 2014 21:32:48 -0500 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <53A785B2.8020103@bitfreak.org> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> Message-ID: <001101cf8e8b$6eded790$4c9c86b0$@iname.com> Our own fiber access vendor now does have IPv6 support, but I haven't been able to keep it in production because a ~7.8 Mbps traffic IPv6 ND traffic loop (side effect of another bug) knocked out voice services. Turns out that the traffic queue for IPv6 and DHCP (for the ONT's voice services) are the same, and so I essentially DDoSed my customers' voice service. Now, I'll admit that ~7.8 Mbps of Neighbor Discovery traffic is atypical, but I did learn that our access vendor does not have any rate-limiters in place for that kind of traffic. The vendor is planning to put voice in a higher priority queue to avoid the voice-loss issue. Some of you might ask why the access platform needs to be aware of ND traffic. My understanding is that for scalability and privacy reasons you don't want to flood that traffic to all access ports, but just to the ones that should respond. The platform needs to do some traffic inspection. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Darren Pilgrim Sent: Sunday, June 22, 2014 8:41 PM To: trejrco at gmail.com; Lee Howard Cc: NANOG Subject: Re: Ars Technica on IPv4 exhaustion On 6/18/2014 11:49 AM, TJ wrote: > Yeah, Verizon and VZW are not the same animal ... FiOS *needs* to get their > IPv6 house in order. > Anyone have any information on that front ...? For FiOS, the ONTs do transparent muckery at the IP level and aren't yet capable of equivalent IPv6 muckery. Verizon is also quite confident they don't actually have to do anything about it. Instead, they'll just roll out 6RD relays like Qwest/Centurylink did. You didn't REALLY need a 1480 MTU, did you? For Comcast business services, the SMC box on my demarc panel isn't IPv6 capable and neither are any of Comcast's other business CPE. From frnkblk at iname.com Mon Jun 23 02:41:54 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 22 Jun 2014 21:41:54 -0500 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <53A790DE.7070800@hpl.hp.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> <53A78BD7.1010500@bitfreak.org> <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> <53A790DE.7070800@hpl.hp.com> Message-ID: <001701cf8e8c$b21b1a40$16514ec0$@iname.com> Did they ever explain why? Did the SMC function as a router, and act as the customer side of a stub network that allowed that /29 to hang off the router? If that was the case, and the Motorola D3 modem was L2-only, that might explain the change in capability. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kalnozols, Andris Sent: Sunday, June 22, 2014 9:29 PM To: nanog at nanog.org Subject: Re: Ars Technica on IPv4 exhaustion My experience as a Comcast Business customer with a /29 IPv4 subnet was that swapping out the SMC modem/router for an IPV6-capable Motorola DOCSIS 3 modem meant that I could no longer have the /29. Andris From andris at hpl.hp.com Mon Jun 23 03:32:40 2014 From: andris at hpl.hp.com (Kalnozols, Andris) Date: Sun, 22 Jun 2014 20:32:40 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <001701cf8e8c$b21b1a40$16514ec0$@iname.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> <53A78BD7.1010500@bitfreak.org> <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> <53A790DE.7070800@hpl.hp.com> <001701cf8e8c$b21b1a40$16514ec0$@iname.com> Message-ID: <53A79FD8.1010301@hpl.hp.com> On 6/22/2014 7:41 PM, Frank Bulk wrote: > Did they ever explain why? Did the SMC function as a router, and act as the > customer side of a stub network that allowed that /29 to hang off the > router? If that was the case, and the Motorola D3 modem was L2-only, that > might explain the change in capability. They didn't really go into detail. Your theory sounds correct; the four ports on the SMC router default to 10.1.10.0/24 but will also handle a routable /29 address from the WAN side of another router plugged into it. Since Comcast now charges $19.95 instead of $9.95/month for a /29, I inquired about the cost of an IPv6 assignment; same price as I recall being told. I then asked if that was for a /60 or /56 and he said no, eight IPv6 addresses (/125?). I politely thanked him and ended the phone call. I realize that I could have gotten a more realistic answer from another Comcast rep with more v6-fu but I didn't pursue it. Andris > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kalnozols, Andris > Sent: Sunday, June 22, 2014 9:29 PM > To: nanog at nanog.org > Subject: Re: Ars Technica on IPv4 exhaustion > > > > My experience as a Comcast Business customer with a /29 IPv4 subnet was > that swapping out the SMC modem/router for an IPV6-capable Motorola > DOCSIS 3 modem meant that I could no longer have the /29. > > Andris > > > From laszlo at heliacal.net Mon Jun 23 03:41:34 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Mon, 23 Jun 2014 03:41:34 +0000 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <53A79FD8.1010301@hpl.hp.com> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> <53A78BD7.1010500@bitfreak.org> <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> <53A790DE.7070800@hpl.hp.com> <001701cf8e8c$b21b1a40$16514ec0$@iname.com> <53A79FD8.1010301@hpl.hp.com> Message-ID: <32F1C1EB-E35B-4BD0-A727-12C8C220A4EB@heliacal.net> On Jun 23, 2014, at 3:32 AM, "Kalnozols, Andris" wrote: > > On 6/22/2014 7:41 PM, Frank Bulk wrote: >> Did they ever explain why? Did the SMC function as a router, and act as the >> customer side of a stub network that allowed that /29 to hang off the >> router? If that was the case, and the Motorola D3 modem was L2-only, that >> might explain the change in capability. > The Comcast business SMC gateway speaks RIP to make the routed /29 work.. in theory it could be put into bridge mode and you can do the RIP yourself but they don't support that configuration (you'd need the key to configure it successfully and they didn't want to do when I asked). If you poke around in the web UI, it does support IPv6 in some form, but it doesn't seem to be active for me. If you don't have a static IP block from them and thus don't have the need to use RIP you can just use a regular DOCSIS 3 cable modem and get IPv6, but you only get one IPv4 number that way. -Laszlo > They didn't really go into detail. Your theory sounds correct; the > four ports on the SMC router default to 10.1.10.0/24 but will also > handle a routable /29 address from the WAN side of another router > plugged into it. > > Since Comcast now charges $19.95 instead of $9.95/month for a /29, > I inquired about the cost of an IPv6 assignment; same price as I > recall being told. I then asked if that was for a /60 or /56 and > he said no, eight IPv6 addresses (/125?). I politely thanked him > and ended the phone call. I realize that I could have gotten a > more realistic answer from another Comcast rep with more v6-fu > but I didn't pursue it. > > Andris > > > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kalnozols, Andris >> Sent: Sunday, June 22, 2014 9:29 PM >> To: nanog at nanog.org >> Subject: Re: Ars Technica on IPv4 exhaustion >> >> >> >> My experience as a Comcast Business customer with a /29 IPv4 subnet was >> that swapping out the SMC modem/router for an IPV6-capable Motorola >> DOCSIS 3 modem meant that I could no longer have the /29. >> >> Andris >> >> >> From owen at delong.com Mon Jun 23 05:04:09 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Jun 2014 22:04:09 -0700 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <32F1C1EB-E35B-4BD0-A727-12C8C220A4EB@heliacal.net> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> <53A78BD7.1010500@bitfreak.org> <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> <53A790DE.7070800@hpl.hp.com> <001701cf8e8c$b21b1a40$16514ec0$@iname.com> <53A79FD8.1010301@hpl.hp.com> <32F1C1EB-E35B-4BD0-A727-12C8C220A4EB@heliacal.net> Message-ID: <763B2A69-ACF9-4E54-8A05-45EC20AFEF65@delong.com> On Jun 22, 2014, at 20:41 , Laszlo Hanyecz wrote: > > On Jun 23, 2014, at 3:32 AM, "Kalnozols, Andris" wrote: > >> >> On 6/22/2014 7:41 PM, Frank Bulk wrote: >>> Did they ever explain why? Did the SMC function as a router, and act as the >>> customer side of a stub network that allowed that /29 to hang off the >>> router? If that was the case, and the Motorola D3 modem was L2-only, that >>> might explain the change in capability. >> > > The Comcast business SMC gateway speaks RIP to make the routed /29 work.. in theory it could be put into bridge mode and you can do the RIP yourself but they don't support that configuration (you'd need the key to configure it successfully and they didn't want to do when I asked). If you poke around in the web UI, it does support IPv6 in some form, but it doesn't seem to be active for me. > > If you don't have a static IP block from them and thus don't have the need to use RIP you can just use a regular DOCSIS 3 cable modem and get IPv6, but you only get one IPv4 number that way. In my experience, if you put a switch behind the modem (not a router), you can get as many IPv4 numbers as you have devices attached to the switch on Business Class. On residential, you're limited to one, but I have gotten multiples on business class. Owen From mysidia at gmail.com Mon Jun 23 07:24:48 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 23 Jun 2014 02:24:48 -0500 Subject: Ars Technica on IPv4 exhaustion In-Reply-To: <32F1C1EB-E35B-4BD0-A727-12C8C220A4EB@heliacal.net> References: <23859677.4070.1403036410625.JavaMail.root@benjamin.baylink.com> <9579E959-CEC8-4C1A-8C26-97CE4E4E0861@puck.nether.net> <53A0BD36.5060703@gmail.com> <53A785B2.8020103@bitfreak.org> <53A78BD7.1010500@bitfreak.org> <63CB7403-4AC0-4F4C-859F-BF2DB8728F91@delong.com> <53A790DE.7070800@hpl.hp.com> <001701cf8e8c$b21b1a40$16514ec0$@iname.com> <53A79FD8.1010301@hpl.hp.com> <32F1C1EB-E35B-4BD0-A727-12C8C220A4EB@heliacal.net> Message-ID: On Sun, Jun 22, 2014 at 10:41 PM, Laszlo Hanyecz wrote: > The Comcast business SMC gateway speaks RIP to make the >routed /29 work.. in theory it could be put into bridge mode and you can do >the RIP yourself but they don't support that configuration (you'd need the >key to configure it successfully and they didn't want to do when I asked). If It begins to sound like a job for a packet capture tool to grab a copy of a SMC's outgoing broadcast, and then an Ad Infinitium replay of the last 30 second broadcast. Even with md5 auth; RIPv2 protocol basically has nothing preventing message replay, so, as long as your original router is offline such that the sequence number does not increase, and if you can continuously replay your router's last RIP broadcast, you may not even need to know any keys...... >you poke around in the web UI, it does support IPv6 in some form, but it -- -JH From stovetop_202 at yahoo.com Sun Jun 22 23:45:28 2014 From: stovetop_202 at yahoo.com (stovetop 202) Date: Sun, 22 Jun 2014 16:45:28 -0700 Subject: short, two part question ICANN Vs. The World Message-ID: <1403480728.65597.YahooMailNeo@web161401.mail.bf1.yahoo.com> Topic: ICANN Vs. The World. The question at hand is.. Do countries/businesses have to affiliate or utilize any of those services provided by ICANN other than the assignment of an IP address?  And can you get away with LAN/CAN/MAN stand-alone systems [instead of utilizing DNS-via-ICANN]?? Example:  Is it legal to cut off those DNS systems and loop in backwards?  (instead of bidirectional).  **  I don't want my city/schools/other systems hooked into the World Wide Web. // someone let me know when you get a chance. From phulshof at aimvalley.nl Mon Jun 23 09:13:57 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Mon, 23 Jun 2014 11:13:57 +0200 Subject: MACsec SFP Message-ID: <53A7EFD5.8080502@aimvalley.nl> All, Last year some people on this list expressed interest in smart SFP options, like e.g. MACsec. As a network consultant and systems architect with AimValley in the Netherlands, I'm currently in the process of gathering feature and market information for such a device, and I would welcome some feedback from interested people. Discussion about other types of smart SFPs would also be welcome. Feel free to contact me directly using the contact information below. Kind regards, Pieter Hulshoff Network Consultant & Systems Architect Aimvalley B.V. Utrechtseweg 38 1213 TV Hilversum +31 35 689 1936 phulshof at aimvalley.nl http://www.aimvalley.com From michael.holstein at csuohio.edu Mon Jun 23 20:05:07 2014 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Mon, 23 Jun 2014 20:05:07 +0000 Subject: short, two part question ICANN Vs. The World In-Reply-To: <1403480728.65597.YahooMailNeo@web161401.mail.bf1.yahoo.com> References: <1403480728.65597.YahooMailNeo@web161401.mail.bf1.yahoo.com> Message-ID: <1403553906798.14718@csuohio.edu> Short answer, Yes .. provided you don't care if anyone can see it. Take a look at what NEW.NET tried with DNS back in the day. Cheers, Michael Holstein Cleveland State University ________________________________________ From: NANOG on behalf of stovetop 202 Sent: Sunday, June 22, 2014 7:45 PM To: nanog at nanog.org Subject: short, two part question ICANN Vs. The World Topic: ICANN Vs. The World. The question at hand is.. Do countries/businesses have to affiliate or utilize any of those services provided by ICANN other than the assignment of an IP address? And can you get away with LAN/CAN/MAN stand-alone systems [instead of utilizing DNS-via-ICANN]?? Example: Is it legal to cut off those DNS systems and loop in backwards? (instead of bidirectional). ** I don't want my city/schools/other systems hooked into the World Wide Web. // someone let me know when you get a chance. From stovetop_202 at yahoo.com Mon Jun 23 21:21:52 2014 From: stovetop_202 at yahoo.com (stovetop 202) Date: Mon, 23 Jun 2014 14:21:52 -0700 Subject: short, two part question ICANN Vs. The World In-Reply-To: <1403553906798.14718@csuohio.edu> References: <1403480728.65597.YahooMailNeo@web161401.mail.bf1.yahoo.com> <1403553906798.14718@csuohio.edu> Message-ID: <1403558512.59036.YahooMailNeo@web161403.mail.bf1.yahoo.com> What do you mean by if anyone can see it? The lines are now closed off from the public's view.. but the textbooks still teach you that you should be able to have access freely.  Is it the data on the hard line that you're worried people can see? On Monday, June 23, 2014 4:05 PM, Michael O Holstein wrote: Short answer, Yes .. provided you don't care if anyone can see it. Take a look at what NEW.NET tried with DNS back in the day. Cheers, Michael Holstein Cleveland State University ________________________________________ From: NANOG on behalf of stovetop 202 Sent: Sunday, June 22, 2014 7:45 PM To: nanog at nanog.org Subject: short, two part question ICANN Vs. The World Topic: ICANN Vs. The World. The question at hand is.. Do countries/businesses have to affiliate or utilize any of those services provided by ICANN other than the assignment of an IP address?  And can you get away with LAN/CAN/MAN stand-alone systems [instead of utilizing DNS-via-ICANN]?? Example: Is it legal to cut off those DNS systems and loop in backwards?  (instead of bidirectional).  **  I don't want my city/schools/other systems hooked into the World Wide Web. // someone let me know when you get a chance. From lyndon at orthanc.ca Mon Jun 23 21:47:57 2014 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 23 Jun 2014 14:47:57 -0700 Subject: Canada and IPv6 (& DNSSEC) In-Reply-To: References: Message-ID: <5C510A1B-9ECA-444C-A533-C669D8680E59@orthanc.ca> On Jun 20, 2014, at 6:24 AM, Jacques Latour wrote: > Just as an indicator, we have 316 .ca domains with IPv6 glue records :-( Part of the problem might be that two of the bigger registrars (Webnames and easyDNS) *still* can't handle input of IPv6 addresses in their management panels - you have to initiate a support request and have them enter the records manually. And neither ca do a zone transfer from an IPv6-only master. I tried a little experiment a couple of months back. I set up a new domain, IPv6 only - not an A record in sight, including for the name servers. I then tried getting the name servers and glue records registered, first through Webnames, then through easyDNS. Both required manual intervention to set this up. I then tried using their secondary DNS services to add them as additional slave servers. Neither of them is capable of providing secondary DNS to an IPv6-only domain. In both cases, they can only initiate an xfer against an IPv4 master. Given the current state of affairs with the registrar infrastructure, it doesn't surprise me one bit those numbers are so low. --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 johnl at iecc.com Mon Jun 23 22:56:58 2014 From: johnl at iecc.com (John Levine) Date: 23 Jun 2014 22:56:58 -0000 Subject: short, two part question ICANN Vs. The World In-Reply-To: <1403558512.59036.YahooMailNeo@web161403.mail.bf1.yahoo.com> Message-ID: <20140623225658.8850.qmail@joyce.lan> In article <1403558512.59036.YahooMailNeo at web161403.mail.bf1.yahoo.com> you write: >What do you mean by if anyone can see it? You can easily set up your own tree of DNS names and servers. The protocol is public, and the software is widely available for free. But if your DNS names and servers aren't findable starting from the ICANN root, your names won't resolve for anyone other than you and your close friends who happen to be using your names rather than ICANN's names. Like the guy said, read up on the failure of NET.NET, and about a dozen other alternate roots. Warning: you quickly get deep into tinfoil hat territory with the other alternates. R's, John From randy at psg.com Mon Jun 23 23:24:54 2014 From: randy at psg.com (Randy Bush) Date: Tue, 24 Jun 2014 08:24:54 +0900 Subject: short, two part question ICANN Vs. The World In-Reply-To: <1403480728.65597.YahooMailNeo@web161401.mail.bf1.yahoo.com> References: <1403480728.65597.YahooMailNeo@web161401.mail.bf1.yahoo.com> Message-ID: > Is it legal to cut off those DNS systems and loop in backwards? >  (instead of bidirectional).  **  I don't want my city/schools/other > systems hooked into the World Wide Web. // someone let me know when > you get a chance. please do so on your network. it will reduce the nut postings on the internet. randy From streiner at cluebyfour.org Mon Jun 23 21:24:17 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 23 Jun 2014 17:24:17 -0400 (EDT) Subject: short, two part question ICANN Vs. The World In-Reply-To: <1403558512.59036.YahooMailNeo@web161403.mail.bf1.yahoo.com> References: <1403480728.65597.YahooMailNeo@web161401.mail.bf1.yahoo.com> <1403553906798.14718@csuohio.edu> <1403558512.59036.YahooMailNeo@web161403.mail.bf1.yahoo.com> Message-ID: On Mon, 23 Jun 2014, stovetop 202 wrote: > What do you mean by if anyone can see it? > The lines are now closed off from the public's view.. but the textbooks > still teach you that you should be able to have access freely.  Is it > the data on the hard line that you're worried people can see? It would help if you'd provide an explanation of what you're trying to accomplish. It almost sounds like some combination of firewalls and proxy servers to provide some separation between your network(s) and the rest of the global Internet might be a more functional solution than doing odd things with DNS. Bear in mind that a lot of the answers you get will probably be along the lines of "it depends" or "this might work", and come with an implied disclaimer (no guarantees). People might also recommend that you consider engaging a consultant to design/build what you need. jms From kmedcalf at dessus.com Tue Jun 24 05:55:07 2014 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 23 Jun 2014 23:55:07 -0600 Subject: short, two part question ICANN Vs. The World In-Reply-To: <1403480728.65597.YahooMailNeo@web161401.mail.bf1.yahoo.com> Message-ID: <23baa81b0780ca4d8ee279c880771564@mail.dessus.com> >The question at hand is.. Do countries/businesses have to affiliate or >utilize any of those services provided by ICANN other than the assignment >of an IP address?   No. >And can you get away with LAN/CAN/MAN stand-alone systems [instead of utilizing DNS-via-ICANN]?? Yes. >Example: >Is it legal to cut off those DNS systems and loop in backwards?  (instead >of bidirectional).  **  I don't want my city/schools/other systems hooked >into the World Wide Web. // someone let me know when you get a chance. Yes. Sounds like you want private (discontiguous) network space. There is no need to be a part of the internet if you don't want to be, but that desire does not prevent you in any way from utilizing internet "technology" discontiguously (ie, separate and apart from the Internet). From saku at ytti.fi Tue Jun 24 06:37:25 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Jun 2014 09:37:25 +0300 Subject: MACsec SFP In-Reply-To: <53A7EFD5.8080502@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> Message-ID: <20140624063725.GA25828@pob.ytti.fi> On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote: > feature and market information for such a device, and I would welcome some > feedback from interested people. Discussion about other types of smart SFPs > would also be welcome. Feel free to contact me directly using the contact > information below. I'd do questionable things for subrate SFP, SFP which I can put to 1GE port and have 10M and 100M rates available. Or to 10GE port and get 1GE, 100M and 10M Use case is network generation upgrade where you still have one or two 100M ports for MGMT ports etc. There are quite few service SFP already available, RAD does E1 over IP/ETH tunnels in SFP, Huawei has router-in-SFP, JDSU has ethernet probe in SFP, probably quite few others. -- ++ytti From bmanning at isi.edu Tue Jun 24 07:30:26 2014 From: bmanning at isi.edu (manning bill) Date: Tue, 24 Jun 2014 00:30:26 -0700 Subject: short, two part question ICANN Vs. The World In-Reply-To: <23baa81b0780ca4d8ee279c880771564@mail.dessus.com> References: <23baa81b0780ca4d8ee279c880771564@mail.dessus.com> Message-ID: On 23June2014Monday, at 22:55, Keith Medcalf wrote: >> The question at hand is.. Do countries/businesses have to affiliate or >> utilize any of those services provided by ICANN other than the assignment >> of an IP address? > > No. except for RFC 1918 and ULA space, which require no coordination whatsoever > >> And can you get away with LAN/CAN/MAN stand-alone systems [instead of utilizing DNS-via-ICANN]?? > > Yes. > >> Example: > > >> Is it legal to cut off those DNS systems and loop in backwards? (instead >> of bidirectional). ** I don't want my city/schools/other systems hooked >> into the World Wide Web. // someone let me know when you get a chance. > > Yes. Sounds like you want private (discontiguous) network space. There is no need to be a part of the internet if you don't want to be, but that desire does not prevent you in any way from utilizing internet "technology" discontiguously (ie, separate and apart from the Internet). > what does “loop in backwards” mean? it is possible (and there are production systems) to “tap” the Internet and load/fill/examine DNS caches of Internet DNS traffic. NSA and its industrial partners (like Farsight Security) do this for a living. there are many corporations that have built/use enclaved or walled garden networks for internal use that have no visibility to the Internet or its applications (like WWW). Its not that hard to do… folks have been doing it for decades. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 From andreas.larsen at ip-only.se Tue Jun 24 07:59:48 2014 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Tue, 24 Jun 2014 07:59:48 +0000 Subject: MACsec SFP In-Reply-To: <20140624063725.GA25828@pob.ytti.fi> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> Message-ID: <3752E484-1C5B-45E3-80AE-2F37D287ED71@ip-only.se> Totally agree with Ytti subrated sfp Yummyyyyy Andreas Larsen IP-Only AB | Postadress: 753 81 UPPSALA | Besöksadress Uppsala: S:t Persg 6 Besöksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70 843 10 56 www.ip-only.se 24 jun 2014 kl. 08:37 skrev Saku Ytti : > On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote: > >> feature and market information for such a device, and I would welcome some >> feedback from interested people. Discussion about other types of smart SFPs >> would also be welcome. Feel free to contact me directly using the contact >> information below. > > I'd do questionable things for subrate SFP, SFP which I can put to 1GE port > and have 10M and 100M rates available. Or to 10GE port and get 1GE, 100M and > 10M > > Use case is network generation upgrade where you still have one or two 100M > ports for MGMT ports etc. > > There are quite few service SFP already available, RAD does E1 over IP/ETH > tunnels in SFP, Huawei has router-in-SFP, JDSU has ethernet probe in SFP, > probably quite few others. > > -- > ++ytti From phulshof at aimvalley.nl Tue Jun 24 07:59:40 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Tue, 24 Jun 2014 09:59:40 +0200 Subject: MACsec SFP In-Reply-To: <20140624063725.GA25828@pob.ytti.fi> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> Message-ID: <53A92FEC.9070206@aimvalley.nl> On 24-6-2014 8:37, Saku Ytti wrote: > On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote: > >> feature and market information for such a device, and I would welcome some >> feedback from interested people. Discussion about other types of smart SFPs >> would also be welcome. Feel free to contact me directly using the contact >> information below. > I'd do questionable things for subrate SFP, SFP which I can put to 1GE port > and have 10M and 100M rates available. Or to 10GE port and get 1GE, 100M and > 10M > > Use case is network generation upgrade where you still have one or two 100M > ports for MGMT ports etc. I've seen this request from others as well. Do you have any proposal/preference to limit the data rate from the switch? > There are quite few service SFP already available, RAD does E1 over IP/ETH > tunnels in SFP, Huawei has router-in-SFP, JDSU has ethernet probe in SFP, > probably quite few others. I'm aware of these products; we (AimValley) build and sell several similar products as well. Since I'm a systems architect, and not a sales person, my email was mostly meant to get an idea of what type of smart SFP products people in the field would like to see come to light, and what type of features they should have. I'll then try to build a business case to get the product developed. MACsec is currently on the top of my own list, but I'll gladly pass other ideas to my colleagues. Kind regards, Pieter Hulshoff From jof at thejof.com Tue Jun 24 08:16:01 2014 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 24 Jun 2014 01:16:01 -0700 Subject: MACsec SFP In-Reply-To: <53A92FEC.9070206@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> Message-ID: On Tue, Jun 24, 2014 at 12:59 AM, Pieter Hulshoff wrote: > On 24-6-2014 8:37, Saku Ytti wrote: >> >> On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote: >> >>> feature and market information for such a device, and I would welcome >>> some >>> feedback from interested people. Discussion about other types of smart >>> SFPs >>> would also be welcome. Feel free to contact me directly using the contact >>> information below. >> >> I'd do questionable things for subrate SFP, SFP which I can put to 1GE >> port >> and have 10M and 100M rates available. Or to 10GE port and get 1GE, 100M >> and >> 10M >> >> Use case is network generation upgrade where you still have one or two >> 100M >> ports for MGMT ports etc. > > > I've seen this request from others as well. Do you have any > proposal/preference to limit the data rate from the switch? Seems like it would be just like emulating a media convertor. Drop any frames in excess of 100 Mbit? Perhaps buffer a little bit? If using the interface for any protocols, configuration might need to be made to adjust link costs. From saku at ytti.fi Tue Jun 24 08:21:18 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Jun 2014 11:21:18 +0300 Subject: MACsec SFP In-Reply-To: <53A92FEC.9070206@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> Message-ID: <20140624082118.GA9721@pob.ytti.fi> On (2014-06-24 09:59 +0200), Pieter Hulshoff wrote: Hi Pieter, > I've seen this request from others as well. Do you have any > proposal/preference to limit the data rate from the switch? For this solution to be marketable, it needs to be extremely cheap, as you're essentially competing against cheapest consumer grade switches to subrate a port. These ports would not be revenue generating, but almost invariably MGMT ports to legacy equipment, issues like QoS are not relevant, price point is. From switch POV, packets would be lost on-link when rate exceeds, and TCP would then decrease rate. So SFP would need to implement rudimentary buffering and packet dropping. And as always, it's best if there is some way for these to work without any configuration, as the moment you need to configure 1 thing, you need to develop provisioning system and potentially also configuration backups, which may in some organizations make solution prohibitively expensive compared to using small switch from existing vendor, which is already supported by systems. -- ++ytti From phulshof at aimvalley.nl Tue Jun 24 08:55:31 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Tue, 24 Jun 2014 10:55:31 +0200 Subject: MACsec SFP In-Reply-To: <20140624082118.GA9721@pob.ytti.fi> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <20140624082118.GA9721@pob.ytti.fi> Message-ID: <53A93D03.9020200@aimvalley.nl> On 24-6-2014 10:21, Saku Ytti wrote: > For this solution to be marketable, it needs to be extremely cheap, as > you're essentially competing against cheapest consumer grade switches > to subrate a port. These ports would not be revenue generating, but > almost invariably MGMT ports to legacy equipment, issues like QoS are > not relevant, price point is. From switch POV, packets would be lost > on-link when rate exceeds, and TCP would then decrease rate. So SFP > would need to implement rudimentary buffering and packet dropping. And > as always, it's best if there is some way for these to work without > any configuration, as the moment you need to configure 1 thing, you > need to develop provisioning system and potentially also configuration > backups, which may in some organizations make solution prohibitively > expensive compared to using small switch from existing vendor, which > is already supported by systems So basically a 1G connection to the switch, buffering with frame drop, and a tri-rate RJ45 connector? Sounds like something that could easily be built into our Chronos platform (http://www.aimvalley.com/portfolio_item/chronos-smart-sfp-tstransparent-synce-sfp/). We'd just have to remove the SyncE, and add the 10/100 Mb support. Probably the most complex part is to build a business case for it to pitch to our management. Would anyone be willing to email me a price indication, and perhaps an indication of how many of these products would be needed? No obligations of course; just to get an idea of whether a business case can be built? Kind regards, Pieter Hulshoff From saku at ytti.fi Tue Jun 24 09:09:31 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Jun 2014 12:09:31 +0300 Subject: MACsec SFP In-Reply-To: <53A93D03.9020200@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <20140624082118.GA9721@pob.ytti.fi> <53A93D03.9020200@aimvalley.nl> Message-ID: <20140624090931.GA16922@pob.ytti.fi> On (2014-06-24 10:55 +0200), Pieter Hulshoff wrote: > So basically a 1G connection to the switch, buffering with frame drop, and a > tri-rate RJ45 connector? Sounds like something that could easily be built Yes, also similar solution for 10GE SFP+. Not sure what price should be 50EUR for 1GE and 100EUR for 10GE definitely would be marketable, but they likely could cost more. Like always, market increases as price decreases, so it might be possible to push NRE costs to early adopters then price drop to reach wider market. > Probably the most complex part is to build a business case for it to pitch > to our management. Would anyone be willing to email me a price indication, > and perhaps an indication of how many of these products would be needed? No > obligations of course; just to get an idea of whether a business case can be > built? I'm not ready to commit, because timing is critical here, as such part does not exist, people have found some solution, solution usually means retaining the previous-generation switch in pop, just to subrate the new-generation ports. But this uses lot of electricity usually and it wastes rack space, so it might be easy to show how in just electricity costs you can recover costs in under a year. If switch takes 150W, that's approximately 150 EUR per year for electricity. If SFP takes 1W, yearly savings on electricity alone are 149EUR. MTBF is probably better, due to no separate PSU and ability to capitalize on redundant PSU of host. -- ++ytti From phulshof at aimvalley.nl Tue Jun 24 12:05:55 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Tue, 24 Jun 2014 14:05:55 +0200 Subject: MACsec SFP In-Reply-To: <20140624090931.GA16922@pob.ytti.fi> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <20140624082118.GA9721@pob.ytti.fi> <53A93D03.9020200@aimvalley.nl> <20140624090931.GA16922@pob.ytti.fi> Message-ID: <53A969A3.70601@aimvalley.nl> On 24-6-2014 11:09, Saku Ytti wrote: > On (2014-06-24 10:55 +0200), Pieter Hulshoff wrote: >> So basically a 1G connection to the switch, buffering with frame drop, and a >> tri-rate RJ45 connector? Sounds like something that could easily be built > Yes, also similar solution for 10GE SFP+. What about XFP? Any need for that as well? > Not sure what price should be 50EUR for 1GE and 100EUR for 10GE definitely > would be marketable, but they likely could cost more. > Like always, market increases as price decreases, so it might be possible to > push NRE costs to early adopters then price drop to reach wider market. Price would indeed depend quite a bit on the volume, since design and production cost will need to be recovered. >> Probably the most complex part is to build a business case for it to pitch >> to our management. Would anyone be willing to email me a price indication, >> and perhaps an indication of how many of these products would be needed? No >> obligations of course; just to get an idea of whether a business case can be >> built? > I'm not ready to commit, because timing is critical here, as such part does > not exist, people have found some solution, solution usually means retaining > the previous-generation switch in pop, just to subrate the new-generation > ports. > But this uses lot of electricity usually and it wastes rack space, so it might > be easy to show how in just electricity costs you can recover costs in under a > year. If switch takes 150W, that's approximately 150 EUR per year for > electricity. If SFP takes 1W, yearly savings on electricity alone are 149EUR. > MTBF is probably better, due to no separate PSU and ability to capitalize on > redundant PSU of host. I'm not looking for commitments in any way; just an indication of how often people need a solution like this to get an idea of the type of volumes we're looking at, and a reasonable selling price. As written above: design and production cost (including test, validation, factory, etc.), and reseller profit margins will need to be recovered, so if I'm to convince our management that we should develop this product I'll need to build some kind of business case for it. Of course we'll also contact our regular customer base about these matters, but I would welcome feedback from this list as well. Kind regards, Pieter Hulshoff From morrowc.lists at gmail.com Tue Jun 24 13:50:55 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Jun 2014 09:50:55 -0400 Subject: MACsec SFP In-Reply-To: <53A92FEC.9070206@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> Message-ID: On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff wrote: > features they should have. I'll then try to build a business case to get the > product developed. MACsec is currently on the top of my own list, but I'll > gladly pass other ideas to my colleagues. what would be your key management strategy for the macsec version? given press / etc over the last 18 or so months it seems like folk with long-haul ether framing might be very interested in macsec for those links and NOT doing it by sticking some switch platform between the 2 routed endpoints. management of key material (and rolling and...) is probably interesting for them as well. -chris From phulshof at aimvalley.nl Tue Jun 24 13:59:31 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Tue, 24 Jun 2014 15:59:31 +0200 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> Message-ID: <53A98443.9060801@aimvalley.nl> On 24-6-2014 15:50, Christopher Morrow wrote: > On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff wrote: > >> features they should have. I'll then try to build a business case to get the >> product developed. MACsec is currently on the top of my own list, but I'll >> gladly pass other ideas to my colleagues. > what would be your key management strategy for the macsec version? > given press / etc over the last 18 or so months it seems like folk > with long-haul ether framing might be very interested in macsec for > those links and NOT doing it by sticking some switch platform between > the 2 routed endpoints. > > management of key material (and rolling and...) is probably > interesting for them as well. Actually, that's part of the feature list I'm trying to put together. Not everyone is willing to put a complete key infrastructure together, and some even expressed interest in a simple unmanaged point-to-point solution. Let me share my current view (subject to change): The first release will support 802.1X MKA using a pre-shared key. I'm still trying to decide if this key should be programmable, e.g. via I2C, or if we will simply sell paired devices with a unique pair-wise key programmed in the factory. MKA will automatically take care of the distribution of new MACsec keys. Later releases may support 802.1X EAPOL device authentication, though exactly which EAP sub-protocols we will support is yet to be determined. As said: a lot depends on the answers I will get from potential customers, including people on this list. Kind regards, Pieter Hulshoff From wyystar at gmail.com Tue Jun 24 05:34:13 2014 From: wyystar at gmail.com (Yangyang Wang) Date: Tue, 24 Jun 2014 13:34:13 +0800 Subject: CFP: [Call for Papers] IEEE ICNP2014 CoolSDN Workshop Message-ID: We cordially invite you to submit papers to the 22nd IEEE International Conference on Network Protocols (ICNP2014) CoolSDN Workshop http://icnp14.cs.unc.edu/workshops.html , which will be held on October 21, in Raleigh, North Carolina, United States. The submission information can be found at workshop web site is http://success.cse.tamu.edu/CoolSDN2014/ Important Dates Submission deadline: July 10, 2014 Acceptance notification: August 2, 2014. Camera ready version: August 16, 2014 Regards, Richard Y. Yang, Yale Univ. Jun Bi, Tsinghua Univ. Guofei Gu, Texas A&M Univ. ICNP2014 CoolSDN Workshop Chairs From morrowc.lists at gmail.com Tue Jun 24 15:50:42 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Jun 2014 11:50:42 -0400 Subject: MACsec SFP In-Reply-To: <53A98443.9060801@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> Message-ID: On Tue, Jun 24, 2014 at 9:59 AM, Pieter Hulshoff wrote: > On 24-6-2014 15:50, Christopher Morrow wrote: >> >> On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff >> wrote: >> >>> features they should have. I'll then try to build a business case to get >>> the >>> product developed. MACsec is currently on the top of my own list, but >>> I'll >>> gladly pass other ideas to my colleagues. >> >> what would be your key management strategy for the macsec version? >> given press / etc over the last 18 or so months it seems like folk >> with long-haul ether framing might be very interested in macsec for >> those links and NOT doing it by sticking some switch platform between >> the 2 routed endpoints. >> >> management of key material (and rolling and...) is probably >> interesting for them as well. > > > Actually, that's part of the feature list I'm trying to put together. Not Hurray! :) > everyone is willing to put a complete key infrastructure together, and some > even expressed interest in a simple unmanaged point-to-point solution. Let > me share my current view (subject to change): > > The first release will support 802.1X MKA using a pre-shared key. I'm still > trying to decide if this key should be programmable, e.g. via I2C, or if we > will simply sell paired devices with a unique pair-wise key programmed in > the factory. MKA will automatically take care of the distribution of new > MACsec keys. So.. now when my SFP in Elbonia dies I need to get a truck to Elbonia AND it's paired link in west caledonia? yikes. Also, is that a 'ybFxasasdasd' on the serial-number/key-pair-note or ybfXasdadasdsd' Gosh joe I'm not sure... remote-hands work is going to get a bunch more difficult than: "grab one from the jar, hurry!!!" Programmable seems like the way to go, provided there's a path to do that in the cli of the device you plugged the SFP into? (which I think is the hard part actually, right?) > Later releases may support 802.1X EAPOL device authentication, though > exactly which EAP sub-protocols we will support is yet to be determined. As > said: a lot depends on the answers I will get from potential customers, > including people on this list. > > Kind regards, > > Pieter Hulshoff > From saku at ytti.fi Tue Jun 24 16:07:43 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Jun 2014 19:07:43 +0300 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> Message-ID: <20140624160743.GA12742@pob.ytti.fi> On (2014-06-24 11:50 -0400), Christopher Morrow wrote: > Programmable seems like the way to go, provided there's a path to do > that in the cli of the device you plugged the SFP into? (which I think > is the hard part actually, right?) Solution could be same as for tunable optics, first you tune with eeprommer until CLI gets support. Remote legs could have their own eeprommer, which can be easy enough to use not to require training and costs like 10EUR. Maybe some customer would then enter need for this in CLI in their multimillion dollar RFQ, and then we'd get the feature. -- ++ytti From morrowc.lists at gmail.com Tue Jun 24 16:30:12 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Jun 2014 12:30:12 -0400 Subject: MACsec SFP In-Reply-To: <20140624160743.GA12742@pob.ytti.fi> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> Message-ID: On Tue, Jun 24, 2014 at 12:07 PM, Saku Ytti wrote: > On (2014-06-24 11:50 -0400), Christopher Morrow wrote: > >> Programmable seems like the way to go, provided there's a path to do >> that in the cli of the device you plugged the SFP into? (which I think >> is the hard part actually, right?) > > Solution could be same as for tunable optics, first you tune with eeprommer > until CLI gets support. > Remote legs could have their own eeprommer, which can be easy enough to use > not to require training and costs like 10EUR. it's going to be hard to schedule a key roll then, right? I would expect that in most/many deployments where someone enters a 'key' there has to be some compliance process that includes: "And you change that key every X days" right? So you'll NOT want to be in a situation that involves coordinating a few thousand truck rolls every X months to have this deployed. also, as soon as you give the remote-hands person a copy of your key material and ask them to do the deed on the eepromer, you'll be buying replacement eepromer's/stick-note-bundles for the remote-hands people (or god forbid asking ${equinix-alike} to cleanse your key material from their ticketing system. > Maybe some customer would then enter need for this in CLI in their multimillion > dollar RFQ, and then we'd get the feature. maybe so... multi-million of sfp is a lot of sfp though. From faisal at snappytelecom.net Tue Jun 24 16:39:31 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 24 Jun 2014 16:39:31 +0000 (GMT) Subject: Finisar SFP/SFP+ Message-ID: <236822939.7174.1403627971398.JavaMail.root@snappytelecom.net> Anyone out there, know what is the 'code' sequence for programming Finisar SFP / SFP+ ? Any and all assistance will be greatly appreciated (off list is fine). Thanks. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net From saku at ytti.fi Tue Jun 24 17:19:53 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Jun 2014 20:19:53 +0300 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> Message-ID: <20140624171953.GA23362@pob.ytti.fi> On (2014-06-24 12:30 -0400), Christopher Morrow wrote: > it's going to be hard to schedule a key roll then, right? I would > expect that in most/many deployments where someone enters a 'key' > there has to be some compliance process that includes: "And you change > that key every X days" right? So you'll NOT want to be in a situation > that involves coordinating a few thousand truck rolls every X months > to have this deployed. Hopefully you could offer date when new keys take effect. > > Maybe some customer would then enter need for this in CLI in their multimillion > > dollar RFQ, and then we'd get the feature. > > maybe so... multi-million of sfp is a lot of sfp though. Of course this would be for the equipment where SFP sits, SFP vendor can't solve this. But if you're making it mandatory in router RFQ, it seems pretty much guaranteed vendors would comply and winning bid at least would implement it. -- ++ytti From morrowc.lists at gmail.com Tue Jun 24 17:32:04 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Jun 2014 13:32:04 -0400 Subject: MACsec SFP In-Reply-To: <20140624171953.GA23362@pob.ytti.fi> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> <20140624171953.GA23362@pob.ytti.fi> Message-ID: On Tue, Jun 24, 2014 at 1:19 PM, Saku Ytti wrote: > On (2014-06-24 12:30 -0400), Christopher Morrow wrote: > >> it's going to be hard to schedule a key roll then, right? I would >> expect that in most/many deployments where someone enters a 'key' >> there has to be some compliance process that includes: "And you change >> that key every X days" right? So you'll NOT want to be in a situation >> that involves coordinating a few thousand truck rolls every X months >> to have this deployed. > > Hopefully you could offer date when new keys take effect. sure, 'use new key in 37.243 minutes!' I still have to coordinate people showing up at all sites over N period of time to do this programming, and I'm SURE that some set of the programmed devices will get an l instead of a 1 ... so 'quick chuck, get in the truck!' is going to be an oft-heard refrain ;( Hand managing this just isn't feasible, I think. >> > Maybe some customer would then enter need for this in CLI in their multimillion >> > dollar RFQ, and then we'd get the feature. >> >> maybe so... multi-million of sfp is a lot of sfp though. > > Of course this would be for the equipment where SFP sits, SFP vendor can't > solve this. But if you're making it mandatory in router RFQ, it seems pretty > much guaranteed vendors would comply and winning bid at least would implement > it. yes, I realized as I clicked 'send'... in any case :) the sfp manufacturer likely has to decide on some way to program the sfp (maybe there are already in-router/switch ways for other things like this? like wavelength...) which all router/switch vendors have to also agree to abide by. From rwebb at ropeguru.com Tue Jun 24 17:49:07 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 24 Jun 2014 13:49:07 -0400 Subject: Help with route latency between TATA and Comcast Message-ID: I am doing some testing between my Comcast Business connection and a Singapore server that I have just setup. I am seeing high latency to the server but it appears it is the Comcast to TATA link and not the link between the U.S. and Singapore. At least that is what I can gather from the reverse lookup in the traceroute. Can someone please enlighten me as to if I am correct or not? Tracing route to 128.199.162.241 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 192.168.1.254 2 1 ms <1 ms <1 ms 23-25-112-190-static.hfc.comcastbusiness.net [23.25.xxx.xxx] 3 27 ms 22 ms 19 ms 96.178.10.1 4 10 ms 9 ms 10 ms te-1-3-ur01.shadygrove.va.richmond.comcast.net [68.86.124.241] 5 17 ms 17 ms 17 ms xe-12-0-1-0-ar02.charlvilleco.va.richmond.comcast.net [68.86.172.17] 6 24 ms 24 ms 25 ms pos-1-2-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.91.53] 7 24 ms 23 ms 23 ms pos-0-3-0-0-pe01.ashburn.va.ibone.comcast.net [68.86.86.142] 8 20 ms 20 ms 20 ms 66.208.233.38 9 268 ms 264 ms 265 ms if-6-8.tcore2.lvw-los-angeles.as6453.net [216.6.87.114] 10 * * * Request timed out. 11 270 ms 255 ms 256 ms if-2-2.tcore1.svw-singapore.as6453.net [180.87.12.1] 12 270 ms 271 ms 275 ms if-11-2.thar1.svq-singapore.as6453.net [180.87.98.37] 13 260 ms 258 ms 260 ms 180.87.98.6 14 256 ms 256 ms 258 ms 103.253.144.242 15 262 ms 258 ms 259 ms 128.199.162.241 Trace complete.? From mpetach at netflight.com Tue Jun 24 18:18:09 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 24 Jun 2014 11:18:09 -0700 Subject: Help with route latency between TATA and Comcast In-Reply-To: References: Message-ID: 260ms from VA to SG is about right. I'd suspect the DNS is wrong in this case, as otherwise they somehow went from LAX to SG in less than 10ms--and if they found a way to do that, I suspect they'd have a *lot* more customers beating down their doors to get onto that pathway. :P Matt On Tue, Jun 24, 2014 at 10:49 AM, rwebb at ropeguru.com wrote: > I am doing some testing between my Comcast Business connection and a > Singapore server that I have just setup. I am seeing high latency to the > server but it appears it is the Comcast to TATA link and not the link > between the U.S. and Singapore. At least that is what I can gather from the > reverse lookup in the traceroute. > > Can someone please enlighten me as to if I am correct or not? > > Tracing route to 128.199.162.241 over a maximum of 30 hops > > 1 <1 ms <1 ms <1 ms 192.168.1.254 > 2 1 ms <1 ms <1 ms 23-25-112-190-static.hfc. > comcastbusiness.net [23.25.xxx.xxx] > 3 27 ms 22 ms 19 ms 96.178.10.1 > 4 10 ms 9 ms 10 ms te-1-3-ur01.shadygrove.va. > richmond.comcast.net [68.86.124.241] > 5 17 ms 17 ms 17 ms xe-12-0-1-0-ar02.charlvilleco. > va.richmond.comcast.net [68.86.172.17] > 6 24 ms 24 ms 25 ms pos-1-2-0-0-cr01.ashburn.va. > ibone.comcast.net [68.86.91.53] > 7 24 ms 23 ms 23 ms pos-0-3-0-0-pe01.ashburn.va. > ibone.comcast.net [68.86.86.142] > 8 20 ms 20 ms 20 ms 66.208.233.38 > 9 268 ms 264 ms 265 ms if-6-8.tcore2.lvw-los-angeles.as6453.net > [216.6.87.114] > 10 * * * Request timed out. > 11 270 ms 255 ms 256 ms if-2-2.tcore1.svw-singapore.as6453.net > [180.87.12.1] > 12 270 ms 271 ms 275 ms if-11-2.thar1.svq-singapore.as6453.net > [180.87.98.37] > 13 260 ms 258 ms 260 ms 180.87.98.6 > 14 256 ms 256 ms 258 ms 103.253.144.242 > 15 262 ms 258 ms 259 ms 128.199.162.241 > > Trace complete.? > > From rwebb at ropeguru.com Tue Jun 24 18:25:38 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 24 Jun 2014 14:25:38 -0400 Subject: Help with route latency between TATA and Comcast In-Reply-To: References: Message-ID: Now that I look at it again, I believe you are correct. This is my first overseas server so I was not really sure what to expect in latency. It has been one of those days that doing a reverse had not occurred to me to try as suggested by another reply. I am seeing about the same on the reverse so I am good to go. Robert On Tue, 24 Jun 2014 11:18:09 -0700 Matthew Petach wrote: > 260ms from VA to SG is about right. I'd suspect > the DNS is wrong in this case, as otherwise > they somehow went from LAX to SG in less > than 10ms--and if they found a way to do that, > I suspect they'd have a *lot* more customers > beating down their doors to get onto that pathway. :P > > Matt > > > > On Tue, Jun 24, 2014 at 10:49 AM, rwebb at ropeguru.com > > wrote: > >> I am doing some testing between my Comcast Business connection and a >> Singapore server that I have just setup. I am seeing high latency to >>the >> server but it appears it is the Comcast to TATA link and not the >>link >> between the U.S. and Singapore. At least that is what I can gather >>from the >> reverse lookup in the traceroute. >> >> Can someone please enlighten me as to if I am correct or not? >> >> Tracing route to 128.199.162.241 over a maximum of 30 hops >> >> 1 <1 ms <1 ms <1 ms 192.168.1.254 >> 2 1 ms <1 ms <1 ms 23-25-112-190-static.hfc. >> comcastbusiness.net [23.25.xxx.xxx] >> 3 27 ms 22 ms 19 ms 96.178.10.1 >> 4 10 ms 9 ms 10 ms te-1-3-ur01.shadygrove.va. >> richmond.comcast.net [68.86.124.241] >> 5 17 ms 17 ms 17 ms xe-12-0-1-0-ar02.charlvilleco. >> va.richmond.comcast.net [68.86.172.17] >> 6 24 ms 24 ms 25 ms pos-1-2-0-0-cr01.ashburn.va. >> ibone.comcast.net [68.86.91.53] >> 7 24 ms 23 ms 23 ms pos-0-3-0-0-pe01.ashburn.va. >> ibone.comcast.net [68.86.86.142] >> 8 20 ms 20 ms 20 ms 66.208.233.38 >> 9 268 ms 264 ms 265 ms >>if-6-8.tcore2.lvw-los-angeles.as6453.net >> [216.6.87.114] >> 10 * * * Request timed out. >> 11 270 ms 255 ms 256 ms >>if-2-2.tcore1.svw-singapore.as6453.net >> [180.87.12.1] >> 12 270 ms 271 ms 275 ms >>if-11-2.thar1.svq-singapore.as6453.net >> [180.87.98.37] >> 13 260 ms 258 ms 260 ms 180.87.98.6 >> 14 256 ms 256 ms 258 ms 103.253.144.242 >> 15 262 ms 258 ms 259 ms 128.199.162.241 >> >> Trace complete.? >> >> From joelja at bogus.com Tue Jun 24 18:28:49 2014 From: joelja at bogus.com (joel jaeggli) Date: Tue, 24 Jun 2014 11:28:49 -0700 Subject: Help with route latency between TATA and Comcast In-Reply-To: References: Message-ID: <53A9C361.4010902@bogus.com> On 6/24/14 10:49 AM, rwebb at ropeguru.com wrote: > I am doing some testing between my Comcast Business connection and a > Singapore server that I have just setup. I am seeing high latency to the > server but it appears it is the Comcast to TATA link and not the link > between the U.S. and Singapore. At least that is what I can gather from > the reverse lookup in the traceroute. given that the latency to hop 9 is basically the same as hop14 you're looking at mpls... if the transpacific hop were on top of that you'd see at least another 100 ms added to the rtt between 9 and 11. it's 9655 miles IAD - SIN over the pole, realistically an actually fiber paths is likely more than 12000 so you'd expect to see ~more than 150ms rtt under the best circumstances... > Can someone please enlighten me as to if I am correct or not? > > Tracing route to 128.199.162.241 over a maximum of 30 hops > > 1 <1 ms <1 ms <1 ms 192.168.1.254 > 2 1 ms <1 ms <1 ms > 23-25-112-190-static.hfc.comcastbusiness.net [23.25.xxx.xxx] > 3 27 ms 22 ms 19 ms 96.178.10.1 > 4 10 ms 9 ms 10 ms > te-1-3-ur01.shadygrove.va.richmond.comcast.net [68.86.124.241] > 5 17 ms 17 ms 17 ms > xe-12-0-1-0-ar02.charlvilleco.va.richmond.comcast.net [68.86.172.17] > 6 24 ms 24 ms 25 ms > pos-1-2-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.91.53] > 7 24 ms 23 ms 23 ms > pos-0-3-0-0-pe01.ashburn.va.ibone.comcast.net [68.86.86.142] > 8 20 ms 20 ms 20 ms 66.208.233.38 > 9 268 ms 264 ms 265 ms if-6-8.tcore2.lvw-los-angeles.as6453.net > [216.6.87.114] > 10 * * * Request timed out. > 11 270 ms 255 ms 256 ms if-2-2.tcore1.svw-singapore.as6453.net > [180.87.12.1] > 12 270 ms 271 ms 275 ms if-11-2.thar1.svq-singapore.as6453.net > [180.87.98.37] > 13 260 ms 258 ms 260 ms 180.87.98.6 > 14 256 ms 256 ms 258 ms 103.253.144.242 > 15 262 ms 258 ms 259 ms 128.199.162.241 > > Trace complete.? > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 286 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Tue Jun 24 18:46:48 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 24 Jun 2014 14:46:48 -0400 Subject: Help with route latency between TATA and Comcast In-Reply-To: References: Message-ID: On Jun 24, 2014, at 2:25 PM, rwebb at ropeguru.com wrote: > It has been one of those days that doing a reverse had not occurred to me to try as suggested by another reply. I am seeing about the same on the reverse so I am good to go. Keep in mind that latency isn't the end-all-be-all in measuring a link, packet loss and having a proper (modern) TCP stack is key here as well. Any modern *nix or Win7+ should be able to fill the pipe with a single TCP flow unless there is someone meddling in the middle. - Jared From eric at flanery.us Tue Jun 24 18:51:47 2014 From: eric at flanery.us (Eric Flanery (eric)) Date: Tue, 24 Jun 2014 11:51:47 -0700 Subject: MACsec SFP In-Reply-To: <20140624171953.GA23362@pob.ytti.fi> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> <20140624171953.GA23362@pob.ytti.fi> Message-ID: Hmm, wandering pie-in-the-sky module wish list... MACsec would be great, hopefully in an easy to manage/replace form. Separately tunable transmitters and receivers; in both DWDM and CWDM flavors. This would reduce the number of different parts to track/stock, and enable the use of simple splitters/combiners in place of mux/demux shelves for some short links. Fully functional (as a manageable device) whatever-PON 'OLT in a module', so that we can use any old host device that lacks specific support. (ONTs too) 'Channelized SFP+', that talks on multiple wavelengths (CWDM/DWDM) at a 1G rate simultaneously, to support a sort of WDM-PON. And/or SFP+ modules that talk on multiple strands at a 1G rate simultaneously, with something like a MPO/MTP connector, to increase density. I suppose there would need to be some sort of switch or mux built into the module in either case. A SFP(+) microwave modem, to connect to a radio head. Hopefully with wide support of many licensed and unlicensed bands. 802.11-whatever APs in a SFP(+) form factor, preferably controller-based. Perhaps doing some sort of RF-over-Ethernet to enable widely distributed antenna systems. Mini MPLS LER/PE routers in SFP form. All sorts of customer-facing interface types could be interesting, but mostly (sub-rate) Ethernet with QoS of some sort. Self power-leveling and/or attenuating with wide ranges, again reducing part tracking/stocking, and eliminating discrete attenuator pads. SIP ATA in SFP form. Small flash-based NAS in SFP form. 'Computational resources' in SFP(+) form (ARM chips maybe?). OTDR functionality built into modules, hopefully able to operate without disrupting the data flow, perhaps continuously. Manageable (CLI and SNMP, please) modules of all sorts, to enable whatever 'special' features to be operated without requiring any particular support from the host device beyond the MSA. 1G/100M SFPs that provide PoE ('passive' 18v or 24v would be most appreciated.) No vendor lock! --Eric On Tue, Jun 24, 2014 at 10:19 AM, Saku Ytti wrote: > On (2014-06-24 12:30 -0400), Christopher Morrow wrote: > > > it's going to be hard to schedule a key roll then, right? I would > > expect that in most/many deployments where someone enters a 'key' > > there has to be some compliance process that includes: "And you change > > that key every X days" right? So you'll NOT want to be in a situation > > that involves coordinating a few thousand truck rolls every X months > > to have this deployed. > > Hopefully you could offer date when new keys take effect. > > > > Maybe some customer would then enter need for this in CLI in their > multimillion > > > dollar RFQ, and then we'd get the feature. > > > > maybe so... multi-million of sfp is a lot of sfp though. > > Of course this would be for the equipment where SFP sits, SFP vendor can't > solve this. But if you're making it mandatory in router RFQ, it seems > pretty > much guaranteed vendors would comply and winning bid at least would > implement > it. > > > -- > ++ytti > From earthurs at legacyinmate.com Tue Jun 24 18:48:36 2014 From: earthurs at legacyinmate.com (Edward Arthurs) Date: Tue, 24 Jun 2014 11:48:36 -0700 Subject: Help with route latency between TATA and Comcast In-Reply-To: References: Message-ID: <012901cf8fdc$e8a0c0a0$b9e241e0$@com> Here is what I get from a trace route, I am in Los Angeles. Tracing route to 128.199.162.241 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 172.25.0.137 2 14 ms 16 ms 14 ms 208.179.145.213 3 7 ms 5 ms 6 ms cr01.lax1.tierzero.net [216.31.153.48] 4 7 ms 6 ms 6 ms ge-0-1-2.br02.lax3.tierzero.net [216.31.128.73] 5 7 ms 7 ms 45 ms xe-7-1-2.edge6.LosAngeles1.Level3.net [4.59.57.157] 6 6 ms 6 ms 6 ms ae-1-60.edge3.LosAngeles1.Level3.net [4.69.144.9] 7 8 ms 7 ms 8 ms xe-0-3-0-5.r04.lsanca03.us.bb.gin.ntt.net [129.250.9.229] 8 8 ms 8 ms 8 ms ae-8.r20.lsanca03.us.bb.gin.ntt.net [129.250.5.1] 9 116 ms 123 ms 117 ms ae-6.r20.osakjp02.jp.bb.gin.ntt.net [129.250.4.39] 10 117 ms 117 ms 117 ms ae-4.r22.osakjp02.jp.bb.gin.ntt.net [129.250.6.188] 11 204 ms 223 ms 208 ms ae-8.r20.sngpsi05.sg.bb.gin.ntt.net [129.250.3.110] 12 200 ms 192 ms 191 ms ae-2.r00.sngpsi02.sg.bb.gin.ntt.net [129.250.3.147] 13 181 ms 184 ms 182 ms 116.51.27.190 APNIC 14 179 ms 180 ms 179 ms 103.253.144.242 APNIC 15 * * * Request timed out. 16 188 ms 188 ms 194 ms 128.199.162.241 digitalocean.com Trace complete. Thank You -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of rwebb at ropeguru.com Sent: Tuesday, June 24, 2014 11:26 AM To: Matthew Petach Cc: nanog at nanog.org Subject: Re: Help with route latency between TATA and Comcast Now that I look at it again, I believe you are correct. This is my first overseas server so I was not really sure what to expect in latency. It has been one of those days that doing a reverse had not occurred to me to try as suggested by another reply. I am seeing about the same on the reverse so I am good to go. Robert On Tue, 24 Jun 2014 11:18:09 -0700 Matthew Petach wrote: > 260ms from VA to SG is about right. I'd suspect the DNS is wrong in > this case, as otherwise they somehow went from LAX to SG in less than > 10ms--and if they found a way to do that, I suspect they'd have a > *lot* more customers beating down their doors to get onto that > pathway. :P > > Matt > > > > On Tue, Jun 24, 2014 at 10:49 AM, rwebb at ropeguru.com > > wrote: > >> I am doing some testing between my Comcast Business connection and a >>Singapore server that I have just setup. I am seeing high latency to >>the server but it appears it is the Comcast to TATA link and not the >>link between the U.S. and Singapore. At least that is what I can >>gather from the reverse lookup in the traceroute. >> >> Can someone please enlighten me as to if I am correct or not? >> >> Tracing route to 128.199.162.241 over a maximum of 30 hops >> >> 1 <1 ms <1 ms <1 ms 192.168.1.254 >> 2 1 ms <1 ms <1 ms 23-25-112-190-static.hfc. >> comcastbusiness.net [23.25.xxx.xxx] >> 3 27 ms 22 ms 19 ms 96.178.10.1 >> 4 10 ms 9 ms 10 ms te-1-3-ur01.shadygrove.va. >> richmond.comcast.net [68.86.124.241] >> 5 17 ms 17 ms 17 ms xe-12-0-1-0-ar02.charlvilleco. >> va.richmond.comcast.net [68.86.172.17] >> 6 24 ms 24 ms 25 ms pos-1-2-0-0-cr01.ashburn.va. >> ibone.comcast.net [68.86.91.53] >> 7 24 ms 23 ms 23 ms pos-0-3-0-0-pe01.ashburn.va. >> ibone.comcast.net [68.86.86.142] >> 8 20 ms 20 ms 20 ms 66.208.233.38 >> 9 268 ms 264 ms 265 ms >>if-6-8.tcore2.lvw-los-angeles.as6453.net >> [216.6.87.114] >> 10 * * * Request timed out. >> 11 270 ms 255 ms 256 ms >>if-2-2.tcore1.svw-singapore.as6453.net >> [180.87.12.1] >> 12 270 ms 271 ms 275 ms >>if-11-2.thar1.svq-singapore.as6453.net >> [180.87.98.37] >> 13 260 ms 258 ms 260 ms 180.87.98.6 >> 14 256 ms 256 ms 258 ms 103.253.144.242 >> 15 262 ms 258 ms 259 ms 128.199.162.241 >> >> Trace complete.? >> >> From frnkblk at iname.com Tue Jun 24 19:05:24 2014 From: frnkblk at iname.com (Frank Bulk (iname.com)) Date: Tue, 24 Jun 2014 14:05:24 -0500 Subject: MACsec SFP In-Reply-To: <20140624082118.GA9721@pob.ytti.fi> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <20140624082118.GA9721@pob.ytti.fi> Message-ID: <004a01cf8fdf$40c78410$c2568c30$@iname.com> DIP switches? Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Saku Ytti Sent: Tuesday, June 24, 2014 3:21 AM To: nanog at nanog.org Subject: Re: MACsec SFP On (2014-06-24 09:59 +0200), Pieter Hulshoff wrote: Hi Pieter, > I've seen this request from others as well. Do you have any > proposal/preference to limit the data rate from the switch? For this solution to be marketable, it needs to be extremely cheap, as you're essentially competing against cheapest consumer grade switches to subrate a port. These ports would not be revenue generating, but almost invariably MGMT ports to legacy equipment, issues like QoS are not relevant, price point is. From switch POV, packets would be lost on-link when rate exceeds, and TCP would then decrease rate. So SFP would need to implement rudimentary buffering and packet dropping. And as always, it's best if there is some way for these to work without any configuration, as the moment you need to configure 1 thing, you need to develop provisioning system and potentially also configuration backups, which may in some organizations make solution prohibitively expensive compared to using small switch from existing vendor, which is already supported by systems. -- ++ytti From me at anuragbhatia.com Tue Jun 24 19:24:21 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 25 Jun 2014 00:54:21 +0530 Subject: Help with route latency between TATA and Comcast In-Reply-To: <53A9C361.4010902@bogus.com> References: <53A9C361.4010902@bogus.com> Message-ID: Hi As from Tata AS6453 looking glass: Router: gin-laa-mcore3 Site: US, Los angeles, LAA Command: ping ip 216.6.87.114 Sending 5, 100-byte ICMP Echos to 216.6.87.114, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms So basically that IP/router is in US but you getting high latency because of return path which is likely via East Asia. As Joel rightly pointed out - end to end latency is just fine in this case. Have fun! On Tue, Jun 24, 2014 at 11:58 PM, joel jaeggli wrote: > On 6/24/14 10:49 AM, rwebb at ropeguru.com wrote: > > I am doing some testing between my Comcast Business connection and a > > Singapore server that I have just setup. I am seeing high latency to the > > server but it appears it is the Comcast to TATA link and not the link > > between the U.S. and Singapore. At least that is what I can gather from > > the reverse lookup in the traceroute. > > given that the latency to hop 9 is basically the same as hop14 you're > looking at mpls... > > if the transpacific hop were on top of that you'd see at least another > 100 ms added to the rtt between 9 and 11. > > it's 9655 miles IAD - SIN over the pole, realistically an actually fiber > paths is likely more than 12000 so you'd expect to see ~more than 150ms > rtt under the best circumstances... > > > > Can someone please enlighten me as to if I am correct or not? > > > > Tracing route to 128.199.162.241 over a maximum of 30 hops > > > > 1 <1 ms <1 ms <1 ms 192.168.1.254 > > 2 1 ms <1 ms <1 ms > > 23-25-112-190-static.hfc.comcastbusiness.net [23.25.xxx.xxx] > > 3 27 ms 22 ms 19 ms 96.178.10.1 > > 4 10 ms 9 ms 10 ms > > te-1-3-ur01.shadygrove.va.richmond.comcast.net [68.86.124.241] > > 5 17 ms 17 ms 17 ms > > xe-12-0-1-0-ar02.charlvilleco.va.richmond.comcast.net [68.86.172.17] > > 6 24 ms 24 ms 25 ms > > pos-1-2-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.91.53] > > 7 24 ms 23 ms 23 ms > > pos-0-3-0-0-pe01.ashburn.va.ibone.comcast.net [68.86.86.142] > > 8 20 ms 20 ms 20 ms 66.208.233.38 > > 9 268 ms 264 ms 265 ms if-6-8.tcore2.lvw-los-angeles.as6453.net > > [216.6.87.114] > > 10 * * * Request timed out. > > 11 270 ms 255 ms 256 ms if-2-2.tcore1.svw-singapore.as6453.net > > [180.87.12.1] > > 12 270 ms 271 ms 275 ms if-11-2.thar1.svq-singapore.as6453.net > > [180.87.98.37] > > 13 260 ms 258 ms 260 ms 180.87.98.6 > > 14 256 ms 256 ms 258 ms 103.253.144.242 > > 15 262 ms 258 ms 259 ms 128.199.162.241 > > > > Trace complete.? > > > > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From phulshof at aimvalley.nl Tue Jun 24 19:27:00 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Tue, 24 Jun 2014 21:27:00 +0200 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> Message-ID: <53A9D104.7070703@aimvalley.nl> On 24-06-14 17:50, Christopher Morrow wrote: > So.. now when my SFP in Elbonia dies I need to get a truck to Elbonia > AND it's paired link in west caledonia? yikes. Also, is that a > 'ybFxasasdasd' on the serial-number/key-pair-note or ybfXasdadasdsd' > Gosh joe I'm not sure... Obviously this solution wouldn't work for everyone, but I think for those people who prefer a simple unmanaged plug-and-play solution it would work just fine. > Programmable seems like the way to go, provided there's a path to do > that in the cli of the device you plugged the SFP into? (which I think > is the hard part actually, right?) Actually, there are many other ways to solve this. If you want unmanaged still, you could opt for using a key infrastructure combined with 802.1X EAPOL. For managed solutions, the device could be made programmable via I2C, in-band from the switch or even in-band from the line. We have several such managed smart SFPs in our portfolio, so adding such features to this device will not be a problem. A management channel however is an also added security risk, so not everybody would be in favour of that. No size fits all. On 24-06-14 18:30, Christopher Morrow wrote: > it's going to be hard to schedule a key roll then, right? I would > expect that in most/many deployments where someone enters a 'key' > there has to be some compliance process that includes: "And you change > that key every X days" right? So you'll NOT want to be in a situation > that involves coordinating a few thousand truck rolls every X months > to have this deployed. True, though an MKA PSK could safely be used for the life-time of a device. Should one want a regular key roll though, the CAK could be given a life-time, with a new one distributed automatically via MKA or EAPOL when it expires. It's also possible to set up a management command to do the same thing at the operator's request. Plenty of options; I'm trying to find out what demand there is for each to determine what should make our first release, and what will not. :) Kind regards, Pieter Hulshoff From nick at foobar.org Tue Jun 24 19:46:15 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 24 Jun 2014 20:46:15 +0100 Subject: Finisar SFP/SFP+ In-Reply-To: <236822939.7174.1403627971398.JavaMail.root@snappytelecom.net> References: <236822939.7174.1403627971398.JavaMail.root@snappytelecom.net> Message-ID: <53A9D587.2050409@foobar.org> On 24/06/2014 17:39, Faisal Imtiaz wrote: > Anyone out there, know what is the 'code' sequence for programming Finisar SFP / SFP+ ? this is a very broken question. I'm going to assume you have a bunch of finisar transceivers and you want to reprogram them to look like e.g. cisco or juniper or whatevs. You can find a bunch on the internet using your favourite search engine with the term "sfp programmer". The difficulty is getting one which will be able to reprogram your SFPs in the way that they need to be reprogrammed. If the reprogrammer includes the software to do this properly, you're on to a winner. Nick From faisal at snappytelecom.net Tue Jun 24 20:23:27 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 24 Jun 2014 20:23:27 +0000 (GMT) Subject: Finisar SFP/SFP+ In-Reply-To: <53A9D587.2050409@foobar.org> References: <236822939.7174.1403627971398.JavaMail.root@snappytelecom.net> <53A9D587.2050409@foobar.org> Message-ID: <1900152838.8258.1403641407251.JavaMail.root@snappytelecom.net> Hi Nick, Thanks for the reply, and yes, your assumption is correct. I was exploring / wanting to know the 'code' for re-programing Finisar SFP/SFP+ I do have a programmer and the software that goes with it. Many for the SFP/SFP+ mfg. have 'locked' eeproms, they require a special sequence of code before they can be programmed. Finisar is one of them. I was wanting to know if there is anyone who has such code for the Finisar SFP/SFP+. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Nick Hilliard" > To: "Faisal Imtiaz" , "NANOG" > Sent: Tuesday, June 24, 2014 3:46:15 PM > Subject: Re: Finisar SFP/SFP+ > > On 24/06/2014 17:39, Faisal Imtiaz wrote: > > Anyone out there, know what is the 'code' sequence for programming Finisar > > SFP / SFP+ ? > > this is a very broken question. I'm going to assume you have a bunch of > finisar transceivers and you want to reprogram them to look like e.g. cisco > or juniper or whatevs. > > You can find a bunch on the internet using your favourite search engine > with the term "sfp programmer". The difficulty is getting one which will > be able to reprogram your SFPs in the way that they need to be > reprogrammed. If the reprogrammer includes the software to do this > properly, you're on to a winner. > > Nick > > From nick at foobar.org Tue Jun 24 20:25:51 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 24 Jun 2014 21:25:51 +0100 Subject: Finisar SFP/SFP+ In-Reply-To: <1900152838.8258.1403641407251.JavaMail.root@snappytelecom.net> References: <236822939.7174.1403627971398.JavaMail.root@snappytelecom.net> <53A9D587.2050409@foobar.org> <1900152838.8258.1403641407251.JavaMail.root@snappytelecom.net> Message-ID: <53A9DECF.8080502@foobar.org> On 24/06/2014 21:23, Faisal Imtiaz wrote: > I was wanting to know if there is anyone who has such code for the Finisar SFP/SFP+. there's a clear solution here: if a vendor locks the transceiver from reprogramming, don't buy transceivers from them. Nick From faisal at snappytelecom.net Tue Jun 24 20:27:26 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 24 Jun 2014 20:27:26 +0000 (GMT) Subject: Finisar SFP/SFP+ In-Reply-To: <53A9DECF.8080502@foobar.org> References: <236822939.7174.1403627971398.JavaMail.root@snappytelecom.net> <53A9D587.2050409@foobar.org> <1900152838.8258.1403641407251.JavaMail.root@snappytelecom.net> <53A9DECF.8080502@foobar.org> Message-ID: <1124472835.8385.1403641646393.JavaMail.root@snappytelecom.net> That is one way to deal with it. :) Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Nick Hilliard" > To: "Faisal Imtiaz" > Cc: "NANOG" > Sent: Tuesday, June 24, 2014 4:25:51 PM > Subject: Re: Finisar SFP/SFP+ > > On 24/06/2014 21:23, Faisal Imtiaz wrote: > > I was wanting to know if there is anyone who has such code for the Finisar > > SFP/SFP+. > > there's a clear solution here: if a vendor locks the transceiver from > reprogramming, don't buy transceivers from them. > > Nick > > From cra at WPI.EDU Tue Jun 24 20:37:48 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 24 Jun 2014 16:37:48 -0400 Subject: Finisar SFP/SFP+ In-Reply-To: <1124472835.8385.1403641646393.JavaMail.root@snappytelecom.net> References: <236822939.7174.1403627971398.JavaMail.root@snappytelecom.net> <53A9D587.2050409@foobar.org> <1900152838.8258.1403641407251.JavaMail.root@snappytelecom.net> <53A9DECF.8080502@foobar.org> <1124472835.8385.1403641646393.JavaMail.root@snappytelecom.net> Message-ID: <20140624203747.GX1897@angus.ind.WPI.EDU> Cheap DIY SFP programmer using a Raspberry Pi: http://eoinpk.blogspot.com/2014/05/raspberry-pi-and-programming-eeproms-on.html Software: https://code.google.com/p/sfppi/ Now we just need some code to brute-force the OEM passwords... How fast is the 2-wire bus on SFPs? On Tue, Jun 24, 2014 at 08:27:26PM +0000, Faisal Imtiaz wrote: > That is one way to deal with it. > > :) > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- > > From: "Nick Hilliard" > > To: "Faisal Imtiaz" > > Cc: "NANOG" > > Sent: Tuesday, June 24, 2014 4:25:51 PM > > Subject: Re: Finisar SFP/SFP+ > > > > On 24/06/2014 21:23, Faisal Imtiaz wrote: > > > I was wanting to know if there is anyone who has such code for the Finisar > > > SFP/SFP+. > > > > there's a clear solution here: if a vendor locks the transceiver from > > reprogramming, don't buy transceivers from them. > > > > Nick From jared at puck.nether.net Tue Jun 24 21:11:38 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 24 Jun 2014 17:11:38 -0400 Subject: Finisar SFP/SFP+ In-Reply-To: <20140624203747.GX1897@angus.ind.WPI.EDU> References: <236822939.7174.1403627971398.JavaMail.root@snappytelecom.net> <53A9D587.2050409@foobar.org> <1900152838.8258.1403641407251.JavaMail.root@snappytelecom.net> <53A9DECF.8080502@foobar.org> <1124472835.8385.1403641646393.JavaMail.root@snappytelecom.net> <20140624203747.GX1897@angus.ind.WPI.EDU> Message-ID: On Jun 24, 2014, at 4:37 PM, Chuck Anderson wrote: > Cheap DIY SFP programmer using a Raspberry Pi: > > http://eoinpk.blogspot.com/2014/05/raspberry-pi-and-programming-eeproms-on.html > > Software: > > https://code.google.com/p/sfppi/ > > Now we just need some code to brute-force the OEM passwords... How > fast is the 2-wire bus on SFPs? This seems like overkill. I have been asking my vendors for the ability to deal with the SFF-MSA data properly and to not break their own optics in their own devices. (Yes, I've seen this). I prefer my XFP/CFP/SFP/SFP+ ports unlocked properly from the factory and the ability to display all the SFF-MSA fields. So far everyone is making high quality CFP parts so I've not seen anything "odd" there aside from some vendors don't realize that 100G-LR4 should display all 4 lanes light levels. If you are buying cheap SFPs you get what you pay for. We have had good luck with Finisar and Finisar OEM, which are available broadly in the market for a fair price. The best way to discourage the locking is to stop buying the optics from those that do engage in the locking activities. It would also be helpful to list those optics that are poor in quality as well. This also may provide an incentive to those in the marketplace to improve them. (eg: I have no problem with a vendor blocking the same S/N from appearing multiple times in a chassis from a "cloned" optic, but if they are putting that effort into the driver, they also need to support their own optics in the chassis as well). If nobody is aware of a SFP/XFP/CFP/whatnot database out there, perhaps we can crowdsource one as a community? This seems to be something that may provide value. - jared From randy at psg.com Tue Jun 24 22:30:10 2014 From: randy at psg.com (Randy Bush) Date: Wed, 25 Jun 2014 07:30:10 +0900 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> Message-ID: >> Solution could be same as for tunable optics, first you tune with >> eeprommer until CLI gets support. >> Remote legs could have their own eeprommer, which can be easy enough >> to use not to require training and costs like 10EUR. > it's going to be hard to schedule a key roll then, right? i have always been fond of rfc 4808 and not the unnecessarily complex alternatives such as tcp-ao. randy From effulgence at gmail.com Wed Jun 25 02:57:05 2014 From: effulgence at gmail.com (Aris Lambrianidis) Date: Wed, 25 Jun 2014 04:57:05 +0200 Subject: MACsec SFP In-Reply-To: <53A9D104.7070703@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> Message-ID: <53AA3A81.8090805@gmail.com> How much ahead of my time would I be if I was to ask for CFP/CFP2 transceivers supporting MACsec? (at a reasonably competitive price) --Aris From markjr at easydns.com Wed Jun 25 03:20:27 2014 From: markjr at easydns.com (Mark E. Jeftovic) Date: Tue, 24 Jun 2014 23:20:27 -0400 Subject: DNSresolvers.com shutdown imminent Message-ID: <53AA3FFB.4020107@easydns.com> As we announced nearly a year ago, DNSresolvers.com open resolvers shutdown is imminent. If you are still using dnsresolvers.com for lookups, this will stop working when we shut it down. Check your resolver lists for: 205.210.42.205 64.68.200.200 and remove them. We will be back with a more sensible resolver system in the future, but it will not be wide open the way these ones are. Thank you for your attention. - mark -- Mark E. Jeftovic Founder & CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com From morrowc.lists at gmail.com Wed Jun 25 05:21:27 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Jun 2014 01:21:27 -0400 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> Message-ID: On Tue, Jun 24, 2014 at 6:30 PM, Randy Bush wrote: >>> Solution could be same as for tunable optics, first you tune with >>> eeprommer until CLI gets support. >>> Remote legs could have their own eeprommer, which can be easy enough >>> to use not to require training and costs like 10EUR. >> it's going to be hard to schedule a key roll then, right? > > i have always been fond of rfc 4808 and not the unnecessarily complex > alternatives such as tcp-ao. sure... but to do this you have to be able to program the keys from the platform the SFP is plugged into.. .not via the sfp itself (outside the chassis) From randy at psg.com Wed Jun 25 05:23:08 2014 From: randy at psg.com (Randy Bush) Date: Wed, 25 Jun 2014 14:23:08 +0900 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> Message-ID: >> i have always been fond of rfc 4808 and not the unnecessarily complex >> alternatives such as tcp-ao. > sure... but to do this you have to be able to program the keys from > the platform the SFP is plugged into.. .not via the sfp itself > (outside the chassis) i was advocating the general method, prepping key roll, not the particular use in md5 tcp randy From phulshof at aimvalley.nl Wed Jun 25 05:57:40 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Wed, 25 Jun 2014 07:57:40 +0200 Subject: MACsec SFP In-Reply-To: <53AA3A81.8090805@gmail.com> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> <53AA3A81.8090805@gmail.com> Message-ID: <53AA64D4.3040204@aimvalley.nl> On 25-06-14 04:57, Aris Lambrianidis wrote: > How much ahead of my time would I be if I was to ask for CFP/CFP2 > transceivers supporting MACsec? (at a reasonably competitive price) So far, most requests I got were for 1 Gbps, and some for 10 Gbps. You're the first to mention 100 Gbps, so my guess is that you're ahead of the curve. Frankly, we're still in the process of designing 10 Gbps in this format, and don't have a CFP platform for smart S/CFPs ready yet, but I'll certainly keep it in mind, especially if more people show interest. Some of our larger customers may be interested in it, so I'll check with them. Kind regards, Pieter Hulshoff From phulshof at aimvalley.nl Wed Jun 25 08:55:35 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Wed, 25 Jun 2014 10:55:35 +0200 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> <20140624171953.GA23362@pob.ytti.fi> Message-ID: <53AA8E87.30605@aimvalley.nl> That's a large number of proposals. :) I'll have a chat with some colleagues about the types outside my areas of expertise to see what they think about it. You're not the first to mention separately tunable transmitters and receivers. Do you think there would be a great demand for this device? Anyone else care to wager in on these proposals; do any of them strike you as something you would be interested in as well? Kind regards, Pieter Hulshoff From eric at flanery.us Wed Jun 25 12:09:49 2014 From: eric at flanery.us (Eric Flanery (eric)) Date: Wed, 25 Jun 2014 05:09:49 -0700 Subject: MACsec SFP In-Reply-To: <53AA8E87.30605@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> <20140624171953.GA23362@pob.ytti.fi> <53AA8E87.30605@aimvalley.nl> Message-ID: Those 'proposals' are really just things that would have been useful in module form at one point or another, not necessarily anything that I've given any serious thought to what sort of market they would have. Some are probably impractical, some would probably be far too expensive to actually be useful, and some would probably only have very narrow appeal. That said, I do think the separately tunable tunable transmitters and receivers could be huge, especially if they came at only a reasonably small premium over fixed wavelengths. Just for CWDM as we are implementing it, we need to deal with 16 different wavelengths, and three different transmit powers, giving us 48 different modules to deal with (DWDM would/will only make that worse). If we could cut that to one, or even three, it would make things much simpler, from planning to stocking and sparing. --Eric On Wed, Jun 25, 2014 at 1:55 AM, Pieter Hulshoff wrote: > That's a large number of proposals. :) I'll have a chat with some > colleagues about the types outside my areas of expertise to see what they > think about it. > > You're not the first to mention separately tunable transmitters and > receivers. Do you think there would be a great demand for this device? > > Anyone else care to wager in on these proposals; do any of them strike you > as something you would be interested in as well? > > Kind regards, > > Pieter Hulshoff > > From saku at ytti.fi Wed Jun 25 12:40:18 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 25 Jun 2014 15:40:18 +0300 Subject: MACsec SFP In-Reply-To: References: <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> <20140624171953.GA23362@pob.ytti.fi> <53AA8E87.30605@aimvalley.nl> Message-ID: <20140625124018.GA27940@pob.ytti.fi> On (2014-06-25 05:09 -0700), Eric Flanery (eric) wrote: > That said, I do think the separately tunable tunable transmitters and > receivers could be huge, especially if they came at only a reasonably small I don't think this technology exists. The receivers are always wideband and there is some filter in optical mux or in BX optic to avoid receiving reflections of your own TX. Not sure if tunable filter exists. But you can today buy BX optics which work on same wavelength, so you can use same part in both ends of the connection. -- ++ytti From tdurack at gmail.com Wed Jun 25 12:49:32 2014 From: tdurack at gmail.com (Tim Durack) Date: Wed, 25 Jun 2014 08:49:32 -0400 Subject: MACsec SFP In-Reply-To: <20140625124018.GA27940@pob.ytti.fi> References: <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <20140624160743.GA12742@pob.ytti.fi> <20140624171953.GA23362@pob.ytti.fi> <53AA8E87.30605@aimvalley.nl> <20140625124018.GA27940@pob.ytti.fi> Message-ID: On Wed, Jun 25, 2014 at 8:40 AM, Saku Ytti wrote: > On (2014-06-25 05:09 -0700), Eric Flanery (eric) wrote: > > > That said, I do think the separately tunable tunable transmitters and > > receivers could be huge, especially if they came at only a reasonably > small > > I don't think this technology exists. The receivers are always wideband and > there is some filter in optical mux or in BX optic to avoid receiving > reflections of your own TX. > Not sure if tunable filter exists. > Tunable rx exists in pluggable format, but it is called 100G coherent :-) I would find tunable rx useful for 1/10G (eliminate DCM, power-splitter based WDM etc), but not sure there is enough market for the product to exist. Closest I got was inline FBG fiber patch. There are manufacturers for these. Tim:> From jra at baylink.com Wed Jun 25 14:17:25 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 25 Jun 2014 10:17:25 -0400 (EDT) Subject: [VoiceOps] Monitoring tools In-Reply-To: <6D497FE8AFD83E49AFADD9114C569F8F1ABD13CD72@EXMBX10.exchhosting.com> Message-ID: <33180557.4686.1403705845543.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joseph Jackson" > Check out Homer @ http://sipcapture.org we love it. There is also a > commercial version that has more features / support. Well, I don't know if Homer hsa the realtime viz tool I'm looking for, but if it lives up to the attitude of it's website and prezi, then it's probably a good thing that I know about it anyway, thanks. Wonder if anyone's working on Sonus support. 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 jra at baylink.com Wed Jun 25 14:28:05 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 25 Jun 2014 10:28:05 -0400 (EDT) Subject: [VoiceOps] Monitoring tools In-Reply-To: <33180557.4686.1403705845543.JavaMail.root@benjamin.baylink.com> Message-ID: <15322305.4704.1403706485642.JavaMail.root@benjamin.baylink.com> Damnit, I hate non RFC 2919 compliant mailers. Sorry. ----- Original Message ----- > From: "Jay Ashworth" > To: "NANOG" > Sent: Wednesday, June 25, 2014 10:17:25 AM > Subject: Re: [VoiceOps] Monitoring tools > ----- Original Message ----- > > From: "Joseph Jackson" > > > Check out Homer @ http://sipcapture.org we love it. There is also a > > commercial version that has more features / support. > > Well, I don't know if Homer hsa the realtime viz tool I'm looking for, > but if it lives up to the attitude of it's website and prezi, then > it's > probably a good thing that I know about it anyway, thanks. > > Wonder if anyone's working on Sonus support. > > 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 -- 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 jcurran at arin.net Wed Jun 25 15:05:44 2014 From: jcurran at arin.net (John Curran) Date: Wed, 25 Jun 2014 15:05:44 +0000 Subject: Remote Participation on Internet Identifier Topics of Interest at ICANN 50 References: <53AAE291.2090605@arin.net> Message-ID: NANOGer's - There are going to be two ICANN sessions tomorrow in the area of coordination of Internet identifiers: the first one is about "Enhancing ICANN Accountability", and the second session is on the "Transition of Stewardship of the IANA Functions". If you are interested in the accountability and oversight of the Internet identifier system, you may find remote participation worthwhile. Attached is details regarding the sessions and a link to the remote participation details. FYI, /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] Remote Participation on Topics of Interest at ICANN 50 Date: June 25, 2014 at 3:54:09 PM GMT+1 To: > ICANN 50 is currently underway in London, UK. This is the largest ICANN meeting to date with over 3,000 registered participants. This is in no small part due to the important discussions taking place on a variety of topics. Two relevant sessions for the ARIN community include "Enhancing ICANN Accountability" and "Transition of NTIA's Stewardship of the IANA Functions" While NTIA has announced an intention to transition the stewardship of the IANA functions to the global Internet community, it is now necessary for all stakeholders to work together to develop a plan for this important transition. I urge you to take the time to listen in and participate remotely in both of these sessions. As part of the larger Internet ecosystem, the ARIN community needs to have a strong voice in these discussions. Both sessions will be held on 26 July. Enhancing ICANN Accountability: 10:30 – 12:30 BST Transition of NTIA 's Stewardship of the IANA Functions - 1:30 – 330 BST Direct links to the webcast and remote participation will be available when you expand the menu for the session in the "Happening Now" box at https://london50.icann.org/en. There is no registration required for remote participation. Full details on ICANN Remote participation services are available at: http://meetings.icann.org/remote-participation Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From jschiel at flowtools.net Wed Jun 25 20:17:12 2014 From: jschiel at flowtools.net (John Schiel) Date: Wed, 25 Jun 2014 14:17:12 -0600 Subject: MACsec SFP In-Reply-To: <53A9D104.7070703@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> Message-ID: Would be nice if we knew what the protocol was that communicated this information down to the SFP and would also be nice if that was an open protocol subject to review. UDP something? is my guess but ow do those messages look? I'm new to the MACsec idea but I would hope we could watch for such key exchange traversing the wire and have some method to ignore spurious messages and keys that may lock up a valid, working SFP. --John On Tue, Jun 24, 2014 at 1:27 PM, Pieter Hulshoff wrote: > On 24-06-14 17:50, Christopher Morrow wrote: > >> So.. now when my SFP in Elbonia dies I need to get a truck to Elbonia >> AND it's paired link in west caledonia? yikes. Also, is that a >> 'ybFxasasdasd' on the serial-number/key-pair-note or ybfXasdadasdsd' >> Gosh joe I'm not sure... >> > > Obviously this solution wouldn't work for everyone, but I think for those > people who prefer a simple unmanaged plug-and-play solution it would work > just fine. > > > Programmable seems like the way to go, provided there's a path to do >> that in the cli of the device you plugged the SFP into? (which I think >> is the hard part actually, right?) >> > > Actually, there are many other ways to solve this. If you want unmanaged > still, you could opt for using a key infrastructure combined with 802.1X > EAPOL. For managed solutions, the device could be made programmable via > I2C, in-band from the switch or even in-band from the line. We have several > such managed smart SFPs in our portfolio, so adding such features to this > device will not be a problem. A management channel however is an also added > security risk, so not everybody would be in favour of that. No size fits > all. > > > > On 24-06-14 18:30, Christopher Morrow wrote: > >> it's going to be hard to schedule a key roll then, right? I would >> expect that in most/many deployments where someone enters a 'key' >> there has to be some compliance process that includes: "And you change >> that key every X days" right? So you'll NOT want to be in a situation >> that involves coordinating a few thousand truck rolls every X months >> to have this deployed. >> > > True, though an MKA PSK could safely be used for the life-time of a > device. Should one want a regular key roll though, the CAK could be given a > life-time, with a new one distributed automatically via MKA or EAPOL when > it expires. It's also possible to set up a management command to do the > same thing at the operator's request. Plenty of options; I'm trying to find > out what demand there is for each to determine what should make our first > release, and what will not. :) > > Kind regards, > > Pieter Hulshoff > > From morrowc.lists at gmail.com Wed Jun 25 20:45:00 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Jun 2014 16:45:00 -0400 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> Message-ID: On Wed, Jun 25, 2014 at 4:17 PM, John Schiel wrote: > Would be nice if we knew what the protocol was that communicated this > information down to the SFP and would also be nice if that was an open > protocol subject to review. UDP something? is my guess but ow do those > messages look? today you program the key (on switches that do macsec, not in an SFP that does it for you, cause those don't exist, yet) in your router config and as near as I have seen there isn't a key distribution protocol aside from that which you write/manage yourself and which is likely using ssh/snmp(ick)/telnet(ick). > I'm new to the MACsec idea but I would hope we could watch for such key > exchange traversing the wire and have some method to ignore spurious > messages and keys that may lock up a valid, working SFP. > > --John > > > On Tue, Jun 24, 2014 at 1:27 PM, Pieter Hulshoff > wrote: > >> On 24-06-14 17:50, Christopher Morrow wrote: >> >>> So.. now when my SFP in Elbonia dies I need to get a truck to Elbonia >>> AND it's paired link in west caledonia? yikes. Also, is that a >>> 'ybFxasasdasd' on the serial-number/key-pair-note or ybfXasdadasdsd' >>> Gosh joe I'm not sure... >>> >> >> Obviously this solution wouldn't work for everyone, but I think for those >> people who prefer a simple unmanaged plug-and-play solution it would work >> just fine. >> >> >> Programmable seems like the way to go, provided there's a path to do >>> that in the cli of the device you plugged the SFP into? (which I think >>> is the hard part actually, right?) >>> >> >> Actually, there are many other ways to solve this. If you want unmanaged >> still, you could opt for using a key infrastructure combined with 802.1X >> EAPOL. For managed solutions, the device could be made programmable via >> I2C, in-band from the switch or even in-band from the line. We have several >> such managed smart SFPs in our portfolio, so adding such features to this >> device will not be a problem. A management channel however is an also added >> security risk, so not everybody would be in favour of that. No size fits >> all. >> >> >> >> On 24-06-14 18:30, Christopher Morrow wrote: >> >>> it's going to be hard to schedule a key roll then, right? I would >>> expect that in most/many deployments where someone enters a 'key' >>> there has to be some compliance process that includes: "And you change >>> that key every X days" right? So you'll NOT want to be in a situation >>> that involves coordinating a few thousand truck rolls every X months >>> to have this deployed. >>> >> >> True, though an MKA PSK could safely be used for the life-time of a >> device. Should one want a regular key roll though, the CAK could be given a >> life-time, with a new one distributed automatically via MKA or EAPOL when >> it expires. It's also possible to set up a management command to do the >> same thing at the operator's request. Plenty of options; I'm trying to find >> out what demand there is for each to determine what should make our first >> release, and what will not. :) >> >> Kind regards, >> >> Pieter Hulshoff >> >> From michael.holstein at csuohio.edu Wed Jun 25 20:45:07 2014 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Wed, 25 Jun 2014 20:45:07 +0000 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl>, Message-ID: <1403729106767.57519@csuohio.edu> >protocol was that communicated this information down to the SFP For EEPROM access in a SFP+ it's I2C with is well documented and used in tons of embedded stuff .. commercial logic analysis tools can handle this protocol, as can your average $10 Arudrino. Of course writing certain parts of the SFP+ EEPROM are "protected" for obvious reasons but that certainly hasn't stopped people. Cheers, Michael Holstein Cleveland State University From phulshof at aimvalley.nl Wed Jun 25 20:45:38 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Wed, 25 Jun 2014 22:45:38 +0200 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> Message-ID: <53AB34F2.3070904@aimvalley.nl> On 25-06-14 22:17, John Schiel wrote: > Would be nice if we knew what the protocol was that communicated this > information down to the SFP and would also be nice if that was an open > protocol subject to review. UDP something? is my guess but ow do those > messages look? > > I'm new to the MACsec idea but I would hope we could watch for such > key exchange traversing the wire and have some method to ignore > spurious messages and keys that may lock up a valid, working SFP. It hasn't been decided yet. For our current portfolio of managed device we use a proprietary layer-2 protocol, and offer a network management module that can be integrated into a network management system, a smart device gateway with SNMP support, and an integrated network management in Creanord's EchoVault system. Layer-3 management support is under investigation. Obviously, any key communication over the line would be encrypted, but what security system will be used will depend greatly on the chosen communication protocol. This will in part depend on the customer feedback I get, which currently range from our current layer-2 solution to a web interface to a CLI. If we go layer-3, we'll probably use a standard like SSL/TLS for web pages, and SSH for CLI. Kind regards, Pieter Hulshoff From phulshof at aimvalley.nl Wed Jun 25 20:51:04 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Wed, 25 Jun 2014 22:51:04 +0200 Subject: MACsec SFP In-Reply-To: References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> Message-ID: <53AB3638.8040300@aimvalley.nl> On 25-06-14 22:45, Christopher Morrow wrote: > today you program the key (on switches that do macsec, not in an SFP > that does it for you, cause those don't exist, yet) in your router > config and as near as I have seen there isn't a key distribution > protocol aside from that which you write/manage yourself and which is > likely using ssh/snmp(ick)/telnet(ick). I'm not familiar with the MACsec key distribution available in current routers/switches. Are you saying Cisco doesn't support EAP and/or MKA for this purpose or just that the command protocol for configuring EAP/MKA is run via SSH/SNMP/telnet? Kind regards, Pieter Hulshoff From morrowc.lists at gmail.com Wed Jun 25 21:02:49 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Jun 2014 17:02:49 -0400 Subject: MACsec SFP In-Reply-To: <53AB3638.8040300@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> <53AB3638.8040300@aimvalley.nl> Message-ID: On Wed, Jun 25, 2014 at 4:51 PM, Pieter Hulshoff wrote: > On 25-06-14 22:45, Christopher Morrow wrote: >> >> today you program the key (on switches that do macsec, not in an SFP >> that does it for you, cause those don't exist, yet) in your router >> config and as near as I have seen there isn't a key distribution >> protocol aside from that which you write/manage yourself and which is >> likely using ssh/snmp(ick)/telnet(ick). > > > I'm not familiar with the MACsec key distribution available in current > routers/switches. Are you saying Cisco doesn't support EAP and/or MKA for > this purpose or just that the command protocol for configuring EAP/MKA is > run via SSH/SNMP/telnet? I had looked a bit ago (like a year or so perhaps longer) for this and it seemed like command-line on the switch functions only. This: (for 15.0 IOS on a 3750... ymmv on others of course) it lookslike they have MKA (and eap) for user-facing ports, and some nutty cisco thing (trustsec) for switch-to-switch. I never looked at this for machine-facing ports... Oh, the manual setup for switch-to-switch is possibly what i recall from my last look at this. -chris From tdurack at gmail.com Wed Jun 25 22:10:38 2014 From: tdurack at gmail.com (Tim Durack) Date: Wed, 25 Jun 2014 18:10:38 -0400 Subject: MACsec SFP In-Reply-To: <53AB3638.8040300@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> <53AB3638.8040300@aimvalley.nl> Message-ID: On Cisco equipment supporting MACsec, EAP and MKA is of course configured through the normal cli. On Wednesday, June 25, 2014, Pieter Hulshoff wrote: > On 25-06-14 22:45, Christopher Morrow wrote: > >> today you program the key (on switches that do macsec, not in an SFP >> that does it for you, cause those don't exist, yet) in your router >> config and as near as I have seen there isn't a key distribution >> protocol aside from that which you write/manage yourself and which is >> likely using ssh/snmp(ick)/telnet(ick). >> > > I'm not familiar with the MACsec key distribution available in current > routers/switches. Are you saying Cisco doesn't support EAP and/or MKA for > this purpose or just that the command protocol for configuring EAP/MKA is > run via SSH/SNMP/telnet? > > Kind regards, > > Pieter Hulshoff > > -- Tim:> From lijun at cs.uoregon.edu Wed Jun 25 06:03:01 2014 From: lijun at cs.uoregon.edu (Jun Li) Date: Tue, 24 Jun 2014 23:03:01 -0700 (PDT) Subject: NPSec 2014: Call for Papers (Submission Deadline: July 10) Message-ID: CALL FOR PAPERS Ninth Workshop on Secure Network Protocols (NPSec 2014) Raleigh, North Carolina, USA October 21, 2014 In conjunction with the 22nd IEEE International Conference on Network Protocols (ICNP 2014) Web page: http://netsec.cs.uoregon.edu/npsec2014 Important dates Submission Deadline: July 10, 2014 (11:59 PM PDT) Notification of acceptance: August 2, 2014 Camera ready version: August 16, 2014 Scope The Workshop on Secure Network Protocols (NPSec) is a top workshop focusing on cutting-edge research with a broad range of topics related to secure network protocols. NPSec 2014 focuses on two exciting areas related to secure network protocols. The first focus is on the development and analysis of networking protocols for the secure operation of various network infrastructures, including both today's Internet and future Internet architectures, wireless and mobile networking, cloud-based networking, peer-to-peer and overlay networks, online social networking, and Internet of things. Papers about new secure protocols, security enhancements to existing protocols, or protocol analysis (such as new attacks on existing protocols) are all welcome. The second focus is on employing such secure network protocols to create or enhance network applications, such as those related to the Web, online social networking, online gaming, or cloud-based applications. Topics of interest include but are not limited to: Vulnerabilities of existing protocols and applications (both theoretical and case studies), including attacks; Design of new secure or resilient network protocols; Security enhancements to existing networking protocols Deployment study of secure protocols on the Internet (e.g., BGPSEC, DNSSEC, IPSEC); Security in future Internet architectures (e.g. Information-centric networking, software-defined networking); Secure network protocols for network applications (e.g., cloud-based apps, online social networking, gaming) Submission requirements Papers need to be submitted at the web page http://edas.info/newPaper.php?c=18197. Submitted papers must be no longer than six (6) pages in double-column format with standard margins (i.e., at least one inch all around) and at least a 10 point font. This length includes everything: figures, tables, references, appendices, and so forth. Longer submissions will not be reviewed. Papers must be written in English and formatted for printing on US LETTER (8.5" by 11") size paper. Papers should include a title; full list of authors, their organization and email address; and an abstract of fewer than 200 words. All papers must adhere to IEEE formatting standards. Consult the IEEE Transactions LaTeX and Microsoft Word Style Files (http://www.ieee.org/web/publications/authors/transjnl/index.html). Papers must be submitted in PDF (Portable Document Format) and compatible with Acrobat (English version), not including any special characters or non-standard fonts. Best Paper Award and Journal Publication The Best Paper Award Committee of NPSec 2014 will select a paper in this year's NPSec Program to receive the Best Paper Award. Every accepted paper will be considered based on its originality, writing quality, potential of impact, and its presentation at the workshop. We are further working on establishing a journal special issue on secure network protocols. While open to the public, the special issue will also invite the authors of quality papers from NPSec to submit an extended version of their work. Steering Committee: Sonia Fahmy, Purdue University, USA (chair) George Kesidis, Penn State University, USA Cristina Nita-Rotaru, Purdue University, USA Gene Tsudik, UC Irvine, USA Technical Program Committee: Johanna Amann, International Computer Science Institute Fred Baker, Cisco Research Center Randy Bush, Internet Initiative Japan Wu-chang Feng, Portland State University Stephen Kent, BBN Technololgies Huan Li, Beihang University Qi Li, ETH Zurich Olaf Maennel, Loughborough University Daniel Massey, US Department of Homeland Security Colin Perkins, University of Glasgow Peter Reiher, UCLA Lan Wang, University of Memphis Brian Weis, Cisco Systems Tilman Wolf, University of Massachusetts Ying Zhang, Ericsson Research Xukai Zou, School of Science, Purdue University-Indianapolis Technical Program Committee Chairs: Jun Li, University of Oregon, USA Wei Zhao, University of Macau, China From stopabuseandreport at gmail.com Thu Jun 26 02:16:23 2014 From: stopabuseandreport at gmail.com (Abuse Contact) Date: Wed, 25 Jun 2014 19:16:23 -0700 Subject: Anycast Message-ID: Hello, So I'm new to owning my own IPs. I want to setup multiple locations for a new service that I'm starting , one location in the USA East and one location in the USA West (to get started). I originally thought that IP Anycasting happened when you have to get a IP Transit from a T1 network like NTT or something and then tell them to set it up for each location;however, now I'm hearing that you need to just announce the IPs at multiple DCs. Could somebody please clarify this confusion for me? Thanks. From mehmet at akcin.net Thu Jun 26 02:32:53 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 26 Jun 2014 03:32:53 +0100 Subject: Anycast In-Reply-To: References: Message-ID: <5678ACE5-8804-4083-9069-7368BFA5E959@akcin.net> http://www.youtube.com/watch?v=sV45Klc3tiE&sns=em http://www.youtube.com/watch?v=VHjlvHdrmSQ&sns=em two good, fairly detailed video by ISC. > On Jun 26, 2014, at 3:16 AM, Abuse Contact wrote: > > Hello, > So I'm new to owning my own IPs. I want to setup multiple locations for a > new service that I'm starting , one location in the USA East and one > location in the USA West (to get started). I originally thought that IP > Anycasting happened when you have to get a IP Transit from a T1 network > like NTT or something and then tell them to set it up for each > location;however, now I'm hearing that you need to just announce the IPs at > multiple DCs. Could somebody please clarify this confusion for me? > > Thanks. From saku at ytti.fi Thu Jun 26 06:24:11 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 26 Jun 2014 09:24:11 +0300 Subject: MACsec SFP In-Reply-To: <53AB34F2.3070904@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> <53AB34F2.3070904@aimvalley.nl> Message-ID: <20140626062411.GA16296@pob.ytti.fi> On (2014-06-25 22:45 +0200), Pieter Hulshoff wrote: > chosen communication protocol. This will in part depend on the customer > feedback I get, which currently range from our current layer-2 solution to a > web interface to a CLI. If we go layer-3, we'll probably use a standard like > SSL/TLS for web pages, and SSH for CLI. Problem I have with SFP getting control-plane is that then I need provisioning and potentially config backup system. I think router CLI and I2C is right place for this, obviously it creates lag, as first routers won't support it, and you need to do it offline. Perhaps such lag could be avoided in future if we'd specify some 'host to SFP' high level protocol, perhaps in much the same way as DHCP 'option' handling? In this case, router could code arbitrary value to arbitrary option without understanding what it means, and down the line introduce syntactic sugar for commonly used features. -- ++ytti From jcurran at arin.net Thu Jun 26 16:45:43 2014 From: jcurran at arin.net (John Curran) Date: Thu, 26 Jun 2014 16:45:43 +0000 Subject: Volunteer to Serve on the ARIN 2014 Nominating Committee? References: <53AC3599.6080902@arin.net> Message-ID: <0DDDD843-EB9F-4083-87B0-FAB54D06A50E@corp.arin.net> Folks - If you are an ARIN member, please consider volunteering to serve on the 2014 ARIN Nominating Committee (which helps develop the slate of candidates for ARIN's AC and Trustee election) Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] Volunteer to Serve on the 2014 NomCom Date: June 26, 2014 at 4:00:41 PM GMT+1 To: > ARIN is still seeking five (5) General Members in good standing to serve on the 2014 ARIN Nomination Committee (NomCom). Want to help select this year’s slate of candidates? Submit your name, email address, ARIN member organization name, and ORG ID toinfo at arin.net before 5:00 PM EDT on Thursday, 3 July 2014. Already appointed NomCom Members Aaron Hughes (NomCom Chair) and Paul Andersen shall select and appoint the five additional individual representatives from the pool of volunteers, which may include up to two (2) serving Advisory Council members. Please note that candidates for this year's Board of Trustees and Advisory Council elections cannot sit on the NomCom. If selected you are required to sign and return a Non-Disclosure Agreement within three business days of being notified of your selection. You can view this NDA at: https://www.arin.net/participate/elections/nomcom_nda.pdf The NomCom is responsible for identifying, recruiting, and certifying a properly selected slate of Trustee and Advisory Council candidates to be placed in nomination before the membership for election. The responsibilities of the Committee are explained in the Bylaws at:https://www.arin.net/about_us/corp_docs/bylaws.html You can learn more by reading the links below. NomCom Charter: https://www.arin.net/about_us/committeecharters.html#nomcom Nomination Committee FAQ: https://www.arin.net/participate/elections/nomcom_faqs.html Nomination and Election Procedures: https://www.arin.net/participate/elections/board.html#nomcom Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From LarrySheldon at cox.net Fri Jun 27 04:07:54 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 26 Jun 2014 23:07:54 -0500 Subject: Owning a name Message-ID: <53ACEE1A.5010404@cox.net> http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html Have not seen much discussion about this. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From patrick at ianai.net Fri Jun 27 04:13:16 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 27 Jun 2014 00:13:16 -0400 Subject: Owning a name In-Reply-To: <53ACEE1A.5010404@cox.net> References: <53ACEE1A.5010404@cox.net> Message-ID: <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> On Jun 27, 2014, at 00:07 , Larry Sheldon wrote: > http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html > > Have not seen much discussion about this. That would be a horrifically bad precedent to set. I hope this insanity stops before it get started. -- TTFN, patrick From woody at pch.net Fri Jun 27 04:20:30 2014 From: woody at pch.net (Bill Woodcock) Date: Thu, 26 Jun 2014 21:20:30 -0700 Subject: Owning a name In-Reply-To: <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: On Jun 26, 2014, at 9:13 PM, Patrick W. Gilmore wrote: > On Jun 27, 2014, at 00:07 , Larry Sheldon wrote: > >> http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html >> >> Have not seen much discussion about this. > > That would be a horrifically bad precedent to set. I hope this insanity stops before it get started. Anyone have a link to the actual ruling? This URL is to a very positionally-specific interpretation of events, which is fairly disconnected from reality on the ICANN side… It’s quite possible it’s an equally clueless interpretation of the court decision. In any event, even if the court was as clueless as this implies, it won’t go anywhere. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brunner at nic-naa.net Fri Jun 27 04:32:38 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 26 Jun 2014 21:32:38 -0700 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: <53ACF3E6.4090301@nic-naa.net> On 6/26/14 9:20 PM, Bill Woodcock wrote: > On Jun 26, 2014, at 9:13 PM, Patrick W. Gilmore wrote: > >> On Jun 27, 2014, at 00:07 , Larry Sheldon wrote: >> >>> http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html >>> >>> Have not seen much discussion about this. >> That would be a horrifically bad precedent to set. I hope this insanity stops before it get started. > Anyone have a link to the actual ruling? This URL is to a very positionally-specific interpretation of events, which is fairly disconnected from reality on the ICANN side… It’s quite possible it’s an equally clueless interpretation of the court decision. In any event, even if the court was as clueless as this implies, it won’t go anywhere. > > -Bill > > > > please see the iana's redelegation rules. start with .pn looking for first principles. -e From LarrySheldon at cox.net Fri Jun 27 04:35:49 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 26 Jun 2014 23:35:49 -0500 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: <53ACF4A5.6060900@cox.net> On 6/26/2014 11:20 PM, Bill Woodcock wrote: > > On Jun 26, 2014, at 9:13 PM, Patrick W. Gilmore > wrote: > >> On Jun 27, 2014, at 00:07 , Larry Sheldon >> wrote: >> >>> http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html >>> >>> >>> Have not seen much discussion about this. >> >> That would be a horrifically bad precedent to set. I hope this >> insanity stops before it get started. > > Anyone have a link to the actual ruling? This URL is to a very > positionally-specific interpretation of events, which is fairly > disconnected from reality on the ICANN side… It’s quite possible > it’s an equally clueless interpretation of the court decision. In > any event, even if the court was as clueless as this implies, it > won’t go anywhere. http://richardedmondson.net/2014/06/25/us-court-ruling-theoretically-could-mean-shut-down-of-iranian-web-sites/ quotes other articles--non seem to be the ruling per se. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From joly at punkcast.com Fri Jun 27 04:35:34 2014 From: joly at punkcast.com (Joly MacFie) Date: Fri, 27 Jun 2014 00:35:34 -0400 Subject: Owning a name In-Reply-To: <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: But, are ccTLDs licenced by ICANN? I thought they were independent. j On Fri, Jun 27, 2014 at 12:13 AM, Patrick W. Gilmore wrote: > On Jun 27, 2014, at 00:07 , Larry Sheldon wrote: > > > > http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html > > > > Have not seen much discussion about this. > > That would be a horrifically bad precedent to set. I hope this insanity > stops before it get started. > > -- > TTFN, > patrick > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From collin at averysmallbird.com Fri Jun 27 04:38:05 2014 From: collin at averysmallbird.com (Collin Anderson) Date: Thu, 26 Jun 2014 21:38:05 -0700 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: As best as I and others have been able to discern, the order in question is a subpoena to ICANN pertaining to contracts, financial information and communications with the Iranian government over their names and addresses. The claims of granted control appear to be inaccurate -- all of the reporting on the matter have been childish to the extent of saying Dot-Iran (‏.ایران) is in Arabic. The next step would be for ICANN to challenge the request, and one might expect that communities such as this one would have an opportunity to amicus along the way. On Thu, Jun 26, 2014 at 9:20 PM, Bill Woodcock wrote: > > On Jun 26, 2014, at 9:13 PM, Patrick W. Gilmore wrote: > > > On Jun 27, 2014, at 00:07 , Larry Sheldon wrote: > > > >> > http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html > >> > >> Have not seen much discussion about this. > > > > That would be a horrifically bad precedent to set. I hope this insanity > stops before it get started. > > Anyone have a link to the actual ruling? This URL is to a very > positionally-specific interpretation of events, which is fairly > disconnected from reality on the ICANN side… It’s quite possible it’s an > equally clueless interpretation of the court decision. In any event, even > if the court was as clueless as this implies, it won’t go anywhere. > > -Bill > > > > > -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. From collin at averysmallbird.com Fri Jun 27 04:40:38 2014 From: collin at averysmallbird.com (Collin Anderson) Date: Thu, 26 Jun 2014 21:40:38 -0700 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: It might also interest the list that every couple of years ICANN actually has to apply to the Department of Treasury's OFAC in order to obtain a license to do business with Iranian parties. On Thu, Jun 26, 2014 at 9:38 PM, Collin Anderson wrote: > As best as I and others have been able to discern, the order in question > is a subpoena to ICANN pertaining to contracts, financial information and > communications with the Iranian government over their names and addresses. > The claims of granted control appear to be inaccurate -- all of the > reporting on the matter have been childish to the extent of saying Dot-Iran > (‏.ایران) is in Arabic. The next step would be for ICANN to challenge the > request, and one might expect that communities such as this one would have > an opportunity to amicus along the way. > > > On Thu, Jun 26, 2014 at 9:20 PM, Bill Woodcock wrote: > >> >> On Jun 26, 2014, at 9:13 PM, Patrick W. Gilmore >> wrote: >> >> > On Jun 27, 2014, at 00:07 , Larry Sheldon wrote: >> > >> >> >> http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html >> >> >> >> Have not seen much discussion about this. >> > >> > That would be a horrifically bad precedent to set. I hope this insanity >> stops before it get started. >> >> Anyone have a link to the actual ruling? This URL is to a very >> positionally-specific interpretation of events, which is fairly >> disconnected from reality on the ICANN side… It’s quite possible it’s an >> equally clueless interpretation of the court decision. In any event, even >> if the court was as clueless as this implies, it won’t go anywhere. >> >> -Bill >> >> >> >> >> > > > -- > *Collin David Anderson* > averysmallbird.com | @cda | Washington, D.C. > -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. From zaid at zaidali.com Fri Jun 27 04:46:05 2014 From: zaid at zaidali.com (Zaid A. Kahn) Date: Thu, 26 Jun 2014 21:46:05 -0700 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: The concept of owned and assets is greatly misunderstood by lawyers in this case. This will go nowhere. Zaid On Jun 26, 2014, at 9:35 PM, Joly MacFie wrote: > But, are ccTLDs licenced by ICANN? I thought they were independent. > > j > > > On Fri, Jun 27, 2014 at 12:13 AM, Patrick W. Gilmore > wrote: > >> On Jun 27, 2014, at 00:07 , Larry Sheldon wrote: >> >>> >> http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html >>> >>> Have not seen much discussion about this. >> >> That would be a horrifically bad precedent to set. I hope this insanity >> stops before it get started. >> >> -- >> TTFN, >> patrick >> >> >> > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > -------------------------------------------------------------- > - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johnl at iecc.com Fri Jun 27 05:00:29 2014 From: johnl at iecc.com (John Levine) Date: 27 Jun 2014 05:00:29 -0000 Subject: Owning a name In-Reply-To: <53ACEE1A.5010404@cox.net> Message-ID: <20140627050029.47186.qmail@joyce.lan> In article <53ACEE1A.5010404 at cox.net> you write: >http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html > >Have not seen much discussion about this. The aroma of BS is pretty intense here. There was a press release last week saying that she'd filed the case, and no Federal court would rule in a week. I've been looking for the case in PACER, and don't see anything filed this year against ICANN so the case doesn't even exist. Further clues: * ICANN has no agreement with Iran for .ir nor the new IDN domain, so .ir pays ICANN nothing. * Address space for Iranian networks come from RIPE, not ICANN. If Iran pays any address space maintenance fees, they'd go to RIPE, which is in Europe, not in the U.S. R's, John From collin at averysmallbird.com Fri Jun 27 05:14:29 2014 From: collin at averysmallbird.com (Collin Anderson) Date: Thu, 26 Jun 2014 22:14:29 -0700 Subject: Owning a name In-Reply-To: <20140627050029.47186.qmail@joyce.lan> References: <53ACEE1A.5010404@cox.net> <20140627050029.47186.qmail@joyce.lan> Message-ID: On Thu, Jun 26, 2014 at 10:00 PM, John Levine wrote: > I've been looking for the case in PACER, and don't see > anything filed this year against ICANN so the case doesn't even exist. > Seth Charles Ben HAIM, et al., Plaintiffs, v. The ISLAMIC REPUBLIC OF IRAN, et al., Defendants. Civil Action No. 02-1811 (RCL) -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. From phulshof at aimvalley.nl Fri Jun 27 07:05:57 2014 From: phulshof at aimvalley.nl (Pieter Hulshoff) Date: Fri, 27 Jun 2014 09:05:57 +0200 Subject: MACsec SFP In-Reply-To: <53A7EFD5.8080502@aimvalley.nl> References: <53A7EFD5.8080502@aimvalley.nl> Message-ID: <53AD17D5.1080102@aimvalley.nl> I was wondering: Would there be an interest in a similar IPsec SFP or is that part already well taken care of by the router market? Kind regards, Pieter Hulshoff From woody at pch.net Fri Jun 27 07:40:39 2014 From: woody at pch.net (Bill Woodcock) Date: Fri, 27 Jun 2014 00:40:39 -0700 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <20140627050029.47186.qmail@joyce.lan> Message-ID: <11BE2CF1-74EE-49C2-A948-D27C7CC92A74@pch.net> On Jun 26, 2014, at 10:14 PM, Collin Anderson wrote: > On Thu, Jun 26, 2014 at 10:00 PM, John Levine wrote: > >> I've been looking for the case in PACER, and don't see >> anything filed this year against ICANN so the case doesn't even exist. >> > > Seth Charles Ben HAIM, et al., Plaintiffs, v. The ISLAMIC REPUBLIC OF IRAN, > et al., Defendants. Civil Action No. 02-1811 (RCL) http://freebeacon.com/wp-content/uploads/2014/06/Subpoena-Ben-Haim-02-1611-with-Schedule-A.pdf -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From drc at virtualized.org Fri Jun 27 07:50:23 2014 From: drc at virtualized.org (David Conrad) Date: Fri, 27 Jun 2014 08:50:23 +0100 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: On Jun 27, 2014, at 5:35 AM, Joly MacFie wrote: > But, are ccTLDs licenced by ICANN? No. Some ccTLD managers have signed "Affirmations of Commitments" with ICANN that basically say both ICANN and the ccTLD admit each other exists, but it isn't required. > I thought they were independent. Yes. ccTLDs are treated as national sovereign resources. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From collin at averysmallbird.com Fri Jun 27 14:49:22 2014 From: collin at averysmallbird.com (Collin Anderson) Date: Fri, 27 Jun 2014 14:49:22 +0000 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: On Fri, Jun 27, 2014 at 7:50 AM, David Conrad wrote: > Yes. ccTLDs are treated as national sovereign resources. > By whom and where? Regardless, there are 'State Sponsors of Terrorism'-related amendments to the Foreign Sovereign Immunities Act that come into play here. -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. From fergdawgster at mykolab.com Fri Jun 27 14:59:49 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 27 Jun 2014 07:59:49 -0700 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <9AB00982-7E2F-4F2D-8E9B-BF9C287AA1EA@ianai.net> Message-ID: <53AD86E5.80302@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 6/27/2014 7:49 AM, Collin Anderson wrote: > On Fri, Jun 27, 2014 at 7:50 AM, David Conrad > wrote: > >> Yes. ccTLDs are treated as national sovereign resources. >> > > By whom and where? > > Regardless, there are 'State Sponsors of Terrorism'-related > amendments to the Foreign Sovereign Immunities Act that come into > play here. > "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." - Jon Postel, RFC 1591 - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOthuUACgkQKJasdVTchbIKegD+M7kYkdYc1HRfvpPAltW0cDUK kWoWdpuE0LyO4PskBMQBALt0zloqKkLQ/ZCUuXw8UMf56Mrc29j91QBwKz+GsDJr =0sSc -----END PGP SIGNATURE----- From johnl at iecc.com Fri Jun 27 15:13:31 2014 From: johnl at iecc.com (John Levine) Date: 27 Jun 2014 15:13:31 -0000 Subject: Owning a name In-Reply-To: Message-ID: <20140627151331.53473.qmail@joyce.lan> >> Yes. ccTLDs are treated as national sovereign resources. > >By whom and where? > >Regardless, there are 'State Sponsors of Terrorism'-related amendments to >the Foreign Sovereign Immunities Act that come into play here. The US has a long policy of not messing with ccTLDs, even of countries that we don't like such as .kp, .cu, and .iq (back in the day). If they started now there would be a firestorm, and not just from companies we don't like. I expect ICANN's response will be to produce what correspondence they have, and to say they have no contracts with Iran, receive no income from Iran, and hold no Iranian assets. The .ir and the new Arabic script From maillist at webjogger.net Fri Jun 27 15:17:43 2014 From: maillist at webjogger.net (Adam Greene) Date: Fri, 27 Jun 2014 11:17:43 -0400 Subject: Team Cymru / Spamhaus Message-ID: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> Hi all, We're evaluating whether to add BGP feeds from these two sources in attempt to minimize exposure to DoS. The Team Cymru BOGON list ( http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt or http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt ) looks promising and common-sense. We already filter RFC1918 inbound at our edge, and are interested to see if adding the rest of the blocks will have a significant positive effect. If it does, we're planning to try the IPv4 FULLBOGON list: http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt We're a little more leery about trying Spamhaus's BGPf service (DROP, EDROP and BCL, http://www.spamhaus.org/bgpf/ ) because we really want to avoid false positives. Just wondering if anyone has any words of caution ("False positives! Avoid FULLBOGONS and Spamhaus!"), or words of praise ("Do it all! These services are wonderful!") before we take the plunge. Thanks, Adam From fergdawgster at mykolab.com Fri Jun 27 15:36:25 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 27 Jun 2014 08:36:25 -0700 Subject: Team Cymru / Spamhaus In-Reply-To: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> References: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> Message-ID: <53AD8F79.3080607@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Could I also encourage you to do anti-spoofing filtering, a la BCP38? - - ferg On 6/27/2014 8:17 AM, Adam Greene wrote: > Hi all, > > > > We're evaluating whether to add BGP feeds from these two sources in > attempt to minimize exposure to DoS. > > > > The Team Cymru BOGON list ( > > http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt or > > http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt > > ) > > looks promising and common-sense. > > > > We already filter RFC1918 inbound at our edge, and are interested > to see if adding the rest of the blocks will have a significant > positive effect. > > > > If it does, we're planning to try the IPv4 FULLBOGON list: > > > > http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt > > > > We're a little more leery about trying Spamhaus's BGPf service > (DROP, EDROP and BCL, > > > > http://www.spamhaus.org/bgpf/ > > ) > > > > because we really want to avoid false positives. > > > > Just wondering if anyone has any words of caution ("False > positives! Avoid FULLBOGONS and Spamhaus!"), or words of praise > ("Do it all! These services are wonderful!") before we take the > plunge. > > > > Thanks, > > Adam > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOtj3kACgkQKJasdVTchbI5hQD/f0DsWNUsebLOX1Io8MqPWmAl JnlMX5cRxNxXgSNEAnoBAMuXCeSHCJvI8jsL6PaGTbh2GA6uktcYpOEfnlG5xfLC =DmDv -----END PGP SIGNATURE----- From dot at dotat.at Fri Jun 27 15:44:20 2014 From: dot at dotat.at (Tony Finch) Date: Fri, 27 Jun 2014 16:44:20 +0100 Subject: Owning a name In-Reply-To: <20140627151331.53473.qmail@joyce.lan> References: <20140627151331.53473.qmail@joyce.lan> Message-ID: John Levine wrote: > > The US has a long policy of not messing with ccTLDs, even of countries > that we don't like such as .kp, .cu, and .iq (back in the day). The latter had a fairly messy history: http://www.iana.org/reports/2005/iq-report-05aug2005.pdf Tony. -- f.anthony.n.finch http://dotat.at/ Irish Sea: East backing northeast 4 or 5. Slight or moderate. Rain or showers. Moderate or good. From mark at rudholm.com Fri Jun 27 05:54:28 2014 From: mark at rudholm.com (Mark Rudholm) Date: Thu, 26 Jun 2014 22:54:28 -0700 Subject: Owning a name In-Reply-To: References: <53ACEE1A.5010404@cox.net> <20140627050029.47186.qmail@joyce.lan> Message-ID: <53AD0714.90408@rudholm.com> On 06/26/2014 10:14 PM, Collin Anderson wrote: > On Thu, Jun 26, 2014 at 10:00 PM, John Levine wrote: > >> I've been looking for the case in PACER, and don't see >> anything filed this year against ICANN so the case doesn't even exist. >> > Seth Charles Ben HAIM, et al., Plaintiffs, v. The ISLAMIC REPUBLIC OF IRAN, > et al., Defendants. Civil Action No. 02-1811 (RCL) It seems to me that even if the ccTLD delegations were removed from the root DNS zone, all sysadmins in Iran would just add the ns.irnic.ir NS record to their cache, effectively ignoring ICANN. I bet a lot of sysadmins outside Iran would do the same thing, since it makes sense to refer to IRNIC for Iranian DNS regardless of any court ruling. Similarly, they'd just keep using their current network numbers. It's not like ARIN would be able to give them to someone else. Nobody would want them. And a lot of us would continue to route those numbers to Iran. Courts have shown time and again that they don't understand that ICANN is a coordinator, not an authority. From halflife4 at gmx.com Fri Jun 27 09:42:50 2014 From: halflife4 at gmx.com (Toney Mareo) Date: Fri, 27 Jun 2014 11:42:50 +0200 Subject: Advice on BGP + uCARP setup on 2 Debian Gateways Message-ID: From IT at SysAccess.net Fri Jun 27 15:22:47 2014 From: IT at SysAccess.net (SysIT) Date: Fri, 27 Jun 2014 15:22:47 +0000 Subject: Team Cymru / Spamhaus In-Reply-To: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> References: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> Message-ID: <8ae484ef995249688559b8ca999e84c6@Email-02.true.local> That wont stop a DoS. A DoS or DDoS is pure bandwidth wars for the most part, if someone is to DoS you, they already have your IP's and urls they need to attack you, thus a spam list won't stop an attack. If you want to minimize actual spam, sure. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Adam Greene Sent: Friday, June 27, 2014 9:18 AM To: 'NANOG list' Subject: Team Cymru / Spamhaus Hi all, We're evaluating whether to add BGP feeds from these two sources in attempt to minimize exposure to DoS. The Team Cymru BOGON list ( http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt or http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt ) looks promising and common-sense. We already filter RFC1918 inbound at our edge, and are interested to see if adding the rest of the blocks will have a significant positive effect. If it does, we're planning to try the IPv4 FULLBOGON list: http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt We're a little more leery about trying Spamhaus's BGPf service (DROP, EDROP and BCL, http://www.spamhaus.org/bgpf/ ) because we really want to avoid false positives. Just wondering if anyone has any words of caution ("False positives! Avoid FULLBOGONS and Spamhaus!"), or words of praise ("Do it all! These services are wonderful!") before we take the plunge. Thanks, Adam From mpetach at netflight.com Fri Jun 27 17:12:12 2014 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 27 Jun 2014 10:12:12 -0700 Subject: Advice on BGP + uCARP setup on 2 Debian Gateways In-Reply-To: References: Message-ID: On Fri, Jun 27, 2014 at 2:42 AM, Toney Mareo wrote: > > Hi Toney, I think something must have gone wrong with your email; all the fine advice you had intended to pass along didn't seem to make it through intact; all we got was an empty message body, and no advice. Thanks! Matt From cscora at apnic.net Fri Jun 27 18:11:21 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Jun 2014 04:11:21 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201406271811.s5RIBLSp014367@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, LacNOG, TRNOG, 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 28 Jun, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 502028 Prefixes after maximum aggregation: 195358 Deaggregation factor: 2.57 Unique aggregates announced to Internet: 247111 Total ASes present in the Internet Routing Table: 47136 Prefixes per ASN: 10.65 Origin-only ASes present in the Internet Routing Table: 35929 Origin ASes announcing only one prefix: 16325 Transit ASes present in the Internet Routing Table: 6101 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1747 Unregistered ASNs in the Routing Table: 451 Number of 32-bit ASNs allocated by the RIRs: 6913 Number of 32-bit ASNs visible in the Routing Table: 5106 Prefixes from 32-bit ASNs in the Routing Table: 17810 Number of bogon 32-bit ASNs visible in the Routing Table: 297 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 373 Number of addresses announced to Internet: 2704306724 Equivalent to 161 /8s, 48 /16s and 114 /24s Percentage of available address space announced: 73.0 Percentage of allocated address space announced: 73.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.6 Total number of prefixes smaller than registry allocations: 173672 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 120759 Total APNIC prefixes after maximum aggregation: 35496 APNIC Deaggregation factor: 3.40 Prefixes being announced from the APNIC address blocks: 123969 Unique aggregates announced from the APNIC address blocks: 51572 APNIC Region origin ASes present in the Internet Routing Table: 4959 APNIC Prefixes per ASN: 25.00 APNIC Region origin ASes announcing only one prefix: 1228 APNIC Region transit ASes present in the Internet Routing Table: 876 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 995 Number of APNIC addresses announced to Internet: 734127232 Equivalent to 43 /8s, 193 /16s and 228 /24s Percentage of available APNIC address space announced: 85.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-63999, 131072-133631 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: 169157 Total ARIN prefixes after maximum aggregation: 84089 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 170870 Unique aggregates announced from the ARIN address blocks: 79753 ARIN Region origin ASes present in the Internet Routing Table: 16319 ARIN Prefixes per ASN: 10.47 ARIN Region origin ASes announcing only one prefix: 6118 ARIN Region transit ASes present in the Internet Routing Table: 1679 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 31 Number of ARIN region 32-bit ASNs visible in the Routing Table: 124 Number of ARIN addresses announced to Internet: 1087721248 Equivalent to 64 /8s, 213 /16s and 79 /24s Percentage of available ARIN address space announced: 57.5 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, 393216-394239 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: 124271 Total RIPE prefixes after maximum aggregation: 62864 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 128967 Unique aggregates announced from the RIPE address blocks: 81634 RIPE Region origin ASes present in the Internet Routing Table: 17717 RIPE Prefixes per ASN: 7.28 RIPE Region origin ASes announcing only one prefix: 8250 RIPE Region transit ASes present in the Internet Routing Table: 2879 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2719 Number of RIPE addresses announced to Internet: 658397060 Equivalent to 39 /8s, 62 /16s and 87 /24s Percentage of available RIPE address space announced: 95.7 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-202239 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: 57861 Total LACNIC prefixes after maximum aggregation: 10203 LACNIC Deaggregation factor: 5.67 Prefixes being announced from the LACNIC address blocks: 65068 Unique aggregates announced from the LACNIC address blocks: 29431 LACNIC Region origin ASes present in the Internet Routing Table: 2118 LACNIC Prefixes per ASN: 30.72 LACNIC Region origin ASes announcing only one prefix: 524 LACNIC Region transit ASes present in the Internet Routing Table: 441 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1231 Number of LACNIC addresses announced to Internet: 166119936 Equivalent to 9 /8s, 230 /16s and 202 /24s Percentage of available LACNIC address space announced: 99.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 12064 Total AfriNIC prefixes after maximum aggregation: 2669 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 12781 Unique aggregates announced from the AfriNIC address blocks: 4391 AfriNIC Region origin ASes present in the Internet Routing Table: 723 AfriNIC Prefixes per ASN: 17.68 AfriNIC Region origin ASes announcing only one prefix: 205 AfriNIC Region transit ASes present in the Internet Routing Table: 152 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 37 Number of AfriNIC addresses announced to Internet: 57593856 Equivalent to 3 /8s, 110 /16s and 208 /24s Percentage of available AfriNIC address space announced: 57.2 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 2932 11591 922 Korea Telecom 17974 2780 899 72 PT Telekomunikasi Indonesia 7545 2232 320 118 TPG Telecom Limited 4755 1866 396 200 TATA Communications formerly 9829 1649 1307 32 National Internet Backbone 9583 1313 103 537 Sify Limited 9498 1273 314 88 BHARTI Airtel Ltd. 7552 1242 1098 14 Viettel Corporation 4808 1215 2152 366 CNCGROUP IP network China169 24560 1160 398 188 Bharti Airtel Ltd., Telemedia 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 6389 2953 3688 53 BellSouth.net Inc. 22773 2563 2938 135 Cox Communications Inc. 7029 2223 1905 303 Windstream Communications Inc 18566 2047 379 178 MegaPath Corporation 20115 1715 1702 569 Charter Communications 4323 1639 1074 418 tw telecom holdings, inc. 30036 1484 323 572 Mediacom Communications Corp 701 1443 11187 730 MCI Communications Services, 6983 1379 818 313 ITC^Deltacom 22561 1308 402 233 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 34984 1710 264 274 TELLCOM ILETISIM HIZMETLERI A 20940 1416 550 1051 Akamai International B.V. 8402 1384 544 15 OJSC "Vimpelcom" 31148 1042 45 20 Freenet Ltd. 13188 1031 100 28 TOV "Bank-Inform" 8551 956 370 41 Bezeq International-Ltd 6849 818 356 26 JSC "Ukrtelecom" 6830 771 2335 429 Liberty Global Operations B.V 12479 732 795 57 France Telecom Espana SA 9198 579 344 28 JSC Kazakhtelecom 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 28573 3763 2022 101 NET Servi�os de Comunica��o S 10620 2900 469 202 Telmex Colombia S.A. 18881 2059 1036 22 Global Village Telecom 7303 1769 1179 231 Telecom Argentina S.A. 8151 1443 2975 419 Uninet S.A. de C.V. 6503 1130 434 61 Axtel, S.A.B. de C.V. 7738 979 1882 41 Telemar Norte Leste S.A. 6147 929 373 27 Telefonica del Peru S.A.A. 27947 894 130 51 Telconet S.A 26615 869 2325 35 Tim Celular S.A. 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 36998 1114 240 6 Sudanese Mobile Telephone (ZA 24863 939 280 26 Link Egypt (Link.NET) 6713 668 742 41 Office National des Postes et 8452 585 958 13 TE-AS 24835 306 144 9 Vodafone Data 36992 300 783 24 ETISALAT MISR 3741 250 921 213 Internet Solutions 37054 243 19 6 Data Telecom Service 29571 227 22 17 Cote d'Ivoire Telecom 15706 187 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 28573 3763 2022 101 NET Servi�os de Comunica��o S 6389 2953 3688 53 BellSouth.net Inc. 4766 2932 11591 922 Korea Telecom 10620 2900 469 202 Telmex Colombia S.A. 17974 2780 899 72 PT Telekomunikasi Indonesia 22773 2563 2938 135 Cox Communications Inc. 7545 2232 320 118 TPG Telecom Limited 7029 2223 1905 303 Windstream Communications Inc 18881 2059 1036 22 Global Village Telecom 18566 2047 379 178 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 6389 2953 2900 BellSouth.net Inc. 17974 2780 2708 PT Telekomunikasi Indonesia 10620 2900 2698 Telmex Colombia S.A. 22773 2563 2428 Cox Communications Inc. 7545 2232 2114 TPG Telecom Limited 18881 2059 2037 Global Village Telecom 4766 2932 2010 Korea Telecom 7029 2223 1920 Windstream Communications Inc 18566 2047 1869 MegaPath Corporation 4755 1866 1666 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 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 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.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:30 /11:91 /12:258 /13:487 /14:980 /15:1705 /16:12999 /17:6957 /18:11701 /19:24652 /20:34964 /21:37252 /22:53685 /23:47081 /24:266970 /25:821 /26:913 /27:397 /28:13 /29:19 /30:10 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 22773 1811 2563 Cox Communications Inc. 6389 1694 2953 BellSouth.net Inc. 30036 1320 1484 Mediacom Communications Corp 11492 1191 1242 CABLE ONE, INC. 7029 1121 2223 Windstream Communications Inc 6983 1086 1379 ITC^Deltacom 36998 1080 1114 Sudanese Mobile Telephone (ZA 8402 1068 1384 OJSC "Vimpelcom" 34984 1039 1710 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1158 2:673 3:3 4:15 5:974 6:19 8:714 12:1829 13:4 14:1056 15:14 16:2 17:37 18:21 20:36 23:935 24:1755 27:1760 31:1484 32:43 33:2 34:5 36:136 37:1821 38:974 39:7 40:204 41:3213 42:258 43:84 44:12 45:29 46:2110 47:24 49:729 50:938 52:12 54:47 55:5 56:2 57:29 58:1219 59:608 60:399 61:1573 62:1255 63:1889 64:4383 65:2291 66:4169 67:2079 68:1064 69:3360 70:867 71:441 72:2026 74:2635 75:319 76:407 77:1690 78:849 79:700 80:1309 81:1205 82:759 83:757 84:754 85:1298 86:434 87:1175 88:452 89:1800 90:140 91:5709 92:710 93:1761 94:2071 95:1580 96:530 97:358 98:1089 99:49 100:63 101:847 103:5146 104:39 105:543 106:175 107:629 108:582 109:2023 110:983 111:1364 112:677 113:854 114:895 115:1136 116:1098 117:951 118:1475 119:1403 120:417 121:830 122:2118 123:1333 124:1434 125:1519 128:585 129:339 130:349 131:667 132:418 133:163 134:320 135:74 136:277 137:285 138:363 139:166 140:216 141:386 142:569 143:411 144:505 145:102 146:639 147:481 148:911 149:369 150:198 151:713 152:444 153:220 154:311 155:511 156:353 157:337 158:250 159:912 160:328 161:558 162:1570 163:263 164:696 165:620 166:284 167:631 168:1062 169:125 170:1443 171:190 172:33 173:1608 174:710 175:601 176:1404 177:3262 178:2056 179:720 180:1764 181:1251 182:1564 183:527 184:729 185:1793 186:2877 187:1643 188:2129 189:1508 190:7546 191:405 192:7378 193:5514 194:4030 195:3519 196:1418 197:667 198:5098 199:5527 200:6286 201:2630 202:9094 203:8954 204:4602 205:2671 206:2968 207:2986 208:3983 209:3739 210:3128 211:1730 212:2307 213:2081 214:872 215:87 216:5598 217:1694 218:610 219:330 220:1285 221:629 222:354 223:587 End of report From IT at SysAccess.net Fri Jun 27 19:55:37 2014 From: IT at SysAccess.net (SysIT) Date: Fri, 27 Jun 2014 19:55:37 +0000 Subject: Team Cymru / Spamhaus In-Reply-To: <74825E6950ECDE449817715200CEAD2703BA327F6D@BRTEXMB76.phillips66.net> References: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> <8ae484ef995249688559b8ca999e84c6@Email-02.true.local> <74825E6950ECDE449817715200CEAD2703BA327F6D@BRTEXMB76.phillips66.net> Message-ID: <5afa899e963d4f36b569de98f2263f2d@Email-02.true.local> Appreciate the Clarification Darden, I wasn't aware Spamhaus had this other division / service, time for some reading. -----Original Message----- From: Darden, Patrick [mailto:Patrick.Darden at p66.com] Sent: Friday, June 27, 2014 11:50 AM To: SysIT; Adam Greene; 'NANOG list' Subject: RE: Team Cymru / Spamhaus I feel like you are conflating DOS and DDOS. DOS attacks can be bandwidth related, but they can also be malformed packets, injections, etc. ad nauseum. DDOS are almost always, as you say, bandwidth wars. The Spamhaus BGPF project has nothing to do with Spam--it is an attempt to provide filters for botnets and other malware hosts/nets, including DDOS and some DOS attacks. However, it will only work if you use it--with the chance for false positives implicitly there. The CYMRU FULLBOGON list won't help with DOS or DDOS--it is simply a list of martians, netbloks, and allocated but unassigned IP space. Well worth using, and a fabulous resource. --patrick darden -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of SysIT Sent: Friday, June 27, 2014 10:23 AM To: Adam Greene; 'NANOG list' Subject: [EXTERNAL]RE: Team Cymru / Spamhaus That wont stop a DoS. A DoS or DDoS is pure bandwidth wars for the most part, if someone is to DoS you, they already have your IP's and urls they need to attack you, thus a spam list won't stop an attack. If you want to minimize actual spam, sure. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Adam Greene Sent: Friday, June 27, 2014 9:18 AM To: 'NANOG list' Subject: Team Cymru / Spamhaus Hi all, We're evaluating whether to add BGP feeds from these two sources in attempt to minimize exposure to DoS. The Team Cymru BOGON list ( http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt or http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt ) looks promising and common-sense. We already filter RFC1918 inbound at our edge, and are interested to see if adding the rest of the blocks will have a significant positive effect. If it does, we're planning to try the IPv4 FULLBOGON list: http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt We're a little more leery about trying Spamhaus's BGPf service (DROP, EDROP and BCL, http://www.spamhaus.org/bgpf/ ) because we really want to avoid false positives. Just wondering if anyone has any words of caution ("False positives! Avoid FULLBOGONS and Spamhaus!"), or words of praise ("Do it all! These services are wonderful!") before we take the plunge. Thanks, Adam From jlewis at lewis.org Fri Jun 27 20:40:12 2014 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 27 Jun 2014 16:40:12 -0400 (EDT) Subject: Team Cymru / Spamhaus In-Reply-To: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> References: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> Message-ID: On Fri, 27 Jun 2014, Adam Greene wrote: > We're evaluating whether to add BGP feeds from these two sources in attempt > to minimize exposure to DoS. > > The Team Cymru BOGON list ( > > http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt or > > http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt These really won't do anything to stop DoS attacks. Common DDoS attack traffic these days comes via reflection from non-spoofed sources replying to a spoofed public IP target. > http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt Same here. Whether or not its worth null routing unallocated IP space may be debatable, but again, it't not going to help protect you from a typical real DDoS. > We're a little more leery about trying Spamhaus's BGPf service (DROP, EDROP > and BCL, > > http://www.spamhaus.org/bgpf/ This is more about stopping spam from entering your network and stopping compromised hosts on your network from becoming active in botnets (by cutting off their command and control). ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From matthias at leisi.net Fri Jun 27 21:04:51 2014 From: matthias at leisi.net (Matthias Leisi) Date: Fri, 27 Jun 2014 23:04:51 +0200 Subject: Team Cymru / Spamhaus In-Reply-To: References: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> Message-ID: On Fri, Jun 27, 2014 at 10:40 PM, Jon Lewis wrote: >> We're a little more leery about trying Spamhaus's BGPf service (DROP, >> EDROP >> and BCL, >> >> http://www.spamhaus.org/bgpf/ > > > This is more about stopping spam from entering your network and stopping > compromised hosts on your network from becoming active in botnets (by > cutting off their command and control). Not quite. DROP (Don't Route Or Peer) and EDROP are advisory "drop all traffic" lists, consisting of netblocks that are "hijacked" or leased by professional spam or cyber-crime operations (used for dissemination of malware, trojan downloaders, botnet controllers). The DROP and EDROP lists are a tiny subset of the SBL, designed for use by firewalls and routing equipment to filter out the malicious traffic from these netblocks. (Source: http://www.spamhaus.org/drop/, linked from the URL quoted above) -- Matthias From cidr-report at potaroo.net Fri Jun 27 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Jun 2014 22:00:01 GMT Subject: The Cidr Report Message-ID: <201406272200.s5RM01a9012968@wattle.apnic.net> This report has been generated at Fri Jun 27 21:13:58 2014 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 20-06-14 506090 284724 21-06-14 506214 283061 22-06-14 506127 283549 23-06-14 506459 283530 24-06-14 506587 283558 25-06-14 506286 283994 26-06-14 507682 284200 27-06-14 507790 284343 AS Summary 47478 Number of ASes in routing system 19245 Number of ASes announcing only one prefix 3752 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120370688 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'). --- 27Jun14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 508112 284386 223726 44.0% All ASes AS28573 3752 185 3567 95.1% NET Servi�os de Comunica��o S.A.,BR AS6389 2951 80 2871 97.3% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2780 179 2601 93.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2558 379 2179 85.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS18881 2062 39 2023 98.1% Global Village Telecom,BR AS4766 2932 931 2001 68.2% KIXS-AS-KR Korea Telecom,KR AS7029 2329 445 1884 80.9% WINDSTREAM - Windstream Communications Inc,US AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS10620 2900 1471 1429 49.3% Telmex Colombia S.A.,CO AS7303 1774 435 1339 75.5% Telecom Argentina S.A.,AR AS7545 2315 999 1316 56.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS4755 1867 585 1282 68.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4323 1653 434 1219 73.7% TWTC - tw telecom holdings, inc.,US AS7552 1269 166 1103 86.9% VIETEL-AS-AP Viettel Corporation,VN AS36998 1114 37 1077 96.7% SDN-MOBITEL,SD AS22561 1308 242 1066 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1379 314 1065 77.2% ITCDELTA - Earthlink, Inc.,US AS9808 1059 175 884 83.5% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS4788 1033 155 878 85.0% TMNET-AS-AP TM Net, Internet Service Provider,MY AS24560 1163 334 829 71.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS9829 1649 836 813 49.3% BSNL-NIB National Internet Backbone,IN AS4808 1215 411 804 66.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS6147 929 140 789 84.9% Telefonica del Peru S.A.A.,PE AS7738 979 215 764 78.0% Telemar Norte Leste S.A.,BR AS8151 1451 693 758 52.2% Uninet S.A. de C.V.,MX AS18101 941 185 756 80.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS26615 869 115 754 86.8% Tim Celular S.A.,BR AS11492 1242 497 745 60.0% CABLEONE - CABLE ONE, INC.,US AS855 772 58 714 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS701 1444 731 713 49.4% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US Total 51736 12031 39705 76.7% Top 30 total Possible Bogus Routes 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.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.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -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 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.253.224.0/19 AS20428 -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 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 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 69.57.64.0/20 AS20428 -Reserved AS-,ZZ 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.115.124.0/23 AS46540 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 74.120.214.0/23 AS32326 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -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.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.140.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.141.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.142.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.143.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.92.0/22 AS13269 103.18.92.0/24 AS13269 103.18.94.0/24 AS13269 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.223.25.0/24 AS13296 OCEANEXPORTS-AS OCEAN EXPORTS,IN 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 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 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 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.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,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.104.61.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,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.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,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 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 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.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 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.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 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.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 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.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT 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 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 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.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 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.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech 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.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.146.36.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 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.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 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 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 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 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 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.192.0/20 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.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 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.116.200.0/21 AS22830 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 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 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 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 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 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.9.24.0/22 AS27425 ASN-IDK-27425 - IdeaTek,US 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,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.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 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 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 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.128.0/24 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.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 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 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.93.144.0/21 AS30693 SERVERHUB-PHOENIX - Eonix Corporation,US 209.90.192.0/19 AS20428 -Reserved AS-,ZZ 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.157.160.0/19 AS20428 -Reserved AS-,ZZ 216.157.172.0/24 AS20428 -Reserved AS-,ZZ 216.157.173.0/24 AS20428 -Reserved AS-,ZZ 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 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 Jun 27 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Jun 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201406272200.s5RM02qG012984@wattle.apnic.net> BGP Update Report Interval: 19-Jun-14 -to- 26-Jun-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26615 106096 3.8% 122.7 -- Tim Celular S.A.,BR 2 - AS9829 86844 3.1% 67.3 -- BSNL-NIB National Internet Backbone,IN 3 - AS54113 43173 1.6% 1233.5 -- FASTLY - Fastly,US 4 - AS8402 36253 1.3% 32.9 -- CORBINA-AS OJSC "Vimpelcom",RU 5 - AS7029 23709 0.8% 6.8 -- WINDSTREAM - Windstream Communications Inc,US 6 - AS28573 23036 0.8% 5.5 -- NET Servi�os de Comunica��o S.A.,BR 7 - AS11340 22821 0.8% 207.5 -- Red Universitaria Nacional,CL 8 - AS13188 22321 0.8% 36.8 -- BANKINFORM-AS TOV "Bank-Inform",UA 9 - AS23693 20596 0.7% 162.2 -- TELKOMSEL-ASN-ID PT. Telekomunikasi Selular,ID 10 - AS17974 20204 0.7% 7.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 11 - AS23752 19234 0.7% 164.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 12 - AS3816 18920 0.7% 22.5 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 13 - AS14287 18677 0.7% 345.9 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 14 - AS41691 16701 0.6% 695.9 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 15 - AS18403 15803 0.6% 26.9 -- FPT-AS-AP The Corporation for Financing & Promoting Technology,VN 16 - AS4775 15395 0.6% 127.2 -- GLOBE-TELECOM-AS Globe Telecoms,PH 17 - AS647 15321 0.6% 123.6 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US 18 - AS45899 12577 0.5% 39.3 -- VNPT-AS-VN VNPT Corp,VN 19 - AS25184 12404 0.4% 95.4 -- AFRANET AFRANET Co. Tehran, Iran,IR 20 - AS13489 11150 0.4% 24.2 -- EPM Telecomunicaciones S.A. E.S.P.,CO TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26661 8230 0.3% 2057.5 -- JCPS-ASN - Jeffco Public Schools,US 2 - AS16118 2961 0.1% 1480.5 -- NNT-MOSCOW-AS Thyphone Communications LLC,RU 3 - AS24311 1447 0.1% 1447.0 -- CNGI-CMNETV6-AS-AP China Mobile Communications Corporation IPv6 network,CN 4 - AS54465 7230 0.3% 1446.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 5 - AS54113 43173 1.6% 1233.5 -- FASTLY - Fastly,US 6 - AS45590 801 0.0% 801.0 -- HGCINTNET-AS-AP Hutch Connect,HK 7 - AS35678 1545 0.1% 772.5 -- TYPOCONSULT Tabulex ApS,DK 8 - AS41691 16701 0.6% 695.9 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 9 - AS58228 1348 0.1% 674.0 -- IT-TELECOM-AS LLC "IT Telecom",RU 10 - AS53116 3259 0.1% 651.8 -- Inform�tica de Munic�pios Associados S/A - IMA,BR 11 - AS3 1926 0.1% 1709.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 12 - AS32413 1140 0.0% 570.0 -- AEPRIO - Aeprio.com, LLC,US 13 - AS24814 4611 0.2% 512.3 -- SCS-AS Syrian Computer Society, scs,SY 14 - AS37373 504 0.0% 504.0 -- AUC-ASN,GH 15 - AS6629 8552 0.3% 503.1 -- NOAA-AS - NOAA,US 16 - AS35093 1457 0.1% 485.7 -- RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 17 - AS14124 391 0.0% 391.0 -- GEEKWERX-NETWORK - GeekWerx LLC,US 18 - AS27913 376 0.0% 376.0 -- Internet Systems Consortium,UY 19 - AS12654 4400 0.2% 366.7 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC),EU 20 - AS37447 1453 0.1% 363.2 -- OASIS-SPRL,CD TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 15863 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 23.235.39.0/24 15353 0.5% AS54113 -- FASTLY - Fastly,US 3 - 23.235.34.0/24 14852 0.5% AS54113 -- FASTLY - Fastly,US 4 - 23.235.38.0/24 12893 0.4% AS54113 -- FASTLY - Fastly,US 5 - 202.70.88.0/21 9404 0.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 6 - 202.70.64.0/21 9194 0.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 7 - 78.109.192.0/20 9064 0.3% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 8 - 192.58.232.0/24 8469 0.3% AS6629 -- NOAA-AS - NOAA,US 9 - 120.28.62.0/24 7795 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 10 - 205.247.12.0/24 7561 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 11 - 206.152.15.0/24 7226 0.2% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 12 - 222.127.0.0/24 7163 0.2% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 13 - 42.83.48.0/20 6149 0.2% AS18135 -- BTV BTV Cable television,JP 14 - 46.53.64.0/19 5236 0.2% AS24814 -- SCS-AS Syrian Computer Society, scs,SY AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY 15 - 203.135.159.0/24 4540 0.2% AS23881 -- UDOMAIN-AS-AP UDomain Web Hosting Company Ltd,HK 16 - 177.54.145.0/24 4168 0.1% AS4 -- ISI-AS - University of Southern California,US 17 - 204.245.102.0/24 4072 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 18 - 208.73.244.0/22 3742 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 19 - 208.78.116.0/22 3735 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 20 - 216.162.0.0/20 3725 0.1% AS14287 -- TRIAD-TELECOM - Triad Telecom, 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 LarrySheldon at cox.net Fri Jun 27 22:35:58 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 27 Jun 2014 17:35:58 -0500 Subject: Advice on BGP + uCARP setup on 2 Debian Gateways In-Reply-To: References: Message-ID: <53ADF1CE.8000302@cox.net> On 6/27/2014 4:42 AM, Toney Mareo wrote: > Fascinating. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From contact at winterei.se Sat Jun 28 02:25:09 2014 From: contact at winterei.se (Paul S.) Date: Sat, 28 Jun 2014 11:25:09 +0900 Subject: Team Cymru / Spamhaus In-Reply-To: References: <01c301cf921a$f1d61d60$d5825820$@webjogger.net> Message-ID: <53AE2785.9050204@winterei.se> +1, blanket banning is probably not the best way to go. On 6/28/2014 午前 05:40, Jon Lewis wrote: > On Fri, 27 Jun 2014, Adam Greene wrote: > >> We're evaluating whether to add BGP feeds from these two sources in >> attempt >> to minimize exposure to DoS. >> >> The Team Cymru BOGON list ( >> >> http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt or >> >> http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt > > These really won't do anything to stop DoS attacks. Common DDoS attack > traffic these days comes via reflection from non-spoofed sources > replying to a spoofed public IP target. > >> http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt > > Same here. Whether or not its worth null routing unallocated IP space > may be debatable, but again, it't not going to help protect you from a > typical real DDoS. > >> We're a little more leery about trying Spamhaus's BGPf service (DROP, >> EDROP >> and BCL, >> >> http://www.spamhaus.org/bgpf/ > > This is more about stopping spam from entering your network and > stopping compromised hosts on your network from becoming active in > botnets (by cutting off their command and control). > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From universe at truemetal.org Sat Jun 28 14:32:15 2014 From: universe at truemetal.org (Markus) Date: Sat, 28 Jun 2014 16:32:15 +0200 Subject: Next steps in extortion case - ideas? Message-ID: <53AED1EF.30702@truemetal.org> Hi list, nothing operational here, but there are many smart minds on this list and people working for telcos, ISPs and law enforcement agencies, so maybe you are willing to give me some advice in the following case: There's an individual out there on the web that has been blackmailing hundreds of people and companies in a specific area of business for years. His scheme is: 1. Contact the alleged "debtor" via e-mail and inform him about an existing debt claim by a third party. 2. Offer the debtor a deadline to pay the debt and warn the debtor if he shouldn't pay he'll be prosecuted and his case will be "made public". 3. Once the deadline has elapsed, he'll publish completely false information made out of thin air on the web, in particular Facebook, Twitter, a blog, a website, including pictures of the debtor and serious accusations like "This debtor is a child molestor" or "This debtor is part of the mafia" and other crazy stuff that you can usually only see in movies. All of course with real names, company information (if applicable) and basically everything he can find out about the debtor. 4. Then, the individual hopes that the debtor will be intimidated because the debtor is afraid of the false information about him, which will show up on Google etc., and will finally pay to get this false information removed from the web. In all cases the published "background information" about the debtors is false, made out of thin air, and over the top. Just the names and pictures are correct. Intentional slander in order to get the debtor to pay. If any of the published information was true, then every 2nd debtor would be a child molestor and every other debtor part of the mafia. That individual is hiding his real identity really well, obviously, and he knows what he's doing. Domain hosted in Russia, taking good care his IP address won't show up in the mail headers, using false names and identities, phone numbers registered through some DID provider who doesn't collect personal information about the DID owner etc. I am one of the accused and had lots of false information about myself and my company published by him. This is why I started to have an interest to track his real identity down. I took 2 days out of my life and researched high and low and finally found his personal phone number along with a name, a picture of him and several possible addresses (in the US). I cannot be sure that the name, picture and addresses are correct, but I called him on his personal phone number and after having spoken with him before under his false identity, I can confirm that it's the same person (the voice is the same). He was quite surprised to say the least. In case it matters, according to a LRN lookup the number belongs to Omnipoint Communications, which is part of T-Mobile USA, I think. My idea is to somehow confirm his identity and confirm my research by matching the voice of the false identity (available from a message he left on my voicemail and also from his voicemail intro) to the real person. I'm thinking about hiring a private investigator in the US (I'm in Germany) to drive up to the addresses I can provide the PI with and find the person that matches the voice / maybe even the picture. The PI then must document the outcome in a way that it can be used in court. I'm wanting to go the PI route because it will be the fastest way to possibly gather evidence, I assume, as opposed to commissioning a lawyer who will then in turn contact law enforcement etc. Unfortunately I do not have the authority to access the personal data of the person that pays the monthly bill for the phone number that I called him on, otherwise that would be the fastest way I suppose. I spent money for some pay-sites that do some reverse phone lookup and stuff like that, and although the information was helpful, I cannot be sure that it's accurate. My goal is to confirm his real identity/name and address in order to start a lawsuit and have a lawyer, or maybe even law enforcement, investigate this case and ultimately, put an end to his slander activities, not just for my case but for all hundreds before me and those which are to come in the future. Do you think the PI route makes sense? Any other recommendations? Your feedback in general? Thanks and sorry for so much text. :) Markus From rdobbins at arbor.net Sat Jun 28 15:34:33 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 28 Jun 2014 22:34:33 +0700 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AED1EF.30702@truemetal.org> References: <53AED1EF.30702@truemetal.org> Message-ID: On Jun 28, 2014, at 9:32 PM, Markus wrote: > Any other recommendations? Law enforcement. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From streiner at cluebyfour.org Sat Jun 28 13:05:46 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 28 Jun 2014 09:05:46 -0400 (EDT) Subject: Next steps in extortion case - ideas? In-Reply-To: <53AED1EF.30702@truemetal.org> References: <53AED1EF.30702@truemetal.org> Message-ID: On Sat, 28 Jun 2014, Markus wrote: > nothing operational here, but there are many smart minds on this list and > people working for telcos, ISPs and law enforcement agencies, so maybe you > are willing to give me some advice in the following case: > > That individual is hiding his real identity really well, obviously, and he > knows what he's doing. Domain hosted in Russia, taking good care his IP > address won't show up in the mail headers, using false names and identities, > phone numbers registered through some DID provider who doesn't collect > personal information about the DID owner etc. Fair warning: I am not a lawyer, and not an expert in the intricacies of international law. You would be well-advised to seek counsel from a lawyer who specializes in this area. Have you contacted your local police, or the German equivalent (the BKA?) of the United States' FBI? Law enforcement agencies are going to have (or can get through court order) the legal authority to get the information you're after, and if the information is deemed credible and the offense serious enough, charges can be brought against the individual. Most likely the US FBI would get involved after being contacted by their counterparts in Germany, since international crime generally falls under federal jurisdiction in the US. My personal opinion is that having a PI go to the individual's house would not accomplish more than 'tipping your hand' to that person - letting them know that you've committed resources to tracking them down. jms From rob at invaluement.com Sat Jun 28 17:44:17 2014 From: rob at invaluement.com (Rob McEwen) Date: Sat, 28 Jun 2014 13:44:17 -0400 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AED1EF.30702@truemetal.org> References: <53AED1EF.30702@truemetal.org> Message-ID: <53AEFEF1.50502@invaluement.com> On 6/28/2014 10:32 AM, Markus wrote: > There's an individual out there on the web that has been blackmailing > hundreds of people and companies in a specific area of business for years. You mentioned that this person resides in the US. Does he always target people outside the US? (from what you know about him) -- Rob McEwen +1 (478) 475-9032 From universe at truemetal.org Sat Jun 28 17:48:01 2014 From: universe at truemetal.org (Markus) Date: Sat, 28 Jun 2014 19:48:01 +0200 Subject: Next steps in extortion case - ideas? In-Reply-To: References: <53AED1EF.30702@truemetal.org> Message-ID: <53AEFFD1.7040708@truemetal.org> Am 28.06.2014 15:05, schrieb Justin M. Streiner: > Have you contacted your local police, or the German equivalent (the > BKA?) of the United States' FBI? > [...] > My personal opinion is that having a PI go to the individual's house > would not accomplish more than 'tipping your hand' to that person - > letting them know that you've committed resources to tracking them down. I haven't contacted any law enforcement agency yet, because I'm not yet certain which one(s), where, and whether it's a good move at this point. According to my experience, German police is too slow, even if it's just passing on the case to the next "higher" agency. Somehow I think it would be most effective to have several investigations, that I start by myself, in parallel. E.g. in Russia -> collect the data of the person who's paying for the domain/hosting, so I guess I need a lawyer in Russia to contact sledcom.ru (the Russian equivalent of the FBI, I think), who in turn hopefully will make the Russian hosting provider provide that data. At the same time, a lawyer in the US to do the same for the phone number. In parallel, the same for the US hosting providers that were used in the past by that individual. But, before I can do all that, won't I need sufficient proof? What I have at this point is a phone number, but I cannot be sure that the connected name and addresses, which I found solely based on web research, is accurate, and even if they were, that's no evidence for anything. This is why I came up with the PI idea, which I didn't explain properly enough. I didn't mean the PI to knock at some doors and say "Hello there, Markus from Germany sends me, are you ?" - hehe. :) I meant that the PI should perform surveillance and observe who's arriving and leaving, and if a person matches the picture I provided or maybe ethnicity/age, walk up to him and ask for the way to the bus stop or something, in order to check whether his voice matches. If it does, and if the PI can document this in a way that can be used in court, I have an address and a name I can use to pass to lawyers/law enforcement. When I write all this I always have in mind that law enforcement research is slow. Talking about Germany now, don't know about the US. Especially in a case like this where no life is in danger or where there's no other immediate threat. This is why I'm thinking: I better do/initiate as much research as I can by myself. Once I've collected everything I can from all kinds of sources I'll throw the whole bunch of documents to a lawyer/LE in the US. Doesn't make sense? Wrong thinking? Thanks! Markus From universe at truemetal.org Sat Jun 28 17:52:37 2014 From: universe at truemetal.org (Markus) Date: Sat, 28 Jun 2014 19:52:37 +0200 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AEFEF1.50502@invaluement.com> References: <53AED1EF.30702@truemetal.org> <53AEFEF1.50502@invaluement.com> Message-ID: <53AF00E5.9010405@truemetal.org> Am 28.06.2014 19:44, schrieb Rob McEwen: > You mentioned that this person resides in the US. Does he always target > people outside the US? (from what you know about him) No, he targets individuals and companies all over the world in this particular area of business. And that's another good aspect. Because my goal is to shut down his activities as a whole, and not simply remove the blog posts about myself. The blog is hosted at blogspot (Google), and I see that they every now and then remove single posts after someone complained for long enough, but I guess the blog as a whole falls under some kind of freedom of information thing, so Google won't shut it down. And even if they would, he'd simply switch to another blog provider. Regards Markus From universe at truemetal.org Sat Jun 28 17:57:44 2014 From: universe at truemetal.org (Markus) Date: Sat, 28 Jun 2014 19:57:44 +0200 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AF00E5.9010405@truemetal.org> References: <53AED1EF.30702@truemetal.org> <53AEFEF1.50502@invaluement.com> <53AF00E5.9010405@truemetal.org> Message-ID: <53AF0218.7090707@truemetal.org> Am 28.06.2014 19:52, schrieb Markus: > Am 28.06.2014 19:44, schrieb Rob McEwen: >> You mentioned that this person resides in the US. Does he always target >> people outside the US? (from what you know about him) > > No, he targets individuals and companies all over the world in this > particular area of business. Sorry, maybe that line wasn't clear. What I meant is: he targets anyone, everywhere, including individuals and businesses in the US. From mpetach at netflight.com Sat Jun 28 18:25:53 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 28 Jun 2014 11:25:53 -0700 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AEFFD1.7040708@truemetal.org> References: <53AED1EF.30702@truemetal.org> <53AEFFD1.7040708@truemetal.org> Message-ID: On Sat, Jun 28, 2014 at 10:48 AM, Markus wrote: > Am 28.06.2014 15:05, schrieb Justin M. Streiner: > > Have you contacted your local police, or the German equivalent (the >> BKA?) of the United States' FBI? >> > > [...] > > My personal opinion is that having a PI go to the individual's house >> would not accomplish more than 'tipping your hand' to that person - >> letting them know that you've committed resources to tracking them down. >> > > I haven't contacted any law enforcement agency yet, because I'm not yet > certain which one(s), where, and whether it's a good move at this point. > According to my experience, German police is too slow, even if it's just > passing on the case to the next "higher" agency. Somehow I think it would > be most effective to have several investigations, that I start by myself, > in parallel. E.g. in Russia -> collect the data of the person who's paying > for the domain/hosting, so I guess I need a lawyer in Russia to contact > sledcom.ru (the Russian equivalent of the FBI, I think), who in turn > hopefully will make the Russian hosting provider provide that data. At the > same time, a lawyer in the US to do the same for the phone number. In > parallel, the same for the US hosting providers that were used in the past > by that individual. > > But, before I can do all that, won't I need sufficient proof? If you've been a victim of extortion, the simple existence of the threat and demand for payment is proof enough for law enforcement to start an investigation. More information can sometimes be helpful, but you run a risk of tainting evidence if you go too far on your own, which may end up hurting the case in the long term. If you obtain proof through illegal or questionable means, it generally can't be used as part of the case against them. > > What I have at this point is a phone number, but I cannot be sure that the > connected name and addresses, which I found solely based on web research, > is accurate, and even if they were, that's no evidence for anything. This > is why I came up with the PI idea, which I didn't explain properly enough. > I didn't mean the PI to knock at some doors and say "Hello there, Markus > from Germany sends me, are you ?" - hehe. :) I meant that the PI > should perform surveillance and observe who's arriving and leaving, and if > a person matches the picture I provided or maybe ethnicity/age, walk up to > him and ask for the way to the bus stop or something, in order to check > whether his voice matches. If it does, and if the PI can document this in a > way that can be used in court, I have an address and a name I can use to > pass to lawyers/law enforcement. > > When I write all this I always have in mind that law enforcement research > is slow. Talking about Germany now, don't know about the US. Especially in > a case like this where no life is in danger or where there's no other > immediate threat. This is why I'm thinking: I better do/initiate as much > research as I can by myself. Once I've collected everything I can from all > kinds of sources I'll throw the whole bunch of documents to a lawyer/LE in > the US. > > Doesn't make sense? Wrong thinking? > > Thanks! > Markus > > It depends on your goal. If your goal is to get this person off your back quickly, yes, law enforcement can often seem slow. But taking action on your own could end up thwarting the longer-term goal of making sure this person is never able to do it again, in that if you obtain proof through means that do not fall within the strict law enforcement guidelines, they may escape prosecution based on those technicalities. It would be far better to start working with law enforcement now, to ensure the investigation doesn't create loopholes they can crawl out of later as the noose tightens. Matt From rob at invaluement.com Sat Jun 28 18:50:54 2014 From: rob at invaluement.com (Rob McEwen) Date: Sat, 28 Jun 2014 14:50:54 -0400 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AF0218.7090707@truemetal.org> References: <53AED1EF.30702@truemetal.org> <53AEFEF1.50502@invaluement.com> <53AF00E5.9010405@truemetal.org> <53AF0218.7090707@truemetal.org> Message-ID: <53AF0E8E.204@invaluement.com> On 6/28/2014 1:57 PM, Markus wrote: > Sorry, maybe that line wasn't clear. What I meant is: he targets > anyone, everywhere, including individuals and businesses in the US. I think it will be easier/faster if a US victim pursues this with law enforcement, since, in general, legal systems often don't take complaints from foreign nationals very seriously. Maybe you join forces with a US-victim? -- Rob McEwen +1 (478) 475-9032 From bill at herrin.us Sat Jun 28 21:55:12 2014 From: bill at herrin.us (William Herrin) Date: Sat, 28 Jun 2014 17:55:12 -0400 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AED1EF.30702@truemetal.org> References: <53AED1EF.30702@truemetal.org> Message-ID: On Sat, Jun 28, 2014 at 10:32 AM, Markus wrote: > Do you think the PI route makes sense? Any other recommendations? Your > feedback in general? Howdy, Some information for you to consider: 1. There are two things going on here: extortion and libel. 2. Extortion is a crime. However, unless a substantial sum was requested (much more than $1000) it may not be a felony. It can be federal crime, but if you know who did it and where that individual is, you'll have better luck pursuing it under state law. Local cops don't need to justify travel expenses to investigate a local crime. 3. The first thing the law enforcement officer will ask you is: are you prepared to come to the US and testify in court that the individual you accuse in fact did what you accused them of. If the answer is no, the case is usually over. 4. The next thing they'll want is some evidence. They need to get enough evidence for "probable cause" so they can ask a judge for a warrant to search the guy's house, computer, etc. Google the term and read about it to learn what level of evidence constitutes probable cause. The more money their department would have to spend to achieve probable cause, the less attention they'll give the case. Hand it to them on a platter and you're golden. 5. Understand that criminal law is about punishing crimes, not making things right for the victim. Law enforcement's agenda is it's agenda, not yours. They're interested in putting the guy in jail, not making him undo the damage he did to you. 6. Libel, harmfully lying in writing, is not a crime: it's a tort. You can sue the guy in court but law enforcement won't get involved. Also, it's covered under state law, not federal. You'll have to sue him either in the locality where he posted the libel from or in a locality where you can prove you were specifically harmed by the libel. Nowhere else has jurisdiction. 7. You'll have to prove you were actually harmed by the libel. So he claimed you are a child molester. Boo hoo. How much money did you lose from who and where as a result? If you can't prove you lost money, don't waste your time. 8. Chat with a lawyer. Before you hire a PI or contact law enforcement or do anything else, hire a lawyer in the area where you believe this creep lives, show him what you have and ask his advice. A few hours of a lawyer's time doesn't cost a fortune and he'll be able to give you a realistic picture of your options. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bob at FiberInternetCenter.com Sat Jun 28 23:30:13 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sat, 28 Jun 2014 16:30:13 -0700 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AED1EF.30702@truemetal.org> References: <53AED1EF.30702@truemetal.org> Message-ID: <2b7e59a06af70613c3817c0c80d0697a.squirrel@66.201.44.180> Well, soccer game is over...so here's some information that may help. You have an interesting dilemma. But I don't think there is much you can do with law enforcement across borders....except operate a work around that will attract the attention of media and law enforcement. The law isn't lazy, it's just busy. Concept: I suggest your operate your own campaign against the extortionists. One that encourages the gathering of data by offering rewards for pieces of information that lead to the conviction. You have the chance to tell the world it's extortion - your info is publicly available as proof you are pursuing the criminal. Here's why: Reminds me of the time I was extorted, legally ! I had to teach a US bank's lawyer about trademark law. Rather than hand it over to that asshole. Not all lawyers are assholes, my partners son is a lawyer now. He's new, so he's working at it. :-) LOL I had one of the first Internet companies called Easynet.com. I was threatened to stop using it from a bank's lawyer that had the trademark in the banking class. Even though I had the valid trademark in the telecom class. Also bank's trademark used the term internally with other banks not consumers. I told him. Lawyer was a jerk, we discussed him being paid more to threaten and sue me than to just agree on 5k for me to market a name change. Said he knew where I lived and he will create a case I just could not afford. While I was staring at making payroll, the math took only 5 seconds to calculate that he was right. On the third call I told him I never stopped, because I never received a letter from him to cease and desist. That he could just be a voice on the phone, a future competitor tricking me. Couple days later I got the letter officially threatening to sue. After getting the letter it kept me up all night. (I was usually up resetting stuck dialup modems anyways). I decided to teach this lawyer International trademark law. I immediately contacted the new Easynet.co.uk (gee, wonder where they got that name idea). I asked if they wanted the .com that I had to release it. They offered me some free hosting that I never used. Told them to call the Internic in 24 hours. They got it. A week later the lawyer called said what did I do to him! I said, what do you mean. I did exactly as your letter stated. I stopped using it as it instructed. You mean someone overseas has the .com now? Oh, well looks like you need to brush up on international trademark law now. Let's see you explain this to the bank. Bank never got the one .com domain name the world can use. You see, while the law was on my side, it didn't matter. I needed the time and money to make the law work for me. Lesson: So sometimes you have to do something knowing you are in the right and at the same time something that makes you feel as good as possible about a bad situation. All the while operate within the law, or as close to the line as you can walk it. Concept Basic Outline: You have an international legal problem, therefore you need to do the math - math doesn't work out for you unless you're really Bill Gates hiding behind this email address. Because, one of those law agencies across a border is likely to take money from the guy you're after and not cooperate. So give that idea up. The Concept is work, you will feel good you are doing something about it, it will be your testimony to the world the things are not true and most of all if you do it right it may work. Create a situation that creates public and media awareness. Build a site against this sort of thing. Post as much info you gather as possible and gather leads from anyone. Have a little fund to gather the data from others...for example. $1000 for the name of the true web site owner extortionist. Explain the details of what that means clearly. Have a rumor posting blog section where others that have had this occur can post. Maybe you create something that locates this operation in good time. Hire a good SEO person to help - make sure your web domains attract just as much search attention. Get your domain name in your name - so that if his info pops up your site link also pops up. Play an SEO war game. If the exposure is to hot he may pull back rather than get caught. But leave this in place, make it bigger than yourself and your dilemma. Help others that end up new victims of the same situation. After it's functional, maybe you can even use one of those free raise money sites for this good cause against criminals. Create a place others can turn, turn it into a .org that makes you and others a paycheck! At the same time you will end up helping law enforcement. They are always watching and openly attend ARIN/NANOG meetings. They come to get ideas from us. ( Isn't that right Bobby ? ) Just a thought. Bob Evans CTO "Rock'n Roll Rules like Old Guys" We are programmed to receive, You can checkout anytime you like, but you can never leave. > Hi list, > > nothing operational here, but there are many smart minds on this list > and people working for telcos, ISPs and law enforcement agencies, so > maybe you are willing to give me some advice in the following case: > > There's an individual out there on the web that has been blackmailing > hundreds of people and companies in a specific area of business for > years. His scheme is: 1. Contact the alleged "debtor" via e-mail and > inform him about an existing debt claim by a third party. 2. Offer the > debtor a deadline to pay the debt and warn the debtor if he shouldn't > pay he'll be prosecuted and his case will be "made public". 3. Once the > deadline has elapsed, he'll publish completely false information made > out of thin air on the web, in particular Facebook, Twitter, a blog, a > website, including pictures of the debtor and serious accusations like > "This debtor is a child molestor" or "This debtor is part of the mafia" > and other crazy stuff that you can usually only see in movies. All of > course with real names, company information (if applicable) and > basically everything he can find out about the debtor. 4. Then, the > individual hopes that the debtor will be intimidated because the debtor > is afraid of the false information about him, which will show up on > Google etc., and will finally pay to get this false information removed > from the web. From bzs at world.std.com Sun Jun 29 17:23:36 2014 From: bzs at world.std.com (Barry Shein) Date: Sun, 29 Jun 2014 13:23:36 -0400 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AF0218.7090707@truemetal.org> References: <53AED1EF.30702@truemetal.org> <53AEFEF1.50502@invaluement.com> <53AF00E5.9010405@truemetal.org> <53AF0218.7090707@truemetal.org> Message-ID: <21424.19352.490442.675819@world.std.com> Not sure if anyone else has mentioned this but one reason to get law enforcement involved, cynicism aside, is a concern for personal, particularly physical, retribution. At one time I spent a bit too much time refuting holocaust deniers, it got rather one-on-one. They came in various flavors but some were easy to characterize as neo-nazis, some well known to law enforcement and the media, etc. There were times I'd look up and down my (fairly long) driveway carefully when coming home, in a manner of speaking. -- -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 digitalocean.com Mon Jun 30 00:26:43 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Sun, 29 Jun 2014 20:26:43 -0400 Subject: Looking for a maxcdn contact. Message-ID: Does anyone have a contact for maxcdn's noc/routing/peering group? We're seeing routes that are note coming over certain providers and from some locations we're seeing private asn's in the as path. Thanks, Bryan Socha Network Engineer DigitalOcean From gdt at gdt.id.au Mon Jun 30 03:58:27 2014 From: gdt at gdt.id.au (Glen Turner) Date: Mon, 30 Jun 2014 13:28:27 +0930 Subject: MACsec SFP In-Reply-To: <20140626062411.GA16296@pob.ytti.fi> References: <53A7EFD5.8080502@aimvalley.nl> <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> <53AB34F2.3070904@aimvalley.nl> <20140626062411.GA16296@pob.ytti.fi> Message-ID: <78F69FEE-1D31-4A45-8F8D-6B1226DF44E6@gdt.id.au> > > Perhaps such lag could be avoided in future if we'd specify some 'host to SFP' > high level protocol, perhaps in much the same way as DHCP 'option' handling? The SFF Committee specifies GBIC registers. They’d be the appropriate group to add registers for features such as MACsec, Ethernet OAM and the like. I’d also encourage a common SFF Committee feature to query and update GBIC firmware and encourage SFP vendors to make firmware freely redistributable so that SFPs can be updated by the operating system as needed to avoid security exposures (and such a feature is problematic, as it would have to be written in such a way as to prevent it being used as another mechanism resellers can use to ‘lock’ SFP sales to their equipment sales). The Committee have already specified registers for tuneable SFPs. After the SFF Committee specifies the registers the operating system vendors or vendors of devices would then add commands to support to toggle the I2C needed to program those registers with MACsec keys, etc. You should not be able to set the MACsec key from the optical side. That feature is not only cryptographically dubious but it also requires that the 'forwarding plane' (which might otherwise be entirely hardware) be connected to the SFP’s management plane. That’s not desirable from a design or security point of view. Note carefully that I’m not discouraging a self-keying mode where GBICs don’t verify their partners but are proof against receive-only optical taps (and in that case I’d encourage the SFF Committee to specify that implementations print their fingerprint and the fingerprint of the partner GBIC, so that people can verify after the fact that the partner expected is the one encountered). -- Glen Turner From skeeve+nanog at eintellegonetworks.com Mon Jun 30 05:59:47 2014 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Mon, 30 Jun 2014 15:59:47 +1000 Subject: Cheap LSN/CGN/NAT444 Solution Message-ID: Hi all, I am sure this is something that a reasonable number of people would have done on this list. I am after a LSN/CGN/NAT444 solution to put about 1000 Residential profile NBN speeds (fastest 100/40) services behind. I am looking at a Cisco ASR1001/2, pfSense and am willing to consider other options, including open source.... Obviously the cheaper the better. This solution is for v4 only, and needs to consider the profile of the typical residential users. Any pitfalls would be helpful to know - as in what will and and more importantly wont work - or any work-arounds which may work. This solution is not designed to be long lasting (maybe 6-9 months)... it is to get the solution going for up to 1000 users, and once it reaches that point then funds will be freed up to roll out a more robust, carrier-grade and long term solution (which will include v6). So no criticism on not doing v6 straight up please. Happy for feedback off-list of any solutions that people have found work well... Note, I am in Australia so any vendors which aren't easily accessible down here, won't be useful. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve at eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve experts360: https://expert360.com/profile/d54a9 twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering From saku at ytti.fi Mon Jun 30 06:17:27 2014 From: saku at ytti.fi (Saku Ytti) Date: Mon, 30 Jun 2014 09:17:27 +0300 Subject: MACsec SFP In-Reply-To: <78F69FEE-1D31-4A45-8F8D-6B1226DF44E6@gdt.id.au> References: <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> <53AB34F2.3070904@aimvalley.nl> <20140626062411.GA16296@pob.ytti.fi> <78F69FEE-1D31-4A45-8F8D-6B1226DF44E6@gdt.id.au> Message-ID: <20140630061727.GA20635@pob.ytti.fi> On (2014-06-30 13:28 +0930), Glen Turner wrote: > After the SFF Committee specifies the registers the operating system vendors or vendors of devices would then add commands to support to toggle the I2C needed to program those registers with MACsec keys, etc. This is what I tried to tackle, this creates chicken/egg scenario, no one is buying optic, because you can't program it from your router, and you can't program it in your router, as no one is using the optic and vendor won't put development hours on it. If instead there would be standardized (DHCP option like) system to code arbitrary value to arbitrary location, you could code the feature, without router understanding what it is, after a while, syntactic sugar might be added for convenience. -- ++ytti From rdrake at direcpath.com Mon Jun 30 06:37:41 2014 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 30 Jun 2014 02:37:41 -0400 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: References: Message-ID: <53B105B5.10908@direcpath.com> On 6/30/2014 1:59 AM, Skeeve Stevens wrote: > Hi all, > > I am sure this is something that a reasonable number of people would have > done on this list. > > I am after a LSN/CGN/NAT444 solution to put about 1000 Residential profile > NBN speeds (fastest 100/40) services behind. > > I am looking at a Cisco ASR1001/2, pfSense and am willing to consider other > options, including open source.... Obviously the cheaper the better. Total PPS or bandwidth is the number you need rather than number of customers. Assuming 1Gbps aggregation then almost anything will work for your requirements and support NAT. Obviously if you have a large number of 100Mbps customers then 1Gbps wouldn't cut it for aggregation. Based on your looking at the ASR I would guess you're somewhere around 1Gbps, maybe 2Gbps. If you're closer to 1Gbps and want to stay with a 1RU solution then I would advise checking out the ASA5512 which is much cheaper than an ASR. If you want to go ultra cheap but scalable to 4Gbps you could use a Cisco 6500/sup2/FWSM (all used.. probably totals less than $1000USD, but I don't know how much it is in Australia). That would let you replace parts later to move to SUP720/ASASM for around 16Gbps throughput. FWIW, I doubt you'll find a NAT platform with no IPv6 support, so you can start your IPv6 work now if need be. Older stuff like the FWSM won't support things like DS-Lite though, so if you plan to go v6-only in your backbone then that's something to think about. > > This solution is for v4 only, and needs to consider the profile of the > typical residential users. Any pitfalls would be helpful to know - as in > what will and and more importantly wont work - or any work-arounds which > may work. > > This solution is not designed to be long lasting (maybe 6-9 months)... it > is to get the solution going for up to 1000 users, and once it reaches that > point then funds will be freed up to roll out a more robust, carrier-grade > and long term solution (which will include v6). So no criticism on not > doing v6 straight up please. Be wary if someone thinks this is going to last 6-9 months. That's less than a funding cycle for a company and longer than an outage. That means the boss is pulling the number out of his ass and it could last anywhere from 30 days to 10 years depending on any number of factors. > > Happy for feedback off-list of any solutions that people have found work > well... > > Note, I am in Australia so any vendors which aren't easily accessible down > here, won't be useful. > > > ...Skeeve > > *Skeeve Stevens - *eintellego Networks Pty Ltd > skeeve at eintellegonetworks.com ; www.eintellegonetworks.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellegonetworks ; > linkedin.com/in/skeeve > > experts360: https://expert360.com/profile/d54a9 > > twitter.com/theispguy ; blog: www.theispguy.com > > > The Experts Who The Experts Call > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > From rdobbins at arbor.net Mon Jun 30 07:48:26 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 30 Jun 2014 14:48:26 +0700 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <53B105B5.10908@direcpath.com> References: <53B105B5.10908@direcpath.com> Message-ID: <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> On Jun 30, 2014, at 1:37 PM, Robert Drake wrote: > Total PPS or bandwidth is the number you need rather than number of customers. Also, be sure you have S/RTBH or some other mechanism southbound of the NAT for dealing with compromised/abusive hosts which can chew up the state-table with SYN-floods and the like. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From gdt at gdt.id.au Mon Jun 30 07:51:30 2014 From: gdt at gdt.id.au (Glen Turner) Date: Mon, 30 Jun 2014 17:21:30 +0930 Subject: MACsec SFP In-Reply-To: <20140630061727.GA20635@pob.ytti.fi> References: <20140624063725.GA25828@pob.ytti.fi> <53A92FEC.9070206@aimvalley.nl> <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> <53AB34F2.3070904@aimvalley.nl> <20140626062411.GA16296@pob.ytti.fi> <78F69FEE-1D31-4A45-8F8D-6B1226DF44E6@gdt.id.au> <20140630061727.GA20635@pob.ytti.fi> Message-ID: <25D793AF-942F-40A2-9B0D-545D1C932D1A@gdt.id.au> On 30 Jun 2014, at 3:47 pm, Saku Ytti wrote: > On (2014-06-30 13:28 +0930), Glen Turner wrote: > >> After the SFF Committee specifies the registers the operating system vendors or vendors of devices would then add commands to support to toggle the I2C needed to program those registers with MACsec keys, etc. > > This is what I tried to tackle, this creates chicken/egg scenario, no one is > buying optic, because you can't program it from your router, and you can't > program it in your router, as no one is using the optic and vendor won't put > development hours on it. > If instead there would be standardized (DHCP option like) system to code > arbitrary value to arbitrary location, you could code the feature, without > router understanding what it is, after a while, syntactic sugar might be added > for convenience. What you really want isn’t DHCP-like, but simple AND-mask OR-set register handling. You’d provide your customers with the magic numbers. interface … gbic-register [if REGISTER AND-MASK VALUE]… [set REGISTER AND-MASK OR-VALUE]… gbic-register … Assuming that the GBIC programming doesn’t change PHY requirements you are done. -- Glen Turner From saku at ytti.fi Mon Jun 30 08:54:21 2014 From: saku at ytti.fi (Saku Ytti) Date: Mon, 30 Jun 2014 11:54:21 +0300 Subject: MACsec SFP In-Reply-To: <25D793AF-942F-40A2-9B0D-545D1C932D1A@gdt.id.au> References: <53A98443.9060801@aimvalley.nl> <53A9D104.7070703@aimvalley.nl> <53AB34F2.3070904@aimvalley.nl> <20140626062411.GA16296@pob.ytti.fi> <78F69FEE-1D31-4A45-8F8D-6B1226DF44E6@gdt.id.au> <20140630061727.GA20635@pob.ytti.fi> <25D793AF-942F-40A2-9B0D-545D1C932D1A@gdt.id.au> Message-ID: <20140630085421.GA10339@pob.ytti.fi> On (2014-06-30 17:21 +0930), Glen Turner wrote: > What you really want isn’t DHCP-like, but simple AND-mask OR-set register handling. You’d provide your customers with the magic numbers. > > interface … > gbic-register [if REGISTER AND-MASK VALUE]… [set REGISTER AND-MASK OR-VALUE]… > gbic-register … > > Assuming that the GBIC programming doesn’t change PHY requirements you are done. It could be lot more user-friendly with syntactic sugar for strings, ip addresses etc. So you'd know you'll push crypto key string to register N1 and crypto integer (implying which algo to use) in regisrter N2, so you'd get something like. gbic-register N1 string "supahsecret" dgib-register N2 int 4 Far more user-friendly. -- ++ytti From tony at wicks.co.nz Mon Jun 30 09:53:16 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Mon, 30 Jun 2014 21:53:16 +1200 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> References: <53B105B5.10908@direcpath.com> <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> Message-ID: <004701cf9449$1eebd850$5cc388f0$@wicks.co.nz> >From experience (we ran out of IPv4 a long time ago in the APNIC region) this is not needed, what is needed however is session timeouts. Xbox and PlayStation are the most sensitive to session timeouts. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Monday, 30 June 2014 7:48 p.m. To: nanog at nanog.org list Subject: Re: Cheap LSN/CGN/NAT444 Solution On Jun 30, 2014, at 1:37 PM, Robert Drake wrote: > Total PPS or bandwidth is the number you need rather than number of customers. Also, be sure you have S/RTBH or some other mechanism southbound of the NAT for dealing with compromised/abusive hosts which can chew up the state-table with SYN-floods and the like. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From rdobbins at arbor.net Mon Jun 30 10:12:17 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 30 Jun 2014 17:12:17 +0700 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <004701cf9449$1eebd850$5cc388f0$@wicks.co.nz> References: <53B105B5.10908@direcpath.com> <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> <004701cf9449$1eebd850$5cc388f0$@wicks.co.nz> Message-ID: <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> On Jun 30, 2014, at 4:53 PM, Tony Wicks wrote: > From experience (we ran out of IPv4 a long time ago in the APNIC region) this is not needed, I've seen huge problems from compromised machines completely killing NATs from the southbound side. > what is needed however is session timeouts. This can help, but it isn't a solution to the botted/abusive machine problem. They'll just keep right on pumping out packets and establishing new sessions, 'crowding out' legitimate users and filling up the state-table, maxing the CPU. Embryonic connection limits and all that stuff aren't enough, either. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From simon at per.reau.lt Mon Jun 30 12:42:15 2014 From: simon at per.reau.lt (Simon Perreault) Date: Mon, 30 Jun 2014 08:42:15 -0400 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> References: <53B105B5.10908@direcpath.com> <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> <004701cf9449$1eebd850$5cc388f0$@wicks.co.nz> <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> Message-ID: <53B15B27.7060803@per.reau.lt> Le 2014-06-30 06:12, Roland Dobbins a écrit : >> what is needed however is session timeouts. > This can help, but it isn't a solution to the botted/abusive machine problem. They'll just keep right on pumping out packets and establishing new sessions, 'crowding out' legitimate users and filling up the state-table, maxing the CPU. Embryonic connection limits and all that stuff aren't enough, either. Why? Cause that (per-subscriber limits on ports and memory) is exactly what we recommend in RFC 6888... Simon From rdobbins at arbor.net Mon Jun 30 13:05:58 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 30 Jun 2014 20:05:58 +0700 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <53B15B27.7060803@per.reau.lt> References: <53B105B5.10908@direcpath.com> <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> <004701cf9449$1eebd850$5cc388f0$@wicks.co.nz> <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> <53B15B27.7060803@per.reau.lt> Message-ID: <3278391F-86EF-4D81-834A-3BD8F0E85876@arbor.net> On Jun 30, 2014, at 7:42 PM, Simon Perreault wrote: > Why? Cause that (per-subscriber limits on ports and memory) is exactly what we recommend in RFC 6888... I can't tell you how many times I've received frantic 4AM calls about NATted wireless networks going down due to this sort of thing. It's a real problem. Also, there are horizontal behaviors which are undesirable, as well. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From simon at per.reau.lt Mon Jun 30 13:19:23 2014 From: simon at per.reau.lt (Simon Perreault) Date: Mon, 30 Jun 2014 09:19:23 -0400 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <3278391F-86EF-4D81-834A-3BD8F0E85876@arbor.net> References: <53B105B5.10908@direcpath.com> <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> <004701cf9449$1eebd850$5cc388f0$@wicks.co.nz> <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> <53B15B27.7060803@per.reau.lt> <3278391F-86EF-4D81-834A-3BD8F0E85876@arbor.net> Message-ID: <53B163DB.20300@per.reau.lt> Le 2014-06-30 09:05, Roland Dobbins a écrit : > > On Jun 30, 2014, at 7:42 PM, Simon Perreault wrote: > >> Why? Cause that (per-subscriber limits on ports and memory) is exactly what we recommend in RFC 6888... > > > > I can't tell you how many times I've received frantic 4AM calls about NATted wireless networks going down due to this sort of thing. It's a real problem. If you're saying "NAT is bad", then sure, ok, but that's besides the point. Otherwise, then I don't know what your point is. Oh, actually I think I get it. You're trying to sell something. > Also, there are horizontal behaviors which are undesirable, as well. Yeah, and let's not forget the diagonal ones either. Simon From rdobbins at arbor.net Mon Jun 30 13:40:57 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 30 Jun 2014 20:40:57 +0700 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <53B163DB.20300@per.reau.lt> References: <53B105B5.10908@direcpath.com> <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> <004701cf9449$1eebd850$5cc388f0$@wicks.co.nz> <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> <53B15B27.7060803@per.reau.lt> <3278391F-86EF-4D81-834A-3BD8F0E85876@arbor.net> <53B163DB.20300@per.reau.lt> Message-ID: <287106E0-5A85-4C0A-A5D5-D84F8575E6AD@arbor.net> On Jun 30, 2014, at 8:19 PM, Simon Perreault wrote: > Oh, actually I think I get it. You're trying to sell something. Yes, you've found me out - I'm 'selling' S/RTBH, which is built-in functionality of routers and layer-3 switches made by companies which don't employ me. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From Valdis.Kletnieks at vt.edu Mon Jun 30 13:40:19 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 30 Jun 2014 09:40:19 -0400 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: Your message of "Mon, 30 Jun 2014 15:59:47 +1000." References: Message-ID: <96782.1404135619@turing-police.cc.vt.edu> On Mon, 30 Jun 2014 15:59:47 +1000, Skeeve Stevens said: > I am after a LSN/CGN/NAT444 solution to put about 1000 Residential profile > NBN speeds (fastest 100/40) services behind. > This solution is for v4 only, and needs to consider the profile of the > typical residential users. Any pitfalls would be helpful to know - as in > what will and and more importantly wont work - or any work-arounds which > may work. Pitfall 1: Make sure you have enough support desk to handle calls from everybody who's doing something that doesn't play nice with CGN/NAT444. And remember that unless "screw you, find another provider" is an acceptable response to a customer, those calls are going to be major resource sinks to resolve to the customer's satisfaction... Pitfall 2: These sort of short-term solutions often end up still in use well after their sell-by date. If you're planning to deploy a new solution in 6 months, maybe throwing resources at a short-term fix is counterproductive and the resources should go towards making the current solution hold together and deploying the long-term solution... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From phil.gardnerjr at gmail.com Mon Jun 30 13:45:13 2014 From: phil.gardnerjr at gmail.com (Phil Gardner) Date: Mon, 30 Jun 2014 09:45:13 -0400 Subject: Comcast Business Internet Options Message-ID: <53B169E9.80706@gmail.com> Hi all - Probably like a lot of people on the list, I depend on my home internet connection for many things including my primary job, and the numerous side projects I work on. I'd really a appreciate a connection that would have a shorter response time if something were to go wrong. Unfortunately, I just moved and now I'm out of the service area of my previous provider, who was actually able to compete with Comcast (FTTH). Now I'm stuck with one option. I really don't plan on spending more than a year where I currently am, so I don't want be locked into a contract for more than a year, especially with Comcast's crap termination fee (75% of the remainder on the contract). I called and talked to a sales rep, who was just a kid, and an arrogant one at that. He knew of the monopoly for a decent internet connection in my area, so I had little bargaining power. The offer he gave me was: minimum 2 year contract, with a $99 installation fee, and his "supervisor" "approved" a $300 Visa giftcard if I agreed to this. The other option is a 1 year contract, with a $199 installation fee, with no giftcard. This is for the 50Mbit option, and he didn't seem to care about my counter offer to bump it up to 75Mbit if he waived the install fee. Come on...$199 to plug in a modem. The address already had Comcast before I got there... Is there anyone out there that has ideas about how to waive or lower that installation fee while only having a 1 year contract? -- _____________________ Phil Gardner PGP Key ID 0xFECC890C OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538 From twh at megagroup.ru Mon Jun 30 12:06:51 2014 From: twh at megagroup.ru (Stepan Kucherenko) Date: Mon, 30 Jun 2014 16:06:51 +0400 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> References: <53B105B5.10908@direcpath.com> <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> <004701cf9449$1eebd850$5cc388f0$@wicks.co.nz> <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> Message-ID: <53B152DB.5000103@megagroup.ru> On 30.06.2014 14:12, Roland Dobbins wrote: > I've seen huge problems from compromised machines completely killing > NATs from the southbound side. It depends on CGN solution used. Some of them will just block new translations for that user after reaching the limit, and that's it. On 30.06.2014 09:59, Skeeve Stevens wrote: > I am after a LSN/CGN/NAT444 solution to put about 1000 Residential > profile NBN speeds (fastest 100/40) services behind. > I am looking at a Cisco ASR1001/2, pfSense and am willing to consider > other options, including open source.... Obviously the cheaper the > better. ASR1k NAT is known to be problematic (nat overload specifically), don't know if they fixed it yet. I recommend to check this with the vendor first. New Juniper MS-MIC/MS-MPC multiservices cards can be used but feature-parity with MS-DPC isn't there yet. For example, you can have a working CGN with most bells and whistles, but you can't use IDS. You can (probably) use deterministic nat with max ports/sessions per user, but sometimes it's not enough. Again, ask the vendor for details/roadmaps/solutions. Both those options aren't really cheap though. Cheaper would be something like Mikrotik but I wouldn't touch that sh*t with a ten-foot pole. It might work but you'll pay for that with your sanity and sleep hours. Speaking of cheap and open-source, I know several relatively large implementations using Linux boxes. One Linux NAT box can chew on at least 1Gb/s of traffic, or even more with a careful selection of hardware and even more careful tuning, and you can load-balance between them, but it's much more effort and it isn't robust enough (which is the reason why they all migrate to better solutions later). BTW, I agree that you should speak in PPS and bandwidth instead of number of users, those are much better as a metric. > This solution is for v4 only, and needs to consider the profile of the > typical residential users. Any pitfalls would be helpful to know - > as in what will and and more importantly wont work - or any > work-arounds which may work. Try to pair a user IP with a public IP, that way you'll workaround most websites/games/applications expecting publicly visible user IP to be the same for all connections. Start with selected few active customers, check how much connections they use with different NAT settings. Double/triple that. Then do the math of how many ports/IPs you need per X users, don't just guess it. Then try to limit it and see if anything breaks. By working with them you can also workaround some of the problems you didn't think about before. Seriously. Fix it before you roll it out. What anyone implementing CGN should expect is complaints from users for any number of reasons, like their IPSEC or L2TP tunnel stopped working, or some application behaves strangely and so on. Prepare your techsupport for that. > This solution is not designed to be long lasting (maybe 6-9 > months)... it is to get the solution going for up to 1000 users, and > once it reaches that point then funds will be freed up to roll out a > more robust, carrier-grade and long term solution (which will include > v6). So no criticism on not doing v6 straight up please. Heh. Nothing lasts longer than temporary solutions. You should implement it like you're going to live it for years (probably true) or you'll create yourself a huge PITA very soon. From lists at billmerriam.com Mon Jun 30 14:00:37 2014 From: lists at billmerriam.com (Bill Merriam) Date: Mon, 30 Jun 2014 10:00:37 -0400 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AED1EF.30702@truemetal.org> References: <53AED1EF.30702@truemetal.org> Message-ID: <20140630100037.1dd66611@giga.billmerriam.com> On Sat, 28 Jun 2014 16:32:15 +0200 Markus wrote: > Hi list, > > nothing operational here, but there are many smart minds on this list > and people working for telcos, ISPs and law enforcement agencies, so > maybe you are willing to give me some advice in the following case: > > There's an individual out there on the web that has been blackmailing > hundreds of people and companies in a specific area of business for > years. His scheme is: 1. Contact the alleged "debtor" via e-mail and > inform him about an existing debt claim by a third party. 2. Offer > the debtor a deadline to pay the debt and warn the debtor if he > shouldn't pay he'll be prosecuted and his case will be "made public". > 3. Once the deadline has elapsed, he'll publish completely false > information made out of thin air on the web, in particular Facebook, > Twitter, a blog, a website, including pictures of the debtor and > serious accusations like "This debtor is a child molestor" or "This > debtor is part of the mafia" and other crazy stuff that you can > usually only see in movies. All of course with real names, company > information (if applicable) and basically everything he can find out > about the debtor. 4. Then, the individual hopes that the debtor will > be intimidated because the debtor is afraid of the false information > about him, which will show up on Google etc., and will finally pay to > get this false information removed from the web. > > In all cases the published "background information" about the debtors > is false, made out of thin air, and over the top. Just the names and > pictures are correct. Intentional slander in order to get the debtor > to pay. If any of the published information was true, then every 2nd > debtor would be a child molestor and every other debtor part of the > mafia. > > That individual is hiding his real identity really well, obviously, > and he knows what he's doing. Domain hosted in Russia, taking good > care his IP address won't show up in the mail headers, using false > names and identities, phone numbers registered through some DID > provider who doesn't collect personal information about the DID owner > etc. > > I am one of the accused and had lots of false information about > myself and my company published by him. This is why I started to have > an interest to track his real identity down. I took 2 days out of my > life and researched high and low and finally found his personal phone > number along with a name, a picture of him and several possible > addresses (in the US). > > I cannot be sure that the name, picture and addresses are correct, > but I called him on his personal phone number and after having spoken > with him before under his false identity, I can confirm that it's the > same person (the voice is the same). He was quite surprised to say > the least. > > In case it matters, according to a LRN lookup the number belongs to > Omnipoint Communications, which is part of T-Mobile USA, I think. > > My idea is to somehow confirm his identity and confirm my research by > matching the voice of the false identity (available from a message he > left on my voicemail and also from his voicemail intro) to the real > person. I'm thinking about hiring a private investigator in the US > (I'm in Germany) to drive up to the addresses I can provide the PI > with and find the person that matches the voice / maybe even the > picture. The PI then must document the outcome in a way that it can > be used in court. I'm wanting to go the PI route because it will be > the fastest way to possibly gather evidence, I assume, as opposed to > commissioning a lawyer who will then in turn contact law enforcement > etc. > > Unfortunately I do not have the authority to access the personal data > of the person that pays the monthly bill for the phone number that I > called him on, otherwise that would be the fastest way I suppose. I > spent money for some pay-sites that do some reverse phone lookup and > stuff like that, and although the information was helpful, I cannot > be sure that it's accurate. > > My goal is to confirm his real identity/name and address in order to > start a lawsuit and have a lawyer, or maybe even law enforcement, > investigate this case and ultimately, put an end to his slander > activities, not just for my case but for all hundreds before me and > those which are to come in the future. > > Do you think the PI route makes sense? Any other recommendations? > Your feedback in general? > > Thanks and sorry for so much text. :) > Markus > Try contacting Brian Krebs. http://krebsonsecurity.com/2014/06/2014-the-year-extortion-went-mainstream/ Also it seems like if you have a industry association you should get them to notify members and help with a response. Bill From charles at thefnf.org Mon Jun 30 16:35:51 2014 From: charles at thefnf.org (Charles N Wyble) Date: Mon, 30 Jun 2014 11:35:51 -0500 Subject: Next steps in extortion case - ideas? In-Reply-To: <53AED1EF.30702@truemetal.org> References: <53AED1EF.30702@truemetal.org> Message-ID: Sue him for slander? Contact the US DOJ and request extortion charges be filed? I mean if someone was committing a crime against me, I'd certainly be in contact with law enforcement to have charges filed and a warrant out for arrest. You shouldn't have called him. He has certainly changed his phone number. He also now most likely has your personal phone number. Contact law enforcement. That's what you should of done instead of calling him. I'd also consult your attorney. Ironically enough , the person you contacted could potentially try and turn the tables on you. Did you record the telephone conversation? On June 28, 2014 9:32:15 AM CDT, Markus wrote: >Hi list, > >nothing operational here, but there are many smart minds on this list >and people working for telcos, ISPs and law enforcement agencies, so >maybe you are willing to give me some advice in the following case: > >There's an individual out there on the web that has been blackmailing >hundreds of people and companies in a specific area of business for >years. His scheme is: 1. Contact the alleged "debtor" via e-mail and >inform him about an existing debt claim by a third party. 2. Offer the >debtor a deadline to pay the debt and warn the debtor if he shouldn't >pay he'll be prosecuted and his case will be "made public". 3. Once the > >deadline has elapsed, he'll publish completely false information made >out of thin air on the web, in particular Facebook, Twitter, a blog, a >website, including pictures of the debtor and serious accusations like >"This debtor is a child molestor" or "This debtor is part of the mafia" > >and other crazy stuff that you can usually only see in movies. All of >course with real names, company information (if applicable) and >basically everything he can find out about the debtor. 4. Then, the >individual hopes that the debtor will be intimidated because the debtor > >is afraid of the false information about him, which will show up on >Google etc., and will finally pay to get this false information removed > >from the web. > >In all cases the published "background information" about the debtors >is >false, made out of thin air, and over the top. Just the names and >pictures are correct. Intentional slander in order to get the debtor to > >pay. If any of the published information was true, then every 2nd >debtor >would be a child molestor and every other debtor part of the mafia. > >That individual is hiding his real identity really well, obviously, and > >he knows what he's doing. Domain hosted in Russia, taking good care his > >IP address won't show up in the mail headers, using false names and >identities, phone numbers registered through some DID provider who >doesn't collect personal information about the DID owner etc. > >I am one of the accused and had lots of false information about myself >and my company published by him. This is why I started to have an >interest to track his real identity down. I took 2 days out of my life >and researched high and low and finally found his personal phone number > >along with a name, a picture of him and several possible addresses (in >the US). > >I cannot be sure that the name, picture and addresses are correct, but >I >called him on his personal phone number and after having spoken with >him >before under his false identity, I can confirm that it's the same >person >(the voice is the same). He was quite surprised to say the least. > >In case it matters, according to a LRN lookup the number belongs to >Omnipoint Communications, which is part of T-Mobile USA, I think. > >My idea is to somehow confirm his identity and confirm my research by >matching the voice of the false identity (available from a message he >left on my voicemail and also from his voicemail intro) to the real >person. I'm thinking about hiring a private investigator in the US (I'm > >in Germany) to drive up to the addresses I can provide the PI with and >find the person that matches the voice / maybe even the picture. The PI > >then must document the outcome in a way that it can be used in court. >I'm wanting to go the PI route because it will be the fastest way to >possibly gather evidence, I assume, as opposed to commissioning a >lawyer >who will then in turn contact law enforcement etc. > >Unfortunately I do not have the authority to access the personal data >of >the person that pays the monthly bill for the phone number that I >called >him on, otherwise that would be the fastest way I suppose. I spent >money >for some pay-sites that do some reverse phone lookup and stuff like >that, and although the information was helpful, I cannot be sure that >it's accurate. > >My goal is to confirm his real identity/name and address in order to >start a lawsuit and have a lawyer, or maybe even law enforcement, >investigate this case and ultimately, put an end to his slander >activities, not just for my case but for all hundreds before me and >those which are to come in the future. > >Do you think the PI route makes sense? Any other recommendations? Your >feedback in general? > >Thanks and sorry for so much text. :) >Markus > > >!DSPAM:53aed254132381214135849! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From brandon.galbraith at gmail.com Mon Jun 30 17:33:08 2014 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 30 Jun 2014 12:33:08 -0500 Subject: Comcast Business Internet Options In-Reply-To: <53B169E9.80706@gmail.com> References: <53B169E9.80706@gmail.com> Message-ID: On Mon, Jun 30, 2014 at 8:45 AM, Phil Gardner wrote: > Is there anyone out there that has ideas about how to waive or lower that > installation fee while only having a 1 year contract? I've worked with Comcast Business on <10 installations for clients, and the only time I was able to get installation charge concessions was on a long-term agreement (3 years minimum). This is in an area where they have active competition with an ILEC. brandon From will at willscorner.net Mon Jun 30 18:37:54 2014 From: will at willscorner.net (Will Dean) Date: Mon, 30 Jun 2014 14:37:54 -0400 Subject: Comcast Business Internet Options In-Reply-To: References: <53B169E9.80706@gmail.com> Message-ID: <53B1AE82.2090906@willscorner.net> Phil, Comcast does have a residential fiber tier that leverages their metro ethernet network. https://www.comcast.com/505 http://www.speedtest.net/result/3595673618.png - Will > Brandon Galbraith > June 30, 2014 at 1:33 PM > > I've worked with Comcast Business on <10 installations for clients, > and the only time I was able to get installation charge concessions > was on a long-term agreement (3 years minimum). This is in an area > where they have active competition with an ILEC. > > brandon > Phil Gardner > June 30, 2014 at 9:45 AM > Hi all - > > Probably like a lot of people on the list, I depend on my home > internet connection for many things including my primary job, and the > numerous side projects I work on. > > I'd really a appreciate a connection that would have a shorter > response time if something were to go wrong. Unfortunately, I just > moved and now I'm out of the service area of my previous provider, who > was actually able to compete with Comcast (FTTH). Now I'm stuck with > one option. > > I really don't plan on spending more than a year where I currently am, > so I don't want be locked into a contract for more than a year, > especially with Comcast's crap termination fee (75% of the remainder > on the contract). > > I called and talked to a sales rep, who was just a kid, and an > arrogant one at that. He knew of the monopoly for a decent internet > connection in my area, so I had little bargaining power. > > The offer he gave me was: minimum 2 year contract, with a $99 > installation fee, and his "supervisor" "approved" a $300 Visa giftcard > if I agreed to this. The other option is a 1 year contract, with a > $199 installation fee, with no giftcard. This is for the 50Mbit > option, and he didn't seem to care about my counter offer to bump it > up to 75Mbit if he waived the install fee. > > Come on...$199 to plug in a modem. The address already had Comcast > before I got there... > > Is there anyone out there that has ideas about how to waive or lower > that installation fee while only having a 1 year contract? From phil.gardnerjr at gmail.com Mon Jun 30 19:49:50 2014 From: phil.gardnerjr at gmail.com (Phil Gardner) Date: Mon, 30 Jun 2014 15:49:50 -0400 Subject: Comcast Business Internet Options In-Reply-To: <53B1AE82.2090906@willscorner.net> References: <53B169E9.80706@gmail.com> <53B1AE82.2090906@willscorner.net> Message-ID: <53B1BF5E.3010107@gmail.com> Damn, interesting. Though for my needs, I'm more interested in the response time for service than all out speed. I'd also be surprised if they offer that in my state. On 06/30/2014 02:37 PM, Will Dean wrote: > Phil, > > > Comcast does have a residential fiber tier that leverages their metro > ethernet network. https://www.comcast.com/505 > > http://www.speedtest.net/result/3595673618.png > > - Will >> Brandon Galbraith >> June 30, 2014 at 1:33 PM >> >> I've worked with Comcast Business on <10 installations for clients, >> and the only time I was able to get installation charge concessions >> was on a long-term agreement (3 years minimum). This is in an area >> where they have active competition with an ILEC. >> >> brandon >> Phil Gardner >> June 30, 2014 at 9:45 AM >> Hi all - >> >> Probably like a lot of people on the list, I depend on my home >> internet connection for many things including my primary job, and the >> numerous side projects I work on. >> >> I'd really a appreciate a connection that would have a shorter >> response time if something were to go wrong. Unfortunately, I just >> moved and now I'm out of the service area of my previous provider, who >> was actually able to compete with Comcast (FTTH). Now I'm stuck with >> one option. >> >> I really don't plan on spending more than a year where I currently am, >> so I don't want be locked into a contract for more than a year, >> especially with Comcast's crap termination fee (75% of the remainder >> on the contract). >> >> I called and talked to a sales rep, who was just a kid, and an >> arrogant one at that. He knew of the monopoly for a decent internet >> connection in my area, so I had little bargaining power. >> >> The offer he gave me was: minimum 2 year contract, with a $99 >> installation fee, and his "supervisor" "approved" a $300 Visa giftcard >> if I agreed to this. The other option is a 1 year contract, with a >> $199 installation fee, with no giftcard. This is for the 50Mbit >> option, and he didn't seem to care about my counter offer to bump it >> up to 75Mbit if he waived the install fee. >> >> Come on...$199 to plug in a modem. The address already had Comcast >> before I got there... >> >> Is there anyone out there that has ideas about how to waive or lower >> that installation fee while only having a 1 year contract? > -- _____________________ Phil Gardner PGP Key ID 0xFECC890C OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538 From rdrake at direcpath.com Mon Jun 30 20:18:39 2014 From: rdrake at direcpath.com (rdrake) Date: Mon, 30 Jun 2014 16:18:39 -0400 Subject: Comcast Business Internet Options In-Reply-To: <53B1BF5E.3010107@gmail.com> References: <53B169E9.80706@gmail.com> <53B1AE82.2090906@willscorner.net> <53B1BF5E.3010107@gmail.com> Message-ID: <53B1C61F.40901@direcpath.com> On 06/30/2014 03:49 PM, Phil Gardner wrote: > Damn, interesting. Though for my needs, I'm more interested in the > response time for service than all out speed. > > I'd also be surprised if they offer that in my state. > Where are you located? Usually you can get an okay DSL connection as a backup and that would be better than most of the SLAs from big companies*. Alternatively you could get a wifi or USB LTE dongle for a secondary connection. Of course that may not be available in your area, but I've gotten LTE in surprising places. * The problem with the SLAs being that they won't restore your service in 3 days, they'll just credit you the full price of your dinky circuit. The good news is if your inside wiring is clean then you probably won't have too many outages on cable. Ask your neighbors if their Internet is reliable. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rwebb at ropeguru.com Mon Jun 30 20:40:55 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Mon, 30 Jun 2014 16:40:55 -0400 Subject: Comcast Business Internet Options In-Reply-To: <53B1BF5E.3010107@gmail.com> References: <53B169E9.80706@gmail.com> <53B1AE82.2090906@willscorner.net> <53B1BF5E.3010107@gmail.com> Message-ID: I have a cable based business in my residence. There is no SLA with the standard business class service. However, I have typically seen about a 4 hour response time during the week for a tech and never any longer than the next day. As far as install fees and such, the only way to get it waived, as others have mentioned, is a 3 year contract. Lower fee for 2 year contract and full install fee for 1 year contract. Good deal with the Visa Card as I have never heard of that being offered before. You get the saem "up to" BS as residential and if you want static IP's with that, be prepared for a required $12.95 equipment rental fee on top of the monthly price, static IP price, and tax. Robert On Mon, 30 Jun 2014 15:49:50 -0400 Phil Gardner wrote: > Damn, interesting. Though for my needs, I'm more interested in the >response time for service than all out speed. > > I'd also be surprised if they offer that in my state. > > > On 06/30/2014 02:37 PM, Will Dean wrote: >> Phil, >> >> >> Comcast does have a residential fiber tier that leverages their >>metro >> ethernet network. https://www.comcast.com/505 >> From tony at wicks.co.nz Mon Jun 30 21:28:19 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 1 Jul 2014 09:28:19 +1200 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> References: <53B105B5.10908@direcpath.com> <4753D63B-02DE-4F97-96EC-172C5C5C9C0E@arbor.net> <004701cf9449$1eebd850$5cc388f0$@wicks.co.nz> <81415AF7-4DC7-4A91-9D6E-4A596C4F9B73@arbor.net> Message-ID: <002501cf94aa$3753be60$a5fb3b20$@wicks.co.nz> I run ASR1k6's ESP40/RP2 with 10-15k BNG clients on each running full CGNAT. Translations peak at about 250k per 10K users. The ESP40 can handle 2M translations, so there is plenty of room to run them up to 32k users without having to be concerned (64k in an emergency). I have been running this configuration for 2+ years in production and never had any issue with getting anywhere near close to having a performance issue. Now incoming DDOS attacks are another matter, they are a lot more common and damaging with the CGNAT as you need to remove the destination IP from your nat pool for the duration. If you were doing your CGNAT on an older 72xx or similar CPU based box, well then all bets are off, I would expect available NAT table resource to be very easy to exhaust. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Monday, 30 June 2014 10:12 p.m. To: nanog at nanog.org list Subject: Re: Cheap LSN/CGN/NAT444 Solution On Jun 30, 2014, at 4:53 PM, Tony Wicks wrote: > From experience (we ran out of IPv4 a long time ago in the APNIC region) this is not needed, I've seen huge problems from compromised machines completely killing NATs from the southbound side. > what is needed however is session timeouts. This can help, but it isn't a solution to the botted/abusive machine problem. They'll just keep right on pumping out packets and establishing new sessions, 'crowding out' legitimate users and filling up the state-table, maxing the CPU. Embryonic connection limits and all that stuff aren't enough, either. ---------------------------------------------------------------------- From marka at isc.org Mon Jun 30 23:23:57 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 01 Jul 2014 09:23:57 +1000 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: Your message of "Mon, 30 Jun 2014 09:40:19 -0400." <96782.1404135619@turing-police.cc.vt.edu> References: <96782.1404135619@turing-police.cc.vt.edu> Message-ID: <20140630232357.D160319828D3@rock.dv.isc.org> In message <96782.1404135619 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1404135618_1958P > Content-Type: text/plain; charset=us-ascii > > On Mon, 30 Jun 2014 15:59:47 +1000, Skeeve Stevens said: > > > I am after a LSN/CGN/NAT444 solution to put about 1000 Residential profile > > NBN speeds (fastest 100/40) services behind. > > > This solution is for v4 only, and needs to consider the profile of the > > typical residential users. Any pitfalls would be helpful to know - as in > > what will and and more importantly wont work - or any work-arounds which > > may work. > > Pitfall 1: Make sure you have enough support desk to handle calls from > everybody who's doing something that doesn't play nice with CGN/NAT444. > And remember that unless "screw you, find another provider" is an acceptable > response to a customer, those calls are going to be major resource sinks to > resolve to the customer's satisfaction... And this is where the entire industry world wide is to blame. CGN, DS-Lite, NAT64 are designed as end-of-transition products not start- of-transition products. They are designed around getting to a legacy IPv4 network. CGN, DS-Lite, and NAT64 all reduce functionality that is normally available on wired networks. Just because there was not a fixed date, like 1/1/2000, for when it would be too late didn't mean that there wasn't a problem coming or that plain dual stack shouldn't have been ubiquitous before then. As a consumer I don't want to be forced to loose functionally because the industry as a whole was too f!@$!#!@ short sighted to do what was best for the consumer well enough in advance so that everyone could sort out the teething issues. Networks work because *everybody* can speak the same protocol. I don't care which transport protocol I use. I do care if I can't continue to do something because people were too slow to react. > Pitfall 2: These sort of short-term solutions often end up still in > use well after their sell-by date. If you're planning to deploy a > new solution in 6 months, maybe throwing resources at a short-term fix > is counterproductive and the resources should go towards making the current > solution hold together and deploying the long-term solution... > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From skeeve+nanog at eintellegonetworks.com Mon Jun 30 23:59:39 2014 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Tue, 1 Jul 2014 09:59:39 +1000 Subject: Cheap LSN/CGN/NAT444 Solution In-Reply-To: <53B105B5.10908@direcpath.com> References: <53B105B5.10908@direcpath.com> Message-ID: Hi Rob, Interesting insights. I hadn't thought of an older 6500/7600... certainly might be worth considering if I want to stay Cisco. Yes, PPS is the key, but I thought someone might have some comments on the metrics/pps I'd expect with that kind of user profile and speeds. It doesn't need to not have v6, I'm just not using it at the moment. The timeframes are my numbers based on the proof of concept for the larger business model/design - which is modular as such. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve at eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve experts360: https://expert360.com/profile/d54a9 twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering On Mon, Jun 30, 2014 at 4:37 PM, Robert Drake wrote: > > On 6/30/2014 1:59 AM, Skeeve Stevens wrote: > >> Hi all, >> >> I am sure this is something that a reasonable number of people would have >> done on this list. >> >> I am after a LSN/CGN/NAT444 solution to put about 1000 Residential profile >> NBN speeds (fastest 100/40) services behind. >> >> I am looking at a Cisco ASR1001/2, pfSense and am willing to consider >> other >> options, including open source.... Obviously the cheaper the better. >> > > Total PPS or bandwidth is the number you need rather than number of > customers. Assuming 1Gbps aggregation then almost anything will work for > your requirements and support NAT. Obviously if you have a large number of > 100Mbps customers then 1Gbps wouldn't cut it for aggregation. > > Based on your looking at the ASR I would guess you're somewhere around > 1Gbps, maybe 2Gbps. If you're closer to 1Gbps and want to stay with a 1RU > solution then I would advise checking out the ASA5512 which is much cheaper > than an ASR. > > If you want to go ultra cheap but scalable to 4Gbps you could use a Cisco > 6500/sup2/FWSM (all used.. probably totals less than $1000USD, but I don't > know how much it is in Australia). That would let you replace parts later > to move to SUP720/ASASM for around 16Gbps throughput. > > FWIW, I doubt you'll find a NAT platform with no IPv6 support, so you can > start your IPv6 work now if need be. Older stuff like the FWSM won't > support things like DS-Lite though, so if you plan to go v6-only in your > backbone then that's something to think about. > > >> This solution is for v4 only, and needs to consider the profile of the >> typical residential users. Any pitfalls would be helpful to know - as in >> what will and and more importantly wont work - or any work-arounds which >> may work. >> >> This solution is not designed to be long lasting (maybe 6-9 months)... it >> is to get the solution going for up to 1000 users, and once it reaches >> that >> point then funds will be freed up to roll out a more robust, carrier-grade >> and long term solution (which will include v6). So no criticism on not >> doing v6 straight up please. >> > Be wary if someone thinks this is going to last 6-9 months. That's less > than a funding cycle for a company and longer than an outage. That means > the boss is pulling the number out of his ass and it could last anywhere > from 30 days to 10 years depending on any number of factors. > > > >> Happy for feedback off-list of any solutions that people have found work >> well... >> >> Note, I am in Australia so any vendors which aren't easily accessible down >> here, won't be useful. >> >> >> ...Skeeve >> >> *Skeeve Stevens - *eintellego Networks Pty Ltd >> skeeve at eintellegonetworks.com ; www.eintellegonetworks.com >> >> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve >> >> facebook.com/eintellegonetworks ; >> linkedin.com/in/skeeve >> >> experts360: https://expert360.com/profile/d54a9 >> >> twitter.com/theispguy ; blog: www.theispguy.com >> >> >> The Experts Who The Experts Call >> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering >> >> >