From baconzombie at gmail.com Thu Nov 1 00:03:55 2012 From: baconzombie at gmail.com (Bacon Zombie) Date: Thu, 1 Nov 2012 00:03:55 +0000 Subject: Google burp In-Reply-To: <20121031234344.GF19113@hiwaay.net> References: <5091A0E9.30801@rancid.berkeley.edu> <20121031234344.GF19113@hiwaay.net> Message-ID: And if you are a Chrome user have a look at Vimium [1] [1] http://vimium.github.com/ On 31 October 2012 23:43, Chris Adams wrote: > Once upon a time, shawn wilson said: >> yeah, be careful with their new compose feature. i'm used to vim, so i >> hit esc half way through an email which generally does nothing. >> however, with this "new" feature, it closed the email. then it took it >> longer to appear in drafts than it did to compose a new email. so, now >> i've disabled it. i hope they don't force the issue until they give me >> vim key bindings in my email editor :) > > Have you tried the Firefox add-on that can turn input boxes into vi > mode? Does that work with Gmail? > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > -- ???????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????? BaconZombie LOAD "*",8,1 From ag4ve.us at gmail.com Thu Nov 1 00:29:32 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 1 Nov 2012 00:29:32 +0000 Subject: Google burp In-Reply-To: References: <5091A0E9.30801@rancid.berkeley.edu> <20121031234344.GF19113@hiwaay.net> Message-ID: On Thu, Nov 1, 2012 at 12:03 AM, Bacon Zombie wrote: > And if you are a Chrome user have a look at Vimium [1] > > [1] http://vimium.github.com/ > looks promising: i enter insert mode -- all commands will be ignored until you hit esc to exit i might be able to handle this - i could never get vimperator (sorry for hijacking the thread :) ) From pumpky at sonic.net Thu Nov 1 05:31:57 2012 From: pumpky at sonic.net (Crist J. Clark) Date: Wed, 31 Oct 2012 22:31:57 -0700 Subject: IPv6 Netowrk Device Numbering BP Message-ID: <20121101053157.GD1727@don.i.pumpky.net> We're working out our dual stacked IPv4-IPv6 network. One issue that recently has arisen is how to number the management interfaces on the network devices themselves. I have always been kind of partial to the idea of taking advantage IPv6 features and letting hosts set their own addresses with EUI-64 interface numbers. For the management interface on a network device, it's more like a "normal" host. I'd just as well tell the device its prefix, and let it build the address itself. For IPv6, my opinion is that I'm not even going to try to remember 128-bit addresses. It's not something reasonable to expect humans to do. I'm going to depend on some name-to-number service (DNS or a hosts file), and as far as a computer goes, 2001:db8::80:abff:fe45:6789 is just as easy to remember as, 2001:db8::12:34. The other approach is to assign addresses. To me, that's more of a hold over from IPv4 thinking, but there are legitimate reasons I can think of. It's nice to have the IPv6 address tied to the configuration rather than the hardware. If you need to drop in a replacement device, you copy the configuration and no addresses change. But OTOH, others might consider it a feature that the IP follows the device rather than the role. And the real reason I think people want to do it is that they want to be able to memorize IP addresses of "important" hosts like these. Another option would be to do both. Assign a fixed address and also let it chose EUI-64. However, I see that leading to confusion. Not sure what good it would do. Is there anything like a standard, best practice for this (yet)? What are other people doing and their reasons? Anyone have operational experience with what works and what does not (and the "what does not" is probably really of more interest)? -- Crist J. Clark From kauer at biplane.com.au Thu Nov 1 06:02:08 2012 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 01 Nov 2012 17:02:08 +1100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <20121101053157.GD1727@don.i.pumpky.net> References: <20121101053157.GD1727@don.i.pumpky.net> Message-ID: <1351749728.3314.867.camel@karl> On Wed, 2012-10-31 at 22:31 -0700, Crist J. Clark wrote: > We're working out our dual stacked IPv4-IPv6 network. One > issue that recently has arisen is how to number the management > interfaces on the network devices themselves. > [...] > Is there anything like a standard, best practice for this (yet)? Yes and no. It's only best practice when enough people have done it, and enough people have done *different, bad* things, for the practice to emerge as, in general, best. I don't think enough people have done either of those things. There are documents floating about that purporting to describe best practice; I've never read one I really agreed with - in particular they have a tendency to recommend overloading address bits with non-address information. So I think you should listen to lots of people then go about making your own educated decisions, and thus become part of the adventure of creating best practice. Either by being a beacon of wonderfulness to us all, or by crashing and burning so that we can say, in hushed voices as we pass by where you and your network used to be, "don't do that :-) > What are other people doing and their reasons? Anyone have operational > experience with what works and what does not (and the "what does > not" is probably really of more interest)? I espouse four principles (there are others, but these are the biggies): - don't overload address bits with non-addressing information - keep the network as flat as reasonably possible - avoid tying topology to geography - avoid exceptions The first can be completely avoided and should be an ironcast rule IMHO. Aggregation requirements will mean the third is always broken eventually, and Murphy's Law will break the fourth. However, by following each rule as far as possible and delaying the point where it must be broken, you will end up with a more flexible, future-proof, error-proof, extensible address plan. I too would be really interested in whatever wisdom others have developed, even if (especially if!) it doesn't agree with mine. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From eugen at imacandi.net Thu Nov 1 11:11:17 2012 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 1 Nov 2012 13:11:17 +0200 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <20121101053157.GD1727@don.i.pumpky.net> References: <20121101053157.GD1727@don.i.pumpky.net> Message-ID: On Thu, Nov 1, 2012 at 7:31 AM, Crist J. Clark wrote: > We're working out our dual stacked IPv4-IPv6 network. One > issue that recently has arisen is how to number the management > interfaces on the network devices themselves. > > I have always been kind of partial to the idea of taking advantage > IPv6 features and letting hosts set their own addresses with EUI-64 > interface numbers. For the management interface on a network device, > it's more like a "normal" host. I'd just as well tell the device its > prefix, and let it build the address itself. For IPv6, my opinion is > that I'm not even going to try to remember 128-bit addresses. It's > not something reasonable to expect humans to do. I'm going to depend > on some name-to-number service (DNS or a hosts file), and as far as > a computer goes, 2001:db8::80:abff:fe45:6789 is just as easy to > remember as, 2001:db8::12:34. > > The other approach is to assign addresses. To me, that's more of > a hold over from IPv4 thinking, but there are legitimate reasons > I can think of. It's nice to have the IPv6 address tied to the > configuration rather than the hardware. If you need to drop in > a replacement device, you copy the configuration and no addresses > change. But OTOH, others might consider it a feature that the IP > follows the device rather than the role. And the real reason I think > people want to do it is that they want to be able to memorize IP > addresses of "important" hosts like these. For simplicity and a wish to keep a mapping to our IPv4 addresses, each device (router/server/firewall) has a static IPv6 address that has the same last digits as the IPv4 address, only the subnet is changed. You can say it's a IPv4 thinking model, but it's easier to remember that if the fileserver it's at 192.168.10.10 then it's IPv6 counterpart address would be 2001:abcd::192:168:10:10 (each subnet being a /64) > > Another option would be to do both. Assign a fixed address and also > let it chose EUI-64. However, I see that leading to confusion. Not > sure what good it would do. > > Is there anything like a standard, best practice for this (yet)? > What are other people doing and their reasons? Anyone have operational > experience with what works and what does not (and the "what does > not" is probably really of more interest)? Letting the host choose it's own IP can be very tricky and has operational hurdles along the way as it's not that easy to copy configurations across devices during upgrades and maintenance swap outs. From mohta at necom830.hpcl.titech.ac.jp Thu Nov 1 12:20:29 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 01 Nov 2012 21:20:29 +0900 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> Message-ID: <5092690D.8000500@necom830.hpcl.titech.ac.jp> Eugeniu Patrascu wrote: > You can say it's a IPv4 thinking model, but it's easier to remember > that if the fileserver it's at 192.168.10.10 then it's IPv6 > counterpart address would be 2001:abcd::192:168:10:10 (each subnet > being a /64) That is a clever idea except that it can not always follow modified EUI-64 format aof rfc4291. We should better introduce partially decimal format for IPv6 addresses or, better, avoid IPv6 entirely. Masataka Ohta > > > >> >> Another option would be to do both. Assign a fixed address and also >> let it chose EUI-64. However, I see that leading to confusion. Not >> sure what good it would do. >> >> Is there anything like a standard, best practice for this (yet)? >> What are other people doing and their reasons? Anyone have operational >> experience with what works and what does not (and the "what does >> not" is probably really of more interest)? > > Letting the host choose it's own IP can be very tricky and has > operational hurdles along the way as it's not that easy to copy > configurations across devices during upgrades and maintenance swap > outs. > > > From zgiles at gmail.com Thu Nov 1 12:37:19 2012 From: zgiles at gmail.com (Zachary Giles) Date: Thu, 1 Nov 2012 08:37:19 -0400 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <5092690D.8000500@necom830.hpcl.titech.ac.jp> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> Message-ID: Though 2001:abcd::192:168:10:10 was written in a format with both : and . , I think would could take the concept mentioned above and extend it either by making it 2001:abcd::C0:A8:0A:0A or 2001:abcd::C0A8:0A0A Doing the latter wastes less space and let's the host use the upper 32bits of the host portion for vhosts. Ex: 2001:abcd::1:C0A8:0A0A Should be easy enough as something like pxelinux already squishes your v4 address down to do file searching on tftp servers. Ex: /mybootdir/pxelinux.cfg/C000025B for 192.0.2.91 I personally have for this "use the last 32bits of the v6 address for the v4 dual stack address" trick and was happy with it. Still fits with the concept of "give each host a /64" On Thu, Nov 1, 2012 at 8:20 AM, Masataka Ohta wrote: > Eugeniu Patrascu wrote: > >> You can say it's a IPv4 thinking model, but it's easier to remember >> that if the fileserver it's at 192.168.10.10 then it's IPv6 >> counterpart address would be 2001:abcd::192:168:10:10 (each subnet >> being a /64) > > That is a clever idea except that it can not always follow > modified EUI-64 format aof rfc4291. > > We should better introduce partially decimal format for > IPv6 addresses or, better, avoid IPv6 entirely. > > Masataka Ohta >> >> >> >>> >>> Another option would be to do both. Assign a fixed address and also >>> let it chose EUI-64. However, I see that leading to confusion. Not >>> sure what good it would do. >>> >>> Is there anything like a standard, best practice for this (yet)? >>> What are other people doing and their reasons? Anyone have operational >>> experience with what works and what does not (and the "what does >>> not" is probably really of more interest)? >> >> Letting the host choose it's own IP can be very tricky and has >> operational hurdles along the way as it's not that easy to copy >> configurations across devices during upgrades and maintenance swap >> outs. >> >> >> > > -- Zach Giles zgiles at gmail.com From nick at foobar.org Thu Nov 1 13:06:29 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 01 Nov 2012 13:06:29 +0000 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <5092690D.8000500@necom830.hpcl.titech.ac.jp> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> Message-ID: <509273D5.3070503@foobar.org> On 01/11/2012 12:20, Masataka Ohta wrote: > We should better introduce partially decimal format for > IPv6 addresses or, better, avoid IPv6 entirely. No we shouldn't. Text representations of IPv6 addresses are already a complete pain to parse. We don't need to add to this pain by adding a new format which gains us nothing in particular over existing schemas such as that suggested by Eugeniu. Nick From mikevs at xs4all.net Thu Nov 1 13:28:48 2012 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Thu, 1 Nov 2012 14:28:48 +0100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> Message-ID: <201211011328.qA1DSmL0014477@xs8.xs4all.nl> In article you write: >For simplicity and a wish to keep a mapping to our IPv4 addresses, >each device (router/server/firewall) has a static IPv6 address that >has the same last digits as the IPv4 address, only the subnet is >changed. >You can say it's a IPv4 thinking model, but it's easier to remember >that if the fileserver it's at 192.168.10.10 then it's IPv6 >counterpart address would be 2001:abcd::192:168:10:10 (each subnet >being a /64) We use a /120 subnet for servers to prevent the NDP cache exhaustion attack. We do maintain a mapping between IPv4 and IPv6 addresses; it's simply 2001:db8:vv:ww::xx, where xx is the hex value of the last octet of the IPv4 address. Mike. From owen at delong.com Thu Nov 1 14:07:35 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Nov 2012 07:07:35 -0700 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <509273D5.3070503@foobar.org> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> Message-ID: On Nov 1, 2012, at 06:06 , Nick Hilliard wrote: > On 01/11/2012 12:20, Masataka Ohta wrote: >> We should better introduce partially decimal format for >> IPv6 addresses or, better, avoid IPv6 entirely. > > No we shouldn't. Text representations of IPv6 addresses are already a > complete pain to parse. We don't need to add to this pain by adding a new > format which gains us nothing in particular over existing schemas such as > that suggested by Eugeniu. > > Nick > I agree with you that we shouldn't introduce partially decimal format, but I don't see why you say IPv6 addresses are difficult to parse. 1. Tokenize (on : boundaries). 2. If n(tokens) < 8, expand null token to 9-n tokens. (result 8 total tokens). 3. Parse tokens left to right as 16 bit hex numbers, such that accumulator a accumulates each token t as follows: a<<=16 a |= t The only exceptions to this parsing would be if someone handed you a textual representation of an IPv4 mapped address (::ffff:192.0.2.50), which essentially represents the partial decimal format Masataka is requesting. You really shouldn't need to parse these and it's perfectly valid to reject them as invalid input. This really is an output only format to describe an IPv4 connection being mapped to an IPv6 socket with IPV6_V6ONLY=false in the socket options. These addresses should never appear on the wire. Internally, the software sees them as any other 128 bit integer and only the UI presentation of these numbers for display should ever use that format. That format is used as a convenience for user display because it allows the user to readily identify the IPv4 address of the connection rather than having to convert the hex to decimal to know what host is involved. Finally, at this point, if you're feeling like you have to write your own IP address parser, you're probably doing something wrong. PLEASE PLEASE PLEASE use the standard libraries whenever possible. inet_pton, getaddrinfo, etc. if you are using C. In PERL, you have these, plus Net::IP as well which provides extensive IP address parsing and manipulation capabilities. There are similar library functions for virtually every other language at this point as well. Owen From sander at steffann.nl Thu Nov 1 14:27:05 2012 From: sander at steffann.nl (Sander Steffann) Date: Thu, 1 Nov 2012 15:27:05 +0100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> Message-ID: <29A07C07-0B3B-4A1D-9AA3-A79413732E0C@steffann.nl> Hi Owen, > You really shouldn't need to parse these and it's perfectly valid to reject them as invalid input. This really is an output only format [...] I don't agree. I think it's actually the other way around. It's a valid representation of an IPv6 address so you be able to parse them. You don't need to be able to output them though. > Finally, at this point, if you're feeling like you have to write your own IP address parser, you're probably doing something wrong. PLEASE PLEASE PLEASE use the standard > libraries whenever possible. Definitely +1 here! Sander From rayw at rayw.net Thu Nov 1 14:43:01 2012 From: rayw at rayw.net (Ray Wong) Date: Thu, 1 Nov 2012 07:43:01 -0700 Subject: Anyone else suddenly getting shaped/throttled by comcast this morning? Message-ID: Looks to have started at almost exactly 8am Eastern, though in our case it's mostly west coast traffic(dst to comcast retail customers), so seems unlikely to be aftermath of storm damage, unless someone didn't look very closely at their traffic before noodling things. Still, coming up on 3 hours my outbound hasn't topped exactly a gbit, which seems a little convenient... -R> From ren.provo at gmail.com Thu Nov 1 14:51:11 2012 From: ren.provo at gmail.com (Ren Provo) Date: Thu, 1 Nov 2012 10:51:11 -0400 Subject: Anyone else suddenly getting shaped/throttled by comcast this morning? In-Reply-To: References: Message-ID: An outage in the Bay Area is being worked at present Ray. -ren On Thu, Nov 1, 2012 at 10:43 AM, Ray Wong wrote: > Looks to have started at almost exactly 8am Eastern, though in our > case it's mostly west coast traffic(dst to comcast retail customers), > so seems unlikely to be aftermath of storm damage, unless someone > didn't look very closely at their traffic before noodling things. > Still, coming up on 3 hours my outbound hasn't topped exactly a gbit, > which seems a little convenient... > > > > -R> > From jabley at hopcount.ca Thu Nov 1 14:51:49 2012 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 1 Nov 2012 10:51:49 -0400 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <29A07C07-0B3B-4A1D-9AA3-A79413732E0C@steffann.nl> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <29A07C07-0B3B-4A1D-9AA3-A79413732E0C@steffann.nl> Message-ID: <2452DE84-416B-40B3-B315-37998E3FBB8B@hopcount.ca> On 2012-11-01, at 10:27, Sander Steffann wrote: >> You really shouldn't need to parse these and it's perfectly valid to reject them as invalid input. This really is an output only format [...] > > I don't agree. I think it's actually the other way around. It's a valid representation of an IPv6 address so you be able to parse them. You don't need to be able to output them though. The active advice from the IETF on this topic would seem to be RFC 5952 as updated by RFC 5952. RFC 5952 specifies (in section 5) that the least-significant 32 bits MAY be written in dotted-quad notation if "it is known by some external method that a given prefix is used to embed IPv4". People who make use of a general-purpose v6 addressing plans which incorporate mapped v4 addresses in the lower 32 bits fit clearly into this category, I would think. 5952 is silent on the distinction between parsing such addresses and using them in output. I don't see any justification in the standards for rejecting v4-mapped addresses on input. For what that's worth. I agree that this adds a step to input validation, and that using standard libraries for this stuff is a good idea. Joe From owen at delong.com Thu Nov 1 15:10:15 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Nov 2012 08:10:15 -0700 Subject: Anyone else suddenly getting shaped/throttled by comcast this morning? In-Reply-To: References: Message-ID: <81197A73-B845-42B1-8090-FFF66475B92A@delong.com> Somewhat. I pay for 30/10. I usually get about 70/30. Currently I'm getting 33.5/7.42. This is on Business Class. Owen On Nov 1, 2012, at 07:43 , Ray Wong wrote: > Looks to have started at almost exactly 8am Eastern, though in our > case it's mostly west coast traffic(dst to comcast retail customers), > so seems unlikely to be aftermath of storm damage, unless someone > didn't look very closely at their traffic before noodling things. > Still, coming up on 3 hours my outbound hasn't topped exactly a gbit, > which seems a little convenient... > > > > -R> From chip at 2bithacker.net Thu Nov 1 17:43:14 2012 From: chip at 2bithacker.net (Chip Marshall) Date: Thu, 1 Nov 2012 13:43:14 -0400 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> Message-ID: <20121101174313.GA58868@2bithacker.net> On 01-Nov-2012, Owen DeLong sent: > The only exceptions to this parsing would be if someone handed > you a textual representation of an IPv4 mapped address > (::ffff:192.0.2.50), which essentially represents the partial > decimal format Masataka is requesting. I might be missing something here, but isn't that format already valid for any IPv6 address, not just the special v4-in-v6 representation? >>> import socket >>> p = '2001:abcd::192.16.10.10' >>> n = socket.inet_pton(socket.AF_INET6, p) >>> socket.inet_ntop(socket.AF_INET6, n) '2001:abcd::c010:a0a' Or is the issue just the ntop part not giving you back the decimalized string? -- Chip Marshall http://weblog.2bithacker.net/ KB1QYW PGP key ID 43C4819E v4sw5PUhw4/5ln5pr5FOPck4ma4u6FLOw5Xm5l5Ui2e4t4/5ARWb7HKOen6a2Xs5IMr2g6CM -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Nov 1 17:59:52 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 01 Nov 2012 13:59:52 -0400 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: Your message of "Thu, 01 Nov 2012 14:28:48 +0100." <201211011328.qA1DSmL0014477@xs8.xs4all.nl> References: <20121101053157.GD1727@don.i.pumpky.net> <201211011328.qA1DSmL0014477@xs8.xs4all.nl> Message-ID: <123376.1351792792@turing-police.cc.vt.edu> On Thu, 01 Nov 2012 14:28:48 +0100, "Miquel van Smoorenburg" said: > We use a /120 subnet for servers to prevent the NDP cache exhaustion > attack. We do maintain a mapping between IPv4 and IPv6 addresses; > it's simply 2001:db8:vv:ww::xx, where xx is the hex value of the > last octet of the IPv4 address. ooh.. that's a clever approach I hadn't seen before. Who should we credit for this one? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From owen at delong.com Thu Nov 1 19:28:05 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Nov 2012 12:28:05 -0700 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <20121101174313.GA58868@2bithacker.net> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <20121101174313.GA58868@2bithacker.net> Message-ID: <40D1D56E-1AEA-42B4-A99B-9EF0EA840636@delong.com> On Nov 1, 2012, at 10:43 , Chip Marshall wrote: > On 01-Nov-2012, Owen DeLong sent: >> The only exceptions to this parsing would be if someone handed >> you a textual representation of an IPv4 mapped address >> (::ffff:192.0.2.50), which essentially represents the partial >> decimal format Masataka is requesting. > > I might be missing something here, but isn't that format already > valid for any IPv6 address, not just the special v4-in-v6 > representation? > >>>> import socket >>>> p = '2001:abcd::192.16.10.10' >>>> n = socket.inet_pton(socket.AF_INET6, p) >>>> socket.inet_ntop(socket.AF_INET6, n) > '2001:abcd::c010:a0a' > > Or is the issue just the ntop part not giving you back the > decimalized string? That's not a problem and I certainly wouldn't expect it to do so. I guess the silly notation is more widely supported than I thought, but, IMHO, it's a kind of poor choice of syntax outside of the limited use of displaying IPv4-mapped addresses for dual-stack socket connections displaying IPv4 connections in IPv6 format. Owen From dmiller at tiggee.com Thu Nov 1 19:58:47 2012 From: dmiller at tiggee.com (David Miller) Date: Thu, 01 Nov 2012 15:58:47 -0400 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <123376.1351792792@turing-police.cc.vt.edu> References: <20121101053157.GD1727@don.i.pumpky.net> <201211011328.qA1DSmL0014477@xs8.xs4all.nl> <123376.1351792792@turing-police.cc.vt.edu> Message-ID: <5092D477.5020901@tiggee.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/1/2012 1:59 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 01 Nov 2012 14:28:48 +0100, "Miquel van Smoorenburg" said: > >> We use a /120 subnet for servers to prevent the NDP cache >> exhaustion attack. We do maintain a mapping between IPv4 and IPv6 >> addresses; it's simply 2001:db8:vv:ww::xx, where xx is the hex >> value of the last octet of the IPv4 address. > > ooh.. that's a clever approach I hadn't seen before. Who should we > credit for this one? > /120 works well until you get > 99 (if you want the decimal representations of addresses to look the same)... or if your techs understand hex. 10.0.0.123 <-> 2001:db8:vv:ww::7b I have used /116 in the past. This gives you 1-fff at the end. 10.0.0.123 <-> 2001:db8:vv:ww::123 Hopefully, this is future proof(ish) in that IPv6 only hosts (...when that happens...) on the same subnet can use 2001:db8:vv:ww::[a-f][0-f][0-f] without danger of collisions with IPv4/IPv6 hosts. - -DMM -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQktR2AAoJECp6zT7OFmGauBMH/2bntbEMqdTtwPc/kMKAeikc iHd3giEcstp/v5kaAgdZGm68Juy3jlHXVe7TZriQA3OWYI7dSzZhuVFQxwP2+t1t fsZiU1ptoSKJMnQZhUdCOSuDXQZ4IwAWyhLq1EoXNxwGWXbM+KpddfwHtfLG6syz 3RQ2BB48l+eT1fvxzd1xmyIAjOxvtsqmpLTTOmXAXtN7+e0py/VpoBvgaDfg3Xnt dnc80i2bKM+DGqZJyGbkno0lANh1iZRnUWaPethlxhgQA433Yzu06ut6Vq4zIN2k HZ84b7VbXbxrOmfiRca0vLgue/VyB6PlBevb9yVnqaHb3iWQKF0G8Mq1Ge/nm5I= =KSjA -----END PGP SIGNATURE----- From owen at delong.com Thu Nov 1 21:01:43 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Nov 2012 14:01:43 -0700 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <5092D477.5020901@tiggee.com> References: <20121101053157.GD1727@don.i.pumpky.net> <201211011328.qA1DSmL0014477@xs8.xs4all.nl> <123376.1351792792@turing-police.cc.vt.edu> <5092D477.5020901@tiggee.com> Message-ID: <963E27C7-A0C5-44AC-86AF-33E6286C9BC1@delong.com> There are better ways to avoid neighbor exhaustion attacks unless you have attackers inside your network. If you have attackers inside your network, you probably have bigger problems than neighbor table attacks anyway, but that's a different issue. Even if you're going to do something silly like use /120s on interfaces, I highly recommend going ahead and reserving the enclosing /64 so that when you discover /120 wasn't the best idea, you can easily retrofit. Owen On Nov 1, 2012, at 12:58 , David Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 11/1/2012 1:59 PM, Valdis.Kletnieks at vt.edu wrote: >> On Thu, 01 Nov 2012 14:28:48 +0100, "Miquel van Smoorenburg" said: >> >>> We use a /120 subnet for servers to prevent the NDP cache >>> exhaustion attack. We do maintain a mapping between IPv4 and IPv6 >>> addresses; it's simply 2001:db8:vv:ww::xx, where xx is the hex >>> value of the last octet of the IPv4 address. >> >> ooh.. that's a clever approach I hadn't seen before. Who should we >> credit for this one? >> > > /120 works well until you get > 99 (if you want the decimal > representations of addresses to look the same)... or if your techs > understand hex. > > 10.0.0.123 <-> 2001:db8:vv:ww::7b > > I have used /116 in the past. This gives you 1-fff at the end. > > 10.0.0.123 <-> 2001:db8:vv:ww::123 > > Hopefully, this is future proof(ish) in that IPv6 only hosts (...when > that happens...) on the same subnet can use > 2001:db8:vv:ww::[a-f][0-f][0-f] without danger of collisions with > IPv4/IPv6 hosts. > > - -DMM > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (MingW32) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQktR2AAoJECp6zT7OFmGauBMH/2bntbEMqdTtwPc/kMKAeikc > iHd3giEcstp/v5kaAgdZGm68Juy3jlHXVe7TZriQA3OWYI7dSzZhuVFQxwP2+t1t > fsZiU1ptoSKJMnQZhUdCOSuDXQZ4IwAWyhLq1EoXNxwGWXbM+KpddfwHtfLG6syz > 3RQ2BB48l+eT1fvxzd1xmyIAjOxvtsqmpLTTOmXAXtN7+e0py/VpoBvgaDfg3Xnt > dnc80i2bKM+DGqZJyGbkno0lANh1iZRnUWaPethlxhgQA433Yzu06ut6Vq4zIN2k > HZ84b7VbXbxrOmfiRca0vLgue/VyB6PlBevb9yVnqaHb3iWQKF0G8Mq1Ge/nm5I= > =KSjA > -----END PGP SIGNATURE----- From russw at riw.us Thu Nov 1 23:18:32 2012 From: russw at riw.us (Russ White) Date: Thu, 01 Nov 2012 19:18:32 -0400 Subject: IOS architecture In-Reply-To: References: Message-ID: <50930348.6090606@riw.us> A couple of thoughts: 1. The IOS specific parts of both Inside Cisco IOS Software Architecture are still pretty relevant. The RIB is now a separate process, and there are other changes, but the software architecture (of IOS specifically!) is pretty close to what's there. 2. The hardware architecture isn't current, but, IMHO, those sections are still "useful," for understanding the general way routers are laid out in terms of driver to ASIC interaction, packet receive processing, and things like that. 3. I've been talking to folks in Cisco to encourage them to write a new version. I'm busy on another project (The Art of Network Architecture), and have a couple of other ideas backed up in my mind to work on, and don't have access to the code or hardware architecture folks any longer, so it would be difficult for me. I would be glad to help anyone in cisco who wants to pull such a book together in any way I can, but I'm just not in a position to actually write an updated version of this pair of books. HTH Russ -- <>< riwhite at verisign.com russw at riw.us From mikevs at xs4all.net Thu Nov 1 23:41:28 2012 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Fri, 2 Nov 2012 00:41:28 +0100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <963E27C7-A0C5-44AC-86AF-33E6286C9BC1@delong.com> References: <20121101053157.GD1727@don.i.pumpky.net> <201211011328.qA1DSmL0014477@xs8.xs4all.nl> <123376.1351792792@turing-police.cc.vt.edu> <5092D477.5020901@tiggee.com> Message-ID: <201211012341.qA1NfSYE002648@xs8.xs4all.nl> In article you write: >There are better ways to avoid neighbor exhaustion attacks unless you >have attackers >inside your network. You mean filtering. I haven't tried it recently, but a while ago I put an output filter on a Juniper router that allowed just the lower /120 out of a /64 on an interface. What happened was that neighbor discovery happened /before/ filtering. I should probably test that against recent JunOS releases, but that was a firm reason to go with a /120 instead of a filter. Besides, configuring a /120 is way less work than a filter per interface (yes we do have per-interface filters but they're kind of generic). >Even if you're going to do something silly like use /120s on interfaces, >I highly >recommend going ahead and reserving the enclosing /64 so that when you discover >/120 wasn't the best idea, you can easily retrofit. Sure, we do that, as soon as router vendors solve the NDP CE attack problem we'll go back to /64s. Mike. From kauer at biplane.com.au Thu Nov 1 23:52:10 2012 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 02 Nov 2012 10:52:10 +1100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> Message-ID: <1351813930.3314.938.camel@karl> On Thu, 2012-11-01 at 07:07 -0700, Owen DeLong wrote: > I agree with you that we shouldn't introduce partially decimal format, but I > don't see why you say IPv6 addresses are difficult to parse. They are not simple to parse, but not particularly difficult either. > 1. Tokenize (on : boundaries). > 2. If n(tokens) < 8, expand null token to 9-n tokens. It's a bit harder than that. You need to deal with the positioning of the "::", which may be at the beginning or end. Scope identifiers need to be handled. On output, you need to handle the requirements of RFC 5952. > You really shouldn't need to parse [mapped addresses] and it's perfectly valid > to reject them as invalid input. No, it's not OK to reject them. You can't just say they are invalid, they are not. > Finally, at this point, if you're feeling like you have to write your own IP address parser, > you're probably doing something wrong. PLEASE PLEASE PLEASE use the standard > libraries whenever possible. Definitely oh very yes! That said, I have had to write my own three times now, because of errors or inadequacies in the existing parsers, and I can confidently say it is slightly tricky, but not hard. The key, the essential and vital thing, is to unit test that sucker until it is gasping and limp. > There are similar library functions for virtually every other language at this point as well. Java's is broken, for a start. I have had to replace it for literals, because it doesn't compress for output, and because it treats a mapped IPv4 address as an IPv4 address! It's also hard to do some operations on InetAddress objects. I still use InetAddress where actual names are concerned, so as not to duplicate the Java DNS functionality. Unfortunately Java appears to not properly prefer IPv6 addresses. There is allegedly a system property to control that, but it is either documented incorrectly or just doesn't work. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From gdt at gdt.id.au Fri Nov 2 03:30:44 2012 From: gdt at gdt.id.au (Glen Turner) Date: Fri, 2 Nov 2012 14:00:44 +1030 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <20121101053157.GD1727@don.i.pumpky.net> References: <20121101053157.GD1727@don.i.pumpky.net> Message-ID: <8F57CD84-A8C0-4889-A7B6-A8ECF5577A35@gdt.id.au> > > I have always been kind of partial to the idea of taking advantage > IPv6 features and letting hosts set their own addresses with EUI-64 > interface numbers. That's all fine and dandy until the NIC card is swapped out for a new one. It's best to use fixed IPv6 addresses for services (and have the service bind() to those) and use the EUI-64 address for machine-related tasks (ssh, backups, etc). You can use the same EUI-64 network for both, as the EUI-64 space is sparse and there are lots of "never will be autoconfed" address, conveniently including those with lots of zeroes. The router(s) interface addresses should be hardcoded within that EUI-64 subnet, and ?::1/64, ?::2/64 are the obvious choices. There's an issue of address exhaustion is you use /64 for router-router links, and the best suggestion I've seen there is to use /126, as that makes the last octet consistently ?1 or ?2 for each end of a point-to-point link, which is operationally nicer than stuffing about with binary in your head to determine which address to ping (i.e., you take your interface's address and replace the last hexnumeral with 1 or 2 to get your neighbours address). The exception to router link addressing would be links with eBGP neighbours, where using the ASN of the networks is just so convenient. You don't care much for correspondence between IPv4 and IPv6 addresses, except in the case of router loopback interfaces where it is very operationally convenient to be able to mentally determine "is this the same router which I just saw in IPv4". Since you'll be typing those most often they are the obvious candidate for "subnet zero" so that "::" reduces the typing to the minimum. The obvious thing to do is to reserve the entire ?:00:00:00:00::/64 and use the bottom N bits of that to match the binary IPv4 address of the loopback. N could be 32 bits if you like excessive typing or have a really big network. I've seen a few schemes which try to decimal numerals of the IPv4 address in the IPv6 address, but I don't find any of them compelling. If you really, really think you want that, then putting the top 16b in hex numerals and the lower 16b in decimal numerals will do what you want without excessive address consumption. This sounds difficult to use, but operationally you soon get used to the hex prefix and only notice when it isn't one of the common ones. -- Glen Turner From owen at delong.com Fri Nov 2 03:48:11 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Nov 2012 20:48:11 -0700 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <201211012341.qA1NfSYE002648@xs8.xs4all.nl> References: <20121101053157.GD1727@don.i.pumpky.net> <201211011328.qA1DSmL0014477@xs8.xs4all.nl> <123376.1351792792@turing-police.cc.vt.edu> <5092D477.5020901@tiggee.com> <201211012341.qA1NfSYE002648@xs8.xs4all.nl> Message-ID: On Nov 1, 2012, at 4:41 PM, "Miquel van Smoorenburg" wrote: > In article you write: >> There are better ways to avoid neighbor exhaustion attacks unless you >> have attackers >> inside your network. > > You mean filtering. I haven't tried it recently, but a while ago > I put an output filter on a Juniper router that allowed just > the lower /120 out of a /64 on an interface. What happened was that > neighbor discovery happened /before/ filtering. I should probably > test that against recent JunOS releases, but that was a firm > reason to go with a /120 instead of a filter. Besides, configuring > a /120 is way less work than a filter per interface (yes we > do have per-interface filters but they're kind of generic). > I mean assign your point to points from a particular /48 within your /32 or a particular /56 within your /48 or whatever is appropriate to your situation. Then, at your borders, filter that entire /48 or /56 or whatever it is so that people outside simply aren't allowed to send packets to your point to point links at all. >> Even if you're going to do something silly like use /120s on interfaces, >> I highly >> recommend going ahead and reserving the enclosing /64 so that when you discover >> /120 wasn't the best idea, you can easily retrofit. > > Sure, we do that, as soon as router vendors solve the NDP CE attack > problem we'll go back to /64s. > FWIW, the NDP CE attack doesn't yield much in the way of incentives to most attackers. As a DOS, it only prevents new nodes from joining the networks attached to the router and they can generally only attack the NC of the upstream router closer to them on each link, not the more distant one. Since core routers tend to have pretty stable neighbor relations, the actual attack surface in the real world is relatively small and there are far more effective DOS vectors available. Nonetheless, defense in depth is the right approach, but, do it in the way that requires the least maintenance effort on your part. Filtering an entire range of P2P links at the borders is about as low maintenance as it gets. (Again, this is assuming you don't have to deal with attackers inside your borders). If you are a university, things get more complicated because your job is to have attackers (or at least potential attackers) inside your borders. If you're not a university, then if you have attackers inside your borders, you probably have bigger problems than NDP CE. Owen From owen at delong.com Fri Nov 2 03:51:46 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Nov 2012 20:51:46 -0700 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <1351813930.3314.938.camel@karl> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> Message-ID: <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> On Nov 1, 2012, at 4:52 PM, Karl Auer wrote: > On Thu, 2012-11-01 at 07:07 -0700, Owen DeLong wrote: >> I agree with you that we shouldn't introduce partially decimal format, > but I >> don't see why you say IPv6 addresses are difficult to parse. > > They are not simple to parse, but not particularly difficult either. > >> 1. Tokenize (on : boundaries). >> 2. If n(tokens) < 8, expand null token to 9-n tokens. > > It's a bit harder than that. You need to deal with the positioning of > the "::", which may be at the beginning or end. Scope identifiers need > to be handled. On output, you need to handle the requirements of RFC > 5952. > Expanding the :: assumed expanding it in place. That's all you need to do to deal with the positioning of it. It can occur anywhere, not just at the beginning or end, as in 2620:0:930::200:2 which is, btw, also equivalent to 2620::930:0:0:0:200:2. >> You really shouldn't need to parse [mapped addresses] and it's > perfectly valid >> to reject them as invalid input. > > No, it's not OK to reject them. You can't just say they are invalid, > they are not. > Yes, it was pointed out to me that for some silly reason passing understanding, that syntax is supported. It's absurd, but supported. Sigh Probably we should deprecate it as it really doesn't make sense to use it that way. Owen From joakim at aronius.se Fri Nov 2 09:34:33 2012 From: joakim at aronius.se (Joakim Aronius) Date: Fri, 2 Nov 2012 10:34:33 +0100 Subject: Network scan tool/appliance horror stories In-Reply-To: References: <7EF4A8B03B0A3A44858C8B42E0DB236A0121BCA40E2B@PHX-52N-EXM04A.lcc.usairways.com> <20121029194646.GD13937@dan.olp.net> Message-ID: <20121102093433.GB32220@nike.aronius.se> * Jones, Barry (BEJones at semprautilities.com) wrote: > I can share with you several stories personnel (both IT or vendors), who have scanned Electric Utility environments with or without permission; and hence caused multiple failures - including electro-mechanical systems and related applications. Utilities typically utilize many industrial controllers - some of which many IT personnel have no knowledge, and some are not robust enough to weather the storm. > > 1. Know your environment. > 2. Know your tools. > 3. Communicate. > Second that. First agree on what rate they are allowed to scan your network, then let them come back with what they find before they point other tools at the found nodes. Then inform the owners of said nodes of what is going to happen. In a previous life I found an publicly available SQL server on a network belonging to a medical institution that I was pen testing. I pointed Nessus at it and it just died... BR /Joakim From tore.anderson at redpill-linpro.com Fri Nov 2 09:52:22 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 02 Nov 2012 10:52:22 +0100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> Message-ID: <509397D6.7020009@redpill-linpro.com> * Owen DeLong > Yes, it was pointed out to me that for some silly reason passing > understanding, that syntax is supported. It's absurd, but supported. > Sigh > > Probably we should deprecate it as it really doesn't make sense to > use it that way. It absolutely does make sense, especially in the case of IPv4/IPv6 translation. For example, when using NAT64, "64:ff9b::192.0.2.33" is an example of a valid IPv6 address that maps to 192.0.2.33. Much easier to relate to for a human than "64:ff9b::c000:221" is. Similarly, when using SIIT, the same syntax may be used in firewall rules or ACLs. So if you want to open, say, the SSH port from a trusted IPv4 address 192.0.2.33 on the far side of the SIIT gateway to your IPv6 server, it's much easier to open for "64:ff9b::192.0.2.33", and it will also make your ACL much more readable to the next guy that comes along than if you had used "64:ff9b::c000:221". Also see RFC 6052 section 2.4. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From egermann at limanews.com Fri Nov 2 15:13:01 2012 From: egermann at limanews.com (Eric Germann) Date: Fri, 2 Nov 2012 11:13:01 -0400 Subject: Looking for recommendation on 10G Ethernet switch Message-ID: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Colleagues, I'm looking for a recommendation on a smallish 10G Ethernet switch for a small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over iSCSI with some legacy boxes on GigE. Preferably - 8-16 10G ports - several GigE ports for legacy GigE hosts or cross connect to a legacy GigE switch - preferably not a large chassis based solution with blades The hosts aren't going to be driving full line rate, nor the SAN boxes providing full line rate, but their offered loads will definitely exceed 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing with quad GigE cards. Trying to find the best solution for > 1G on a trunk and < $50K per box. Any recommendations appreciated. Thanks EKG From lathama at gmail.com Fri Nov 2 15:18:24 2012 From: lathama at gmail.com (Andrew Latham) Date: Fri, 2 Nov 2012 11:18:24 -0400 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann wrote: > Colleagues, > > I'm looking for a recommendation on a smallish 10G Ethernet switch for a > small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over > iSCSI with some legacy boxes on GigE. > > Preferably > > - 8-16 10G ports > - several GigE ports for legacy GigE hosts or cross connect to a legacy > GigE switch > - preferably not a large chassis based solution with blades > > The hosts aren't going to be driving full line rate, nor the SAN boxes > providing full line rate, but their offered loads will definitely exceed > 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing > with quad GigE cards. Trying to find the best solution for > 1G on a > trunk and < $50K per box. > > Any recommendations appreciated. > > Thanks > > EKG This topic has been covered completely and often on the Beowulf list. http://www.beowulf.org/pipermail/beowulf/ or do a site search via your friendly search engine. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From netfortius at gmail.com Fri Nov 2 17:31:24 2012 From: netfortius at gmail.com (Stefan) Date: Fri, 2 Nov 2012 18:31:24 +0100 Subject: Dark fiber usage info request - know-how pointers and experience sharing Message-ID: Looking at dark fiber leasing as an alternative for existing ISP-acquired MPLS, MetroE, P2P, etc. services. I would appreciate some pointers (links) into specific technologies used with dark fiber, as direct consumer (not ISP). I am not looking for the theory behind (C)DWDM, but rather real life implementations and experience with folks operating such. Highly appreciated would also be extra info on what the learning curve required for traditional network engineering crew to operate devices terminating into such, and maybe even work (installation and operation) needed to maintain plants with this infrastructure. TIA, ***Stefan From eyeronic.design at gmail.com Fri Nov 2 17:58:16 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 2 Nov 2012 10:58:16 -0700 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: If you're looking at sub 50k, the Nexus 5k isn't a terrible option. It gives you 32 10Gig SFP slots for ~$25,000 or less if you don't mind used from ebay. On Fri, Nov 2, 2012 at 8:18 AM, Andrew Latham wrote: > On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann wrote: >> Colleagues, >> >> I'm looking for a recommendation on a smallish 10G Ethernet switch for a >> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over >> iSCSI with some legacy boxes on GigE. >> >> Preferably >> >> - 8-16 10G ports >> - several GigE ports for legacy GigE hosts or cross connect to a legacy >> GigE switch >> - preferably not a large chassis based solution with blades >> >> The hosts aren't going to be driving full line rate, nor the SAN boxes >> providing full line rate, but their offered loads will definitely exceed >> 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing >> with quad GigE cards. Trying to find the best solution for > 1G on a >> trunk and < $50K per box. >> >> Any recommendations appreciated. >> >> Thanks >> >> EKG > > This topic has been covered completely and often on the Beowulf list. > http://www.beowulf.org/pipermail/beowulf/ or do a site search via your > friendly search engine. > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From lathama at gmail.com Fri Nov 2 18:05:23 2012 From: lathama at gmail.com (Andrew Latham) Date: Fri, 2 Nov 2012 14:05:23 -0400 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: On Fri, Nov 2, 2012 at 1:58 PM, Mike Hale wrote: > If you're looking at sub 50k, the Nexus 5k isn't a terrible option. > It gives you 32 10Gig SFP slots for ~$25,000 or less if you don't mind > used from ebay. > > On Fri, Nov 2, 2012 at 8:18 AM, Andrew Latham wrote: >> On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann wrote: >>> Colleagues, >>> >>> I'm looking for a recommendation on a smallish 10G Ethernet switch for a >>> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over >>> iSCSI with some legacy boxes on GigE. >>> >>> Preferably >>> >>> - 8-16 10G ports >>> - several GigE ports for legacy GigE hosts or cross connect to a legacy >>> GigE switch >>> - preferably not a large chassis based solution with blades >>> >>> The hosts aren't going to be driving full line rate, nor the SAN boxes >>> providing full line rate, but their offered loads will definitely exceed >>> 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing >>> with quad GigE cards. Trying to find the best solution for > 1G on a >>> trunk and < $50K per box. >>> >>> Any recommendations appreciated. >>> >>> Thanks >>> >>> EKG >> >> This topic has been covered completely and often on the Beowulf list. >> http://www.beowulf.org/pipermail/beowulf/ or do a site search via your >> friendly search engine. >> >> -- >> ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ >> Also note that new devices hit the market everyday. For example Supermicro has an offering at http://www.supermicro.com/products/accessories/Networking/SSE-X24S.cfm which at the very least will be supported forever. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From davidpeahi at gmail.com Fri Nov 2 18:31:24 2012 From: davidpeahi at gmail.com (david peahi) Date: Fri, 2 Nov 2012 11:31:24 -0700 Subject: Dark fiber usage info request - know-how pointers and experience sharing In-Reply-To: References: Message-ID: In the USA the Federal School Lunch program has built out a parallel fiber network equal to or superior to telco fiber in many urban locations, under the E-Rate program. TheE-Rate backbone fiber is leased typically on a 10-20 year IRU basis. Sunesys is a provider of dark fiber, and their web site interfaces with Google Maps to provide detailed fiber maps where they have deployed fiber (I do not work for Sunesys, or any other dark fiber company). My own experience with dark fiber using off the shelf long reach sfps (GiGE, CWDM wavelengths with passive mux technology, h, connecting Ethernet switches from various vendors) is that dark fiber networks are extremely stable,and require little maintenance once operational. An experienced network engineer will have no trouble deploying such a network. David On Fri, Nov 2, 2012 at 10:31 AM, Stefan wrote: > Looking at dark fiber leasing as an alternative for existing ISP-acquired > MPLS, MetroE, P2P, etc. services. I would appreciate some pointers (links) > into specific technologies used with dark fiber, as direct consumer (not > ISP). I am not looking for the theory behind (C)DWDM, but rather real life > implementations and experience with folks operating such. > > Highly appreciated would also be extra info on what the learning curve > required for traditional network engineering crew to operate devices > terminating into such, and maybe even work (installation and operation) > needed to maintain plants with this infrastructure. > > TIA, > ***Stefan > From davidpeahi at gmail.com Fri Nov 2 18:37:00 2012 From: davidpeahi at gmail.com (david peahi) Date: Fri, 2 Nov 2012 11:37:00 -0700 Subject: Cisco 6509 SUP32 SNMP Meltdown With CatOS Message-ID: Anyone have experience with Cisco 6509E/SUP32 crashing under heavy SNMP polling load, causing high cpu utilization and 6509 lockup, requiring 6509 reboot? CatOS is deployed. Is the behavior any different with 6509 IOS? David From cscora at apnic.net Fri Nov 2 18:52:00 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Nov 2012 04:52:00 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201211021852.qA2Iq0ij031509@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 03 Nov, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 429394 Prefixes after maximum aggregation: 179257 Deaggregation factor: 2.40 Unique aggregates announced to Internet: 211352 Total ASes present in the Internet Routing Table: 42340 Prefixes per ASN: 10.14 Origin-only ASes present in the Internet Routing Table: 33614 Origin ASes announcing only one prefix: 15739 Transit ASes present in the Internet Routing Table: 5668 Transit-only ASes present in the Internet Routing Table: 144 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 42 Max AS path prepend of ASN ( 22394) 36 Prefixes from unregistered ASNs in the Routing Table: 928 Unregistered ASNs in the Routing Table: 334 Number of 32-bit ASNs allocated by the RIRs: 3429 Number of 32-bit ASNs visible in the Routing Table: 3058 Prefixes from 32-bit ASNs in the Routing Table: 8306 Special use prefixes present in the Routing Table: 14 Prefixes being announced from unallocated address space: 161 Number of addresses announced to Internet: 2609947628 Equivalent to 155 /8s, 144 /16s and 163 /24s Percentage of available address space announced: 70.5 Percentage of allocated address space announced: 70.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.8 Total number of prefixes smaller than registry allocations: 150664 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 103913 Total APNIC prefixes after maximum aggregation: 32578 APNIC Deaggregation factor: 3.19 Prefixes being announced from the APNIC address blocks: 104695 Unique aggregates announced from the APNIC address blocks: 43002 APNIC Region origin ASes present in the Internet Routing Table: 4787 APNIC Prefixes per ASN: 21.87 APNIC Region origin ASes announcing only one prefix: 1245 APNIC Region transit ASes present in the Internet Routing Table: 781 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 347 Number of APNIC addresses announced to Internet: 712664992 Equivalent to 42 /8s, 122 /16s and 103 /24s Percentage of available APNIC address space announced: 83.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 154569 Total ARIN prefixes after maximum aggregation: 78063 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155424 Unique aggregates announced from the ARIN address blocks: 69585 ARIN Region origin ASes present in the Internet Routing Table: 15136 ARIN Prefixes per ASN: 10.27 ARIN Region origin ASes announcing only one prefix: 5706 ARIN Region transit ASes present in the Internet Routing Table: 1599 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1087341440 Equivalent to 64 /8s, 207 /16s and 131 /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, 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: 108545 Total RIPE prefixes after maximum aggregation: 57629 RIPE Deaggregation factor: 1.88 Prefixes being announced from the RIPE address blocks: 111213 Unique aggregates announced from the RIPE address blocks: 72284 RIPE Region origin ASes present in the Internet Routing Table: 16924 RIPE Prefixes per ASN: 6.57 RIPE Region origin ASes announcing only one prefix: 8144 RIPE Region transit ASes present in the Internet Routing Table: 2745 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1985 Number of RIPE addresses announced to Internet: 648584612 Equivalent to 38 /8s, 168 /16s and 157 /24s Percentage of available RIPE address space announced: 94.3 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, 196608-199679 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: 44337 Total LACNIC prefixes after maximum aggregation: 8696 LACNIC Deaggregation factor: 5.10 Prefixes being announced from the LACNIC address blocks: 47804 Unique aggregates announced from the LACNIC address blocks: 22887 LACNIC Region origin ASes present in the Internet Routing Table: 1694 LACNIC Prefixes per ASN: 28.22 LACNIC Region origin ASes announcing only one prefix: 475 LACNIC Region transit ASes present in the Internet Routing Table: 323 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 703 Number of LACNIC addresses announced to Internet: 118410536 Equivalent to 7 /8s, 14 /16s and 205 /24s Percentage of available LACNIC address space announced: 70.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 9609 Total AfriNIC prefixes after maximum aggregation: 2238 AfriNIC Deaggregation factor: 4.29 Prefixes being announced from the AfriNIC address blocks: 10097 Unique aggregates announced from the AfriNIC address blocks: 3457 AfriNIC Region origin ASes present in the Internet Routing Table: 565 AfriNIC Prefixes per ASN: 17.87 AfriNIC Region origin ASes announcing only one prefix: 169 AfriNIC Region transit ASes present in the Internet Routing Table: 124 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 42634240 Equivalent to 2 /8s, 138 /16s and 140 /24s Percentage of available AfriNIC address space announced: 42.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2964 11558 900 Korea Telecom (KIX) 17974 2430 829 54 PT TELEKOMUNIKASI INDONESIA 7545 1801 301 88 TPG Internet Pty Ltd 4755 1618 376 159 TATA Communications formerly 9829 1407 1154 41 BSNL National Internet Backbo 9583 1189 88 507 Sify Limited 4808 1111 2056 315 CNCGROUP IP network: China169 7552 1107 1062 11 Vietel Corporation 24560 1034 385 161 Bharti Airtel Ltd., Telemedia 9498 1018 310 73 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3202 991 189 Windstream Communications Inc 6389 3169 3723 161 bellsouth.net, inc. 18566 2084 382 180 Covad Communications 22773 1971 2931 129 Cox Communications, Inc. 1785 1927 678 128 PaeTec Communications, Inc. 20115 1667 1585 628 Charter Communications 4323 1592 1153 392 Time Warner Telecom 30036 1349 272 751 Mediacom Communications Corp 7018 1261 10289 843 AT&T WorldNet Services 7011 1222 334 692 Citizens Utilities 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 1781 544 16 Corbina telecom 12479 851 776 64 Uni2 Autonomous System 34984 824 207 197 BILISIM TELEKOM 31148 726 37 9 FreeNet ISP 13188 720 93 137 Educational Network 6830 715 2313 438 UPC Distribution Services 20940 706 225 545 Akamai Technologies European 58113 601 66 364 LIR DATACENTER TELECOM SRL 8551 595 364 61 Bezeq International 3320 497 8440 407 Deutsche Telekom AG Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2243 382 204 TVCABLE BOGOTA 28573 2152 1281 63 NET Servicos de Comunicao S.A 7303 1662 1132 202 Telecom Argentina Stet-France 8151 1596 3024 356 UniNet S.A. de C.V. 6503 1538 435 67 AVANTEL, S.A. 27947 745 77 91 Telconet S.A 3816 656 309 69 Empresa Nacional de Telecomun 14420 594 90 103 CORPORACION NACIONAL DE TELEC 11172 589 85 65 Servicios Alestra S.A de C.V 7738 582 1178 33 Telecomunicacoes da Bahia 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 24863 896 275 36 LINKdotNET AS number 36998 772 48 3 MOBITEL 8452 558 958 13 TEDATA 6713 516 650 19 Itissalat Al-MAGHRIB 24835 287 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 172 697 88 MTN Network Solutions 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 7029 3202 991 189 Windstream Communications Inc 6389 3169 3723 161 bellsouth.net, inc. 4766 2964 11558 900 Korea Telecom (KIX) 17974 2430 829 54 PT TELEKOMUNIKASI INDONESIA 10620 2243 382 204 TVCABLE BOGOTA 28573 2152 1281 63 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 22773 1971 2931 129 Cox Communications, Inc. 1785 1927 678 128 PaeTec Communications, Inc. 7545 1801 301 88 TPG Internet Pty Ltd 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 3169 3008 bellsouth.net, inc. 17974 2430 2376 PT TELEKOMUNIKASI INDONESIA 28573 2152 2089 NET Servicos de Comunicao S.A 4766 2964 2064 Korea Telecom (KIX) 10620 2243 2039 TVCABLE BOGOTA 18566 2084 1904 Covad Communications 22773 1971 1842 Cox Communications, Inc. 1785 1927 1799 PaeTec Communications, Inc. 8402 1781 1765 Corbina telecom 7545 1801 1713 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 61408 UNALLOCATED 5.56.0.0/21 174 Cogent Communication 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< 128.0.160.0/21 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.220.80.0/24 38925 DAC AS Germany 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:18 /9:14 /10:29 /11:87 /12:243 /13:478 /14:850 /15:1548 /16:12449 /17:6540 /18:10885 /19:21262 /20:30632 /21:32608 /22:43083 /23:40287 /24:224132 /25:1350 /26:1695 /27:904 /28:182 /29:77 /30:16 /31:0 /32:25 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2643 3202 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1786 3169 bellsouth.net, inc. 8402 1482 1781 Corbina telecom 22773 1300 1971 Cox Communications, Inc. 30036 1266 1349 Mediacom Communications Corp 11492 1150 1185 Cable One 6503 1054 1538 AVANTEL, S.A. 1785 1017 1927 PaeTec Communications, Inc. 7011 957 1222 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:646 2:799 3:1 4:13 5:589 6:3 8:471 12:1945 13:3 14:685 15:11 16:3 17:6 20:27 23:211 24:1808 27:1393 31:1031 32:54 33:2 34:2 36:7 37:937 38:805 39:2 40:137 41:2690 42:176 44:3 46:1629 47:2 49:473 50:601 52:12 54:27 55:7 56:4 57:27 58:984 59:545 60:237 61:1291 62:949 63:1988 64:4244 65:2183 66:4469 67:2092 68:1155 69:3207 70:930 71:505 72:1874 74:2603 75:479 76:267 77:976 78:1001 79:510 80:1234 81:981 82:626 83:541 84:526 85:1154 86:495 87:941 88:358 89:1744 90:306 91:5293 92:581 93:1385 94:1700 95:1313 96:411 97:324 98:970 99:39 100:31 101:289 103:1735 105:514 106:120 107:200 108:477 109:1625 110:828 111:976 112:437 113:717 114:668 115:875 116:889 117:762 118:958 119:1222 120:361 121:694 122:1691 123:1158 124:1338 125:1276 128:578 129:199 130:276 131:644 132:310 133:142 134:252 135:61 136:228 137:244 138:336 139:176 140:491 141:294 142:493 143:377 144:497 145:82 146:526 147:273 148:725 149:327 150:159 151:206 152:452 153:183 154:21 155:433 156:226 157:365 158:286 159:670 160:333 161:414 162:367 163:191 164:710 165:448 166:515 167:559 168:1000 169:129 170:914 171:154 172:6 173:1712 174:632 175:457 176:736 177:1408 178:1623 180:1361 181:166 182:1109 183:294 184:615 185:50 186:2251 187:1396 188:1730 189:1621 190:5939 192:6029 193:5401 194:4127 195:3451 196:1231 197:249 198:3880 199:5076 200:6017 201:1968 202:8685 203:8726 204:4395 205:2530 206:2744 207:2807 208:4019 209:3597 210:2828 211:1531 212:2087 213:1839 214:881 215:75 216:5139 217:1551 218:576 219:308 220:1250 221:529 222:337 223:403 End of report From dolson at mcs.anl.gov Fri Nov 2 18:58:15 2012 From: dolson at mcs.anl.gov (Dan Olson) Date: Fri, 2 Nov 2012 13:58:15 -0500 (CDT) Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: <788955102.1129.1351882695530.JavaMail.root@zimbra-mb2.anl.gov> You may want to take a look at the Brocade VDX 6720, it provides 16 10gb ports, with 8 ports on demand with addl license. They are very reasonable, esp. if you only need 16 ports. Maintenance costs are less than cisco. ----- Original Message ----- > From: "Eric Germann" > To: nanog at nanog.org > Sent: Friday, November 2, 2012 10:13:01 AM > Subject: Looking for recommendation on 10G Ethernet switch > Colleagues, > > I'm looking for a recommendation on a smallish 10G Ethernet switch for > a > small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over > iSCSI with some legacy boxes on GigE. > > Preferably > > - 8-16 10G ports > - several GigE ports for legacy GigE hosts or cross connect to a > legacy > GigE switch > - preferably not a large chassis based solution with blades > > The hosts aren't going to be driving full line rate, nor the SAN boxes > providing full line rate, but their offered loads will definitely > exceed > 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing > with quad GigE cards. Trying to find the best solution for > 1G on a > trunk and < $50K per box. > > Any recommendations appreciated. > > Thanks > > EKG From chip.gwyn at gmail.com Fri Nov 2 18:59:01 2012 From: chip.gwyn at gmail.com (chip) Date: Fri, 2 Nov 2012 14:59:01 -0400 Subject: Dark fiber usage info request - know-how pointers and experience sharing In-Reply-To: References: Message-ID: Your people will need to come to grips with the fact that just being able to see light coming out the end of the fiber is no longer sufficient. Depending on the length you will have to deal with Chromatic Dispersion and compensation for that. People will need to understand that waves that are coming into a filter at -3 will totally blow out waves coming in at -15, especially when EDFA (amps) are concerned. DWDM (in the metro instance) is all about light levels and making sure that all waves are within 3-5db of each other as they go from site to site. Also documentation of exactly which waves are used on each part of a path and management of your waves is important, especially to the NOC when troubleshooting or determining exactly everything that's affected when a path or wave goes down. Also fiber cleanliness and proper handling becomes really important. With 850nm and SMF you can pretty much lick the end of it and it will stick work fine. When running 20 lambdas over 50km it becomes a much bigger issue. I would recommend investing in good fiber cleaning/scoping gear and proper training for your physical plant folks. Also invest in a couple of decent OSA's to check levels of all waves coming off a fiber. You don't have to drop $80k (or lots more) on gear, but you'll need something capable of determining the power of different waves at once and checking for noise. JDSU, EXFO, and Fluke make some good gear and should have options to meet just about whatever your budget is. An OTDR is nice to have but not crucial, whoever is leasing you the fiber should be able to provide OTDR shots and characterization of the paths. Normal light level checking at various points should be able to provide you enough info to determine whether its your gear or the long fiber. With fixed wave gear you can start pretty cheap and build a decent enough system. If you're making lots of moves/add/changes all the time, I'd recommend tunable optics, especially for sparing. Then move to ROADM gear if needed. For the most part if your system is fairly static once you get it up and going you don't have to touch it much, it just works. The things that then change are when fiber is cut or stretched due to weather conditions or backhoes. The gear is pretty stable. Hope that helps a little bit. Enjoy! --chip On Fri, Nov 2, 2012 at 1:31 PM, Stefan wrote: > Looking at dark fiber leasing as an alternative for existing ISP-acquired > MPLS, MetroE, P2P, etc. services. I would appreciate some pointers (links) > into specific technologies used with dark fiber, as direct consumer (not > ISP). I am not looking for the theory behind (C)DWDM, but rather real life > implementations and experience with folks operating such. > > Highly appreciated would also be extra info on what the learning curve > required for traditional network engineering crew to operate devices > terminating into such, and maybe even work (installation and operation) > needed to maintain plants with this infrastructure. > > TIA, > ***Stefan -- Just my $.02, your mileage may vary, batteries not included, etc.... From jsw at inconcepts.biz Fri Nov 2 20:10:27 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 2 Nov 2012 16:10:27 -0400 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann wrote: > I'm looking for a recommendation on a smallish 10G Ethernet switch for a > small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over > iSCSI with some legacy boxes on GigE. > 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing > with quad GigE cards. Trying to find the best solution for > 1G on a > trunk and < $50K per box. Certainly the days of doing NxGE to servers should be behind us. There are many good 10GE switch offerings. The Juniper QFX and Arista (insert one of three good product lines here) have been excellent for us. We like them for different reasons -- Arista is quite good if you want to integrate with a provisioning system; QFX is our choice when most provisioning is done manually. Both are way under $50k per box. The biggest difference between the TOR-style switches and chassis offerings, aside from the obvious, is buffers. All the TOR-type 10G switches have really small buffers and that can be a performance issue for iSCSI when utilization is high. Most of the chassis-type switches have very generous buffers so you do not run into problems with micro-bursting, etc. The vendors will all tell you about lossless ethernet, flow control, etc. and that crap sounds great on paper. Try making it actually work. You'll want those days of your life back. :) $0.02. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From mlepinski.ietf at gmail.com Thu Nov 1 03:49:29 2012 From: mlepinski.ietf at gmail.com (Matthew Lepinski) Date: Wed, 31 Oct 2012 23:49:29 -0400 Subject: IETF Nominations Committee seeks operations community input Message-ID: The IETF Nominations Committee (NomCom) is currently working to select a new Operations Area Director who will replace Ron Bonica (who is stepping down next March). Ideally, the Operations area within the IETF serves as a focal point for communication and collaboration with the network operations community. I understand that over the years the Operations area has had varying degrees of success at fostering productive discussion with the networks operations community. The IETF NomCom would greatly appreciate input from network operators to ensure that we select an Operations Area Director who best serves the needs of the community. The NomCom welcomes general feedback on issues that the NomCom should take into account in selecting an Operations Area Director, including things that the IETF Operations area could/should be doing to better interface with the network operations community. Please do not hesitate to send input/feedback by email to the NomCom at nomcom12 at ietf.org Additionally, the specific individuals that the NomCom is currently considering for the position of Operations Area Director are: -- Linda Dunbar -- Joel Jaeggli -- Melinda Shore -- Tina Tsou The NomCom welcomes any feedback specifically related to any of these individuals, and whether they are particularly well suited for the position of Operations Area Director. The IETF NomCom takes very seriously the confidentiality of any input provided to the committee (as per RFC 3777). Thank you for any help that you can provide to the IETF NomCom, - Matt Lepinski nomcom-chair at ietf.org From gary.steers at sharedband.com Fri Nov 2 20:38:17 2012 From: gary.steers at sharedband.com (Gary Steers) Date: Fri, 2 Nov 2012 20:38:17 +0000 Subject: AT&T Microcell Contact Message-ID: <41DA2F6B03CD6B4495EF33E1B275089D5F5D9F15@SBIPS-ADE-001.corp.sharedband.com> Hi All, Possibly not the best place but we have a couple of customers trying to use AT&T Microcell's (Femtocell) on our US Network and they won't We have previously had an issue on UK Networks not accepting our UK Range, we just needed to speak to the right team at the operator to get our IP Range/AS Whitelisted Does anyone on list have any contact details for AT&T's team (Feel free to reply off-list) Gary Gary Steers Chief Network Engineer | Sharedband e: gary.steers at sharedband.com -- SHAREDBAND EMAIL DISCLAIMER -- This e-mail and any attachments are confidential, are intended solely for the use of the individual to whom it is addressed and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose, or store or copy the information in any medium. Sharedband Ltd, Sharedband Technologies LLC, their affiliates, assigns or successors ("Sharedband") make no representations and give no warranties of whatever nature in respect of the email and its contents including but not limited to the accuracy or completeness of any information, facts and/or opinions contained in the email. The email is provided by Sharedband solely for the recipient's information, and all rights in and to the email including copyright and other intellectual property rights therein are proprietary to Sharedband. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Sharedband. Although this e-mail and any attachments are believed to be free from any virus or other defect which might affect any system into which they are opened or received, it is the responsibility of the recipient to check that they are virus free and that they will in no way affect systems and data. No responsibility is accepted by Sharedband for any loss or damage arising in any way from their receipt, opening or use. Shared Band Ltd T/A Sharedband Ltd Registered in England No 04861356, VAT No GB822654826 Registered Office: 40 Princes St, Ipswich, Suffolk, IP1 1RJ UK Sharedband Technologies, LLC 2033 6th Avenue, Suite 902, Seattle, WA, 98121 US From nick at foobar.org Fri Nov 2 20:52:33 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 02 Nov 2012 20:52:33 +0000 Subject: Cisco 6509 SUP32 SNMP Meltdown With CatOS In-Reply-To: References: Message-ID: <50943291.1050701@foobar.org> On 02/11/2012 18:37, david peahi wrote: > Anyone have experience with Cisco 6509E/SUP32 crashing under heavy SNMP > polling load, causing high cpu utilization and 6509 lockup, requiring 6509 > reboot? CatOS is deployed. Is the behavior any different with 6509 IOS? You're being very coy about details here. I've not managed to actually crash a 6500 running IOS by excessive snmp, but the more interesting question is: how on earth are you running so many snmp queries that this is happening? E.g. a fully loaded 6509 with 384 ports would take ~3000 queries every several minutes to perform full port diagnostic polling, and you'd want to be doing this every couple of seconds to cause serious CPU impact. Are you doing something like full DFZ or MAC table polling? Or IP accounting over snmp? If you are, there are probably better ways of achieving what you're trying to do. Also, you may want to consider moving away from CatOS, as it's now basically abandonware (or at least will formally be in Jan 2013), and hasn't even seen maintenance updates in the last 4 years. Nick From morrowc.lists at gmail.com Fri Nov 2 21:03:02 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Nov 2012 17:03:02 -0400 Subject: AT&T Microcell Contact In-Reply-To: <41DA2F6B03CD6B4495EF33E1B275089D5F5D9F15@SBIPS-ADE-001.corp.sharedband.com> References: <41DA2F6B03CD6B4495EF33E1B275089D5F5D9F15@SBIPS-ADE-001.corp.sharedband.com> Message-ID: On Fri, Nov 2, 2012 at 4:38 PM, Gary Steers wrote: > Hi All, > > Possibly not the best place but we have a couple of customers trying to use AT&T Microcell's (Femtocell) on our US Network and they won't > > We have previously had an issue on UK Networks not accepting our UK Range, we just needed to speak to the right team at the operator to get our IP Range/AS Whitelisted > it's a shame that for a service which ATT wants to charge you money to get/use/keep they won't accept packets from the internet, on a product which uses the 'internet' to get the voice packets from you to them :( at least att does the femtocell jazz? tmo won't :( > Does anyone on list have any contact details for AT&T's team (Feel free to reply off-list) > > Gary wow that disclaimer is long ... I mean ... really, very long! From mhuff at ox.com Fri Nov 2 21:10:17 2012 From: mhuff at ox.com (Matthew Huff) Date: Fri, 2 Nov 2012 17:10:17 -0400 Subject: Cisco 6509 SUP32 SNMP Meltdown With CatOS In-Reply-To: References: Message-ID: <483E6B0272B0284BA86D7596C40D29F901AAC0901E19@PUR-EXCH07.ox.com> By any chance were you querying a Sup32 that had BGP full routes? That and other large tables can easily swamp the cpu on the Sup32. This technote is based on IOS, and I don't know if the same facilities exist in CatOS, but as Nick mentioned, run, don't walk and convert to IOS. CatOS is dead. http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00800948e6.shtml -----Original Message----- From: david peahi [mailto:davidpeahi at gmail.com] Sent: Friday, November 02, 2012 2:37 PM To: nanog at nanog.org Subject: Cisco 6509 SUP32 SNMP Meltdown With CatOS Anyone have experience with Cisco 6509E/SUP32 crashing under heavy SNMP polling load, causing high cpu utilization and 6509 lockup, requiring 6509 reboot? CatOS is deployed. Is the behavior any different with 6509 IOS? David From jeffg at opennms.org Fri Nov 2 21:12:26 2012 From: jeffg at opennms.org (Jeff Gehlbach) Date: Fri, 02 Nov 2012 17:12:26 -0400 Subject: Cisco 6509 SUP32 SNMP Meltdown With CatOS In-Reply-To: <50943291.1050701@foobar.org> References: <50943291.1050701@foobar.org> Message-ID: <5094373A.6050800@opennms.org> On 11/02/2012 04:52 PM, Nick Hilliard wrote: > E.g. a fully loaded 6509 with 384 ports would take ~3000 queries every > several minutes to perform full port diagnostic polling, and you'd want to > be doing this every couple of seconds to cause serious CPU impact. Are you > doing something like full DFZ or MAC table polling? I bet you're close toward the end there. My guess is he's carrying a large BGP feed and querying the ipRouteTable. The caveat below is for IOS 12.4(20)T but equivalent issues surely exist for CatOS: http://www.cisco.com/en/US/docs/ios/12_4t/release/notes/124TCAVS3.html#wp2057950 The killer in this case is not the SNMP traffic or anything resulting directly from it, but the CPU overhead from constantly re-sorting the ipRouteTable since that's generated from the FIB when CEF is enabled. Workaround is to disable CEF (heh) or configure a MIB view that excludes the ipRouteTable. This one bites an OpenNMS support customer a few times a year -- happened again just today, in fact, at a shop that just enabled topology discovery. > Also, you may want to consider moving away from CatOS, as it's now > basically abandonware (or at least will formally be in Jan 2013), and > hasn't even seen maintenance updates in the last 4 years. What you said :) -jeff From johnl at iecc.com Fri Nov 2 21:57:42 2012 From: johnl at iecc.com (John Levine) Date: 2 Nov 2012 21:57:42 -0000 Subject: AT&T Microcell Contact In-Reply-To: <41DA2F6B03CD6B4495EF33E1B275089D5F5D9F15@SBIPS-ADE-001.corp.sharedband.com> Message-ID: <20121102215742.5323.qmail@joyce.lan> >-- SHAREDBAND EMAIL DISCLAIMER -- >This e-mail and any attachments are confidential, are intended solely for the use of the individual to >whom it is addressed and may also be privileged. If you are not the named recipient, please notify the >sender immediately and do not disclose the contents to another person, use it for any purpose, or store >or copy the information in any medium. I would suggest that people delete this mail unread to avoid unpleasant legal consequences, since none of us are "nanog at nanog.org" to which it was addressed. R's, John From cidr-report at potaroo.net Fri Nov 2 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Nov 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201211022200.qA2M00fr089323@wattle.apnic.net> This report has been generated at Fri Nov 2 21:13:07 2012 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 26-10-12 431572 249274 27-10-12 432213 249384 28-10-12 432113 249282 29-10-12 432015 248962 30-10-12 431640 248679 31-10-12 430741 248820 01-11-12 430584 248727 02-11-12 431467 249292 AS Summary 42456 Number of ASes in routing system 17666 Number of ASes announcing only one prefix 3201 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 114164704 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 02Nov12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 431785 249253 182532 42.3% All ASes AS6389 3168 168 3000 94.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2129 70 2059 96.7% NET Servicos de Comunicao S.A. AS4766 2969 941 2028 68.3% KIXS-AS-KR Korea Telecom AS17974 2430 551 1879 77.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1971 140 1831 92.9% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7029 3201 1391 1810 56.5% WINDSTREAM - Windstream Communications Inc AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS7303 1669 426 1243 74.5% Telecom Argentina S.A. AS4323 1597 399 1198 75.0% TWTC - tw telecom holdings, inc. AS10620 2243 1153 1090 48.6% Telmex Colombia S.A. AS4755 1618 531 1087 67.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1107 182 925 83.6% VIETEL-AS-AP Vietel Corporation AS8151 1611 695 916 56.9% Uninet S.A. de C.V. AS18101 1018 174 844 82.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7545 1802 1026 776 43.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS4808 1111 348 763 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 862 115 747 86.7% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS1785 1927 1212 715 37.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS855 704 53 651 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1122 498 624 55.6% LEVEL3 Level 3 Communications AS17676 709 87 622 87.7% GIGAINFRA Softbank BB Corp. AS24560 1034 434 600 58.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3549 1032 438 594 57.6% GBLX Global Crossing Ltd. AS36998 772 178 594 76.9% SDN-MOBITEL AS19262 1001 409 592 59.1% VZGNI-TRANSIT - Verizon Online LLC AS22561 1019 433 586 57.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS4780 844 286 558 66.1% SEEDNET Digital United Inc. AS22047 578 30 548 94.8% VTR BANDA ANCHA S.A. AS7011 1222 692 530 43.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS18881 578 48 530 91.7% Global Village Telecom Total 45132 13531 31601 70.0% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 41.222.82.0/24 AS37110 moztel-as 41.222.83.0/24 AS37110 moztel-as 41.222.85.0/24 AS37110 moztel-as 41.222.86.0/24 AS37110 moztel-as 41.222.87.0/24 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 65.111.16.0/20 AS26407 GUILFORD-COMMUNICATIONS - Guilford Communications, Inc. 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.8.204.0/22 AS8613 ICM-NETSERV-UK-AS ICM NetServ Ltd 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.38.164.0/23 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 202.38.166.0/23 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 Nov 2 22:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Nov 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201211022200.qA2M022B089347@wattle.apnic.net> BGP Update Report Interval: 25-Oct-12 -to- 01-Nov-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS28306 95190 3.3% 2644.2 -- TC Net Inform?tica e Telecomunica??es LTDA 2 - AS8402 55060 1.9% 26.7 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS31692 38258 1.3% 4782.2 -- SATURN-R-AS OOO Saturn-R 4 - AS9829 34381 1.2% 24.4 -- BSNL-NIB National Internet Backbone 5 - AS22561 27857 1.0% 26.9 -- DIGITAL-TELEPORT - Digital Teleport Inc. 6 - AS24560 24999 0.9% 24.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - AS13118 22668 0.8% 462.6 -- ASN-YARTELECOM OJSC Rostelecom 8 - AS1637 22256 0.8% 250.1 -- DNIC-AS-01637 - Headquarters, USAISC 9 - AS7029 21380 0.8% 6.6 -- WINDSTREAM - Windstream Communications Inc 10 - AS19361 20568 0.7% 604.9 -- Atrium Telecomunicacoes Ltda 11 - AS28573 19804 0.7% 9.1 -- NET Servicos de Comunicao S.A. 12 - AS17974 17560 0.6% 7.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS10620 16919 0.6% 7.6 -- Telmex Colombia S.A. 14 - AS6389 16633 0.6% 5.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 15 - AS4766 13330 0.5% 4.5 -- KIXS-AS-KR Korea Telecom 16 - AS27947 13256 0.5% 16.9 -- Telconet S.A 17 - AS11300 12806 0.5% 376.6 -- GLOBECOMM-11300 - Globecomm Services Maryland LLC 18 - AS5800 12797 0.5% 48.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS7552 12425 0.4% 10.8 -- VIETEL-AS-AP Vietel Corporation 20 - AS2708 11426 0.4% 83.4 -- Universidad de Guanajuato TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS24057 5461 0.2% 5461.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 2 - AS21684 5061 0.2% 5061.0 -- CYBERINETBGP - Cyberonics, Inc. 3 - AS31692 38258 1.3% 4782.2 -- SATURN-R-AS OOO Saturn-R 4 - AS28306 95190 3.3% 2644.2 -- TC Net Inform?tica e Telecomunica??es LTDA 5 - AS59706 4882 0.2% 2441.0 -- IBC-AS-TIRANA I.B.C shpk 6 - AS14680 6913 0.2% 2304.3 -- REALE-6 - Auction.com 7 - AS41674 1411 0.1% 1411.0 -- ALVARION-AS Alvarion SRL 8 - AS3 1243 0.0% 2240.0 -- CMED-AS Cmed Technology Ltd 9 - AS49888 1175 0.0% 1175.0 -- ULTRANET-AS Ultranet Sp. z o.o. 10 - AS23101 1090 0.0% 1090.0 -- PERCEPTA-GW2-AS - Percepta 11 - AS24994 1687 0.1% 843.5 -- GENESYS-AS genesys informatica srl 12 - AS50478 3955 0.1% 791.0 -- BVOX BVOX AS 13 - AS19361 20568 0.7% 604.9 -- Atrium Telecomunicacoes Ltda 14 - AS57341 602 0.0% 602.0 -- FSC-UA-AS FINANCIAL COMPANY "FINANCIAL SOLUTIONS CENTER" LTD 15 - AS25585 519 0.0% 519.0 -- KENCOMP Kencomp Internet LTD 16 - AS13118 22668 0.8% 462.6 -- ASN-YARTELECOM OJSC Rostelecom 17 - AS57201 456 0.0% 456.0 -- EDF-AS Estonian Defence Forces 18 - AS16517 420 0.0% 420.0 -- LEEPROCESS - LEE & ASSOCIATES LLC 19 - AS32529 388 0.0% 388.0 -- CGI-FEDERAL-ASN-1 - CGI Federal 20 - AS19406 4222 0.1% 383.8 -- TWRS-MA - Towerstream I, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 18988 0.6% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 184.159.130.0/23 12038 0.4% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - 122.161.0.0/16 11548 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - 184.157.224.0/19 10276 0.3% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 5 - 200.46.0.0/19 9859 0.3% AS21599 -- NETDIRECT S.A. 6 - 178.161.162.0/24 9559 0.3% AS31692 -- SATURN-R-AS OOO Saturn-R 7 - 178.161.174.0/24 9558 0.3% AS31692 -- SATURN-R-AS OOO Saturn-R 8 - 178.161.166.0/24 9558 0.3% AS31692 -- SATURN-R-AS OOO Saturn-R 9 - 178.161.163.0/24 9558 0.3% AS31692 -- SATURN-R-AS OOO Saturn-R 10 - 189.38.15.0/24 9501 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 11 - 187.94.82.0/24 9500 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 12 - 187.94.81.0/24 9500 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 13 - 189.38.5.0/24 9500 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 14 - 189.38.8.0/24 9500 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 15 - 189.38.14.0/24 9500 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 16 - 187.94.83.0/24 9500 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 17 - 189.38.9.0/24 9500 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 18 - 187.94.90.0/24 9500 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 19 - 189.38.10.0/24 9499 0.3% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 20 - 182.64.0.0/16 8946 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 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 paul4004 at gmail.com Fri Nov 2 22:03:29 2012 From: paul4004 at gmail.com (PC) Date: Fri, 2 Nov 2012 16:03:29 -0600 Subject: AT&T Microcell Contact In-Reply-To: References: <41DA2F6B03CD6B4495EF33E1B275089D5F5D9F15@SBIPS-ADE-001.corp.sharedband.com> Message-ID: I wonder why they filter by IPs anyways? The only reason I can guess is geolocation to ensure they have a frequency license in a given geographic area. However my experience has been that other providers use a GPS for this (and unfortunately, require a GPS lock to operate). Great for a house with a window, not so good for the basement of a building. On Fri, Nov 2, 2012 at 3:03 PM, Christopher Morrow wrote: > On Fri, Nov 2, 2012 at 4:38 PM, Gary Steers > wrote: > > Hi All, > > > > Possibly not the best place but we have a couple of customers trying to > use AT&T Microcell's (Femtocell) on our US Network and they won't > > > > We have previously had an issue on UK Networks not accepting our UK > Range, we just needed to speak to the right team at the operator to get our > IP Range/AS Whitelisted > > > > it's a shame that for a service which ATT wants to charge you money to > get/use/keep they won't accept packets from the internet, on a product > which uses the 'internet' to get the voice packets from you to them :( > > at least att does the femtocell jazz? tmo won't :( > > > Does anyone on list have any contact details for AT&T's team (Feel free > to reply off-list) > > > > Gary > > wow that disclaimer is long ... I mean ... really, very long! > > From nick at foobar.org Fri Nov 2 23:02:39 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 02 Nov 2012 23:02:39 +0000 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: <5094510F.1000301@foobar.org> On 02/11/2012 20:10, Jeff Wheeler wrote: > The biggest difference between the TOR-style switches and chassis > offerings, aside from the obvious, is buffers. All the TOR-type 10G > switches have really small buffers and that can be a performance issue > for iSCSI when utilization is high not particularly when utilisation is high, but in situations where congestion occurs, e.g. when you either have a high write load from multiple clients to a single server, or if you're down-shifting from a 10G server to 1G clients or something. > The vendors will all tell you about lossless ethernet, flow control, > etc. and that crap sounds great on paper. Try making it actually work. flow control on a switch port can lead to hol blocking, which is bad bad news - guaranteed to trash multi-access network performance. Some vendors actually push this as a feature. I don't completely understand why, but maybe it has something to do with customers mistakenly believing that it will make their lives better. People believe in all sorts of odd superstitions though: black cats, spilling salt, having full features on ethernet LAGs, vendor marketing blurb, fear of the number 13, etc. All very odd stuff. Nick From max at mxcrypt.com Fri Nov 2 23:30:04 2012 From: max at mxcrypt.com (Maxim Khitrov) Date: Fri, 2 Nov 2012 19:30:04 -0400 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: On Fri, Nov 2, 2012 at 4:10 PM, Jeff Wheeler wrote: > On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann wrote: >> I'm looking for a recommendation on a smallish 10G Ethernet switch for a >> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over >> iSCSI with some legacy boxes on GigE. > >> 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing >> with quad GigE cards. Trying to find the best solution for > 1G on a >> trunk and < $50K per box. > > Certainly the days of doing NxGE to servers should be behind us. > There are many good 10GE switch offerings. The Juniper QFX and Arista > (insert one of three good product lines here) have been excellent for > us. We like them for different reasons -- Arista is quite good if you > want to integrate with a provisioning system; QFX is our choice when > most provisioning is done manually. Both are way under $50k per box. > > The biggest difference between the TOR-style switches and chassis > offerings, aside from the obvious, is buffers. All the TOR-type 10G > switches have really small buffers and that can be a performance issue > for iSCSI when utilization is high. Most of the chassis-type switches > have very generous buffers so you do not run into problems with > micro-bursting, etc. The vendors will all tell you about lossless > ethernet, flow control, etc. and that crap sounds great on paper. Try > making it actually work. You'll want those days of your life back. :) I'm curious if anyone here has experience with the Extreme Summit X650 or X670 switches? I'm also currently looking for 10GBASE-T switch for my first SAN, but one with 48 ports. The price for X670V-48T seems reasonable, but I have no experience with 10 GbE over copper, so it's difficult to figure out what criteria to use (other than price) when comparing Extreme, Arista, Dell, and others. Any tips? - Max From owen at delong.com Sat Nov 3 02:30:06 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Nov 2012 19:30:06 -0700 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <509397D6.7020009@redpill-linpro.com> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> <509397D6.7020009@redpill-linpro.com> Message-ID: On Nov 2, 2012, at 02:52 , Tore Anderson wrote: > * Owen DeLong > >> Yes, it was pointed out to me that for some silly reason passing >> understanding, that syntax is supported. It's absurd, but supported. >> Sigh >> >> Probably we should deprecate it as it really doesn't make sense to >> use it that way. > > It absolutely does make sense, especially in the case of IPv4/IPv6 > translation. For example, when using NAT64, "64:ff9b::192.0.2.33" is an > example of a valid IPv6 address that maps to 192.0.2.33. Much easier to > relate to for a human than "64:ff9b::c000:221" is. > But there are two situations where you'd use that for NAT64... 1. Presentation of electronic information to the end user, where it's virtually impossible for the system to know whether that's a NAT64 address representing an IPv4 remote end or an IPv6 address, so, how do you know when to represent it that way to the end user? 2. As a destination specifier (in which case the system most likely got the address as a binary return from DNS64 and doesn't present it to the end user prior to sending the request off to the remote server and even if it did, again, doesn't likely have a way to know when to use that notation. Sure, there's the third possibility that an end-user is hand-typing an IPv6-encoded IPv4 address to go through a translator, but, I think for a variety of reasons, that behavior should be relatively strongly discouraged, no? > Similarly, when using SIIT, the same syntax may be used in firewall > rules or ACLs. So if you want to open, say, the SSH port from a trusted > IPv4 address 192.0.2.33 on the far side of the SIIT gateway to your IPv6 > server, it's much easier to open for "64:ff9b::192.0.2.33", and it will > also make your ACL much more readable to the next guy that comes along > than if you had used "64:ff9b::c000:221". SIIT is a really bad idea. Codifying it into a firewall only makes things worse. > > Also see RFC 6052 section 2.4. RFC's contain all kinds of embodiments and documentation of bad ideas that should have been deprecated long ago. Use of this notation for parsing rather than as an output-only format is just another example. Yes, once upon a time, lumping lots of V4-ness into IPv6 to try and create some impression of backwards compatibility seemed like a good idea. A couple of decades of experimentation and operational experience has now taught us that it doesn't work out as well as one might have hoped. Time to move on. Owen From lathama at gmail.com Sat Nov 3 02:53:50 2012 From: lathama at gmail.com (Andrew Latham) Date: Fri, 2 Nov 2012 22:53:50 -0400 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: <011701cdb929$51e34920$f5a9db60$@vackinc.com> References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> <011701cdb929$51e34920$f5a9db60$@vackinc.com> Message-ID: On Fri, Nov 2, 2012 at 2:38 PM, Kevin L. Karch wrote: > Andrew > > We offer several solutions that meet your initial requirements. Can you tell me if this is a multi rack deployment and a few more details? > > If you would like we could have a call with one of our applications engineers and get a budgetary quote assembled. > > Please let me know how you would like to proceed. > > Thank you, > > Kevin L. Karch > Network Specialist > > Direct: 847-833-8810 > Fax: 847-985-5550 > Email: kevinkarch at vackinc.com > Web: www.vackinc.com > The Optical Network Specialists Kevin, no thank you, I did not start this thread. If I ever need products I reach out to my contacts at each manufacturer or distributor. It would be much less embarrassing for you if the website in your signature actually finished loading the images containing the text for your company. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From don at bowenvale.co.nz Sat Nov 3 03:42:16 2012 From: don at bowenvale.co.nz (Don Gould) Date: Sat, 03 Nov 2012 16:42:16 +1300 Subject: qwest.net dropping packets... wife would like someone to pick them up please... Message-ID: <50949298.2010804@bowenvale.co.nz> Hi all, Hope you're all getting on top of Sandy. Trying to hit kajabi.com, I'm getting up to 60% packet loss off qwest.net - dca2-edge-02.inet.qwest.net A bit of quick googleing and we assumed that they're on the west coast of US, so please excuse (and just ignore me) if you're on the east coast and this is being caused by all the Sandy issues (yes I've been following the Outage list and think you guys are just doing an amazing job right now!!!) Re the subject - told the wife that her problem is likely being caused by packets being dropped by qwest, her response "can someone pick them up for me plse :)" mx.8013.yournet.co.nz (0.0.0.0) Sat Nov 3 16:43:18 2012 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 39 0.2 0.2 0.2 0.3 0.0 2. ??? 3. 218.101.61.101 0.0% 39 9.1 21.8 7.0 173.6 33.4 4. ie2-g-0-0-0.telstraclear.net 0.0% 39 38.0 22.9 19.6 38.0 3.5 5. ge-0-2-0-1.xcore1.acld.telstracl 0.0% 39 22.2 22.9 18.9 38.5 3.9 6. unknown.telstraglobal.net 0.0% 39 23.4 22.1 17.6 26.4 1.4 7. i-0-6-1-0.tlot-core01.bx.telstra 0.0% 39 153.4 153.3 151.2 163.9 2.3 8. i-4-2.eqla01.bi.telstraglobal.ne 0.0% 39 147.0 154.8 143.5 313.8 27.7 9. lap-brdr-04.inet.qwest.net 0.0% 39 154.2 154.5 152.0 159.2 1.6 10. dca2-edge-02.inet.qwest.net 10.5% 39 221.0 223.1 217.1 247.6 6.6 11. 67.133.224.194 0.0% 39 220.8 222.2 216.3 268.6 8.1 12. 72.21.220.161 0.0% 39 221.2 225.3 217.6 268.2 10.8 13. 72.21.222.139 0.0% 38 220.9 222.8 216.6 266.6 7.5 14. 216.182.224.8 0.0% 38 221.3 223.2 220.5 243.9 4.1 15. ??? D -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From contact at nullivex.com Sat Nov 3 04:35:01 2012 From: contact at nullivex.com (Bryan Tong) Date: Fri, 2 Nov 2012 22:35:01 -0600 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> <011701cdb929$51e34920$f5a9db60$@vackinc.com> Message-ID: I have used the summit x650s for cloud and they work fine for public and SAN traffic on the same switch. I have seen then as low as 7k if you can work with extreme directly. The only downside being the configuration for large VLAN amounts. Also netgear makes the xsm7224s which does everything the summit does aside from only supporting 1024 vlans. I have a pair of these and they work very well. On Friday, November 2, 2012, Andrew Latham wrote: > On Fri, Nov 2, 2012 at 2:38 PM, Kevin L. Karch > > wrote: > > Andrew > > > > We offer several solutions that meet your initial requirements. Can you > tell me if this is a multi rack deployment and a few more details? > > > > If you would like we could have a call with one of our applications > engineers and get a budgetary quote assembled. > > > > Please let me know how you would like to proceed. > > > > Thank you, > > > > Kevin L. Karch > > Network Specialist > > > > Direct: 847-833-8810 > > Fax: 847-985-5550 > > Email: kevinkarch at vackinc.com > > Web: www.vackinc.com > > The Optical Network Specialists > > Kevin, no thank you, I did not start this thread. If I ever need > products I reach out to my contacts at each manufacturer or > distributor. It would be much less embarrassing for you if the > website in your signature actually finished loading the images > containing the text for your company. > > -- > ~ Andrew "lathama" Latham lathama at gmail.com > http://lathama.net ~ > > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From mpetach at netflight.com Sat Nov 3 05:43:47 2012 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 2 Nov 2012 22:43:47 -0700 Subject: qwest.net dropping packets... wife would like someone to pick them up please... In-Reply-To: <50949298.2010804@bowenvale.co.nz> References: <50949298.2010804@bowenvale.co.nz> Message-ID: On Fri, Nov 2, 2012 at 8:42 PM, Don Gould wrote: > Hi all, > > Hope you're all getting on top of Sandy. > > Trying to hit kajabi.com, I'm getting up to 60% packet loss off qwest.net - > dca2-edge-02.inet.qwest.net > > A bit of quick googleing and we assumed that they're on the west coast of > US, so please excuse (and just ignore me) if you're on the east coast and > this is being caused by all the Sandy issues (yes I've been following the > Outage list and think you guys are just doing an amazing job right now!!!) > > Re the subject - told the wife that her problem is likely being caused by > packets being dropped by qwest, her response "can someone pick them up for > me plse :)" > > > mx.8013.yournet.co.nz (0.0.0.0) Sat Nov 3 16:43:18 > 2012 > Keys: Help Display mode Restart statistics Order of fields quit > Packets Pings > Host Loss% Snt Last Avg Best Wrst > StDev > 1. router 0.0% 39 0.2 0.2 0.2 0.3 > 0.0 > 2. ??? > 3. 218.101.61.101 0.0% 39 9.1 21.8 7.0 173.6 > 33.4 > 4. ie2-g-0-0-0.telstraclear.net 0.0% 39 38.0 22.9 19.6 38.0 > 3.5 > 5. ge-0-2-0-1.xcore1.acld.telstracl 0.0% 39 22.2 22.9 18.9 38.5 > 3.9 > 6. unknown.telstraglobal.net 0.0% 39 23.4 22.1 17.6 26.4 > 1.4 > 7. i-0-6-1-0.tlot-core01.bx.telstra 0.0% 39 153.4 153.3 151.2 163.9 > 2.3 > 8. i-4-2.eqla01.bi.telstraglobal.ne 0.0% 39 147.0 154.8 143.5 313.8 > 27.7 > 9. lap-brdr-04.inet.qwest.net 0.0% 39 154.2 154.5 152.0 159.2 > 1.6 > 10. dca2-edge-02.inet.qwest.net 10.5% 39 221.0 223.1 217.1 247.6 > 6.6 > 11. 67.133.224.194 0.0% 39 220.8 222.2 216.3 268.6 > 8.1 > 12. 72.21.220.161 0.0% 39 221.2 225.3 217.6 268.2 > 10.8 > 13. 72.21.222.139 0.0% 38 220.9 222.8 216.6 266.6 > 7.5 > 14. 216.182.224.8 0.0% 38 221.3 223.2 220.5 243.9 > 4.1 > 15. ??? > > D > -- > Don Gould > 31 Acheson Ave > Mairehau > Christchurch, New Zealand > Ph: + 64 3 348 7235 > Mobile: + 64 21 114 0699 > > Hi Don, based on your mtr output, there's no loss to the end destination; one router along the path showing loss that does not continue to affect the rest of the path simply means the cpu on that router is a bit too busy to respond to icmp messages; but there's 0% loss beyond it, which means it's doing its primary job of forwarding packets just fine. Thanks, and have a wonderful weekend! Matt From nanog at afxr.net Sat Nov 3 05:44:14 2012 From: nanog at afxr.net (Randy) Date: Sat, 03 Nov 2012 00:44:14 -0500 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <8F57CD84-A8C0-4889-A7B6-A8ECF5577A35@gdt.id.au> References: <20121101053157.GD1727@don.i.pumpky.net> <8F57CD84-A8C0-4889-A7B6-A8ECF5577A35@gdt.id.au> Message-ID: <5094AF2E.7090706@afxr.net> Veering off this topic's course, Is there any issue with addresses like this ? 2001:470:1f00:1aa:abad:babe:8:beef < I have a bunch of these type 'addresses' configured for my various machines. I make it a point to come up with some sort of 'hex' speak address, what are peoples opinions on this? From don at bowenvale.co.nz Sat Nov 3 05:55:39 2012 From: don at bowenvale.co.nz (Don Gould) Date: Sat, 03 Nov 2012 18:55:39 +1300 Subject: qwest.net dropping packets... wife would like someone to pick them up please... In-Reply-To: References: <50949298.2010804@bowenvale.co.nz> Message-ID: <5094B1DB.5000400@bowenvale.co.nz> Hi Matt (and other helpful posters off list), Yes, makes sense. I'm told this pops up twice a month, so opps, clearly I need to spend more time reading and learning! :) Thanks to the person who pointed out the PTR rec suggests that the impacted resource might be more west than I realised. I confess I don't know the .us very well at all. D On 3/11/2012 6:43 p.m., Matthew Petach wrote: > Hi Don, based on your mtr output, there's no loss to the end > destination; one router along the path showing loss that does not > continue to affect the rest of the path simply means the cpu on that > router is a bit too busy to respond to icmp messages; but there's 0% > loss beyond it, which means it's doing its primary job of forwarding > packets just fine. Thanks, and have a wonderful weekend! Matt -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From graham at apolix.co.za Sat Nov 3 06:07:52 2012 From: graham at apolix.co.za (Graham Beneke) Date: Sat, 03 Nov 2012 08:07:52 +0200 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <5094AF2E.7090706@afxr.net> References: <20121101053157.GD1727@don.i.pumpky.net> <8F57CD84-A8C0-4889-A7B6-A8ECF5577A35@gdt.id.au> <5094AF2E.7090706@afxr.net> Message-ID: <5094B4B8.3090002@apolix.co.za> On 03/11/2012 07:44, Randy wrote: > Veering off this topic's course, Is there any issue with addresses like > this ? > 2001:470:1f00:1aa:abad:babe:8:beef < I have a bunch of these type > 'addresses' configured for my various machines. > > I make it a point to come up with some sort of 'hex' speak address, what > are peoples opinions on this? Why bother? DNS supports all 26 characters ;-) Its cute... but it tends to only be useful in fairly small deployments. You quickly run out of nice combinations. I prefer to choose addresses that allow for the most consecutive zeros. Many UIs I've used display IPv6 address strings in very un-useful ways as they approach the allowable length of 39 characters. Many require you to resize your viewing window/column/etc to see the full address and some simply truncate the string and refuse to show you the host ID portion. -- Graham Beneke From kauer at biplane.com.au Sat Nov 3 06:28:37 2012 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 03 Nov 2012 17:28:37 +1100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <5094AF2E.7090706@afxr.net> References: <20121101053157.GD1727@don.i.pumpky.net> <8F57CD84-A8C0-4889-A7B6-A8ECF5577A35@gdt.id.au> <5094AF2E.7090706@afxr.net> Message-ID: <1351924117.2935.35.camel@karl> On Sat, 2012-11-03 at 00:44 -0500, Randy wrote: > Veering off this topic's course, Is there any issue with addresses like > this ? > 2001:470:1f00:1aa:abad:babe:8:beef < I have a bunch of these type > 'addresses' configured for my various machines. > > I make it a point to come up with some sort of 'hex' speak address, what > are peoples opinions on this? I tell my students to avoid them. For several reasons: - if you need to remember an IP address, you are doing it wrong - limiting yourself to "word space" wastes "address space". Possibly acceptable in interface IDs, foolish in subnetting bits. - if people expect something, they will type it, possibly instead of what's actually needed. By making them expect words, you introduce a source of error. - cultural sensitivity and plain good sense suggest that many words or combinations might not be a good idea. How do your female techs feel about "BAD:BABE"? Only marginally better than they feel about "B16:B00B:EEZ", probably. Your markets in India, with its 900 million Hindus, might take a dim view of "DEAD:BEEF". Etc. - clever addresses are guessable addresses for scanners, and highly identifiable in data as probably attached to high-value targets - something that is witty once is generally irritating the thousandth time you see it. Doubly so if it wasn't very funny to begin with. - the time you spend trying to find something "meaningful" is basically wasted, and the time you spend will increase exponentially once you've used all the low-hanging fruit. All in all, using such addresses is probably a Bad Idea. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From randy at psg.com Sat Nov 3 07:07:29 2012 From: randy at psg.com (Randy Bush) Date: Sat, 03 Nov 2012 16:07:29 +0900 Subject: qwest.net dropping packets... wife would like someone to pick them up please... In-Reply-To: References: <50949298.2010804@bowenvale.co.nz> Message-ID: > one router along the path showing loss that does not continue to > affect the rest of the path simply means the cpu on that router > is a bit too busy to respond to icmp messages trivial footnote: some folk configure some routers to rate limit icmp randy From tore.anderson at redpill-linpro.com Sat Nov 3 11:19:18 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sat, 03 Nov 2012 12:19:18 +0100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> <509397D6.7020009@redpill-linpro.com> Message-ID: <5094FDB6.2000905@redpill-linpro.com> * Owen DeLong > On Nov 2, 2012, at 02:52 , Tore Anderson > wrote: > >> It absolutely does make sense, especially in the case of IPv4/IPv6 >> translation. For example, when using NAT64, "64:ff9b::192.0.2.33" >> is an example of a valid IPv6 address that maps to 192.0.2.33. >> Much easier to relate to for a human than "64:ff9b::c000:221" is. > > But there are two situations where you'd use that for NAT64... > > 1. Presentation of electronic information to the end user, where > it's virtually impossible for the system to know whether that's a > NAT64 address representing an IPv4 remote end or an IPv6 address, so, > how do you know when to represent it that way to the end user? > > 2. As a destination specifier (in which case the system most likely > got the address as a binary return from DNS64 and doesn't present it > to the end user prior to sending the request off to the remote > server and even if it did, again, doesn't likely have a way to know > when to use that notation. There's also the case of when including NAT64 support directly into an application. Not all applications use DNS, and therefore cannot use DNS64 either, e.g., applications that are passing around IP literals in their payload (p2p stuff like BitTorrent and Skype comes to mind). However, by discovering the NAT64 prefix in some other way (see draft-ietf-behave-nat64-discovery-heuristic), they can construct a usable destination specifier by simple string concatenation. It's wouldn't be the only way to do it, but it's certainly simple and easy to understand approach. > Sure, there's the third possibility that an end-user is hand-typing > an IPv6-encoded IPv4 address to go through a translator, but, I > think for a variety of reasons, that behavior should be relatively > strongly discouraged, no? That wouldn't be a end-user friendly application, no. However, for network operators, dealing with IP literals is common when debugging or other stuff. I frequently use the dotted quad syntax when working on our NAT64 installation, and find it very convenient. >> Similarly, when using SIIT, the same syntax may be used in firewall >> rules or ACLs. So if you want to open, say, the SSH port from a >> trusted IPv4 address 192.0.2.33 on the far side of the SIIT gateway >> to your IPv6 server, it's much easier to open for >> "64:ff9b::192.0.2.33", and it will also make your ACL much more >> readable to the next guy that comes along than if you had used >> "64:ff9b::c000:221". > > SIIT is a really bad idea. I disagree. In my opinion, SIIT is perfectly suited for data centres. But let's not take that discussion here - I'll be submitting a draft about the use case to the IETF in a few days, and I hope you'll read it and participate in the discussion on the v6ops or sunset4 list (not yet sure which one it'll be). >> Also see RFC 6052 section 2.4. > > RFC's contain all kinds of embodiments and documentation of bad > ideas that should have been deprecated long ago. Certainly. There is, however, a mechanism for deprecating RFCs. Either you can move them to Historic status, or you can obsolete them by writing new ones. You, or anyone else who don't like the ::0.0.0.0 syntax, is free to do so. Until that happens, though, it will remain part of the standard and you cannot reject it out of hand just because you don't like it. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From netfortius at gmail.com Sat Nov 3 12:54:41 2012 From: netfortius at gmail.com (Stefan) Date: Sat, 3 Nov 2012 13:54:41 +0100 Subject: Dark fiber usage info request - know-how pointers and experience sharing In-Reply-To: References: Message-ID: Thank you all who answered. I got a few good leads to follow, and information on operation gotchas. ***Stefan From owen at delong.com Sat Nov 3 16:48:24 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 3 Nov 2012 09:48:24 -0700 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <5094FDB6.2000905@redpill-linpro.com> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> <509397D6.7020009@redpill-linpro.com> <5094FDB6.2000905@redpill-linpro.com> Message-ID: <1AD89D5D-D9E2-4531-B8E5-A76DCD633F44@delong.com> On Nov 3, 2012, at 04:19 , Tore Anderson wrote: > * Owen DeLong > >> On Nov 2, 2012, at 02:52 , Tore Anderson >> wrote: >> >>> It absolutely does make sense, especially in the case of IPv4/IPv6 >>> translation. For example, when using NAT64, "64:ff9b::192.0.2.33" >>> is an example of a valid IPv6 address that maps to 192.0.2.33. >>> Much easier to relate to for a human than "64:ff9b::c000:221" is. >> >> But there are two situations where you'd use that for NAT64... >> >> 1. Presentation of electronic information to the end user, where >> it's virtually impossible for the system to know whether that's a >> NAT64 address representing an IPv4 remote end or an IPv6 address, so, >> how do you know when to represent it that way to the end user? >> >> 2. As a destination specifier (in which case the system most likely >> got the address as a binary return from DNS64 and doesn't present it >> to the end user prior to sending the request off to the remote >> server and even if it did, again, doesn't likely have a way to know >> when to use that notation. > > There's also the case of when including NAT64 support directly into an > application. Not all applications use DNS, and therefore cannot use > DNS64 either, e.g., applications that are passing around IP literals in > their payload (p2p stuff like BitTorrent and Skype comes to mind). > However, by discovering the NAT64 prefix in some other way (see > draft-ietf-behave-nat64-discovery-heuristic), they can construct a > usable destination specifier by simple string concatenation. It's > wouldn't be the only way to do it, but it's certainly simple and easy to > understand approach. > But if the application is doing the construction, then it's doing it with binary and not with a string representation of the address. The binary 128 bits don't change. We're talking about the format of a string representing those 128 bit. >> Sure, there's the third possibility that an end-user is hand-typing >> an IPv6-encoded IPv4 address to go through a translator, but, I >> think for a variety of reasons, that behavior should be relatively >> strongly discouraged, no? > > That wouldn't be a end-user friendly application, no. However, for > network operators, dealing with IP literals is common when debugging or > other stuff. I frequently use the dotted quad syntax when working on our > NAT64 installation, and find it very convenient. > Fair point. >>> Similarly, when using SIIT, the same syntax may be used in firewall >>> rules or ACLs. So if you want to open, say, the SSH port from a >>> trusted IPv4 address 192.0.2.33 on the far side of the SIIT gateway >>> to your IPv6 server, it's much easier to open for >>> "64:ff9b::192.0.2.33", and it will also make your ACL much more >>> readable to the next guy that comes along than if you had used >>> "64:ff9b::c000:221". >> >> SIIT is a really bad idea. > > I disagree. In my opinion, SIIT is perfectly suited for data centres. > But let's not take that discussion here - I'll be submitting a draft > about the use case to the IETF in a few days, and I hope you'll read it > and participate in the discussion on the v6ops or sunset4 list (not yet > sure which one it'll be). What do you get from SIIT that you don't get from dual stack in a datacenter? > >>> Also see RFC 6052 section 2.4. >> >> RFC's contain all kinds of embodiments and documentation of bad >> ideas that should have been deprecated long ago. > > Certainly. There is, however, a mechanism for deprecating RFCs. Either > you can move them to Historic status, or you can obsolete them by > writing new ones. You, or anyone else who don't like the ::0.0.0.0 > syntax, is free to do so. Until that happens, though, it will remain > part of the standard and you cannot reject it out of hand just because > you don't like it. Fair point, however, I can certainly discourage its use. Frankly, lots of stuff from RFCs gets rejected out of hand by various implementers all the time. Owen From joelja at bogus.com Sat Nov 3 18:43:43 2012 From: joelja at bogus.com (joel jaeggli) Date: Sat, 03 Nov 2012 14:43:43 -0400 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <963E27C7-A0C5-44AC-86AF-33E6286C9BC1@delong.com> References: <20121101053157.GD1727@don.i.pumpky.net> <201211011328.qA1DSmL0014477@xs8.xs4all.nl> <123376.1351792792@turing-police.cc.vt.edu> <5092D477.5020901@tiggee.com> <963E27C7-A0C5-44AC-86AF-33E6286C9BC1@delong.com> Message-ID: <509565DF.8040402@bogus.com> On 11/1/12 2:01 PM, Owen DeLong wrote: > There are better ways to avoid neighbor exhaustion attacks unless you have attackers > inside your network. All of the migrations are compromises of one sort or another. We thought this one was important enough to include in an informational status RFC (6583). Which approach is most appropriate (and whether it's necessary at all) will depend on the circumstances involved. > If you have attackers inside your network, you probably have bigger problems than > neighbor table attacks anyway, but that's a different issue. > > Even if you're going to do something silly like use /120s on interfaces, I highly > recommend going ahead and reserving the enclosing /64 so that when you discover > /120 wasn't the best idea, you can easily retrofit. The problem isn't silly, I didn't find it all that funny when I first induced it in the lab. > Owen > > On Nov 1, 2012, at 12:58 , David Miller wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> On 11/1/2012 1:59 PM, Valdis.Kletnieks at vt.edu wrote: >>> On Thu, 01 Nov 2012 14:28:48 +0100, "Miquel van Smoorenburg" said: >>> >>>> We use a /120 subnet for servers to prevent the NDP cache >>>> exhaustion attack. We do maintain a mapping between IPv4 and IPv6 >>>> addresses; it's simply 2001:db8:vv:ww::xx, where xx is the hex >>>> value of the last octet of the IPv4 address. >>> ooh.. that's a clever approach I hadn't seen before. Who should we >>> credit for this one? >>> >> /120 works well until you get > 99 (if you want the decimal >> representations of addresses to look the same)... or if your techs >> understand hex. >> >> 10.0.0.123 <-> 2001:db8:vv:ww::7b >> >> I have used /116 in the past. This gives you 1-fff at the end. >> >> 10.0.0.123 <-> 2001:db8:vv:ww::123 >> >> Hopefully, this is future proof(ish) in that IPv6 only hosts (...when >> that happens...) on the same subnet can use >> 2001:db8:vv:ww::[a-f][0-f][0-f] without danger of collisions with >> IPv4/IPv6 hosts. >> >> - -DMM >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.17 (MingW32) >> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJQktR2AAoJECp6zT7OFmGauBMH/2bntbEMqdTtwPc/kMKAeikc >> iHd3giEcstp/v5kaAgdZGm68Juy3jlHXVe7TZriQA3OWYI7dSzZhuVFQxwP2+t1t >> fsZiU1ptoSKJMnQZhUdCOSuDXQZ4IwAWyhLq1EoXNxwGWXbM+KpddfwHtfLG6syz >> 3RQ2BB48l+eT1fvxzd1xmyIAjOxvtsqmpLTTOmXAXtN7+e0py/VpoBvgaDfg3Xnt >> dnc80i2bKM+DGqZJyGbkno0lANh1iZRnUWaPethlxhgQA433Yzu06ut6Vq4zIN2k >> HZ84b7VbXbxrOmfiRca0vLgue/VyB6PlBevb9yVnqaHb3iWQKF0G8Mq1Ge/nm5I= >> =KSjA >> -----END PGP SIGNATURE----- > > From fred at cisco.com Sat Nov 3 20:44:19 2012 From: fred at cisco.com (Fred Baker (fred)) Date: Sat, 3 Nov 2012 20:44:19 +0000 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <5092690D.8000500@necom830.hpcl.titech.ac.jp> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> Message-ID: <8C48B86A895913448548E6D15DA7553B193890@xmb-rcd-x09.cisco.com> On Nov 1, 2012, at 8:20 AM, Masataka Ohta wrote: > We should better introduce partially decimal format for > IPv6 addresses or, better, avoid IPv6 entirely. With respect, it is already possible to use the decimal subset if you wish. For example, you could write 2001:dba::192:168:2:1 It wouldn't be very dense, but EID density wasn't the objective. From morrowc.lists at gmail.com Sun Nov 4 02:04:47 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 3 Nov 2012 22:04:47 -0400 Subject: qwest.net dropping packets... wife would like someone to pick them up please... In-Reply-To: References: <50949298.2010804@bowenvale.co.nz> Message-ID: On Sat, Nov 3, 2012 at 3:07 AM, Randy Bush wrote: >> one router along the path showing loss that does not continue to >> affect the rest of the path simply means the cpu on that router >> is a bit too busy to respond to icmp messages > > trivial footnote: some folk configure some routers to rate limit > icmp other trivial footnote, not all traceroute is icmp. From randy_94108 at yahoo.com Sun Nov 4 05:10:18 2012 From: randy_94108 at yahoo.com (Randy) Date: Sat, 3 Nov 2012 22:10:18 -0700 (PDT) Subject: qwest.net dropping packets... wife would like someone to pick them up please... In-Reply-To: Message-ID: <1352005818.275.YahooMailClassic@web184702.mail.ne1.yahoo.com> --- On Sat, 11/3/12, Christopher Morrow wrote: > From: Christopher Morrow > Subject: Re: qwest.net dropping packets... wife would like someone to pick them up please... > To: "Randy Bush" > Cc: "North American Network Operators' Group" > Date: Saturday, November 3, 2012, 7:04 PM > On Sat, Nov 3, 2012 at 3:07 AM, Randy > Bush > wrote: > >> one router along the path showing loss that does > not continue to > >> affect the rest of the path simply means the cpu on > that router > >> is a bit too busy to respond to icmp messages > > > > trivial footnote: some folk configure some routers to > rate limit > > icmp > > other trivial footnote, not all traceroute is icmp. > True, wrt to destination. However all intermediate(including penultimate) hops reveal themselves via ICMP type 11 Code 0 (TTL exceeded in transit) ./Randy From paul4004 at gmail.com Sun Nov 4 06:12:20 2012 From: paul4004 at gmail.com (PC) Date: Sun, 4 Nov 2012 00:12:20 -0600 Subject: qwest.net dropping packets... wife would like someone to pick them up please... In-Reply-To: <1352005818.275.YahooMailClassic@web184702.mail.ne1.yahoo.com> References: <1352005818.275.YahooMailClassic@web184702.mail.ne1.yahoo.com> Message-ID: For some more information, this previous document and presentation make good resources: Document: http://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf There's also a presentation here: http://www.nanog.org/meetings/nanog45/presentations/Interpret_traceroutes.wmv On Sat, Nov 3, 2012 at 11:10 PM, Randy wrote: > --- On Sat, 11/3/12, Christopher Morrow wrote: > > > From: Christopher Morrow > > Subject: Re: qwest.net dropping packets... wife would like someone to > pick them up please... > > To: "Randy Bush" > > Cc: "North American Network Operators' Group" > > Date: Saturday, November 3, 2012, 7:04 PM > > On Sat, Nov 3, 2012 at 3:07 AM, Randy > > Bush > > wrote: > > >> one router along the path showing loss that does > > not continue to > > >> affect the rest of the path simply means the cpu on > > that router > > >> is a bit too busy to respond to icmp messages > > > > > > trivial footnote: some folk configure some routers to > > rate limit > > > icmp > > > > other trivial footnote, not all traceroute is icmp. > > > True, wrt to destination. However all intermediate(including penultimate) > hops reveal themselves via ICMP type 11 Code 0 (TTL exceeded in transit) > ./Randy > > > From tore.anderson at redpill-linpro.com Sun Nov 4 09:55:44 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sun, 04 Nov 2012 10:55:44 +0100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <1AD89D5D-D9E2-4531-B8E5-A76DCD633F44@delong.com> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> <509397D6.7020009@redpill-linpro.com> <5094FDB6.2000905@redpill-linpro.com> <1AD89D5D-D9E2-4531-B8E5-A76DCD633F44@delong.com> Message-ID: <50963BA0.2060407@redpill-linpro.com> * Owen DeLong > What do you get from SIIT that you don't get from dual stack in a > datacenter? In no particular order: - Single stack is much simpler than dual stack. A single stack to configure, a single ACL to write, a single service address to monitor, staff needs to know only a single protocol, deveopment staff needs only develop and do QA for a single protocol, it's a single topology to document, a single IGP to run and monitor, a single protocol to debug and troubleshoot, one less attack vector for the bad guys, and so on. I have a strong feeling that the reason why dual stack failed so miserably as a transition mechanism was precisely because of the fact that it adds significant complexity and operational overhead, compared to single stack. - IPv4 address conservation. If you're running out of IPv4 addresses, you cannot use dual stack, as dual stack does nothing to reduce your dependency on IPv4 compared to single stack IPv4. With dual stack, you'll be using (at least) one IPv4 address per server, plus a bit of overhead due to the server LAN prefixes needing to be rounded up to the nearest power or two (or higher if you want to accommodate for future growth), plus overhead due to the network infrastructure. With SIIT, on the other hand, you'll be using a single IPv4 address per publicly available service - one /32 out of a pool, with nothing going to waste due to aggregation, network infrastructure, and so on. - Promotes first-class native IPv6 deployment. Not that dual stack isn't native IPv6 too, but I do have the impression that often, IPv6 in a dual stacked environment is a second class citizen. IPv6 might be only partially deployed, not monitored as well as IPv4, or that there are architectural dependencies on IPv4 in the application stack, so that you cannot just shut off IPv4 and expect it to continue to work fine on IPv6 only. With SIIT, you get only a single, first-class, citizen - IPv6. And it'll be the only IPv6 migration/transition/deployment project you'll ever have to do. When the time comes to discontinue support for IPv4, you just remove your IN A records and shut down the SIIT gateway(s), there will be no need to touch the application stack at all. As I said earlier, I will submit an IETF draft about the use case shortly (it seems that the upload page is closed right now, due to the upcoming IETF meeting), and I invite you to participate in the discussion - hopefully, we can work together to address your technical concerns with the solution. I did present the use case at RIPE64, by the way - I hope you will find these links interesting: https://ripe64.ripe.net/archives/video/37 https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From outsider at scarynet.org Sun Nov 4 10:42:34 2012 From: outsider at scarynet.org (Alexander Maassen) Date: Sun, 04 Nov 2012 11:42:34 +0100 Subject: mail-abuse.org down? In-Reply-To: <2452DE84-416B-40B3-B315-37998E3FBB8B@hopcount.ca> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <29A07C07-0B3B-4A1D-9AA3-A79413732E0C@steffann.nl> <2452DE84-416B-40B3-B315-37998E3FBB8B@hopcount.ca> Message-ID: <1352025754.2312.7.camel@outsider.laptop> Looks like it's down again.... From ge0-1-v201.r2.mst1.proxility.net (77.93.64.146) icmp_seq=1 Destination Host Unreachable Now that could be through a filter... however: --2012-11-04 11:07:25-- http://www.mail-abuse.org/ Resolving www.mail-abuse.org... 150.70.74.99 Connecting to www.mail-abuse.org|150.70.74.99|:80... failed: No route to host. trace itself ends at my own providers gateway... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From ops.lists at gmail.com Sun Nov 4 10:47:25 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 4 Nov 2012 16:17:25 +0530 Subject: mail-abuse.org down? In-Reply-To: <1352025754.2312.7.camel@outsider.laptop> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <29A07C07-0B3B-4A1D-9AA3-A79413732E0C@steffann.nl> <2452DE84-416B-40B3-B315-37998E3FBB8B@hopcount.ca> <1352025754.2312.7.camel@outsider.laptop> Message-ID: Maps was taken over by trend micro years back, maybe they just retired the old domain? --srs (htc one x) On Nov 4, 2012 4:14 PM, "Alexander Maassen" wrote: > Looks like it's down again.... > > From ge0-1-v201.r2.mst1.proxility.net (77.93.64.146) icmp_seq=1 > Destination Host Unreachable > > Now that could be through a filter... however: > > --2012-11-04 11:07:25-- http://www.mail-abuse.org/ > Resolving www.mail-abuse.org... 150.70.74.99 > Connecting to www.mail-abuse.org|150.70.74.99|:80... failed: No route to > host. > > > trace itself ends at my own providers gateway... > From owen at delong.com Sun Nov 4 12:24:46 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 4 Nov 2012 04:24:46 -0800 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <50963BA0.2060407@redpill-linpro.com> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> <509397D6.7020009@redpill-linpro.com> <5094FDB6.2000905@redpill-linpro.com> <1AD89D5D-D9E2-4531-B8E5-A76DCD633F44@delong.com> <50963BA0.2060407@redpill-linpro.com> Message-ID: On Nov 4, 2012, at 1:55 AM, Tore Anderson wrote: > * Owen DeLong > >> What do you get from SIIT that you don't get from dual stack in a >> datacenter? > > In no particular order: > > - Single stack is much simpler than dual stack. A single stack to > configure, a single ACL to write, a single service address to monitor, > staff needs to know only a single protocol, deveopment staff needs only > develop and do QA for a single protocol, it's a single topology to > document, a single IGP to run and monitor, a single protocol to debug > and troubleshoot, one less attack vector for the bad guys, and so on. I > have a strong feeling that the reason why dual stack failed so miserably > as a transition mechanism was precisely because of the fact that it adds > significant complexity and operational overhead, compared to single stack. > Except that with SIIT, you're still dealing with two stacks, just moving the place where you deal with them around a bit. Further, you're adding the complication of NAT into your world (SIIT is a form of NAT whether you care to admit that to yourself or not). > - IPv4 address conservation. If you're running out of IPv4 addresses, > you cannot use dual stack, as dual stack does nothing to reduce your > dependency on IPv4 compared to single stack IPv4. With dual stack, > you'll be using (at least) one IPv4 address per server, plus a bit of > overhead due to the server LAN prefixes needing to be rounded up to the > nearest power or two (or higher if you want to accommodate for future > growth), plus overhead due to the network infrastructure. With SIIT, on > the other hand, you'll be using a single IPv4 address per publicly > available service - one /32 out of a pool, with nothing going to waste > due to aggregation, network infrastructure, and so on. Since you end up dealing with NAT anyway, why not just use NAT for IPv4 conservation. It's what most engineers are already used to dealing with and you don't lose anything between it and SIIT. Further, for SIIT to work, you don't really conserve any IPv4 addresses, since address conservation requires state. > > - Promotes first-class native IPv6 deployment. Not that dual stack isn't > native IPv6 too, but I do have the impression that often, IPv6 in a dual > stacked environment is a second class citizen. IPv6 might be only > partially deployed, not monitored as well as IPv4, or that there are > architectural dependencies on IPv4 in the application stack, so that you > cannot just shut off IPv4 and expect it to continue to work fine on IPv6 > only. With SIIT, you get only a single, first-class, citizen - IPv6. And > it'll be the only IPv6 migration/transition/deployment project you'll > ever have to do. When the time comes to discontinue support for IPv4, > you just remove your IN A records and shut down the SIIT gateway(s), > there will be no need to touch the application stack at all. Treating IPv6 as a second class citizen is a choice, not an inherent consequence of dual-stack. IPv6 certainly isn't a second class citizen on my network or on Hurricane Electric's network. > As I said earlier, I will submit an IETF draft about the use case > shortly (it seems that the upload page is closed right now, due to the > upcoming IETF meeting), and I invite you to participate in the > discussion - hopefully, we can work together to address your technical > concerns with the solution. I'll look forward to reading the draft. > I did present the use case at RIPE64, by the way - I hope you will find > these links interesting: > > https://ripe64.ripe.net/archives/video/37 > https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf I'll try to look them over when I get some time. Owen From tore.anderson at redpill-linpro.com Sun Nov 4 13:15:28 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sun, 04 Nov 2012 14:15:28 +0100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> <509397D6.7020009@redpill-linpro.com> <5094FDB6.2000905@redpill-linpro.com> <1AD89D5D-D9E2-4531-B8E5-A76DCD633F44@delong.com> <50963BA0.2060407@redpill-linpro.com> Message-ID: <50966A70.1050705@redpill-linpro.com> * Owen DeLong > On Nov 4, 2012, at 1:55 AM, Tore Anderson > wrote: > >> * Owen DeLong >> >>> What do you get from SIIT that you don't get from dual stack in a >>> datacenter? >> >> In no particular order: >> >> - Single stack is much simpler than dual stack. A single stack to >> configure, a single ACL to write, a single service address to >> monitor, staff needs to know only a single protocol, deveopment >> staff needs only develop and do QA for a single protocol, it's a >> single topology to document, a single IGP to run and monitor, a >> single protocol to debug and troubleshoot, one less attack vector >> for the bad guys, and so on. I have a strong feeling that the >> reason why dual stack failed so miserably as a transition >> mechanism was precisely because of the fact that it adds >> significant complexity and operational overhead, compared to single >> stack. > > Except that with SIIT, you're still dealing with two stacks, just > moving the place where you deal with them around a bit. Further, > you're adding the complication of NAT into your world (SIIT is a > form of NAT whether you care to admit that to yourself or not). The difference is that only a small number of people will need to deal with the two stacks, in a small number of places. They way I envision it, the networking staff would ideally operate SIIT a logical function on the data centre's access routers, or their in their backbone's core/border routers. A typical data centre operator/content provider has a vastly larger number of servers, applications, systems administrators, and software developers, than they have routers and network administrators. By making IPv4 end-user connectivity a service provided by the network, you make the amount of dual stack-related complexity a fraction of what it would be if you had to run dual stack on every server and in every application. I have no problem admitting that SIIT is a form of NAT. It is. The ?T? in both cases stands for ?Translation?, after all. >> - IPv4 address conservation. If you're running out of IPv4 >> addresses, you cannot use dual stack, as dual stack does nothing >> to reduce your dependency on IPv4 compared to single stack IPv4. >> With dual stack, you'll be using (at least) one IPv4 address per >> server, plus a bit of overhead due to the server LAN prefixes >> needing to be rounded up to the nearest power or two (or higher if >> you want to accommodate for future growth), plus overhead due to >> the network infrastructure. With SIIT, on the other hand, you'll be >> using a single IPv4 address per publicly available service - one >> /32 out of a pool, with nothing going to waste due to aggregation, >> network infrastructure, and so on. > > Since you end up dealing with NAT anyway, why not just use NAT for > IPv4 conservation. It's what most engineers are already used to > dealing with and you don't lose anything between it and SIIT. > Further, for SIIT to work, you don't really conserve any IPv4 > addresses, since address conservation requires state. Nope! The ?S? in SIIT stands for ?Stateless?. That is the beauty of it. NAT44, on the other hand, is stateful, a very undesirable trait. Suddenly, things like flows per second and flow initiation rate is relevant for the overall performance of the architecture. It requires flows to pass bidirectionally across a single instance - the servers' default route must point to the NAT44, and a failure will cause the disruption of all existing flows. It is probably possible to find ways to avoid some or all of these problems, but it comes at the expense of added complexity. SIIT, on the other hand, is stateless, so you can use anycasting with normal routing protocols or load balancing using ECMP. A failure handled just like any IP re-routing event. You don't need the server's default route to point to the SIIT box, it is just a regular IPv6 route (typically a /96). You don't even have to run it in your own network. Assuming we have IPv6 connectivity between us, I could sell you SIIT service over the Internet or via a direct peering. (I'll be happy to give you a demo just for fun, give me an IPv6 address and I'll map up a public IPv4 front-end address for you in our SIIT deployment.) Finally, by putting your money into NAT44 for IPv4 conservation, you have accomplished exactly *nothing* when it comes to IPv6 deployment. You'll still have to go down the dual stack route, with the added complexity that will cause. With SIIT, you can kill both birds with one stone. >> - Promotes first-class native IPv6 deployment. Not that dual stack >> isn't native IPv6 too, but I do have the impression that often, >> IPv6 in a dual stacked environment is a second class citizen. IPv6 >> might be only partially deployed, not monitored as well as IPv4, >> or that there are architectural dependencies on IPv4 in the >> application stack, so that you cannot just shut off IPv4 and >> expect it to continue to work fine on IPv6 only. With SIIT, you get >> only a single, first-class, citizen - IPv6. And it'll be the only >> IPv6 migration/transition/deployment project you'll ever have to >> do. When the time comes to discontinue support for IPv4, you just >> remove your IN A records and shut down the SIIT gateway(s), there >> will be no need to touch the application stack at all. > > Treating IPv6 as a second class citizen is a choice, not an inherent > consequence of dual-stack. IPv6 certainly isn't a second class > citizen on my network or on Hurricane Electric's network. Agreed, and I have no reason to doubt that HE does dual stack really well. That said, I don't think HE is the type of organisation for which SIIT makes the most sense - certainly not for your ISP activities. The type of organisation I picture using SIIT, is one that operates a bunch of servers and application cluster, i.e., they are controlling the entire service stack, and making them available to the internet through a small number of host names. Most internet content providers would fall in this category, including my own employer. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From owen at delong.com Sun Nov 4 15:07:03 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 4 Nov 2012 07:07:03 -0800 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <50966A70.1050705@redpill-linpro.com> References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> <509397D6.7020009@redpill-linpro.com> <5094FDB6.2000905@redpill-linpro.com> <1AD89D5D-D9E2-4531-B8E5-A76DCD633F44@delong.com> <50963BA0.2060407@redpill-linpro.com> <50966A70.1050705@redpill-linpro.com> Message-ID: On Nov 4, 2012, at 5:15 AM, Tore Anderson wrote: > * Owen DeLong > >> On Nov 4, 2012, at 1:55 AM, Tore Anderson >> wrote: >> >>> * Owen DeLong >>> >>>> What do you get from SIIT that you don't get from dual stack in a >>>> datacenter? >>> >>> In no particular order: >>> >>> - Single stack is much simpler than dual stack. A single stack to >>> configure, a single ACL to write, a single service address to >>> monitor, staff needs to know only a single protocol, deveopment >>> staff needs only develop and do QA for a single protocol, it's a >>> single topology to document, a single IGP to run and monitor, a >>> single protocol to debug and troubleshoot, one less attack vector >>> for the bad guys, and so on. I have a strong feeling that the >>> reason why dual stack failed so miserably as a transition >>> mechanism was precisely because of the fact that it adds >>> significant complexity and operational overhead, compared to single >>> stack. >> >> Except that with SIIT, you're still dealing with two stacks, just >> moving the place where you deal with them around a bit. Further, >> you're adding the complication of NAT into your world (SIIT is a >> form of NAT whether you care to admit that to yourself or not). > > The difference is that only a small number of people will need to deal > with the two stacks, in a small number of places. They way I envision > it, the networking staff would ideally operate SIIT a logical function > on the data centre's access routers, or their in their backbone's > core/border routers. > I suppose if you're not moving significant traffic, that might work. In the data centers I deal with, that's a really expensive approach because it would tie up a lot more router CPU resources that really shouldn't be wasted on things end-hosts can do for themselves. By having the end-host just do dual-stack, life gets a lot easier if you're moving significant traffic. If you only have a few megabits or even a couple of gigabits, sure. I haven't worked with anything that small in a long time. > A typical data centre operator/content provider has a vastly larger > number of servers, applications, systems administrators, and software > developers, than they have routers and network administrators. By making > IPv4 end-user connectivity a service provided by the network, you make > the amount of dual stack-related complexity a fraction of what it would > be if you had to run dual stack on every server and in every application. In a world where you have lots of network/system administrators that fully understand IPv6 and have limited IPv4 knowledge, sure. In the real world, where the situation is reversed, you just confuse everyone and make the complexity of troubleshooting a lot of things that much harder because it is far more likely to require interaction across teams to get things fixed. > I have no problem admitting that SIIT is a form of NAT. It is. The ?T? > in both cases stands for ?Translation?, after all. > Yep. >>> - IPv4 address conservation. If you're running out of IPv4 >>> addresses, you cannot use dual stack, as dual stack does nothing >>> to reduce your dependency on IPv4 compared to single stack IPv4. >>> With dual stack, you'll be using (at least) one IPv4 address per >>> server, plus a bit of overhead due to the server LAN prefixes >>> needing to be rounded up to the nearest power or two (or higher if >>> you want to accommodate for future growth), plus overhead due to >>> the network infrastructure. With SIIT, on the other hand, you'll be >>> using a single IPv4 address per publicly available service - one >>> /32 out of a pool, with nothing going to waste due to aggregation, >>> network infrastructure, and so on. >> >> Since you end up dealing with NAT anyway, why not just use NAT for >> IPv4 conservation. It's what most engineers are already used to >> dealing with and you don't lose anything between it and SIIT. >> Further, for SIIT to work, you don't really conserve any IPv4 >> addresses, since address conservation requires state. > > Nope! The ?S? in SIIT stands for ?Stateless?. That is the beauty of it. > Right? As soon as you make it stateless, you lose the ability to overload the addresses unless you're using a static mapping of ports, in which case, you've traded dynamic state tables for static tables that, while stateless, are a greater level of complexity and create even more limitations. > NAT44, on the other hand, is stateful, a very undesirable trait. > Suddenly, things like flows per second and flow initiation rate is > relevant for the overall performance of the architecture. It requires > flows to pass bidirectionally across a single instance - the servers' > default route must point to the NAT44, and a failure will cause the > disruption of all existing flows. It is probably possible to find ways > to avoid some or all of these problems, but it comes at the expense of > added complexity. > > SIIT, on the other hand, is stateless, so you can use anycasting with > normal routing protocols or load balancing using ECMP. A failure handled > just like any IP re-routing event. You don't need the server's default > route to point to the SIIT box, it is just a regular IPv6 route > (typically a /96). You don't even have to run it in your own network. > Assuming we have IPv6 connectivity between us, I could sell you SIIT > service over the Internet or via a direct peering. (I'll be happy to > give you a demo just for fun, give me an IPv6 address and I'll map up a > public IPv4 front-end address for you in our SIIT deployment.) Without state, how are you overloading the IPv4 addresses? If I don't have a 1:1 mapping between public IPv4 addresses and IPv6 addresses at the SIIT box, what you have described doesn't seem feasible to me. If I have a 1:1 mapping, then, I don't have any address conservation because the SIIT box has an IPv4 address for every IPv6 host that speaks IPv4. > > Finally, by putting your money into NAT44 for IPv4 conservation, you > have accomplished exactly *nothing* when it comes to IPv6 deployment. > You'll still have to go down the dual stack route, with the added > complexity that will cause. With SIIT, you can kill both birds with one > stone. But I'm not putting more money into NAT44? I'm deploying IPv6 on top of my existing IPv4 environment where the NAT44 is already paid for. > >>> - Promotes first-class native IPv6 deployment. Not that dual stack >>> isn't native IPv6 too, but I do have the impression that often, >>> IPv6 in a dual stacked environment is a second class citizen. IPv6 >>> might be only partially deployed, not monitored as well as IPv4, >>> or that there are architectural dependencies on IPv4 in the >>> application stack, so that you cannot just shut off IPv4 and >>> expect it to continue to work fine on IPv6 only. With SIIT, you get >>> only a single, first-class, citizen - IPv6. And it'll be the only >>> IPv6 migration/transition/deployment project you'll ever have to >>> do. When the time comes to discontinue support for IPv4, you just >>> remove your IN A records and shut down the SIIT gateway(s), there >>> will be no need to touch the application stack at all. >> >> Treating IPv6 as a second class citizen is a choice, not an inherent >> consequence of dual-stack. IPv6 certainly isn't a second class >> citizen on my network or on Hurricane Electric's network. > > Agreed, and I have no reason to doubt that HE does dual stack really > well. That said, I don't think HE is the type of organisation for which > SIIT makes the most sense - certainly not for your ISP activities. The > type of organisation I picture using SIIT, is one that operates a bunch > of servers and application cluster, i.e., they are controlling the > entire service stack, and making them available to the internet through > a small number of host names. Most internet content providers would fall > in this category, including my own employer. > We have a lot of customers and professional services clients that fit exactly what you describe. Not one of them has chosen SIIT over dual stack. Admittedly, they also aren't using NAT44, but that's because everything has a public IPv4 address, as things should be for server clusters. Owen From tore.anderson at redpill-linpro.com Sun Nov 4 16:09:09 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sun, 04 Nov 2012 17:09:09 +0100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <1351813930.3314.938.camel@karl> <63173517-331B-4030-840C-F9C8C1A9C833@delong.com> <509397D6.7020009@redpill-linpro.com> <5094FDB6.2000905@redpill-linpro.com> <1AD89D5D-D9E2-4531-B8E5-A76DCD633F44@delong.com> <50963BA0.2060407@redpill-linpro.com> <50966A70.1050705@redpill-linpro.com> Message-ID: <50969325.6000101@redpill-linpro.com> * Owen DeLong >> The difference is that only a small number of people will need to >> deal with the two stacks, in a small number of places. They way I >> envision it, the networking staff would ideally operate SIIT a >> logical function on the data centre's access routers, or their in >> their backbone's core/border routers. > > I suppose if you're not moving significant traffic, that might work. > > In the data centers I deal with, that's a really expensive approach > because it would tie up a lot more router CPU resources that really > shouldn't be wasted on things end-hosts can do for themselves. > > By having the end-host just do dual-stack, life gets a lot easier if > you're moving significant traffic. If you only have a few megabits > or even a couple of gigabits, sure. I haven't worked with anything > that small in a long time. For a production deployment, we would obviously not do this in our routers' CPUs, for the same reasons that we wouldn't run regular IP forwarding in their CPUs. If a data centre access router gets a mix of dual-stacked input traffic coming in from the Internet, that same amount of traffic has to go out in the rear towards the data centre. Whether or not it comes out as the same dual stacked mix as what came in, or as only IPv6 does not change the total amount of bandwidth the router has to pass. So the amount of bandwidth is irrelevant, really. I would agree with you if this was question of doing SIIT in software instead of IP forwarding in hardware. But that's no different than when what was a problem a while back - routers that did IPv4 in hardware and IPv6 in software. Under such conditions, you just don't deploy. >> A typical data centre operator/content provider has a vastly >> larger number of servers, applications, systems administrators, and >> software developers, than they have routers and network >> administrators. By making IPv4 end-user connectivity a service >> provided by the network, you make the amount of dual stack-related >> complexity a fraction of what it would be if you had to run dual >> stack on every server and in every application. > > In a world where you have lots of network/system administrators that > fully understand IPv6 and have limited IPv4 knowledge, sure. In the > real world, where the situation is reversed, you just confuse > everyone and make the complexity of troubleshooting a lot of things > that much harder because it is far more likely to require interaction > across teams to get things fixed. With dual stack, they would need to fully understand *both* IPv6 and IPv4. This sounds to me more like an argument for staying IPv4 only. And even if they do know both protocols perfectly, they still have to operate them both, monitor them both, document them both, and so on. That is a non-negligible operational overhead, in my experience. > Right? As soon as you make it stateless, you lose the ability to > overload the addresses unless you're using a static mapping of > ports, in which case, you've traded dynamic state tables for static > tables that, while stateless, are a greater level of complexity and > create even more limitations. I would claim that stateful NAPT44 mapping, which requires a router to dynamically maintain a table of all concurrent flows using a five-tuple identifier based on both L3 and L4 headers, is a vastly more complex and thing than a static configured mapping table with two L3 addresses for each entry. > Without state, how are you overloading the IPv4 addresses? We're not. > If I don't have a 1:1 mapping between public IPv4 addresses and IPv6 > addresses at the SIIT box, what you have described doesn't seem > feasible to me. SIIT is 1:1. > If I have a 1:1 mapping, then, I don't have any address conservation > because the SIIT box has an IPv4 address for every IPv6 host that > speaks IPv4. The SIIT box has indeed an IPv4 address for every IPv6 host that speaks IPv4, true. The conservation comes from elsewhere, from the fact that a content provider will often have a large number of servers, but a much smaller number of publicly available IPv4 service addresses. Let's say you have a small customer with a web server and a database server. Using dual stack, you'll need to assign that customer at least a /29. One address for each server, three for network/broadcast/default router, and three more that goes away just because those five gets rounded up to the nearest power of two. With SIIT, that customer would instead get an IPv6 /64 on his LAN, and no IPv4 at all. Instead, a single IPv4 address will gets mapped to the IPv6 address of the customer's web server. You've now just saved 7 out of 8 addresses which you may use for 7 other customers like this one. That's just a small example. For most my customers, the ratio of assigned IPv4 addresses to publicly available services is *at least* one order of magnitude. So I have huge potential for savings here. >> Finally, by putting your money into NAT44 for IPv4 conservation, >> you have accomplished exactly *nothing* when it comes to IPv6 >> deployment. You'll still have to go down the dual stack route, with >> the added complexity that will cause. With SIIT, you can kill both >> birds with one stone. > > But I'm not putting more money into NAT44? I'm deploying IPv6 on top > of my existing IPv4 environment where the NAT44 is already paid for. We don't currently use NAT44 and have no desire to invest in it either. I strongly dislike the idea of putting big stateful boxes between our customers and their end users. But if we have to do it anyway, it will certainly eat away from any human resources and budget that could otherwise be used for IPv6 activities. Unfortunately. If you've already bought NAT44 for your IPv4 conservation strategy, the case for SIIT is weaker, I admit. However, there's still the benefits of potentially reducing complexity compared to dual stack, and the fact that it requires no state in your network. >> Agreed, and I have no reason to doubt that HE does dual stack >> really well. That said, I don't think HE is the type of >> organisation for which SIIT makes the most sense - certainly not >> for your ISP activities. The type of organisation I picture using >> SIIT, is one that operates a bunch of servers and application >> cluster, i.e., they are controlling the entire service stack, and >> making them available to the internet through a small number of >> host names. Most internet content providers would fall in this >> category, including my own employer. > > We have a lot of customers and professional services clients that fit > exactly what you describe. Not one of them has chosen SIIT over dual > stack. Well, today it's not easy to deploy SIIT, so that's quite understandable. There's not that many implementations available. You can do it on the Cisco ASR1K, although it lacks some features (in particular the static mapping feature) that I find are very desirable in the data centre use case. > Admittedly, they also aren't using NAT44, but that's because > everything has a public IPv4 address, as things should be for server > clusters. I'm confused, you said above that you were already using NAT44..? In any case, good for you that you have enough public IPv4 addresses for everything. Very shortly, we won't, and our friendly neighbourhood RIR is fresh out. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From tom at cloudflare.com Sun Nov 4 17:26:22 2012 From: tom at cloudflare.com (Tom Paseka) Date: Sun, 4 Nov 2012 09:26:22 -0800 Subject: mail-abuse.org down? In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> <5092690D.8000500@necom830.hpcl.titech.ac.jp> <509273D5.3070503@foobar.org> <29A07C07-0B3B-4A1D-9AA3-A79413732E0C@steffann.nl> <2452DE84-416B-40B3-B315-37998E3FBB8B@hopcount.ca> <1352025754.2312.7.camel@outsider.laptop> Message-ID: from the website: This website has been moved to http://ers.trendmicro.com. Please update your bookmarks with this URL. On Sun, Nov 4, 2012 at 2:47 AM, Suresh Ramasubramanian wrote: > > Maps was taken over by trend micro years back, maybe they just retired the > old domain? From mysidia at gmail.com Sun Nov 4 19:26:52 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 4 Nov 2012 13:26:52 -0600 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <1351749728.3314.867.camel@karl> References: <20121101053157.GD1727@don.i.pumpky.net> <1351749728.3314.867.camel@karl> Message-ID: On 11/1/12, Karl Auer wrote: > I espouse four principles (there are others, but these are the biggies): Sounds like what is suggested is anti-practices, rather than suggesting affirmative practices. I would suggest slightly differently. Complexity results in failure modes that are difficult to predict, so - Keep addressing design as simple as possible, with as few "interesting things" or distinctions as possible, (such as multiple different prefix lengths for different nets, different autoconfig methods, different host IDs for default gateways, unique numbering schemes, for different network or host types, etc) Without omitting requirements, or overall opportunities for efficient reliable network operations. - Keep addressing complexity in addressing. E.g. Addressing may be simpler with a flat network, but don't use that as an excuse to relocate 2x the cost of addressing complexity to switching infrastructure/routing design and scalability limits that will forseeably be reached. Don't implement carrier grade NAT, just because it ensures the user's default gateway is always 192.168.1.1. Ensure the simplicity and benefits of the whole is maximized, not the individual design elements. > - don't overload address bits with non-addressing information You suggest building networks with address bits that contain only addressing information. It sounds like an IPv4 principle whose days are done; that, addressing bits are precious, so don't waste a single bit encoding extra information. If encoding additional information can provide something worthwhile, then it should be considered. I'm not sure what exactly would be worthwhile to encode, but something such as a POP#, Serving router, Label/Tag id, Security level, type of network, hash of a circuit ID, might be some potential contenders for some network operators to encode in portions of the network ID for some networks. Specifically P-t-P networks, to which a /48 end site numbered differently may be routed. > - keep the network as flat as reasonably possible You are suggesting the avoidance of multiple networks, preferring instead large single IP subnets for large areas, whenever possible? IPv6 has not replaced ethernet. Bottlenecks such as unknown unicast flooding, broadcast domain chatter, scalability limits still exist on IPv6oE. Ample subnet IDs are available. With IPv6, there are more reasons than ever to avoid flat networks, even in cases where a flat network might be an option. My suggestion would be: - Avoid flat networks; implement segmentation. Make new subnets; whenever possible plus reliability, security, and serviceability gains exceed the basic config, and continuous management costs. Make flat networks when the benefits are limited, or segmented networks are not possible, or too expensive due to poorly designed hardware/software (E.g. software requiring a flat network between devices that should be segmented). > - avoid tying topology to geography It sounds like IPv4 thinking again --- avoid creating additional topology for geographic locations, in order to conserve address space. > - avoid exceptions Consistency is something good designs should strive for; when it can be achieved without major risks, costs, or technical sacrifices, exceeding the value of that consistency. > I too would be really interested in whatever wisdom others have > developed, even if (especially if!) it doesn't agree with mine. > > Regards, K. -- -JH From sharonsaa at gmail.com Sun Nov 4 20:18:30 2012 From: sharonsaa at gmail.com (sharon saadon) Date: Sun, 4 Nov 2012 22:18:30 +0200 Subject: Cisco devices mass config Message-ID: Hi, A small open source app that i wrote to configure mass of devices (tested with cisco devices) http://sharontools.com/Products/MassConfig.php Regards, Sharon From kauer at biplane.com.au Mon Nov 5 00:21:36 2012 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 05 Nov 2012 11:21:36 +1100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> <1351749728.3314.867.camel@karl> Message-ID: <1352074896.17094.166.camel@karl> On Sun, 2012-11-04 at 13:26 -0600, Jimmy Hess wrote: > On 11/1/12, Karl Auer wrote: > > I espouse four principles (there are others, but these are the biggies): > > Sounds like what is suggested is anti-practices, rather than > suggesting affirmative practices. I would suggest slightly differently. I agree that positive is best, but my rules can be expressed in a few phrases. There is value in being concise. > You suggest building networks with address bits that contain only > addressing information. > It sounds like an IPv4 principle whose days are done; that, > addressing bits are precious, so don't waste a single bit encoding > extra information. Address bits are not precious; subnetting bits are. We have moved, with IPv6, from conserving address space to conserving subnet space. Your address space in a leaf subnet numbers in the billions of billions; your subnetting space in a typical /48 site numbers in the tens of thousands. By the way, there are two very diffferent kinds of subnet - the leaf subnet that actually contains hosts, and the structural subnet that divides your network up. I'm talking about structural subnetting. > If encoding additional information can provide something worthwhile, > then it should be considered. Of course. But *as a rule* it should not be done. Only you can weigh the benefits against the downsides. Remember I said these were rules for students; I'm not going to tell a competent professional what to do. I personally would however strenuously avoid overloading address bits merely for the sake of human convenience or readability. Systems with no necessary technical links inevitably diverge; if you have encoded one in the other, the latter will eventually start lying to you. You will have to work to keep the two things in sync, but if they diverge enough that may not be possible, and you end up with one system containing the irrelevant, misleading remnants of another. > > - keep the network as flat as reasonably possible > > You are suggesting the avoidance of multiple networks, preferring instead > large single IP subnets for large areas, whenever possible? No, that's not what I'm suggesting. See above for the distinction I make between leaf and structural subnets. I am suggesting keeping the network structure as flat as possible. > - Avoid flat networks; implement segmentation. Yes at the edge, no in the network structure. > > - avoid tying topology to geography > > It sounds like IPv4 thinking again --- avoid creating additional > topology for geographic locations, in order to conserve address space. Conserving address space is NOT one of my goals, though conserving subnet space is. Without being foolishly parsimonious, though. As you say, there is ample subnet space, but it's not nearly as ample as address space. I use "geography" in the broadest sense of "the physical world". The reason for avoiding tying your network topology to geography is that networks move and flex all the time. So does the physical world, in a way - companies buy extra buildings, occupy more floors, open new state branches, move to new buildings with different floor plans. New administrative divisions arise, old ones disappear, divisions merge. Building your topology on these shifting sands means that every time they change, either your address schema moves further away from reality, or you spend time adjusting it to the new reality. If you chose poorly at the start, it may not be possible to adjust it easily. Again, I can't second guess what physical constructs you will want or need to mirror in your network topology, but I can say with confidence that you should avoid doing so unless absolutely technically necessary. These rules are not really IPv6-specific. It's just that in the IPv4 world, we basically can't follow them, because the technical requirements of the cramped address space drive us towards particular, unavoidable solutions. With IPv6, the rules gain new currency because we *can* mostly follow them. Regards, K. PS: I've put a lot of this, word for word, in my blog at www.biplane.com.au/blog -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From network.ipdog at gmail.com Mon Nov 5 01:47:36 2012 From: network.ipdog at gmail.com (Network IPdog) Date: Sun, 4 Nov 2012 17:47:36 -0800 Subject: Cisco devices mass config In-Reply-To: References: Message-ID: <50971aa9.8abe440a.64c8.3552@mx.google.com> Hi Sharon! Program looks great on the webpage, but... you cannot download it or look at the pdf of the manual Not Found The requested URL /Products/Download\Mass config v1.8.rar was not found on this server. Apache/2.2.9 (Debian) PHP/5.4.0-3 mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 Server at sharontools.com Port 80 Not Found The requested URL /Products/Download\MassConfig v1.8 - User manual.pdf was not found on this server. Apache/2.2.9 (Debian) PHP/5.4.0-3 mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 Server at sharontools.com Port 80 Ephesians 4:32 & Cheers!!! A password is like a... toothbrush ;^) Choose a good one, change it regularly and don't share it. -----Original Message----- From: sharon saadon [mailto:sharonsaa at gmail.com] Sent: Sunday, November 04, 2012 12:19 PM To: nanog at nanog.org Subject: Cisco devices mass config Hi, A small open source app that i wrote to configure mass of devices (tested with Cisco devices) http://sharontools.com/Products/MassConfig.php Regards, Sharon From aj at jonesy.com.au Mon Nov 5 02:44:20 2012 From: aj at jonesy.com.au (Andrew Jones) Date: Mon, 05 Nov 2012 13:44:20 +1100 Subject: Cisco devices mass config In-Reply-To: <50971aa9.8abe440a.64c8.3552@mx.google.com> References: <50971aa9.8abe440a.64c8.3552@mx.google.com> Message-ID: Downloads work fine for me, looks like something's changing forward slashes to backslashes in the download URL for you... Try these links: http://sharontools.com/Products/Download/Mass%20config%20v1.8.rar http://sharontools.com/Products/Download/MassConfig%20v1.8%20-%20User%20manual.pdf -Jonesy On 05.11.2012 12:47, Network IPdog wrote: > Hi Sharon! > > Program looks great on the webpage, but... you cannot download it or > look at > the pdf of the manual > > Not Found > > The requested URL /Products/Download\Mass config v1.8.rar was not > found on > this server. > Apache/2.2.9 (Debian) PHP/5.4.0-3 mod_python/3.3.1 Python/2.5.2 > mod_perl/2.0.4 Perl/v5.10.0 Server at sharontools.com Port 80 > > > Not Found > > The requested URL /Products/Download\MassConfig v1.8 - User > manual.pdf was > not found on this server. > Apache/2.2.9 (Debian) PHP/5.4.0-3 mod_python/3.3.1 Python/2.5.2 > mod_perl/2.0.4 Perl/v5.10.0 Server at sharontools.com Port 80 > > > Ephesians 4:32 & Cheers!!! > > A password is like a... toothbrush ;^) > Choose a good one, change it regularly and don't share it. > > > > -----Original Message----- > From: sharon saadon [mailto:sharonsaa at gmail.com] > Sent: Sunday, November 04, 2012 12:19 PM > To: nanog at nanog.org > Subject: Cisco devices mass config > > Hi, > A small open source app that i wrote to configure mass of devices > (tested > with Cisco devices) http://sharontools.com/Products/MassConfig.php > > Regards, > Sharon From r.engehausen at gmail.com Mon Nov 5 06:20:36 2012 From: r.engehausen at gmail.com (Roy) Date: Sun, 04 Nov 2012 22:20:36 -0800 Subject: Sandy seen costing telco, cable hundreds of millions of dollars Message-ID: <50975AB4.8060502@gmail.com> http://www.reuters.com/article/2012/11/01/storm-sandy-telecoms-idUSL1E8M1L9Z20121101 From sharonsaa at gmail.com Mon Nov 5 06:50:18 2012 From: sharonsaa at gmail.com (sharon saadon) Date: Mon, 5 Nov 2012 08:50:18 +0200 Subject: Cisco devices mass config In-Reply-To: References: Message-ID: Hi, i updated the app file name. now it's also possible to download the app :) Sharon On Sun, Nov 4, 2012 at 10:18 PM, sharon saadon wrote: > Hi, > A small open source app that i wrote to configure mass of devices > (tested with cisco devices) > http://sharontools.com/Products/MassConfig.php > > Regards, > Sharon > From eugen at imacandi.net Mon Nov 5 08:07:39 2012 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Mon, 5 Nov 2012 10:07:39 +0200 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: <1351924117.2935.35.camel@karl> References: <20121101053157.GD1727@don.i.pumpky.net> <8F57CD84-A8C0-4889-A7B6-A8ECF5577A35@gdt.id.au> <5094AF2E.7090706@afxr.net> <1351924117.2935.35.camel@karl> Message-ID: On Sat, Nov 3, 2012 at 8:28 AM, Karl Auer wrote: > - if you need to remember an IP address, you are doing it wrong Because DNS always works flawlessly and you never need to remember IP addresses, right ? > - cultural sensitivity and plain good sense suggest that many words or > combinations might not be a good idea. How do your female techs feel > about "BAD:BABE"? Only marginally better than they feel about > "B16:B00B:EEZ", probably. Your markets in India, with its 900 million > Hindus, might take a dim view of "DEAD:BEEF". Etc. I think you're looking for problems where there are none. I see nothing wrong with BAD:BABE or with DEAD:BEEF. Your thinking suggests that there are only good babes and live beef, which is wrong on so many levels. Positive discrimination is as bad as discrimination and it creates more problems than it solves. In India you can have beef steak at restaurants, so I see no problem with the term. > > - clever addresses are guessable addresses for scanners, and highly > identifiable in data as probably attached to high-value targets What is a clever IP address ? From eugen at imacandi.net Mon Nov 5 08:14:20 2012 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Mon, 5 Nov 2012 10:14:20 +0200 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: On Fri, Nov 2, 2012 at 5:13 PM, Eric Germann wrote: > Colleagues, > > I'm looking for a recommendation on a smallish 10G Ethernet switch for a > small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over > iSCSI with some legacy boxes on GigE. > > Preferably > > - 8-16 10G ports > - several GigE ports for legacy GigE hosts or cross connect to a legacy > GigE switch > - preferably not a large chassis based solution with blades > > The hosts aren't going to be driving full line rate, nor the SAN boxes > providing full line rate, but their offered loads will definitely exceed > 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing > with quad GigE cards. Trying to find the best solution for > 1G on a > trunk and < $50K per box. You can look ar Brocade TurboIron 24. It has 24 ports of 1/10G depending on the SFP you put in. From covaigopi at gmail.com Mon Nov 5 08:21:07 2012 From: covaigopi at gmail.com (Gopi) Date: Mon, 05 Nov 2012 13:51:07 +0530 Subject: Looking for recommendation on 10G Ethernet switch Message-ID: ARISTA 7xxx series would be one of the options to consider cheers! Gopi... __________________________________ please ignore typo's if any... sent from handheld device __________________________________ Eugeniu Patrascu wrote: >On Fri, Nov 2, 2012 at 5:13 PM, Eric Germann wrote: >> Colleagues, >> >> I'm looking for a recommendation on a smallish 10G Ethernet switch for a >> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over >> iSCSI with some legacy boxes on GigE. >> >> Preferably >> >> - 8-16 10G ports >> - several GigE ports for legacy GigE hosts or cross connect to a legacy >> GigE switch >> - preferably not a large chassis based solution with blades >> >> The hosts aren't going to be driving full line rate, nor the SAN boxes >> providing full line rate, but their offered loads will definitely exceed >> 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing >> with quad GigE cards. Trying to find the best solution for > 1G on a >> trunk and < $50K per box. > >You can look ar Brocade TurboIron 24. It has 24 ports of 1/10G >depending on the SFP you put in. > From kauer at biplane.com.au Mon Nov 5 11:22:17 2012 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 05 Nov 2012 22:22:17 +1100 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: References: <20121101053157.GD1727@don.i.pumpky.net> <8F57CD84-A8C0-4889-A7B6-A8ECF5577A35@gdt.id.au> <5094AF2E.7090706@afxr.net> <1351924117.2935.35.camel@karl> Message-ID: <1352114537.2832.58.camel@karl> On Mon, 2012-11-05 at 10:07 +0200, Eugeniu Patrascu wrote: > On Sat, Nov 3, 2012 at 8:28 AM, Karl Auer wrote: > > - if you need to remember an IP address, you are doing it wrong > Because DNS always works flawlessly and you never need to remember IP > addresses, right ? If you are NOT memorising IP addresses and NOT wasting time on fragile encodings buried in your IP addresses, then your addressing is more robust and more flexible. So you occasionally have a problem with whatever system maps your IP addresses to human-usable entities - so what? You can't memorise ALL your addresses, so you have that problem anyway. And let's not forget your (possibly emergency) replacement - sure, *you* have lots of addresses memorised, but what about other people? You need a suitable mapping system *anyway*. > I think you're looking for problems where there are none. I see > nothing wrong with BAD:BABE or with DEAD:BEEF. Your thinking suggests > that there are only good babes and live beef, which is wrong on so > many levels. Positive discrimination is as bad as discrimination and > it creates more problems than it solves. *You* don't see a problem, so there is no problem? I *personally* have no problem with either example, but I can see how others might, and how others might have a problem with constructs similar in nature to these ones. I think it is likely that others would find those sorts of things objectionable, I see no benefit to using them, and I see several technical and non-technical disadvantages to using them - so my recommendation is not to use them. As to "my thinking", your comments on that are confused. I don't recommend crafting words, regardless of what words they are. How you got from one OP-supplied example and one well-known example to "my thinking" and thence to positive discrimination is a mystery to me. The OP asked for reasons why embedding wordiness in IPv6 addresses might not be a good idea. I gave several reasons, some technical, some not. You've attacked two non-technical ones, with counterarguments that amount to "is not!". > > - clever addresses are guessable addresses for scanners, and highly > > identifiable in data as probably attached to high-value targets > What is a clever IP address ? One that has obviously been constructed by a human - such as one containing readable words, obvious numeric patterns and the like. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From dariusjs at gmail.com Mon Nov 5 16:49:41 2012 From: dariusjs at gmail.com (Darius Seroka) Date: Mon, 5 Nov 2012 17:49:41 +0100 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: The Juniper ex4500/4550 could work, small chassis, can be made part of a virtual chassis. Works well in an enterprise setup but can cause configuration headaches if within a service provider environment where vlans need to be translated. Darius On Fri, Nov 2, 2012 at 4:13 PM, Eric Germann wrote: > Colleagues, > > I'm looking for a recommendation on a smallish 10G Ethernet switch for a > small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over > iSCSI with some legacy boxes on GigE. > > Preferably > > - 8-16 10G ports > - several GigE ports for legacy GigE hosts or cross connect to a legacy > GigE switch > - preferably not a large chassis based solution with blades > > The hosts aren't going to be driving full line rate, nor the SAN boxes > providing full line rate, but their offered loads will definitely exceed > 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing > with quad GigE cards. Trying to find the best solution for > 1G on a > trunk and < $50K per box. > > Any recommendations appreciated. > > Thanks > > EKG > > > From victor.kuarsingh at gmail.com Mon Nov 5 18:32:53 2012 From: victor.kuarsingh at gmail.com (Victor Kuarsingh) Date: Mon, 05 Nov 2012 13:32:53 -0500 Subject: Operational Experience with SSR Message-ID: All, I was looking for anyone who has operational experience with the SSR platform used as a SGW and/or PGW function in mobile environment. Please contact me off-list. Thanks, Victor Kuarsingh From jeroen at mompl.net Mon Nov 5 20:33:39 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 05 Nov 2012 12:33:39 -0800 Subject: NJ impact In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE477B1DF@EXCHMBX.hq.nac.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE477B1DF@EXCHMBX.hq.nac.net> Message-ID: <509822A3.7030303@mompl.net> On 10/31/2012 12:24 PM, Alex Rubenstein wrote: > I had to summarize this recently for a news article I was interviewed for, so I figured I forward: > > Of our three datacenters, this is what we saw: > > Parsippany 1 (OCT) - The worst we saw here was several sub-second power hits. UPS's held without problem, and we did not transfer to generator at all yet. > > Parsippany 2 (WBR) - Transferred to generator at about 7:55 PM EST Monday as a precautionary measure due to ongoing utility power hits. However, shortly after transfer, utility voltage went to 0 on all phases; around 10p power returned, but abnormally high (seeing about 550 volts on 480 volt bus). We retransferred last night as utility voltage settled down. > > Cedar Knolls 1 (MMU) - Briefly transferred to generator around 7:10, then back to utility. We then force transferred to generator around 8pm and stayed until this morning. Returned to utility and all systems are normal. I would be interested to know how the power outages due to the storm have negatively affected air pollution and the smog problem in the area. Due to generators burning huge amounts of diesel, generators which undoubtedly have no meaningful air pollution control to speak of. http://www.nytimes.com/2012/09/23/technology/data-centers-waste-vast-amounts-of-energy-belying-industry-image.html?pagewanted=all&_r=0 "Most data centers, by design, consume vast amounts of energy in an incongruously wasteful manner, interviews and documents show. Online companies typically run their facilities at maximum capacity around the clock, whatever the demand. As a result, data centers can waste 90 percent or more of the electricity they pull off the grid, The Times found. To guard against a power failure, they further rely on banks of generators that emit diesel exhaust. The pollution from data centers has increasingly been cited by the authorities for violating clean air regulations, documents show. In Silicon Valley, many data centers appear on the state government?s Toxic Air Contaminant Inventory, a roster of the area?s top stationary diesel polluters." Greetings, Jeroen -- Earthquake Magnitude: 4.6 Date: Monday, November 5, 2012 13:07:59 UTC Location: western Xizang Latitude: 28.4112; Longitude: 86.2001 Depth: 65.60 km From h.wahl at ifw-dresden.de Mon Nov 5 08:14:54 2012 From: h.wahl at ifw-dresden.de (Henri Wahl) Date: Mon, 05 Nov 2012 09:14:54 +0100 Subject: dhcpy6d - a MAC address aware DHCPv6 server Message-ID: <5097757E.5070307@ifw-dresden.de> Hello World, like other people we had the problem that existing DHCPv6 servers do not evaluate the MAC address of clients, following RFC 3315. The IPv4 clients already are managed via their MAC addresses so we wanted to use these identifiers for IPv6 too for our dualstack network. At the end we had to write our own DHCPv6 server dhcpy6d which I want to present here to a larger audience. It runs on Linux, tested on Debian and CentOS. It gets the client MAC addresses from neighbor cache by calling "ip -6 neigh" and caches them itself, allowing to access the already working MAC-based IPv4 infrastructure. This obviously only works on the local subnet but might be worked around with several servers being connected via database storage of clients and leases. Features are: - identifies clients by MAC address, DUID or hostname - generates addresses randomly, by MAC address, by range or by given ID - filters clients by MAC, DUID or hostname - assignes more than one address per client - allows to organize clients in different classes - stores leases in MySQL or SQLite database - client information can be retrieved from database or textfile - dynamically updates DNS (Bind) We run it with ~500 clients without problems. I am interested if it would run in larger environments too. If not, how to make it running. Bugs and ideas how to improve it are welcome too. Packages are not yet available but the Python code should run as is. See further details at http://dhcpy6d.ifw-dresden.de Best regards Henri Wahl -- Henri Wahl IT Department Leibniz-Institut f?r Festk?rper- u. Werkstoffforschung Dresden tel. (03 51) 46 59 - 797 email: h.wahl at ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor for your desktop: http://nagstamon.ifw-dresden.de IFW Dresden e.V., Helmholtzstra?e 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4719 bytes Desc: S/MIME Kryptografische Unterschrift URL: From bmanning at vacation.karoshi.com Mon Nov 5 21:13:22 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Nov 2012 21:13:22 +0000 Subject: dhcpy6d - a MAC address aware DHCPv6 server In-Reply-To: <5097757E.5070307@ifw-dresden.de> References: <5097757E.5070307@ifw-dresden.de> Message-ID: <20121105211322.GA20630@vacation.karoshi.com.> cool. this is the fifth version of a DHCP server modified to work with IPv4 and IPv6 in accord with the DHCP specs. a feature request... some sites run IVI, and so the have a MAC and and v6 address and need to be dynamically assigned a v4 address. My crude attempt uses the last 48bits of the v6 address asa proxy MAC. It works ok in my small network. It might be useful in larger nets that run IVI or carrier-grade NAT ... /bill On Mon, Nov 05, 2012 at 09:14:54AM +0100, Henri Wahl wrote: > Hello World, > like other people we had the problem that existing DHCPv6 servers do not > evaluate the MAC address of clients, following RFC 3315. The IPv4 > clients already are managed via their MAC addresses so we wanted to use > these identifiers for IPv6 too for our dualstack network. > > At the end we had to write our own DHCPv6 server dhcpy6d which I want to > present here to a larger audience. It runs on Linux, tested on Debian > and CentOS. It gets the client MAC addresses from neighbor cache by > calling "ip -6 neigh" and caches them itself, allowing to access the > already working MAC-based IPv4 infrastructure. This obviously only works > on the local subnet but might be worked around with several servers > being connected via database storage of clients and leases. > > Features are: > - identifies clients by MAC address, DUID or hostname > - generates addresses randomly, by MAC address, by range or by given ID > - filters clients by MAC, DUID or hostname > - assignes more than one address per client > - allows to organize clients in different classes > - stores leases in MySQL or SQLite database > - client information can be retrieved from database or textfile > - dynamically updates DNS (Bind) > > We run it with ~500 clients without problems. I am interested if it > would run in larger environments too. If not, how to make it running. > Bugs and ideas how to improve it are welcome too. > > Packages are not yet available but the Python code should run as is. > > See further details at http://dhcpy6d.ifw-dresden.de > > Best regards > Henri Wahl > > -- > Henri Wahl > > IT Department > Leibniz-Institut f|r Festkvrper- u. > Werkstoffforschung Dresden > > tel. (03 51) 46 59 - 797 > email: h.wahl at ifw-dresden.de > http://www.ifw-dresden.de > > Nagios status monitor for your desktop: > http://nagstamon.ifw-dresden.de > > IFW Dresden e.V., Helmholtzstra_e 20, D-01069 Dresden > VR Dresden Nr. 1369 > Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle > From Valdis.Kletnieks at vt.edu Tue Nov 6 00:31:59 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Nov 2012 19:31:59 -0500 Subject: IPv6 Netowrk Device Numbering BP In-Reply-To: Your message of "Sat, 03 Nov 2012 00:44:14 -0500." <5094AF2E.7090706@afxr.net> References: <20121101053157.GD1727@don.i.pumpky.net> <8F57CD84-A8C0-4889-A7B6-A8ECF5577A35@gdt.id.au> <5094AF2E.7090706@afxr.net> Message-ID: <65263.1352161919@turing-police.cc.vt.edu> On Sat, 03 Nov 2012 00:44:14 -0500, Randy said: > > Veering off this topic's course, Is there any issue with addresses like > this ? > 2001:470:1f00:1aa:abad:babe:8:beef < I have a bunch of these type > 'addresses' configured for my various machines. > > I make it a point to come up with some sort of 'hex' speak address, what > are peoples opinions on this? Google for "microsoft hyperv hex constant". Show the results to whoever handles your PR. Follow their advice. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From pnowak at batblue.com Tue Nov 6 04:32:34 2012 From: pnowak at batblue.com (Peter Nowak) Date: Mon, 5 Nov 2012 23:32:34 -0500 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: References: <195076ab5cac62020593c2f8d034bc97.squirrel@secure.townnews.com> Message-ID: <2F84575B-A5A1-41D9-A160-EA6376743637@batblue.com> Dell Force10 S4810 is a decent ToR switch: 48 dual-speed 1/10GbE (SFP+) ports and four 40GbE (QSFP+) uplinks Peter > > > On Fri, Nov 2, 2012 at 4:13 PM, Eric Germann wrote: > >> Colleagues, >> >> I'm looking for a recommendation on a smallish 10G Ethernet switch for a >> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over >> iSCSI with some legacy boxes on GigE. >> >> Preferably >> >> - 8-16 10G ports >> - several GigE ports for legacy GigE hosts or cross connect to a legacy >> GigE switch >> - preferably not a large chassis based solution with blades >> >> The hosts aren't going to be driving full line rate, nor the SAN boxes >> providing full line rate, but their offered loads will definitely exceed >> 1Gbps. Assessing whether it is better to go 10G now vs. multi-pathing >> with quad GigE cards. Trying to find the best solution for > 1G on a >> trunk and < $50K per box. >> >> Any recommendations appreciated. >> >> Thanks >> >> EKG >> >> >> From kmedcalf at dessus.com Tue Nov 6 05:24:04 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 05 Nov 2012 22:24:04 -0700 Subject: NSA and the exchanges In-Reply-To: Message-ID: <12e697064515c34ba334ab017d5acfbe@mail.dessus.com> And don't forget about the NSA's "Operation Backhoe". What more convenient way of installing a tap than cutting the fibre, then installing a passive tap while repairs are in progress ... --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: John Adams [mailto:jna at retina.net] > Sent: Wednesday, 31 October, 2012 12:38 > To: andy lam > Cc: nanog at nanog.org > Subject: Re: NSA and the exchanges > > Allegedly? No, definately. > > https://www.eff.org/nsa-spying > > https://www.eff.org/files/filenode/att/presskit/ATT_onepager.pdf > > > > -j > > On Wed, Oct 31, 2012 at 11:25 AM, andy lam wrote: > > > Anyone knows if there's a way to find out how involved NSA monitors 151 > > front street at Toronto? NSA allegedly monitors data centres in the US, > > but does it have the same influence at a building sitting in its neighbor's > > soil? > > > > There's something on the web like www.ixmaps.ca that tries to piece it > > together. but not sure how helpful the information on there really is? > > > > > > feedback welcome. > > From kmedcalf at dessus.com Tue Nov 6 05:25:10 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 05 Nov 2012 22:25:10 -0700 Subject: NSA and the exchanges In-Reply-To: <0B224A2FE01CC54C860290D42474BF600570D6B8@exchange.nff.local> Message-ID: <48f562e97c02524c97fa2303c4dfa3b3@mail.dessus.com> That would be the CSE, not CSIS ... --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: Erik Soosalu [mailto:erik.soosalu at calyxinc.com] > Sent: Wednesday, 31 October, 2012 12:53 > To: jim deleskie; andy lam > Cc: nanog at nanog.org > Subject: RE: NSA and the exchanges > > I'd assume the NSA and CSIS would be talking as needed. > > Whether CSIS is actually monitoring in there is another question. I'd > assume yes, but have never heard anything to confirm or deny. > > > -----Original Message----- > From: jim deleskie [mailto:deleskie at gmail.com] > Sent: Wednesday, October 31, 2012 2:37 PM > To: andy lam > Cc: nanog at nanog.org > Subject: Re: NSA and the exchanges > > If your talking "the NSA" I doubt anyone would tell you. That being > said: it would mean the US gov't breaking Canadian law I suspect. Now > in Canada it is quite possible that the Canadian Fed gov't monitors > traffic but I would also say no one would tell you because telling you > would also be in violation in wiretap laws. > > Best advice, assume they do and hope they don't. :) > > -jim > > On Wed, Oct 31, 2012 at 3:25 PM, andy lam wrote: > > Anyone knows if there's a way to find out how involved NSA monitors > 151 front street at Toronto? NSA allegedly monitors data centres in the > US, but does it have the same influence at a building sitting in its > neighbor's soil? > > > > There's something on the web like www.ixmaps.ca that tries to piece it > together. but not sure how helpful the information on there really is? > > > > > > feedback welcome. > > From bortzmeyer at nic.fr Tue Nov 6 10:19:00 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 6 Nov 2012 11:19:00 +0100 Subject: dhcpy6d - a MAC address aware DHCPv6 server In-Reply-To: <5097757E.5070307@ifw-dresden.de> References: <5097757E.5070307@ifw-dresden.de> Message-ID: <20121106101900.GA2109@nic.fr> On Mon, Nov 05, 2012 at 09:14:54AM +0100, Henri Wahl wrote a message of 155 lines which said: > - identifies clients by MAC address, DUID or hostname Excellent, identification by MAC address was often requested. Thanks for this software. > like other people we had the problem that existing DHCPv6 servers do > not evaluate the MAC address of clients, following RFC 3315. I'm not convinced that it is RFC's fault. The only thing I find in RFC 3315 is (section 9) "DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients." I read it as "a compliant DHCPv6 server MUST recognize DUID and identify clients this way" which does not logically imply that it cannot identify clients by other means as well. From achatz at forthnetgroup.gr Tue Nov 6 11:32:39 2012 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Tue, 06 Nov 2012 13:32:39 +0200 Subject: p2p addresses for point-to-point connections with customers Message-ID: <5098F557.7060806@forthnetgroup.gr> I've been trying hard to come up with a solution regarding this, but i haven't decided yet which one is the best. >From the perspective of an ISP, how do you characterize the p2p addresses given for a point-to-point connection to a) customers with their own ASN b) customers without an ASN? These are ip addresses configured on your router's border interface and on the customer's peer router interface (old WAN-style), so they actually are both infrastructure and customer addresses. So... Do you consider them infrastructure addresses or customer addresses? Do you put them in your IGP or in BGP? Do you filter them on your border routers (via iACLs) and if yes, how? -- Tassos From me at anuragbhatia.com Tue Nov 6 11:35:14 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 6 Nov 2012 17:05:14 +0530 Subject: Indonesian ISP Moratel announces Google's prefixes Message-ID: Another case of route hijack - http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about I am curious if big networks have any pre-defined filters for big content providers like Google to avoid these? I am sure internet community would be working in direction to somehow prevent these issues. Curious to know developments so far. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ From rdobbins at arbor.net Tue Nov 6 12:05:16 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 6 Nov 2012 12:05:16 +0000 Subject: p2p addresses for point-to-point connections with customers In-Reply-To: <5098F557.7060806@forthnetgroup.gr> References: <5098F557.7060806@forthnetgroup.gr> Message-ID: <7B5C1FA0-1F62-4F84-AB4A-533FDDB1FF7D@arbor.net> On Nov 6, 2012, at 6:32 PM, Tassos Chatzithomaoglou wrote: > Do you consider them infrastructure addresses or customer addresses? They're infrastructure addresses. > Do you put them in your IGP or in BGP? You should treat them as you do your other infrastructure addresses (i.e., if you're null-routing them at the peering edge, or what-have-you). > Do you filter them on your border routers (via iACLs) Yes. > and if yes, how? The same way you filter any other interface addresses in your iACLs. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From achatz at forthnetgroup.gr Tue Nov 6 12:31:12 2012 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Tue, 06 Nov 2012 14:31:12 +0200 Subject: p2p addresses for point-to-point connections with customers In-Reply-To: <7B5C1FA0-1F62-4F84-AB4A-533FDDB1FF7D@arbor.net> References: <5098F557.7060806@forthnetgroup.gr> <7B5C1FA0-1F62-4F84-AB4A-533FDDB1FF7D@arbor.net> Message-ID: <50990310.8040107@forthnetgroup.gr> Having an iACL format like below, that means that i would have to add at least one extra "permit" entry before the spoofing entries. deny MARTIANS/BOGONS deny SPOOFING deny PROTOCOLS/PORTS permit BGP-PEERINGS permit TUNNELS deny INFRASTRUCTURE permit ANY If that's indeed the case, what non-routing protocols do you allow from/to these type of addresses? Only specific types of icmp messages? -- Tassos Dobbins, Roland wrote on 06/11/2012 14:05: > On Nov 6, 2012, at 6:32 PM, Tassos Chatzithomaoglou wrote: > >> Do you filter them on your border routers (via iACLs) > Yes. > >> and if yes, how? > The same way you filter any other interface addresses in your iACLs. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > From seth.mos at dds.nl Tue Nov 6 12:33:39 2012 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 06 Nov 2012 13:33:39 +0100 Subject: MTU issues s0.wp.com Message-ID: <509903A3.2070308@dds.nl> Hi, Since about a week or so it's become impossible to reach wp.com content over IPv6. IPv4 content does work fine, using the IPv6 literal returns a 404 which is small enough to fit in a smaller 1480 byte MTU. I have another test site that has a clean 1500 byte mtu and I can fetch the s0.wp.com page from there. It looks like tunneled IPv6 users might be in hurt here. Is anyone else experiencing similar issues? My traceroute shows they are employing a CDN for s0.wp.com, so not everyone might be affected. 7 asd2-rou-1022.NL.eurorings.net (2001:680:0:800f::291) 6.460 ms 6.203 ms 6.188 ms 8 asd2-rou-1044.eurorings.net (2001:680::134:222:85:63) 6.447 ms 6.494 ms 6.495 ms 9 adm-b5-link.telia.net (2001:2000:3080:6f::1) 6.818 ms 6.936 ms 6.891 ms 10 ldn-b3-v6.telia.net (2001:2000:3018:5::1) 15.290 ms 27.481 ms 15.380 ms 11 edgecast-ic-147468-ldn-b3.c.telia.net (2001:2000:3080:378::2) 15.116 ms 15.174 ms 15.176 ms 12 2606:2800:234:1922:15a7:17bf:bb7:f09 (2606:2800:234:1922:15a7:17bf:bb7:f09) 15.496 ms 15.327 ms 15.460 ms Kind regards, Seth From rdobbins at arbor.net Tue Nov 6 12:34:30 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 6 Nov 2012 12:34:30 +0000 Subject: p2p addresses for point-to-point connections with customers In-Reply-To: <50990310.8040107@forthnetgroup.gr> References: <5098F557.7060806@forthnetgroup.gr> <7B5C1FA0-1F62-4F84-AB4A-533FDDB1FF7D@arbor.net> <50990310.8040107@forthnetgroup.gr> Message-ID: On Nov 6, 2012, at 7:31 PM, Tassos Chatzithomaoglou wrote: > Only specific types of icmp messages? That, plus the routing session (if any) with your customer, plus anything else that's situationally-specific (GRE tunnel termination, etc.). ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From tmorizot at gmail.com Tue Nov 6 12:45:44 2012 From: tmorizot at gmail.com (Timothy Morizot) Date: Tue, 6 Nov 2012 06:45:44 -0600 Subject: MTU issues s0.wp.com In-Reply-To: <509903A3.2070308@dds.nl> References: <509903A3.2070308@dds.nl> Message-ID: On Nov 6, 2012 6:35 AM, "Seth Mos" wrote: > > Hi, > > Since about a week or so it's become impossible to reach wp.com content over IPv6. [snip] > It looks like tunneled IPv6 users might be in hurt here. > > Is anyone else experiencing similar issues? I've definitely had problems from my home network (HE tunnel) recently. I hadn't had time to look into it yet -- too swamped at work. But the above would be consistent with what I've seen. Scott From owen at delong.com Tue Nov 6 13:38:32 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Nov 2012 05:38:32 -0800 Subject: dhcpy6d - a MAC address aware DHCPv6 server In-Reply-To: <5097757E.5070307@ifw-dresden.de> References: <5097757E.5070307@ifw-dresden.de> Message-ID: If you're on local subnet, why not pull the MAC address out of the received packet? Further, what happens to this when IPv4 goes away? Owen On Nov 5, 2012, at 12:14 AM, Henri Wahl wrote: > Hello World, > like other people we had the problem that existing DHCPv6 servers do not > evaluate the MAC address of clients, following RFC 3315. The IPv4 > clients already are managed via their MAC addresses so we wanted to use > these identifiers for IPv6 too for our dualstack network. > > At the end we had to write our own DHCPv6 server dhcpy6d which I want to > present here to a larger audience. It runs on Linux, tested on Debian > and CentOS. It gets the client MAC addresses from neighbor cache by > calling "ip -6 neigh" and caches them itself, allowing to access the > already working MAC-based IPv4 infrastructure. This obviously only works > on the local subnet but might be worked around with several servers > being connected via database storage of clients and leases. > > Features are: > - identifies clients by MAC address, DUID or hostname > - generates addresses randomly, by MAC address, by range or by given ID > - filters clients by MAC, DUID or hostname > - assignes more than one address per client > - allows to organize clients in different classes > - stores leases in MySQL or SQLite database > - client information can be retrieved from database or textfile > - dynamically updates DNS (Bind) > > We run it with ~500 clients without problems. I am interested if it > would run in larger environments too. If not, how to make it running. > Bugs and ideas how to improve it are welcome too. > > Packages are not yet available but the Python code should run as is. > > See further details at http://dhcpy6d.ifw-dresden.de > > Best regards > Henri Wahl > > -- > Henri Wahl > > IT Department > Leibniz-Institut f?r Festk?rper- u. > Werkstoffforschung Dresden > > tel. (03 51) 46 59 - 797 > email: h.wahl at ifw-dresden.de > http://www.ifw-dresden.de > > Nagios status monitor for your desktop: > http://nagstamon.ifw-dresden.de > > IFW Dresden e.V., Helmholtzstra?e 20, D-01069 Dresden > VR Dresden Nr. 1369 > Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle > From achatz at forthnetgroup.gr Tue Nov 6 13:44:34 2012 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Tue, 06 Nov 2012 15:44:34 +0200 Subject: p2p addresses for point-to-point connections with customers In-Reply-To: References: <5098F557.7060806@forthnetgroup.gr> <7B5C1FA0-1F62-4F84-AB4A-533FDDB1FF7D@arbor.net> <50990310.8040107@forthnetgroup.gr> Message-ID: <50991442.3090900@forthnetgroup.gr> Roland, how do you handle customer requests regarding the remote management of their devices? i.e. if the customer wants to do any kind of management (ssh, snmp) from outside his router, he must use our infrastructure address (which is configured on his router) as a destination. Generally, the customer might want to use this wan address for many other things which you shouldn't actually care, since it's his router. -- Tassos Dobbins, Roland wrote on 06/11/2012 14:34: > On Nov 6, 2012, at 7:31 PM, Tassos Chatzithomaoglou wrote: > >> Only specific types of icmp messages? > That, plus the routing session (if any) with your customer, plus anything else that's situationally-specific (GRE tunnel termination, etc.). > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > > From bortzmeyer at nic.fr Tue Nov 6 13:49:29 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 6 Nov 2012 14:49:29 +0100 Subject: dhcpy6d - a MAC address aware DHCPv6 server In-Reply-To: References: <5097757E.5070307@ifw-dresden.de> Message-ID: <20121106134929.GA17574@nic.fr> On Tue, Nov 06, 2012 at 05:38:32AM -0800, Owen DeLong wrote a message of 68 lines which said: > If you're on local subnet, why not pull the MAC address out of the > received packet? Because it requires access to raw sockets, which should not be necessary for DHCP? From uwcableguy at gmail.com Tue Nov 6 14:02:12 2012 From: uwcableguy at gmail.com (Ben Bartsch) Date: Tue, 6 Nov 2012 08:02:12 -0600 Subject: AS 1668 BGP contact - possible prefix hijacking Message-ID: Hi: Is there anyone here who can help us with a possible prefix hijacking situation through ATDN? Please contact me off list if you (or you know somebody) that can help us. I've tried the ATDN NOC and Vikas, but they have been no help whatsoever. The hijacked prefix appears to be sent to AS 1668, then propagated from there. Thanks. Ben AS 32440 From sthaug at nethelp.no Tue Nov 6 14:03:39 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 06 Nov 2012 15:03:39 +0100 (CET) Subject: MTU issues s0.wp.com In-Reply-To: <509903A3.2070308@dds.nl> References: <509903A3.2070308@dds.nl> Message-ID: <20121106.150339.74706359.sthaug@nethelp.no> > Is anyone else experiencing similar issues? Not from here (AS 2116, Norway). No problem getting up the web page, tcpdump shows MSS 1440. > My traceroute shows they are employing a CDN for s0.wp.com, so not > everyone might be affected. > > 7 asd2-rou-1022.NL.eurorings.net (2001:680:0:800f::291) 6.460 ms > 6.203 ms 6.188 ms > 8 asd2-rou-1044.eurorings.net (2001:680::134:222:85:63) 6.447 ms > 6.494 ms 6.495 ms > 9 adm-b5-link.telia.net (2001:2000:3080:6f::1) 6.818 ms 6.936 ms > 6.891 ms > 10 ldn-b3-v6.telia.net (2001:2000:3018:5::1) 15.290 ms 27.481 ms > 15.380 ms > 11 edgecast-ic-147468-ldn-b3.c.telia.net (2001:2000:3080:378::2) > 15.116 ms 15.174 ms 15.176 ms > 12 2606:2800:234:1922:15a7:17bf:bb7:f09 > (2606:2800:234:1922:15a7:17bf:bb7:f09) 15.496 ms 15.327 ms 15.460 ms I have a clean 1500 byte path to s0.wp.com through Level3 and Telia: 1 ge0-0-0-10.ar1.skxy.no.catchbone.net (2001:8c0:9602:1::1) 7.937 ms 7.882 ms 10.373 ms 2 ge0-0-2.cr2.osls.as2116.net (2001:8c0:3::71) 9.745 ms 9.540 ms 9.117 ms 3 te3-0-0.br1.osls.as2116.net (2001:8c0:3::292) 10.352 ms 9.548 ms 9.733 ms 4 te-4-1.car1.Oslo1.Level3.net (2001:1900:5:2:1::99) 10.374 ms 9.023 ms 10.206 ms 5 ae-3-6.bar1.Copenhagen1.Level3.net (2001:1900:5:1::49) 18.002 ms 18.597 ms 14.754 ms 6 ae-0-10.bar1.Copenhagen2.Level3.net (2001:1900:5:1::1b6) 15.193 ms 19.215 ms 15.314 ms 7 kbn-b3-link.telia.net (2001:2000:3080:459::1) 20.434 ms 18.480 ms 15.821 ms 8 ldn-b3-v6.telia.net (2001:2000:3018:5::1) 41.915 ms 62.951 ms 39.543 ms 9 edgecast-ic-147468-ldn-b3.c.telia.net (2001:2000:3080:378::2) 40.656 ms 37.063 ms 37.683 ms 10 2606:2800:234:1922:15a7:17bf:bb7:f09 (2606:2800:234:1922:15a7:17bf:bb7:f09) 39.866 ms 39.443 ms 40.827 ms Steinar Haug, AS 2116 From jeroen at unfix.org Tue Nov 6 14:11:49 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 06 Nov 2012 15:11:49 +0100 Subject: MTU issues s0.wp.com In-Reply-To: <509903A3.2070308@dds.nl> References: <509903A3.2070308@dds.nl> Message-ID: <50991AA5.4080809@unfix.org> On 2012-11-06 13:33, Seth Mos wrote: > Hi, > > Since about a week or so it's become impossible to reach wp.com content > over IPv6. > > IPv4 content does work fine, using the IPv6 literal returns a 404 which > is small enough to fit in a smaller 1480 byte MTU. > > I have another test site that has a clean 1500 byte mtu and I can fetch > the s0.wp.com page from there. > > It looks like tunneled IPv6 users might be in hurt here. tracepath and scapy are the tools of choice here to determine where pMTU messages go missing. Also, it would be very useful to have a source address when reporting these issues as it might affect a lot of other paths too. Greets, Jeroen From brad.passwaters at gmail.com Tue Nov 6 14:27:24 2012 From: brad.passwaters at gmail.com (Brad Passwaters) Date: Tue, 6 Nov 2012 09:27:24 -0500 Subject: AS 1668 BGP contact - possible prefix hijacking In-Reply-To: References: Message-ID: Ben, We don't believe there is prefix hijacking. Due to various legal and contractual obligations there are certain questions you asked that we just can not answer. However I have asked an engineer to sanitize our internal audit and provide it to you. Also I'll reach out to you later today by phone and make sure that it answers your questions. Brad Passwaters - Director Production Networks at Aol (My Nanog participation predates my employment at Aol thus the use of a personal account) On Tue, Nov 6, 2012 at 9:02 AM, Ben Bartsch wrote: > Hi: > > Is there anyone here who can help us with a possible prefix hijacking > situation through ATDN? Please contact me off list if you (or you know > somebody) that can help us. I've tried the ATDN NOC and Vikas, but they > have been no help whatsoever. > > The hijacked prefix appears to be sent to AS 1668, then propagated from > there. > > Thanks. > > Ben > AS 32440 > -- Brad Passwaters ------------------------------------------ brad.passwaters at gmail.com From otis at ocosa.com Tue Nov 6 14:47:39 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Tue, 6 Nov 2012 08:47:39 -0600 Subject: p2p addresses for point-to-point connections with customers In-Reply-To: <50991442.3090900@forthnetgroup.gr> References: <5098F557.7060806@forthnetgroup.gr> <7B5C1FA0-1F62-4F84-AB4A-533FDDB1FF7D@arbor.net> <50990310.8040107@forthnetgroup.gr> <50991442.3090900@forthnetgroup.gr> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B017F0F@ocsbs.ocosa.com> We generally perform all the management needed for our customer's circuits. If the customer is wanting to remotely manage their own router and etc then you should adjust your iACL to grant the customer access only on the IP on their router interface not the whole /30 or etc. Or if you've routed an IP range to that customer they can use that and pick an IP for mgmt stuff from that range and let your infrastructure be at peace. ;) Also, if you are going to adjust your iACL for them you will want that customer to have a static IP address or range (not dynamic address) they are using to monitor/manage/access the infrastructure IP you've assigned on their router. Otis -----Original Message----- From: Tassos Chatzithomaoglou [mailto:achatz at forthnetgroup.gr] Sent: Tuesday, November 06, 2012 7:45 AM To: Dobbins, Roland Cc: NANOG list Subject: Re: p2p addresses for point-to-point connections with customers Roland, how do you handle customer requests regarding the remote management of their devices? i.e. if the customer wants to do any kind of management (ssh, snmp) from outside his router, he must use our infrastructure address (which is configured on his router) as a destination. Generally, the customer might want to use this wan address for many other things which you shouldn't actually care, since it's his router. From mjl at caida.org Tue Nov 6 15:46:43 2012 From: mjl at caida.org (Matthew Luckie) Date: Tue, 6 Nov 2012 07:46:43 -0800 Subject: MTU issues s0.wp.com In-Reply-To: <509903A3.2070308@dds.nl> Message-ID: <20121106154642.GA52743@spandex.luckie.org.nz> > Since about a week or so it's become impossible to reach wp.com content > over IPv6. > > IPv4 content does work fine, using the IPv6 literal returns a 404 which > is small enough to fit in a smaller 1480 byte MTU. > > I have another test site that has a clean 1500 byte mtu and I can fetch > the s0.wp.com page from there. > > It looks like tunneled IPv6 users might be in hurt here. Yes, a middlebox is discarding PTB messages before they reach the webserver: $ scamper -F ipfw -I "tbit -u 'http://s0.wp.com/' 2606:2800:220:1c85:99b:1b56:207e:ea5" tbit from 2001:48d0:101:501:d267:e5ff:fe14:a701 to 2606:2800:220:1c85:99b:1b56:207e:ea5 server-mss 1440, result: pmtud-fail app: http, url: http://s0.wp.com/ [ 0.048] TX SYN 64 seq = 0:0 [ 0.061] RX SYN/ACK 64 seq = 0:1 [ 0.099] TX 60 seq = 1:1 [ 0.148] TX 228 seq = 1:1(168) [ 0.161] RX 60 seq = 1:169 [ 0.162] RX 1500 seq = 1:169(1440) [ 0.162] RX 1500 seq = 1441:169(1440) [ 0.162] RX 1500 seq = 2881:169(1440) [ 0.162] RX 1500 seq = 4321:169(1440) [ 0.162] RX 1500 seq = 5761:169(1440) [ 0.162] RX 914 seq = 7201:169(854) [ 0.198] TX PTB 1280 mtu = 1280 [ 0.248] TX 60 seq = 169:1 [ 3.173] RX 1500 seq = 1:169(1440) [ 3.173] TX PTB 1280 mtu = 1280 [ 6.044] RX FIN 60 seq = 8055:169 [ 6.044] TX 60 seq = 169:1 [ 9.183] RX 1500 seq = 1:169(1440) [ 9.183] TX PTB 1280 mtu = 1280 [ 21.204] RX 1500 seq = 1:169(1440) [ 21.204] TX PTB 1280 mtu = 1280 [ 45.254] RX 1500 seq = 1:169(1440) From george.herbert at gmail.com Tue Nov 6 16:12:49 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 6 Nov 2012 08:12:49 -0800 Subject: dhcpy6d - a MAC address aware DHCPv6 server In-Reply-To: <20121106134929.GA17574@nic.fr> References: <5097757E.5070307@ifw-dresden.de> <20121106134929.GA17574@nic.fr> Message-ID: <12EF9311-B9FF-4E86-BB0E-E178C357FA89@gmail.com> Oh, horrors, part of my infrastructure needs raw socket data? We should ban that, for security. Who needs those pesky switches anyways? George William Herbert Sent from my iPhone On Nov 6, 2012, at 5:49 AM, Stephane Bortzmeyer wrote: > On Tue, Nov 06, 2012 at 05:38:32AM -0800, > Owen DeLong wrote > a message of 68 lines which said: > >> If you're on local subnet, why not pull the MAC address out of the >> received packet? > > Because it requires access to raw sockets, which should not be > necessary for DHCP? > > From eugen at leitl.org Tue Nov 6 16:44:00 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 6 Nov 2012 17:44:00 +0100 Subject: UK Scientists Claim to Develop 2000 Times Faster Broadband via Fibre Optic Message-ID: <20121106164400.GG9750@leitl.org> http://www.ispreview.co.uk/index.php/2012/11/uk-scientists-claim-to-develop-2000-times-faster-broadband-via-fibre-optic.html UK Scientists Claim to Develop 2000 Times Faster Broadband via Fibre Optic Posted Tuesday, November 6th, 2012 (11:08 am) by Mark Jackson (Score 746) A team of scientists working out of Bangor University in Wales has developed a commercially affordable method of using Optical Orthogonal Frequency Division Multiplexing (OOFDM) over fibre optic lines, which could deliver broadband ISP speeds that are 2,000 times faster than current services. But the three-year project (OCEAN) is not the first to make use of OOFDM, which typically splits a laser down to multiple different optical frequencies. The data can then be broken up and sent in parallel streams via the different frequencies. Last year a team of Sydney University scientists found an energy-efficient way of using a single laser to transfer data down a 50km long single-mode fibre optic cable at speeds of up to 26Tbps (Terabits per second). The key difference with OCEAN is that this work is capable of ?significantly saving the network installation and maintenance cost for both [ISPs] and equipment vendors? by using low-cost off-the-shelf components and end-to-end real-time OOFDM transceivers via currently installed fibre networks (FTTH etc.). It also provides a ?Green? solution due to the ?significant reduction in electrical power consumption?. The work is also more targeted towards home and business connections, as opposed to undersea cables, most of which tend to offer broadband speeds of less than 100Mbps; currently only a few UK FTTH ISPs offer up to 1Gbps and most suffer from very limited coverage. Professor Jianming Tang explained: ?Compared to today?s commercially available broadband connections, the technology is expected to provide end-users with both downloading and uploading speeds up to 2,000 times faster than current speeds and with a guaranteed quality of services at a price that subscribers are currently paying for their current 20Mb/s services, regardless of subscribers? home location. Obviously, this will revolutionise communication technology.? However there?s still the little matter of capacity supply costs and Traffic Management measures to consider, although the university?s efforts bode well for the future and could help a new generation of truly fibre optic ISPs to improve their service without incurring excessive additional costs. On the other hand most of today?s connections are still being delivered over older and slower copper based broadband lines. This is gradually beginning to change and the situation could look very different in another ten or twenty years? time. According to Bangor University, OCEAN is a partnership project (funded by the European Union (3m Euros+)) that includes several major global telecoms firms; Fujitsu Semiconductors Europe, Finisar Israel, Fraunhofer Heinrich Hertz Institute and VPIsystems GmbH. From bmanning at vacation.karoshi.com Tue Nov 6 17:20:38 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 6 Nov 2012 17:20:38 +0000 Subject: dhcpy6d - a MAC address aware DHCPv6 server In-Reply-To: References: <5097757E.5070307@ifw-dresden.de> Message-ID: <20121106172038.GA24162@vacation.karoshi.com.> On Tue, Nov 06, 2012 at 05:38:32AM -0800, Owen DeLong wrote: > If you're on local subnet, why not pull the MAC address out of the > received packet? > > Further, what happens to this when IPv4 goes away? > > Owen "the cat came back" ... IPv4 is going away like RIP is a dead routing protocol. give it another 20 years. /bill From h.wahl at ifw-dresden.de Tue Nov 6 14:11:25 2012 From: h.wahl at ifw-dresden.de (Henri Wahl) Date: Tue, 06 Nov 2012 15:11:25 +0100 Subject: dhcpy6d - a MAC address aware DHCPv6 server In-Reply-To: References: <5097757E.5070307@ifw-dresden.de> Message-ID: <50991A8D.9090208@ifw-dresden.de> Hi, > If you're on local subnet, why not pull the MAC address out of the > received packet? > The used SocketServer module of Python has no support for raw sockets, as far as I see. Let me know if there is a way to get the MAC in a cleaner way. > Further, what happens to this when IPv4 goes away? > Will that day ever come? :-) I think until this day a lot of RFCs will be written. This server here just allows to make transistion easier. And, it also allows the use of DUIDs, so it might work in an IPv6-only world. Regards Henri -- Henri Wahl IT Department Leibniz-Institut f?r Festk?rper- u. Werkstoffforschung Dresden tel. (03 51) 46 59 - 797 email: h.wahl at ifw-dresden.de http://www.ifw-dresden.de http://nagstamon.ifw-dresden.de http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstra?e 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4719 bytes Desc: S/MIME Kryptografische Unterschrift URL: From james at jgbaker.co.nz Tue Nov 6 22:38:26 2012 From: james at jgbaker.co.nz (James Baker) Date: Tue, 6 Nov 2012 22:38:26 +0000 Subject: p2p addresses for point-to-point connections with customers In-Reply-To: <50991442.3090900@forthnetgroup.gr> References: <5098F557.7060806@forthnetgroup.gr> <7B5C1FA0-1F62-4F84-AB4A-533FDDB1FF7D@arbor.net> <50990310.8040107@forthnetgroup.gr> <50991442.3090900@forthnetgroup.gr> Message-ID: <735EB08BFA483545A9035BEF8E4A03DF1CC749C8@SIXPRD0410MB396.apcprd04.prod.outlook.com> Well if you?re null routing the /30 then you or them should have a /32 or larger for NAT or no RFC space behind it. -----Original Message----- From: Tassos Chatzithomaoglou [mailto:achatz at forthnetgroup.gr] Sent: Wednesday, 7 November 2012 2:45 a.m. To: Dobbins, Roland Cc: NANOG list Subject: Re: p2p addresses for point-to-point connections with customers Roland, how do you handle customer requests regarding the remote management of their devices? i.e. if the customer wants to do any kind of management (ssh, snmp) from outside his router, he must use our infrastructure address (which is configured on his router) as a destination. Generally, the customer might want to use this wan address for many other things which you shouldn't actually care, since it's his router. -- Tassos Dobbins, Roland wrote on 06/11/2012 14:34: > On Nov 6, 2012, at 7:31 PM, Tassos Chatzithomaoglou wrote: > >> Only specific types of icmp messages? > That, plus the routing session (if any) with your customer, plus anything else that's situationally-specific (GRE tunnel termination, etc.). > > ---------------------------------------------------------------------- > - Roland Dobbins // > > > Luck is the residue of opportunity and design. > > -- John Milton > > > > From aj at sneep.net Tue Nov 6 22:44:25 2012 From: aj at sneep.net (Alastair Johnson) Date: Tue, 06 Nov 2012 14:44:25 -0800 Subject: p2p addresses for point-to-point connections with customers In-Reply-To: <50991442.3090900@forthnetgroup.gr> References: <5098F557.7060806@forthnetgroup.gr> <7B5C1FA0-1F62-4F84-AB4A-533FDDB1FF7D@arbor.net> <50990310.8040107@forthnetgroup.gr> <50991442.3090900@forthnetgroup.gr> Message-ID: <509992C9.6020704@sneep.net> On 11/6/2012 5:44 AM, Tassos Chatzithomaoglou wrote: > Roland, how do you handle customer requests regarding the remote management of their devices? > i.e. if the customer wants to do any kind of management (ssh, snmp) from outside his router, he must use our > infrastructure address (which is configured on his router) as a destination. > Generally, the customer might want to use this wan address for many other things which you shouldn't actually care, > since it's his router. Why would the customer not have a loopback interface configured on his router with an accessible IP address? Relying on the WAN address is arguably a poor choice for a number of reasons including renumbering events and circuit outages. From frnkblk at iname.com Wed Nov 7 00:55:48 2012 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 6 Nov 2012 18:55:48 -0600 Subject: Unable to reach www.t-online.de over IPv6 since late September Message-ID: <000001cdbc82$a0b50280$e21f0780$@iname.com> For 42 days we have not been able to reach www.t-online.de over IPv6. C:\>tracert -6 www.t-online.de Tracing route to www.t-online.de [2003:2:2:40:62:153:159:92] over a maximum of 30 hops: 1 4 ms 3 ms 2 ms router-core.mtcnet.net [2607:fe28:11:1000::2] 2 3 ms 3 ms 2 ms sxct.sxcy.mtcnet.net [2607:fe28:11:1002::197] 8 24 ms 23 ms 22 ms sl-crs2-chi-te1-2-0-1.v6.sprintlink.net [2600:4::6] 9 31 ms 30 ms 30 ms sl-crs2-akr-bu-2.v6.sprintlink.net [2600:0:2:1239:144:232:20:186] 10 41 ms 41 ms 39 ms sl-crs2-rly-bu-2.v6.sprintlink.net [2600:0:2:1239:144:232:4:187] 11 40 ms 40 ms 39 ms sl-crs2-dc-po0-9-0-0.v6.sprintlink.net [2600:0:2:1239:144:232:25:128] 12 42 ms 42 ms 41 ms sl-st31-ash-po0-2-0-0.v6.sprintlink.net [2600:0:2:1239:144:232:25:15] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. DT (Deutsche Telekom) is not learning our routes (AS53347) or the routes of our upstream provider (AS5056). DT's looking glass (https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg) confirms that: sh ipv6 bgp 2607:fe28::/32 % Network not in table sh ipv6 bgp 2001:05f8::/32 % Network not in table Our prefix goes over our upstream provider's transit link with Sprint, so on September 26 our upstream provider opened up a ticket with Sprint. From what our upstream provider tells us, Sprint is advertising our routes to DT but DT has an IPv6 prefix that is blocking all of Sprint's customer prefixes. It's almost been a month since the last substantive update from DT (via our upstream provider, via Sprint). If anybody is able to help and shake something loose at DT, that would be appreciated. For the right people, I can provide both Sprint and DT's ticket numbers. Thanks, Frank From rdobbins at arbor.net Wed Nov 7 02:08:01 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 7 Nov 2012 02:08:01 +0000 Subject: p2p addresses for point-to-point connections with customers In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017F0F@ocsbs.ocosa.com> References: <5098F557.7060806@forthnetgroup.gr> <7B5C1FA0-1F62-4F84-AB4A-533FDDB1FF7D@arbor.net> <50990310.8040107@forthnetgroup.gr> <50991442.3090900@forthnetgroup.gr> <5FE1FB6D43B8A647BBC821840C1AEA8B017F0F@ocsbs.ocosa.com> Message-ID: On Nov 6, 2012, at 9:47 PM, Otis L. Surratt, Jr. wrote: > Also, if you are going to adjust your iACL for them you will want that customer to have a static IP address or range (not dynamic address) they are using to monitor/manage/access the infrastructure IP you've assigned on their router. Yes, this is key. Management access to this router should not be possible from the public Internet at large. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From frnkblk at iname.com Wed Nov 7 02:48:05 2012 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 6 Nov 2012 20:48:05 -0600 Subject: Sandy seen costing telco, cable hundreds of millions of dollars In-Reply-To: <50975AB4.8060502@gmail.com> References: <50975AB4.8060502@gmail.com> Message-ID: <001301cdbc92$50352640$f09f72c0$@iname.com> The U.S. Federal Communications Commission said on Thursday that about 19 percent of towers were still offline that morning down from 25 percent the day after the storm. Verizon Wireless, a venture of Verizon Communications and Vodafone Group Plc, said on Thursday that about 96 percent of their cellsite were up and running, up from 94 percent the day before. Sprint, the No. 3 U.S. operator said that more than 80 percent of its network was operating by Thursday evening. T-Mobile USA, a unit of Deutsche Telekom, said it had completed 85 percent of its restoration in New York by Thursday evening. However it is only 80 percent complete in Staten Island, a borough of New York. So which wireless carrier is bringing down the average to 81%? Frank -----Original Message----- From: Roy [mailto:r.engehausen at gmail.com] Sent: Monday, November 05, 2012 12:21 AM To: nanog Subject: Sandy seen costing telco, cable hundreds of millions of dollars http://www.reuters.com/article/2012/11/01/storm-sandy-telecoms-idUSL1E8M1L9Z 20121101 From guxiaojian at gmail.com Wed Nov 7 04:48:55 2012 From: guxiaojian at gmail.com (Jian Gu) Date: Tue, 6 Nov 2012 20:48:55 -0800 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: Message-ID: What do you mean hijack? Google is peering with Moratel, if Google does not want Moratel to advertise its routes to Moratel's peers/upstreams, then Google should've set the correct BGP attributes in the first place. On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia wrote: > Another case of route hijack - > http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about > > > > I am curious if big networks have any pre-defined filters for big content > providers like Google to avoid these? I am sure internet community would be > working in direction to somehow prevent these issues. Curious to know > developments so far. > > > > > Thanks. > > > -- > > Anurag Bhatia > anuragbhatia.com > > Linkedin | > Twitter| > Google+ > From morrowc.lists at gmail.com Wed Nov 7 04:51:44 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Nov 2012 23:51:44 -0500 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: Message-ID: On Tue, Nov 6, 2012 at 11:48 PM, Jian Gu wrote: > What do you mean hijack? Google is peering with Moratel, if Google does not > want Moratel to advertise its routes to Moratel's peers/upstreams, then > Google should've set the correct BGP attributes in the first place. > curios to know which those are? From aj at jonesy.com.au Wed Nov 7 04:55:49 2012 From: aj at jonesy.com.au (Andrew Jones) Date: Wed, 07 Nov 2012 15:55:49 +1100 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: Message-ID: It's widely accepted that you only advertise your peers' routes to customers, and you only advertise your own, and your customers' routes to your upstreams. On 07.11.2012 15:48, Jian Gu wrote: > What do you mean hijack? Google is peering with Moratel, if Google > does not > want Moratel to advertise its routes to Moratel's peers/upstreams, > then > Google should've set the correct BGP attributes in the first place. > > On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia > wrote: > >> Another case of route hijack - >> >> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about >> >> >> >> I am curious if big networks have any pre-defined filters for big >> content >> providers like Google to avoid these? I am sure internet community >> would be >> working in direction to somehow prevent these issues. Curious to >> know >> developments so far. >> >> >> >> >> Thanks. >> >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> >> Linkedin | >> Twitter| >> Google+ >> From guxiaojian at gmail.com Wed Nov 7 04:58:10 2012 From: guxiaojian at gmail.com (Jian Gu) Date: Tue, 6 Nov 2012 20:58:10 -0800 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: Message-ID: By reading cloudflare blog, cloudflare network engineer discovered that Google's authoritative DNS server networks (including Google's public DNS 8.8.8.0/24) were being routed to Indonesia according their cloudflare's SF office edge router, this is werid unless cloudflare is doing something crazy on their edge router, given that those networks are heavily anycasted across the Internet, if cloudflare sees those networks are being routed to Indonesia from San Francisco, then a lot more people should've been affected. On Tue, Nov 6, 2012 at 8:51 PM, Christopher Morrow wrote: > On Tue, Nov 6, 2012 at 11:48 PM, Jian Gu wrote: > > What do you mean hijack? Google is peering with Moratel, if Google does > not > > want Moratel to advertise its routes to Moratel's peers/upstreams, then > > Google should've set the correct BGP attributes in the first place. > > > > curios to know which those are? > From patrick at ianai.net Wed Nov 7 05:02:19 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 7 Nov 2012 00:02:19 -0500 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: Message-ID: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> On Nov 06, 2012, at 23:48 , Jian Gu wrote: > What do you mean hijack? Google is peering with Moratel, if Google does not > want Moratel to advertise its routes to Moratel's peers/upstreams, then > Google should've set the correct BGP attributes in the first place. That doesn't make the slightest bit of sense. If a Moratel customer announced a Google-owned prefix to Moratel, and Moratel did not have the proper filters in place, there is nothing Google could do to stop the hijack from happening. Exactly what attribute do you think would stop this? -- TTFN, patrick > On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia wrote: > >> Another case of route hijack - >> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about >> >> >> >> I am curious if big networks have any pre-defined filters for big content >> providers like Google to avoid these? I am sure internet community would be >> working in direction to somehow prevent these issues. Curious to know >> developments so far. >> >> >> >> >> Thanks. >> >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> >> Linkedin | >> Twitter| >> Google+ >> > From guxiaojian at gmail.com Wed Nov 7 05:07:47 2012 From: guxiaojian at gmail.com (Jian Gu) Date: Tue, 6 Nov 2012 21:07:47 -0800 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> Message-ID: Where did you get the idea that a Moratel customer announced a google-owned prefix to Moratel and Moratel did not have the proper filters in place? according to the blog, all google's 4 authoritative DNS server networks and 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a Moratel customers announce all those prefixes? On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore wrote: > On Nov 06, 2012, at 23:48 , Jian Gu wrote: > > > What do you mean hijack? Google is peering with Moratel, if Google does > not > > want Moratel to advertise its routes to Moratel's peers/upstreams, then > > Google should've set the correct BGP attributes in the first place. > > That doesn't make the slightest bit of sense. > > If a Moratel customer announced a Google-owned prefix to Moratel, and > Moratel did not have the proper filters in place, there is nothing Google > could do to stop the hijack from happening. > > Exactly what attribute do you think would stop this? > > -- > TTFN, > patrick > > > > On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia > wrote: > > > >> Another case of route hijack - > >> > http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about > >> > >> > >> > >> I am curious if big networks have any pre-defined filters for big > content > >> providers like Google to avoid these? I am sure internet community > would be > >> working in direction to somehow prevent these issues. Curious to know > >> developments so far. > >> > >> > >> > >> > >> Thanks. > >> > >> > >> -- > >> > >> Anurag Bhatia > >> anuragbhatia.com > >> > >> Linkedin | > >> Twitter| > >> Google+ > >> > > > > > From steve.wilcox at ixreach.com Wed Nov 7 05:13:16 2012 From: steve.wilcox at ixreach.com (Stephen Wilcox) Date: Wed, 7 Nov 2012 05:13:16 +0000 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> Message-ID: Nobody said a Moratel customer announced a Google prefix, they said the issue was within Moratel. This is a really good article that explains the issue in detail, maybe read it again? http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about Steve On 7 November 2012 05:07, Jian Gu wrote: > Where did you get the idea that a Moratel customer announced a google-owned > prefix to Moratel and Moratel did not have the proper filters in place? > according to the blog, all google's 4 authoritative DNS server networks and > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a > Moratel customers announce all those prefixes? > > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore >wrote: > > > On Nov 06, 2012, at 23:48 , Jian Gu wrote: > > > > > What do you mean hijack? Google is peering with Moratel, if Google does > > not > > > want Moratel to advertise its routes to Moratel's peers/upstreams, then > > > Google should've set the correct BGP attributes in the first place. > > > > That doesn't make the slightest bit of sense. > > > > If a Moratel customer announced a Google-owned prefix to Moratel, and > > Moratel did not have the proper filters in place, there is nothing Google > > could do to stop the hijack from happening. > > > > Exactly what attribute do you think would stop this? > > > > -- > > TTFN, > > patrick > > > > > > > On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia > > wrote: > > > > > >> Another case of route hijack - > > >> > > http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about > > >> > > >> > > >> > > >> I am curious if big networks have any pre-defined filters for big > > content > > >> providers like Google to avoid these? I am sure internet community > > would be > > >> working in direction to somehow prevent these issues. Curious to know > > >> developments so far. > > >> > > >> > > >> > > >> > > >> Thanks. > > >> > > >> > > >> -- > > >> > > >> Anurag Bhatia > > >> anuragbhatia.com > > >> > > >> Linkedin | > > >> Twitter| > > >> Google+ > > >> > > > > > > > > > > From patrick at ianai.net Wed Nov 7 05:13:52 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 7 Nov 2012 00:13:52 -0500 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> Message-ID: <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> On Nov 07, 2012, at 00:07 , Jian Gu wrote: > Where did you get the idea that a Moratel customer announced a google-owned > prefix to Moratel and Moratel did not have the proper filters in place? > according to the blog, all google's 4 authoritative DNS server networks and > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a > Moratel customers announce all those prefixes? Ah, right, they just leaked Google's prefix. I thought a customer originated the prefix. Original question still stands. Which attribute do you expect Google to set to stop this? Hint: Don't say No-Advertise, unless you want peers to only talk to the adjacent AS, not their customers or their customers' customers, etc. Looking forward to your answer. -- TTFN, patrick > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore wrote: > >> On Nov 06, 2012, at 23:48 , Jian Gu wrote: >> >>> What do you mean hijack? Google is peering with Moratel, if Google does >> not >>> want Moratel to advertise its routes to Moratel's peers/upstreams, then >>> Google should've set the correct BGP attributes in the first place. >> >> That doesn't make the slightest bit of sense. >> >> If a Moratel customer announced a Google-owned prefix to Moratel, and >> Moratel did not have the proper filters in place, there is nothing Google >> could do to stop the hijack from happening. >> >> Exactly what attribute do you think would stop this? >> >> -- >> TTFN, >> patrick >> >> >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia >> wrote: >>> >>>> Another case of route hijack - >>>> >> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about >>>> >>>> >>>> >>>> I am curious if big networks have any pre-defined filters for big >> content >>>> providers like Google to avoid these? I am sure internet community >> would be >>>> working in direction to somehow prevent these issues. Curious to know >>>> developments so far. >>>> >>>> >>>> >>>> >>>> Thanks. >>>> >>>> >>>> -- >>>> >>>> Anurag Bhatia >>>> anuragbhatia.com >>>> >>>> Linkedin | >>>> Twitter| >>>> Google+ >>>> >>> >> >> >> From guxiaojian at gmail.com Wed Nov 7 05:21:56 2012 From: guxiaojian at gmail.com (Jian Gu) Date: Tue, 6 Nov 2012 21:21:56 -0800 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> Message-ID: I don't know what Google and Moratel's peering agreement, but "leak"? educate me, Google is announcing /24 for all of their 4 NS prefix and 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes to Internet? On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore wrote: > On Nov 07, 2012, at 00:07 , Jian Gu wrote: > > > Where did you get the idea that a Moratel customer announced a > google-owned > > prefix to Moratel and Moratel did not have the proper filters in place? > > according to the blog, all google's 4 authoritative DNS server networks > and > > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a > > Moratel customers announce all those prefixes? > > Ah, right, they just leaked Google's prefix. I thought a customer > originated the prefix. > > Original question still stands. Which attribute do you expect Google to > set to stop this? > > Hint: Don't say No-Advertise, unless you want peers to only talk to the > adjacent AS, not their customers or their customers' customers, etc. > > Looking forward to your answer. > > -- > TTFN, > patrick > > > > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore >wrote: > > > >> On Nov 06, 2012, at 23:48 , Jian Gu wrote: > >> > >>> What do you mean hijack? Google is peering with Moratel, if Google does > >> not > >>> want Moratel to advertise its routes to Moratel's peers/upstreams, then > >>> Google should've set the correct BGP attributes in the first place. > >> > >> That doesn't make the slightest bit of sense. > >> > >> If a Moratel customer announced a Google-owned prefix to Moratel, and > >> Moratel did not have the proper filters in place, there is nothing > Google > >> could do to stop the hijack from happening. > >> > >> Exactly what attribute do you think would stop this? > >> > >> -- > >> TTFN, > >> patrick > >> > >> > >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia > >> wrote: > >>> > >>>> Another case of route hijack - > >>>> > >> > http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about > >>>> > >>>> > >>>> > >>>> I am curious if big networks have any pre-defined filters for big > >> content > >>>> providers like Google to avoid these? I am sure internet community > >> would be > >>>> working in direction to somehow prevent these issues. Curious to know > >>>> developments so far. > >>>> > >>>> > >>>> > >>>> > >>>> Thanks. > >>>> > >>>> > >>>> -- > >>>> > >>>> Anurag Bhatia > >>>> anuragbhatia.com > >>>> > >>>> Linkedin | > >>>> Twitter| > >>>> Google+ > >>>> > >>> > >> > >> > >> > > > From patrick at ianai.net Wed Nov 7 05:26:59 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 7 Nov 2012 00:26:59 -0500 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> Message-ID: <6CC95916-4964-4A1A-9CFC-8F579ADF1FF0@ianai.net> On Nov 07, 2012, at 00:21 , Jian Gu wrote: > I don't know what Google and Moratel's peering agreement, but "leak"? > educate me, Google is announcing /24 for all of their 4 NS prefix and > 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes > to Internet? Downthread, someone said what is typical with peering prefixes, i.e. announce to customers, not to peers or upstreams. How do you think peering works? However, I place most of the blame on PCCW for crappy filtering of their customers. And I'm a little surprised to see nLayer in the path. Shame on them! (Does that have any effect any more? :) Oh, and we are still waiting for an answer: Which attribute do you think Google could have used to stop this? -- TTFN, patrick > On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore wrote: > >> On Nov 07, 2012, at 00:07 , Jian Gu wrote: >> >>> Where did you get the idea that a Moratel customer announced a >> google-owned >>> prefix to Moratel and Moratel did not have the proper filters in place? >>> according to the blog, all google's 4 authoritative DNS server networks >> and >>> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a >>> Moratel customers announce all those prefixes? >> >> Ah, right, they just leaked Google's prefix. I thought a customer >> originated the prefix. >> >> Original question still stands. Which attribute do you expect Google to >> set to stop this? >> >> Hint: Don't say No-Advertise, unless you want peers to only talk to the >> adjacent AS, not their customers or their customers' customers, etc. >> >> Looking forward to your answer. >> >> -- >> TTFN, >> patrick >> >> >>> On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore >> wrote: >>> >>>> On Nov 06, 2012, at 23:48 , Jian Gu wrote: >>>> >>>>> What do you mean hijack? Google is peering with Moratel, if Google does >>>> not >>>>> want Moratel to advertise its routes to Moratel's peers/upstreams, then >>>>> Google should've set the correct BGP attributes in the first place. >>>> >>>> That doesn't make the slightest bit of sense. >>>> >>>> If a Moratel customer announced a Google-owned prefix to Moratel, and >>>> Moratel did not have the proper filters in place, there is nothing >> Google >>>> could do to stop the hijack from happening. >>>> >>>> Exactly what attribute do you think would stop this? >>>> >>>> -- >>>> TTFN, >>>> patrick >>>> >>>> >>>>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia >>>> wrote: >>>>> >>>>>> Another case of route hijack - >>>>>> >>>> >> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about >>>>>> >>>>>> >>>>>> >>>>>> I am curious if big networks have any pre-defined filters for big >>>> content >>>>>> providers like Google to avoid these? I am sure internet community >>>> would be >>>>>> working in direction to somehow prevent these issues. Curious to know >>>>>> developments so far. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Anurag Bhatia >>>>>> anuragbhatia.com >>>>>> >>>>>> Linkedin | >>>>>> Twitter| >>>>>> Google+ >>>>>> >>>>> >>>> >>>> >>>> >> >> >> From hank at efes.iucc.ac.il Wed Nov 7 05:30:18 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 07 Nov 2012 07:30:18 +0200 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: Message-ID: <5.1.1.6.2.20121107072847.002ef7b8@efes.iucc.ac.il> At 20:48 06/11/2012 -0800, Jian Gu wrote: Ahhh...blame the victim. Google - shame on you. -Hank >What do you mean hijack? Google is peering with Moratel, if Google does not >want Moratel to advertise its routes to Moratel's peers/upstreams, then >Google should've set the correct BGP attributes in the first place. > >On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia wrote: > > > Another case of route hijack - > > http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about > > > > > > > > I am curious if big networks have any pre-defined filters for big content > > providers like Google to avoid these? I am sure internet community would be > > working in direction to somehow prevent these issues. Curious to know > > developments so far. > > > > > > > > > > Thanks. > > > > > > -- > > > > Anurag Bhatia > > anuragbhatia.com > > > > Linkedin | > > Twitter| > > Google+ > > From hank at efes.iucc.ac.il Wed Nov 7 05:33:22 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 07 Nov 2012 07:33:22 +0200 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> Message-ID: <5.1.1.6.2.20121107073100.00303948@efes.iucc.ac.il> At 21:21 06/11/2012 -0800, Jian Gu wrote: If Google announces 8.8.8.0/24 to you and you in turn start announcing to the Internet 8.8.8.0/24 as originating from you, then a certain section of the Internet will believe your announcement over Google's. This has happened many times before due to improper filters, but this is the first time I have seen the victim being blamed. Interesting concept. -Hank >I don't know what Google and Moratel's peering agreement, but "leak"? >educate me, Google is announcing /24 for all of their 4 NS prefix and >8.8.8.0/24 for their public DNS server, how did Moratel leak those routes >to Internet? > >On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore wrote: > > > On Nov 07, 2012, at 00:07 , Jian Gu wrote: > > > > > Where did you get the idea that a Moratel customer announced a > > google-owned > > > prefix to Moratel and Moratel did not have the proper filters in place? > > > according to the blog, all google's 4 authoritative DNS server networks > > and > > > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a > > > Moratel customers announce all those prefixes? > > > > Ah, right, they just leaked Google's prefix. I thought a customer > > originated the prefix. > > > > Original question still stands. Which attribute do you expect Google to > > set to stop this? > > > > Hint: Don't say No-Advertise, unless you want peers to only talk to the > > adjacent AS, not their customers or their customers' customers, etc. > > > > Looking forward to your answer. > > > > -- > > TTFN, > > patrick > > > > > > > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore > >wrote: > > > > > >> On Nov 06, 2012, at 23:48 , Jian Gu wrote: > > >> > > >>> What do you mean hijack? Google is peering with Moratel, if Google does > > >> not > > >>> want Moratel to advertise its routes to Moratel's peers/upstreams, then > > >>> Google should've set the correct BGP attributes in the first place. > > >> > > >> That doesn't make the slightest bit of sense. > > >> > > >> If a Moratel customer announced a Google-owned prefix to Moratel, and > > >> Moratel did not have the proper filters in place, there is nothing > > Google > > >> could do to stop the hijack from happening. > > >> > > >> Exactly what attribute do you think would stop this? > > >> > > >> -- > > >> TTFN, > > >> patrick > > >> > > >> > > >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia > > >> wrote: > > >>> > > >>>> Another case of route hijack - > > >>>> > > >> > > http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about > > >>>> > > >>>> > > >>>> > > >>>> I am curious if big networks have any pre-defined filters for big > > >> content > > >>>> providers like Google to avoid these? I am sure internet community > > >> would be > > >>>> working in direction to somehow prevent these issues. Curious to know > > >>>> developments so far. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Thanks. > > >>>> > > >>>> > > >>>> -- > > >>>> > > >>>> Anurag Bhatia > > >>>> anuragbhatia.com > > >>>> > > >>>> Linkedin | > > >>>> Twitter| > > >>>> Google+ > > >>>> > > >>> > > >> > > >> > > >> > > > > > > From guxiaojian at gmail.com Wed Nov 7 05:35:26 2012 From: guxiaojian at gmail.com (Jian Gu) Date: Tue, 6 Nov 2012 21:35:26 -0800 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: <5.1.1.6.2.20121107073100.00303948@efes.iucc.ac.il> References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <5.1.1.6.2.20121107073100.00303948@efes.iucc.ac.il> Message-ID: Hmm, look at this screen shot from the blog, 8.8.8.0/24 was orignated from Google. tom at edge01.sfo01> show route 8.8.8.8 inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, 14 hidden) + = Active Route, - = Last Active, * = Both 8.8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100 AS path: 4436 3491 23947 15169 I > to 69.22.153.1 via ge-1/0/9.0 On Tue, Nov 6, 2012 at 9:33 PM, Hank Nussbacher wrote: > At 21:21 06/11/2012 -0800, Jian Gu wrote: > > If Google announces 8.8.8.0/24 to you and you in turn start announcing to > the Internet 8.8.8.0/24 as originating from you, then a certain section > of the Internet will believe your announcement over Google's. This has > happened many times before due to improper filters, but this is the first > time I have seen the victim being blamed. Interesting concept. > > -Hank > > I don't know what Google and Moratel's peering agreement, but "leak"? >> educate me, Google is announcing /24 for all of their 4 NS prefix and >> 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes >> to Internet? >> >> On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore > >wrote: >> >> >> > On Nov 07, 2012, at 00:07 , Jian Gu wrote: >> > >> > > Where did you get the idea that a Moratel customer announced a >> > google-owned >> > > prefix to Moratel and Moratel did not have the proper filters in >> place? >> > > according to the blog, all google's 4 authoritative DNS server >> networks >> > and >> > > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for >> a >> > > Moratel customers announce all those prefixes? >> > >> > Ah, right, they just leaked Google's prefix. I thought a customer >> > originated the prefix. >> > >> > Original question still stands. Which attribute do you expect Google to >> > set to stop this? >> > >> > Hint: Don't say No-Advertise, unless you want peers to only talk to the >> > adjacent AS, not their customers or their customers' customers, etc. >> > >> > Looking forward to your answer. >> > >> > -- >> > TTFN, >> > patrick >> > >> > >> > > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore > > >wrote: >> > > >> > >> On Nov 06, 2012, at 23:48 , Jian Gu wrote: >> > >> >> > >>> What do you mean hijack? Google is peering with Moratel, if Google >> does >> > >> not >> > >>> want Moratel to advertise its routes to Moratel's peers/upstreams, >> then >> > >>> Google should've set the correct BGP attributes in the first place. >> > >> >> > >> That doesn't make the slightest bit of sense. >> > >> >> > >> If a Moratel customer announced a Google-owned prefix to Moratel, and >> > >> Moratel did not have the proper filters in place, there is nothing >> > Google >> > >> could do to stop the hijack from happening. >> > >> >> > >> Exactly what attribute do you think would stop this? >> > >> >> > >> -- >> > >> TTFN, >> > >> patrick >> > >> >> > >> >> > >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia >> > >> wrote: >> > >>> >> > >>>> Another case of route hijack - >> > >>>> >> > >> >> > http://blog.cloudflare.com/**why-google-went-offline-today-** >> and-a-bit-about >> > >>>> >> > >>>> >> > >>>> >> > >>>> I am curious if big networks have any pre-defined filters for big >> > >> content >> > >>>> providers like Google to avoid these? I am sure internet community >> > >> would be >> > >>>> working in direction to somehow prevent these issues. Curious to >> know >> > >>>> developments so far. >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> Thanks. >> > >>>> >> > >>>> >> > >>>> -- >> > >>>> >> > >>>> Anurag Bhatia >> > >>>> anuragbhatia.com >> > >>>> >> > >>>> Linkedin > >> | >> > >>>> Twitter >> >| >> > >>>> Google+ >> > >> > >>>> >> > >>> >> > >> >> > >> >> > >> >> > >> > >> > >> > > From patrick at ianai.net Wed Nov 7 05:45:19 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 7 Nov 2012 00:45:19 -0500 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <5.1.1.6.2.20121107073100.00303948@efes.iucc.ac.il> Message-ID: On Nov 07, 2012, at 00:35 , Jian Gu wrote: > Hmm, look at this screen shot from the blog, 8.8.8.0/24 was orignated from > Google. Everyone who posted in this thread was well aware of that. (Well, except me in my first post. :) Google was still the victim, and it was still not their fault. You are showing wide and clear ignorance on the basics of peering. Which is fine, the vast majority of the planet hasn't a clue what peering is. However, the rest of the people who do not know what they are talking about have managed to avoid commenting on the subject to 10K+ of their not-so-closest friends. To be clear, if you had started with something like: "Why is Google originating the route? Doesn't that make it valid?", you would have gotten a lot of help & support. But instead you started by claiming it was Google's fault and they could stop this by setting "the correct BGP attributes". I note you still haven't told us what those attributes would be despite repeated questions. Perhaps it's time to admit you don't know what attributes, and you need a little more education on peering in general? When you find yourself in a hole, stop digging. -- TTFN, patrick > tom at edge01.sfo01> show route 8.8.8.8 > > inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, > 14 hidden) > + = Active Route, - = Last Active, * = Both > 8.8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100 > AS path: 4436 3491 23947 15169 I >> to 69.22.153.1 via ge-1/0/9.0 > > > > On Tue, Nov 6, 2012 at 9:33 PM, Hank Nussbacher wrote: > >> At 21:21 06/11/2012 -0800, Jian Gu wrote: >> >> If Google announces 8.8.8.0/24 to you and you in turn start announcing to >> the Internet 8.8.8.0/24 as originating from you, then a certain section >> of the Internet will believe your announcement over Google's. This has >> happened many times before due to improper filters, but this is the first >> time I have seen the victim being blamed. Interesting concept. >> >> -Hank >> >> I don't know what Google and Moratel's peering agreement, but "leak"? >>> educate me, Google is announcing /24 for all of their 4 NS prefix and >>> 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes >>> to Internet? >>> >>> On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore >>> wrote: >>> >>> >>>> On Nov 07, 2012, at 00:07 , Jian Gu wrote: >>>> >>>>> Where did you get the idea that a Moratel customer announced a >>>> google-owned >>>>> prefix to Moratel and Moratel did not have the proper filters in >>> place? >>>>> according to the blog, all google's 4 authoritative DNS server >>> networks >>>> and >>>>> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for >>> a >>>>> Moratel customers announce all those prefixes? >>>> >>>> Ah, right, they just leaked Google's prefix. I thought a customer >>>> originated the prefix. >>>> >>>> Original question still stands. Which attribute do you expect Google to >>>> set to stop this? >>>> >>>> Hint: Don't say No-Advertise, unless you want peers to only talk to the >>>> adjacent AS, not their customers or their customers' customers, etc. >>>> >>>> Looking forward to your answer. >>>> >>>> -- >>>> TTFN, >>>> patrick >>>> >>>> >>>>> On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore >>>> wrote: >>>>> >>>>>> On Nov 06, 2012, at 23:48 , Jian Gu wrote: >>>>>> >>>>>>> What do you mean hijack? Google is peering with Moratel, if Google >>> does >>>>>> not >>>>>>> want Moratel to advertise its routes to Moratel's peers/upstreams, >>> then >>>>>>> Google should've set the correct BGP attributes in the first place. >>>>>> >>>>>> That doesn't make the slightest bit of sense. >>>>>> >>>>>> If a Moratel customer announced a Google-owned prefix to Moratel, and >>>>>> Moratel did not have the proper filters in place, there is nothing >>>> Google >>>>>> could do to stop the hijack from happening. >>>>>> >>>>>> Exactly what attribute do you think would stop this? >>>>>> >>>>>> -- >>>>>> TTFN, >>>>>> patrick >>>>>> >>>>>> >>>>>>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia >>>>>> wrote: >>>>>>> >>>>>>>> Another case of route hijack - >>>>>>>> >>>>>> >>>> http://blog.cloudflare.com/**why-google-went-offline-today-** >>> and-a-bit-about >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I am curious if big networks have any pre-defined filters for big >>>>>> content >>>>>>>> providers like Google to avoid these? I am sure internet community >>>>>> would be >>>>>>>> working in direction to somehow prevent these issues. Curious to >>> know >>>>>>>> developments so far. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Anurag Bhatia >>>>>>>> anuragbhatia.com >>>>>>>> >>>>>>>> Linkedin > >>> | >>>>>>>> Twitter >>>> | >>>>>>>> Google+ >>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >> >> From joelja at bogus.com Wed Nov 7 05:48:45 2012 From: joelja at bogus.com (joel jaeggli) Date: Wed, 07 Nov 2012 00:48:45 -0500 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> Message-ID: <5099F63D.5090708@bogus.com> On 11/7/12 12:13 AM, Patrick W. Gilmore wrote: > On Nov 07, 2012, at 00:07 , Jian Gu wrote: > >> Where did you get the idea that a Moratel customer announced a google-owned >> prefix to Moratel and Moratel did not have the proper filters in place? >> according to the blog, all google's 4 authoritative DNS server networks and >> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a >> Moratel customers announce all those prefixes? > Ah, right, they just leaked Google's prefix. I thought a customer originated the prefix. > > Original question still stands. Which attribute do you expect Google to set to stop this? > > Hint: Don't say No-Advertise, unless you want peers to only talk to the adjacent AS, not their customers or their customers' customers, etc. > > Looking forward to your answer. I would expect that moratel should have a route object which their transit providers can construct a prefix filter for. if moratel advertised an AS path including themselves and a google orgin pccw should not have accepted it. if they originated the prefix, pccw should not have accepted it. From aj at jonesy.com.au Wed Nov 7 05:54:45 2012 From: aj at jonesy.com.au (Andrew Jones) Date: Wed, 07 Nov 2012 16:54:45 +1100 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: <5.1.1.6.2.20121107073100.00303948@efes.iucc.ac.il> References: <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <5.1.1.6.2.20121107073100.00303948@efes.iucc.ac.il> Message-ID: <593c63ef732ef8338fb670199d7f69f9@jonesy.com.au> It looks like nLayer have routes learned through Moratel which have local-pref set to anywhere up to 250 (learned from private peers), while the routes learned from direct peering relationships to Google on public peering have a local-pref of 200. This explains why the routes from Moratel would have been preferred during the period when they were being leaked, despite the shorter as-path (but doesn't explain why they weren't being filtered). On 07.11.2012 16:33, Hank Nussbacher wrote: > At 21:21 06/11/2012 -0800, Jian Gu wrote: > > If Google announces 8.8.8.0/24 to you and you in turn start > announcing to the Internet 8.8.8.0/24 as originating from you, then a > certain section of the Internet will believe your announcement over > Google's. This has happened many times before due to improper > filters, but this is the first time I have seen the victim being > blamed. Interesting concept. > > -Hank > >>I don't know what Google and Moratel's peering agreement, but "leak"? >>educate me, Google is announcing /24 for all of their 4 NS prefix and >>8.8.8.0/24 for their public DNS server, how did Moratel leak those >> routes >>to Internet? >> >>On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore >> wrote: >> >> > On Nov 07, 2012, at 00:07 , Jian Gu wrote: >> > >> > > Where did you get the idea that a Moratel customer announced a >> > google-owned >> > > prefix to Moratel and Moratel did not have the proper filters in >> place? >> > > according to the blog, all google's 4 authoritative DNS server >> networks >> > and >> > > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity >> for a >> > > Moratel customers announce all those prefixes? >> > >> > Ah, right, they just leaked Google's prefix. I thought a customer >> > originated the prefix. >> > >> > Original question still stands. Which attribute do you expect >> Google to >> > set to stop this? >> > >> > Hint: Don't say No-Advertise, unless you want peers to only talk >> to the >> > adjacent AS, not their customers or their customers' customers, >> etc. >> > >> > Looking forward to your answer. >> > >> > -- >> > TTFN, >> > patrick >> > >> > >> > > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore >> > > >wrote: >> > > >> > >> On Nov 06, 2012, at 23:48 , Jian Gu >> wrote: >> > >> >> > >>> What do you mean hijack? Google is peering with Moratel, if >> Google does >> > >> not >> > >>> want Moratel to advertise its routes to Moratel's >> peers/upstreams, then >> > >>> Google should've set the correct BGP attributes in the first >> place. >> > >> >> > >> That doesn't make the slightest bit of sense. >> > >> >> > >> If a Moratel customer announced a Google-owned prefix to >> Moratel, and >> > >> Moratel did not have the proper filters in place, there is >> nothing >> > Google >> > >> could do to stop the hijack from happening. >> > >> >> > >> Exactly what attribute do you think would stop this? >> > >> >> > >> -- >> > >> TTFN, >> > >> patrick >> > >> >> > >> >> > >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia >> >> > >> wrote: >> > >>> >> > >>>> Another case of route hijack - >> > >>>> >> > >> >> > >> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about >> > >>>> >> > >>>> >> > >>>> >> > >>>> I am curious if big networks have any pre-defined filters for >> big >> > >> content >> > >>>> providers like Google to avoid these? I am sure internet >> community >> > >> would be >> > >>>> working in direction to somehow prevent these issues. Curious >> to know >> > >>>> developments so far. >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> Thanks. >> > >>>> >> > >>>> >> > >>>> -- >> > >>>> >> > >>>> Anurag Bhatia >> > >>>> anuragbhatia.com >> > >>>> >> > >>>> Linkedin | >> > >>>> Twitter| >> > >>>> Google+ >> > >>>> >> > >>> >> > >> >> > >> >> > >> >> > >> > >> > From me at anuragbhatia.com Wed Nov 7 06:29:10 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 7 Nov 2012 11:59:10 +0530 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: <5099F63D.5090708@bogus.com> References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <5099F63D.5090708@bogus.com> Message-ID: Apologize for calling it an prefix hijack. I misunderstood in start. Clearly it was case of prefix leaking. Thanks (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Nov 7, 2012 11:22 AM, "joel jaeggli" wrote: > On 11/7/12 12:13 AM, Patrick W. Gilmore wrote: > >> On Nov 07, 2012, at 00:07 , Jian Gu wrote: >> >> Where did you get the idea that a Moratel customer announced a >>> google-owned >>> prefix to Moratel and Moratel did not have the proper filters in place? >>> according to the blog, all google's 4 authoritative DNS server networks >>> and >>> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a >>> Moratel customers announce all those prefixes? >>> >> Ah, right, they just leaked Google's prefix. I thought a customer >> originated the prefix. >> >> Original question still stands. Which attribute do you expect Google to >> set to stop this? >> >> Hint: Don't say No-Advertise, unless you want peers to only talk to the >> adjacent AS, not their customers or their customers' customers, etc. >> >> Looking forward to your answer. >> > > I would expect that moratel should have a route object which their transit > providers can construct a prefix filter for. if moratel advertised an AS > path including themselves and a google orgin pccw should not have accepted > it. if they originated the prefix, pccw should not have accepted it. > > > From guxiaojian at gmail.com Wed Nov 7 07:30:27 2012 From: guxiaojian at gmail.com (Jian Gu) Date: Tue, 6 Nov 2012 23:30:27 -0800 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <5.1.1.6.2.20121107073100.00303948@efes.iucc.ac.il> Message-ID: Dear Mr. Know-Peering, I came here to learn and I believe I have the right to say what I was thinking, no matter how ignorant my comment was. I don't have the right to blame anybody, in fact I don't give a damn whose fault it is, it is not my business. I apologize if I offended you when you claimed that it was a hijacking. On Tue, Nov 6, 2012 at 9:45 PM, Patrick W. Gilmore wrote: > On Nov 07, 2012, at 00:35 , Jian Gu wrote: > > > Hmm, look at this screen shot from the blog, 8.8.8.0/24 was orignated > from > > Google. > > Everyone who posted in this thread was well aware of that. (Well, except > me in my first post. :) Google was still the victim, and it was still not > their fault. > > You are showing wide and clear ignorance on the basics of peering. Which > is fine, the vast majority of the planet hasn't a clue what peering is. > However, the rest of the people who do not know what they are talking > about have managed to avoid commenting on the subject to 10K+ of their > not-so-closest friends. > > To be clear, if you had started with something like: "Why is Google > originating the route? Doesn't that make it valid?", you would have gotten > a lot of help & support. But instead you started by claiming it was > Google's fault and they could stop this by setting "the correct BGP > attributes". I note you still haven't told us what those attributes would > be despite repeated questions. > > Perhaps it's time to admit you don't know what attributes, and you need a > little more education on peering in general? > > When you find yourself in a hole, stop digging. > > -- > TTFN, > patrick > > > > tom at edge01.sfo01> show route 8.8.8.8 > > > > inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, > > 14 hidden) > > + = Active Route, - = Last Active, * = Both > > 8.8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100 > > AS path: 4436 3491 23947 15169 I > >> to 69.22.153.1 via ge-1/0/9.0 > > > > > > > > On Tue, Nov 6, 2012 at 9:33 PM, Hank Nussbacher >wrote: > > > >> At 21:21 06/11/2012 -0800, Jian Gu wrote: > >> > >> If Google announces 8.8.8.0/24 to you and you in turn start announcing > to > >> the Internet 8.8.8.0/24 as originating from you, then a certain section > >> of the Internet will believe your announcement over Google's. This > has > >> happened many times before due to improper filters, but this is the > first > >> time I have seen the victim being blamed. Interesting concept. > >> > >> -Hank > >> > >> I don't know what Google and Moratel's peering agreement, but "leak"? > >>> educate me, Google is announcing /24 for all of their 4 NS prefix and > >>> 8.8.8.0/24 for their public DNS server, how did Moratel leak those > routes > >>> to Internet? > >>> > >>> On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore >>>> wrote: > >>> > >>> > >>>> On Nov 07, 2012, at 00:07 , Jian Gu wrote: > >>>> > >>>>> Where did you get the idea that a Moratel customer announced a > >>>> google-owned > >>>>> prefix to Moratel and Moratel did not have the proper filters in > >>> place? > >>>>> according to the blog, all google's 4 authoritative DNS server > >>> networks > >>>> and > >>>>> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for > >>> a > >>>>> Moratel customers announce all those prefixes? > >>>> > >>>> Ah, right, they just leaked Google's prefix. I thought a customer > >>>> originated the prefix. > >>>> > >>>> Original question still stands. Which attribute do you expect Google > to > >>>> set to stop this? > >>>> > >>>> Hint: Don't say No-Advertise, unless you want peers to only talk to > the > >>>> adjacent AS, not their customers or their customers' customers, etc. > >>>> > >>>> Looking forward to your answer. > >>>> > >>>> -- > >>>> TTFN, > >>>> patrick > >>>> > >>>> > >>>>> On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore < > patrick at ianai.net > >>>>> wrote: > >>>>> > >>>>>> On Nov 06, 2012, at 23:48 , Jian Gu wrote: > >>>>>> > >>>>>>> What do you mean hijack? Google is peering with Moratel, if Google > >>> does > >>>>>> not > >>>>>>> want Moratel to advertise its routes to Moratel's peers/upstreams, > >>> then > >>>>>>> Google should've set the correct BGP attributes in the first place. > >>>>>> > >>>>>> That doesn't make the slightest bit of sense. > >>>>>> > >>>>>> If a Moratel customer announced a Google-owned prefix to Moratel, > and > >>>>>> Moratel did not have the proper filters in place, there is nothing > >>>> Google > >>>>>> could do to stop the hijack from happening. > >>>>>> > >>>>>> Exactly what attribute do you think would stop this? > >>>>>> > >>>>>> -- > >>>>>> TTFN, > >>>>>> patrick > >>>>>> > >>>>>> > >>>>>>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia > > >>>>>> wrote: > >>>>>>> > >>>>>>>> Another case of route hijack - > >>>>>>>> > >>>>>> > >>>> http://blog.cloudflare.com/**why-google-went-offline-today-** > >>> and-a-bit-about< > http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I am curious if big networks have any pre-defined filters for big > >>>>>> content > >>>>>>>> providers like Google to avoid these? I am sure internet community > >>>>>> would be > >>>>>>>> working in direction to somehow prevent these issues. Curious to > >>> know > >>>>>>>> developments so far. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks. > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> > >>>>>>>> Anurag Bhatia > >>>>>>>> anuragbhatia.com > >>>>>>>> > >>>>>>>> Linkedin http://in.linkedin.com/in/anuragbhatia21>> > >>> | > >>>>>>>> Twitter https://twitter.com/anurag_bhatia> > >>>> | > >>>>>>>> Google+ https://plus.google.com/118280168625121532854> > >>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>> > >> > >> > > > From me at anuragbhatia.com Wed Nov 7 10:05:11 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 7 Nov 2012 15:35:11 +0530 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: <3BF11704-8424-4D68-AF2E-23D41276287D@ianai.net> References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <5099F63D.5090708@bogus.com> <3BF11704-8424-4D68-AF2E-23D41276287D@ianai.net> Message-ID: OK one quick question here - Moratel leaked route and thus for a portion of internet route to Google was via Moratel but was a path. What caused 100% outage I.e all four authoritative DNS servers and open resolver service too ? Can we just guess that due to ultra high traffic path between Moratel and Google was checked ? Or there's a chance that some customer of Moratel announced prefix using Google's ASN at first place. Hard to believe why they would have set bgp session in first place with wrong asn but was curious to know if that is also a possibility? Thanks (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Nov 7, 2012 12:22 PM, "Patrick W. Gilmore" wrote: > On Nov 07, 2012, at 01:29 , Anurag Bhatia wrote: > > > Apologize for calling it an prefix hijack. I misunderstood in start. > Clearly it was case of prefix leaking. > > No worries. I should have read more closely. > > -- > TTFN, > patrick > > From dmiller at tiggee.com Wed Nov 7 10:42:22 2012 From: dmiller at tiggee.com (David Miller) Date: Wed, 07 Nov 2012 05:42:22 -0500 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <5099F63D.5090708@bogus.com> <3BF11704-8424-4D68-AF2E-23D41276287D@ianai.net> Message-ID: <509A3B0E.6010904@tiggee.com> On 11/7/2012 5:05 AM, Anurag Bhatia wrote: > OK one quick question here - Moratel leaked route and thus for a portion of > internet route to Google was via Moratel but was a path. What caused 100% > outage I.e all four authoritative DNS servers and open resolver service too > ? Can we just guess that due to ultra high traffic path between Moratel > and Google was checked ? > > Or there's a chance that some customer of Moratel announced prefix using > Google's ASN at first place. Hard to believe why they would have set bgp > session in first place with wrong asn but was curious to know if that is > also a possibility? Possible? Yes. Probable? No. Refer to: Hanlon's Razor and Occam's Razor -DMM > > Thanks > > (Sent from my mobile device) > > Anurag Bhatia > http://anuragbhatia.com > On Nov 7, 2012 12:22 PM, "Patrick W. Gilmore" wrote: > >> On Nov 07, 2012, at 01:29 , Anurag Bhatia wrote: >> >>> Apologize for calling it an prefix hijack. I misunderstood in start. >> Clearly it was case of prefix leaking. >> >> No worries. I should have read more closely. >> >> -- >> TTFN, >> patrick >> >> From rdobbins at arbor.net Wed Nov 7 11:14:35 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 7 Nov 2012 11:14:35 +0000 Subject: Overview on Defending DDoS attack In-Reply-To: References: Message-ID: On Nov 7, 2012, at 5:56 PM, Mohamed Al-fateh wrote: > Could you please share them with us or direct us to other good resources for that ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nanog at jima.tk Wed Nov 7 14:32:25 2012 From: nanog at jima.tk (Jima) Date: Wed, 7 Nov 2012 07:32:25 -0700 (MST) Subject: Sandy seen costing telco, cable hundreds of millions of dollars In-Reply-To: <001301cdbc92$50352640$f09f72c0$@iname.com> References: <50975AB4.8060502@gmail.com> <001301cdbc92$50352640$f09f72c0$@iname.com> Message-ID: <50348.2001:49f0:a057:0:4982:a05b:5fad:2c9e.1352298745.squirrel@laughton.us> On Tuesday, 2012-11-06, Frank Bulk wrote: > So which wireless carrier is bringing down the average to 81%? A quick skim of the article (again, http://www.reuters.com/article/2012/11/01/storm-sandy-telecoms-idUSL1E8M1L9Z20121101 ) makes me suspect AT&T. They're mentioned twice in other context, but there's not a sites-online statistic for them. I suppose it's worth noting that this wouldn't be the first time they've caught flak for their (in)ability to cover NYC sufficiently. Jima From alex at corp.nac.net Wed Nov 7 14:38:36 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 7 Nov 2012 09:38:36 -0500 Subject: Sandy seen costing telco, cable hundreds of millions of dollars Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE439F02F@EXCHMBX.hq.nac.net> Probably ATT. Many areas of NJ had zero service from them for days. ----- Original Message ----- From: Jima To: nanog Sent: Wed Nov 07 09:32:25 2012 Subject: RE: Sandy seen costing telco, cable hundreds of millions of dollars On Tuesday, 2012-11-06, Frank Bulk wrote: > So which wireless carrier is bringing down the average to 81%? A quick skim of the article (again, http://www.reuters.com/article/2012/11/01/storm-sandy-telecoms-idUSL1E8M1L9Z20121101 ) makes me suspect AT&T. They're mentioned twice in other context, but there's not a sites-online statistic for them. I suppose it's worth noting that this wouldn't be the first time they've caught flak for their (in)ability to cover NYC sufficiently. Jima From uwcableguy at gmail.com Wed Nov 7 16:25:20 2012 From: uwcableguy at gmail.com (Ben Bartsch) Date: Wed, 7 Nov 2012 10:25:20 -0600 Subject: AS 1668 BGP contact - possible prefix hijacking In-Reply-To: References: Message-ID: Big thanks to several folks for their help yesterday: AS 1668 for contacting me off list and the conducting a very thorough review of the routes in questions AS 4323, AS 19151 for verifying routes were received and advertised as expected routeviews.org for verifying the routes received from AS 13703 were suspect AS 13703 for isolating the issue and fixing it NANOG is a great community and I hope to see y'all in NOLA next year. -Ben AS 32440 On Tue, Nov 6, 2012 at 8:02 AM, Ben Bartsch wrote: > Hi: > > Is there anyone here who can help us with a possible prefix hijacking > situation through ATDN? Please contact me off list if you (or you know > somebody) that can help us. I've tried the ATDN NOC and Vikas, but they > have been no help whatsoever. > > The hijacked prefix appears to be sent to AS 1668, then propagated from > there. > > Thanks. > > Ben > AS 32440 > From eosterweil at verisign.com Wed Nov 7 18:44:04 2012 From: eosterweil at verisign.com (Eric Osterweil) Date: Wed, 7 Nov 2012 13:44:04 -0500 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> Message-ID: <4E77514D-5880-4343-9B5D-94BAE744D29E@verisign.com> As for the, ``what is a leak'' question, a few of us just put a draft together to describe it, in the IETF: Eric On Nov 7, 2012, at 12:21 AM, Jian Gu wrote: > I don't know what Google and Moratel's peering agreement, but "leak"? > educate me, Google is announcing /24 for all of their 4 NS prefix and > 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes > to Internet? From uwcableguy at gmail.com Wed Nov 7 18:52:23 2012 From: uwcableguy at gmail.com (Ben Bartsch) Date: Wed, 7 Nov 2012 12:52:23 -0600 Subject: Indonesian ISP Moratel announces Google's prefixes In-Reply-To: <4E77514D-5880-4343-9B5D-94BAE744D29E@verisign.com> References: <0DD240E2-F928-475E-9793-C688A1C99AC0@ianai.net> <22C81BE5-5A07-40E3-9608-1FE42B04713B@ianai.net> <4E77514D-5880-4343-9B5D-94BAE744D29E@verisign.com> Message-ID: http://bgplay.routeviews.org/bgplay/ gives a good idea of what happened On Wed, Nov 7, 2012 at 12:44 PM, Eric Osterweil wrote: > > > As for the, ``what is a leak'' question, a few of us just put a draft > together to describe it, in the IETF: > < > http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02 > > > > Eric > > > On Nov 7, 2012, at 12:21 AM, Jian Gu wrote: > > > I don't know what Google and Moratel's peering agreement, but "leak"? > > educate me, Google is announcing /24 for all of their 4 NS prefix and > > 8.8.8.0/24 for their public DNS server, how did Moratel leak those > routes > > to Internet? > > > > From alex at corp.nac.net Wed Nov 7 19:13:03 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 7 Nov 2012 14:13:03 -0500 Subject: NJ impact In-Reply-To: <509822A3.7030303@mompl.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE477B1DF@EXCHMBX.hq.nac.net> <509822A3.7030303@mompl.net> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE477B9BC@EXCHMBX.hq.nac.net> > I would be interested to know how the power outages due to the storm > have negatively affected air pollution and the smog problem in the area. > Due to generators burning huge amounts of diesel, generators which > undoubtedly have no meaningful air pollution control to speak of. Well, that isn't really that true. Many machine are tier 2 compliant, and lots of new ones are getting catalytic converters. > http://www.nytimes.com/2012/09/23/technology/data-centers-waste-vast- > amounts-of-energy-belying-industry-image.html?pagewanted=all&_r=0 Well, if someone doesn't install something properly or get the proper permit, they should be fined. > "Most data centers, by design, consume vast amounts of energy in an > incongruously wasteful manner, interviews and documents show. Online > companies typically run their facilities at maximum capacity around the clock, > whatever the demand. As a result, data centers can waste 90 percent or > more of the electricity they pull off the grid, The Times found. It is more like 99%, converted to heat. That has been the same for 30 years. > To guard against a power failure, they further rely on banks of generators > that emit diesel exhaust. The pollution from data centers has increasingly > been cited by the authorities for violating clean air regulations, documents > show. In Silicon Valley, many data centers appear on the state government?s > Toxic Air Contaminant Inventory, a roster of the area?s top stationary diesel > polluters." What is your actual question? I'd submit the following to you - for instance, one of our facilities consumed about 600 gallons last week over a 24 hour period. I am located adjacent to an interstate, which has much dirtier vehicles and trucks driving by every second of every day forever. If a diesel truck gets 8 mpg (and that is being really nice), then that is the equivalent of 4,800 trucks passing my place on a one mile stretch of highway. This isn't an argument of whether or not DC's are clean or not, it's a question of what the bigger problem is. From eesslinger at fpu-tn.com Wed Nov 7 22:47:05 2012 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Wed, 7 Nov 2012 16:47:05 -0600 Subject: Verizon wireless (cdma/LTE) compatible ethernet connectable OOB access device. Message-ID: <2730A40A53ADE9418D5F58E734953DF4603D1AC3E2@exchange.corp.fpu-tn.com> We have Verizon Wireless as our provider of choice for our company, and I've convinced those who are they that I need a completely OOB method for getting back in the NOC, as we don't have a full time NOC staff and internet coverage can be spotty around here in general, as we're a small town. The people who need the OOB management access are getting 4G Myfi devices with static IP addresses. What I need at our NOC is a 3 or 4G (our area only has 3G atm) Verizon compatible device with an wired ethernet link. I'm looking at several but wondered if anyone has any familiarity with such units. I just need a basic wwan-ethernet modem/bridge, I will be handling vpn termination, firewalling, access control, and such with my existing firewall. Off-list is fine. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From dhubbard at dino.hostasaurus.com Wed Nov 7 23:02:19 2012 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 7 Nov 2012 18:02:19 -0500 Subject: Verizon wireless (cdma/LTE) compatible ethernet connectable OOB access device. References: <2730A40A53ADE9418D5F58E734953DF4603D1AC3E2@exchange.corp.fpu-tn.com> Message-ID: OpenGear's stuff is awesome. http://opengear.com/product-acm5000-g.html We have the 5004G on Verizon, it has four serial ports, ethernet and USB running linux. We have a 5 gig plan from Verizon and static IP for $50/month minus our corporate discount. Since it's put on a 'machine' plan with them, you can get plans all the way down to I think $5/month with a few megabytes of included data; they treat it the same way you'd treat a cell backup for an alarm and similar devices. You can have the OpenGear unit keep the data portion of the cellular side always live, or for added security and lower risk of data consumption by drive by scans, you can have it turn the data off and on by sending it text messages to the associated phone number. You can ssh directly to serial ports by using different port numbers than standard, ssh in and then utilize the ports, there's a web-based serial interface too so they're really great for routers. On the ethernet/web side you can do things like vpn gateway, proxying, port mapping, etc like you'd find in a typical consumer type soho router, or you can lock it all down for whatever you don't need. My only complaint is no LTE version last I checked, which is fine for serial ports but an LTE would make it a lot nicer since then you could do more interactive things like remote desktop, heavy web traffic and other things that you might also want in a bind. David > -----Original Message----- > From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] > Sent: Wednesday, November 07, 2012 5:47 PM > To: 'nanog at nanog.org' > Subject: Verizon wireless (cdma/LTE) compatible ethernet > connectable OOB access device. > > We have Verizon Wireless as our provider of choice for our > company, and I've convinced those who are they that I need a > completely OOB method for getting back in the NOC, as we > don't have a full time NOC staff and internet coverage can be > spotty around here in general, as we're a small town. > > The people who need the OOB management access are getting 4G > Myfi devices with static IP addresses. What I need at our NOC > is a 3 or 4G (our area only has 3G atm) Verizon compatible > device with an wired ethernet link. I'm looking at several > but wondered if anyone has any familiarity with such units. I > just need a basic wwan-ethernet modem/bridge, I will be > handling vpn termination, firewalling, access control, and > such with my existing firewall. > > Off-list is fine. > > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary > information and is intended for the person/entity to whom it > was originally addressed. Any use by others is strictly prohibited. > > > From arapoport at telepacific.com Wed Nov 7 23:09:33 2012 From: arapoport at telepacific.com (Asaf Rapoport) Date: Wed, 7 Nov 2012 23:09:33 +0000 Subject: Verizon wireless (cdma/LTE) compatible ethernet connectable OOB access device. In-Reply-To: Message-ID: OpenGear does make good, low footprint, low power consumption console servers. I think they have an IPSec stack too. Note: They make another type with just a modem (I don't know why they don't make one with both 3G and dialup?), in case the cell coverage is so spotty that you won't get what you really need. Just my 2 cents. On 11/7/12 3:02 PM, "David Hubbard" wrote: >OpenGear's stuff is awesome. > >http://opengear.com/product-acm5000-g.html > >We have the 5004G on Verizon, it has four serial ports, >ethernet and USB running linux. We have a 5 gig plan >from Verizon and static IP for $50/month minus our >corporate discount. Since it's put on a 'machine' plan >with them, you can get plans all the way down to I >think $5/month with a few megabytes of included data; >they treat it the same way you'd treat a cell backup >for an alarm and similar devices. > >You can have the OpenGear unit keep the data portion of >the cellular side always live, or for added security and >lower risk of data consumption by drive by scans, you >can have it turn the data off and on by sending it text >messages to the associated phone number. > >You can ssh directly to serial ports by using different >port numbers than standard, ssh in and then utilize the >ports, there's a web-based serial interface too so they're >really great for routers. On the ethernet/web side you >can do things like vpn gateway, proxying, port mapping, >etc like you'd find in a typical consumer type soho >router, or you can lock it all down for whatever you >don't need. > >My only complaint is no LTE version last I checked, >which is fine for serial ports but an LTE would make >it a lot nicer since then you could do more interactive >things like remote desktop, heavy web traffic and other >things that you might also want in a bind. > >David > >> -----Original Message----- >> From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] >> Sent: Wednesday, November 07, 2012 5:47 PM >> To: 'nanog at nanog.org' >> Subject: Verizon wireless (cdma/LTE) compatible ethernet >> connectable OOB access device. >> >> We have Verizon Wireless as our provider of choice for our >> company, and I've convinced those who are they that I need a >> completely OOB method for getting back in the NOC, as we >> don't have a full time NOC staff and internet coverage can be >> spotty around here in general, as we're a small town. >> >> The people who need the OOB management access are getting 4G >> Myfi devices with static IP addresses. What I need at our NOC >> is a 3 or 4G (our area only has 3G atm) Verizon compatible >> device with an wired ethernet link. I'm looking at several >> but wondered if anyone has any familiarity with such units. I >> just need a basic wwan-ethernet modem/bridge, I will be >> handling vpn termination, firewalling, access control, and >> such with my existing firewall. >> >> Off-list is fine. >> >> __________________________ >> Eric Esslinger >> Information Services Manager - Fayetteville Public Utilities >> http://www.fpu-tn.com/ >> (931)433-1522 ext 165 >> >> This message may contain confidential and/or proprietary >> information and is intended for the person/entity to whom it >> was originally addressed. Any use by others is strictly prohibited. >> >> >> > > From chort at smtps.net Thu Nov 8 03:08:45 2012 From: chort at smtps.net (Brian Keefer) Date: Wed, 7 Nov 2012 19:08:45 -0800 Subject: MTU issues s0.wp.com In-Reply-To: <509903A3.2070308@dds.nl> References: <509903A3.2070308@dds.nl> Message-ID: <61ACD00A-30B2-4E79-87FF-166390D90173@smtps.net> On Nov 6, 2012, at 4:33 AM, Seth Mos wrote: > Hi, > > Since about a week or so it's become impossible to reach wp.com content over IPv6. > > IPv4 content does work fine, using the IPv6 literal returns a 404 which is small enough to fit in a smaller 1480 byte MTU. > > I have another test site that has a clean 1500 byte mtu and I can fetch the s0.wp.com page from there. > > It looks like tunneled IPv6 users might be in hurt here. > > Is anyone else experiencing similar issues? > > My traceroute shows they are employing a CDN for s0.wp.com, so not everyone might be affected. > > 7 asd2-rou-1022.NL.eurorings.net (2001:680:0:800f::291) 6.460 ms 6.203 ms 6.188 ms > 8 asd2-rou-1044.eurorings.net (2001:680::134:222:85:63) 6.447 ms 6.494 ms 6.495 ms > 9 adm-b5-link.telia.net (2001:2000:3080:6f::1) 6.818 ms 6.936 ms 6.891 ms > 10 ldn-b3-v6.telia.net (2001:2000:3018:5::1) 15.290 ms 27.481 ms 15.380 ms > 11 edgecast-ic-147468-ldn-b3.c.telia.net (2001:2000:3080:378::2) 15.116 ms 15.174 ms 15.176 ms > 12 2606:2800:234:1922:15a7:17bf:bb7:f09 (2606:2800:234:1922:15a7:17bf:bb7:f09) 15.496 ms 15.327 ms 15.460 ms > > Kind regards, > > Seth > Exact same issue here over HE.net tunnel. I can get errors from the (presumably) front-end proxy, but content stalls forever. I'm seeing this for all WP related requests that go to EdgecastCDN. -- chort From kmedcalf at dessus.com Thu Nov 8 03:29:06 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 07 Nov 2012 20:29:06 -0700 Subject: Looking for recommendation on 10G Ethernet switch In-Reply-To: Message-ID: <5b493b94130dfb42b06a300e95bd18fb@mail.dessus.com> > On Fri, Nov 2, 2012 at 2:38 PM, Kevin L. Karch > wrote: > > Andrew > > > > We offer several solutions that meet your initial requirements. Can you > tell me if this is a multi rack deployment and a few more details? > > > > If you would like we could have a call with one of our applications > engineers and get a budgetary quote assembled. > > > > Please let me know how you would like to proceed. > > > > Thank you, > > > > Kevin L. Karch > > Network Specialist > > > > Direct: 847-833-8810 > > Fax: 847-985-5550 > > Email: kevinkarch at vackinc.com > > Web: www.vackinc.com > > The Optical Network Specialists > > Kevin, no thank you, I did not start this thread. If I ever need > products I reach out to my contacts at each manufacturer or > distributor. It would be much less embarrassing for you if the > website in your signature actually finished loading the images > containing the text for your company. The page does not render at all for me -- it is completely blank once the gratuitous code stripper is finished with it. I presume security has to be disabled to view it -- and I'm not going to do that. As a matter of policy I never deal with anyone who is so incompetent as to create web sites like this. Generally I have found that such companies product is of the same quality as the web page. From dave at temk.in Thu Nov 8 16:48:52 2012 From: dave at temk.in (David Temkin) Date: Thu, 8 Nov 2012 08:48:52 -0800 Subject: Call for Presentations: NANOG 57 in Orlando, FL Message-ID: <2C3236F3-9D72-4078-94C7-DCC8E023F2EB@temk.in> NANOG Community, I know that we all just left Dallas after NANOG 56, but the NANOG Program Committee is already hard at work preparing for NANOG 57 in Orlando! The North American Network Operators' Group (NANOG) will hold their 57th meeting in Orlando, FL on February 4th through the 6th. Of special note, this is the first meeting that will have a fully Monday through Wednesday agenda. Our host, CyrusOne is eagerly awaiting welcoming you to the Renaissance Orlando at SeaWorld. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 57 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. NANOG 57 submissions are welcome at http://pc.nanog.org For further information on what the Program Committee is seeking, please see http://www.nanog.org/meetings/nanog57/callforpresentations.html This will also be our first meeting after the 2012 WCIT in early December, and we expect topical and timely presentations regarding the results When considering submitting a presentation, keep these important dates in mind: Presentation Abstracts and Draft Slides Due: 10-December-2012 Final Slides Due: 7-January-2013 Draft Program Published: 14-January-2013 Final Agenda Published: 18-January-2013 Please submit your materials to http://pc.nanog.org Looking forward to seeing everyone in Orlando! -Dave Temkin From cjp at 0x1.net Thu Nov 8 18:28:29 2012 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Thu, 8 Nov 2012 13:28:29 -0500 Subject: Looking for a outside plant contact Zayo/AboveNet Manhattan Message-ID: We're looking at some emergency office space in Manhattan and we identified an AboveNet/Zayo fiber panel in the space. Would like to see if someone could confirm if it is viable. Anyone from Abovenet lurking? Thanks, -cjp From kemp at network-services.uoregon.edu Thu Nov 8 20:40:39 2012 From: kemp at network-services.uoregon.edu (John Kemp) Date: Thu, 08 Nov 2012 12:40:39 -0800 Subject: route-views.eqix DC METRO AREA IX RENUMBERING Message-ID: <509C18C7.5040607@network-services.uoregon.edu> We have the renumber interface enabled and configured for any known peers to make the transition for the RouteViews EQUINIX ASHBURN route collector. OLD PEERING ADDRESS: 206.223.115.142 NEW PEERING ADDRESS: 206.126.236.142 Current v4 peer list looks like below. If you need to check, telnet to route-views.eqix.routeviews.org Thanks, John Kemp (kemp at routeviews.org) > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > State/PfxRcd > 206.126.236.10 4 4589 0 0 0 0 0 never > Active > 206.126.236.12 4 2914 0 0 0 0 0 never > Active > 206.126.236.19 4 3257 0 0 0 0 0 never > Active > 206.126.236.24 4 11666 0 0 0 0 0 never > Active > 206.126.236.25 4 6079 0 0 0 0 0 never > Active > 206.126.236.26 4 16559 0 0 0 0 0 never > Active > 206.126.236.37 4 6939 0 0 0 0 0 never > Active > 206.126.236.47 4 19151 0 0 0 0 0 never > Active > 206.126.236.52 4 4565 0 0 0 0 0 never > Active > 206.126.236.58 4 32098 0 0 0 0 0 never > Active > 206.126.236.60 4 4436 0 0 0 0 0 never > Active > 206.126.236.61 4 4436 0 0 0 0 0 never > Active > 206.126.236.76 4 5769 0 0 0 0 0 never > Active > 206.126.236.81 4 6453 0 0 0 0 0 never > Active > 206.126.236.109 4 19166 0 0 0 0 0 never > Active > 206.126.236.120 4 41095 0 0 0 0 0 never > Active > 206.126.236.156 4 7795 0 0 0 0 0 never > Active > 206.126.236.181 4 8781 0 0 0 0 0 never > Active > 206.223.115.10 4 4589 168086 1454 0 0 0 1d00h12m > 428226 > 206.223.115.12 4 2914 335570 1454 0 0 0 1d00h12m > 422014 > 206.223.115.19 4 3257 306479 2886 0 0 0 1d00h12m > 421751 > 206.223.115.24 4 11666 350048 2886 0 0 0 1d00h12m > 427034 > 206.223.115.25 4 6079 127539 1454 0 0 0 1d00h12m > 421048 > 206.223.115.26 4 16559 150834 1454 0 0 0 1d00h12m > 422475 > 206.223.115.37 4 6939 280514 1454 0 0 0 1d00h12m > 426934 > 206.223.115.47 4 19151 179133 1454 0 0 0 1d00h12m > 424028 > 206.223.115.52 4 4565 3061 2886 0 0 0 > 1d00h12m 2058 > 206.223.115.58 4 32098 5855 1454 0 0 0 > 1d00h12m 957 > 206.223.115.60 4 4436 235866 2886 0 0 0 1d00h12m > 422375 > 206.223.115.61 4 4436 237259 2886 0 0 0 1d00h12m > 422375 > 206.223.115.76 4 5769 205324 1454 0 0 0 1d00h12m > 422482 > 206.223.115.81 4 6453 0 0 0 0 0 never > Active > 206.223.115.109 4 19166 0 0 0 0 0 never > Active > 206.223.115.120 4 41095 166604 1454 0 0 0 1d00h12m > 422118 > 206.223.115.156 4 7795 3176 1454 0 0 0 > 1d00h12m 191 > 206.223.115.181 4 8781 6157 1454 0 0 0 > 1d00h12m 764 > -- John Kemp (kemp at routeviews.org) RouteViews Engineer NOC: noc at routeviews.org MAIL: help at routeviews.org WWW: http://www.routeviews.org From achatz at forthnetgroup.gr Thu Nov 8 21:57:27 2012 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Thu, 08 Nov 2012 23:57:27 +0200 Subject: MTU issues s0.wp.com In-Reply-To: <61ACD00A-30B2-4E79-87FF-166390D90173@smtps.net> References: <509903A3.2070308@dds.nl> <61ACD00A-30B2-4E79-87FF-166390D90173@smtps.net> Message-ID: <509C2AC7.4090800@forthnetgroup.gr> Same here too...i don't know if having a direct peering with Edgecast will solve the issue. -- Tassos Brian Keefer wrote on 8/11/2012 05:08: > On Nov 6, 2012, at 4:33 AM, Seth Mos wrote: > >> Hi, >> >> Since about a week or so it's become impossible to reach wp.com content over IPv6. >> >> IPv4 content does work fine, using the IPv6 literal returns a 404 which is small enough to fit in a smaller 1480 byte MTU. >> >> I have another test site that has a clean 1500 byte mtu and I can fetch the s0.wp.com page from there. >> >> It looks like tunneled IPv6 users might be in hurt here. >> >> Is anyone else experiencing similar issues? >> >> My traceroute shows they are employing a CDN for s0.wp.com, so not everyone might be affected. >> >> 7 asd2-rou-1022.NL.eurorings.net (2001:680:0:800f::291) 6.460 ms 6.203 ms 6.188 ms >> 8 asd2-rou-1044.eurorings.net (2001:680::134:222:85:63) 6.447 ms 6.494 ms 6.495 ms >> 9 adm-b5-link.telia.net (2001:2000:3080:6f::1) 6.818 ms 6.936 ms 6.891 ms >> 10 ldn-b3-v6.telia.net (2001:2000:3018:5::1) 15.290 ms 27.481 ms 15.380 ms >> 11 edgecast-ic-147468-ldn-b3.c.telia.net (2001:2000:3080:378::2) 15.116 ms 15.174 ms 15.176 ms >> 12 2606:2800:234:1922:15a7:17bf:bb7:f09 (2606:2800:234:1922:15a7:17bf:bb7:f09) 15.496 ms 15.327 ms 15.460 ms >> >> Kind regards, >> >> Seth >> > Exact same issue here over HE.net tunnel. I can get errors from the (presumably) front-end proxy, but content stalls forever. I'm seeing this for all WP related requests that go to EdgecastCDN. > > -- > chort > > > > From Vinny_Abello at Dell.com Thu Nov 8 22:33:52 2012 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Thu, 8 Nov 2012 22:33:52 +0000 Subject: Sandy seen costing telco, cable hundreds of millions of dollars In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE439F02F@EXCHMBX.hq.nac.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE439F02F@EXCHMBX.hq.nac.net> Message-ID: Agreed... I live in the same general vicinity in NJ as Alex and ATT service was pretty much non-existent anywhere there was no power from what I experienced. I have friends on Verizon to whom I've spoken and they didn't seem to notice as large of an impact at all on their cellular service. -Vinny -----Original Message----- From: Alex Rubenstein [mailto:alex at corp.nac.net] Sent: Wednesday, November 07, 2012 9:39 AM To: 'nanog at jima.tk'; 'nanog at nanog.org' Subject: Re: Sandy seen costing telco, cable hundreds of millions of dollars Probably ATT. Many areas of NJ had zero service from them for days. ----- Original Message ----- From: Jima To: nanog Sent: Wed Nov 07 09:32:25 2012 Subject: RE: Sandy seen costing telco, cable hundreds of millions of dollars On Tuesday, 2012-11-06, Frank Bulk wrote: > So which wireless carrier is bringing down the average to 81%? A quick skim of the article (again, http://www.reuters.com/article/2012/11/01/storm-sandy-telecoms-idUSL1E8M1L9Z20121101 ) makes me suspect AT&T. They're mentioned twice in other context, but there's not a sites-online statistic for them. I suppose it's worth noting that this wouldn't be the first time they've caught flak for their (in)ability to cover NYC sufficiently. Jima From karim.adel at gmail.com Thu Nov 8 23:22:58 2012 From: karim.adel at gmail.com (Kasper Adel) Date: Fri, 9 Nov 2012 01:22:58 +0200 Subject: Whats so difficult about ISSU Message-ID: Hello, We've been hearing about ISSU for so many years and i didnt hear that any vendor was able to achieve it yet. What is the technical reason behind that? If i understand correctly, the way it will be done would be simply to have extra ASICs/HW to be able to build dual circuits accessing the same memory, and gracefully switch from one to another. Is that right? Thanks, Kim From zaid at zaidali.com Thu Nov 8 23:38:27 2012 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 8 Nov 2012 15:38:27 -0800 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: <813B894D-A090-4C8C-AE11-491FF0E5DCFC@zaidali.com> Cisco Nexus platform does it pretty well so they have achieved it. Zaid On Nov 8, 2012, at 3:22 PM, Kasper Adel wrote: > Hello, > > We've been hearing about ISSU for so many years and i didnt hear that any > vendor was able to achieve it yet. > > What is the technical reason behind that? > > If i understand correctly, the way it will be done would be simply to have > extra ASICs/HW to be able to build dual circuits accessing the same memory, > and gracefully switch from one to another. Is that right? > > Thanks, > Kim From kenneth.mcrae at dreamhost.com Thu Nov 8 23:42:03 2012 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Thu, 8 Nov 2012 15:42:03 -0800 Subject: Whats so difficult about ISSU In-Reply-To: <813B894D-A090-4C8C-AE11-491FF0E5DCFC@zaidali.com> References: <813B894D-A090-4C8C-AE11-491FF0E5DCFC@zaidali.com> Message-ID: Juniper also offers it on the EX virtual switching platform. Works if you have the correct version of JunOS. On Thu, Nov 8, 2012 at 3:38 PM, Zaid Ali wrote: > Cisco Nexus platform does it pretty well so they have achieved it. > > Zaid > > On Nov 8, 2012, at 3:22 PM, Kasper Adel wrote: > > > Hello, > > > > We've been hearing about ISSU for so many years and i didnt hear that any > > vendor was able to achieve it yet. > > > > What is the technical reason behind that? > > > > If i understand correctly, the way it will be done would be simply to > have > > extra ASICs/HW to be able to build dual circuits accessing the same > memory, > > and gracefully switch from one to another. Is that right? > > > > Thanks, > > Kim > > > From bedard.phil at gmail.com Fri Nov 9 00:48:07 2012 From: bedard.phil at gmail.com (Phil) Date: Thu, 8 Nov 2012 19:48:07 -0500 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: The major vendors have figured it out for the most part by moving to stateful synchronization between control plane modules and implementing non-stop routing. ALU has supported ISSU on minor releases for many years and just added support for major releases. The Cisco Nexus ISSU works well, I've done an upgrade on a 5K switch and it was completely hitless. Juniper and Cisco with the 9K have gone through some hurdles but ISSU is actually usable now if the software versions support it. The main remaining hurdle is updating microcode on linecards, they still need to be rebooted after an upgrade. Phil On Nov 8, 2012, at 6:22 PM, Kasper Adel wrote: > Hello, > > We've been hearing about ISSU for so many years and i didnt hear that any > vendor was able to achieve it yet. > > What is the technical reason behind that? > > If i understand correctly, the way it will be done would be simply to have > extra ASICs/HW to be able to build dual circuits accessing the same memory, > and gracefully switch from one to another. Is that right? > > Thanks, > Kim From karim.adel at gmail.com Fri Nov 9 00:52:09 2012 From: karim.adel at gmail.com (Kasper Adel) Date: Fri, 9 Nov 2012 02:52:09 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: What i was asking is full ISSU, even with micro code. I assume between Major release there will be microcode upgrade most of the time. On Fri, Nov 9, 2012 at 2:48 AM, Phil wrote: > The major vendors have figured it out for the most part by moving to > stateful synchronization between control plane modules and implementing > non-stop routing. > > ALU has supported ISSU on minor releases for many years and just added > support for major releases. > > The Cisco Nexus ISSU works well, I've done an upgrade on a 5K switch and > it was completely hitless. > > Juniper and Cisco with the 9K have gone through some hurdles but ISSU is > actually usable now if the software versions support it. > > The main remaining hurdle is updating microcode on linecards, they still > need to be rebooted after an upgrade. > > Phil > > On Nov 8, 2012, at 6:22 PM, Kasper Adel wrote: > > > Hello, > > > > We've been hearing about ISSU for so many years and i didnt hear that any > > vendor was able to achieve it yet. > > > > What is the technical reason behind that? > > > > If i understand correctly, the way it will be done would be simply to > have > > extra ASICs/HW to be able to build dual circuits accessing the same > memory, > > and gracefully switch from one to another. Is that right? > > > > Thanks, > > Kim > From kenneth.mcrae at dreamhost.com Fri Nov 9 00:55:15 2012 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Thu, 8 Nov 2012 16:55:15 -0800 Subject: Whats so difficult about ISSU In-Reply-To: <509C4C19.5030304@yahoo.com> References: <813B894D-A090-4C8C-AE11-491FF0E5DCFC@zaidali.com> <509C4C19.5030304@yahoo.com> Message-ID: I have executed successfully on the MX960 with no issues.. EX on the other hand, really depends on your version of JunOS. On Thu, Nov 8, 2012 at 4:19 PM, Alex wrote: > http://www.juniper.net/**techpubs/en_US/junos/topics/** > concept/issu-oveview.html > > The Juniper ISSU guide. > > You need two things: > > 1. Separation of the control plane and forwarding plane > 2. 2 routing engines in the same chassis -- the non active RE upgrades > first, then when its up and running the active one goes into upgrade mode > and control fails over to the secondary RE which is running the upgraded > version of the software. > > I assume it works on any vendor that has 2 REs in the same chassis and the > fwd and control planes are separated, and there is a redundancy protocol > running between the two REs(like Graceful Switchover on Juniper gear). > > > On 11/09/2012 01:42 AM, Kenneth McRae wrote: > >> Juniper also offers it on the EX virtual switching platform. Works if you >> have the correct version of JunOS. >> >> On Thu, Nov 8, 2012 at 3:38 PM, Zaid Ali wrote: >> >> Cisco Nexus platform does it pretty well so they have achieved it. >>> >>> Zaid >>> >>> On Nov 8, 2012, at 3:22 PM, Kasper Adel wrote: >>> >>> Hello, >>>> >>>> We've been hearing about ISSU for so many years and i didnt hear that >>>> any >>>> vendor was able to achieve it yet. >>>> >>>> What is the technical reason behind that? >>>> >>>> If i understand correctly, the way it will be done would be simply to >>>> >>> have >>> >>>> extra ASICs/HW to be able to build dual circuits accessing the same >>>> >>> memory, >>> >>>> and gracefully switch from one to another. Is that right? >>>> >>>> Thanks, >>>> Kim >>>> >>> >>> From kenneth.mcrae at dreamhost.com Fri Nov 9 00:56:41 2012 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Thu, 8 Nov 2012 16:56:41 -0800 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: I have performed micro code upgrades using ISSU on the Juniper platform. On Thu, Nov 8, 2012 at 4:52 PM, Kasper Adel wrote: > What i was asking is full ISSU, even with micro code. I assume between > Major release there will be microcode upgrade most of the time. > > > On Fri, Nov 9, 2012 at 2:48 AM, Phil wrote: > > > The major vendors have figured it out for the most part by moving to > > stateful synchronization between control plane modules and implementing > > non-stop routing. > > > > ALU has supported ISSU on minor releases for many years and just added > > support for major releases. > > > > The Cisco Nexus ISSU works well, I've done an upgrade on a 5K switch and > > it was completely hitless. > > > > Juniper and Cisco with the 9K have gone through some hurdles but ISSU is > > actually usable now if the software versions support it. > > > > The main remaining hurdle is updating microcode on linecards, they still > > need to be rebooted after an upgrade. > > > > Phil > > > > On Nov 8, 2012, at 6:22 PM, Kasper Adel wrote: > > > > > Hello, > > > > > > We've been hearing about ISSU for so many years and i didnt hear that > any > > > vendor was able to achieve it yet. > > > > > > What is the technical reason behind that? > > > > > > If i understand correctly, the way it will be done would be simply to > > have > > > extra ASICs/HW to be able to build dual circuits accessing the same > > memory, > > > and gracefully switch from one to another. Is that right? > > > > > > Thanks, > > > Kim > > > From karim.adel at gmail.com Fri Nov 9 01:00:39 2012 From: karim.adel at gmail.com (Kasper Adel) Date: Fri, 9 Nov 2012 03:00:39 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: Does that mean they are the only vendor capable of doing this today? I am interested in the technology behind this if this is something public, any ideas? Thx On Friday, November 9, 2012, Kenneth McRae wrote: > I have performed micro code upgrades using ISSU on the Juniper platform. > > On Thu, Nov 8, 2012 at 4:52 PM, Kasper Adel > > wrote: > >> What i was asking is full ISSU, even with micro code. I assume between >> Major release there will be microcode upgrade most of the time. >> >> >> On Fri, Nov 9, 2012 at 2:48 AM, Phil > >> wrote: >> >> > The major vendors have figured it out for the most part by moving to >> > stateful synchronization between control plane modules and implementing >> > non-stop routing. >> > >> > ALU has supported ISSU on minor releases for many years and just added >> > support for major releases. >> > >> > The Cisco Nexus ISSU works well, I've done an upgrade on a 5K switch and >> > it was completely hitless. >> > >> > Juniper and Cisco with the 9K have gone through some hurdles but ISSU is >> > actually usable now if the software versions support it. >> > >> > The main remaining hurdle is updating microcode on linecards, they still >> > need to be rebooted after an upgrade. >> > >> > Phil >> > >> > On Nov 8, 2012, at 6:22 PM, Kasper Adel > >> wrote: >> > >> > > Hello, >> > > >> > > We've been hearing about ISSU for so many years and i didnt hear that >> any >> > > vendor was able to achieve it yet. >> > > >> > > What is the technical reason behind that? >> > > >> > > If i understand correctly, the way it will be done would be simply to >> > have >> > > extra ASICs/HW to be able to build dual circuits accessing the same >> > memory, >> > > and gracefully switch from one to another. Is that right? >> > > >> > > Thanks, >> > > Kim >> > >> > > From oliver at g.garraux.net Fri Nov 9 01:22:20 2012 From: oliver at g.garraux.net (Oliver Garraux) Date: Thu, 8 Nov 2012 20:22:20 -0500 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: I know some people here have mentioned good experiences with ISSU on Nexus. I don't doubt that it usually works right, but in my latest experience with upgrading NX-OS on dual-SUP'ed 7k's, it was "hitless" if, by "hitless", you mean ~20% packet loss while troubleshooting with TAC before we found that we had to remove and re-apply QoS policies from every interface. Also, depending on the update, linecards might have to be reset. Oliver ------------------------------------- Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux On Thu, Nov 8, 2012 at 8:00 PM, Kasper Adel wrote: > Does that mean they are the only vendor capable of doing this today? > > I am interested in the technology behind this if this is something public, > any ideas? > > Thx > > On Friday, November 9, 2012, Kenneth McRae wrote: > >> I have performed micro code upgrades using ISSU on the Juniper platform. >> >> On Thu, Nov 8, 2012 at 4:52 PM, Kasper Adel >> > wrote: >> >>> What i was asking is full ISSU, even with micro code. I assume between >>> Major release there will be microcode upgrade most of the time. >>> >>> >>> On Fri, Nov 9, 2012 at 2:48 AM, Phil > >>> wrote: >>> >>> > The major vendors have figured it out for the most part by moving to >>> > stateful synchronization between control plane modules and implementing >>> > non-stop routing. >>> > >>> > ALU has supported ISSU on minor releases for many years and just added >>> > support for major releases. >>> > >>> > The Cisco Nexus ISSU works well, I've done an upgrade on a 5K switch and >>> > it was completely hitless. >>> > >>> > Juniper and Cisco with the 9K have gone through some hurdles but ISSU is >>> > actually usable now if the software versions support it. >>> > >>> > The main remaining hurdle is updating microcode on linecards, they still >>> > need to be rebooted after an upgrade. >>> > >>> > Phil >>> > >>> > On Nov 8, 2012, at 6:22 PM, Kasper Adel > >>> wrote: >>> > >>> > > Hello, >>> > > >>> > > We've been hearing about ISSU for so many years and i didnt hear that >>> any >>> > > vendor was able to achieve it yet. >>> > > >>> > > What is the technical reason behind that? >>> > > >>> > > If i understand correctly, the way it will be done would be simply to >>> > have >>> > > extra ASICs/HW to be able to build dual circuits accessing the same >>> > memory, >>> > > and gracefully switch from one to another. Is that right? >>> > > >>> > > Thanks, >>> > > Kim >>> > >>> >> >> From bedard.phil at gmail.com Fri Nov 9 03:12:12 2012 From: bedard.phil at gmail.com (Phil) Date: Thu, 8 Nov 2012 22:12:12 -0500 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: Heh you will find vendors avoid using the term hitless. I can't think of any router which supports ISSU that is truly hitless. The ASR9K ISSU states it will sustain less than 6 seconds of loss... ISSU is still rife with caveats and incompatibilities as well if you are doing more advanced things. Phil On Nov 8, 2012, at 8:22 PM, Oliver Garraux wrote: > I know some people here have mentioned good experiences with ISSU on > Nexus. I don't doubt that it usually works right, but in my latest > experience with upgrading NX-OS on dual-SUP'ed 7k's, it was "hitless" > if, by "hitless", you mean ~20% packet loss while troubleshooting with > TAC before we found that we had to remove and re-apply QoS policies > from every interface. > > Also, depending on the update, linecards might have to be reset. > > Oliver > > ------------------------------------- > > Oliver Garraux > Check out my blog: www.GetSimpliciti.com/blog > Follow me on Twitter: twitter.com/olivergarraux > > > On Thu, Nov 8, 2012 at 8:00 PM, Kasper Adel wrote: >> Does that mean they are the only vendor capable of doing this today? >> >> I am interested in the technology behind this if this is something public, >> any ideas? >> >> Thx >> >> On Friday, November 9, 2012, Kenneth McRae wrote: >> >>> I have performed micro code upgrades using ISSU on the Juniper platform. >>> >>> On Thu, Nov 8, 2012 at 4:52 PM, Kasper Adel >>>> wrote: >>> >>>> What i was asking is full ISSU, even with micro code. I assume between >>>> Major release there will be microcode upgrade most of the time. >>>> >>>> >>>> On Fri, Nov 9, 2012 at 2:48 AM, Phil > >>>> wrote: >>>> >>>>> The major vendors have figured it out for the most part by moving to >>>>> stateful synchronization between control plane modules and implementing >>>>> non-stop routing. >>>>> >>>>> ALU has supported ISSU on minor releases for many years and just added >>>>> support for major releases. >>>>> >>>>> The Cisco Nexus ISSU works well, I've done an upgrade on a 5K switch and >>>>> it was completely hitless. >>>>> >>>>> Juniper and Cisco with the 9K have gone through some hurdles but ISSU is >>>>> actually usable now if the software versions support it. >>>>> >>>>> The main remaining hurdle is updating microcode on linecards, they still >>>>> need to be rebooted after an upgrade. >>>>> >>>>> Phil >>>>> >>>>> On Nov 8, 2012, at 6:22 PM, Kasper Adel > >>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> We've been hearing about ISSU for so many years and i didnt hear that >>>> any >>>>>> vendor was able to achieve it yet. >>>>>> >>>>>> What is the technical reason behind that? >>>>>> >>>>>> If i understand correctly, the way it will be done would be simply to >>>>> have >>>>>> extra ASICs/HW to be able to build dual circuits accessing the same >>>>> memory, >>>>>> and gracefully switch from one to another. Is that right? >>>>>> >>>>>> Thanks, >>>>>> Kim > From swmike at swm.pp.se Fri Nov 9 04:13:26 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 9 Nov 2012 05:13:26 +0100 (CET) Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: On Thu, 8 Nov 2012, Phil wrote: > The major vendors have figured it out for the most part by moving to > stateful synchronization between control plane modules and implementing > non-stop routing. NSR isn't ISSU. ISSU contains the wording "in service". 6 seconds of outage isn't "in service". 0.5 seconds of outage isn't "in service". I could accept a few microseconds of outage as being "ISSU", but tenths of seconds isn't in service. > The main remaining hurdle is updating microcode on linecards, they still > need to be rebooted after an upgrade. ... and as long as this is the case, there is no ISSU. There is only "shorter outages during upgrade compared to a complete reboot". -- Mikael Abrahamsson email: swmike at swm.pp.se From jof at thejof.com Fri Nov 9 05:15:04 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 8 Nov 2012 21:15:04 -0800 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: On Thu, Nov 8, 2012 at 8:13 PM, Mikael Abrahamsson wrote: > On Thu, 8 Nov 2012, Phil wrote: > >> The major vendors have figured it out for the most part by moving to >> stateful synchronization between control plane modules and implementing >> non-stop routing. > > > NSR isn't ISSU. > > ISSU contains the wording "in service". 6 seconds of outage isn't "in > service". 0.5 seconds of outage isn't "in service". I could accept a few > microseconds of outage as being "ISSU", but tenths of seconds isn't in > service. > > >> The main remaining hurdle is updating microcode on linecards, they still >> need to be rebooted after an upgrade. > > > ... and as long as this is the case, there is no ISSU. There is only > "shorter outages during upgrade compared to a complete reboot". This. There are some wonderfully reconfigurable router hardwares out in the world, and platforms that can dynamically program their forwarding hardware make this seem possible. It's possible to build things such that portions of a single box can be upgraded at a time. With multiple links, or forwarding-paths out to a remote destination, it seems to me that if the upgrade process could just coordinate things and update each piece of forwarding hardware while letting traffic cut over and waiting for it to come back before moving on. I could envision a Juniper M/TX box, where MPLS FRR or an "ae" interface across FPCs could take backup traffic while a PFE is upgraded. Of course, every possible path would need to be able to survive an FPC being down, and the process would have to have hooks into protocols to know when everything is switched back. From juuso.lehtinen at gmail.com Fri Nov 9 07:36:22 2012 From: juuso.lehtinen at gmail.com (Juuso Lehtinen) Date: Thu, 8 Nov 2012 23:36:22 -0800 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: In vendor-speak ISSU usually refers to 'minimal traffic impact' upgrade. Definition of minimal varies from vendor to vendor and from upgrade to upgrade, depending of which parts of the code need to be upgraded. In general, traffic loss during ISSU is an order of magnitude less than by reloading the whole box or line card as with conventional upgrade. On high level, the ISSU can be divided to two areas: * Control plane / controller card software upgrade * Forwarding plane / line card software upgrade Control card software upgrade is the easy part. In 1+1 controller design, the standby controller card is upgraded first. Next, control card switchover is performed. And last, the remaining controller card is upgraded. Line card upgrade is the more tricky part. On high level, the line card can be divided into forwarding plane and control plane (yes - there is CPU complex on line cards as well). The control plane part of the line card can be upgraded separately and then restarted. If line-card CPU is responsible for generating OSPF hellos, the OSPF session might time out during the restart. However, for most protocols, graceful restart extensions help over any such issues. While the control plane is rebooting, the forwarding bits on the line card continue packet forwarding. The forwarding plane upgrade of the line card is the tricky part. This is the part that will cause the 'short outage' during ISSU. If the code upgrade needs to touch microcode or FPGA code, you will be seeing some traffic loss. It is just the way these chips are built - you cannot reprogram FPGA without taking the FPGA out of service first. The same applies to network processors as well. In theory you could duplicate these forwarding plane chips on line cards and implement simple switch before the PHY. However, I doubt if any vendor has gone this way as it would push line card prices much higher. If your SLAs are built so that no packet loss is acceptable, you need to work around the ISSU limitations: * Use line-level protection on adjacent line cards (LAG, APS1+1, MSP1+1) - when primary card goes down, the backup card will carry the traffic * When upgrading a transit router, route traffic via redundant path before starting transit router upgrade BR, Juuso is such that no traffic loss whatsoever is acceptable, be sure to On Thu, Nov 8, 2012 at 3:22 PM, Kasper Adel wrote: > Hello, > > We've been hearing about ISSU for so many years and i didnt hear that any > vendor was able to achieve it yet. > > What is the technical reason behind that? > > If i understand correctly, the way it will be done would be simply to have > extra ASICs/HW to be able to build dual circuits accessing the same memory, > and gracefully switch from one to another. Is that right? > > Thanks, > Kim > From saku at ytti.fi Fri Nov 9 07:36:21 2012 From: saku at ytti.fi (Saku Ytti) Date: Fri, 9 Nov 2012 09:36:21 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: <20121109073621.GA29358@pob.ytti.fi> On (2012-11-09 01:22 +0200), Kasper Adel wrote: > We've been hearing about ISSU for so many years and i didnt hear that any > vendor was able to achieve it yet. > > What is the technical reason behind that? I'd say generally code quality in routers is really really bad, I'm not sure why this is. I think one problem is, that we start on premise that code will be written correctly. When we start on that premise, we can do silly things like write run-to-completion operating systems like IOS and JunOS (rpd). Which means single guy making one bad judgement call, and whole OS is bad. Of course run-to-completion is most optimum way to execute code, if your code is flawless, but that ship has sailed. Possibly when IOS started CPU time was premium and it was cheaper to through code review money at the problem. But today it clearly is cheaper to add power to control plane and have levels of abstraction in control-plane which saves the system from bad code, i.e. design your control-plane assuming code you deliver isn't good. Take a page from erlang team on design principles. I think Arista is walking the right path. They have (hopefully) stable and simplistic state-storage process, from which separate processes can download their states when they crash, which can make crashing virtually transparent to operator. However I think Arista is still running single BGPd etc, I think you should at least rung iBGP and eBGP or maybe even peer gruops in different daemons, so when you get bad UPDATE, it'll crash your eBGPs or one peer-group, instead of all neighbours. Or of course if you keep TCP state and various bgp RIBs in separate location, you won't need to tear down the TCP just because you crash. Someone might argue the overhead is too large, but is it though? MX routers ship with 4 cores RP, out of which you're using 1 core. The overhead isn't that high. Some people write positive things about ISSU in reply, only box where I've seen it work reliably is CAT4500 switches. I've not seen it working in routers. On MX960 my personal hit miss ratio is like 4/5 ISSU work, 1/5 have failed catastrophically, like suddenly PFE is dropping packets as if FW filter was applied, while none is. So we've stopped using ISSU. Point of ISSU is, you're not doing change management notices to your customers, so then it positively has to work, or you're in breach of contract. -- ++ytti From righa.shake at gmail.com Fri Nov 9 08:32:40 2012 From: righa.shake at gmail.com (Righa Shake) Date: Fri, 9 Nov 2012 11:32:40 +0300 Subject: Contact from TeliaSonera International Carrier Message-ID: Hi, Kindly would any contact from TeliaSonera International Carrier (TELIANET) contact me off list. Regards, Righa Shake From jeroen at unfix.org Fri Nov 9 09:36:31 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 09 Nov 2012 10:36:31 +0100 Subject: IPv6 is really there when "SEO"-style spammers want to start using it ;) Message-ID: <509CCE9F.3040401@unfix.org> Hi, As it is http://www.youtube.com/watch?v=kfVsfOSbJY0 ... (don't look if you have a video and audio enabled terminal ;) I just came across the following: 8<---------- I want to use IPv6 to test if my Marketing Referral System will work with this protocol. Since IPv4s are running low, it takes a justifiable reason to request multiple IPv4s. I need multiple IPs to post jobs available ads in multiple cities. --------------->8 It is good in one way that quite a few sites are not IPv6 enabled yet and that limiting based on /64, then /48, then /32 is a very simple technique ;) Just a heads up for the folks providing connectivity that these kind of people are finally also looking at IPv6 as they see the scrunch of IPv4 and can't justify their "But I want to run 10000's of SSL hosts on 1 physical hardware box" anymore to get more IPv4 IPs... Greets, Jeroen From BECHA at ripe.net Fri Nov 9 10:03:11 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 09 Nov 2012 11:03:11 +0100 Subject: CLI & text-based server for RIPEstat now available Message-ID: <509CD4DF.9010006@ripe.net> Dear colleagues, due to the popular demand, we are now providing RIPEstat data in the text format, in two ways: you can use existing clients to query the RIPEstat server on port 43: ~# echo as3333 | nc stat.ripe.net 43 | less ~# whois -h stat.ripe.net AS3333 or you can get out client from GitHub, use it and/or modify it: https://github.com/RIPE-NCC/ripestat-text Please let us know if this is how the operators prefer their data, and what would be new features you want us to work on. Or, contribute to the code yourself :) Regards, Vesna More info: RIPEstat is an interface to the information about IP addresses and AS numbers collected by RIPE NCC: registry data, RIPE (whois) database, IRR data, and both real-time & historical routing information collected by RIS (Route Information Service). The visualized data is available via web queries, and there is a Data-API access available too, but now made easily accessible even for people who do not know much about scripting, yet prefer command-line queries. You can find the announcement & links in this article on RIPELabs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripestat-new-text-service-now-available From alumbis at gmail.com Fri Nov 9 13:02:49 2012 From: alumbis at gmail.com (Pete Lumbis) Date: Fri, 9 Nov 2012 08:02:49 -0500 Subject: Whats so difficult about ISSU In-Reply-To: <20121109073621.GA29358@pob.ytti.fi> References: <20121109073621.GA29358@pob.ytti.fi> Message-ID: I can't speak for JunOS, but none of the "new" IOS operating systems are run to completion. This includes IOS-XE, XR and NX-OS. On Fri, Nov 9, 2012 at 2:36 AM, Saku Ytti wrote: > When we start on that premise, we can do silly things like write > run-to-completion operating systems like IOS and JunOS (rpd). Which means > single guy making one bad judgement call, and whole OS is bad. > > Of course run-to-completion is most optimum way to execute code, if your > code is flawless, but that ship has sailed. Possibly when IOS started CPU > time was premium and it was cheaper to through code review money at the > problem. > But today it clearly is cheaper to add power to control plane and have > levels of abstraction in control-plane which saves the system from bad > code, i.e. design your control-plane assuming code you deliver isn't good. > From saku at ytti.fi Fri Nov 9 13:27:23 2012 From: saku at ytti.fi (Saku Ytti) Date: Fri, 9 Nov 2012 15:27:23 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: <20121109073621.GA29358@pob.ytti.fi> Message-ID: <20121109132723.GA29560@pob.ytti.fi> On (2012-11-09 08:02 -0500), Pete Lumbis wrote: > I can't speak for JunOS, but none of the "new" IOS operating systems > are run to completion. This includes IOS-XE, XR and NX-OS. Really? I thought IOS XE is Linux control-plane on top of where you have monolithic IOSd process? I had chat with Michael Beesley when ASR1k was coming up, and he said Cisco has plans to remove processes from IOS and directly on top of Linux in XE, starting with BGP. But I don't think that has materialized? To me JunOS and IOS XE look very much same, NIX control-plane and magic process with has its own memory management and cooperative multitasking/scheduling? -- ++ytti From kilobit at gmail.com Fri Nov 9 13:34:19 2012 From: kilobit at gmail.com (bas) Date: Fri, 9 Nov 2012 14:34:19 +0100 Subject: ADCKRONE OMX800 (or another high density fiber distribution solution) Message-ID: Hi All, Does anyone know a party that might have stock of ADC OMX ? We're looking for a couple of distribution frames and termination modules in a short timeframe. Or can someone advise a different brand for high end and high density fiber distribution that might be available on short notice? Thanks in advance, Bas From mike at smashing.net Fri Nov 9 15:27:36 2012 From: mike at smashing.net (Mike Hughes) Date: Fri, 9 Nov 2012 15:27:36 +0000 Subject: UKNOF 24: Call for Presentations Message-ID: UKNOF 24 Call For Presentations The next UKNOF meeting will take place on 17th January 2013 at Timico in Newark-on-Trent, Nottinghamshire, and the Programme Committee are seeking content from the community for this meeting. You may often hear it said that UKNOF's remit is "distribution of clue", so if the content of your talk fits with that ethos, we're actually pretty open minded about what the actual topic is - as long as it's relevant to our community's broad area of interest, and the quality is good. Talks are usually around 20 to 40 minutes in length, and common subject areas are: Network operations Network architecture and design Networking hardware and software architecture Peering and interconnect Data centre design and operations IPv6 deployment Network monitoring and measurement New innovations in networking technology Open protocol standards Domain Name System infrastructure Network security and abuse prevention Impact of public policy of network operations But, we're always on the lookout for something different, so don't feel it has to fall into the areas above. We're also interested in hearing proposals for panel discussions, as these are a great way of presenting and discussing different views on the same subject. Please submit your proposals via our website at http://indico.uknof.org.uk/event/uknof24 Submissions are welcome at any time, but for UKNOF24 we would like to have them no later than 12th December 2012. However, don't worry if you miss the deadline and have something interesting to talk about, as we are often able to accept shorter (10 minute) "lightning talks" closer in to the meeting. Please also get in touch if you would like to suggest any topics, themes or speakers. Please note that UKNOF is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings. Thanks, Mike From alumbis at gmail.com Fri Nov 9 18:33:47 2012 From: alumbis at gmail.com (Pete Lumbis) Date: Fri, 9 Nov 2012 13:33:47 -0500 Subject: Whats so difficult about ISSU In-Reply-To: <20121109132723.GA29560@pob.ytti.fi> References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> Message-ID: I apologize, I realized I forgot a critical word in my reply. The new Cisco OSes are /NOT/ run to completion. For IOS-XE we have Linux in charge of the scheduler with a multi-threaded IOSd process responsible for the control plane. I'm not familiar with movements to put processes directly on top of the kernel, but this would be a lot more like the NX-OS model where a process like BGP can crash without taking down the system (or the critical IOSd process for example). The down side of this model is that control plane scaling, due to message passing, starts to have a lot of overhead. You can see this in the fact that the NX-OS routing scale is not where IOS-XE is. -Pete On Fri, Nov 9, 2012 at 8:27 AM, Saku Ytti wrote: > On (2012-11-09 08:02 -0500), Pete Lumbis wrote: > >> I can't speak for JunOS, but none of the "new" IOS operating systems >> are run to completion. This includes IOS-XE, XR and NX-OS. > > Really? I thought IOS XE is Linux control-plane on top of where you have > monolithic IOSd process? > I had chat with Michael Beesley when ASR1k was coming up, and he said Cisco > has plans to remove processes from IOS and directly on top of Linux in XE, > starting with BGP. But I don't think that has materialized? > > To me JunOS and IOS XE look very much same, NIX control-plane and magic > process with has its own memory management and cooperative > multitasking/scheduling? > > -- > ++ytti > From cscora at apnic.net Fri Nov 9 18:53:35 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Nov 2012 04:53:35 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201211091853.qA9IrZOs031181@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 10 Nov, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 430598 Prefixes after maximum aggregation: 179737 Deaggregation factor: 2.40 Unique aggregates announced to Internet: 211964 Total ASes present in the Internet Routing Table: 42546 Prefixes per ASN: 10.12 Origin-only ASes present in the Internet Routing Table: 33796 Origin ASes announcing only one prefix: 15820 Transit ASes present in the Internet Routing Table: 5667 Transit-only ASes present in the Internet Routing Table: 143 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 41 Max AS path prepend of ASN ( 22394) 37 Prefixes from unregistered ASNs in the Routing Table: 1021 Unregistered ASNs in the Routing Table: 362 Number of 32-bit ASNs allocated by the RIRs: 3454 Number of 32-bit ASNs visible in the Routing Table: 3083 Prefixes from 32-bit ASNs in the Routing Table: 8404 Special use prefixes present in the Routing Table: 14 Prefixes being announced from unallocated address space: 159 Number of addresses announced to Internet: 2613326316 Equivalent to 155 /8s, 196 /16s and 49 /24s Percentage of available address space announced: 70.6 Percentage of allocated address space announced: 70.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.8 Total number of prefixes smaller than registry allocations: 151196 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 104236 Total APNIC prefixes after maximum aggregation: 32552 APNIC Deaggregation factor: 3.20 Prefixes being announced from the APNIC address blocks: 105065 Unique aggregates announced from the APNIC address blocks: 43031 APNIC Region origin ASes present in the Internet Routing Table: 4787 APNIC Prefixes per ASN: 21.95 APNIC Region origin ASes announcing only one prefix: 1247 APNIC Region transit ASes present in the Internet Routing Table: 780 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 354 Number of APNIC addresses announced to Internet: 714174880 Equivalent to 42 /8s, 145 /16s and 113 /24s Percentage of available APNIC address space announced: 83.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 155121 Total ARIN prefixes after maximum aggregation: 78402 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155953 Unique aggregates announced from the ARIN address blocks: 69890 ARIN Region origin ASes present in the Internet Routing Table: 15281 ARIN Prefixes per ASN: 10.21 ARIN Region origin ASes announcing only one prefix: 5769 ARIN Region transit ASes present in the Internet Routing Table: 1594 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 41 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1087874432 Equivalent to 64 /8s, 215 /16s and 165 /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, 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: 108902 Total RIPE prefixes after maximum aggregation: 57789 RIPE Deaggregation factor: 1.88 Prefixes being announced from the RIPE address blocks: 111641 Unique aggregates announced from the RIPE address blocks: 72576 RIPE Region origin ASes present in the Internet Routing Table: 16950 RIPE Prefixes per ASN: 6.59 RIPE Region origin ASes announcing only one prefix: 8148 RIPE Region transit ASes present in the Internet Routing Table: 2752 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2004 Number of RIPE addresses announced to Internet: 648615332 Equivalent to 38 /8s, 169 /16s and 21 /24s Percentage of available RIPE address space announced: 94.3 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, 196608-199679 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: 44231 Total LACNIC prefixes after maximum aggregation: 8710 LACNIC Deaggregation factor: 5.08 Prefixes being announced from the LACNIC address blocks: 47694 Unique aggregates announced from the LACNIC address blocks: 22765 LACNIC Region origin ASes present in the Internet Routing Table: 1701 LACNIC Prefixes per ASN: 28.04 LACNIC Region origin ASes announcing only one prefix: 481 LACNIC Region transit ASes present in the Internet Routing Table: 326 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 702 Number of LACNIC addresses announced to Internet: 119237416 Equivalent to 7 /8s, 27 /16s and 107 /24s Percentage of available LACNIC address space announced: 71.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 9585 Total AfriNIC prefixes after maximum aggregation: 2230 AfriNIC Deaggregation factor: 4.30 Prefixes being announced from the AfriNIC address blocks: 10086 Unique aggregates announced from the AfriNIC address blocks: 3567 AfriNIC Region origin ASes present in the Internet Routing Table: 568 AfriNIC Prefixes per ASN: 17.76 AfriNIC Region origin ASes announcing only one prefix: 175 AfriNIC Region transit ASes present in the Internet Routing Table: 122 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 43120640 Equivalent to 2 /8s, 145 /16s and 248 /24s Percentage of available AfriNIC address space announced: 42.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 4766 2959 11557 898 Korea Telecom (KIX) 17974 2421 826 46 PT TELEKOMUNIKASI INDONESIA 7545 1802 301 88 TPG Internet Pty Ltd 4755 1613 375 159 TATA Communications formerly 9829 1412 1155 42 BSNL National Internet Backbo 9583 1190 88 508 Sify Limited 7552 1131 1062 11 Vietel Corporation 4808 1111 2056 315 CNCGROUP IP network: China169 24560 1039 385 165 Bharti Airtel Ltd., Telemedia 9498 1020 310 73 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3204 992 191 Windstream Communications Inc 6389 3167 3722 159 bellsouth.net, inc. 18566 2084 382 180 Covad Communications 22773 1972 2931 128 Cox Communications, Inc. 1785 1933 678 128 PaeTec Communications, Inc. 20115 1670 1603 626 Charter Communications 4323 1589 1153 392 Time Warner Telecom 30036 1374 283 745 Mediacom Communications Corp 7018 1268 10275 846 AT&T WorldNet Services 7011 1220 333 692 Citizens Utilities 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 1738 544 16 Corbina telecom 12479 853 777 63 Uni2 Autonomous System 34984 829 207 199 BILISIM TELEKOM 31148 726 37 9 FreeNet ISP 13188 724 93 139 Educational Network 6830 712 2313 435 UPC Distribution Services 20940 711 228 548 Akamai Technologies European 58113 602 67 365 LIR DATACENTER TELECOM SRL 8551 596 364 61 Bezeq International 3320 494 8438 405 Deutsche Telekom AG Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2251 384 208 TVCABLE BOGOTA 28573 2170 1283 64 NET Servicos de Comunicao S.A 7303 1663 1139 202 Telecom Argentina Stet-France 8151 1596 3035 347 UniNet S.A. de C.V. 6503 1539 435 67 AVANTEL, S.A. 27947 747 77 91 Telconet S.A 3816 654 309 75 Empresa Nacional de Telecomun 11172 588 85 65 Servicios Alestra S.A de C.V 18881 584 716 18 Global Village Telecom 7738 582 1178 33 Telecomunicacoes da Bahia 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 24863 903 275 36 LINKdotNET AS number 36998 772 48 3 MOBITEL 8452 547 958 13 TEDATA 6713 516 650 19 Itissalat Al-MAGHRIB 24835 287 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 181 697 88 MTN Network Solutions 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 7029 3204 992 191 Windstream Communications Inc 6389 3167 3722 159 bellsouth.net, inc. 4766 2959 11557 898 Korea Telecom (KIX) 17974 2421 826 46 PT TELEKOMUNIKASI INDONESIA 10620 2251 384 208 TVCABLE BOGOTA 28573 2170 1283 64 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 22773 1972 2931 128 Cox Communications, Inc. 1785 1933 678 128 PaeTec Communications, Inc. 7545 1802 301 88 TPG Internet Pty Ltd 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 3167 3008 bellsouth.net, inc. 17974 2421 2375 PT TELEKOMUNIKASI INDONESIA 28573 2170 2106 NET Servicos de Comunicao S.A 4766 2959 2061 Korea Telecom (KIX) 10620 2251 2043 TVCABLE BOGOTA 18566 2084 1904 Covad Communications 22773 1972 1844 Cox Communications, Inc. 1785 1933 1805 PaeTec Communications, Inc. 8402 1738 1722 Corbina telecom 7545 1802 1714 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59530 UNALLOCATED 5.8.182.0/24 31261 GARS Telecom 61408 UNALLOCATED 5.56.0.0/21 174 Cogent Communication 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< 128.0.160.0/21 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.220.80.0/24 38925 DAC AS Germany 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:18 /9:13 /10:29 /11:88 /12:243 /13:480 /14:851 /15:1552 /16:12448 /17:6535 /18:10898 /19:21305 /20:30713 /21:32757 /22:43317 /23:40393 /24:224694 /25:1361 /26:1697 /27:905 /28:182 /29:78 /30:17 /31:0 /32:24 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2644 3204 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1786 3167 bellsouth.net, inc. 8402 1450 1738 Corbina telecom 22773 1300 1972 Cox Communications, Inc. 30036 1291 1374 Mediacom Communications Corp 11492 1149 1184 Cable One 6503 1054 1539 AVANTEL, S.A. 1785 1018 1933 PaeTec Communications, Inc. 7011 955 1220 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:645 2:780 3:1 4:13 5:641 6:3 8:477 12:1955 13:3 14:688 15:11 16:3 17:6 20:27 23:211 24:1813 27:1396 31:1034 32:54 33:2 34:2 36:7 37:930 38:837 39:2 40:138 41:2657 42:177 44:3 46:1648 47:2 49:505 50:607 52:12 54:27 55:5 56:4 57:27 58:986 59:544 60:237 61:1296 62:948 63:2018 64:4296 65:2202 66:4523 67:2102 68:1159 69:3221 70:936 71:554 72:1889 74:2620 75:478 76:284 77:992 78:1008 79:512 80:1242 81:980 82:629 83:539 84:520 85:1149 86:507 87:945 88:350 89:1739 90:305 91:5306 92:580 93:1411 94:1710 95:1281 96:412 97:325 98:971 99:39 100:31 101:291 103:1762 105:519 106:121 107:203 108:478 109:1632 110:831 111:978 112:435 113:738 114:676 115:895 116:883 117:758 118:967 119:1233 120:362 121:693 122:1698 123:1163 124:1332 125:1288 128:554 129:200 130:292 131:661 132:315 133:142 134:253 135:62 136:217 137:238 138:339 139:175 140:503 141:291 142:496 143:378 144:493 145:83 146:525 147:267 148:737 149:327 150:157 151:211 152:451 153:183 154:21 155:432 156:228 157:364 158:285 159:670 160:337 161:414 162:369 163:191 164:581 165:446 166:454 167:561 168:980 169:130 170:919 171:151 172:7 173:1699 174:635 175:471 176:728 177:1396 178:1642 180:1383 181:167 182:1108 183:302 184:617 185:54 186:2071 187:1397 188:1747 189:1623 190:5835 192:6049 193:5407 194:4134 195:3462 196:1229 197:260 198:3906 199:5092 200:5999 201:1974 202:8735 203:8714 204:4427 205:2537 206:2761 207:2807 208:4067 209:3626 210:2832 211:1531 212:2140 213:1848 214:892 215:75 216:5167 217:1572 218:577 219:311 220:1260 221:531 222:337 223:405 End of report From saku at ytti.fi Fri Nov 9 21:00:59 2012 From: saku at ytti.fi (Saku Ytti) Date: Fri, 9 Nov 2012 23:00:59 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> Message-ID: <20121109210059.GA29673@pob.ytti.fi> On (2012-11-09 13:33 -0500), Pete Lumbis wrote: > I apologize, I realized I forgot a critical word in my reply. > > The new Cisco OSes are /NOT/ run to completion. I did not notice that :). I assumed not was there, and was arguing that I thought IOS XE still is. I know XR and NX-OS aren't. > For IOS-XE we have Linux in charge of the scheduler with a > multi-threaded IOSd process responsible for the control plane. I'm I'm sceptical if this means there isn't normal IOS run-to-completion scheduler, certainly not all ios processes are separate threads to linux kernel? But I guess this is moving target. Would be interesting to hear how many threads, what are threads relative priorities, what runs in each thread etc. But anyhow just to hear it is threaded, is good news. Does this mean, IOSd can capitalize on multiple cores? (Something JunOS cannot do today) > critical IOSd process for example). The down side of this model is > that control plane scaling, due to message passing, starts to have a > lot of overhead. You can see this in the fact that the NX-OS routing > scale is not where IOS-XE is. Yup, luckily you guys stopped freescale pq3 and switch to xeon in ng nexus sup (unfortunately you also killed CMP, which I think every vendor should have). I think the overhead is worth it, built correctly you can scale horizontally and just keep throwing faster RP CPU at it. -- ++ytti From alumbis at gmail.com Fri Nov 9 21:58:51 2012 From: alumbis at gmail.com (Pete Lumbis) Date: Fri, 9 Nov 2012 16:58:51 -0500 Subject: Whats so difficult about ISSU In-Reply-To: <20121109210059.GA29673@pob.ytti.fi> References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> Message-ID: On Fri, Nov 9, 2012 at 4:00 PM, Saku Ytti wrote: >> For IOS-XE we have Linux in charge of the scheduler with a >> multi-threaded IOSd process responsible for the control plane. I'm > > I'm sceptical if this means there isn't normal IOS run-to-completion > scheduler, certainly not all ios processes are separate threads to linux > kernel? But I guess this is moving target. Would be interesting to hear how > many threads, what are threads relative priorities, what runs in each > thread etc. > But anyhow just to hear it is threaded, is good news. Does this mean, IOSd > can capitalize on multiple cores? (Something JunOS cannot do today) > I do not believe that the linux scheduler is run to completion, but to be honest I'm not 100% certain. I know a big reason for IOS-XE was to be able to operate in multicore environments. From a high level you have IOSd as a process with each traditional process (BGP, OSPF, IP Input) as a thread within IOSd. Overall IOS-XE is Linux managing a few processes: IOSd, FMan-RP, CMan-RP (and a few others) FMan deals with adjacencies and CMan deals with modules/cards and IOSd all the interesting stuff. Since Linux is the piece actually running the show IOS-XE gets all the memory management and scheduling benefits that linux has. From cidr-report at potaroo.net Fri Nov 9 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Nov 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201211092200.qA9M008o012169@wattle.apnic.net> This report has been generated at Fri Nov 9 21:13:09 2012 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 02-11-12 431467 249208 03-11-12 431919 249577 04-11-12 432057 249241 05-11-12 432211 249589 06-11-12 432407 249528 07-11-12 432725 249783 08-11-12 432776 250342 09-11-12 432954 250442 AS Summary 42666 Number of ASes in routing system 17750 Number of ASes announcing only one prefix 3204 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 114148320 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 09Nov12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 433138 250382 182756 42.2% All ASes AS6389 3167 163 3004 94.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2170 65 2105 97.0% NET Servicos de Comunicao S.A. AS4766 2964 940 2024 68.3% KIXS-AS-KR Korea Telecom AS17974 2421 537 1884 77.8% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1972 130 1842 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7029 3204 1495 1709 53.3% WINDSTREAM - Windstream Communications Inc AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS10620 2250 640 1610 71.6% Telmex Colombia S.A. AS7303 1669 426 1243 74.5% Telecom Argentina S.A. AS4323 1594 398 1196 75.0% TWTC - tw telecom holdings, inc. AS4755 1613 532 1081 67.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1131 200 931 82.3% VIETEL-AS-AP Vietel Corporation AS8151 1603 690 913 57.0% Uninet S.A. de C.V. AS18101 1016 173 843 83.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS1785 1933 1155 778 40.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1111 348 763 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 862 115 747 86.7% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS7545 1803 1120 683 37.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS855 708 52 656 92.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1118 494 624 55.8% LEVEL3 Level 3 Communications AS17676 707 89 618 87.4% GIGAINFRA Softbank BB Corp. AS19262 1002 403 599 59.8% VZGNI-TRANSIT - Verizon Online LLC AS3549 1038 442 596 57.4% GBLX Global Crossing Ltd. AS24560 1039 444 595 57.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS36998 772 178 594 76.9% SDN-MOBITEL AS22561 1006 432 574 57.1% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 579 30 549 94.8% VTR BANDA ANCHA S.A. AS4780 844 299 545 64.6% SEEDNET Digital United Inc. AS18881 584 49 535 91.6% Global Village Telecom AS7011 1220 692 528 43.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 45184 13154 32030 70.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 41.222.82.0/24 AS37110 moztel-as 41.222.83.0/24 AS37110 moztel-as 41.222.85.0/24 AS37110 moztel-as 41.222.86.0/24 AS37110 moztel-as 41.222.87.0/24 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.9.166.0/23 AS30893 GLASSBILEN-AS Glassbilen networks 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 Nov 9 22:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Nov 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201211092200.qA9M02cm012188@wattle.apnic.net> BGP Update Report Interval: 01-Nov-12 -to- 08-Nov-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS31692 80292 4.1% 10036.5 -- SATURN-R-AS OOO Saturn-R 2 - AS8402 45763 2.3% 15.3 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS28306 43337 2.2% 4333.7 -- TC Net Inform?tica e Telecomunica??es LTDA 4 - AS9829 37170 1.9% 52.7 -- BSNL-NIB National Internet Backbone 5 - AS13118 32918 1.7% 1936.4 -- ASN-YARTELECOM OJSC Rostelecom 6 - AS22561 22148 1.1% 228.3 -- DIGITAL-TELEPORT - Digital Teleport Inc. 7 - AS2686 15312 0.8% 134.3 -- AT&T Global Network Services - EMEA 8 - AS24560 14896 0.8% 17.4 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 9 - AS2708 14790 0.8% 108.0 -- Universidad de Guanajuato 10 - AS45322 14157 0.7% 2831.4 -- IDNIC-ID Indonesia Network Information Center 11 - AS7552 12636 0.6% 13.0 -- VIETEL-AS-AP Vietel Corporation 12 - AS1637 10875 0.6% 122.2 -- DNIC-AS-01637 - Headquarters, USAISC 13 - AS11300 10778 0.6% 317.0 -- GLOBECOMM-11300 - Globecomm Services Maryland LLC 14 - AS11664 10693 0.5% 36.1 -- Techtel LMDS Comunicaciones Interactivas S.A. 15 - AS2561 10428 0.5% 137.2 -- EUN 16 - AS48159 9959 0.5% 30.8 -- TIC-AS Telecommunication Infrastructure Company 17 - AS21599 9879 0.5% 395.2 -- NETDIRECT S.A. 18 - AS5800 9647 0.5% 36.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS17974 9587 0.5% 6.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS17762 9191 0.5% 77.2 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS31692 80292 4.1% 10036.5 -- SATURN-R-AS OOO Saturn-R 2 - AS21684 5531 0.3% 5531.0 -- CYBERINETBGP - Cyberonics, Inc. 3 - AS28306 43337 2.2% 4333.7 -- TC Net Inform?tica e Telecomunica??es LTDA 4 - AS19406 4120 0.2% 4120.0 -- TWRS-MA - Towerstream I, Inc. 5 - AS293 3102 0.2% 3102.0 -- ESNET - ESnet 6 - AS24057 2997 0.1% 2997.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 7 - AS45322 14157 0.7% 2831.4 -- IDNIC-ID Indonesia Network Information Center 8 - AS40946 2718 0.1% 2718.0 -- PROCON - Sat Track 9 - AS14680 7325 0.4% 2441.7 -- REALE-6 - Auction.com 10 - AS13118 32918 1.7% 1936.4 -- ASN-YARTELECOM OJSC Rostelecom 11 - AS50478 3329 0.2% 1664.5 -- BVOX BVOX AS 12 - AS59706 2614 0.1% 1307.0 -- IBC-AS-TIRANA I.B.C shpk 13 - AS36529 2560 0.1% 1280.0 -- AXXA-RACKCO - Rackco.com 14 - AS39915 5278 0.3% 1055.6 -- PREM-AS Premiere Global Services 15 - AS6197 913 0.1% 913.0 -- BATI-ATL - BellSouth Network Solutions, Inc 16 - AS55410 7967 0.4% 796.7 -- VODAFONE-NET-AS-AP C48 Okhla Industrial Estate, New Delhi-110020 17 - AS32244 3450 0.2% 690.0 -- LIQUID-WEB-INC - Liquid Web, Inc. 18 - AS24994 1379 0.1% 689.5 -- GENESYS-AS genesys informatica srl 19 - AS11203 623 0.0% 623.0 -- CALDSL - ZINNIA NETWORKS INC 20 - AS29398 609 0.0% 609.0 -- PETROBALTIC Lotos Petrobaltic Spolka Akcyjna TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 178.161.166.0/24 20055 0.9% AS31692 -- SATURN-R-AS OOO Saturn-R 2 - 178.161.163.0/24 20054 0.9% AS31692 -- SATURN-R-AS OOO Saturn-R 3 - 178.161.174.0/24 20053 0.9% AS31692 -- SATURN-R-AS OOO Saturn-R 4 - 178.161.162.0/24 20053 0.9% AS31692 -- SATURN-R-AS OOO Saturn-R 5 - 109.161.64.0/19 16996 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 6 - 93.181.255.0/24 15798 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 7 - 122.161.0.0/16 11277 0.5% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - 184.159.130.0/23 11206 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 9 - 184.157.224.0/19 10560 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 10 - 200.46.0.0/19 9831 0.5% AS21599 -- NETDIRECT S.A. 11 - 12.139.133.0/24 5796 0.3% AS14680 -- REALE-6 - Auction.com 12 - 216.4.42.0/24 5531 0.3% AS21684 -- CYBERINETBGP - Cyberonics, Inc. 13 - 95.128.195.0/24 5268 0.2% AS39915 -- PREM-AS Premiere Global Services 14 - 194.63.9.0/24 4827 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 15 - 187.94.82.0/24 4334 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 16 - 187.94.81.0/24 4334 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 17 - 189.38.8.0/24 4334 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 18 - 189.38.5.0/24 4334 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 19 - 187.94.83.0/24 4334 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 20 - 189.38.9.0/24 4334 0.2% AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA 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 saku at ytti.fi Fri Nov 9 22:07:45 2012 From: saku at ytti.fi (Saku Ytti) Date: Sat, 10 Nov 2012 00:07:45 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> Message-ID: <20121109220745.GA29691@pob.ytti.fi> On (2012-11-09 16:58 -0500), Pete Lumbis wrote: > I do not believe that the linux scheduler is run to completion, but to > be honest I'm not 100% certain. I know a big reason for IOS-XE was to It certainly is not, I'm not proposing it is. I'm saying it is bit of a stretch to believe that IOSd does not have own legacy scheduler and memory management as pulling that switch would have been quite major rework. > be able to operate in multicore environments. From a high level you > have IOSd as a process with each traditional process (BGP, OSPF, IP > Input) as a thread within IOSd. Overall IOS-XE is Linux managing a few > processes: IOSd, FMan-RP, CMan-RP (and a few others) FMan deals with > adjacencies and CMan deals with modules/cards and IOSd all the > interesting stuff. Since Linux is the piece actually running the show > IOS-XE gets all the memory management and scheduling benefits that > linux has. So each IOSd process 'show proc cpu' are separate threads to linux? -- ++ytti From alumbis at gmail.com Sat Nov 10 01:24:35 2012 From: alumbis at gmail.com (Pete Lumbis) Date: Fri, 9 Nov 2012 20:24:35 -0500 Subject: Whats so difficult about ISSU In-Reply-To: <20121109220745.GA29691@pob.ytti.fi> References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> Message-ID: > So each IOSd process 'show proc cpu' are separate threads to linux? Yep. The "show platform software..." commands are used to look at things in software, outside of IOSd. Don't get me started on how absurd the command lengths are. =========================== ASR#show proc cpu CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 2 16 125 0.00% 0.00% 0.00% 0 Chunk Manager 2 12446 402522 30 0.00% 0.00% 0.00% 0 Load Meter 3 2927 97933 29 0.00% 0.00% 0.00% 0 CDP Protocol .... ASR#show platform software process list rp active Name Pid PPid Group Id Status Priority Size ------------------------------------------------------------------------------ init 1 0 1 S 20 2207744 kthreadd 2 0 0 S 15 0 ksoftirqd/0 3 2 0 S 15 0 watchdog/0 4 2 0 S 4294967196 0 events/0 5 2 0 S 15 0 khelper 6 2 0 S 15 0 netns 9 2 0 S 15 0 linux_iosd-imag 26181 24860 26181 R 20 2010271744 ..... ASR#show plat soft proc slot rp active monitor cycles 5 top - 17:14:45 up 23 days, 7:15, 0 users, load average: 0.10, 0.11, 0.09 Tasks: 126 total, 2 running, 124 sleeping, 0 stopped, 0 zombie Cpu(s): 1.8%us, 3.0%sy, 0.0%ni, 95.1%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st Mem: 3874968k total, 1760588k used, 2114380k free, 129520k buffers Swap: 0k total, 0k used, 0k free, 1122644k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25395 root 20 0 26784 15m 13m S 9.8 0.4 288:48.06 imand 23350 root 20 0 28004 11m 8628 S 5.9 0.3 219:03.66 cmand 13631 root 20 0 2648 1148 884 R 2.0 0.0 0:00.01 top 26181 root 20 0 1917m 406m 143m R 2.0 10.7 365:07.12 linux_iosd-imag 28395 root 20 0 101m 90m 6328 S 2.0 2.4 13:08.97 smand 1 root 20 0 2156 640 552 S 0.0 0.0 0:04.66 init =========================== From shtsuchi at cisco.com Sat Nov 10 06:37:39 2012 From: shtsuchi at cisco.com (Shishio Tsuchiya) Date: Sat, 10 Nov 2012 01:37:39 -0500 Subject: GeoIP information page Message-ID: <509DF633.3060009@cisco.com> Hi As NANOG53 presentation described,most of information of GeoIP was written in this page. http://nanog.cluepon.net/index.php/GeoIP http://www.nanog.org/meetings/nanog53/presentations/Wednesday/Barnes.pdf But the service is not currently available. Was it moved to another? or Has someone backup? Regards, -Shishio From saku at ytti.fi Sat Nov 10 08:43:38 2012 From: saku at ytti.fi (Saku Ytti) Date: Sat, 10 Nov 2012 10:43:38 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> Message-ID: <20121110084338.GA29984@pob.ytti.fi> On (2012-11-09 20:24 -0500), Pete Lumbis wrote: > > So each IOSd process 'show proc cpu' are separate threads to linux? > Yep. The "show platform software..." commands are used to look at things in To be honest I'm very sceptical about this. I fully accept that IOSd is multithreaded. But I'm having difficulties accepting that each IOSd process would be own thread scheduled by Linux and that native/IOS run-to-completion scheduler isn't used at all. But we're out of scope for ISSU thread in nanog-ml, I think. I do appreciate always when vendors pitch in in public forums, so thank you for that Pete. -- ++ytti From saku at ytti.fi Sat Nov 10 13:17:49 2012 From: saku at ytti.fi (Saku Ytti) Date: Sat, 10 Nov 2012 15:17:49 +0200 Subject: Whats so difficult about ISSU In-Reply-To: <20121110084338.GA29984@pob.ytti.fi> References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> Message-ID: <20121110131749.GA30406@pob.ytti.fi> On (2012-11-10 10:43 +0200), Saku Ytti wrote: > > > So each IOSd process 'show proc cpu' are separate threads to linux? > > Yep. The "show platform software..." commands are used to look at things in > > To be honest I'm very sceptical about this. I fully accept that IOSd is > multithreaded. But I'm having difficulties accepting that each IOSd process > would be own thread scheduled by Linux and that native/IOS > run-to-completion scheduler isn't used at all. Someone who has ASR1004 just ran 'ps auxH' and it's running 3 threads. So IOS XE control-plane is for most parts run-to-completion and relies on classic IOS scheduler and memory-management. I'm not saying this is inherently bad, it is least overhead way to do it, but it also sets requirement for code quality unrealistically high. I'm pretty sure it would be easier to start from scratch and loan IOS BGP, ISIS, OSPF etc code to new project than to try to make IOS be pre-emptive and SMP safe. I'm also not saying IOS XE is bad, JunOS is same design and many consider JunOS good design (I'm not one of them). I think XR and NX-OS are better, more modern examples how to do things now, when we have some extra CPU time in control-plane. It would be interesting ti know what are the roles of these 3 threads. If I'd have to guess, one is IOS control-plane, one is emulation of IOS interrupts and one is abstraction for hardware forwarding. But this is likely far off. -- ++ytti From randy at psg.com Sat Nov 10 15:14:57 2012 From: randy at psg.com (Randy Bush) Date: Sun, 11 Nov 2012 00:14:57 +0900 Subject: Whats so difficult about ISSU In-Reply-To: <20121110084338.GA29984@pob.ytti.fi> References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> Message-ID: as to whether ios/xe is rtc, you may want to see my preso at the last nanog. randy From saku at ytti.fi Sat Nov 10 16:48:26 2012 From: saku at ytti.fi (Saku Ytti) Date: Sat, 10 Nov 2012 18:48:26 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> Message-ID: <20121110164826.GA30511@pob.ytti.fi> On (2012-11-11 00:14 +0900), Randy Bush wrote: > as to whether ios/xe is rtc, you may want to see my preso at the last > nanog. NANOG56? I only found RPKI Propagation by you. Direct URL would be appreciated. But I really have 0 doubt that IOSd is run-to-completion, exactly like RPD is. But IOSd indeed seems to have 3 OS threads, while RPD is single threaded. As I understand RPD does have green threads though, but that is not helping at all making things simple for JNPR, more if anything, it's making things more complex. If native process separation and even native thread separation cannot be made scale (I'm highly suspicious why it couldn't). Then I wonder why vendors don't use some existing VM, instead of inventing their own. Many existing are free and support green threads and native thread and many-to-many mapping between, so you could get benefit of minimal overhead of green thread and you get benefit of OS level threading (SMP, scheduling) to compartmentalize processes. -- ++ytti From nick at foobar.org Sat Nov 10 17:26:10 2012 From: nick at foobar.org (Nick Hilliard) Date: Sat, 10 Nov 2012 17:26:10 +0000 Subject: Whats so difficult about ISSU In-Reply-To: <20121110164826.GA30511@pob.ytti.fi> References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> <20121110164826.GA30511@pob.ytti.fi> Message-ID: <509E8E32.20604@foobar.org> On 10/11/2012 16:48, Saku Ytti wrote: > If native process separation and even native thread separation cannot be > made scale (I'm highly suspicious why it couldn't). As the old joke goes, once you introduce threading to fix a problem, you end up with evmeonr eprboelm.s > Then I wonder why > vendors don't use some existing VM, instead of inventing their own. because of legacy issues. It's easier to rewrite from scratch than to adapt existing code. Nick From sthaug at nethelp.no Sat Nov 10 19:22:27 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 10 Nov 2012 20:22:27 +0100 (CET) Subject: Whats so difficult about ISSU In-Reply-To: <20121110164826.GA30511@pob.ytti.fi> References: <20121110084338.GA29984@pob.ytti.fi> <20121110164826.GA30511@pob.ytti.fi> Message-ID: <20121110.202227.74742034.sthaug@nethelp.no> > > as to whether ios/xe is rtc, you may want to see my preso at the last > > nanog. > > NANOG56? I only found RPKI Propagation by you. Direct URL would be > appreciated. Look towards the end of the presentation and you'll find run to completion... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From randy at psg.com Sat Nov 10 23:50:31 2012 From: randy at psg.com (Randy Bush) Date: Sun, 11 Nov 2012 08:50:31 +0900 Subject: Whats so difficult about ISSU In-Reply-To: <20121110164826.GA30511@pob.ytti.fi> References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> <20121110164826.GA30511@pob.ytti.fi> Message-ID: > NANOG56? I only found RPKI Propagation by you. Direct URL would be > appreciated. apologies. i slid a second preso into my time allotment, and i thought the archive maintainer was going to catenate them. here is the second preso, some measurements of the tcp behavior of bgp. http://archive.psg.com/121022.nanog-bgp-tcp.pdf > But I really have 0 doubt that IOSd is run-to-completion nor i. but, as i said but did not write in my preso, consider the following: linux has become a fad in the vendor community. it seems to lend legitimacy to their products in some way, witness this discussion. but linux has the gpl poison. so, any code that they wish to keep proprietary is in userland. randy From j at arpa.com Sun Nov 11 05:11:41 2012 From: j at arpa.com (jamie rishaw) Date: Sat, 10 Nov 2012 23:11:41 -0600 Subject: OT: Hurricane retweet-2-smtp. Message-ID: Here would be a prime guess.. obviously anyone that can help, karma=good.. -jamie /// from @virtadpt -- > Need sources for Proxim point-to-point microwave hardware. Needed for uplink from mesh to global Net. PLS RT #sandy #nyc #projectbyzantium From saku at ytti.fi Sun Nov 11 09:45:36 2012 From: saku at ytti.fi (Saku Ytti) Date: Sun, 11 Nov 2012 11:45:36 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> <20121110164826.GA30511@pob.ytti.fi> Message-ID: <20121111094536.GA30915@pob.ytti.fi> On (2012-11-11 08:50 +0900), Randy Bush wrote: > linux has become a fad in the vendor community. it seems to lend > legitimacy to their products in some way, witness this discussion. > but linux has the gpl poison. so, any code that they wish to keep > proprietary is in userland. I've sometimes wondered why Linux is so common, and not FreeBSD. Is it easier to hire people if you use Linux? Or is GPL not really problematic issue, as you can hide your intellectual property in binary kernel modules? -- ++ytti From randy at psg.com Sun Nov 11 10:22:56 2012 From: randy at psg.com (Randy Bush) Date: Sun, 11 Nov 2012 19:22:56 +0900 Subject: Whats so difficult about ISSU In-Reply-To: <20121111094536.GA30915@pob.ytti.fi> References: <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> <20121110164826.GA30511@pob.ytti.fi> <20121111094536.GA30915@pob.ytti.fi> Message-ID: > I've sometimes wondered why Linux is so common, and not FreeBSD. juniper is currently freebsd > Is it easier to hire people if you use Linux? i think it's just perceived as having more customer acceptance. > Or is GPL not really problematic issue my lawyer tells me it is very problematic randy From regnauld at nsrc.org Sun Nov 11 10:33:57 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Sun, 11 Nov 2012 11:33:57 +0100 Subject: Whats so difficult about ISSU In-Reply-To: <20121111094536.GA30915@pob.ytti.fi> References: <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> <20121110164826.GA30511@pob.ytti.fi> <20121111094536.GA30915@pob.ytti.fi> Message-ID: <20121111103357.GB77227@macbook.bluepipe.net> Saku Ytti (saku) writes: > > I've sometimes wondered why Linux is so common, and not FreeBSD. Historical reasons and good timing. > Is it easier to hire people if you use Linux? As opposed to... ? > Or is GPL not really problematic issue, > as you can hide your intellectual property in binary kernel modules? You can't. The GPL has provisions for that. Common mistake, several lawsuits have shown. As Randy pointed out, Juniper is FreeBSD inside, and NetApp uses it as well (+ number of other vendors that don't advertise it because they don't have to). Phil From mikevs at xs4all.net Sun Nov 11 10:46:44 2012 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Sun, 11 Nov 2012 11:46:44 +0100 Subject: Whats so difficult about ISSU In-Reply-To: References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> <20121110164826.GA30511@pob.ytti.fi> Message-ID: <201211111046.qABAkiGe006098@xs8.xs4all.nl> In article you write: >linux has become a fad in the vendor community. it seems to lend >legitimacy to their products in some way, witness this discussion. >but linux has the gpl poison. so, any code that they wish to keep >proprietary is in userland. Which isn't really a problem, none of the control plane stuff needs to run in the kernel. The only thing that needs to run in the kernel is the device driver(s) to talk to the forwarding plane hardware, but if you use ethernet or infiniband for that communication you don't need any proprietary drivers. Mike. From tknchris at gmail.com Sun Nov 11 12:07:27 2012 From: tknchris at gmail.com (chris) Date: Sun, 11 Nov 2012 07:07:27 -0500 Subject: OT: Hurricane retweet-2-smtp. In-Reply-To: References: Message-ID: It made me lol a bit that their website specifically says this: *Unlike most mesh implementations, a Byzantium Mesh requires no specialized equipment that may not be easy to get during an emergency, just an x86 computer with at least one 802.11 a/b/g/n wireless interface.* yet now we are in search of specialty wifi hw? :) chris On Sun, Nov 11, 2012 at 12:11 AM, jamie rishaw wrote: > Here would be a prime guess.. obviously anyone that can help, karma=good.. > > -jamie > > /// > > from @virtadpt -- > > > Need sources for Proxim point-to-point microwave hardware. Needed for > uplink from mesh to global Net. PLS RT #sandy #nyc #projectbyzantium > From bonomi at mail.r-bonomi.com Sun Nov 11 12:29:47 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 11 Nov 2012 06:29:47 -0600 (CST) Subject: OT: Hurricane retweet-2-smtp. In-Reply-To: Message-ID: <201211111229.qABCTlQf044071@mail.r-bonomi.com> > Date: Sun, 11 Nov 2012 07:07:27 -0500 > Subject: Re: OT: Hurricane retweet-2-smtp. > From: chris > > It made me lol a bit that their website specifically says this: > > *Unlike most mesh implementations, a Byzantium Mesh requires no specialized > equipment that may not be easy to get during an emergency, just an x86 > computer with at least one 802.11 a/b/g/n wireless interface.* > > yet now we are in search of specialty wifi hw? :) > chris There's something downright Byzantine about that! > > On Sun, Nov 11, 2012 at 12:11 AM, jamie rishaw wrote: > > > Here would be a prime guess.. obviously anyone that can help, karma=good.. > > > > -jamie > > > > /// > > > > from @virtadpt -- > > > > > Need sources for Proxim point-to-point microwave hardware. Needed for > > uplink from mesh to global Net. PLS RT #sandy #nyc #projectbyzantium > > > From jgreco at ns.sol.net Sun Nov 11 12:41:38 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 11 Nov 2012 06:41:38 -0600 (CST) Subject: Whats so difficult about ISSU In-Reply-To: <20121111094536.GA30915@pob.ytti.fi> Message-ID: <201211111241.qABCfcVi099436@aurora.sol.net> > On (2012-11-11 08:50 +0900), Randy Bush wrote: > > linux has become a fad in the vendor community. it seems to lend > > legitimacy to their products in some way, witness this discussion. > > but linux has the gpl poison. so, any code that they wish to keep > > proprietary is in userland. > > I've sometimes wondered why Linux is so common, and not FreeBSD. Is it > easier to hire people if you use Linux? Or is GPL not really problematic > issue, as you can hide your intellectual property in binary kernel modules? Years ago, Linux was relatively immature and FreeBSD wasn't. Vendors like Juniper, NetApp, Apple, etc., took whatever suited them from FreeBSD, often ran it on x86, and went on their way. The relatively low legal bar presented little problem, as was intended. Over the years, Linux was ported to more platforms, and has matured a good bit, so now the "obvious" choice when someone was looking for a cheap platform to build a residential CPE or NAT gateway or whatever became Linux. At the same time, large companies have poured lots of dollars and man-hours into Linux, and this has improved code quality and maturity. However, there are still legal issues relating to the GPL. If you're on supported CPU's, the BSD's are likely to be a better choice if you want to avoid legal entanglements. Otherwise, if you don't mind code disclosure, Linux supports more platforms. Both are relatively mature, feature-full operating systems when used for embedded applications. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From eugen at leitl.org Sun Nov 11 14:42:40 2012 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 11 Nov 2012 15:42:40 +0100 Subject: [HacDC:Byzantium] Re: OT: Hurricane retweet-2-smtp. Message-ID: <20121111144240.GO9750@leitl.org> ----- Forwarded message from Ben Mendis ----- From: Ben Mendis Date: Sun, 11 Nov 2012 08:37:13 -0500 To: Byzantium at hacdc.org Subject: Re: [HacDC:Byzantium] Re: OT: Hurricane retweet-2-smtp. Reply-To: Byzantium at hacdc.org We are in an interesting situation. Our call for hardware for Byzantium was just laptops and USB keys, but we're also extending an existing Commotion mesh, and trying to get a point to point connection to a part of the city that has stable power and internet. Byzantium works without the special equipment, but as we said in our talk, long range links must be improvised on a case by case basis. Ben the Pyrate On Nov 11, 2012 7:47 AM, "Eugen Leitl" wrote: > ----- Forwarded message from chris ----- > > From: chris > Date: Sun, 11 Nov 2012 07:07:27 -0500 > To: jamie rishaw > Cc: NANOG list > Subject: Re: OT: Hurricane retweet-2-smtp. > > It made me lol a bit that their website specifically says this: > > *Unlike most mesh implementations, a Byzantium Mesh requires no specialized > equipment that may not be easy to get during an emergency, just an x86 > computer with at least one 802.11 a/b/g/n wireless interface.* > > yet now we are in search of specialty wifi hw? :) > chris > > On Sun, Nov 11, 2012 at 12:11 AM, jamie rishaw wrote: > > > Here would be a prime guess.. obviously anyone that can help, > karma=good.. > > > > -jamie > > > > /// > > > > from @virtadpt -- > > > > > Need sources for Proxim point-to-point microwave hardware. Needed for > > uplink from mesh to global Net. PLS RT #sandy #nyc #projectbyzantium > > > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > -- > You received this message because you are subscribed to the Google Groups > "Project Byzantium (Emergency Mesh Networking)" group. > To post to this group, send email to Byzantium at hacdc.org. > To unsubscribe from this group, send email to > Byzantium+unsubscribe at hacdc.org. > For more options, visit this group at > http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group. To post to this group, send email to Byzantium at hacdc.org. To unsubscribe from this group, send email to Byzantium+unsubscribe at hacdc.org. For more options, visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en. ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From gary.buhrmaster at gmail.com Sun Nov 11 15:12:05 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sun, 11 Nov 2012 07:12:05 -0800 Subject: Whats so difficult about ISSU In-Reply-To: <20121111094536.GA30915@pob.ytti.fi> References: <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> <20121110164826.GA30511@pob.ytti.fi> <20121111094536.GA30915@pob.ytti.fi> Message-ID: On Sun, Nov 11, 2012 at 1:45 AM, Saku Ytti wrote: > ... Or is GPL not really problematic > issue, as you can hide your intellectual property in binary kernel modules? GPLv2, which governs the Linux Kernel, does tolorate use of binary kernel modules under some conditions (the classic example is the nVidia driver blob which uses a GPL shim). Regardless, most lawyers would advise a company to avoid being a test case for some of the poorly defined terms used in the license, including "derivative work". A recent paper discussing the issue can be found at: "LOADED QUESTION: EXAMINING LOADABLE KERNEL MODULES UNDER THE GENERAL PUBLIC LICENSE V2" http://digital.law.washington.edu/dspace-law/bitstream/handle/1773.1/1115/7WJLTA265.pdf?sequence=8 Gary From felipe at starbyte.net Sun Nov 11 15:31:41 2012 From: felipe at starbyte.net (Felipe Zanchet Grazziotin) Date: Sun, 11 Nov 2012 15:31:41 +0000 Subject: Whats so difficult about ISSU In-Reply-To: <201211111241.qABCfcVi099436@aurora.sol.net> References: <20121111094536.GA30915@pob.ytti.fi> <201211111241.qABCfcVi099436@aurora.sol.net> Message-ID: On Sun, Nov 11, 2012 at 12:41 PM, Joe Greco wrote: > If you're on supported CPU's, the BSD's are likely to be a better > choice if you want to avoid legal entanglements. Otherwise, if you > don't mind code disclosure, Linux supports more platforms. Both > are relatively mature, feature-full operating systems when used for > embedded applications. If your silicon vendor supports BSD's, of course. >From my (little) experience most vendors SDK will be available to Linux and vxWorks but not BSD. This limits companies that are building equipments based on third parties ASIC to use anything but Linux. My 0.02... Felipe From mysidia at gmail.com Sun Nov 11 15:32:44 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 11 Nov 2012 09:32:44 -0600 Subject: Whats so difficult about ISSU In-Reply-To: <201211111046.qABAkiGe006098@xs8.xs4all.nl> References: <20121109073621.GA29358@pob.ytti.fi> <20121109132723.GA29560@pob.ytti.fi> <20121109210059.GA29673@pob.ytti.fi> <20121109220745.GA29691@pob.ytti.fi> <20121110084338.GA29984@pob.ytti.fi> <20121110164826.GA30511@pob.ytti.fi> <201211111046.qABAkiGe006098@xs8.xs4all.nl> Message-ID: On 11/11/12, Miquel van Smoorenburg wrote: > Which isn't really a problem, none of the control plane stuff needs > to run in the kernel. The only thing that needs to run in the > kernel is the device driver(s) to talk to the forwarding plane Yes. But avoiding kernel mode is a consideration, even before GPL. Perhaps GPL is just another force to discourage developers from doing what they shouldn't be doing anyways -- which is to insert complicated code in the kernel itself to do application-specific things, instead of providing hardware interfaces for applications. You introduce risks if you run control plane things in kernel mode ring0 and not separate control plane functions into user processes. Risks that buggy code will be executed with privilege and corrupt critical data. Risks that a buffer overflow in the SNMP code will crash the kernel and cause the entire control unit to reboot. If instead, each control function is a separate user process, running without privilege in protected mode, then you have a larger amount of fault isolation provided by the hardware -- restart the SNMP process automatically, but leave ISISd/Bgpd alone, and no kernel panic... > hardware, but if you use ethernet or infiniband for that > communication you don't need any proprietary drivers. > Mike. -- -JH From gary.buhrmaster at gmail.com Sun Nov 11 16:07:22 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sun, 11 Nov 2012 08:07:22 -0800 Subject: Whats so difficult about ISSU In-Reply-To: References: <20121111094536.GA30915@pob.ytti.fi> <201211111241.qABCfcVi099436@aurora.sol.net> Message-ID: On Sun, Nov 11, 2012 at 7:31 AM, Felipe Zanchet Grazziotin wrote: ... > If your silicon vendor supports BSD's, of course. > From my (little) experience most vendors SDK will be available to > Linux and vxWorks but not BSD. > This limits companies that are building equipments based on third > parties ASIC to use anything but Linux. You are right, of course, since the silicon vendors customers decide what they want the device to support, and that is (currently) Linux and VxWorks. Some BSD folk are trying to change that, by investing their time in the patches/ports needed to support additional embedded processor types/derivatives and make it a viable platform. There is even a Raspberry Pi port now available for FreeBSD as I recall. Ideally those efforts will produce a viable ecosystem for BSD in this space. Gary From mysidia at gmail.com Sun Nov 11 16:33:37 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 11 Nov 2012 10:33:37 -0600 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: On 11/8/12, Mikael Abrahamsson wrote: > On Thu, 8 Nov 2012, Phil wrote: > NSR isn't ISSU. The equipment vendors call upgrades with NSR failover, ISSU; if their marketing people feel that a 0.5 or 6 second hit is "good enough".. If you care about the 0.5 seconds, it's important you speak their language, and require that vague expressions such as "In-Service Software Update" be clarified. Personally, I don't trust any of it; routers should have regular maintenance windows, period, with a minimum duration of 30 minutes. And software updates to fix known bugs should be done regularly, and during those windows. NSR for ISSU, or ISSU with a small hit called ISSU, is likely inexpensive for the network equipment vendors, because they already invested hundreds of thousands of developer hours in implementing and validating NSR functionality to provide redundancy against device failure. The process of replacing code on a hot device, and restructuring any stored data to match expectations of the new code, without suspending or delaying execution of any code during that process, is possible, but a non-trivial problem: whose solutions add complexity (and therefore a higher risk of bugs and unexpected results) to the upgrade process. You might reduce the hit from 0.5 seconds to 0.01 seconds by implementing true in-place upgrade 90% of the time; but 10% of the time, the online upgrade either fails, because of an issue with the online patch, or unexpected interactions between partially patched functional units, result in a period of incorrect device operation --- until the patching finishes, and continued use of bad data even after patching finished. > ISSU contains the wording "in service". 6 seconds of outage isn't "in > service". 0.5 seconds of outage isn't "in service". I could accept a few > microseconds of outage as being "ISSU", but tenths of seconds isn't in > service. What is the maximum percentage more would your organization be able to justify paying the network equipment vendor for routers/switches, to reduce the ISSU hit from 0.5 seconds to a few microseconds? :) >> The main remaining hurdle is updating microcode on linecards, they still >> need to be rebooted after an upgrade. > -- > Mikael Abrahamsson email: swmike at swm.pp.se -- -JH From frnkblk at iname.com Mon Nov 12 04:13:19 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 11 Nov 2012 22:13:19 -0600 Subject: Whats so difficult about ISSU In-Reply-To: References: Message-ID: <001001cdc08c$0c4fc040$24ef40c0$@iname.com> We do it on our Class 5 softswitch ... and it works consistently. There may be a few seconds, once, where a new call can't be made, but most people will re-dial. It just works. It can be done, but the product has to be built with that in mind. Frank -----Original Message----- From: Kasper Adel [mailto:karim.adel at gmail.com] Sent: Thursday, November 08, 2012 5:23 PM To: NANOG list Subject: Whats so difficult about ISSU Hello, We've been hearing about ISSU for so many years and i didnt hear that any vendor was able to achieve it yet. What is the technical reason behind that? If i understand correctly, the way it will be done would be simply to have extra ASICs/HW to be able to build dual circuits accessing the same memory, and gracefully switch from one to another. Is that right? Thanks, Kim From karim.adel at gmail.com Mon Nov 12 06:21:32 2012 From: karim.adel at gmail.com (Kasper Adel) Date: Mon, 12 Nov 2012 08:21:32 +0200 Subject: Whats so difficult about ISSU In-Reply-To: <001001cdc08c$0c4fc040$24ef40c0$@iname.com> References: <001001cdc08c$0c4fc040$24ef40c0$@iname.com> Message-ID: Hi Frank, Is it because C5 softswitches have expensive hardware, advanced software and dual asics? I would have never imagined that any vendor is capable of upgrading fpd's/ASICs ucode without a hit unless there are multiple chips continuously syncing with each other. Regards, Kim On Monday, November 12, 2012, Frank Bulk wrote: > We do it on our Class 5 softswitch ... and it works consistently. There > may > be a few seconds, once, where a new call can't be made, but most people > will > re-dial. It just works. > > It can be done, but the product has to be built with that in mind. > > Frank > > -----Original Message----- > From: Kasper Adel [mailto:karim.adel at gmail.com ] > Sent: Thursday, November 08, 2012 5:23 PM > To: NANOG list > Subject: Whats so difficult about ISSU > > Hello, > > We've been hearing about ISSU for so many years and i didnt hear that any > vendor was able to achieve it yet. > > What is the technical reason behind that? > > If i understand correctly, the way it will be done would be simply to have > extra ASICs/HW to be able to build dual circuits accessing the same memory, > and gracefully switch from one to another. Is that right? > > Thanks, > Kim > > > From Bryan at bryanfields.net Mon Nov 12 06:40:12 2012 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 12 Nov 2012 01:40:12 -0500 Subject: Whats so difficult about ISSU In-Reply-To: References: <001001cdc08c$0c4fc040$24ef40c0$@iname.com> Message-ID: <50A099CC.4050106@bryanfields.net> On 11/12/12 1:21 AM, Kasper Adel wrote: > Is it because C5 softswitches have expensive hardware, advanced software > and dual asics? I would have never imagined that any vendor is capable of > upgrading fpd's/ASICs ucode without a hit unless there are multiple chips > continuously syncing with each other. And they only have to process maybe 2mbit/s of control traffic during busy hour. The rest is handled by dedicated hardware/ASIC's. Each one has a fully redundant hardware circuit pack and a bunch of monitoring to switch over in case one fails. Even then, it's fun when some one screws up and reboots it :) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From swmike at swm.pp.se Mon Nov 12 07:29:59 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 12 Nov 2012 08:29:59 +0100 (CET) Subject: Whats so difficult about ISSU In-Reply-To: <50A099CC.4050106@bryanfields.net> References: <001001cdc08c$0c4fc040$24ef40c0$@iname.com> <50A099CC.4050106@bryanfields.net> Message-ID: On Mon, 12 Nov 2012, Bryan Fields wrote: > And they only have to process maybe 2mbit/s of control traffic during > busy hour. The rest is handled by dedicated hardware/ASIC's. Each one > has a fully redundant hardware circuit pack and a bunch of monitoring to > switch over in case one fails. I'd imagine it's also because some are written in a language especially designed for the task. http://en.wikipedia.org/wiki/Erlang_(programming_language) "... It supports hot swapping, so that code can be changed without stopping a system.[2]" I've been told some people are doing routing control plane implementations in erlang just because of these features, but I'd imagine there is a hurdle getting enough programmers who are experienced in the language. -- Mikael Abrahamsson email: swmike at swm.pp.se From jcdill.lists at gmail.com Mon Nov 12 14:19:53 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 12 Nov 2012 06:19:53 -0800 Subject: Cisco IT class on groupon!? Message-ID: <50A10589.3060900@gmail.com> http://www.groupon.com/deals/g1mm-it-university-online-san-jose-ca "$99 for a Complete Cisco Network Training Bundle ($3,295 Value) The Complete Cisco Network Training Bundle includes five training courses designed to provide the skills needed for the CCNA and CCNP suite of certifications. Each bundle includes instructor-led training, hands-on exercises, multimedia presentations, and exam simulators." From dreamwaverfx at yahoo.com Fri Nov 9 00:19:37 2012 From: dreamwaverfx at yahoo.com (Alex) Date: Fri, 09 Nov 2012 02:19:37 +0200 Subject: Whats so difficult about ISSU In-Reply-To: References: <813B894D-A090-4C8C-AE11-491FF0E5DCFC@zaidali.com> Message-ID: <509C4C19.5030304@yahoo.com> http://www.juniper.net/techpubs/en_US/junos/topics/concept/issu-oveview.html The Juniper ISSU guide. You need two things: 1. Separation of the control plane and forwarding plane 2. 2 routing engines in the same chassis -- the non active RE upgrades first, then when its up and running the active one goes into upgrade mode and control fails over to the secondary RE which is running the upgraded version of the software. I assume it works on any vendor that has 2 REs in the same chassis and the fwd and control planes are separated, and there is a redundancy protocol running between the two REs(like Graceful Switchover on Juniper gear). On 11/09/2012 01:42 AM, Kenneth McRae wrote: > Juniper also offers it on the EX virtual switching platform. Works if you > have the correct version of JunOS. > > On Thu, Nov 8, 2012 at 3:38 PM, Zaid Ali wrote: > >> Cisco Nexus platform does it pretty well so they have achieved it. >> >> Zaid >> >> On Nov 8, 2012, at 3:22 PM, Kasper Adel wrote: >> >>> Hello, >>> >>> We've been hearing about ISSU for so many years and i didnt hear that any >>> vendor was able to achieve it yet. >>> >>> What is the technical reason behind that? >>> >>> If i understand correctly, the way it will be done would be simply to >> have >>> extra ASICs/HW to be able to build dual circuits accessing the same >> memory, >>> and gracefully switch from one to another. Is that right? >>> >>> Thanks, >>> Kim >> >> From wbailey at satelliteintelligencegroup.com Sat Nov 10 19:54:15 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 10 Nov 2012 19:54:15 +0000 Subject: ARIN lead time Message-ID: <8200F04ED2C5EF40B246388AD4B822A5123A2429@CH1PRD0510MB367.namprd05.prod.outlook.com> Does anyone know the lead time for ARIN to issue OrgID and subsequently an AS? From jackson.tim at gmail.com Mon Nov 12 15:36:16 2012 From: jackson.tim at gmail.com (Tim Jackson) Date: Mon, 12 Nov 2012 09:36:16 -0600 Subject: Whats so difficult about ISSU In-Reply-To: References: <001001cdc08c$0c4fc040$24ef40c0$@iname.com> Message-ID: I would argue no. The Class 5 softswitches that are around now are off-the-shelf cPCI or ACTA hardware running Linux or some other *nix. The TDM -> IP cards are the only sticky point there to be upgraded, but since everything is a mid-plane, you can do rolling N:1 upgrades across the cards with minimal (sub 400msec) impact. There's not a ton special secret sauce there.. To the other point, they probably process way more than 2mbps/s of control traffic during busy hour, especially in geo-redundant configurations as lots of things have to be synchronized. I think you're talking more on the order of 50-120mbps.. Yet all of this works pretty damn well. -- Tim On Mon, Nov 12, 2012 at 12:21 AM, Kasper Adel wrote: > Hi Frank, > > Is it because C5 softswitches have expensive hardware, advanced software > and dual asics? I would have never imagined that any vendor is capable of > upgrading fpd's/ASICs ucode without a hit unless there are multiple chips > continuously syncing with each other. > > Regards, > Kim > > On Monday, November 12, 2012, Frank Bulk wrote: > > > We do it on our Class 5 softswitch ... and it works consistently. There > > may > > be a few seconds, once, where a new call can't be made, but most people > > will > > re-dial. It just works. > > > > It can be done, but the product has to be built with that in mind. > > > > Frank > > > > -----Original Message----- > > From: Kasper Adel [mailto:karim.adel at gmail.com ] > > Sent: Thursday, November 08, 2012 5:23 PM > > To: NANOG list > > Subject: Whats so difficult about ISSU > > > > Hello, > > > > We've been hearing about ISSU for so many years and i didnt hear that any > > vendor was able to achieve it yet. > > > > What is the technical reason behind that? > > > > If i understand correctly, the way it will be done would be simply to > have > > extra ASICs/HW to be able to build dual circuits accessing the same > memory, > > and gracefully switch from one to another. Is that right? > > > > Thanks, > > Kim > > > > > > > From betty at newnog.org Mon Nov 12 16:44:45 2012 From: betty at newnog.org (Betty Burke ) Date: Mon, 12 Nov 2012 11:44:45 -0500 Subject: GeoIP information page In-Reply-To: <509DF633.3060009@cisco.com> References: <509DF633.3060009@cisco.com> Message-ID: Hello Shishio, the nanog.cluepon.net environment was in fact moved. We will check to see if the data is still available and work to link it to the GeoIP presentation on nanog.org/nanog53 All best. Betty Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 On Sat, Nov 10, 2012 at 1:37 AM, Shishio Tsuchiya wrote: > Hi > As NANOG53 presentation described,most of information of GeoIP was written > in this page. > http://nanog.cluepon.net/index.php/GeoIP > http://www.nanog.org/meetings/nanog53/presentations/Wednesday/Barnes.pdf > > But the service is not currently available. > Was it moved to another? or Has someone backup? > > Regards, > -Shishio > > > -- From shtsuchi at cisco.com Mon Nov 12 17:02:34 2012 From: shtsuchi at cisco.com (Shishio Tsuchiya) Date: Tue, 13 Nov 2012 02:02:34 +0900 Subject: GeoIP information page In-Reply-To: References: <509DF633.3060009@cisco.com> Message-ID: <50A12BAA.8080902@cisco.com> Betty Thanks. I believe this information is really useful for trouble shooting of GeoIP. It is great job. I would like to copy to our local wiki for redundancy , and I will try to add Japan local GeoIP provider information to the wiki for Japan internet users and ISP. Regards, -Shishio (2012/11/13 1:44), Betty Burke wrote: > Hello Shishio, the nanog.cluepon.net environment was in fact moved. We will check to see if the data is still available and work to link it to the GeoIP presentation on nanog.org/nanog53 > > All best. > Betty > > Betty Burke > NANOG Executive Director > 48377 Fremont Boulevard, Suite 117 > Fremont, CA 94538 > Tel: +1 510 492 4030 > > > On Sat, Nov 10, 2012 at 1:37 AM, Shishio Tsuchiya > wrote: > > Hi > As NANOG53 presentation described,most of information of GeoIP was written in this page. > http://nanog.cluepon.net/index.php/GeoIP > http://www.nanog.org/meetings/nanog53/presentations/Wednesday/Barnes.pdf > > But the service is not currently available. > Was it moved to another? or Has someone backup? > > Regards, > -Shishio > > > > > > -- > > > From eugen at leitl.org Mon Nov 12 17:04:17 2012 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 12 Nov 2012 18:04:17 +0100 Subject: NASA DTN Protocol: Interplanetary Internet, How It Works, What LEGOS Have to To With It Message-ID: <20121112170417.GD9750@leitl.org> http://anewdomain.net/2012/11/10/nasa-dtn-protocol-bp-protocol-vint-cerf-interplanetary-internet-how-it-works-what-legos-have-to-to-with-it/# NASA DTN Protocol: Interplanetary Internet, How It Works, What LEGOS Have to To With It Author: Gina Smith NASA is calling it the interplanetary Internet, and announcements have been hitting in recent weeks regarding the sending of the first emails, voicemails and, of late, news of an experiment that involved remote controlling of a LEGO space robot with it. But what?s truly cool is the technology enabling it ? it?s a protocol called Delay-Tolerant Networking, better known as DTN. At its heart is Vint Cerf?s Bundle Protocol (BP), a version of the IP protocol he helped develop to pioneer the Internet decades ago. In testing for several years, DTN got a major boost recently, says Badri Younes, a NASA administrator in Washington. Astronaut Sunita Williams ? she commanded the International Space Station?s current Expedition 33 mission ? used NASA?s experimental Disruption Tolerant Networking (DTN) protocol to drive a small LEGO robot at the European Space Operations Center in Germany late last month. That was big news for the DTN and BP protocols, developed jointly by Internet pioneer +Vint Cerf and NASA?s Jet Propulsion Laboratory. In a nutshell ? we?ll get down and dirty with the tech lower in the piece ? DTN allows a standard method of communication over long distances and through time delays, agency officials said. Its centering tech is similar to the IP protocol (that is the TCP/IP protocol) that is the building block of the Internet we use on Earth. That?s called the Bundle Protocol (BP). The big difference between BP and IP is that, while IP assumes a more or less smooth pathway for packets going from start to end point, BP allows for disconnections, glitches and other problems you see commonly in deep space, Younes said. Basically, a BP network ? the one that will the Interplanetary Internet possible ? moves data packets in bursts from node to node, so that it can check when the next node is available or up. ?The demonstration (of the DTN controlled robot) showed the feasibility of using a new communications infrastructure to send commands to a surface robot from an orbiting spacecraft and receive images and data back from the robot,? Younes said. ?The experimental DTN we?ve tested from the space station may one day be used by humans on a spacecraft in orbit around Mars to operate robots on the surface, or from Earth using orbiting satellites as relay stations,? Younes added. Credit: European Space Agency The first thing to understand is that the DTN testbed with BP driving it is in active testing now, NASA says. Its first successful test was in 2008, when NASA announced that early DTN software for the first time enabled the transmission of more than a dozen of space images to and from a NASA science spacecraft located about 20 million miles (32M KM) from Earth. In a statement then, NASA?s Jet Propulsion Laboratory and Google?s +Vint Cerf said it kicked off the Interplanetary Internet. But what is DTN? ?The experimental DTN we?ve tested from the space station may one day be used by humans on a spacecraft in orbit around Mars to operate robots on the surface, or from Earth using orbiting satellites as relay stations,? Younes added. Source: NASA In a nutshell, says NASA, ?The Disruption Tolerant Networking (DTN) program establishes a long-term, readily accessible communications test-bed onboard the International Space Station (ISS). Two Commercial Generic Bioprocessing Apparatus (CGBA), CGBA-5 and CGBA-4, will serve as communications test computers that transmit messages between ISS and ground Mission Control Centers. All data will be monitored and controlled at the BioServe remote Payload Operations Control Center (POCC) located on the Engineering Center premises at the University of Colorado ? Boulder,? reps said today. According to NASA?s Delay-Tolerant Networking Research Group (DTNRG), ?the DTN protocol is under active development.? An experiment using DTN to control the LEGO robot is in the news today, but NASA says there are real world, military and consumer applications that affect Internet users worldwide. ?In addition to network security, research goals for the DTN activity will focus on testing and evolving important network services including naming and addressing, time synchronization, routing, network management and class of service,? NASA reps add, saying that ?the DTN experiments on the International Space Station (ISS) consist of software which is to be placed on both Commercial Generic Bioprocessing Apparatus (CGBA), CGBA-4 and CGBA-5, and then tested from a ground operations center. What?s going on? Researchers explain ?the DTN activity will focus on testing and evolving important network services including naming and addressing, time synchronization, routing, network management and class of service. The DTN experiments on ISS consist of software (that) is to be placed on both Commercial Generic Bioprocessing Apparatus, CGBA-4 and CGBA-5, and then tested from a ground operations center. This software is not in any critical path of the CGBA operations and may be turned off at anytime. This software does not preclude the use of the CGBA units for other purposes or research support. DTN, say NASA reps, is ?a networked architecture required to successfully complete these missions. The experiments that will be performed are designed to test the DTN protocol suite in an actual space environment, and to determine how well the protocols perform and what improvements may need to be made. The impact of the results of the research will help to advance the technical maturity of the DTN communications technology so that it is available for NASA use in both human and robotic Exploration missions. The Delay-Tolerant Networking Research Group (DTNRG) is a research group chartered as part of the Internet Research Task Force (IRTF). Members of DTNRG are concerned with how to address the architectural and protocol design principles arising from the need to provide interoperable communications with and among extreme and performance-challenged environments where continuous end-to-end connectivity cannot be assumed. Said another way, we are concerned with interconnecting highly heterogeneous networks together even if end-to-end connectivity may never be available. Examples of such environments include spacecraft, military/tactical, some forms of disaster response, underwater, and some forms of ad-hoc sensor/actuator networks. It may also include Internet connectivity in places where performance may suffer such as developing parts of the world. DTNRG members research aspects of delay-tolerant networking in a number of ways including academic publications, technical specifications, several active mailing lists, and code (reference implementation) development. DTNRG holds semi-regular teleconferences for software developers and occasional face-to-face public meetings. The public meetings usually occur in conjunction with an IETF meeting. The current co-chairs for DTNRG are Kevin Fall (Qualcomm), Stephen Farrell (Trinity College, Dublin) and J?rg Ott (Aalto University, Helsinki). Back in 2006 Stephen wrote a book on DTN. Several of the members of DTNRG participated in the (highly-related) DARPA Disruption Tolerant Networking program. DTN research is necessary in space especially, NASA says, for the maturation of protocols to enable Internet-like communications with space vehicles, remote planetary habitats, rover vehicles and support infrastructure on a planetary surface. ?It is being tested for the first time on ISS Onboard (local) ISS , ISS-to-ground, and NASA ground communications networks will become DTN-enabled,? NASA says. ?That is the key stepping stone to enabling the Interplanetary Internet. From josmon at rigozsaurus.com Mon Nov 12 18:03:19 2012 From: josmon at rigozsaurus.com (John Osmon) Date: Mon, 12 Nov 2012 11:03:19 -0700 Subject: ARIN lead time In-Reply-To: <8200F04ED2C5EF40B246388AD4B822A5123A2429@CH1PRD0510MB367.namprd05.prod.outlook.com> References: <8200F04ED2C5EF40B246388AD4B822A5123A2429@CH1PRD0510MB367.namprd05.prod.outlook.com> Message-ID: <20121112180319.GA14282@jeeves.rigozsaurus.com> On Sat, Nov 10, 2012 at 07:54:15PM +0000, Warren Bailey wrote: > Does anyone know the lead time for ARIN to issue OrgID and subsequently an AS? Generally a day or so after getting them the proper information. From frnkblk at iname.com Mon Nov 12 22:24:09 2012 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 12 Nov 2012 16:24:09 -0600 Subject: Whats so difficult about ISSU In-Reply-To: References: <001001cdc08c$0c4fc040$24ef40c0$@iname.com> Message-ID: <000501cdc124$6fa06b20$4ee14160$@iname.com> Compared to our CMTS, our class 5 softswitch cost us less money. Yet our CMTS vendor stopped talking about hitless software upgrades 2 years ago because the upgrade path (from, to, and which software releases you can use) is so limited it's hardly practical. Frank From: Kasper Adel [mailto:karim.adel at gmail.com] Sent: Monday, November 12, 2012 12:22 AM To: Frank Bulk Cc: NANOG list Subject: Re: Whats so difficult about ISSU Hi Frank, Is it because C5 softswitches have expensive hardware, advanced software and dual asics? I would have never imagined that any vendor is capable of upgrading fpd's/ASICs ucode without a hit unless there are multiple chips continuously syncing with each other. Regards, Kim On Monday, November 12, 2012, Frank Bulk wrote: We do it on our Class 5 softswitch ... and it works consistently. There may be a few seconds, once, where a new call can't be made, but most people will re-dial. It just works. It can be done, but the product has to be built with that in mind. Frank -----Original Message----- From: Kasper Adel [mailto:karim.adel at gmail.com ] Sent: Thursday, November 08, 2012 5:23 PM To: NANOG list Subject: Whats so difficult about ISSU Hello, We've been hearing about ISSU for so many years and i didnt hear that any vendor was able to achieve it yet. What is the technical reason behind that? If i understand correctly, the way it will be done would be simply to have extra ASICs/HW to be able to build dual circuits accessing the same memory, and gracefully switch from one to another. Is that right? Thanks, Kim From frnkblk at iname.com Mon Nov 12 22:24:09 2012 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 12 Nov 2012 16:24:09 -0600 Subject: Whats so difficult about ISSU In-Reply-To: References: <001001cdc08c$0c4fc040$24ef40c0$@iname.com> Message-ID: <000a01cdc124$6fd3b020$4f7b1060$@iname.com> Our softswitch vendor talks about control plane bandwidths for geo-redundant configurations on the low end of your numbers. I'd have to drag out the slide deck to see exactly what they recommended. My point is that carrier-class products have demonstrated it's possible. Frank From: Tim Jackson [mailto:jackson.tim at gmail.com] Sent: Monday, November 12, 2012 9:36 AM To: Kasper Adel Cc: Frank Bulk; NANOG list Subject: Re: Whats so difficult about ISSU I would argue no. The Class 5 softswitches that are around now are off-the-shelf cPCI or ACTA hardware running Linux or some other *nix. The TDM -> IP cards are the only sticky point there to be upgraded, but since everything is a mid-plane, you can do rolling N:1 upgrades across the cards with minimal (sub 400msec) impact. There's not a ton special secret sauce there.. To the other point, they probably process way more than 2mbps/s of control traffic during busy hour, especially in geo-redundant configurations as lots of things have to be synchronized. I think you're talking more on the order of 50-120mbps.. Yet all of this works pretty damn well. -- Tim On Mon, Nov 12, 2012 at 12:21 AM, Kasper Adel wrote: Hi Frank, Is it because C5 softswitches have expensive hardware, advanced software and dual asics? I would have never imagined that any vendor is capable of upgrading fpd's/ASICs ucode without a hit unless there are multiple chips continuously syncing with each other. Regards, Kim On Monday, November 12, 2012, Frank Bulk wrote: > We do it on our Class 5 softswitch ... and it works consistently. There > may > be a few seconds, once, where a new call can't be made, but most people > will > re-dial. It just works. > > It can be done, but the product has to be built with that in mind. > > Frank > > -----Original Message----- > From: Kasper Adel [mailto:karim.adel at gmail.com ] > Sent: Thursday, November 08, 2012 5:23 PM > To: NANOG list > Subject: Whats so difficult about ISSU > > Hello, > > We've been hearing about ISSU for so many years and i didnt hear that any > vendor was able to achieve it yet. > > What is the technical reason behind that? > > If i understand correctly, the way it will be done would be simply to have > extra ASICs/HW to be able to build dual circuits accessing the same memory, > and gracefully switch from one to another. Is that right? > > Thanks, > Kim > > > From scott at sberkman.net Mon Nov 12 23:22:39 2012 From: scott at sberkman.net (Scott Berkman) Date: Mon, 12 Nov 2012 18:22:39 -0500 Subject: Verizon wireless (cdma/LTE) compatible ethernet connectable OOB access device. In-Reply-To: References: Message-ID: <010701cdc12c$9c275e80$d4761b80$@sberkman.net> We have one site using this type of OpeGear setup, but we use an LTE "MiFi" with wireless to the OpenGear's "WAN", but also use a USB port on the open gear to keep the MiFi powered. -----Original Message----- From: Asaf Rapoport [mailto:arapoport at telepacific.com] Sent: Wednesday, November 07, 2012 6:10 PM To: David Hubbard; nanog at nanog.org Subject: Re: Verizon wireless (cdma/LTE) compatible ethernet connectable OOB access device. OpenGear does make good, low footprint, low power consumption console servers. I think they have an IPSec stack too. Note: They make another type with just a modem (I don't know why they don't make one with both 3G and dialup?), in case the cell coverage is so spotty that you won't get what you really need. Just my 2 cents. On 11/7/12 3:02 PM, "David Hubbard" wrote: >OpenGear's stuff is awesome. > >http://opengear.com/product-acm5000-g.html > >We have the 5004G on Verizon, it has four serial ports, ethernet and >USB running linux. We have a 5 gig plan from Verizon and static IP for >$50/month minus our corporate discount. Since it's put on a 'machine' >plan with them, you can get plans all the way down to I think $5/month >with a few megabytes of included data; they treat it the same way you'd >treat a cell backup for an alarm and similar devices. > >You can have the OpenGear unit keep the data portion of the cellular >side always live, or for added security and lower risk of data >consumption by drive by scans, you can have it turn the data off and on >by sending it text messages to the associated phone number. > >You can ssh directly to serial ports by using different port numbers >than standard, ssh in and then utilize the ports, there's a web-based >serial interface too so they're really great for routers. On the >ethernet/web side you can do things like vpn gateway, proxying, port >mapping, etc like you'd find in a typical consumer type soho router, or >you can lock it all down for whatever you don't need. > >My only complaint is no LTE version last I checked, which is fine for >serial ports but an LTE would make it a lot nicer since then you could >do more interactive things like remote desktop, heavy web traffic and >other things that you might also want in a bind. > >David > >> -----Original Message----- >> From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] >> Sent: Wednesday, November 07, 2012 5:47 PM >> To: 'nanog at nanog.org' >> Subject: Verizon wireless (cdma/LTE) compatible ethernet connectable >> OOB access device. >> >> We have Verizon Wireless as our provider of choice for our company, >> and I've convinced those who are they that I need a completely OOB >> method for getting back in the NOC, as we don't have a full time NOC >> staff and internet coverage can be spotty around here in general, as >> we're a small town. >> >> The people who need the OOB management access are getting 4G Myfi >> devices with static IP addresses. What I need at our NOC is a 3 or 4G >> (our area only has 3G atm) Verizon compatible device with an wired >> ethernet link. I'm looking at several but wondered if anyone has any >> familiarity with such units. I just need a basic wwan-ethernet >> modem/bridge, I will be handling vpn termination, firewalling, access >> control, and such with my existing firewall. >> >> Off-list is fine. >> >> __________________________ >> Eric Esslinger >> Information Services Manager - Fayetteville Public Utilities >> http://www.fpu-tn.com/ >> (931)433-1522 ext 165 >> >> This message may contain confidential and/or proprietary information >> and is intended for the person/entity to whom it was originally >> addressed. Any use by others is strictly prohibited. >> >> >> > > From joe at nethead.com Tue Nov 13 00:41:27 2012 From: joe at nethead.com (Joe Hamelin) Date: Mon, 12 Nov 2012 16:41:27 -0800 Subject: Verizon wireless (cdma/LTE) compatible ethernet connectable OOB access device. In-Reply-To: <010701cdc12c$9c275e80$d4761b80$@sberkman.net> References: <010701cdc12c$9c275e80$d4761b80$@sberkman.net> Message-ID: I've used digi.com before, does the job. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From jim at reptiles.org Mon Nov 12 19:43:46 2012 From: jim at reptiles.org (Jim Mercer) Date: Mon, 12 Nov 2012 14:43:46 -0500 Subject: "authority" to route? Message-ID: <20121112194346.GE28511@reptiles.org> Hi, Is there a common practice of providers to vet / validate requests to advertise blocks? Who is the "authority" when it comes to determining if a request for routing is valid? Is it the WHOIS data maintained by the various RIR? It seems I'm playing whack-a-mole to get some routes shut down for some blocks I've taken over admin for. If I email the contacts for the AS in WHOIS, and get no response, or a negative response, should I start going to their peers? Some practical advice would be appreciated. -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From mysidia at gmail.com Tue Nov 13 06:31:05 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 13 Nov 2012 00:31:05 -0600 Subject: "authority" to route? In-Reply-To: <20121112194346.GE28511@reptiles.org> References: <20121112194346.GE28511@reptiles.org> Message-ID: On 11/12/12, Jim Mercer wrote: > Hi, > Is there a common practice of providers to vet / validate requests to > advertise > blocks? There is a common practice of providers to require an initial Letter of authorization from the org listed in WHOIS when first setting up, and manual request to allow the prefix or entry of the route in an internet routing registry, for end users to originate prefixes. > Who is the "authority" when it comes to determining if a request for > routing > is valid? Defined by routing policy of the provider considering the request, and their upstreams. > Is it the WHOIS data maintained by the various RIR? WHOIS data is often used for that purpose; the basic information about the organization listed as registrant of the block is considered authoritative, in general. > It seems I'm playing whack-a-mole to get some routes shut down for some > blocks I've taken over admin for. It would probably help to submit to them in writing, that the org responsible for the block never authorized the space to be announced by the provider originating it, inform that their unauthorized announcement is causing network issues and costing money, and request that they suppress it. If that's not the case, e.g. if at any time there was bonafide authorization, then the dispute is something to be discussed with the downstream org. still routing the block. If their peers question them about it, they might have the prior LOA on file to show the peers; it is not as if such things expire, or can necessarily be easily withdrawn, it depends on the agreement that allowed the advertisement to be authorized, in that case. Listing of an e-mail address in WHOIS as an admin contact, does not necessarily imply authority that a provider is entitled to rely upon, to tell a peer to shutdown the network. > If I email the contacts for the AS in WHOIS, and get no response, or a > negative response, should I start going to their peers? It's an option. Their peers may summarily ignore the request to disrupt the network by "shutting down" a customer's announcements, though, on the word of an email, if it's not very obvious that they are bad announcements. You may need to email and call, and possibly fax and mail. > Some practical advice would be appreciated. > -- > Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 -- -JH From h.wahl at ifw-dresden.de Tue Nov 13 11:28:53 2012 From: h.wahl at ifw-dresden.de (Henri Wahl) Date: Tue, 13 Nov 2012 12:28:53 +0100 Subject: dhcpy6d - a MAC address aware DHCPv6 server In-Reply-To: References: <5097757E.5070307@ifw-dresden.de> <50991A8D.9090208@ifw-dresden.de> Message-ID: <50A22EF5.6040908@ifw-dresden.de> Hi Owen, > |ioctl(sock, SIOCGIFADDR, &ifr)| > > Shouldn't that do the trick? I don't know if Python can do that or not, but if it can't, that's pretty weak. > > As far as I was able to find out this only gives back the local MAC address which is of no use here. To be independent of external call I at least for Linux managed to access neighbor cache via netlink socket as the "ip" command itself does. Thus no external call is necessary anymore. Regards Henri -- Henri Wahl IT Department Leibniz-Institut f?r Festk?rper- u. Werkstoffforschung Dresden tel. (03 51) 46 59 - 797 email: h.wahl at ifw-dresden.de http://www.ifw-dresden.de http://nagstamon.ifw-dresden.de http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstra?e 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4719 bytes Desc: S/MIME Kryptografische Unterschrift URL: From rodrick.brown at gmail.com Tue Nov 13 18:39:49 2012 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Tue, 13 Nov 2012 13:39:49 -0500 Subject: High CPU utilization w/VRF NAT - Cat6500 Message-ID: ~80 or so static NAT's configured, multiple versions of IOS tested. Most of the traffic is being punted to the CPU through the NAT interfaces causing high CPU utilization. Increasing fast aging timers had 0 benefit, TCAM utilization is less than 5% Does anyone have any thoughts on other configuration tweaks I should try? I think we're at the point where new hardware maybe FWSM or another platform for NAT should be explored. --RB From kenneth.mcrae at dreamhost.com Tue Nov 13 18:44:55 2012 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Tue, 13 Nov 2012 10:44:55 -0800 Subject: High CPU utilization w/VRF NAT - Cat6500 In-Reply-To: References: Message-ID: I would recommend you do this on a firewall (fwsm or something external).. On Tue, Nov 13, 2012 at 10:39 AM, Rodrick Brown wrote: > ~80 or so static NAT's configured, multiple versions of IOS tested. > Most of the traffic is being punted to the CPU through the NAT interfaces > causing high CPU utilization. > > Increasing fast aging timers had 0 benefit, TCAM utilization is less than > 5% > Does anyone have any thoughts on other configuration tweaks I should try? I > think we're at the point where new hardware maybe FWSM or another platform > for NAT should be explored. > > --RB > -- Best Regards, Kenneth McRae *Sr. Network Engineer* kenneth.mcrae at dreamhost.com Ph: 323-375-3814 www.dreamhost.com From reza at lethalnetworks.com Tue Nov 13 17:25:59 2012 From: reza at lethalnetworks.com (reza) Date: Tue, 13 Nov 2012 09:25:59 -0800 (PST) Subject: Cisco IT class on groupon!? In-Reply-To: <50A10589.3060900@gmail.com> References: <50A10589.3060900@gmail.com> Message-ID: <1117731019.5366.1352827559287.JavaMail.root@lethalnetworks.com> Has anyone taken classes from IT U before, this seems like a good deal but I'd like to get someone's feedback if the classes are actually decent. ----- Original Message ----- From: "JC Dill" To: "NANOG list" Sent: Monday, November 12, 2012 6:19:53 AM Subject: Cisco IT class on groupon!? http://www.groupon.com/deals/g1mm-it-university-online-san-jose-ca "$99 for a Complete Cisco Network Training Bundle ($3,295 Value) The Complete Cisco Network Training Bundle includes five training courses designed to provide the skills needed for the CCNA and CCNP suite of certifications. Each bundle includes instructor-led training, hands-on exercises, multimedia presentations, and exam simulators." From sean-list at head-net.com Tue Nov 13 19:27:12 2012 From: sean-list at head-net.com (Sean Head) Date: Tue, 13 Nov 2012 11:27:12 -0800 Subject: Cisco IT class on groupon!? In-Reply-To: <1117731019.5366.1352827559287.JavaMail.root@lethalnetworks.com> References: <50A10589.3060900@gmail.com> <1117731019.5366.1352827559287.JavaMail.root@lethalnetworks.com> Message-ID: <50A29F10.1010003@head-net.com> On 2012.11.13 09:25:59, reza wrote: > Has anyone taken classes from IT U before, this seems like a good deal but I'd like to get someone's feedback if the classes are actually decent. > > ----- Original Message ----- > From: "JC Dill" > To: "NANOG list" > Sent: Monday, November 12, 2012 6:19:53 AM > Subject: Cisco IT class on groupon!? > > http://www.groupon.com/deals/g1mm-it-university-online-san-jose-ca > > "$99 for a Complete Cisco Network Training Bundle ($3,295 Value) > > The Complete Cisco Network Training Bundle includes five training > courses designed to provide the skills needed for the CCNA and CCNP > suite of certifications. Each bundle includes instructor-led training, > hands-on exercises, multimedia presentations, and exam simulators." > I had the same question but couldn't really find any good information about them. Their name is also hard to google which doesn't help. From rayw at rayw.net Tue Nov 13 19:51:56 2012 From: rayw at rayw.net (Ray Wong) Date: Tue, 13 Nov 2012 11:51:56 -0800 Subject: Cisco IT class on groupon!? In-Reply-To: <50A29F10.1010003@head-net.com> References: <50A10589.3060900@gmail.com> <1117731019.5366.1352827559287.JavaMail.root@lethalnetworks.com> <50A29F10.1010003@head-net.com> Message-ID: >From their description, it's an examcram, not an education. If you already know what you're doing and just want to fill in enough detail gaps to quickly get your cert, you'll likely get what you were looking for. Personally, I can't remember the last time someone brought up certs for a network req in more than passing, so I wouldn't expect it to offer much of a longer term educational value. -R> On Tue, Nov 13, 2012 at 11:27 AM, Sean Head wrote: > On 2012.11.13 09:25:59, reza wrote: >> Has anyone taken classes from IT U before, this seems like a good deal but I'd like to get someone's feedback if the classes are actually decent. >> >> ----- Original Message ----- >> From: "JC Dill" >> To: "NANOG list" >> Sent: Monday, November 12, 2012 6:19:53 AM >> Subject: Cisco IT class on groupon!? >> >> http://www.groupon.com/deals/g1mm-it-university-online-san-jose-ca >> >> "$99 for a Complete Cisco Network Training Bundle ($3,295 Value) >> >> The Complete Cisco Network Training Bundle includes five training >> courses designed to provide the skills needed for the CCNA and CCNP >> suite of certifications. Each bundle includes instructor-led training, >> hands-on exercises, multimedia presentations, and exam simulators." >> > > > I had the same question but couldn't really find any good information > about them. Their name is also hard to google which doesn't help. > > From sethm at rollernet.us Tue Nov 13 19:59:18 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 13 Nov 2012 11:59:18 -0800 Subject: Eaton 9130 UPS feedback Message-ID: <50A2A696.7070403@rollernet.us> Does anyone use Eaton 9130 series UPS for anything? I'm curious how they've worked out for you. I bought a 700VA model to give it a whirl versus the traditional APC since the Eaton is an online type with static bypass and also does some high efficiency thing where it normally stays on bypass, but the first thing it did on the bench was have the inverter/rectifier or bypass section catch on fire and destroy itself. ~Seth From berry at gadsdenst.org Tue Nov 13 20:02:12 2012 From: berry at gadsdenst.org (Berry Mobley) Date: Tue, 13 Nov 2012 15:02:12 -0500 Subject: Eaton 9130 UPS feedback In-Reply-To: <50A2A696.7070403@rollernet.us> References: <50A2A696.7070403@rollernet.us> Message-ID: At 02:59 PM 11/13/2012, Seth Mattinen wrote: >Does anyone use Eaton 9130 series UPS for anything? I'm curious how >they've worked out for you. > >I bought a 700VA model to give it a whirl versus the traditional APC >since the Eaton is an online type with static bypass and also does some >high efficiency thing where it normally stays on bypass, but the first >thing it did on the bench was have the inverter/rectifier or bypass >section catch on fire and destroy itself. My basic rule is that if the first one I buy catches fire, I don't buy any more. Berry From mikea at mikea.ath.cx Tue Nov 13 20:27:19 2012 From: mikea at mikea.ath.cx (Mike A) Date: Tue, 13 Nov 2012 14:27:19 -0600 Subject: Eaton 9130 UPS feedback In-Reply-To: <50A2A696.7070403@rollernet.us> References: <50A2A696.7070403@rollernet.us> Message-ID: <20121113202718.GA43910@mikea.ath.cx> On Tue, Nov 13, 2012 at 11:59:18AM -0800, Seth Mattinen wrote: > Does anyone use Eaton 9130 series UPS for anything? I'm curious how > they've worked out for you. > > I bought a 700VA model to give it a whirl versus the traditional APC > since the Eaton is an online type with static bypass and also does some > high efficiency thing where it normally stays on bypass, but the first > thing it did on the bench was have the inverter/rectifier or bypass > section catch on fire and destroy itself. Was this the 2U rackmount form factor, or the tower? Either way, I hope that you will pursue this with APC tech support. That's a pricey piece of gear, and it shouldn't toast itself at any time. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From harbor235 at gmail.com Tue Nov 13 20:43:40 2012 From: harbor235 at gmail.com (harbor235) Date: Tue, 13 Nov 2012 15:43:40 -0500 Subject: High CPU utilization w/VRF NAT - Cat6500 In-Reply-To: References: Message-ID: What Supervisior do you have? If its an older SUP NAT may be done in software, which sounds like you are currently experiencing. Its not hard to max out a 6500 CPU. -Mike On Tue, Nov 13, 2012 at 1:44 PM, Kenneth McRae wrote: > I would recommend you do this on a firewall (fwsm or something external).. > > On Tue, Nov 13, 2012 at 10:39 AM, Rodrick Brown >wrote: > > > ~80 or so static NAT's configured, multiple versions of IOS tested. > > Most of the traffic is being punted to the CPU through the NAT interfaces > > causing high CPU utilization. > > > > Increasing fast aging timers had 0 benefit, TCAM utilization is less than > > 5% > > Does anyone have any thoughts on other configuration tweaks I should > try? I > > think we're at the point where new hardware maybe FWSM or another > platform > > for NAT should be explored. > > > > --RB > > > > > > -- > Best Regards, > > > > Kenneth McRae > *Sr. Network Engineer* > kenneth.mcrae at dreamhost.com > Ph: 323-375-3814 > www.dreamhost.com > From ikiris at gmail.com Tue Nov 13 21:20:35 2012 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 13 Nov 2012 15:20:35 -0600 Subject: Eaton 9130 UPS feedback In-Reply-To: <20121113202718.GA43910@mikea.ath.cx> References: <50A2A696.7070403@rollernet.us> <20121113202718.GA43910@mikea.ath.cx> Message-ID: As a side note, how do you call a UPS "online" if it stays on bypass most of the time, and throws out of "bypass" to go to battery? On Tue, Nov 13, 2012 at 2:27 PM, Mike A wrote: > On Tue, Nov 13, 2012 at 11:59:18AM -0800, Seth Mattinen wrote: > > Does anyone use Eaton 9130 series UPS for anything? I'm curious how > > they've worked out for you. > > > > I bought a 700VA model to give it a whirl versus the traditional APC > > since the Eaton is an online type with static bypass and also does some > > high efficiency thing where it normally stays on bypass, but the first > > thing it did on the bench was have the inverter/rectifier or bypass > > section catch on fire and destroy itself. > > Was this the 2U rackmount form factor, or the tower? > > Either way, I hope that you will pursue this with APC tech support. That's > a pricey piece of gear, and it shouldn't toast itself at any time. > > -- > Mike Andrews, W5EGO > mikea at mikea.ath.cx > Tired old sysadmin > > From bonomi at mail.r-bonomi.com Tue Nov 13 21:52:19 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 13 Nov 2012 15:52:19 -0600 (CST) Subject: Eaton 9130 UPS feedback In-Reply-To: Message-ID: <201211132152.qADLqJwK082221@mail.r-bonomi.com> > From: Blake Dunlap > Date: Tue, 13 Nov 2012 15:20:35 -0600 >_ > On Tue, Nov 13, 2012 at 2:27 PM, Mike A wrote: > > > On Tue, Nov 13, 2012 at 11:59:18AM -0800, Seth Mattinen wrote: > > > Does anyone use Eaton 9130 series UPS for anything? I'm curious how > > > they've worked out for you. > > > > > > I bought a 700VA model to give it a whirl versus the traditional APC > > > since the Eaton is an online type with static bypass and also does some > > > high efficiency thing where it normally stays on bypass, but the first > > > thing it did on the bench was have the inverter/rectifier or bypass > > > section catch on fire and destroy itself. > > > > Was this the 2U rackmount form factor, or the tower? > > > > Either way, I hope that you will pursue this with APC tech support. That's > > a pricey piece of gear, and it shouldn't toast itself at any time. > > > > As a side note, how do you call a UPS "online" if it stays on bypass most > of the time, and throws out of "bypass" to go to battery? Reading the specs, it _is_ 'true online' normally, has a bypass mode if internal failure detected, or manually commanded. UPS totally disabled in bypass -- if utility power fails while on bypass, downstream devices lose power. In bypass, device provides 'passive' filtering of utility power ONLY. > From daniel at pch.net Tue Nov 13 21:54:39 2012 From: daniel at pch.net (Daniel Griggs) Date: Wed, 14 Nov 2012 10:54:39 +1300 Subject: Eaton 9130 UPS feedback In-Reply-To: <50A2A696.7070403@rollernet.us> References: <50A2A696.7070403@rollernet.us> Message-ID: Hi Seth, A previous employer we looked at a few UPS. We used Emerson GXT2/3 3Kva UPSs and they worked a treat. We also tried the Eaton 9130 and we never had any problems with them, but the SNMP monitoring was only good for telling you if there was a problem, not what the problem was. So we eventually went back to the Emersons. On 14/11/2012, at 8:59 AM, Seth Mattinen wrote: > Does anyone use Eaton 9130 series UPS for anything? I'm curious how > they've worked out for you. > > I bought a 700VA model to give it a whirl versus the traditional APC > since the Eaton is an online type with static bypass and also does some > high efficiency thing where it normally stays on bypass, but the first > thing it did on the bench was have the inverter/rectifier or bypass > section catch on fire and destroy itself. > > ~Seth > -- Daniel From george.herbert at gmail.com Tue Nov 13 22:00:35 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 13 Nov 2012 14:00:35 -0800 Subject: Eaton 9130 UPS feedback In-Reply-To: <201211132152.qADLqJwK082221@mail.r-bonomi.com> References: <201211132152.qADLqJwK082221@mail.r-bonomi.com> Message-ID: On Tue, Nov 13, 2012 at 1:52 PM, Robert Bonomi wrote: > >> From: Blake Dunlap >> Date: Tue, 13 Nov 2012 15:20:35 -0600 >>_ >> On Tue, Nov 13, 2012 at 2:27 PM, Mike A wrote: >> >> > On Tue, Nov 13, 2012 at 11:59:18AM -0800, Seth Mattinen wrote: >> > > Does anyone use Eaton 9130 series UPS for anything? I'm curious how >> > > they've worked out for you. >> > > >> > > I bought a 700VA model to give it a whirl versus the traditional APC >> > > since the Eaton is an online type with static bypass and also does some >> > > high efficiency thing where it normally stays on bypass, but the first >> > > thing it did on the bench was have the inverter/rectifier or bypass >> > > section catch on fire and destroy itself. >> > >> > Was this the 2U rackmount form factor, or the tower? >> > >> > Either way, I hope that you will pursue this with APC tech support. That's >> > a pricey piece of gear, and it shouldn't toast itself at any time. >> > >> >> As a side note, how do you call a UPS "online" if it stays on bypass most >> of the time, and throws out of "bypass" to go to battery? > > Reading the specs, it _is_ 'true online' normally, has a bypass mode if > internal failure detected, or manually commanded. UPS totally disabled > in bypass -- if utility power fails while on bypass, downstream devices > lose power. In bypass, device provides 'passive' filtering of utility > power ONLY. Reading the users manual... pp 33, "Setting Power Strategy", it indicates that normal operation is true online (as above) and that you can change it to "high efficiency" mode, which is not online per se (default bypass, 10 ms cutover if it detects a fail or spike). So it has 3 modes; default/normal (online), high efficiency (bypass w/cutback), and partially failed (bypass only, UPS functions disabled). -- -george william herbert george.herbert at gmail.com From sethm at rollernet.us Tue Nov 13 22:12:19 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 13 Nov 2012 14:12:19 -0800 Subject: Eaton 9130 UPS feedback In-Reply-To: References: <50A2A696.7070403@rollernet.us> <20121113202718.GA43910@mikea.ath.cx> Message-ID: <50A2C5C3.3010207@rollernet.us> On 11/13/12 1:20 PM, Blake Dunlap wrote: > As a side note, how do you call a UPS "online" if it stays on bypass most > of the time, and throws out of "bypass" to go to battery? > It's a selectable feature. I was probably going to set it to true online mode, but play with the other mode for curiosity's sake. ~Seth From choprboy at dakotacom.net Tue Nov 13 22:16:10 2012 From: choprboy at dakotacom.net (Adrian) Date: Tue, 13 Nov 2012 15:16:10 -0700 Subject: Eaton 9130 UPS feedback In-Reply-To: <50A2A696.7070403@rollernet.us> References: <50A2A696.7070403@rollernet.us> Message-ID: <201211131516.10733.choprboy@dakotacom.net> On Tuesday 13 November 2012 12:59, Seth Mattinen wrote: > Does anyone use Eaton 9130 series UPS for anything? I'm curious how > they've worked out for you. > > I bought a 700VA model to give it a whirl versus the traditional APC > since the Eaton is an online type with static bypass and also does some > high efficiency thing where it normally stays on bypass, but the first > thing it did on the bench was have the inverter/rectifier or bypass > section catch on fire and destroy itself. > > ~Seth We have several 5130 and 9125 models (2kVA rackmount), never given us a problem in years of service... Well, one network management card that lost its mind, reset the configuration and went on with life, but the UPS just chugged along. Biggest plus has been that they don't cook their batteries like APCs do. Adrian From blueneon at gmail.com Tue Nov 13 23:42:45 2012 From: blueneon at gmail.com (Tom Morris) Date: Tue, 13 Nov 2012 18:42:45 -0500 Subject: Eaton 9130 UPS feedback In-Reply-To: <201211131516.10733.choprboy@dakotacom.net> References: <50A2A696.7070403@rollernet.us> <201211131516.10733.choprboy@dakotacom.net> Message-ID: Sorry to say, I've used them and had them eat themselves. They just die mysteriously and let out lots of smoke when they do. When they do, however, they leave behind a perfectly good set of batteries. I'd recommend looking elsewhere... Does Eaton/PowerWare still make the FerrUPS series? Those were *solid*. On Tue, Nov 13, 2012 at 5:16 PM, Adrian wrote: > On Tuesday 13 November 2012 12:59, Seth Mattinen wrote: >> Does anyone use Eaton 9130 series UPS for anything? I'm curious how >> they've worked out for you. >> >> I bought a 700VA model to give it a whirl versus the traditional APC >> since the Eaton is an online type with static bypass and also does some >> high efficiency thing where it normally stays on bypass, but the first >> thing it did on the bench was have the inverter/rectifier or bypass >> section catch on fire and destroy itself. >> >> ~Seth > > > We have several 5130 and 9125 models (2kVA rackmount), never given us a > problem in years of service... Well, one network management card that lost > its mind, reset the configuration and went on with life, but the UPS just > chugged along. Biggest plus has been that they don't cook their batteries > like APCs do. > > > Adrian > > -- -- Tom Morris, KG4CYX Mad Scientist For Hire Chairman, South Florida Tropical Hamboree / Miami Hamfest Engineer, WRGP Radiate FM, Florida International University 786-228-7087 151.820 Megacycles From tvhawaii at shaka.com Wed Nov 14 00:04:50 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 13 Nov 2012 14:04:50 -1000 Subject: Eaton 9130 UPS feedback References: <50A2A696.7070403@rollernet.us> <201211131516.10733.choprboy@dakotacom.net> Message-ID: Adrian wrote: > We have several 5130 and 9125 models (2kVA rackmount), never given us a > problem in years of service... Well, one network management card that lost > its mind, reset the configuration and went on with life, but the UPS just > chugged along. Biggest plus has been that they don't cook their batteries > like APCs do. > > > Adrian Now *that's* good to know...thanks! From dreamwaverfx at yahoo.com Wed Nov 14 01:37:42 2012 From: dreamwaverfx at yahoo.com (Alex) Date: Wed, 14 Nov 2012 03:37:42 +0200 Subject: Eaton 9130 UPS feedback In-Reply-To: References: <50A2A696.7070403@rollernet.us> <201211131516.10733.choprboy@dakotacom.net> Message-ID: <50A2F5E6.2030409@yahoo.com> We have quite alot of Eaton UPS's in our network, all sorts of models. There have been no problems from what I've seen, except when you add water from a broken pipe or bad roof. We've had the once in a blue moon management card reset as Adrian said but it didn't interrupt our equipment. On 11/14/2012 2:04 AM, Michael Painter wrote: > Adrian wrote: >> We have several 5130 and 9125 models (2kVA rackmount), never given us a >> problem in years of service... Well, one network management card that >> lost >> its mind, reset the configuration and went on with life, but the UPS >> just >> chugged along. Biggest plus has been that they don't cook their >> batteries >> like APCs do. >> >> >> Adrian > > Now *that's* good to know...thanks! > From tvhawaii at shaka.com Wed Nov 14 02:28:25 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 13 Nov 2012 16:28:25 -1000 Subject: Eaton 9130 UPS feedback References: <50A2A696.7070403@rollernet.us> <201211131516.10733.choprboy@dakotacom.net> <50A2F5E6.2030409@yahoo.com> Message-ID: <3DA784F616114878B39CB6A83F96792F@owner59e1f1502> Alex wrote: > We have quite alot of Eaton UPS's in our network, all sorts of models. > There have been no problems from what I've seen, except when you add > water from a broken pipe or bad roof. > > We've had the once in a blue moon management card reset as Adrian said > but it didn't interrupt our equipment. Thanks! I've been very disappointed with APC. I had a customer spend thousands on replacement batteries/freight for a Matrix 5000 only to have a $5 cooling fan crap out and no way to get a replacement. From jeff-kell at utc.edu Wed Nov 14 02:49:16 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 13 Nov 2012 21:49:16 -0500 Subject: Eaton 9130 UPS feedback In-Reply-To: References: <50A2A696.7070403@rollernet.us> <201211131516.10733.choprboy@dakotacom.net> Message-ID: <50A306AC.4060506@utc.edu> On 11/13/2012 6:42 PM, Tom Morris wrote: > Sorry to say, I've used them and had them eat themselves. They just > die mysteriously and let out lots of smoke when they do. When they do, > however, they leave behind a perfectly good set of batteries. I'd > recommend looking elsewhere... Does Eaton/PowerWare still make the > FerrUPS series? Those were *solid*. Interesting. So far the feedback sounds overwhelmingly negative. Heard some good points on Emerson (I'm assuming Liebert?). We've had much better luck overall with them, although a couple of incidents where they don't care to come back online after they were drained. We largely use the UPS to survive power glitches without dropping the network for switch reboot times, we're not after long runs. As such, the occasional extended outages drain the UPS'es and there are always the percentage of them that do not come back online and require manual intervention. We were formerly a big TrippLite user, but they seem to be incredibly fault-intolerant with regard to the scenario above (coming back online after draining), and to a lesser degree, going offline after a power glitch. Never used an Eaton that I'm aware of however. Would be interested in other recommendations for remote / IDF / MDF environment UPS systems to just "keep the stack up" over power glitches. Jeff From jackson.tim at gmail.com Wed Nov 14 02:59:16 2012 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 13 Nov 2012 20:59:16 -0600 Subject: Eaton 9130 UPS feedback In-Reply-To: <50A306AC.4060506@utc.edu> References: <50A2A696.7070403@rollernet.us> <201211131516.10733.choprboy@dakotacom.net> <50A306AC.4060506@utc.edu> Message-ID: Just go -48vdc. None of these pesky UPS problems :) Unfortunately there's a serious lack of PoE switches that are -48. On Nov 13, 2012 8:51 PM, "Jeff Kell" wrote: > On 11/13/2012 6:42 PM, Tom Morris wrote: > > Sorry to say, I've used them and had them eat themselves. They just > > die mysteriously and let out lots of smoke when they do. When they do, > > however, they leave behind a perfectly good set of batteries. I'd > > recommend looking elsewhere... Does Eaton/PowerWare still make the > > FerrUPS series? Those were *solid*. > > Interesting. So far the feedback sounds overwhelmingly negative. Heard > some good points on Emerson (I'm assuming Liebert?). We've had much > better luck overall with them, although a couple of incidents where they > don't care to come back online after they were drained. > > We largely use the UPS to survive power glitches without dropping the > network for switch reboot times, we're not after long runs. As such, > the occasional extended outages drain the UPS'es and there are always > the percentage of them that do not come back online and require manual > intervention. > > We were formerly a big TrippLite user, but they seem to be incredibly > fault-intolerant with regard to the scenario above (coming back online > after draining), and to a lesser degree, going offline after a power > glitch. > > Never used an Eaton that I'm aware of however. > > Would be interested in other recommendations for remote / IDF / MDF > environment UPS systems to just "keep the stack up" over power glitches. > > Jeff > > > From sethm at rollernet.us Wed Nov 14 03:12:51 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 13 Nov 2012 19:12:51 -0800 Subject: Eaton 9130 UPS feedback In-Reply-To: <50A306AC.4060506@utc.edu> References: <50A2A696.7070403@rollernet.us> <201211131516.10733.choprboy@dakotacom.net> <50A306AC.4060506@utc.edu> Message-ID: <50A30C33.5000905@rollernet.us> On 11/13/12 6:49 PM, Jeff Kell wrote: > On 11/13/2012 6:42 PM, Tom Morris wrote: >> Sorry to say, I've used them and had them eat themselves. They just >> die mysteriously and let out lots of smoke when they do. When they do, >> however, they leave behind a perfectly good set of batteries. I'd >> recommend looking elsewhere... Does Eaton/PowerWare still make the >> FerrUPS series? Those were *solid*. > > Interesting. So far the feedback sounds overwhelmingly negative. Heard > some good points on Emerson (I'm assuming Liebert?). We've had much > better luck overall with them, although a couple of incidents where they > don't care to come back online after they were drained. > > We largely use the UPS to survive power glitches without dropping the > network for switch reboot times, we're not after long runs. As such, > the occasional extended outages drain the UPS'es and there are always > the percentage of them that do not come back online and require manual > intervention. > > We were formerly a big TrippLite user, but they seem to be incredibly > fault-intolerant with regard to the scenario above (coming back online > after draining), and to a lesser degree, going offline after a power glitch. > > Never used an Eaton that I'm aware of however. > > Would be interested in other recommendations for remote / IDF / MDF > environment UPS systems to just "keep the stack up" over power glitches. > I do have much larger Eaton units like the 9355 that haven't given me anything to complain about yet. But they're of a wholly different classes and I don't really expect one to represent the other. The 9130 that exploded was my first foray into their smaller side, destined to be a telco room aux unit and replace an APC SmartUPS. ~Seth From alex at corp.nac.net Wed Nov 14 03:57:56 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 13 Nov 2012 22:57:56 -0500 Subject: Eaton 9130 UPS feedback In-Reply-To: References: <50A2A696.7070403@rollernet.us> <201211131516.10733.choprboy@dakotacom.net> <50A306AC.4060506@utc.edu> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81AE477C0B8@EXCHMBX.hq.nac.net> > Just go -48vdc. None of these pesky UPS problems :) Well, you still have 1/2 the UPS - the inverter section. It's not a silver bullet. From Ben.Butler at c2internet.net Wed Nov 14 13:10:57 2012 From: Ben.Butler at c2internet.net (Ben S. Butler) Date: Wed, 14 Nov 2012 13:10:57 +0000 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> Message-ID: <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> Hi, I am hoping for a bit of advice. We are rolling out IPv6 en mass now to peers and I am finding that our "strict" IPv6 ingress prefix filter is meaning a lot of peers are sending me zero prefixes. Upon investigation I determine they have de-agregrated their /32 for routing reasons / non interconnected islands of address space and in consequence advertise no covering /32 route. The RIR block that the allocation is from is meant to have a minimum assignment of /32. From: http://www.space.net/~gert/RIPE/ipv6-filters.html We get: ipv6 prefix-list ipv6-ebgp-strict deny 3ffe::/16 le 128 ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48 ipv6 prefix-list ipv6-ebgp-strict deny 2001:db8::/32 le 128 ipv6 prefix-list ipv6-ebgp-strict permit 2001::/32 ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 35 le 35 ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2001:0678::/29 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2001:0c00::/23 ge 48 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2001:13c7:6000::/36 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2001:13c7:7000::/36 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2001:43f8::/29 ge 40 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2002::/16 ipv6 prefix-list ipv6-ebgp-strict permit 2003::/16 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2600::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2610::/23 ge 24 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2620::/23 ge 40 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2800::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2a00::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2801:0000::/24 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2c00::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict deny 0::/0 le 128 I have peers in 2a00::/12 that are advertising me /48s without the /32 assigned to them. While this has been a problem in IPv4 land in the past with some people de-aggregating a /19 to regional /24s with no covering route because of no backbone. What should we be doing in IPv6 land as I suspect this may become a bigger problem than it ever was in IPv4. I can adopt the view, well you should, so I'm going to filter, and they can say well that's not practical, we have a /32 and we advertise a /48 at each individual internet exchange. RIRs policy wont allocate us a lot of separate /48s from an appropriate block. Aggregation argues you shouldn't de-aggregate. We might as well start off as we mean to go along and try not to pollute the v6 route table with all the rubbish that is in the v4 one. So what is the "best" answer. 1> Don't advertise islands of space under assignment minimum, without providing a covering aggregate route? 2> Don't use strict filters, they don't work well and de-agragegation with IPv6 is going to be a problem? 3> Don't use filters, generate it from an IRR? Given there is no "right" answer what is considered to be the best fit one? Kind Regards Ben From ops.lists at gmail.com Wed Nov 14 13:24:35 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 14 Nov 2012 18:54:35 +0530 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> Message-ID: On Wed, Nov 14, 2012 at 6:40 PM, Ben S. Butler wrote: > > 3> Don't use filters, generate it from an IRR? > > Given there is no "right" answer what is considered to be the best fit one? This sounds like your best bet. Assuming you can find an IRR with comprehensive enough coverage. The other option is of course "don't filter based solely on RIR minimum assignments" .. I know at least some ISPs (like swisscom) do this for v4 too, but that simply means people who try to multihome with anything less than a /19 in level3 land aren't going to succeed. http://v-authoring.ip-plus.net/documents/BIS_TI_Router_Filter_Policy_EN.pdf ip prefix-list martians seq 8000 permit 8.0.0.0/7 le 19 [etc] Not so much of a problem in v4 but as you saw for yourself, you risk not seeing prefixes at all if you try this. -- Suresh Ramasubramanian (ops.lists at gmail.com) From Erik.Amundson at oati.net Wed Nov 14 13:38:57 2012 From: Erik.Amundson at oati.net (Erik Amundson) Date: Wed, 14 Nov 2012 07:38:57 -0600 Subject: Eaton 9130 UPS feedback In-Reply-To: <50A2A696.7070403@rollernet.us> References: <50A2A696.7070403@rollernet.us> Message-ID: <635D17EE85D35A49B8F278998E6C340464FAE828ED@EXVS.dev.oati.local> I've had issues and experience with many types of UPSes, including HP (probably OEM'd from someone else), APC, EATON/Powerware, and Liebert/Emerson. I keep coming back to APC. Solid units, and are always slightly 'ahead' in technology. Sure, I've seen each model have failures and even faults (big boom style), but APC provides a solid product and supports their customers the best if you ask me. That being said, a very close second choice would be EATON/Powerware. - Erik -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Tuesday, November 13, 2012 1:59 PM To: nanog at nanog.org Subject: Eaton 9130 UPS feedback Does anyone use Eaton 9130 series UPS for anything? I'm curious how they've worked out for you. I bought a 700VA model to give it a whirl versus the traditional APC since the Eaton is an online type with static bypass and also does some high efficiency thing where it normally stays on bypass, but the first thing it did on the bench was have the inverter/rectifier or bypass section catch on fire and destroy itself. ~Seth From Ben.Butler at c2internet.net Wed Nov 14 13:40:12 2012 From: Ben.Butler at c2internet.net (Ben S. Butler) Date: Wed, 14 Nov 2012 13:40:12 +0000 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2F0@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2F0@EXCHANGE.atlasbiz.com> Message-ID: <416A23FC91E34449999D047BF540B46901689658E2F1@EXCHANGE.atlasbiz.com> Hi, Yes, but a multi-homing customer would have PI space from an appropriately filtered block allowing /24 PI v4 or /48 PI v6. An ISP would have their own RIR PA allocation /22 to /19 v4 or /29, /32 v6 block that are from blocks that follow along the lines of minimum assignment size for that block. This is not a problem created by the registries or by the filters. The problem comes with ASes that don?t have a backbone interconnecting all of their POPs / islands and are therefore unable to add a covering route and do not provide a route via any transit provide for the whole ip block at the RIR minimum boundary. In some ways whether people should: 1> Have a network of none interconnected islands that take IP space from the same IP block below RIR minimum? 2> Should we filter these networks? 3> Should the /32 be visible in the route table somewhere if the intention that component /48s are going to be visible on the Internet. I don?t like the IRR answer particularly as it requires a level of third party trust that I am not entirely comfortable with, nor configuring separate filters for each BGP peering session. Ben From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: 14 November 2012 13:25 To: Ben S. Butler Cc: NANOG Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On Wed, Nov 14, 2012 at 6:40 PM, Ben S. Butler > wrote: 3> Don't use filters, generate it from an IRR? Given there is no "right" answer what is considered to be the best fit one? This sounds like your best bet. Assuming you can find an IRR with comprehensive enough coverage. The other option is of course "don't filter based solely on RIR minimum assignments" .. I know at least some ISPs (like swisscom) do this for v4 too, but that simply means people who try to multihome with anything less than a /19 in level3 land aren't going to succeed. http://v-authoring.ip-plus.net/documents/BIS_TI_Router_Filter_Policy_EN.pdf ip prefix-list martians seq 8000 permit 8.0.0.0/7 le 19 [etc] Not so much of a problem in v4 but as you saw for yourself, you risk not seeing prefixes at all if you try this. -- Suresh Ramasubramanian (ops.lists at gmail.com) From os10rules at gmail.com Wed Nov 14 14:15:24 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Wed, 14 Nov 2012 09:15:24 -0500 Subject: Eaton 9130 UPS feedback In-Reply-To: <635D17EE85D35A49B8F278998E6C340464FAE828ED@EXVS.dev.oati.local> References: <50A2A696.7070403@rollernet.us> <635D17EE85D35A49B8F278998E6C340464FAE828ED@EXVS.dev.oati.local> Message-ID: Are these UPS units going inside the racks? Would it not be better to do something in the power room with an inverter on the circuits that feed the racks, such as a large Outback unit with sufficient battery capacity? http://www.amazon.com/OutBack-Inverter-3600-Watts-Volt/dp/B002MWAAYU With one device acting as your UPS you'd have only one point of failure (that may be a plus or minus), only one set of batteries to worry about, and those inverters are very well made. They have 120v and 240v units. There are other brands you could use but my experience with various brands is that Outback is the best in their class. Greg On Wed, Nov 14, 2012 at 8:38 AM, Erik Amundson wrote: > I've had issues and experience with many types of UPSes, including HP > (probably OEM'd from someone else), APC, EATON/Powerware, and > Liebert/Emerson. I keep coming back to APC. Solid units, and are always > slightly 'ahead' in technology. Sure, I've seen each model have failures > and even faults (big boom style), but APC provides a solid product and > supports their customers the best if you ask me. That being said, a very > close second choice would be EATON/Powerware. > > - Erik > > > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Tuesday, November 13, 2012 1:59 PM > To: nanog at nanog.org > Subject: Eaton 9130 UPS feedback > > Does anyone use Eaton 9130 series UPS for anything? I'm curious how > they've worked out for you. > > I bought a 700VA model to give it a whirl versus the traditional APC > since the Eaton is an online type with static bypass and also does some > high efficiency thing where it normally stays on bypass, but the first > thing it did on the bench was have the inverter/rectifier or bypass > section catch on fire and destroy itself. > > ~Seth > > > From bill at herrin.us Wed Nov 14 15:02:03 2012 From: bill at herrin.us (William Herrin) Date: Wed, 14 Nov 2012 10:02:03 -0500 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> Message-ID: On Wed, Nov 14, 2012 at 8:10 AM, Ben S. Butler wrote: > So what is the "best" answer. > > > 1> Don't advertise islands of space under assignment minimum, without providing a covering aggregate route? > > 2> Don't use strict filters, they don't work well and de-agragegation with IPv6 is going to be a problem? > > 3> Don't use filters, generate it from an IRR? > > Given there is no "right" answer what is considered to be the best fit one? IMHO: 4) Use mild filters (e.g. allow a /32 to be disaggregated to /36's) and send a polite email to the POC to the effect of, "Please beware that because you have not offered a covering route matching your allocation, your IPv6 network is not reachable from ours. IPv6 is not IPv4: end users requiring /48s for multihoming should get them directly from the RIR. For complete Internet connectivity, we strongly encourage you to offer a covering route." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From geier at geier.ne.tz Wed Nov 14 16:56:25 2012 From: geier at geier.ne.tz (Frank Habicht) Date: Wed, 14 Nov 2012 19:56:25 +0300 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> Message-ID: <50A3CD39.4020509@geier.ne.tz> On 11/14/2012 6:02 PM, William Herrin wrote: > and send a polite email to the POC to the effect of, "Please beware > that because you have not offered a covering route matching your > allocation, your IPv6 network is not reachable from ours. IPv6 is not > IPv4: end users requiring /48s for multihoming should get them > directly from the RIR. For complete Internet connectivity, we strongly > encourage you to offer a covering route." like that. Frank From Ben.Butler at c2internet.net Wed Nov 14 17:08:03 2012 From: Ben.Butler at c2internet.net (Ben S. Butler) Date: Wed, 14 Nov 2012 17:08:03 +0000 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <50A3CD39.4020509@geier.ne.tz> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> Message-ID: <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> Hi, Yes, nice. But... It does not address the case when this is not the ISPs customers but the ISP (read content provider) that operates globally but without a network interconnecting their routers. They then advertise a /24 v4 and /48 v6 at each Internet exchange that they are connected to. That is "fine" for driving router. The "problem" with this design is that they cant announce their /32 as they are not running a iBGP mesh. I have seen a number of content providers doing this by design, and in the context of their business I can understand why and see it makes some sense. The only problem comes with the prefixes ending up under the minimum prefix size for the block they are in. Now when this is a large content provider and we all want the peering, then we relax the filters, fine, but why one rule for them and another for everyone else in the same /12 block. Would it not make sense for the RIRs to assign a /12 as issuable in /32, /29 to content providers who will specifically deagregate to /48 with no internal network. That solves the filtering problem, doesn't force these networks to put an iBGP network in place and lets everyone who does run a network "properly" to announce the proper aggregate blocks / covering routes with more specifics if we have to have them for routing purposes. A separate /12 for the "island" type networks would immediately make this problem disappear. Am I being overly simplistic? Ben -----Original Message----- From: Frank Habicht [mailto:geier at geier.ne.tz] Sent: 14 November 2012 16:56 To: nanog at nanog.org Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On 11/14/2012 6:02 PM, William Herrin wrote: > and send a polite email to the POC to the effect of, "Please beware > that because you have not offered a covering route matching your > allocation, your IPv6 network is not reachable from ours. IPv6 is not > IPv4: end users requiring /48s for multihoming should get them > directly from the RIR. For complete Internet connectivity, we strongly > encourage you to offer a covering route." like that. Frank From geier at geier.ne.tz Wed Nov 14 17:28:47 2012 From: geier at geier.ne.tz (Frank Habicht) Date: Wed, 14 Nov 2012 20:28:47 +0300 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> Message-ID: <50A3D4CF.3080504@geier.ne.tz> On 11/14/2012 8:08 PM, Ben S. Butler wrote: > Hi, > > Yes, nice. But... It does not address the case when this is not the ISPs customers but the ISP (read content provider) that operates globally but without a network interconnecting their routers. They then advertise a /24 v4 and /48 v6 at each Internet exchange that they are connected to. That is "fine" for driving router. The "problem" with this design is that they cant announce their /32 as they are not running a iBGP mesh. I have seen a number of content providers doing this by design, and in the context of their business I can understand why and see it makes some sense. The only problem comes with the prefixes ending up under the minimum prefix size for the block they are in. Yep. Ack. For the filtering policies it'd be nice to use space from a special prefix - like for PI assignments. But that will drive "global" routing table size :-( But that's what content providers who create islands are bound to do - or is there a way around without real connectivity or tunnels? And the "polluters" apparently don't have enough incentives or pain to void islands... Frank > Now when this is a large content provider and we all want the peering, then we relax the filters, fine, but why one rule for them and another for everyone else in the same /12 block. Would it not make sense for the RIRs to assign a /12 as issuable in /32, /29 to content providers who will specifically deagregate to /48 with no internal network. > > That solves the filtering problem, doesn't force these networks to put an iBGP network in place and lets everyone who does run a network "properly" to announce the proper aggregate blocks / covering routes with more specifics if we have to have them for routing purposes. > > A separate /12 for the "island" type networks would immediately make this problem disappear. > > Am I being overly simplistic? > > Ben > > -----Original Message----- > From: Frank Habicht [mailto:geier at geier.ne.tz] > Sent: 14 November 2012 16:56 > To: nanog at nanog.org > Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. > > On 11/14/2012 6:02 PM, William Herrin wrote: > >> and send a polite email to the POC to the effect of, "Please beware >> that because you have not offered a covering route matching your >> allocation, your IPv6 network is not reachable from ours. IPv6 is not >> IPv4: end users requiring /48s for multihoming should get them >> directly from the RIR. For complete Internet connectivity, we strongly >> encourage you to offer a covering route." > > like that. > Frank > > > > From rps at maine.edu Wed Nov 14 17:46:42 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 14 Nov 2012 12:46:42 -0500 Subject: DHCPv6 and MAC addresses Message-ID: Saw yet another attempt at a solution pop up to try and deal with the lack of a MAC address in DHCPv6 messages. I've been giving this some thought about how this should be best accomplished without requiring that host implementations of DHCPv6 be modified. Taking advantage of the relay-agent seems to be the most elegant solution: 1) Any DHCPv6 server on a local segment will already have access to the MAC address; but having a DHCPv6 server on each segment is not ideal. 2) Requests that are relayed flow through a relay-agent, which is on a device that also has access to the MAC address of the client system. Option A: RFC 6422 provides for Realy-Supplied DHCP Options, currently with one option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). You can see the list here: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml I think the quickest solution would be: 1) Adding an RSOO for the client MAC address 2) Get vendors on board to draft and adopt a standard for it on routers, 3) Modify DHCPv6 servers to have support for MAC identification based on the MAC of the local request OR the MAC of the relayed request when the option is present. Option B: The current RELAY-FORW message already includes the link-local address of the client. Perhaps there should be a modification to the privacy extensions RFC to forbid the use of privacy addressing on the link-local scope; at this point we could modify DHCPv6 servers to be able to determine the MAC address for relayed requests based on their link-local address. Unfortunately, the cat is out of the bag on this one, so it would take time to get host implementations modified. I might be overlooking something critical... thoughts? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From rps at maine.edu Wed Nov 14 17:47:28 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 14 Nov 2012 12:47:28 -0500 Subject: dhcpy6d - a MAC address aware DHCPv6 server In-Reply-To: <12EF9311-B9FF-4E86-BB0E-E178C357FA89@gmail.com> References: <5097757E.5070307@ifw-dresden.de> <20121106134929.GA17574@nic.fr> <12EF9311-B9FF-4E86-BB0E-E178C357FA89@gmail.com> Message-ID: FWIW ISC DHCPd listens on raw sockets. On Tue, Nov 6, 2012 at 11:12 AM, George Herbert wrote: > Oh, horrors, part of my infrastructure needs raw socket data? > > We should ban that, for security. Who needs those pesky switches anyways? > > > George William Herbert > Sent from my iPhone > > On Nov 6, 2012, at 5:49 AM, Stephane Bortzmeyer wrote: > >> On Tue, Nov 06, 2012 at 05:38:32AM -0800, >> Owen DeLong wrote >> a message of 68 lines which said: >> >>> If you're on local subnet, why not pull the MAC address out of the >>> received packet? >> >> Because it requires access to raw sockets, which should not be >> necessary for DHCP? >> >> > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From bicknell at ufp.org Wed Nov 14 17:59:18 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 14 Nov 2012 09:59:18 -0800 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> Message-ID: <20121114175918.GA76075@ussenterprise.ufp.org> In a message written on Wed, Nov 14, 2012 at 01:10:57PM +0000, Ben S. Butler wrote: > I am hoping for a bit of advice. We are rolling out IPv6 en mass now to peers and I am finding that our "strict" IPv6 ingress prefix filter is meaning a lot of peers are sending me zero prefixes. Upon investigation I determine they have de-agregrated their /32 for routing reasons / non interconnected islands of address space and in consequence advertise no covering /32 route. The RIR block that the allocation is from is meant to have a minimum assignment of /32. You are conflating two different issues, which are essentially toally unrelated. There is the smallest size block an RIR will allocate out of some chuck of address space, and then there is how people announce it on the Internet. In the real world they have almost nothing to do with each other, something folks understand today in IPv4 but seem to think IPv6 magically fixes, it doesn't. [Historically there were folks who maintained filters on IPv4 space, but they gradually disappeared as the filters became so long they were unmaintinable, and people discovered when your job is to connect people throwing away routes is a bad thing.] For instance, there are folks who could use the "multiple discrete networks" policy to get a /48 for each of their 5 sites. But instead they get on /32, use a /48 at each site, and announce them independantly. Same prefixes in the table, but filtering on the RIR /32 boundry means you won't hear them. I'll point out it's not just longer, but shorter prefixes as well: > ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48 F-Root announces 2001:4f8:500:2e::/47. You're going to miss it. There are other servers in this block that are in /47's or /46's. If connectivity is what you value, here's the right filter: ipv6 prefix-list ipv6-ebgp-permissive 2001::/12 ge 13 le 48 Yes, the DOD has a /13, and yes, people expect to be able to announce down to a /48. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From tjc at ecs.soton.ac.uk Wed Nov 14 18:02:35 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 14 Nov 2012 18:02:35 +0000 Subject: DHCPv6 and MAC addresses In-Reply-To: References: Message-ID: What about http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03 ? -- Tim On 14 Nov 2012, at 17:46, Ray Soucy wrote: > Saw yet another attempt at a solution pop up to try and deal with the > lack of a MAC address in DHCPv6 messages. > > I've been giving this some thought about how this should be best > accomplished without requiring that host implementations of DHCPv6 be > modified. > Taking advantage of the relay-agent seems to be the most elegant solution: > > 1) Any DHCPv6 server on a local segment will already have access to > the MAC address; but having a DHCPv6 server on each segment is not > ideal. > 2) Requests that are relayed flow through a relay-agent, which is on a > device that also has access to the MAC address of the client system. > > > > > Option A: > > RFC 6422 provides for Realy-Supplied DHCP Options, currently with one > option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). > You can see the list here: > > http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml > > I think the quickest solution would be: > > 1) Adding an RSOO for the client MAC address > 2) Get vendors on board to draft and adopt a standard for it on routers, > 3) Modify DHCPv6 servers to have support for MAC identification based > on the MAC of the local request OR the MAC of the relayed request when > the option is present. > > > > > Option B: > > The current RELAY-FORW message already includes the link-local address > of the client. Perhaps there should be a modification to the privacy > extensions RFC to forbid the use of privacy addressing on the > link-local scope; at this point we could modify DHCPv6 servers to be > able to determine the MAC address for relayed requests based on their > link-local address. > > Unfortunately, the cat is out of the bag on this one, so it would take > time to get host implementations modified. > > > > > I might be overlooking something critical... thoughts? > > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net > From bill at herrin.us Wed Nov 14 18:06:22 2012 From: bill at herrin.us (William Herrin) Date: Wed, 14 Nov 2012 13:06:22 -0500 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> Message-ID: On Wed, Nov 14, 2012 at 12:08 PM, Ben S. Butler wrote: > Yes, nice. But... It does not address the case when this is >not the ISPs customers but the ISP (read content provider) >that operates globally but without a network interconnecting >their routers. Hi Ben, That case is covered by things like ARIN's multiple discrete networks policy which permit an ISP /32 or end-user /48 for _each_ distinct network. There are plenty of addresses in IPv6. You should be break up a /32 for traffic engineering purposes, not for the sake of handling multiple disconnected sites. And when exercising TE, you can offer a covering route and expect the network as a whole to still function regardless of other folks' suballocation filtering. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rps at maine.edu Wed Nov 14 19:01:35 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 14 Nov 2012 14:01:35 -0500 Subject: DHCPv6 and MAC addresses In-Reply-To: References: Message-ID: Well I guess someone is already working on it, +1 Since this is a relay-only message, though. I think it would be better as a sub-option of RFC 6422 with a requirement that relay-agents drop the option if the client tries to source it. But, I guess it's splitting hairs. On Wed, Nov 14, 2012 at 1:02 PM, Tim Chown wrote: > What about > > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03 > > ? > > -- > Tim > > On 14 Nov 2012, at 17:46, Ray Soucy wrote: > > Saw yet another attempt at a solution pop up to try and deal with the > lack of a MAC address in DHCPv6 messages. > > I've been giving this some thought about how this should be best > accomplished without requiring that host implementations of DHCPv6 be > modified. > Taking advantage of the relay-agent seems to be the most elegant solution: > > 1) Any DHCPv6 server on a local segment will already have access to > the MAC address; but having a DHCPv6 server on each segment is not > ideal. > 2) Requests that are relayed flow through a relay-agent, which is on a > device that also has access to the MAC address of the client system. > > > > > Option A: > > RFC 6422 provides for Realy-Supplied DHCP Options, currently with one > option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). > You can see the list here: > > http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml > > I think the quickest solution would be: > > 1) Adding an RSOO for the client MAC address > 2) Get vendors on board to draft and adopt a standard for it on routers, > 3) Modify DHCPv6 servers to have support for MAC identification based > on the MAC of the local request OR the MAC of the relayed request when > the option is present. > > > > > Option B: > > The current RELAY-FORW message already includes the link-local address > of the client. Perhaps there should be a modification to the privacy > extensions RFC to forbid the use of privacy addressing on the > link-local scope; at this point we could modify DHCPv6 servers to be > able to determine the MAC address for relayed requests based on their > link-local address. > > Unfortunately, the cat is out of the bag on this one, so it would take > time to get host implementations modified. > > > > > I might be overlooking something critical... thoughts? > > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From rs at seastrom.com Wed Nov 14 19:57:06 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 14 Nov 2012 14:57:06 -0500 Subject: Ethernet NID plus POE+ (802.3at)... or POE+ injector with OAM... Message-ID: <868va4c60d.fsf@seastrom.com> Hi everyone, I'm looking for a gigabit ethernet media converter to go from SFP plugable optics to 802.3at POE+. The application involves wireless access points some distance from a central switch for a venue. Difficulty: in my old age, I've become allergic to installing completely unmanaged bump-in-the-wire devices that can't be monitored in some way. They make for a big nuisance when it comes time to debug the installation. The metro ethernet folks have brought us 802.1ag, 802.3ah, and Y.1731. Even the simplest of these - .1ag L2 ping (LBM/LBR) - is sufficient for my purposes of making sure that we're bidirectionally passing traffic. I'm aware of pluggable optics that do OAM (OEsolution Smart SFP) as well as some piggyback devices from other sources. I'd like to find a single box though that will do my media conversion, POE+ injection, and response to OAM packets all in one convenient tiny enclosure. Bonus points for well-thought-out details such as DIN rail mounting capability and cable retention tricks. Anyone got any pointers? -f From mksmith at mac.com Wed Nov 14 20:10:43 2012 From: mksmith at mac.com (Michael Smith) Date: Wed, 14 Nov 2012 12:10:43 -0800 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> Message-ID: <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> On Nov 14, 2012, at 10:06 AM, William Herrin wrote: > On Wed, Nov 14, 2012 at 12:08 PM, Ben S. Butler > wrote: >> Yes, nice. But... It does not address the case when this is >> not the ISPs customers but the ISP (read content provider) >> that operates globally but without a network interconnecting >> their routers. > > Hi Ben, > > That case is covered by things like ARIN's multiple discrete networks > policy which permit an ISP /32 or end-user /48 for _each_ distinct > network. There are plenty of addresses in IPv6. You should be break up > a /32 for traffic engineering purposes, not for the sake of handling > multiple disconnected sites. And when exercising TE, you can offer a > covering route and expect the network as a whole to still function > regardless of other folks' suballocation filtering. > > Regards, > Bill Herrin > I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast. So, how is it "worse" to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ. Mike From nanog at rsle.net Wed Nov 14 21:26:54 2012 From: nanog at rsle.net (R. Scott Evans) Date: Wed, 14 Nov 2012 16:26:54 -0500 Subject: Ethernet NID plus POE+ (802.3at)... or POE+ injector with OAM... In-Reply-To: <868va4c60d.fsf@seastrom.com> References: <868va4c60d.fsf@seastrom.com> Message-ID: On Wed, 14 Nov 2012 14:57:06 -0500, "Robert E. Seastrom" wrote: > Hi everyone, > > I'm looking for a gigabit ethernet media converter to go from SFP > plugable optics to 802.3at POE+. The application involves wireless > access points some distance from a central switch for a venue. > > Difficulty: in my old age, I've become allergic to installing > completely unmanaged bump-in-the-wire devices that can't be monitored > in some way. They make for a big nuisance when it comes time to debug > the installation. > > The metro ethernet folks have brought us 802.1ag, 802.3ah, and Y.1731. > Even the simplest of these - .1ag L2 ping (LBM/LBR) - is sufficient > for my purposes of making sure that we're bidirectionally passing > traffic. > > I'm aware of pluggable optics that do OAM (OEsolution Smart SFP) as > well as some piggyback devices from other sources. > > I'd like to find a single box though that will do my media conversion, > POE+ injection, and response to OAM packets all in one convenient tiny > enclosure. Bonus points for well-thought-out details such as DIN rail > mounting capability and cable retention tricks. > > Anyone got any pointers? > > -f You'll probably have better luck looking for a switch. http://www.transition.com/TransitionNetworks/Products2/Family.aspx?Name=SISPM1040-384-LRT -scott From bill at herrin.us Wed Nov 14 21:50:43 2012 From: bill at herrin.us (William Herrin) Date: Wed, 14 Nov 2012 16:50:43 -0500 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> Message-ID: On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith wrote: > I guess I'm confused. I have a /32 that I have broken up > into /47's for my discrete POP locations. I don't have a > network between them, by design. And, I won't > announce the /32 covering route because there is > no single POP that can take requests for the entire > /32 - think regionalized anycast. > > So, how is it "worse" to announce the deaggregated > /47's versus getting a /32 for every POP? In either > case, I'm going to put the same number of routes into the DFZ. Hi Michael, If you announce an ISP /32 from each POP (or an end-user /48, /47, etc) then I know that a neutral third party has vetted your proposed network configuration and confirmed that the routes are disaggregated because the network architecture requires it. If you announce a /47 from your ISP space, for all I know you're trying to tweak utilization on your ISP uplinks. In the former case, the protocols are capable of what they're capable of. Discrete multihomed network, discrete announcement. Like it or lump it. In the latter case, I don't particularly need to burn resources on my router half a world away to facilitate your traffic tweaking. Let the ISPs you're paying for the privilege carry your more-specifics. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jabley at hopcount.ca Wed Nov 14 22:40:56 2012 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 14 Nov 2012 17:40:56 -0500 Subject: "authority" to route? In-Reply-To: <20121112194346.GE28511@reptiles.org> References: <20121112194346.GE28511@reptiles.org> Message-ID: <727C5943-1BA0-470A-8BF7-05188C164E4F@hopcount.ca> On 2012-11-12, at 14:43, Jim Mercer wrote: > Is there a common practice of providers to vet / validate requests to advertise > blocks? Yes, most providers whose customers request a particular route to be pointed towards them will ask for ambiguous instructions, written on letterhead with crayon, and signed illegibly by someone who may or may not have authority to do so but who in any case cannot be identified clearly by their scrawl. Ideally the letterhead should be crudely constructed in photoshop and then faxed across a noisy analogue line. Once you have one of those babies in your file, no lawyer can touch you. Joe From joelja at bogus.com Wed Nov 14 23:27:15 2012 From: joelja at bogus.com (joel jaeggli) Date: Wed, 14 Nov 2012 15:27:15 -0800 Subject: "authority" to route? In-Reply-To: <727C5943-1BA0-470A-8BF7-05188C164E4F@hopcount.ca> References: <20121112194346.GE28511@reptiles.org> <727C5943-1BA0-470A-8BF7-05188C164E4F@hopcount.ca> Message-ID: <50A428D3.9090706@bogus.com> On 11/14/12 2:40 PM, Joe Abley wrote: > On 2012-11-12, at 14:43, Jim Mercer wrote: > >> Is there a common practice of providers to vet / validate requests to advertise >> blocks? > Yes, most providers whose customers request a particular route to be pointed towards them will ask for ambiguous instructions, written on letterhead with crayon, and signed illegibly by someone who may or may not have authority to do so but who in any case cannot be identified clearly by their scrawl. Some providers ask for route objects and appropriate import/export policy in RADB. that fandamently no higher quality an attestation than a LOA but it's a lot easier to read. > Ideally the letterhead should be crudely constructed in photoshop and then faxed across a noisy analogue line. > > Once you have one of those babies in your file, no lawyer can touch you. > > > Joe > > > From mksmith at mac.com Wed Nov 14 23:31:44 2012 From: mksmith at mac.com (Michael Smith) Date: Wed, 14 Nov 2012 15:31:44 -0800 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> Message-ID: <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com> On Nov 14, 2012, at 1:50 PM, William Herrin wrote: > On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith wrote: >> I guess I'm confused. I have a /32 that I have broken up >> into /47's for my discrete POP locations. I don't have a >> network between them, by design. And, I won't >> announce the /32 covering route because there is >> no single POP that can take requests for the entire >> /32 - think regionalized anycast. >> >> So, how is it "worse" to announce the deaggregated >> /47's versus getting a /32 for every POP? In either >> case, I'm going to put the same number of routes into the DFZ. > > Hi Michael, > > If you announce an ISP /32 from each POP (or an end-user /48, /47, > etc) then I know that a neutral third party has vetted your proposed > network configuration and confirmed that the routes are disaggregated > because the network architecture requires it. If you announce a /47 > from your ISP space, for all I know you're trying to tweak utilization > on your ISP uplinks. > Again, I thought the discussion was about PI, not PA. I don't announce any PA. > In the former case, the protocols are capable of what they're capable > of. Discrete multihomed network, discrete announcement. Like it or > lump it. > > In the latter case, I don't particularly need to burn resources on my > router half a world away to facilitate your traffic tweaking. Let the > ISPs you're paying for the privilege carry your more-specifics. > You have great confidence in the immutability of design and the description thereof. Mike From Ben.Butler at c2internet.net Thu Nov 15 00:05:08 2012 From: Ben.Butler at c2internet.net (Ben S. Butler) Date: Thu, 15 Nov 2012 00:05:08 +0000 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com> Message-ID: <416A23FC91E34449999D047BF540B46901689658E2FC@EXCHANGE.atlasbiz.com> Hi, " Again, I thought the discussion was about PI, not PA. I don't announce any PA." My point, which I feel may be getting lost, and for which ARIN may already have policies in place for, is that an IP assignment is made out of a block with a defined minimum assignment size. Now some people simply advertise the assignment that is made to them, some people chose to advertise more specifics with a covering route, I have no problem with any of this. What I am saying, is if people chose to deagregate to create islands, for which I can completely understand the commercial and networking reason and why it is then by extension impossible for them to advertise the covering route. Then in these specific cases of "islands" then these assignments should be made by the RIR from a block with a minimum prefix size of a /48. Then the application is submitted to the RIR it will justify as much space as it justifies, but at this point it should also be established - without any judgment positive or negative - if the intention is to advertise this unagregated or with a route for the aggregate. The RIR would then be empowered to assign the requested amount of address space from a block which can be labelled with a lower minimum prefix size. I am not judging any of these design practices. What I am pointing out is that the designs are being implemented in assignment blocks that do not reflect the recipients implementations intentions and this is neither helpful for them or other AS operators when it comes to filtering. If RIR policies establish this intention at the point of assignment then the "island" case will be catered for and we absolutely do not want to see an aggregate in the route table for assignments from that block. IF it is TE then it can be made from a conventional block with a cover router and more specifics. What I am seeing in the real world is island networks in address space with minimum /32 assigments. It is my choice if I filter your TE, it is a stupid choice if you don't advertise the cover route because you are doing TE. But what we need to facilitate are islands networks which for very sensible technical and commercial reasons are unable to advertise an aggregate. Policies may be in place to provide for this, however, what I am seeing in the route table is telling me that the policies are failing to identify people that want to implement their network in this fashion as they are coming from blocks with /32 min and they are advertising /48s. If these announcements came from and address block to which they were assigned with a minimum of a /48 because of their design intentions then everyone is happy and can announce and filer accordingly and end points are reachable. There is a reason that different blocks have different minimum sizes, I am advocating ensuring that we get assignments aligned with the blocks that are suit the intended implementation. It is not my place to judge your business, nor is it anyone elses to expect the rest of us to accept TE routes without a coverall and expect to be reachable. My 2c Ben -----Original Message----- From: Michael Smith [mailto:mksmith at mac.com] Sent: 14 November 2012 23:32 To: William Herrin Cc: nanog at nanog.org; Michael Smith Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On Nov 14, 2012, at 1:50 PM, William Herrin wrote: > On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith wrote: >> I guess I'm confused. I have a /32 that I have broken up into /47's >> for my discrete POP locations. I don't have a network between them, >> by design. And, I won't announce the /32 covering route because >> there is no single POP that can take requests for the entire >> /32 - think regionalized anycast. >> >> So, how is it "worse" to announce the deaggregated /47's versus >> getting a /32 for every POP? In either case, I'm going to put the >> same number of routes into the DFZ. > > Hi Michael, > > If you announce an ISP /32 from each POP (or an end-user /48, /47, > etc) then I know that a neutral third party has vetted your proposed > network configuration and confirmed that the routes are disaggregated > because the network architecture requires it. If you announce a /47 > from your ISP space, for all I know you're trying to tweak utilization > on your ISP uplinks. > Again, I thought the discussion was about PI, not PA. I don't announce any PA. > In the former case, the protocols are capable of what they're capable > of. Discrete multihomed network, discrete announcement. Like it or > lump it. > > In the latter case, I don't particularly need to burn resources on my > router half a world away to facilitate your traffic tweaking. Let the > ISPs you're paying for the privilege carry your more-specifics. > You have great confidence in the immutability of design and the description thereof. Mike From bill at herrin.us Thu Nov 15 00:19:04 2012 From: bill at herrin.us (William Herrin) Date: Wed, 14 Nov 2012 19:19:04 -0500 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com> Message-ID: On Wed, Nov 14, 2012 at 6:31 PM, Michael Smith wrote: > > On Nov 14, 2012, at 1:50 PM, William Herrin wrote: > >> On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith wrote: >>> I guess I'm confused. I have a /32 that I have broken up >>> into /47's for my discrete POP locations. I don't have a >>> network between them, by design. And, I won't >>> announce the /32 covering route because there is >>> no single POP that can take requests for the entire >>> /32 - think regionalized anycast. >>> >>> So, how is it "worse" to announce the deaggregated >>> /47's versus getting a /32 for every POP? In either >>> case, I'm going to put the same number of routes into the DFZ. >> >> If you announce an ISP /32 from each POP (or an end-user /48, /47, >> etc) then I know that a neutral third party has vetted your proposed >> network configuration and confirmed that the routes are disaggregated >> because the network architecture requires it. If you announce a /47 >> from your ISP space, for all I know you're trying to tweak utilization >> on your ISP uplinks. > > Again, I thought the discussion was about PI, not PA. I don't announce any PA. Hi Michael, PI and PA terminology is getting to be as obsolete as Class A, B and C. Your IPv6 addresses fall in to one of three categories: "Allocation" from RIR under ISP rules (/32 or more) "Assignment" from RIR under end-user rules (/48 or more) "Reassignment" from ISP (any size) You will find that you can successfully propagate announcements of allocations in units of /32 or shorter, assignments in units of /48 or shorter and reassignments in units of /32 or shorter. Longer prefix announcements won't be rejected by everybody, but they'll be rejected by enough folks to spoil your day. So, regardless of which of the three types of addresses you work with, you should make sure to get enough so that each of your discrete multihomed networks can announce a prefix as big as or bigger than the minimum. And as a purely pragmatic matter, you should never ever try to number a discrete multihomed IPv6 network using a reassignment. Go get an allocation or assignment (as appropriate) from the RIR instead. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From MGauvin at dryden.ca Thu Nov 15 01:09:52 2012 From: MGauvin at dryden.ca (Mark Gauvin) Date: Wed, 14 Nov 2012 19:09:52 -0600 Subject: "authority" to route? In-Reply-To: <50A428D3.9090706@bogus.com> References: <20121112194346.GE28511@reptiles.org> <727C5943-1BA0-470A-8BF7-05188C164E4F@hopcount.ca> <50A428D3.9090706@bogus.com> Message-ID: <9ADAFE30-C036-47F4-AB08-CC1A9D015545@dryden.ca> Careful though cause the crayons must be crayola approved Sent from my iPhone On 2012-11-14, at 5:28 PM, "joel jaeggli" wrote: > On 11/14/12 2:40 PM, Joe Abley wrote: >> On 2012-11-12, at 14:43, Jim Mercer wrote: >> >>> Is there a common practice of providers to vet / validate requests to advertise >>> blocks? >> Yes, most providers whose customers request a particular route to be pointed towards them will ask for ambiguous instructions, written on letterhead with crayon, and signed illegibly by someone who may or may not have authority to do so but who in any case cannot be identified clearly by their scrawl. > Some providers ask for route objects and appropriate import/export > policy in RADB. that fandamently no higher quality an attestation than a > LOA but it's a lot easier to read. >> Ideally the letterhead should be crudely constructed in photoshop and then faxed across a noisy analogue line. >> >> Once you have one of those babies in your file, no lawyer can touch you. >> >> >> Joe >> >> >> > > From robertg at garlic.com Thu Nov 15 01:14:00 2012 From: robertg at garlic.com (Robert Glover) Date: Wed, 14 Nov 2012 17:14:00 -0800 Subject: "authority" to route? In-Reply-To: <9ADAFE30-C036-47F4-AB08-CC1A9D015545@dryden.ca> References: <20121112194346.GE28511@reptiles.org> <727C5943-1BA0-470A-8BF7-05188C164E4F@hopcount.ca> <50A428D3.9090706@bogus.com> <9ADAFE30-C036-47F4-AB08-CC1A9D015545@dryden.ca> Message-ID: <50A441D8.2000908@garlic.com> Another big-name-big-$$$ vendor whose name begins with "C". Sounds like a "c"onspiracy to me............ On 11/14/2012 5:09 PM, Mark Gauvin wrote: > Careful though cause the crayons must be crayola approved > > Sent from my iPhone > > On 2012-11-14, at 5:28 PM, "joel jaeggli" wrote: > >> On 11/14/12 2:40 PM, Joe Abley wrote: >>> On 2012-11-12, at 14:43, Jim Mercer wrote: >>> >>>> Is there a common practice of providers to vet / validate requests to advertise >>>> blocks? >>> Yes, most providers whose customers request a particular route to be pointed towards them will ask for ambiguous instructions, written on letterhead with crayon, and signed illegibly by someone who may or may not have authority to do so but who in any case cannot be identified clearly by their scrawl. >> Some providers ask for route objects and appropriate import/export >> policy in RADB. that fandamently no higher quality an attestation than a >> LOA but it's a lot easier to read. >>> Ideally the letterhead should be crudely constructed in photoshop and then faxed across a noisy analogue line. >>> >>> Once you have one of those babies in your file, no lawyer can touch you. >>> >>> >>> Joe >>> >>> >>> >> From o.calvano at gmail.com Thu Nov 15 04:00:42 2012 From: o.calvano at gmail.com (Olivier CALVANO) Date: Thu, 15 Nov 2012 05:00:42 +0100 Subject: Brasil/Mexico/Argentina connectivity Message-ID: Hi I am search one or more carrier for connect 3 sites in Brasil, Mexico and Argentina to one of our pop in USA or Spain. if you have a name and contact ;=) best regards Olivier From pfsinoz at gmail.com Thu Nov 15 08:03:33 2012 From: pfsinoz at gmail.com (Philip Smith) Date: Thu, 15 Nov 2012 18:03:33 +1000 Subject: APRICOT 2013 in Singapore Message-ID: <50A4A1D5.3010400@gmail.com> Hi everyone, Just to let you know that the call for papers for APRICOT 2013 (in Singapore next February) opened a few days ago. Rather than posting the whole cfp here, you can see it via the programme page on the APRICOT website - www.apricot2013.net/program. NANOG and APRICOT are the network operations conferences for adjacent regions - and indeed both regions have considerable overlap and interests in common. Please give some thought to presenting something topical at APRICOT - the Programme Committee would love to hear from you. You can submit your proposal via http://papers.apricot.net. Thanks! philip (on behalf of the APRICOT PC) -- From Ben.Butler at c2internet.net Thu Nov 15 10:15:04 2012 From: Ben.Butler at c2internet.net (Ben S. Butler) Date: Thu, 15 Nov 2012 10:15:04 +0000 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2FC@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com> <416A23FC91E34449999D047BF540B46901689658E2FC@EXCHANGE.atlasbiz.com> Message-ID: <416A23FC91E34449999D047BF540B46901689658E2FE@EXCHANGE.atlasbiz.com> Hi, I thought I would share an extract from an email I sent off list to a peer. My mail was a rather ramberly stream of consciousness exploring the issue, which worked its way to a potential solution... Hence why I am sharing an extract from it. I am not sure how practicably implementable it would be with the use of communities and some extra filtering logic implemented by the router software to enable prefix matching on less specific. I include for open discussion, I am sure there are things wrong with this idea, but maybe we can move towards a solution that works for everyone, rather than continuing in a straight line and having a bloated v6 route soup of indistinguishable /48s all over the place. Maybe the below has some legs, I leave it for those clever than me to see if this can be incorporated into an emergent BCP that might address what we should be doing and give everyone clear guidelines and keep everything on track. As I said its not the content networks I have issue with, it the rest of the access networks and hosting networks that are going to abuse a relaxation policy of "you should only announce /32 and use communities and no export for TE to adjacent ASes, but because there are a lot of island networks that require /48 support yours will also get accepted but please don't do this for TE reasons." What we need is a way to filter that says throw this prefix away if I can see it inside of another prefix. Ie discard this /48 if it is part of a /32 (or bigger) that I also have in my RIB and then insert the /32 into FIB and discard the /48". That would dump off all the TE nonsense, while keeping the island networks /48s. This new functionality could be used in a route map so it could be augmented with community matching or AS filter lists. That would solve the problem, all be it at the cost of the processing overhead to examine each /48 in the table and recurse its route, versus simple application of a filter list based on net block and minimum allocation size. I guess another thing that might work is if we all start passing communities and then we can tag some /48s as I am a TE prefix with a cover route and use a different community to tag I am an island prefix with no cover route, and then we can filter or permit those in a route map as the recipient sees fit and next the route map could filter everything left on RIR minimums for the block. That might work a lot better, if everyone passed communities.... At least people would be incentivised to tag the island routes which would be guaranteed to be permitted, we might have to worry about some people tagging a TE route as an island route. So I guess the logic becomes.... /48 Routes tagged with an island community permit as long as there is not a less specific covering route in the RIB. /48 Routes tagged with a TE community can be permitted or denied as chosen by the recipient end AS but should be carried in the DFZ by transit providers. /48 Routes that are not tagged should be assessed against RIR netblock minimums as being valid or invalid. Future RIR assignments should rigorously explore if the assignment is intended to be going to have an aggregate route or not, so for island networks that will not be aggregated are moved to a separate /12 with a /48 minimum and /40 maximum announced prefix size - rather than carried in the same block as "PA (Aggregated)" / "ISP" blocks that have a /32 minimum. If we do that, it keeps the existing problem the size it is currently and solves it for future assignments, allows the island networks to work, prevents people cheating by trying to sneak a TE route in as an island route when there is covering /32 route, dumps off the rubbish from spurious announcements and hijacking, while allowing PI end user /48s to continue to work... I think that would address the problem. Thoughts...? Ben -----Original Message----- From: Ben S. Butler Sent: 15 November 2012 00:05 To: 'Michael Smith'; William Herrin Cc: nanog at nanog.org Subject: RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. Hi, " Again, I thought the discussion was about PI, not PA. I don't announce any PA." My point, which I feel may be getting lost, and for which ARIN may already have policies in place for, is that an IP assignment is made out of a block with a defined minimum assignment size. Now some people simply advertise the assignment that is made to them, some people chose to advertise more specifics with a covering route, I have no problem with any of this. What I am saying, is if people chose to deagregate to create islands, for which I can completely understand the commercial and networking reason and why it is then by extension impossible for them to advertise the covering route. Then in these specific cases of "islands" then these assignments should be made by the RIR from a block with a minimum prefix size of a /48. Then the application is submitted to the RIR it will justify as much space as it justifies, but at this point it should also be established - without any judgment positive or negative - if the intention is to advertise this unagregated or with a route for the aggregate. The RIR would then be empowered to assign the requested amount of address space from a block which can be labelled with a lower minimum prefix size. I am not judging any of these design practices. What I am pointing out is that the designs are being implemented in assignment blocks that do not reflect the recipients implementations intentions and this is neither helpful for them or other AS operators when it comes to filtering. If RIR policies establish this intention at the point of assignment then the "island" case will be catered for and we absolutely do not want to see an aggregate in the route table for assignments from that block. IF it is TE then it can be made from a conventional block with a cover router and more specifics. What I am seeing in the real world is island networks in address space with minimum /32 assigments. It is my choice if I filter your TE, it is a stupid choice if you don't advertise the cover route because you are doing TE. But what we need to facilitate are islands networks which for very sensible technical and commercial reasons are unable to advertise an aggregate. Policies may be in place to provide for this, however, what I am seeing in the route table is telling me that the policies are failing to identify people that want to implement their network in this fashion as they are coming from blocks with /32 min and they are advertising /48s. If these announcements came from and address block to which they were assigned with a minimum of a /48 because of their design intentions then everyone is happy and can announce and filer accordingly and end points are reachable. There is a reason that different blocks have different minimum sizes, I am advocating ensuring that we get assignments aligned with the blocks that are suit the intended implementation. It is not my place to judge your business, nor is it anyone elses to expect the rest of us to accept TE routes without a coverall and expect to be reachable. My 2c Ben -----Original Message----- From: Michael Smith [mailto:mksmith at mac.com] Sent: 14 November 2012 23:32 To: William Herrin Cc: nanog at nanog.org; Michael Smith Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On Nov 14, 2012, at 1:50 PM, William Herrin wrote: > On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith wrote: >> I guess I'm confused. I have a /32 that I have broken up into /47's >> for my discrete POP locations. I don't have a network between them, >> by design. And, I won't announce the /32 covering route because >> there is no single POP that can take requests for the entire >> /32 - think regionalized anycast. >> >> So, how is it "worse" to announce the deaggregated /47's versus >> getting a /32 for every POP? In either case, I'm going to put the >> same number of routes into the DFZ. > > Hi Michael, > > If you announce an ISP /32 from each POP (or an end-user /48, /47, > etc) then I know that a neutral third party has vetted your proposed > network configuration and confirmed that the routes are disaggregated > because the network architecture requires it. If you announce a /47 > from your ISP space, for all I know you're trying to tweak utilization > on your ISP uplinks. > Again, I thought the discussion was about PI, not PA. I don't announce any PA. > In the former case, the protocols are capable of what they're capable > of. Discrete multihomed network, discrete announcement. Like it or > lump it. > > In the latter case, I don't particularly need to burn resources on my > router half a world away to facilitate your traffic tweaking. Let the > ISPs you're paying for the privilege carry your more-specifics. > You have great confidence in the immutability of design and the description thereof. Mike From david at mailplus.nl Thu Nov 15 14:12:23 2012 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Thu, 15 Nov 2012 15:12:23 +0100 Subject: Dns sometimes fails using Google DNS / automatic dnssec Message-ID: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D38@SBS1.blinker.local> Hi, We've been seeing automatic RRSIG records on Google DNS lately, the 8.8.8.8 en 8.8.4.4. They are not always provided. They cause problems for some of our customers in a weird way I cannot explain. For them these records do not resolve but I cannot reproduce it. So when I run dig command dig @8.8.8.8 m1.mailplus.nl it often provides the RRSIG record (but e.g. the TXT record will not be signed). I've heard that DNS may fall back to TCP and/or may be filtered by firewalls if UDP is over 512 bytes. However, the request is not that long, about 200 bytes if I interpret the answer correctly. Can someone come up with a good explanation why a tiny percentage of our customers cannot resolve (some of) our domains? Btw, our nameservers (transip.nl) only provide DNSSEC records if explicitly asked. What is standard here? Thanks, David Hofstee From ralph.brandt at pateam.com Thu Nov 15 14:28:14 2012 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Thu, 15 Nov 2012 09:28:14 -0500 Subject: Eaton 9130 UPS feedback In-Reply-To: <50A2A696.7070403@rollernet.us> References: <50A2A696.7070403@rollernet.us> Message-ID: <51C66083768C2949A7EB14910C78B01701BA451F@embgsr24.pateam.com> Note the EATON Press release. Maybe the "burn on the bench" is the way they get to the California energy reduction Standards? If it isn't working it isn't using power. Date: 23 October 2012 Latest Eaton Thought Leadership White Paper Provides Technical Analysis of Eaton's Energy Saver System Eaton today announced the release of its latest white paper, "Understanding Eaton Energy Saver System." In the paper, George Navarro, an Eaton technical solutions engineering specialist, explains how Eaton's Energy Saver System (ESS) enables large uninterruptible power systems (UPSs) to operate at up to 99 percent efficiency without sacrificing reliability. Though ESS is rapidly gaining support in the UPS industry for its ability to build on the strengths of traditional double-conversion architectures, many consultants and end users have questions about how ESS works and what enables it to lower power consumption while maintaining high levels of availability. In the paper, Navarro answers these questions by providing in-depth technical information about ESS's architecture, reliability characteristics, computational infrastructure and surge suppression attributes. Ralph Brandt -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Tuesday, November 13, 2012 2:59 PM To: nanog at nanog.org Subject: Eaton 9130 UPS feedback Does anyone use Eaton 9130 series UPS for anything? I'm curious how they've worked out for you. I bought a 700VA model to give it a whirl versus the traditional APC since the Eaton is an online type with static bypass and also does some high efficiency thing where it normally stays on bypass, but the first thing it did on the bench was have the inverter/rectifier or bypass section catch on fire and destroy itself. ~Seth From guu at google.com Thu Nov 15 14:47:02 2012 From: guu at google.com (Yunhong Gu) Date: Thu, 15 Nov 2012 09:47:02 -0500 Subject: Dns sometimes fails using Google DNS / automatic dnssec In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D38@SBS1.blinker.local> References: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D38@SBS1.blinker.local> Message-ID: Hi, David I work at Google Public DNS and will take a look at this issue. No RRSIG should be returned unless the client set the DO bit to ask for it. Thanks Yunhong On Thu, Nov 15, 2012 at 9:12 AM, MailPlus| David Hofstee wrote: > Hi, > > We've been seeing automatic RRSIG records on Google DNS lately, the 8.8.8.8 en 8.8.4.4. They are not always provided. They cause problems for some of our customers in a weird way I cannot explain. For them these records do not resolve but I cannot reproduce it. > > So when I run dig command > > dig @8.8.8.8 m1.mailplus.nl > > it often provides the RRSIG record (but e.g. the TXT record will not be signed). I've heard that DNS may fall back to TCP and/or may be filtered by firewalls if UDP is over 512 bytes. However, the request is not that long, about 200 bytes if I interpret the answer correctly. > > Can someone come up with a good explanation why a tiny percentage of our customers cannot resolve (some of) our domains? > > Btw, our nameservers (transip.nl) only provide DNSSEC records if explicitly asked. What is standard here? > > > Thanks, > > David Hofstee From blueneon at gmail.com Thu Nov 15 14:57:43 2012 From: blueneon at gmail.com (Tom Morris) Date: Thu, 15 Nov 2012 09:57:43 -0500 Subject: Eaton 9130 UPS feedback In-Reply-To: <51C66083768C2949A7EB14910C78B01701BA451F@embgsr24.pateam.com> References: <50A2A696.7070403@rollernet.us> <51C66083768C2949A7EB14910C78B01701BA451F@embgsr24.pateam.com> Message-ID: Yeah, that's about right. When I had one fail that was not set in power saver mode, it just shut off intermittently before letting out the genie. When I had one go out while it was in energy saver mode, it continued to operate but put out a weak ~80Vrms with heavy distortion that caused equipment damage. Foul. Also in regards to OutBack - the Radian GS8048 is beautiful. I'd highly recommend it. It is basically two inverter/charger modules paralleled in one chassis, each being 4Kw. I was playing with one and yoinked the control cable to one module -- the power stayed on without incident and the MATE3 control unit (which is fun and Ethernet equipped) reported the error. If you use the 8048 in half capacity it's redundant. It gives 120/240 (l1, neutral, l2) out of the box and is pure sine. I recommend getting the matching GS load center with it because it makes the install super easy and includes the requisite breakers. Tom Morris, KG4CYX Chairman, South Florida Tropical Hamboree Mad Scientist, Miami Children's Museum This message sent from a mobile device. Silly typos provided free of charge. On Nov 15, 2012 9:29 AM, "Brandt, Ralph" wrote: > Note the EATON Press release. Maybe the "burn on the bench" is the way > they get to the California energy reduction Standards? If it isn't > working it isn't using power. > > > Date: 23 October 2012 > > Latest Eaton Thought Leadership White Paper Provides Technical Analysis > of Eaton's Energy Saver System > > Eaton today announced the release of its latest white paper, > "Understanding Eaton Energy Saver System." In the paper, George Navarro, > an Eaton technical solutions engineering specialist, explains how > Eaton's Energy Saver System (ESS) enables large uninterruptible power > systems (UPSs) to operate at up to 99 percent efficiency without > sacrificing reliability. > > Though ESS is rapidly gaining support in the UPS industry for its > ability to build on the strengths of traditional double-conversion > architectures, many consultants and end users have questions about how > ESS works and what enables it to lower power consumption while > maintaining high levels of availability. In the paper, Navarro answers > these questions by providing in-depth technical information about ESS's > architecture, reliability characteristics, computational infrastructure > and surge suppression attributes. > > Ralph Brandt > > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Tuesday, November 13, 2012 2:59 PM > To: nanog at nanog.org > Subject: Eaton 9130 UPS feedback > > Does anyone use Eaton 9130 series UPS for anything? I'm curious how > they've worked out for you. > > I bought a 700VA model to give it a whirl versus the traditional APC > since the Eaton is an online type with static bypass and also does some > high efficiency thing where it normally stays on bypass, but the first > thing it did on the bench was have the inverter/rectifier or bypass > section catch on fire and destroy itself. > > ~Seth > > > From nanog at jima.tk Thu Nov 15 16:05:37 2012 From: nanog at jima.tk (Jima) Date: Thu, 15 Nov 2012 09:05:37 -0700 (MST) Subject: Brasil/Mexico/Argentina connectivity In-Reply-To: References: Message-ID: <51581.2001:1938:1ce:0:5054:ff:fead:107.1352995537.squirrel@laughton.us> On Wednesday, November 14th, 2012, Olivier CALVANO wrote: > I am search one or more carrier for connect 3 sites in Brasil, Mexico > and Argentina to one of our pop > in USA or Spain. I don't deal with it directly, but my employer has used MPLS offerings from (in alphabetical order) BT, Level 3/Global Crossing, and Verizon in a number of countries. I suspect any of the three have access in all of the countries listed. I imagine there are others, but those are the ones that sprung to mind. Jima From david at mailplus.nl Thu Nov 15 15:06:11 2012 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Thu, 15 Nov 2012 16:06:11 +0100 Subject: Dns sometimes fails using Google DNS / automatic dnssec In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D38@SBS1.blinker.local> Message-ID: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D51@SBS1.blinker.local> root at e3:/home/services# dig @8.8.8.8 m1.mailplus.nl ; <<>> DiG 9.7.3 <<>> @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38880 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;m1.mailplus.nl. IN A ;; ANSWER SECTION: m1.mailplus.nl. 1867 IN A 46.31.50.16 m1.mailplus.nl. 1867 IN RRSIG A 7 3 3600 20130517082302 20121115082302 3767 mailplus.nl. WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1pQRo8YIcxzlSN tHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0bMKYKIDuK8Gtz47AVDJaU0eX 0FR8F5qqw897ClGf5ISa0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWF ujs= ;; Query time: 5 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 16:05:26 2012 ;; MSG SIZE rcvd: 219 ----------------------- David Hofstee -----Oorspronkelijk bericht----- Van: Yunhong Gu [mailto:guu at google.com] Verzonden: donderdag 15 november 2012 15:47 Aan: MailPlus| David Hofstee CC: nanog at nanog.org Onderwerp: Re: Dns sometimes fails using Google DNS / automatic dnssec Hi, David I work at Google Public DNS and will take a look at this issue. No RRSIG should be returned unless the client set the DO bit to ask for it. Thanks Yunhong On Thu, Nov 15, 2012 at 9:12 AM, MailPlus| David Hofstee wrote: > Hi, > > We've been seeing automatic RRSIG records on Google DNS lately, the 8.8.8.8 en 8.8.4.4. They are not always provided. They cause problems for some of our customers in a weird way I cannot explain. For them these records do not resolve but I cannot reproduce it. > > So when I run dig command > > dig @8.8.8.8 m1.mailplus.nl > > it often provides the RRSIG record (but e.g. the TXT record will not be signed). I've heard that DNS may fall back to TCP and/or may be filtered by firewalls if UDP is over 512 bytes. However, the request is not that long, about 200 bytes if I interpret the answer correctly. > > Can someone come up with a good explanation why a tiny percentage of our customers cannot resolve (some of) our domains? > > Btw, our nameservers (transip.nl) only provide DNSSEC records if explicitly asked. What is standard here? > > > Thanks, > > David Hofstee From jay-ford at uiowa.edu Thu Nov 15 17:26:24 2012 From: jay-ford at uiowa.edu (Jay Ford) Date: Thu, 15 Nov 2012 11:26:24 -0600 (CST) Subject: Dns sometimes fails using Google DNS / automatic dnssec In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D51@SBS1.blinker.local> References: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D38@SBS1.blinker.local> <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D51@SBS1.blinker.local> Message-ID: It looks like if the server has the RRSIG RR, it returns it. For example, a query with +dnssec will cause it to cache the RRSIG, after which it returns it even if +dnssec not specified. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 ________________________________________ query without +dnssec before RRSIG is cached; RRSIG not returned ________________________________________ : dig @8.8.8.8 m1.mailplus.nl ; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3665 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;m1.mailplus.nl. IN A ;; ANSWER SECTION: m1.mailplus.nl. 2985 IN A 46.31.50.16 ;; Query time: 15 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 11:22:02 2012 ;; MSG SIZE rcvd: 48 ________________________________________ query with +dnssec; RRSIG is returned ________________________________________ : dig +dnssec +multi @8.8.8.8 m1.mailplus.nl ; <<>> DiG 9.8.1-P1 <<>> +dnssec +multi @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58877 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;m1.mailplus.nl. IN A ;; ANSWER SECTION: m1.mailplus.nl. 2978 IN A 46.31.50.16 m1.mailplus.nl. 2978 IN RRSIG A 7 3 3600 20130517082302 ( 20121115082302 3767 mailplus.nl. WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1p QRo8YIcxzlSNtHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0 bMKYKIDuK8Gtz47AVDJaU0eX0FR8F5qqw897ClGf5ISa 0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWFujs= ) ;; Query time: 16 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 11:22:10 2012 ;; MSG SIZE rcvd: 230 ________________________________________ query without +dnssec after RRSIG is cached; RRSIG returned ________________________________________ : dig +multi @8.8.8.8 m1.mailplus.nl ; <<>> DiG 9.8.1-P1 <<>> +multi @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13524 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;m1.mailplus.nl. IN A ;; ANSWER SECTION: m1.mailplus.nl. 2974 IN A 46.31.50.16 m1.mailplus.nl. 2974 IN RRSIG A 7 3 3600 20130517082302 ( 20121115082302 3767 mailplus.nl. WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1p QRo8YIcxzlSNtHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0 bMKYKIDuK8Gtz47AVDJaU0eX0FR8F5qqw897ClGf5ISa 0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWFujs= ) ;; Query time: 17 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 11:22:13 2012 ;; MSG SIZE rcvd: 219 From guu at google.com Thu Nov 15 17:29:18 2012 From: guu at google.com (Yunhong Gu) Date: Thu, 15 Nov 2012 12:29:18 -0500 Subject: Dns sometimes fails using Google DNS / automatic dnssec In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D38@SBS1.blinker.local> <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D51@SBS1.blinker.local> Message-ID: Hi, we have found the bug that caused this problem. It was introduced in a very recent release. The fix is on its way. Thanks very much for the report, Yunhong On Thu, Nov 15, 2012 at 12:26 PM, Jay Ford wrote: > It looks like if the server has the RRSIG RR, it returns it. For example, a > query with +dnssec will cause it to cache the RRSIG, after which it returns > it even if +dnssec not specified. > > ________________________________________________________________________ > Jay Ford, Network Engineering Group, Information Technology Services > University of Iowa, Iowa City, IA 52242 > email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 > > ________________________________________ > query without +dnssec before RRSIG is cached; RRSIG not returned > ________________________________________ > > : dig @8.8.8.8 m1.mailplus.nl > > ; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 m1.mailplus.nl > > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3665 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;m1.mailplus.nl. IN A > > ;; ANSWER SECTION: > m1.mailplus.nl. 2985 IN A 46.31.50.16 > > ;; Query time: 15 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Thu Nov 15 11:22:02 2012 > ;; MSG SIZE rcvd: 48 > > ________________________________________ > query with +dnssec; RRSIG is returned > ________________________________________ > > : dig +dnssec +multi @8.8.8.8 m1.mailplus.nl > > ; <<>> DiG 9.8.1-P1 <<>> +dnssec +multi @8.8.8.8 m1.mailplus.nl > > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58877 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > > ;; QUESTION SECTION: > ;m1.mailplus.nl. IN A > > ;; ANSWER SECTION: > m1.mailplus.nl. 2978 IN A 46.31.50.16 > m1.mailplus.nl. 2978 IN RRSIG A 7 3 3600 20130517082302 ( > > 20121115082302 3767 mailplus.nl. > > WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1p > > QRo8YIcxzlSNtHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0 > > bMKYKIDuK8Gtz47AVDJaU0eX0FR8F5qqw897ClGf5ISa > 0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWFujs= ) > > ;; Query time: 16 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Thu Nov 15 11:22:10 2012 > ;; MSG SIZE rcvd: 230 > > ________________________________________ > query without +dnssec after RRSIG is cached; RRSIG returned > ________________________________________ > > : dig +multi @8.8.8.8 m1.mailplus.nl > > ; <<>> DiG 9.8.1-P1 <<>> +multi @8.8.8.8 m1.mailplus.nl > > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13524 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;m1.mailplus.nl. IN A > > ;; ANSWER SECTION: > m1.mailplus.nl. 2974 IN A 46.31.50.16 > m1.mailplus.nl. 2974 IN RRSIG A 7 3 3600 20130517082302 ( > > 20121115082302 3767 mailplus.nl. > > WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1p > > QRo8YIcxzlSNtHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0 > > bMKYKIDuK8Gtz47AVDJaU0eX0FR8F5qqw897ClGf5ISa > 0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWFujs= ) > > ;; Query time: 17 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Thu Nov 15 11:22:13 2012 > ;; MSG SIZE rcvd: 219 From alejandroacostaalamo at gmail.com Thu Nov 15 17:32:47 2012 From: alejandroacostaalamo at gmail.com (alejandroacostaalamo at gmail.com) Date: Thu, 15 Nov 2012 17:32:47 +0000 Subject: Brasil/Mexico/Argentina connectivity Message-ID: <1984961007-1353000772-cardhu_decombobulator_blackberry.rim.net-1637513584-@b27.c3.bise6.blackberry> Hi Jima, I can help you contacting BT if you need so. Alejandro, ------Mensaje original------ De: Jima Para: nanog at nanog.org Asunto: Re: Brasil/Mexico/Argentina connectivity Enviado: 15 nov, 2012 11:35 On Wednesday, November 14th, 2012, Olivier CALVANO wrote: > I am search one or more carrier for connect 3 sites in Brasil, Mexico > and Argentina to one of our pop > in USA or Spain. I don't deal with it directly, but my employer has used MPLS offerings from (in alphabetical order) BT, Level 3/Global Crossing, and Verizon in a number of countries. I suspect any of the three have access in all of the countries listed. I imagine there are others, but those are the ones that sprung to mind. Jima Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet From dot at dotat.at Thu Nov 15 17:38:24 2012 From: dot at dotat.at (Tony Finch) Date: Thu, 15 Nov 2012 17:38:24 +0000 Subject: Dns sometimes fails using Google DNS / automatic dnssec In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D38@SBS1.blinker.local> <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D51@SBS1.blinker.local> Message-ID: Jay Ford wrote: > It looks like if the server has the RRSIG RR, it returns it. For example, a > query with +dnssec will cause it to cache the RRSIG, after which it returns > it even if +dnssec not specified. It's weird. If you repeatedly query 8.8.4.4 without the DO bit, you get a mixture of responses with and without an RRSIG and with varying TTLs. With DO it appears to consistently return an RRSIG in the answer and the TTL drops monotonically. 8.8.8.8 is similar except DO=0 replies don't include RRSIGs. (Querying from JANET UK and hitting some servers a lethargic 12ms away.) while sleep 1; do dig +dnssec @8.8.4.4 m1.mailplus.nl; done Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From heather.schiller at verizon.com Thu Nov 15 18:36:20 2012 From: heather.schiller at verizon.com (Schiller, Heather A) Date: Thu, 15 Nov 2012 13:36:20 -0500 Subject: "authority" to route? In-Reply-To: <20121112194346.GE28511@reptiles.org> References: <20121112194346.GE28511@reptiles.org> Message-ID: "..for some blocks I've taken over admin for." Make sure you are visibly listed as a Point of Contact on those records in the appropriate RIR, so that folks who get your request can verify you. Even better, register in your RIR's RPKI program and generate a ROA for it. Info about ARIN's here: https://www.arin.net/resources/rpki/index.html Then yes, notify their upstreams/peers if needed and post here if things get really desperate - have your records in order first. --Heather -----Original Message----- From: Jim Mercer [mailto:jim at reptiles.org] Sent: Monday, November 12, 2012 2:44 PM To: nanog at nanog.org Subject: "authority" to route? Hi, Is there a common practice of providers to vet / validate requests to advertise blocks? Who is the "authority" when it comes to determining if a request for routing is valid? Is it the WHOIS data maintained by the various RIR? It seems I'm playing whack-a-mole to get some routes shut down for some blocks I've taken over admin for. If I email the contacts for the AS in WHOIS, and get no response, or a negative response, should I start going to their peers? Some practical advice would be appreciated. -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From mikeal.clark at gmail.com Thu Nov 15 18:54:17 2012 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Thu, 15 Nov 2012 12:54:17 -0600 Subject: MPLS acceptable latency? Message-ID: Hello! I have some AT&T MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Thanks, From dwhite at olp.net Thu Nov 15 19:13:06 2012 From: dwhite at olp.net (Dan White) Date: Thu, 15 Nov 2012 13:13:06 -0600 Subject: MPLS acceptable latency? In-Reply-To: References: Message-ID: <20121115191306.GI6576@dan.olp.net> On 11/15/12?12:54?-0600, Mikeal Clark wrote: >Hello! > >I have some AT&T MPLS sites under a managed contract with latency >averaging 75-85 ms without any load. These sites are only 45 minutes >away. What is considered normal/acceptable? I recently had a scenario with some MPLS sites within the state nearly doubling in latency (below 50ms round trip). Typically I see round trip latency in the 20-35ms range, and those sites are within about a 90 minute drive from each other (Oklahoma, mostly T1s). When I asked an AT&T tech to investigate, he did not see log entries to explain the increase or admit to any trouble, and stated that the service levels for these MPLS circuits allowed for 75-80ms and I don't recall if that was one way or round trip. He said that was to allow for coast to coast latency scenarios. Delay returned to typical levels about 4 days later, without explanation. -- Dan White From eyeronic.design at gmail.com Thu Nov 15 19:14:38 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Thu, 15 Nov 2012 11:14:38 -0800 Subject: MPLS acceptable latency? In-Reply-To: References: Message-ID: Acceptable from a technical standpoint (in that stuff works) or acceptable from an expected service standpoint? In the case of the former, MPLS can run over really high latencies, so you're nowhere near the limit. For the latter, 85ms would be highly unacceptable to me for a circuit to a site that's so close. I would think your traffic is either being routed really, really badly or their circuits are way over-subscribed. On Thu, Nov 15, 2012 at 10:54 AM, Mikeal Clark wrote: > Hello! > > I have some AT&T MPLS sites under a managed contract with latency > averaging 75-85 ms without any load. These sites are only 45 minutes > away. What is considered normal/acceptable? > > Thanks, > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From surfer at mauigateway.com Thu Nov 15 19:15:05 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 15 Nov 2012 11:15:05 -0800 Subject: MPLS acceptable latency? Message-ID: <20121115111505.90E09BD7@m0005312.ppops.net> --- mikeal.clark at gmail.com wrote: From: Mikeal Clark I have some AT&T MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? -------------------------------------------- Coast-to-coast latency is around 60-65msec, so that's high. scott From jared at puck.nether.net Thu Nov 15 19:16:14 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 15 Nov 2012 14:16:14 -0500 Subject: MPLS acceptable latency? In-Reply-To: References: Message-ID: On Nov 15, 2012, at 1:54 PM, Mikeal Clark wrote: > Hello! > > I have some AT&T MPLS sites under a managed contract with latency > averaging 75-85 ms without any load. These sites are only 45 minutes > away. What is considered normal/acceptable? MPLS as a technology should not add any significant delay as it is just a few bytes of label on the packet. What is the physical path of the circuits involved? Have you asked for the design of them? - Jared From jared at puck.nether.net Thu Nov 15 19:20:40 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 15 Nov 2012 14:20:40 -0500 Subject: MPLS acceptable latency? In-Reply-To: <20121115111505.90E09BD7@m0005312.ppops.net> References: <20121115111505.90E09BD7@m0005312.ppops.net> Message-ID: <0ADAD17B-1B4C-4C01-9449-FBA45AC49C84@puck.nether.net> On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: > > > --- mikeal.clark at gmail.com wrote: > From: Mikeal Clark > > I have some AT&T MPLS sites under a managed contract with latency > averaging 75-85 ms without any load. These sites are only 45 minutes > away. What is considered normal/acceptable? > -------------------------------------------- > > > Coast-to-coast latency is around 60-65msec, so that's high. What link speed? Perhaps he's using ISDN or a T1? Serialization delay is not to be ignored. - Jared From mikeal.clark at gmail.com Thu Nov 15 19:35:13 2012 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Thu, 15 Nov 2012 13:35:13 -0600 Subject: MPLS acceptable latency? In-Reply-To: <0ADAD17B-1B4C-4C01-9449-FBA45AC49C84@puck.nether.net> References: <20121115111505.90E09BD7@m0005312.ppops.net> <0ADAD17B-1B4C-4C01-9449-FBA45AC49C84@puck.nether.net> Message-ID: The location in question is 7 T1s. They were not willing to give us fiber. On Thu, Nov 15, 2012 at 1:20 PM, Jared Mauch wrote: > > On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: > >> >> >> --- mikeal.clark at gmail.com wrote: >> From: Mikeal Clark >> >> I have some AT&T MPLS sites under a managed contract with latency >> averaging 75-85 ms without any load. These sites are only 45 minutes >> away. What is considered normal/acceptable? >> -------------------------------------------- >> >> >> Coast-to-coast latency is around 60-65msec, so that's high. > > What link speed? > > Perhaps he's using ISDN or a T1? > > Serialization delay is not to be ignored. > > - Jared > From paul4004 at gmail.com Thu Nov 15 19:50:17 2012 From: paul4004 at gmail.com (PC) Date: Thu, 15 Nov 2012 12:50:17 -0700 Subject: MPLS acceptable latency? In-Reply-To: <0ADAD17B-1B4C-4C01-9449-FBA45AC49C84@puck.nether.net> References: <20121115111505.90E09BD7@m0005312.ppops.net> <0ADAD17B-1B4C-4C01-9449-FBA45AC49C84@puck.nether.net> Message-ID: Your provider is likely backhauling the circuits opposite directions to PE routers in a different geographic local than the sites. It's time to have a discussion with your sales engineer about the physical pathing of your circuits and PE router locations. When I know I have latency critical circuits, I always insist on backhaul to the same geographic region and/or Pe. It's unlikely the MPLS or circuits themselves have anything to do with the latency, assuming this is T1, Ethernet, or similar. It's possible it could be a routing issue SP side, but is not as likely as a general pathing issue. On Thu, Nov 15, 2012 at 12:20 PM, Jared Mauch wrote: > > On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: > > > > > > > --- mikeal.clark at gmail.com wrote: > > From: Mikeal Clark > > > > I have some AT&T MPLS sites under a managed contract with latency > > averaging 75-85 ms without any load. These sites are only 45 minutes > > away. What is considered normal/acceptable? > > -------------------------------------------- > > > > > > Coast-to-coast latency is around 60-65msec, so that's high. > > What link speed? > > Perhaps he's using ISDN or a T1? > > Serialization delay is not to be ignored. > > - Jared > > From westribble at gmail.com Thu Nov 15 19:35:26 2012 From: westribble at gmail.com (Wes Tribble) Date: Thu, 15 Nov 2012 13:35:26 -0600 Subject: MPLS acceptable latency? Message-ID: I concur. We have sites all over the US and it is about 80-100 ms from coast to coast with both of our MPLS providers. 45 minutes away your latency should be <5ms on a decent network. ------------------------------------------------- --- mikeal.clark at gmail.com wrote: From: Mikeal Clark I have some AT&T MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? -------------------------------------------- Coast-to-coast latency is around 60-65msec, so that's high. scott From surfer at mauigateway.com Thu Nov 15 20:17:44 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 15 Nov 2012 12:17:44 -0800 Subject: MPLS acceptable latency? Message-ID: <20121115121744.90E0A30E@m0005312.ppops.net> --- jared at puck.nether.net wrote: On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: > --- mikeal.clark at gmail.com wrote: > I have some AT&T MPLS sites under a managed contract with latency > averaging 75-85 ms without any load. These sites are only 45 minutes > away. What is considered normal/acceptable? > -------------------------------------------- > Coast-to-coast latency is around 60-65msec, so that's high. What link speed? Perhaps he's using ISDN or a T1? Serialization delay is not to be ignored. ------------------------------------------------- I believe serialization delay is so small as to not be very noticeable. A coast-to-coast T1 (that is not full) should have no more latency than a coast-to-coast DS-3 or any other circuit. After all, the T1 is muxed up and then down crossing the same BACs in the middle. The only serialization delay that is different is at the end points. scott (BAC = Big Ass Circuit :) From davidpeahi at gmail.com Thu Nov 15 20:31:23 2012 From: davidpeahi at gmail.com (david peahi) Date: Thu, 15 Nov 2012 12:31:23 -0800 Subject: Fwd: MPLS acceptable latency? In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: david peahi Date: Thu, Nov 15, 2012 at 12:15 PM Subject: Re: MPLS acceptable latency? To: Mikeal Clark Assuming no configuration errors, this underscores the need to negotiate SLAs, and serious SLA penalties, with the telcos, and to always request a telco network map, with the telco path that data will be transitting end-to-end.. My rule of thumb in network design is that data over copper or fiber takes 10 ms per 1000 miles, which is governed by the speed of light. Network devices along the path add serialization/de-serialization delay, but with modern network devices this delay is negligible. So according to this rule of thumb 85 ms is almost enough time for data to traverse the USA 3 times. I have found that telcos have been setting round trip SLAs so high that they are meaningless (e.g. 50 ms for a GigE MEF ELAN service, 20 ms for "Gold" MEF EVPL service), and border on being fraudulent. In one case I also noted 100 ms round trip times between sites less than 1 mile away, and discovered that every packet was being sent back to east Texas from Southern California, almost a 5000 mile detour. On Thu, Nov 15, 2012 at 10:54 AM, Mikeal Clark wrote: > Hello! > > I have some AT&T MPLS sites under a managed contract with latency > averaging 75-85 ms without any load. These sites are only 45 minutes > away. What is considered normal/acceptable? > > Thanks, > > From eric-list at truenet.com Thu Nov 15 20:38:42 2012 From: eric-list at truenet.com (eric-list at truenet.com) Date: Thu, 15 Nov 2012 15:38:42 -0500 Subject: Fwd: MPLS acceptable latency? Message-ID: <35d35314$52980739$1eccee7c$@truenet.com> My humble opinion SLAs are more for accountants and lawyers. Get the right tech support on the phone and you can solve most issues without all the hassle. SLAs really are minimal if you can contact the right people and work through the problem. +1 to Level3 and Cogent as I have had some of the best trouble shooting for even minimal problems... ---------------------------------------- From: "david peahi" Sent: Thursday, November 15, 2012 3:31 PM To: nanog at nanog.org Subject: Fwd: MPLS acceptable latency? ---------- Forwarded message ---------- From: david peahi Date: Thu, Nov 15, 2012 at 12:15 PM Subject: Re: MPLS acceptable latency? To: Mikeal Clark Assuming no configuration errors, this underscores the need to negotiate SLAs, and serious SLA penalties, with the telcos, and to always request a telco network map, with the telco path that data will be transitting end-to-end.. My rule of thumb in network design is that data over copper or fiber takes 10 ms per 1000 miles, which is governed by the speed of light. Network devices along the path add serialization/de-serialization delay, but with modern network devices this delay is negligible. So according to this rule of thumb 85 ms is almost enough time for data to traverse the USA 3 times. I have found that telcos have been setting round trip SLAs so high that they are meaningless (e.g. 50 ms for a GigE MEF ELAN service, 20 ms for "Gold" MEF EVPL service), and border on being fraudulent. In one case I also noted 100 ms round trip times between sites less than 1 mile away, and discovered that every packet was being sent back to east Texas from Southern California, almost a 5000 mile detour. From mpetach at netflight.com Thu Nov 15 20:44:40 2012 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 15 Nov 2012 12:44:40 -0800 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2FE@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com> <416A23FC91E34449999D047BF540B46901689658E2FC@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2FE@EXCHANGE.atlasbiz.com> Message-ID: On Thu, Nov 15, 2012 at 2:15 AM, Ben S. Butler wrote: > Hi, ... > ... > What we need is a way to filter that says throw this prefix away if I can see it inside of another prefix. Ie discard this /48 if it is part of a /32 (or bigger) that I also have in my RIB and then insert the /32 into FIB and discard the /48". Would you want this logic to still apply if you have ::/0 in your table anywhere? It really is the ultimate "covering" route for everything else, and for some set of sites that advertise non-aggregated /48s, their thought process may wander into the territory of "it doesn't matter so much if you don't see the more specifics, you'll just follow your default route to your upstream provider, and it'll reach me that way." It seems that this particular problem space only occurs for networks that want to implement strict filters to limit their routing table size, but also want to run completely default-free. It sounds a little bit like such people may be trying to shift the cost burden around in an odd fashion. "I don't want to listen to your more specifics; I worry about my routing table resources, and whether or not I can keep up with the rest of the internet. But I also want to look like I'm one of the big default-free providers, which means I'm creating reachability problems to your network through my own choices. Won't you help me solve my self-created problem by altering how you build and configure your network?" I have no issues with people filtering out more specific prefixes to limit the size of their view of the routing table; I do it for routers I administer that don't have adequate resources to take a full view. But I also ensure that those devices have a covering default route towards something that *does* know how to get closer to the destination. [more snippage...] > So I guess the logic becomes.... > > /48 Routes tagged with an island community permit as long as there is not a less specific covering route in the RIB. > > /48 Routes tagged with a TE community can be permitted or denied as chosen by the recipient end AS but should be carried in the DFZ by transit providers. If you're having reachability problems to /48s that you're filtering out, you must be trying to play in the DFZ; otherwise, your default route would cover you, and this would be a non-issue. And if you're playing in the DFZ, by your own rule here, you should be carrying those routes rather than filtering them out. > /48 Routes that are not tagged should be assessed against RIR netblock minimums as being valid or invalid. > > Future RIR assignments should rigorously explore if the assignment is intended to be going to have an aggregate route or not, so for island networks that will not be aggregated are moved to a separate /12 with a /48 minimum and /40 maximum announced prefix size - rather than carried in the same block as "PA (Aggregated)" / "ISP" blocks that have a /32 minimum. > > If we do that, it keeps the existing problem the size it is currently and solves it for future assignments, allows the island networks to work, prevents people cheating by trying to sneak a TE route in as an island route when there is covering /32 route, dumps off the rubbish from spurious announcements and hijacking, while allowing PI end user /48s to continue to work... I think that would address the problem. > I think your use of the term "cheating" here is misapplied. You've stated that the more specifics *must* be accepted by the DFZ providers, so that downstreams can make their own decisions as to whether to accept and use them or not. You're implying that your network is default free, and thus by not accepting the more specific prefixes, you would see reachabiliity issues: > It is not my place to judge your business, nor is it anyone elses to expect the rest of us to accept TE routes without a coverall and expect to be reachable. Contrary to that line, you've stated you _do_ expect that DFZ providers should accept those TE routes with or without a coverall, in order to provide reachability. I don't think it's reasonable for you to expect to have it both ways. It really sounds like you want every other DFZ provider to have to carry the longer prefixes *except you*--and I don't think you'll see much support from the rest of the community for a proposal like that. And if you *do* carry ::/0 in your network from an upstream, this is all a moot point; filter away to whatever level your heart desires, you won't be creating a reachability problem; at worst, you'll create some inefficient routing, but the packets will still flow. > > > Thoughts...? > > Ben tl;dr -- "this is what those HE sessions are for." Matt probably way off in the weeds in left field at this point...I should never try to reply to messages during the day; so many distractions, I never remember what it was I was trying to say back when I started the sentence. ^_^; From bill at herrin.us Thu Nov 15 21:23:39 2012 From: bill at herrin.us (William Herrin) Date: Thu, 15 Nov 2012 16:23:39 -0500 Subject: MPLS acceptable latency? In-Reply-To: References: Message-ID: On Thu, Nov 15, 2012 at 1:54 PM, Mikeal Clark wrote: > I have some AT&T MPLS sites under a managed contract with latency > averaging 75-85 ms without any load. These sites are only 45 minutes > away. I've noticed this with AT&T's MPLS product when dealing with the internal corporate network here. I don't know what they're doing wrong but it is so very wrong. > What is considered normal/acceptable? Less than 10ms unless you're using a sub-T1 interface or going a very long distance. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy_94108 at yahoo.com Thu Nov 15 22:06:03 2012 From: randy_94108 at yahoo.com (Randy) Date: Thu, 15 Nov 2012 14:06:03 -0800 (PST) Subject: MPLS acceptable latency? In-Reply-To: Message-ID: <1353017163.26653.YahooMailClassic@web184706.mail.ne1.yahoo.com> --- On Thu, 11/15/12, William Herrin wrote: > From: William Herrin > Subject: Re: MPLS acceptable latency? > To: "Mikeal Clark" > Cc: "NANOG [nanog at nanog.org]" > Date: Thursday, November 15, 2012, 1:23 PM > On Thu, Nov 15, 2012 at 1:54 PM, > Mikeal Clark > wrote: > > I have some AT&T MPLS sites under a managed > contract with latency > > averaging 75-85 ms without any load.? These sites > are only 45 minutes > > away. > > I've noticed this with AT&T's MPLS product when dealing > with the > internal corporate network here. I don't know what they're > doing wrong > but it is so very wrong. circa 2007, noticed same thing: never below 90ms coast-to-coast across as13979. atm ds3 handoffs on both ends. > > >? What is considered normal/acceptable? > > Less than 10ms unless you're using a sub-T1 interface or > going a very > long distance. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? > bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From dreamwaverfx at yahoo.com Thu Nov 15 22:33:25 2012 From: dreamwaverfx at yahoo.com (Alex) Date: Fri, 16 Nov 2012 00:33:25 +0200 Subject: MPLS acceptable latency? In-Reply-To: <1353017163.26653.YahooMailClassic@web184706.mail.ne1.yahoo.com> References: <1353017163.26653.YahooMailClassic@web184706.mail.ne1.yahoo.com> Message-ID: <50A56DB5.5090502@yahoo.com> Perhaps the network is "oldish" and there are BW bottlenecks that lead to queues on the switches/routers that results in higher latency. This would depend alot on the internal QoS strategy used by AT&T, the type of equipment used and the load in different parts of the network. The only way to know what happens inside their MPLS cloud is to get past support and ask someone from the technical staff. On 11/16/2012 12:06 AM, Randy wrote: > --- On Thu, 11/15/12, William Herrin wrote: > >> From: William Herrin >> Subject: Re: MPLS acceptable latency? >> To: "Mikeal Clark" >> Cc: "NANOG [nanog at nanog.org]" >> Date: Thursday, November 15, 2012, 1:23 PM >> On Thu, Nov 15, 2012 at 1:54 PM, >> Mikeal Clark >> wrote: >>> I have some AT&T MPLS sites under a managed >> contract with latency >>> averaging 75-85 ms without any load. These sites >> are only 45 minutes >>> away. >> I've noticed this with AT&T's MPLS product when dealing >> with the >> internal corporate network here. I don't know what they're >> doing wrong >> but it is so very wrong. > circa 2007, noticed same thing: never below 90ms coast-to-coast across as13979. atm ds3 handoffs on both ends. > >>> What is considered normal/acceptable? >> Less than 10ms unless you're using a sub-T1 interface or >> going a very >> long distance. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com >> bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> From Ben.Butler at c2internet.net Fri Nov 16 00:54:12 2012 From: Ben.Butler at c2internet.net (Ben S. Butler) Date: Fri, 16 Nov 2012 00:54:12 +0000 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com> <416A23FC91E34449999D047BF540B46901689658E2FC@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2FE@EXCHANGE.atlasbiz.com> Message-ID: <416A23FC91E34449999D047BF540B46901689658E308@EXCHANGE.atlasbiz.com> Hi, Ok. I am trying to encourage an inclusive exploration of an issue that seems to be emergent. I am trying to get the community to articulate BCP not dictate it. "Would you want this logic to still apply if you have ::/0 in your table anywhere?" Yes obviously limits would apply to the filter on min and max in a recursive filter. "It sounds a little bit like such people may be trying to shift the cost burden around in an odd fashion." I am seeking community input before we manage to screw things up. I do not want a route table with 10M+ prefixes. One of the points of v6 is aggregation, would it not be silly to adopt a liaise a faire view to route pollution and associated security considerations. "But I also want to look like I'm one of the big default-free providers" I struggle to not use direct language here. Firstly I never asserted I was DFZ or want to be, quiet the opposite, seeking clarification of BCP. "default route towards something that *does* know how to get closer to the destination." Filtering exists for internet security not route table size, your default return path trashes that. "you must be trying to play in the DFZ" Lol, understand the issue at hand "I think your use of the term "cheating" here is misapplied." Read my suggestion, if you deliberately falsely tag a route with the wrong community under my proposed model, what would you call it? "You're implying that your network is default free" Nope, I am trying to find a solution that works for everyone that empowers the recipient AS with the choice of what they filter in an informed fashion for mutual benefit. "DFZ provider to have to carry the longer prefixes *except you*" Firstly that was a comment to the sub informed way some people work, however, my point is we have a legacy that can not be solved by new policy. We have to accommodate that legacy and the answer is not to say lets just go with a /48 no questions asked. Networks involve design and engineering, we can accommodate all peoples needs within a structure. "And if you *do* carry ::/0 in your network from an upstream, this is all a moot point; filter away to whatever level your heart desires," You just agreed with me. # We are at the start of a new network, lets learn from the past. My posts are open and non judgemental, please, keep to the issue, if you don't get it yet then clue up. Arms open here, can anyone else see the future cast issue I am tryin to raise if all the aggregate deag without control, we were all worried about PI multihoming a year ago and route table bloat. Lets try to stay on point. Ben From kyle.creyts at gmail.com Fri Nov 16 07:05:39 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Thu, 15 Nov 2012 23:05:39 -0800 Subject: "authority" to route? In-Reply-To: References: <20121112194346.GE28511@reptiles.org> Message-ID: Jeez, isn't RPKI supposed to solve this problem? On Thu, Nov 15, 2012 at 10:36 AM, Schiller, Heather A wrote: > > "..for some blocks I've taken over admin for." > > Make sure you are visibly listed as a Point of Contact on those records in the appropriate RIR, so that folks who get your request can verify you. Even better, register in your RIR's RPKI program and generate a ROA for it. Info about ARIN's here: https://www.arin.net/resources/rpki/index.html > > Then yes, notify their upstreams/peers if needed and post here if things get really desperate - have your records in order first. > > --Heather > > -----Original Message----- > From: Jim Mercer [mailto:jim at reptiles.org] > Sent: Monday, November 12, 2012 2:44 PM > To: nanog at nanog.org > Subject: "authority" to route? > > Hi, > > Is there a common practice of providers to vet / validate requests to advertise blocks? > > Who is the "authority" when it comes to determining if a request for routing is valid? > > Is it the WHOIS data maintained by the various RIR? > > It seems I'm playing whack-a-mole to get some routes shut down for some blocks I've taken over admin for. > > If I email the contacts for the AS in WHOIS, and get no response, or a negative response, should I start going to their peers? > > Some practical advice would be appreciated. > > -- > Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 > "He who dies with the most toys is nonetheless dead" > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From adam.vitkovsky at swan.sk Fri Nov 16 08:08:27 2012 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Fri, 16 Nov 2012 09:08:27 +0100 Subject: MPLS acceptable latency? In-Reply-To: References: <20121115111505.90E09BD7@m0005312.ppops.net> <0ADAD17B-1B4C-4C01-9449-FBA45AC49C84@puck.nether.net> Message-ID: <000c01cdc3d1$8f040940$ad0c1bc0$@swan.sk> It might be some T1 muxing issue adam -----Original Message----- From: Mikeal Clark [mailto:mikeal.clark at gmail.com] Sent: Thursday, November 15, 2012 8:35 PM To: Jared Mauch Cc: nanog at nanog.org Subject: Re: MPLS acceptable latency? The location in question is 7 T1s. They were not willing to give us fiber. On Thu, Nov 15, 2012 at 1:20 PM, Jared Mauch wrote: > > On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: > >> >> >> --- mikeal.clark at gmail.com wrote: >> From: Mikeal Clark >> >> I have some AT&T MPLS sites under a managed contract with latency >> averaging 75-85 ms without any load. These sites are only 45 minutes >> away. What is considered normal/acceptable? >> -------------------------------------------- >> >> >> Coast-to-coast latency is around 60-65msec, so that's high. > > What link speed? > > Perhaps he's using ISDN or a T1? > > Serialization delay is not to be ignored. > > - Jared > From Valdis.Kletnieks at vt.edu Fri Nov 16 17:55:13 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 16 Nov 2012 12:55:13 -0500 Subject: "authority" to route? In-Reply-To: Your message of "Thu, 15 Nov 2012 23:05:39 -0800." References: <20121112194346.GE28511@reptiles.org> Message-ID: <18067.1353088513@turing-police.cc.vt.edu> On Thu, 15 Nov 2012 23:05:39 -0800, Kyle Creyts said: > Jeez, isn't RPKI supposed to solve this problem? That would presume the existence of a deployed system that everybody actually used. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From cscora at apnic.net Fri Nov 16 18:52:35 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Nov 2012 04:52:35 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201211161852.qAGIqZhn031510@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 17 Nov, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 432112 Prefixes after maximum aggregation: 180096 Deaggregation factor: 2.40 Unique aggregates announced to Internet: 212508 Total ASes present in the Internet Routing Table: 42597 Prefixes per ASN: 10.14 Origin-only ASes present in the Internet Routing Table: 33812 Origin ASes announcing only one prefix: 15821 Transit ASes present in the Internet Routing Table: 5680 Transit-only ASes present in the Internet Routing Table: 144 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 36 Prefixes from unregistered ASNs in the Routing Table: 1034 Unregistered ASNs in the Routing Table: 371 Number of 32-bit ASNs allocated by the RIRs: 3490 Number of 32-bit ASNs visible in the Routing Table: 3105 Prefixes from 32-bit ASNs in the Routing Table: 8459 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 153 Number of addresses announced to Internet: 2612770316 Equivalent to 155 /8s, 187 /16s and 182 /24s Percentage of available address space announced: 70.6 Percentage of allocated address space announced: 70.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.9 Total number of prefixes smaller than registry allocations: 151794 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 104545 Total APNIC prefixes after maximum aggregation: 32647 APNIC Deaggregation factor: 3.20 Prefixes being announced from the APNIC address blocks: 105377 Unique aggregates announced from the APNIC address blocks: 43227 APNIC Region origin ASes present in the Internet Routing Table: 4784 APNIC Prefixes per ASN: 22.03 APNIC Region origin ASes announcing only one prefix: 1241 APNIC Region transit ASes present in the Internet Routing Table: 783 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 361 Number of APNIC addresses announced to Internet: 713916352 Equivalent to 42 /8s, 141 /16s and 127 /24s Percentage of available APNIC address space announced: 83.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 155346 Total ARIN prefixes after maximum aggregation: 78462 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 156129 Unique aggregates announced from the ARIN address blocks: 69965 ARIN Region origin ASes present in the Internet Routing Table: 15295 ARIN Prefixes per ASN: 10.21 ARIN Region origin ASes announcing only one prefix: 5768 ARIN Region transit ASes present in the Internet Routing Table: 1595 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1087292032 Equivalent to 64 /8s, 206 /16s and 194 /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, 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: 109952 Total RIPE prefixes after maximum aggregation: 57875 RIPE Deaggregation factor: 1.90 Prefixes being announced from the RIPE address blocks: 112735 Unique aggregates announced from the RIPE address blocks: 72764 RIPE Region origin ASes present in the Internet Routing Table: 16963 RIPE Prefixes per ASN: 6.65 RIPE Region origin ASes announcing only one prefix: 8151 RIPE Region transit ASes present in the Internet Routing Table: 2751 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2009 Number of RIPE addresses announced to Internet: 648665508 Equivalent to 38 /8s, 169 /16s and 217 /24s Percentage of available RIPE address space announced: 94.3 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, 196608-199679 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: 44335 Total LACNIC prefixes after maximum aggregation: 8783 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 47843 Unique aggregates announced from the LACNIC address blocks: 22811 LACNIC Region origin ASes present in the Internet Routing Table: 1708 LACNIC Prefixes per ASN: 28.01 LACNIC Region origin ASes announcing only one prefix: 487 LACNIC Region transit ASes present in the Internet Routing Table: 328 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 712 Number of LACNIC addresses announced to Internet: 119477800 Equivalent to 7 /8s, 31 /16s and 22 /24s Percentage of available LACNIC address space announced: 71.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 9357 Total AfriNIC prefixes after maximum aggregation: 2275 AfriNIC Deaggregation factor: 4.11 Prefixes being announced from the AfriNIC address blocks: 9875 Unique aggregates announced from the AfriNIC address blocks: 3607 AfriNIC Region origin ASes present in the Internet Routing Table: 565 AfriNIC Prefixes per ASN: 17.48 AfriNIC Region origin ASes announcing only one prefix: 174 AfriNIC Region transit ASes present in the Internet Routing Table: 127 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 43110912 Equivalent to 2 /8s, 145 /16s and 210 /24s Percentage of available AfriNIC address space announced: 42.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 4766 2958 11557 898 Korea Telecom (KIX) 17974 2421 826 46 PT TELEKOMUNIKASI INDONESIA 7545 1789 301 87 TPG Internet Pty Ltd 4755 1614 375 159 TATA Communications formerly 9829 1411 1155 42 BSNL National Internet Backbo 9583 1217 92 529 Sify Limited 7552 1141 1062 11 Vietel Corporation 4808 1111 2056 315 CNCGROUP IP network: China169 24560 1040 385 165 Bharti Airtel Ltd., Telemedia 9498 1021 310 74 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3204 992 191 Windstream Communications Inc 6389 3157 3721 155 bellsouth.net, inc. 18566 2084 382 180 Covad Communications 22773 1942 2931 129 Cox Communications, Inc. 1785 1931 678 126 PaeTec Communications, Inc. 20115 1680 1601 634 Charter Communications 4323 1586 1153 392 Time Warner Telecom 30036 1363 284 766 Mediacom Communications Corp 7018 1279 10276 855 AT&T WorldNet Services 7011 1222 334 692 Citizens Utilities 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 1725 544 16 Corbina telecom 12479 854 777 64 Uni2 Autonomous System 34984 840 210 207 BILISIM TELEKOM 31148 731 37 9 FreeNet ISP 13188 726 93 130 Educational Network 20940 713 230 552 Akamai Technologies European 6830 712 2313 435 UPC Distribution Services 2118 691 97 14 EUnet/RELCOM Autonomous Syste 58113 602 67 365 LIR DATACENTER TELECOM SRL 8551 595 364 61 Bezeq International Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2251 384 208 TVCABLE BOGOTA 28573 2177 1285 65 NET Servicos de Comunicao S.A 7303 1668 1138 201 Telecom Argentina Stet-France 8151 1603 3044 356 UniNet S.A. de C.V. 6503 1538 435 67 AVANTEL, S.A. 27947 748 77 92 Telconet S.A 3816 655 309 69 Empresa Nacional de Telecomun 11172 592 85 68 Servicios Alestra S.A de C.V 18881 587 716 18 Global Village Telecom 22047 579 326 15 VTR PUNTO NET 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 24863 864 274 36 LINKdotNET AS number 36998 606 48 3 MOBITEL 8452 533 958 13 TEDATA 6713 516 650 19 Itissalat Al-MAGHRIB 24835 289 80 8 RAYA Telecom - Egypt 3741 268 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 181 697 88 MTN Network Solutions 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 7029 3204 992 191 Windstream Communications Inc 6389 3157 3721 155 bellsouth.net, inc. 4766 2958 11557 898 Korea Telecom (KIX) 17974 2421 826 46 PT TELEKOMUNIKASI INDONESIA 10620 2251 384 208 TVCABLE BOGOTA 28573 2177 1285 65 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 22773 1942 2931 129 Cox Communications, Inc. 1785 1931 678 126 PaeTec Communications, Inc. 7545 1789 301 87 TPG Internet Pty Ltd 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 3157 3002 bellsouth.net, inc. 17974 2421 2375 PT TELEKOMUNIKASI INDONESIA 28573 2177 2112 NET Servicos de Comunicao S.A 4766 2958 2060 Korea Telecom (KIX) 10620 2251 2043 TVCABLE BOGOTA 18566 2084 1904 Covad Communications 22773 1942 1813 Cox Communications, Inc. 1785 1931 1805 PaeTec Communications, Inc. 8402 1725 1709 Corbina telecom 7545 1789 1702 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59530 UNALLOCATED 5.8.182.0/24 31261 GARS Telecom 61408 UNALLOCATED 5.56.0.0/21 174 Cogent Communication 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.220.94.0/23 42235 Intra Data Communication 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:18 /9:13 /10:29 /11:88 /12:243 /13:479 /14:851 /15:1553 /16:12442 /17:6539 /18:10892 /19:21349 /20:30749 /21:32827 /22:43338 /23:40503 /24:225937 /25:1357 /26:1696 /27:910 /28:179 /29:79 /30:17 /31:0 /32:24 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2643 3204 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1783 3157 bellsouth.net, inc. 8402 1441 1725 Corbina telecom 30036 1279 1363 Mediacom Communications Corp 22773 1272 1942 Cox Communications, Inc. 11492 1145 1180 Cable One 6503 1054 1538 AVANTEL, S.A. 1785 1016 1931 PaeTec Communications, Inc. 7011 957 1222 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:644 2:771 3:1 4:13 5:677 6:3 8:481 12:1956 13:3 14:695 15:11 16:3 17:6 20:27 23:213 24:1778 27:1409 31:1276 32:54 33:2 34:2 36:5 37:949 38:842 39:2 40:139 41:2567 42:179 44:3 46:1657 47:2 49:498 50:606 52:12 54:27 55:3 56:1 57:28 58:1059 59:541 60:237 61:1290 62:924 63:2018 64:4339 65:2201 66:4515 67:2103 68:1164 69:3228 70:933 71:556 72:1895 74:2615 75:483 76:293 77:990 78:1004 79:505 80:1225 81:981 82:619 83:540 84:520 85:1156 86:516 87:958 88:360 89:1753 90:305 91:5327 92:586 93:1467 94:1795 95:1413 96:412 97:323 98:961 99:40 100:31 101:292 103:1798 105:409 106:119 107:203 108:479 109:1642 110:832 111:976 112:436 113:734 114:674 115:880 116:888 117:759 118:959 119:1242 120:363 121:672 122:1729 123:1169 124:1334 125:1285 128:563 129:201 130:292 131:667 132:315 133:143 134:256 135:62 136:218 137:238 138:339 139:174 140:505 141:292 142:496 143:373 144:491 145:83 146:528 147:268 148:737 149:328 150:153 151:215 152:450 153:183 154:21 155:429 156:229 157:370 158:281 159:670 160:337 161:414 162:370 163:191 164:581 165:447 166:480 167:561 168:973 169:130 170:922 171:154 172:7 173:1697 174:636 175:453 176:730 177:1430 178:1662 180:1383 181:170 182:1098 183:301 184:631 185:68 186:2095 187:1412 188:1754 189:1619 190:5802 192:6056 193:5411 194:4288 195:3672 196:1239 197:263 198:3939 199:5095 200:6006 201:1975 202:8791 203:8704 204:4426 205:2542 206:2765 207:2805 208:4071 209:3610 210:2885 211:1530 212:2152 213:1869 214:896 215:75 216:5188 217:1580 218:577 219:312 220:1259 221:531 222:337 223:410 End of report From richard.barnes at gmail.com Fri Nov 16 19:44:22 2012 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 16 Nov 2012 14:44:22 -0500 Subject: "authority" to route? In-Reply-To: <18067.1353088513@turing-police.cc.vt.edu> References: <20121112194346.GE28511@reptiles.org> <18067.1353088513@turing-police.cc.vt.edu> Message-ID: I think Heather was pointing out that this would be a good time to actually use it. On Fri, Nov 16, 2012 at 12:55 PM, wrote: > On Thu, 15 Nov 2012 23:05:39 -0800, Kyle Creyts said: > > Jeez, isn't RPKI supposed to solve this problem? > > That would presume the existence of a deployed system that > everybody actually used. > From cidr-report at potaroo.net Fri Nov 16 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Nov 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201211162200.qAGM00Q6055077@wattle.apnic.net> This report has been generated at Fri Nov 16 21:13:09 2012 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-11-12 432954 250422 10-11-12 432998 250549 11-11-12 433001 250565 12-11-12 433177 250728 13-11-12 433567 250582 14-11-12 433477 251136 15-11-12 433827 251224 16-11-12 434519 251608 AS Summary 42724 Number of ASes in routing system 17781 Number of ASes announcing only one prefix 3204 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 114148320 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 16Nov12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 434723 251534 183189 42.1% All ASes AS6389 3157 159 2998 95.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2178 66 2112 97.0% NET Servicos de Comunicao S.A. AS4766 2963 940 2023 68.3% KIXS-AS-KR Korea Telecom AS17974 2421 530 1891 78.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3204 1494 1710 53.4% WINDSTREAM - Windstream Communications Inc AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS22773 1942 291 1651 85.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2251 863 1388 61.7% Telmex Colombia S.A. AS7303 1668 396 1272 76.3% Telecom Argentina S.A. AS4323 1592 399 1193 74.9% TWTC - tw telecom holdings, inc. AS4755 1614 537 1077 66.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1141 197 944 82.7% VIETEL-AS-AP Vietel Corporation AS8151 1610 702 908 56.4% Uninet S.A. de C.V. AS18101 1016 174 842 82.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS1785 1931 1155 776 40.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1111 348 763 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 862 115 747 86.7% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 705 52 653 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1120 497 623 55.6% LEVEL3 Level 3 Communications AS2118 691 73 618 89.4% RELCOM-AS OOO "NPO Relcom" AS17676 707 89 618 87.4% GIGAINFRA Softbank BB Corp. AS22561 1030 429 601 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1003 404 599 59.7% VZGNI-TRANSIT - Verizon Online LLC AS3549 1040 444 596 57.3% GBLX Global Crossing Ltd. AS24560 1040 444 596 57.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 1804 1230 574 31.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 579 30 549 94.8% VTR BANDA ANCHA S.A. AS4780 843 298 545 64.7% SEEDNET Digital United Inc. AS18881 587 49 538 91.7% Global Village Telecom AS7011 1222 692 530 43.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 45116 13520 31596 70.0% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 Nov 16 22:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Nov 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201211162200.qAGM01KD055092@wattle.apnic.net> BGP Update Report Interval: 08-Nov-12 -to- 15-Nov-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS12880 77630 3.9% 575.0 -- DCI-AS Information Technology Company (ITC) 2 - AS31692 53761 2.7% 6720.1 -- SATURN-R-AS OOO Saturn-R 3 - AS8402 44968 2.2% 12.2 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS9829 38547 1.9% 53.8 -- BSNL-NIB National Internet Backbone 5 - AS3909 37913 1.9% 3791.3 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - AS28263 22803 1.1% 1425.2 -- 7 - AS22561 22678 1.1% 157.5 -- DIGITAL-TELEPORT - Digital Teleport Inc. 8 - AS6458 21553 1.1% 74.1 -- Telgua 9 - AS13118 17664 0.9% 360.5 -- ASN-YARTELECOM OJSC Rostelecom 10 - AS22833 14319 0.7% 143.2 -- CTE S.A. de C.V. 11 - AS14754 14275 0.7% 140.0 -- Telgua 12 - AS27738 13836 0.7% 24.8 -- Ecuadortelecom S.A. 13 - AS2708 13331 0.7% 97.3 -- Universidad de Guanajuato 14 - AS3216 12448 0.6% 28.2 -- SOVAM-AS OJSC "Vimpelcom" 15 - AS2386 12189 0.6% 75.7 -- INS-AS - AT&T Data Communications Services 16 - AS6503 12054 0.6% 18.3 -- Axtel, S.A.B. de C.V. 17 - AS11492 11824 0.6% 33.5 -- CABLEONE - CABLE ONE, INC. 18 - AS17974 11800 0.6% 17.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS1637 11712 0.6% 131.6 -- DNIC-AS-01637 - Headquarters, USAISC 20 - AS37023 11555 0.6% 5777.5 -- OCEANICBNK TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS21599 9697 0.5% 9697.0 -- NETDIRECT S.A. 2 - AS31692 53761 2.7% 6720.1 -- SATURN-R-AS OOO Saturn-R 3 - AS37023 11555 0.6% 5777.5 -- OCEANICBNK 4 - AS21684 4230 0.2% 4230.0 -- CYBERINETBGP - Cyberonics, Inc. 5 - AS19406 4207 0.2% 4207.0 -- TWRS-MA - Towerstream I, Inc. 6 - AS3909 37913 1.9% 3791.3 -- QWEST-AS-3908 - Qwest Communications Company, LLC 7 - AS37426 3751 0.2% 3751.0 -- Amcon 8 - AS6629 6848 0.3% 3424.0 -- NOAA-AS - NOAA 9 - AS50478 4994 0.2% 2497.0 -- BVOX BVOX AS 10 - AS14680 7154 0.4% 2384.7 -- REALE-6 - Auction.com 11 - AS293 2369 0.1% 2369.0 -- ESNET - ESnet 12 - AS6197 2045 0.1% 2045.0 -- BATI-ATL - BellSouth Network Solutions, Inc 13 - AS55410 9052 0.5% 1810.4 -- VODAFONE-NET-AS-AP C48 Okhla Industrial Estate, New Delhi-110020 14 - AS43695 1601 0.1% 1601.0 -- LISNER_AS UNIQ LISNER Sp. z o.o. 15 - AS28263 22803 1.1% 1425.2 -- 16 - AS36529 2504 0.1% 1252.0 -- AXXA-RACKCO - Rackco.com 17 - AS57918 956 0.1% 956.0 -- ACOD-AS ACOD CJSC 18 - AS38278 1838 0.1% 919.0 -- VTELECOMNET-MY-AP VTelecoms Berhad - Metro Ethernet LL and Internet Service Provider, Malaysia 19 - AS44532 840 0.0% 840.0 -- WAPTAK-AS WapTak Ltd. 20 - AS2 828 0.0% 1076.0 -- SOCGEN-HK 7/F, Three Pacific Place TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 16662 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 2.184.219.0/24 15050 0.7% AS12880 -- DCI-AS Information Technology Company (ITC) 3 - 78.39.108.0/24 15032 0.7% AS12880 -- DCI-AS Information Technology Company (ITC) 4 - 217.219.249.0/24 15029 0.7% AS12880 -- DCI-AS Information Technology Company (ITC) 5 - 2.184.218.0/24 14884 0.7% AS12880 -- DCI-AS Information Technology Company (ITC) 6 - 2.184.217.0/24 14882 0.7% AS12880 -- DCI-AS Information Technology Company (ITC) 7 - 178.161.166.0/24 13421 0.6% AS31692 -- SATURN-R-AS OOO Saturn-R 8 - 178.161.174.0/24 13419 0.6% AS31692 -- SATURN-R-AS OOO Saturn-R 9 - 178.161.163.0/24 13419 0.6% AS31692 -- SATURN-R-AS OOO Saturn-R 10 - 178.161.162.0/24 13417 0.6% AS31692 -- SATURN-R-AS OOO Saturn-R 11 - 151.118.255.0/24 12634 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 12 - 151.118.254.0/24 12634 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 13 - 151.118.18.0/24 12624 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 14 - 184.159.130.0/23 11056 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 15 - 184.157.224.0/19 10903 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 16 - 200.46.0.0/19 9697 0.5% AS21599 -- NETDIRECT S.A. 17 - 41.203.108.0/24 5778 0.3% AS37023 -- OCEANICBNK 18 - 41.203.109.0/24 5777 0.3% AS37023 -- OCEANICBNK 19 - 12.139.133.0/24 5692 0.3% AS14680 -- REALE-6 - Auction.com 20 - 187.17.172.0/22 5565 0.3% AS28263 -- 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 randy at psg.com Sat Nov 17 08:42:20 2012 From: randy at psg.com (Randy Bush) Date: Sat, 17 Nov 2012 15:42:20 +0700 Subject: new clueless security softwhere References: Message-ID: new crapware on the misconfigured loose. did we not just have a thread on frags? how long will it take the amateurs to learn about port 53? sigh randy Date: Sat, 17 Nov 2012 16:15:23 +0800 To: randy at psg.com From: Security Ops Center Subject: Network abuse from attacker: 147.28.0.39 to 203.124.10.107(ID# 86329) Message-ID: Dear Sir, We detected an attack/abuse to our network that come from an IP owned by your ASN. The IP of your network [ 147.28.0.39 ] was infected and sending attack to our network [ 203.124.10.107 ]. The following is the logs that you can take proper actions. [TimeZone: GMT +8] ================================================== 2012-11-17 20:21:30 Fragmented traffic! From 147.28.0.39:53 to 203.124.9.11:56958, 2012-11-17 20:37:56 Fragmented traffic! From 147.28.0.39:53 to 203.124.10.223:39843, 2012-11-17 20:37:56 Fragmented traffic! From 147.28.0.39:3600 to 203.124.10.223:20678, ... ================================================== Should you have any questions, please call us at +(852) 29980833. Please include the ticket number, ID#86329, in all communications on this issue. Thank you, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Ops Center - CommuniLink Internet Limited. security at communilink.net http://www.communilink.net 852.2998.0833 (voice) 852.2998.0899 (fax) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From mhernand1 at comcast.net Sat Nov 17 15:51:27 2012 From: mhernand1 at comcast.net (Manolo Hernandez) Date: Sat, 17 Nov 2012 10:51:27 -0500 Subject: new clueless security softwhere In-Reply-To: References: Message-ID: <50A7B27F.5070807@comcast.net> LOL On 11/17/12 3:42 AM, Randy Bush wrote: > new crapware on the misconfigured loose. did we not just have a thread > on frags? how long will it take the amateurs to learn about port 53? > > sigh > > randy > > > Date: Sat, 17 Nov 2012 16:15:23 +0800 > To: randy at psg.com > From: Security Ops Center > Subject: Network abuse from attacker: 147.28.0.39 to 203.124.10.107(ID# 86329) > Message-ID: > > Dear Sir, > > We detected an attack/abuse to our network that come from an IP owned by your ASN. > The IP of your network [ 147.28.0.39 ] was infected and sending attack to our network [ 203.124.10.107 ]. > > The following is the logs that you can take proper actions. [TimeZone: GMT +8] > ================================================== > 2012-11-17 20:21:30 Fragmented traffic! From 147.28.0.39:53 to 203.124.9.11:56958, > 2012-11-17 20:37:56 Fragmented traffic! From 147.28.0.39:53 to 203.124.10.223:39843, > 2012-11-17 20:37:56 Fragmented traffic! From 147.28.0.39:3600 to 203.124.10.223:20678, > ... > > ================================================== > > Should you have any questions, please call us at +(852) 29980833. > Please include the ticket number, ID#86329, in all communications on this issue. > > Thank you, > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Security Ops Center - CommuniLink Internet Limited. > security at communilink.net > http://www.communilink.net > 852.2998.0833 (voice) 852.2998.0899 (fax) > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > From bruns at 2mbit.com Sat Nov 17 20:27:07 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 17 Nov 2012 13:27:07 -0700 Subject: new clueless security softwhere In-Reply-To: References: Message-ID: <50A7F31B.3030700@2mbit.com> On 11/17/12 1:42 AM, Randy Bush wrote: > new crapware on the misconfigured loose. did we not just have a thread > on frags? how long will it take the amateurs to learn about port 53? > > sigh > > randy > > > Date: Sat, 17 Nov 2012 16:15:23 +0800 > To: randy at psg.com > From: Security Ops Center True call: "ZoneAlarm is telling me that your internet server is attacking my computer on port 53 with something called UDP. I told it to not allow the attack and now my internet doesn't work!" Don't know which is more funny - the broken/braindead software, or the fact its coming from a location of the world where the average response to abuse reports is "SPAM NO ILLEGAL, YOU NO BLOCK US." -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From branto at networking-architecture.com Sat Nov 17 21:20:04 2012 From: branto at networking-architecture.com (Brant I. Stevens) Date: Sat, 17 Nov 2012 22:20:04 +0100 Subject: In Need of 10GbE Optics @AMS4 Message-ID: Please forgive the cross-post, but figured this was the best way to reach my target audiences. I am onsite and in need of: -8 10GbE Single-Mode SFP's. -4 10GbE Single-Mode XFPs. If you have them available for sale, that would be great, but pointing us in the direction of where to obtain them in-country, quickly, would be very useful as well. Regards, - Brant aim:branto From pashdown at xmission.com Sun Nov 18 04:00:48 2012 From: pashdown at xmission.com (Pete Ashdown) Date: Sat, 17 Nov 2012 21:00:48 -0700 Subject: In Need of 10GbE Optics @AMS4 In-Reply-To: References: Message-ID: <50A85D70.3010000@xmission.com> I don't have the quantity you need, but this reminded me that I'm in need of a reliable supplier of CWDM 40KM XFP 10GbE optics. Specifically 1310nm, but I'll need other wavelengths soon. These things seem to be manufactured by elves. I can't find a reliable supplier anywhere. Can anyone help? On 11/17/12 2:20 PM, Brant I. Stevens wrote: > Please forgive the cross-post, but figured this was the best way to reach > my target audiences. I am onsite and in need of: > > -8 10GbE Single-Mode SFP's. > -4 10GbE Single-Mode XFPs. > > If you have them available for sale, that would be great, but pointing us > in the direction of where to obtain them in-country, quickly, would be very > useful as well. > > Regards, > - Brant > aim:branto > From kuenzler at init7.net Sun Nov 18 09:55:16 2012 From: kuenzler at init7.net (Fredy Kuenzler) Date: Sun, 18 Nov 2012 10:55:16 +0100 Subject: In Need of 10GbE Optics @AMS4 In-Reply-To: <50A85D70.3010000@xmission.com> References: <50A85D70.3010000@xmission.com> Message-ID: <11CBE0C5-68DE-43E9-A262-F1366C36040E@init7.net> I guess the Flexoptix experts are able to adress this problem... http://www.flexoptix.net/ HTH, Fredy / Init7 Von meinem iPhone gesendet Am 18.11.2012 um 05:00 schrieb Pete Ashdown : > I don't have the quantity you need, but this reminded me that I'm in > need of a reliable supplier of CWDM 40KM XFP 10GbE optics. Specifically > 1310nm, but I'll need other wavelengths soon. These things seem to be > manufactured by elves. I can't find a reliable supplier anywhere. Can > anyone help? > From ebais at a2b-internet.com Sun Nov 18 10:12:49 2012 From: ebais at a2b-internet.com (Erik Bais) Date: Sun, 18 Nov 2012 11:12:49 +0100 Subject: In Need of 10GbE Optics @AMS4 In-Reply-To: References: Message-ID: <88E978C3-875E-41C8-9F4D-4F8039AE10E1@a2b-internet.com> You could contact Solid Optics in The Netherlands. Contact : wouter AT solid-optics.eu Regards, Erik Bais Verstuurd vanaf mijn iPad Op 17 nov. 2012 om 22:20 heeft "Brant I. Stevens" het volgende geschreven: > Please forgive the cross-post, but figured this was the best way to reach > my target audiences. I am onsite and in need of: > > -8 10GbE Single-Mode SFP's. > -4 10GbE Single-Mode XFPs. > > If you have them available for sale, that would be great, but pointing us > in the direction of where to obtain them in-country, quickly, would be very > useful as well. > > Regards, > - Brant > aim:branto From tammy-lists at wiztech.biz Sun Nov 18 10:30:37 2012 From: tammy-lists at wiztech.biz (Tammy A Wisdom) Date: Sun, 18 Nov 2012 03:30:37 -0700 Subject: In Need of 10GbE Optics @AMS4 In-Reply-To: <11CBE0C5-68DE-43E9-A262-F1366C36040E@init7.net> References: <50A85D70.3010000@xmission.com> <11CBE0C5-68DE-43E9-A262-F1366C36040E@init7.net> Message-ID: Also terabit systems has an office in Amsterdam http://www.terabitsystems.com/ I know they definitely have optics there :) Sent from my iPhone On Nov 18, 2012, at 2:55, Fredy Kuenzler wrote: > I guess the Flexoptix experts are able to adress this problem... > http://www.flexoptix.net/ > > HTH, Fredy / Init7 > > Von meinem iPhone gesendet > > Am 18.11.2012 um 05:00 schrieb Pete Ashdown : > >> I don't have the quantity you need, but this reminded me that I'm in >> need of a reliable supplier of CWDM 40KM XFP 10GbE optics. Specifically >> 1310nm, but I'll need other wavelengths soon. These things seem to be >> manufactured by elves. I can't find a reliable supplier anywhere. Can >> anyone help? > From rinse.kloek at isp.solcon.nl Sun Nov 18 11:09:31 2012 From: rinse.kloek at isp.solcon.nl (Rinse Kloek) Date: Sun, 18 Nov 2012 12:09:31 +0100 Subject: In Need of 10GbE Optics @AMS4 Message-ID: <1fo4tldchhq9jm9cwnnh838j.1353236971960@email.android.com> +1 :) Erik Bais schreef:You could contact Solid Optics in The Netherlands. Contact : wouter AT solid-optics.eu Regards, Erik Bais Verstuurd vanaf mijn iPad Op 17 nov. 2012 om 22:20 heeft "Brant I. Stevens" het volgende geschreven: > Please forgive the cross-post, but figured this was the best way to reach > my target audiences.? I am onsite and in need of: > > -8 10GbE Single-Mode SFP's. > -4 10GbE Single-Mode XFPs. > > If you have them available for sale, that would be great, but pointing us > in the direction of where to obtain them in-country, quickly, would be very > useful as well. > > Regards, > - Brant > aim:branto From arnold at nipper.de Sun Nov 18 13:18:39 2012 From: arnold at nipper.de (Arnold Nipper) Date: Sun, 18 Nov 2012 14:18:39 +0100 Subject: In Need of 10GbE Optics @AMS4 In-Reply-To: <50A85D70.3010000@xmission.com> References: <50A85D70.3010000@xmission.com> Message-ID: <50A8E02F.9080707@nipper.de> On 18.11.2012 05:00, Pete Ashdown wrote: > I don't have the quantity you need, but this reminded me that I'm in > need of a reliable supplier of CWDM 40KM XFP 10GbE optics. Specifically > 1310nm, but I'll need other wavelengths soon. These things seem to be > manufactured by elves. I can't find a reliable supplier anywhere. Can > anyone help? > try http://www.cubeoptics.com/en/ ... well established since years, not only selling transceivers but also manufacturing muxes and other opticals stuff. If you need a contact let me know. If anyone is in need of DWDM 40km XFP next year, I have hundreds of them available Best regards Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 152 53717690 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From shortdudey123 at gmail.com Sun Nov 18 20:12:43 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 18 Nov 2012 14:12:43 -0600 Subject: Apple iMessage Message-ID: Hi, Is anyone having trouble with apples iMessage service? A friend and I are in Wisconsin and Illinois respectfully and messages via iMessage are taking up to several minutes to send. I am using a 4s on iOS 5 and my friend is using a 3GS. Thanks Grant From mikeal.clark at gmail.com Sun Nov 18 20:17:37 2012 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Sun, 18 Nov 2012 14:17:37 -0600 Subject: Apple iMessage In-Reply-To: References: Message-ID: I'm having issues as well on my iPhone 5. (Wi) On Sun, Nov 18, 2012 at 2:12 PM, Grant Ridder wrote: > Hi, > > Is anyone having trouble with apples iMessage service? A friend and I are > in Wisconsin and Illinois respectfully and messages via iMessage are taking > up to several minutes to send. I am using a 4s on iOS 5 and my friend is > using a 3GS. > > Thanks > Grant From jason at biel-tech.com Sun Nov 18 20:19:55 2012 From: jason at biel-tech.com (Jason Biel) Date: Sun, 18 Nov 2012 14:19:55 -0600 Subject: Apple iMessage In-Reply-To: References: Message-ID: Issues in FL as well. On Sun, Nov 18, 2012 at 2:17 PM, Mikeal Clark wrote: > I'm having issues as well on my iPhone 5. (Wi) > > On Sun, Nov 18, 2012 at 2:12 PM, Grant Ridder > wrote: > > Hi, > > > > Is anyone having trouble with apples iMessage service? A friend and I > are > > in Wisconsin and Illinois respectfully and messages via iMessage are > taking > > up to several minutes to send. I am using a 4s on iOS 5 and my friend is > > using a 3GS. > > > > Thanks > > Grant > > -- Jason From litt.matt at gmail.com Sun Nov 18 20:28:39 2012 From: litt.matt at gmail.com (Matthew Litt) Date: Sun, 18 Nov 2012 12:28:39 -0800 Subject: Apple iMessage In-Reply-To: References: Message-ID: <7B16DE99-526F-4B1A-902E-7CCE5ADB4F16@gmail.com> Having same issues in Los Angeles. iMessages are failing. On Nov 18, 2012, at 12:19 PM, Jason Biel wrote: > Issues in FL as well. > > On Sun, Nov 18, 2012 at 2:17 PM, Mikeal Clark wrote: > >> I'm having issues as well on my iPhone 5. (Wi) >> >> On Sun, Nov 18, 2012 at 2:12 PM, Grant Ridder >> wrote: >>> Hi, >>> >>> Is anyone having trouble with apples iMessage service? A friend and I >> are >>> in Wisconsin and Illinois respectfully and messages via iMessage are >> taking >>> up to several minutes to send. I am using a 4s on iOS 5 and my friend is >>> using a 3GS. >>> >>> Thanks >>> Grant >> >> > > > -- > Jason From waqqasahmed at gmail.com Sun Nov 18 20:30:58 2012 From: waqqasahmed at gmail.com (Syed W Ahmed) Date: Sun, 18 Nov 2012 12:30:58 -0800 Subject: Apple iMessage In-Reply-To: References: Message-ID: In canada. Same issue now imessage activation failing. Sent from my iPhone On Nov 18, 2012, at 12:19 PM, Jason Biel wrote: > Issues in FL as well. > > On Sun, Nov 18, 2012 at 2:17 PM, Mikeal Clark wrote: > >> I'm having issues as well on my iPhone 5. (Wi) >> >> On Sun, Nov 18, 2012 at 2:12 PM, Grant Ridder >> wrote: >>> Hi, >>> >>> Is anyone having trouble with apples iMessage service? A friend and I >> are >>> in Wisconsin and Illinois respectfully and messages via iMessage are >> taking >>> up to several minutes to send. I am using a 4s on iOS 5 and my friend is >>> using a 3GS. >>> >>> Thanks >>> Grant > > > -- > Jason From curtis at generous.com Sun Nov 18 20:36:14 2012 From: curtis at generous.com (Curtis Generous) Date: Sun, 18 Nov 2012 15:36:14 -0500 Subject: Apple iMessage In-Reply-To: Message-ID: Issues in Northern Virginia as well.. On 11/18/12 3:30 PM, "Syed W Ahmed" wrote: >In canada. Same issue now imessage activation failing. > > >Sent from my iPhone > >On Nov 18, 2012, at 12:19 PM, Jason Biel wrote: > >> Issues in FL as well. >> >> On Sun, Nov 18, 2012 at 2:17 PM, Mikeal Clark >>wrote: >> >>> I'm having issues as well on my iPhone 5. (Wi) >>> >>> On Sun, Nov 18, 2012 at 2:12 PM, Grant Ridder >>> wrote: >>>> Hi, >>>> >>>> Is anyone having trouble with apples iMessage service? A friend and I >>> are >>>> in Wisconsin and Illinois respectfully and messages via iMessage are >>> taking >>>> up to several minutes to send. I am using a 4s on iOS 5 and my >>>>friend is >>>> using a 3GS. >>>> >>>> Thanks >>>> Grant >> >> >> -- >> Jason > From contact at nullivex.com Sun Nov 18 20:40:24 2012 From: contact at nullivex.com (Bryan Tong) Date: Sun, 18 Nov 2012 13:40:24 -0700 Subject: Apple iMessage In-Reply-To: References: Message-ID: Down in Colorado as well. On Sun, Nov 18, 2012 at 1:36 PM, Curtis Generous wrote: > Issues in Northern Virginia as well.. > > On 11/18/12 3:30 PM, "Syed W Ahmed" wrote: > >>In canada. Same issue now imessage activation failing. >> >> >>Sent from my iPhone >> >>On Nov 18, 2012, at 12:19 PM, Jason Biel wrote: >> >>> Issues in FL as well. >>> >>> On Sun, Nov 18, 2012 at 2:17 PM, Mikeal Clark >>>wrote: >>> >>>> I'm having issues as well on my iPhone 5. (Wi) >>>> >>>> On Sun, Nov 18, 2012 at 2:12 PM, Grant Ridder >>>> wrote: >>>>> Hi, >>>>> >>>>> Is anyone having trouble with apples iMessage service? A friend and I >>>> are >>>>> in Wisconsin and Illinois respectfully and messages via iMessage are >>>> taking >>>>> up to several minutes to send. I am using a 4s on iOS 5 and my >>>>>friend is >>>>> using a 3GS. >>>>> >>>>> Thanks >>>>> Grant >>> >>> >>> -- >>> Jason >> > > > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From cferguson at nepc.com Sun Nov 18 20:17:56 2012 From: cferguson at nepc.com (Ferguson, Chris) Date: Sun, 18 Nov 2012 20:17:56 +0000 Subject: Apple iMessage In-Reply-To: References: Message-ID: <5A08108A-86B0-4D7A-BE75-5FF334FA9D82@nepc.com> I'm experiencing the same issue. Chris Ferguson Systems and Network Administrator | NEPC, LLC 617-395-7329 Sent from my iPhone On Nov 18, 2012, at 3:13 PM, "Grant Ridder" wrote: > Hi, > > Is anyone having trouble with apples iMessage service? A friend and I are > in Wisconsin and Illinois respectfully and messages via iMessage are taking > up to several minutes to send. I am using a 4s on iOS 5 and my friend is > using a 3GS. > > Thanks > Grant > From zaid.hammoudi at gmail.com Sun Nov 18 21:37:22 2012 From: zaid.hammoudi at gmail.com (Zaid Hammoudi) Date: Sun, 18 Nov 2012 14:37:22 -0700 Subject: Apple iMessage In-Reply-To: References: Message-ID: <4973808634057318185@unknownmsgid> Seeing the same thing here in Edmonton AB. Sent from my iPhone On 2012-11-18, at 1:13 PM, Grant Ridder wrote: > Hi, > > Is anyone having trouble with apples iMessage service? A friend and I are > in Wisconsin and Illinois respectfully and messages via iMessage are taking > up to several minutes to send. I am using a 4s on iOS 5 and my friend is > using a 3GS. > > Thanks > Grant From snoble at sonn.com Sun Nov 18 21:56:18 2012 From: snoble at sonn.com (Steven Noble) Date: Sun, 18 Nov 2012 13:56:18 -0800 Subject: Apple iMessage In-Reply-To: <4973808634057318185@unknownmsgid> References: <4973808634057318185@unknownmsgid> Message-ID: It came back for me.. was doing txt messages between iPhones but now iMessage but delayed. On Nov 18, 2012, at 1:37 PM, Zaid Hammoudi wrote: > Seeing the same thing here in Edmonton AB. > > Sent from my iPhone > > On 2012-11-18, at 1:13 PM, Grant Ridder wrote: > >> Hi, >> >> Is anyone having trouble with apples iMessage service? A friend and I are >> in Wisconsin and Illinois respectfully and messages via iMessage are taking >> up to several minutes to send. I am using a 4s on iOS 5 and my friend is >> using a 3GS. >> >> Thanks >> Grant > From khomyakov.andrey at gmail.com Sun Nov 18 22:39:54 2012 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Sun, 18 Nov 2012 17:39:54 -0500 Subject: Apple iMessage In-Reply-To: References: <4973808634057318185@unknownmsgid> Message-ID: Still out for me in MA and a friend in IL --Andrey On Sun, Nov 18, 2012 at 4:56 PM, Steven Noble wrote: > It came back for me.. was doing txt messages between iPhones but now > iMessage but delayed. > On Nov 18, 2012, at 1:37 PM, Zaid Hammoudi > wrote: > > > Seeing the same thing here in Edmonton AB. > > > > Sent from my iPhone > > > > On 2012-11-18, at 1:13 PM, Grant Ridder wrote: > > > >> Hi, > >> > >> Is anyone having trouble with apples iMessage service? A friend and I > are > >> in Wisconsin and Illinois respectfully and messages via iMessage are > taking > >> up to several minutes to send. I am using a 4s on iOS 5 and my friend > is > >> using a 3GS. > >> > >> Thanks > >> Grant > > > > > From danny at danysek.cz Sun Nov 18 22:47:33 2012 From: danny at danysek.cz (Daniel Suchy) Date: Sun, 18 Nov 2012 23:47:33 +0100 Subject: Google/Youtube problems Message-ID: <50A96585.5010304@danysek.cz> Hello, for approx. last 14 days we're seeing problems with video playing from youtube (page loads without problems, but player shows error), and also other applications like maps are having problems. As these problems were only for some of prefixes announced out of AS 8251, we recognised that as problem with Google's CDN and reported it to Google. As workaround, filtering affected prefixes from peering in Prague partially helped. We already tried communicate problem with Google from the beginning (in our network, around 50000 end users are directly afected), and they're claiming, that problem is related only to our network and there's no global issue. But similar issues we're seeing from some other networks, which are peering with Google and have nothing common with our AS8251. We sent emails to Google NOC/NST, also tried to phone them about the problems, but according to end-user claims, problem persist. Problem is isolated only to peak hours, when something seems to be saturated. If I recall past optional IPv6 from Google, they said: "It is very important to us that our users always receive the best possible experience". But majority of end users still uses IPv4 and we're seeing problems here - and response is minimal. At least information about cause of the problem and expected time for problem resolution. Is anyone else seeing similar problems with Google/Youtube? With regards, Daniel From ben.brown at sunlessinc.com Sun Nov 18 21:25:34 2012 From: ben.brown at sunlessinc.com (BEN BROWN) Date: Sun, 18 Nov 2012 21:25:34 +0000 Subject: Apple iMessage In-Reply-To: References: , Message-ID: <7453A345-2988-433E-A585-53DF75AE3963@sunlessinc.com> Correct, down in Ohio. -Ben Brown On Nov 18, 2012, at 3:42 PM, "Bryan Tong" wrote: > Down in Colorado as well. > > On Sun, Nov 18, 2012 at 1:36 PM, Curtis Generous wrote: >> Issues in Northern Virginia as well.. >> >> On 11/18/12 3:30 PM, "Syed W Ahmed" wrote: >> >>> In canada. Same issue now imessage activation failing. >>> >>> >>> Sent from my iPhone >>> >>> On Nov 18, 2012, at 12:19 PM, Jason Biel wrote: >>> >>>> Issues in FL as well. >>>> >>>> On Sun, Nov 18, 2012 at 2:17 PM, Mikeal Clark >>>> wrote: >>>> >>>>> I'm having issues as well on my iPhone 5. (Wi) >>>>> >>>>> On Sun, Nov 18, 2012 at 2:12 PM, Grant Ridder >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> Is anyone having trouble with apples iMessage service? A friend and I >>>>> are >>>>>> in Wisconsin and Illinois respectfully and messages via iMessage are >>>>> taking >>>>>> up to several minutes to send. I am using a 4s on iOS 5 and my >>>>>> friend is >>>>>> using a 3GS. >>>>>> >>>>>> Thanks >>>>>> Grant >>>> >>>> >>>> -- >>>> Jason >>> >> >> >> > > > > -- > -------------------- > Bryan Tong > Nullivex LLC | eSited LLC > (507) 298-1624 > From mureninc at gmail.com Sun Nov 18 22:53:47 2012 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sun, 18 Nov 2012 14:53:47 -0800 Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker Message-ID: Dear NANOG@, I came across an interesting problem in trying to find an affordable KVM provider with IPv6 support. It seems like several rather major and reputable providers in the value sector do claim to have IPv6 support, but once you get your IPv6 addresses or subnets from them, you might be rather disappointed. == Example of edis.at == edis.at gives you an IPv4 address of, for example, 158.255.21x.xxx, and the IPv6 /112 that you get is 2a03:f80:ed15:158:255:21x:xxx:0/112 (really a /48), with 2a03:0f80:ed15::1 as the gateway. I've tried contacting them in an effort to receive any kind of a "proper" IPv6 address without the plaintext IPv4 embedment, but they've given me all sorts of crazy and (IMHO) far-sketched excuses; from not wanting to maintain a separate database of IPv6 addresses/subnets, and from lack of software provisioning support; to supposedly RIPE and/or edis' upstream providers requiring public whois entries for any /64's that edis.at would allocate for their customers, and to not having control of the underlying routers/switches/firewalls in any but one of their 13+ datacentres that thus makes creating 2^16 separate routes problematic. ??? All I'm asking for, are sane and short addresses and/or a saner /112, don't really care if it's still a shared /48 underneath. == Example of buyvm.net == On the other hand, buyvm.net claims to give you 16 IPv6 addresses. This is the kind of addresses that they give out (some consecutive 4 out of the 16 provided addresses listed): 2607:f358:0001:fed5:0022:a124:fe56:xxxx, 2607:f358:0001:fed5:0022:f6a6:dffe:xxxx, 2607:f358:0001:fed5:0022:c6a3:7826:xxxx, 2607:f358:0001:fed5:0022:654f:964d:xxxx. This is the response I've got from buyvm.net when trying to ask for some reasonable (shorter) addresses or a whole subnet instead: << We cannot offer that at this time as we have to store these IPs in MySQL which would slow down the database. >> WTF? Surely offering some 16 random addresses that are 128-bits long doesn't slow down MySQL, but offering one single, short and abbreviatable /64 or /112 subnet would. I'm puzzled! == == (HE's tunnelbroker.net, on the other hand, has no problem in giving out IPv6 addresses that, when abbreviated, can be represented by the same number of ASCII characters as an IPv4 address; for free, might I add.) == == Am _I_ supposed to have a MySQL database with the list of the IPv6 addresses that my virtual private servers have been assigned? Wouldn't it "slow down MySQL", so to speak? :-) What's your take on this? Since IPv6 is still a very low priority for many of the hosting providers (edis.at cited a rather negligible amount of IPv6 traffic, so, they argue that, as a small shop, they simply can't justify spending much R&D on further improving something that they consider already supported and not broken in the first place), would I be crazy to opt-out of such pathetic IPv6 support, and sign back up with a tunnelbroker from HE.net instead? (In fact, my preliminary tests show that IPv6 latency between Austria and Fremont, London and Moscow are either the same or slightly better when using the HE.net tunnelbroker in Prague, instead of edis.at native IPv6 support; bandwidth doesn't seem to be affected, either.) A little extra latency (only potentially) and MTU reduction by 20 bytes are the only negatives, right? Yet on the positive side, I'll get a proper and short /64 or /48 subnet, proper rDNS support, guaranteed proper intermediate hops with proper rDNS entries and no stupid hops impeding traceroute, potentially much better IPv6 routing/peering/latency, and short or custom ...:face:b00c::-style addresses to my liking; and, last but not least, a higher number of potential KVM providers to choose from, since I wouldn't require any native IPv6 support with such an arrangement. Comparing these options, seems like on the KVM hoster side, a blanket "IPv6 support" (with no /48 or /64 promises) is thus basically a useless concept anyways, and, at this time, should not even be sought? Any thoughts? Did I miss anything? In summary, I thought I have to have native IPv6 support in any new VPS that I buy, but looks like using a tunnelbroker might just be a much cleaner and better solution anyways. P.S. Does anyone other than me object to calling /48 subnets with allocations such as 2a03:f80:ed15:158:255:21x:xxx:0/112 as native IPv6 in this context of VPS hosting? How should such addresses/subnets/arrangements be called? Best regards, Constantine. From dougb at dougbarton.us Sun Nov 18 23:50:36 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 18 Nov 2012 15:50:36 -0800 Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: References: Message-ID: <50A9744C.2090000@dougbarton.us> On 11/18/2012 02:53 PM, Constantine A. Murenin wrote: > All I'm asking for, are sane and short addresses and/or a saner /112, > don't really care if it's still a shared /48 underneath. How do you define "sane," and why do you care? Doug From apishdadi at gmail.com Sun Nov 18 23:55:14 2012 From: apishdadi at gmail.com (A. Pishdadi) Date: Sun, 18 Nov 2012 17:55:14 -0600 Subject: Apple iMessage In-Reply-To: References: <4973808634057318185@unknownmsgid> Message-ID: not only issues, but getting messages that were either not directed to me or delivered weeks late, my girlfriend downstairs just got a text from me that i didnt sent, said it was sent at 10am this morning, but i never sent her a message at that time or a message ever in a sentence the way it was worded...... On Sun, Nov 18, 2012 at 4:39 PM, Andrey Khomyakov < khomyakov.andrey at gmail.com> wrote: > Still out for me in MA and a friend in IL > > > --Andrey > > > On Sun, Nov 18, 2012 at 4:56 PM, Steven Noble wrote: > > > It came back for me.. was doing txt messages between iPhones but now > > iMessage but delayed. > > On Nov 18, 2012, at 1:37 PM, Zaid Hammoudi > > wrote: > > > > > Seeing the same thing here in Edmonton AB. > > > > > > Sent from my iPhone > > > > > > On 2012-11-18, at 1:13 PM, Grant Ridder > wrote: > > > > > >> Hi, > > >> > > >> Is anyone having trouble with apples iMessage service? A friend and I > > are > > >> in Wisconsin and Illinois respectfully and messages via iMessage are > > taking > > >> up to several minutes to send. I am using a 4s on iOS 5 and my friend > > is > > >> using a 3GS. > > >> > > >> Thanks > > >> Grant > > > > > > > > > > From aewhale at ABS-CompTech.com Sun Nov 18 23:59:33 2012 From: aewhale at ABS-CompTech.com (Albert Whale) Date: Sun, 18 Nov 2012 18:59:33 -0500 Subject: Apple iMessage In-Reply-To: References: Message-ID: Issues as well in Pittsburgh, PA Sent from my iPhone On Nov 18, 2012, at 3:12 PM, Grant Ridder wrote: > Hi, > > Is anyone having trouble with apples iMessage service? A friend and I are > in Wisconsin and Illinois respectfully and messages via iMessage are taking > up to several minutes to send. I am using a 4s on iOS 5 and my friend is > using a 3GS. > > Thanks > Grant From sander at steffann.nl Mon Nov 19 00:04:37 2012 From: sander at steffann.nl (Sander Steffann) Date: Mon, 19 Nov 2012 01:04:37 +0100 Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: References: Message-ID: <452C2619-9BB6-40C6-A4AA-0A031E0299D2@steffann.nl> Hi, > I've tried contacting them in an effort to receive any kind of a > "proper" IPv6 address without the plaintext IPv4 embedment, but > they've given me all sorts of crazy and (IMHO) far-sketched excuses; > from not wanting to maintain a separate database of IPv6 > addresses/subnets, and from lack of software provisioning support; to > supposedly RIPE and/or edis' upstream providers requiring public whois > entries for any /64's that edis.at would allocate for their customers I can guarantee you that RIPE does *not* require public whois records for individual /64s (or even for separate /48s in PA space). - Sander From bross at pobox.com Mon Nov 19 00:05:23 2012 From: bross at pobox.com (Brandon Ross) Date: Sun, 18 Nov 2012 19:05:23 -0500 (EST) Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: References: Message-ID: On Sun, 18 Nov 2012, Constantine A. Murenin wrote: > I came across an interesting problem in trying to find an affordable > KVM provider with IPv6 support. Does "affordable" mean cheap?... > I've tried contacting them in an effort to receive any kind of a > "proper" IPv6 address without the plaintext IPv4 embedment, but > they've given me all sorts of crazy and (IMHO) far-sketched excuses; So you've contacted cheapo providers and you are now surprised that they can't afford to hire people who know what they are talking about? > (HE's tunnelbroker.net, on the other hand, has no problem in giving > out IPv6 addresses that, when abbreviated, can be represented by the > same number of ASCII characters as an IPv4 address; for free, might I > add.) Clearly HE has people who know what they are doing when it comes to IPv6, probably because they have made a MAJOR investment in both people and infrastructure to do so. Explain again why you aren't using HE for your services? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From Bryan at bryanfields.net Mon Nov 19 00:08:06 2012 From: Bryan at bryanfields.net (Bryan Fields) Date: Sun, 18 Nov 2012 19:08:06 -0500 Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: References: Message-ID: <50A97866.6080305@bryanfields.net> On 11/18/12 5:53 PM, Constantine A. Murenin wrote: > edis.at gives you an IPv4 address of, for example, 158.255.21x.xxx, > and the IPv6 /112 that you get is 2a03:f80:ed15:158:255:21x:xxx:0/112 > (really a /48), with 2a03:0f80:ed15::1 as the gateway. Vote with your dollars and find a provider with clue? It's the only way you'll get the service you want. And also, dear god a /112. It's giving me a flash back to a tier 2 carrier I consulted for about 2 years ago. Their guy (who was a CCNP :rolleyes:), threw out my plans as being wasteful of space (each site a /48 out of a /40 reservation, each network a /64, etc.). The entire thing was done out of a /112 at each site with /120's for subnets. Course this same guy asked why we needed oc-48's between locations, he wanted to get bonded gigE's of IP transport and do a VPN...... -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From david at davidcoulson.net Mon Nov 19 00:09:09 2012 From: david at davidcoulson.net (David Coulson) Date: Sun, 18 Nov 2012 19:09:09 -0500 Subject: Apple iMessage In-Reply-To: References: Message-ID: <50A978A5.9010708@davidcoulson.net> http://www.apple.com/support/icloud/systemstatus/ On 11/18/12 3:12 PM, Grant Ridder wrote: > Hi, > > Is anyone having trouble with apples iMessage service? A friend and I are > in Wisconsin and Illinois respectfully and messages via iMessage are taking > up to several minutes to send. I am using a 4s on iOS 5 and my friend is > using a 3GS. > > Thanks > Grant From jlewis at lewis.org Mon Nov 19 00:53:07 2012 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 18 Nov 2012 19:53:07 -0500 (EST) Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: <50A97866.6080305@bryanfields.net> References: <50A97866.6080305@bryanfields.net> Message-ID: On Sun, 18 Nov 2012, Bryan Fields wrote: > On 11/18/12 5:53 PM, Constantine A. Murenin wrote: >> edis.at gives you an IPv4 address of, for example, 158.255.21x.xxx, >> and the IPv6 /112 that you get is 2a03:f80:ed15:158:255:21x:xxx:0/112 >> (really a /48), with 2a03:0f80:ed15::1 as the gateway. By "KVM", I assume he's talking about cloud or VPS, i.e. a KVM based virtual machine. With cloud in particular, I've been trying to decide how to dole out IPv6 space. Because we're doing bridged networking for the VMs, we've been giving out IPv4 /32s to each VM and all VMs are in the same VLAN. It seems insane to try to setup a proper IPv6 subnet and unique gateway for each VM, so I've been thinking something similar to what the host being complained about here has done is the only way to go. Not down to the detail of making the IPv6 ip based on the IPv4 IP, but giving out "very small" v6 blocks, (i.e. maybe /120 or /124), out of a /48 with the prefix::1/48 IP as everyone's gateway. Sure, IPv6 is big enough that we could give out /64s from that /48 and not run out of numbers, but I'm concerned about what happens when an abusive customer turns up 2^64 addresses and overloads the neighbor discovery cache on our gear. What's anyone really going to do with more than a few IP addresses on a VPS anyway? Just as we do with additional v4 IPs, if someone really has a need for additional v6 subnets, those could be provided, likely for a fee. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From johnl at iecc.com Mon Nov 19 03:58:09 2012 From: johnl at iecc.com (John Levine) Date: 19 Nov 2012 03:58:09 -0000 Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: Message-ID: <20121119035809.4054.qmail@joyce.lan> > What's anyone really going to do with more than a few IP addresses on a VPS >anyway? Give every web site its own IP address, rather than using virtual hosts, I expect. On the other hand, I suppose if someone has more than a a few dozen web sites on a single VPS, more likely than not something peculiar is going on. R's, John PS: For something peculiar, see http://wild.sp.am/ which broke the bingbot, and Google's been spidering for months, emptying out the queue they built up before I put in a robots.txt saying to go away. From bill at herrin.us Mon Nov 19 04:49:39 2012 From: bill at herrin.us (William Herrin) Date: Sun, 18 Nov 2012 23:49:39 -0500 Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: References: <50A97866.6080305@bryanfields.net> Message-ID: On Sun, Nov 18, 2012 at 7:53 PM, Jon Lewis wrote: > It seems insane to try to setup a proper IPv6 subnet and unique gateway for > each VM, so I've been thinking something similar to what the host being > complained about here has done is the only way to go. Not down to the > detail of making the IPv6 ip based on the IPv4 IP, but giving out "very > small" v6 blocks, (i.e. maybe /120 or /124), out of a /48 with the > prefix::1/48 IP as everyone's gateway. Sure, IPv6 is big enough that we > could give out /64s from that /48 and not run out of numbers, but I'm > concerned about what happens when an abusive customer turns up 2^64 > addresses and overloads the neighbor discovery cache on our gear. What's > anyone really going to do with more than a few IP addresses on a VPS anyway? > Just as we do with additional v4 IPs, if someone really has a need for > additional v6 subnets, those could be provided, likely for a fee. Hi Jon, Why not assign a single IPv6 address to each VM and then for those folks who need more, *route* a /64 to the original address? With Linux, I think you can then attach the whole /64 to a loopback alias (lo:1) and the host will understand that it has the entire /64 without creating neighbor table entries or any other chancy things. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon Nov 19 05:40:45 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 18 Nov 2012 21:40:45 -0800 Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: References: <50A97866.6080305@bryanfields.net> Message-ID: <62D64EAC-80D1-4D85-BEB6-3F968705C5A2@delong.com> On Nov 18, 2012, at 4:53 PM, Jon Lewis wrote: > On Sun, 18 Nov 2012, Bryan Fields wrote: > >> On 11/18/12 5:53 PM, Constantine A. Murenin wrote: >>> edis.at gives you an IPv4 address of, for example, 158.255.21x.xxx, >>> and the IPv6 /112 that you get is 2a03:f80:ed15:158:255:21x:xxx:0/112 >>> (really a /48), with 2a03:0f80:ed15::1 as the gateway. > > By "KVM", I assume he's talking about cloud or VPS, i.e. a KVM based virtual machine. With cloud in particular, I've been trying to decide how to dole out IPv6 space. Because we're doing bridged networking for the VMs, we've been giving out IPv4 /32s to each VM and all VMs are in the same VLAN. > > It seems insane to try to setup a proper IPv6 subnet and unique gateway for each VM, so I've been thinking something similar to what the host being complained about here has done is the only way to go. Not down to the detail of making the IPv6 ip based on the IPv4 IP, but giving out "very small" v6 blocks, (i.e. maybe /120 or /124), out of a /48 with the prefix::1/48 IP as everyone's gateway. Sure, IPv6 is big enough that we could give out /64s from that /48 and not run out of numbers, but I'm concerned about what happens when an abusive customer turns up 2^64 addresses and overloads the neighbor discovery cache on our gear. What's anyone really going to do with more than a few IP addresses on a VPS anyway? Just as we do with additional v4 IPs, if someone really has a need for additional v6 subnets, those could be provided, likely for a fee. Setting up a proper IPv6 subnet and unique gateway for each VM is probably insane, but, potentially less insane than some other alternatives. Setting one up for each customer's collection of VMs, OTOH, might not be so insane. Remember, you can have multiple IPv6 subnets on the same link without much penalty. Since you probably want the ability to have VPS portable across physical servers, you probably don't want to set up a subnet per physical server with all the VPS on a given PS sharing that subnet which is the numerically simplest approach. I'd have to review your actual architecture (physical and overlaid virtual) to really know what would be best for your particular circumstance. Contact me off-list if you're interested in something like that. Owen From saku at ytti.fi Mon Nov 19 08:05:47 2012 From: saku at ytti.fi (Saku Ytti) Date: Mon, 19 Nov 2012 10:05:47 +0200 Subject: Google/Youtube problems In-Reply-To: <50A96585.5010304@danysek.cz> References: <50A96585.5010304@danysek.cz> Message-ID: <20121119080547.GA8020@pob.ytti.fi> On (2012-11-18 23:47 +0100), Daniel Suchy wrote: > Is anyone else seeing similar problems with Google/Youtube? My advice is, host the content locally. Certain Finnish domestic SPs had issues with youtube during peak hours for years, when content came via Stockholm, if content came from mainland europe or locally you were set. Perhaps Google was (maybe still is) regularly congested in Stockholm, and there might not be much incentive for google to add capacity everywhere sufficiently, as they can just pressure to people to host them for free. I'm bit curious about market position youtube has. GOOG claims youtube is making profit, but I think this is because network is considered other BUs cost and youtube rides on it for free (remember pre-youtube, how GOOG micro-optimized google front-page to save on network cost, post-youtube they rightly stopped caring and added predictive input etc.) I can't see how anyone could compete against youtube, I don't believe the service is anywhere near profitable (it's maybe 10% of Internet, and I can't see revenue being 10% of Internet), if it would have to pay for the network itself. Consequently you probably can't compete with them, as you need to cover the costs from the profits. It is just so ubiquitous service, that if it does not work your eyeballs will switch to network where it does, so you will give google free capacity, which you wouldn't probably do for others web streaming shops. -- ++ytti From david at mailplus.nl Mon Nov 19 10:36:53 2012 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Mon, 19 Nov 2012 11:36:53 +0100 Subject: Dns sometimes fails using Google DNS / automatic dnssec In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D38@SBS1.blinker.local> <78C35D6C1A82D243B830523B4193CF5F5E8D4C6D51@SBS1.blinker.local> Message-ID: <78C35D6C1A82D243B830523B4193CF5F5E8D4C7053@SBS1.blinker.local> fixed... ----------------------- David Hofstee -----Oorspronkelijk bericht----- Van: Yunhong Gu [mailto:guu at google.com] Verzonden: donderdag 15 november 2012 18:29 Aan: Jay Ford CC: MailPlus| David Hofstee; nanog at nanog.org Onderwerp: Re: Dns sometimes fails using Google DNS / automatic dnssec Hi, we have found the bug that caused this problem. It was introduced in a very recent release. The fix is on its way. Thanks very much for the report, Yunhong On Thu, Nov 15, 2012 at 12:26 PM, Jay Ford wrote: > It looks like if the server has the RRSIG RR, it returns it. For example, a > query with +dnssec will cause it to cache the RRSIG, after which it returns > it even if +dnssec not specified. > From patrick at ianai.net Mon Nov 19 13:27:53 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 19 Nov 2012 08:27:53 -0500 Subject: Google/Youtube problems In-Reply-To: <20121119080547.GA8020@pob.ytti.fi> References: <50A96585.5010304@danysek.cz> <20121119080547.GA8020@pob.ytti.fi> Message-ID: <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> On Nov 19, 2012, at 03:05 , Saku Ytti wrote: > On (2012-11-18 23:47 +0100), Daniel Suchy wrote: > >> Is anyone else seeing similar problems with Google/Youtube? > > My advice is, host the content locally. Sound advice, IMHO. > I'm bit curious about market position youtube has. GOOG claims youtube is > making profit, but I think this is because network is considered other BUs > cost and youtube rides on it for free (remember pre-youtube, how GOOG > micro-optimized google front-page to save on network cost, post-youtube > they rightly stopped caring and added predictive input etc.) I do not work for Google, nor have I asked anyone in Google how they do their accounting. However, I would be rather surprised to find the vast majority of their capacity is charged to the BU using a tiny fraction of that capacity, while the BU using the lion's share gets a "free ride". > I can't see how anyone could compete against youtube, I don't believe the > service is anywhere near profitable (it's maybe 10% of Internet, and I > can't see revenue being 10% of Internet), if it would have to pay for the > network itself. Consequently you probably can't compete with them, as you > need to cover the costs from the profits. It is just so ubiquitous service, > that if it does not work your eyeballs will switch to network where it > does, so you will give google free capacity, which you wouldn't probably do > for others web streaming shops. First, I believe YouTube is > 10% of the Internet. Second, I see no reason why that requires anything close - not even within a couple orders of magnitude - of 10% of the Internet's revenue to be profitable. Why would you assume such a thing? -- TTFN, patrick From saku at ytti.fi Mon Nov 19 13:59:22 2012 From: saku at ytti.fi (Saku Ytti) Date: Mon, 19 Nov 2012 15:59:22 +0200 Subject: Google/Youtube problems In-Reply-To: <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> References: <50A96585.5010304@danysek.cz> <20121119080547.GA8020@pob.ytti.fi> <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> Message-ID: <20121119135922.GA8266@pob.ytti.fi> On (2012-11-19 08:27 -0500), Patrick W. Gilmore wrote: > Second, I see no reason why that requires anything close - not even within a couple orders of magnitude - of 10% of the Internet's revenue to be profitable. Why would you assume such a thing? Agreed, 10% of Internet's revenue would be exaggeration. What I'm trying to say, I can't see youtube generating anywhere nearly enough revenue who shift 10% (or more) of Internet. And to explain this conundrum to myself, I've speculated accounting magic (which I'd frown upon) and leveraging market position to get free capacity (which is ok, I'd do the same, had I the leverage) -- ++ytti From bicknell at ufp.org Mon Nov 19 14:30:25 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 19 Nov 2012 06:30:25 -0800 Subject: Google/Youtube problems In-Reply-To: <20121119135922.GA8266@pob.ytti.fi> References: <50A96585.5010304@danysek.cz> <20121119080547.GA8020@pob.ytti.fi> <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> <20121119135922.GA8266@pob.ytti.fi> Message-ID: <20121119143025.GA99801@ussenterprise.ufp.org> In a message written on Mon, Nov 19, 2012 at 03:59:22PM +0200, Saku Ytti wrote: > What I'm trying to say, I can't see youtube generating anywhere nearly > enough revenue who shift 10% (or more) of Internet. And to explain this > conundrum to myself, I've speculated accounting magic (which I'd frown > upon) and leveraging market position to get free capacity (which is ok, I'd > do the same, had I the leverage) I suspect you're thinking about revenue in terms of say, the advertisements they run with the videos. I beleive you're right, that would never pay the bills. Consider a different model. Google checks out your gmail account, and discovers you really like Red Bull and from your YouTube profile knows you watch a lot of Ke$ha videos. It also discovers there are a lot more folks with the same profile. They can now sell that data to a marketing firm, that there is a strong link between energy drinks and Ke$ha videos. GOOG-411 - building a corpus of voice data for Android's voice recognition. ReCaptcha - improving visual recognition for their book scanning process. Most of the "free" services are simply the cheapest way to get the data needed for some other service that can make much more money. It may seem weird to write off all the costs of YouTube as data aquisition costs, but there's far more money to be made selling marketing data than ads against streaming videos... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From glen.kent at gmail.com Mon Nov 19 15:02:25 2012 From: glen.kent at gmail.com (Glen Kent) Date: Mon, 19 Nov 2012 20:32:25 +0530 Subject: 25Mbps vs 4 Mbps Message-ID: Hi, The service provider(s) pipe that takes all web traffic from my laptop to the central servers (assume youtube) remain same whether i take a 4Mbps or a 25Mbps connection from my service provider. This means that the internet connection that i take from my service provider only affects the last mile -- from my home network to my service providers first access router. Given this, would one really see a 6 times improvement in a 25Mbps connection over a 4Mbps connection? I assume that the service providers rate limit the traffic much more aggressively in a 4Mbps connection. But this would only matter if the traffic from my youtube server is greater than 4Mbps, which i suspect would be the case. The question then is that how does going for a higher BW connection from the service provider help? Glen From swmike at swm.pp.se Mon Nov 19 15:12:57 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 19 Nov 2012 16:12:57 +0100 (CET) Subject: 25Mbps vs 4 Mbps In-Reply-To: References: Message-ID: On Mon, 19 Nov 2012, Glen Kent wrote: > The question then is that how does going for a higher BW connection from > the service provider help? That is like asking if a 600 bhp car is 6 times better than a 100 bhp car. I'd say you definitely can benefit in surfing speed etc up to somewhere 5-15 megabit/s, after that it's hard to discern any difference in interactivity. For youtube alone I doubt you'll notice that much difference.unless you're watching 720p/1080p material, where you will notice that 4 megabit/s probably isn't enough. I've seen netflix 1080p stream use over 10 megabit/s in 30 second interval, so sometimes it's good to have more :P -- Mikael Abrahamsson email: swmike at swm.pp.se From adam.vitkovsky at swan.sk Mon Nov 19 15:17:15 2012 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Mon, 19 Nov 2012 16:17:15 +0100 Subject: Google/Youtube problems In-Reply-To: <20121119143025.GA99801@ussenterprise.ufp.org> References: <50A96585.5010304@danysek.cz> <20121119080547.GA8020@pob.ytti.fi> <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> <20121119135922.GA8266@pob.ytti.fi> <20121119143025.GA99801@ussenterprise.ufp.org> Message-ID: <007f01cdc668$f4f49320$deddb960$@swan.sk> >From the latest csco prime presentation it appears it offers similar functionality in one of the modules that one can buy to it so that providers can have a sneak peak on these type of data in order to sell them to third parties Though I wouldn't even know whom to sell such information Nor have I been hit by a targeted advertisement, yet adam -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Monday, November 19, 2012 3:30 PM To: nanog at nanog.org Subject: Re: Google/Youtube problems In a message written on Mon, Nov 19, 2012 at 03:59:22PM +0200, Saku Ytti wrote: > What I'm trying to say, I can't see youtube generating anywhere nearly > enough revenue who shift 10% (or more) of Internet. And to explain > this conundrum to myself, I've speculated accounting magic (which I'd > frown > upon) and leveraging market position to get free capacity (which is > ok, I'd do the same, had I the leverage) I suspect you're thinking about revenue in terms of say, the advertisements they run with the videos. I beleive you're right, that would never pay the bills. Consider a different model. Google checks out your gmail account, and discovers you really like Red Bull and from your YouTube profile knows you watch a lot of Ke$ha videos. It also discovers there are a lot more folks with the same profile. They can now sell that data to a marketing firm, that there is a strong link between energy drinks and Ke$ha videos. GOOG-411 - building a corpus of voice data for Android's voice recognition. ReCaptcha - improving visual recognition for their book scanning process. Most of the "free" services are simply the cheapest way to get the data needed for some other service that can make much more money. It may seem weird to write off all the costs of YouTube as data aquisition costs, but there's far more money to be made selling marketing data than ads against streaming videos... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From nick at flhsi.com Mon Nov 19 15:19:14 2012 From: nick at flhsi.com (Nick Olsen) Date: Mon, 19 Nov 2012 10:19:14 -0500 Subject: 25Mbps vs 4 Mbps Message-ID: <69a3f799$7b5e5fd7$3cb06967$@flhsi.com> It's all about if the bandwidth is there to use. I'm sure every youtube caching server has a connection which exceeds 4Mb/s. How does a faster connection help? It allows the video to fill the buffer faster. Allowing for smoother playback on less bandwidth consistent circuits. Do you need it really if your video source is under 4Mb/s? In a perfect scenario, No. Now, That's youtube. Using Netflix as an example. I can start streaming a movie. And it'll pull 50-60Mb/s for about 20 seconds, And it's playing HD quality almost immediately. Where on a slower connection it may not switch to HD until its filled its buffer more. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Glen Kent" Sent: Monday, November 19, 2012 10:04 AM To: "nanog at nanog.org" Subject: 25Mbps vs 4 Mbps Hi, The service provider(s) pipe that takes all web traffic from my laptop to the central servers (assume youtube) remain same whether i take a 4Mbps or a 25Mbps connection from my service provider. This means that the internet connection that i take from my service provider only affects the last mile -- from my home network to my service providers first access router. Given this, would one really see a 6 times improvement in a 25Mbps connection over a 4Mbps connection? I assume that the service providers rate limit the traffic much more aggressively in a 4Mbps connection. But this would only matter if the traffic from my youtube server is greater than 4Mbps, which i suspect would be the case. The question then is that how does going for a higher BW connection from the service provider help? Glen From adam.vitkovsky at swan.sk Mon Nov 19 15:22:02 2012 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Mon, 19 Nov 2012 16:22:02 +0100 Subject: Google/Youtube problems References: <50A96585.5010304@danysek.cz> <20121119080547.GA8020@pob.ytti.fi> <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> <20121119135922.GA8266@pob.ytti.fi> <20121119143025.GA99801@ussenterprise.ufp.org> Message-ID: <008101cdc669$a05e9030$e11bb090$@swan.sk> For some providers this might be an interesting revenue stream in these days where we need to build ever faster backbones to carry more and more video traffic for users that want to pay less and less for high-speed internet connectivity adam -----Original Message----- From: Adam Vitkovsky [mailto:adam.vitkovsky at swan.sk] Sent: Monday, November 19, 2012 4:17 PM To: 'Leo Bicknell'; 'nanog at nanog.org' Subject: RE: Google/Youtube problems >From the latest csco prime presentation it appears it offers similar functionality in one of the modules that one can buy to it so that providers can have a sneak peak on these type of data in order to sell them to third parties Though I wouldn't even know whom to sell such information Nor have I been hit by a targeted advertisement, yet adam -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Monday, November 19, 2012 3:30 PM To: nanog at nanog.org Subject: Re: Google/Youtube problems In a message written on Mon, Nov 19, 2012 at 03:59:22PM +0200, Saku Ytti wrote: > What I'm trying to say, I can't see youtube generating anywhere nearly > enough revenue who shift 10% (or more) of Internet. And to explain > this conundrum to myself, I've speculated accounting magic (which I'd > frown > upon) and leveraging market position to get free capacity (which is > ok, I'd do the same, had I the leverage) I suspect you're thinking about revenue in terms of say, the advertisements they run with the videos. I beleive you're right, that would never pay the bills. Consider a different model. Google checks out your gmail account, and discovers you really like Red Bull and from your YouTube profile knows you watch a lot of Ke$ha videos. It also discovers there are a lot more folks with the same profile. They can now sell that data to a marketing firm, that there is a strong link between energy drinks and Ke$ha videos. GOOG-411 - building a corpus of voice data for Android's voice recognition. ReCaptcha - improving visual recognition for their book scanning process. Most of the "free" services are simply the cheapest way to get the data needed for some other service that can make much more money. It may seem weird to write off all the costs of YouTube as data aquisition costs, but there's far more money to be made selling marketing data than ads against streaming videos... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From saku at ytti.fi Mon Nov 19 15:33:40 2012 From: saku at ytti.fi (Saku Ytti) Date: Mon, 19 Nov 2012 17:33:40 +0200 Subject: Google/Youtube problems In-Reply-To: <20121119143025.GA99801@ussenterprise.ufp.org> References: <50A96585.5010304@danysek.cz> <20121119080547.GA8020@pob.ytti.fi> <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> <20121119135922.GA8266@pob.ytti.fi> <20121119143025.GA99801@ussenterprise.ufp.org> Message-ID: <20121119153340.GA8364@pob.ytti.fi> On (2012-11-19 06:30 -0800), Leo Bicknell wrote: > Consider a different model. Google checks out your gmail account, and > discovers you really like Red Bull and from your YouTube profile knows > you watch a lot of Ke$ha videos. It also discovers there are a lot more Sure. I have no doubt the main reasons to keep youtube are. a) data mining b) contingency B) is essentially having the most popular platform, in case if video platform becomes viable marketing platform on itself. Data mining aspect might make it less dubious to sink network cost to different BU than to the BU which actually uses the network, as that network is also benefitting from the data. -- ++ytti From foojipe at gmail.com Mon Nov 19 16:48:18 2012 From: foojipe at gmail.com (jipe foo) Date: Mon, 19 Nov 2012 17:48:18 +0100 Subject: Plages d'adresses IP Orange Message-ID: Bonjour ? tous, Quelqu'un d'Orange (ou autre) pourrait-il me donner plus d'info sur les plages d'adresses suivantes: inetnum: 81.253.0.0 - 81.253.95.255 netname: ORANGE-FRANCE-HSIAB descr: Orange France / Wanadoo service country: FR admin-c: AR10027-RIPE tech-c: ER1049-RIPE inetnum: 90.96.0.0 - 90.96.199.255 netname: ORANGEFRANCE-WFP descr: Orange France - WFP country: FR admin-c: ER1049-RIPE tech-c: ER1049-RIPE S'agit-il de plages d'adresses de mobiles, de livebox ou de connexions WIFI partag?es (au moins pour la seconde) ? Merci d'avance, -- J From joelja at bogus.com Mon Nov 19 16:55:24 2012 From: joelja at bogus.com (joel jaeggli) Date: Mon, 19 Nov 2012 08:55:24 -0800 Subject: Google/Youtube problems In-Reply-To: <20121119135922.GA8266@pob.ytti.fi> References: <50A96585.5010304@danysek.cz> <20121119080547.GA8020@pob.ytti.fi> <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> <20121119135922.GA8266@pob.ytti.fi> Message-ID: <50AA647C.7090500@bogus.com> On 11/19/12 5:59 AM, Saku Ytti wrote: > What I'm trying to say, I can't see youtube generating anywhere nearly > enough revenue who shift 10% (or more) of Internet. And to explain > this conundrum to myself, I've speculated accounting magic (which I'd > frown upon) and leveraging market position to get free capacity (which > is ok, I'd do the same, had I the leverage) Or there's a simpler explanation. Which is that it makes money either directly or as part of a salubrious interaction with other google properties. They had about 2.5Billion left over for their trouble in the quarter ending 9/30 which isn't too shabby on a gross of 14 billion. From nanog at maunier.org Mon Nov 19 16:56:59 2012 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Mon, 19 Nov 2012 17:56:59 +0100 Subject: Plages d'adresses IP Orange In-Reply-To: References: Message-ID: Hi, I think few people understand French on this list. You should try FRnOG. Pierre-Yves Maunier Le 19 novembre 2012 17:48, jipe foo a ?crit : > Bonjour ? tous, > > Quelqu'un d'Orange (ou autre) pourrait-il me donner plus d'info sur les > plages d'adresses suivantes: > > inetnum: 81.253.0.0 - 81.253.95.255 > netname: ORANGE-FRANCE-HSIAB > descr: Orange France / Wanadoo service > country: FR > admin-c: AR10027-RIPE > tech-c: ER1049-RIPE > > inetnum: 90.96.0.0 - 90.96.199.255 > netname: ORANGEFRANCE-WFP > descr: Orange France - WFP > country: FR > admin-c: ER1049-RIPE > tech-c: ER1049-RIPE > > S'agit-il de plages d'adresses de mobiles, de livebox ou de connexions WIFI > partag?es (au moins pour la seconde) ? > > Merci d'avance, > > -- > J > -- Pierre-Yves Maunier From jlewis at lewis.org Mon Nov 19 17:10:14 2012 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 19 Nov 2012 12:10:14 -0500 (EST) Subject: Plages d'adresses IP Orange In-Reply-To: References: Message-ID: Pourquoi demandez-vous des questions NANOG que Wanadoo peut r??pondre? Hopefully google translate hasn't butchered that too badly. On Mon, 19 Nov 2012, Pierre-Yves Maunier wrote: > Hi, > > I think few people understand French on this list. You should try FRnOG. > > Pierre-Yves Maunier > > > Le 19 novembre 2012 17:48, jipe foo a ?crit : > >> Bonjour ? tous, >> >> Quelqu'un d'Orange (ou autre) pourrait-il me donner plus d'info sur les >> plages d'adresses suivantes: >> >> inetnum: 81.253.0.0 - 81.253.95.255 >> netname: ORANGE-FRANCE-HSIAB >> descr: Orange France / Wanadoo service >> country: FR >> admin-c: AR10027-RIPE >> tech-c: ER1049-RIPE >> >> inetnum: 90.96.0.0 - 90.96.199.255 >> netname: ORANGEFRANCE-WFP >> descr: Orange France - WFP >> country: FR >> admin-c: ER1049-RIPE >> tech-c: ER1049-RIPE >> >> S'agit-il de plages d'adresses de mobiles, de livebox ou de connexions WIFI >> partag?es (au moins pour la seconde) ? >> >> Merci d'avance, >> >> -- >> J >> > > > > -- > Pierre-Yves Maunier > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jamie at photon.com Mon Nov 19 17:16:31 2012 From: jamie at photon.com (Jamie Bowden) Date: Mon, 19 Nov 2012 17:16:31 +0000 Subject: Plages d'adresses IP Orange In-Reply-To: References: Message-ID: <465966A5F5B867419F604CD3E604C1E520D1F209@PRA-DCA-MAIL.pra.ray.com> Actually, this is kind of an interesting aside. Last time I checked, Canada counts as North America and large parts of Quebec are inhabited by folks who don't speak much, if any, English. Having said that, I can't recall having seen any Quebecois posting in French here, but I find it hard to believe those folks don't have use for a list like this. -- Jamie Bowden (jamie at photon.com) Sr. Sys. Admin. (703) 243-6613 x3848 Photon Research Associates, Inc. 1616 Fort Myer Drive, Suite 1000 Arlington, VA 22209 > -----Original Message----- > From: Pierre-Yves Maunier [mailto:nanog at maunier.org] > Sent: Monday, November 19, 2012 11:59 AM > To: jipe foo > Cc: NANOG list > Subject: Re: Plages d'adresses IP Orange > > Hi, > > I think few people understand French on this list. You should try > FRnOG. > > Pierre-Yves Maunier > > > Le 19 novembre 2012 17:48, jipe foo a ?crit : > > > Bonjour ? tous, > > > > Quelqu'un d'Orange (ou autre) pourrait-il me donner plus d'info sur > les > > plages d'adresses suivantes: > > > > inetnum: 81.253.0.0 - 81.253.95.255 > > netname: ORANGE-FRANCE-HSIAB > > descr: Orange France / Wanadoo service > > country: FR > > admin-c: AR10027-RIPE > > tech-c: ER1049-RIPE > > > > inetnum: 90.96.0.0 - 90.96.199.255 > > netname: ORANGEFRANCE-WFP > > descr: Orange France - WFP > > country: FR > > admin-c: ER1049-RIPE > > tech-c: ER1049-RIPE > > > > S'agit-il de plages d'adresses de mobiles, de livebox ou de > connexions WIFI > > partag?es (au moins pour la seconde) ? > > > > Merci d'avance, > > > > -- > > J > > > > > > -- > Pierre-Yves Maunier From wmaton at ottix.net Mon Nov 19 17:27:30 2012 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Mon, 19 Nov 2012 12:27:30 -0500 (EST) Subject: Plages d'adresses IP Orange In-Reply-To: References: Message-ID: Il serait mieux si vous contactez directement d'Orange. On Mon, 19 Nov 2012, jipe foo wrote: > Bonjour ? tous, > > Quelqu'un d'Orange (ou autre) pourrait-il me donner plus d'info sur les > plages d'adresses suivantes: > > inetnum: 81.253.0.0 - 81.253.95.255 > netname: ORANGE-FRANCE-HSIAB > descr: Orange France / Wanadoo service > country: FR > admin-c: AR10027-RIPE > tech-c: ER1049-RIPE > > inetnum: 90.96.0.0 - 90.96.199.255 > netname: ORANGEFRANCE-WFP > descr: Orange France - WFP > country: FR > admin-c: ER1049-RIPE > tech-c: ER1049-RIPE > > S'agit-il de plages d'adresses de mobiles, de livebox ou de connexions WIFI > partag?es (au moins pour la seconde) ? > > Merci d'avance, > > -- > J > wfms From patrick at ianai.net Mon Nov 19 17:31:41 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 19 Nov 2012 12:31:41 -0500 Subject: Plages d'adresses IP Orange In-Reply-To: <465966A5F5B867419F604CD3E604C1E520D1F209@PRA-DCA-MAIL.pra.ray.com> References: <465966A5F5B867419F604CD3E604C1E520D1F209@PRA-DCA-MAIL.pra.ray.com> Message-ID: <9CA5F877-4AB0-4CF5-91E4-243012644EEE@ianai.net> On Nov 19, 2012, at 12:16 , Jamie Bowden wrote: > Actually, this is kind of an interesting aside. Last time I checked, Canada counts as North America and large parts of Quebec are inhabited by folks who don't speak much, if any, English. Having said that, I can't recall having seen any Quebecois posting in French here, but I find it hard to believe those folks don't have use for a list like this. The entire population of Quebec (and at least some of them speak English) is barely under 1/4 of Canada, and about 2.5% of the US. Hell, it's lower than many major metro areas in the US. Better to ask why we do not post in Spanish, as Mexico has 112M people, plus of course "Central America" (whatever that is), the Caribbean, etc. But we never have, and I doubt we will in the future. -- TTFN, patrick >> -----Original Message----- >> From: Pierre-Yves Maunier [mailto:nanog at maunier.org] >> Sent: Monday, November 19, 2012 11:59 AM >> To: jipe foo >> Cc: NANOG list >> Subject: Re: Plages d'adresses IP Orange >> >> Hi, >> >> I think few people understand French on this list. You should try >> FRnOG. >> >> Pierre-Yves Maunier >> >> >> Le 19 novembre 2012 17:48, jipe foo a ?crit : >> >>> Bonjour ? tous, >>> >>> Quelqu'un d'Orange (ou autre) pourrait-il me donner plus d'info sur >> les >>> plages d'adresses suivantes: >>> >>> inetnum: 81.253.0.0 - 81.253.95.255 >>> netname: ORANGE-FRANCE-HSIAB >>> descr: Orange France / Wanadoo service >>> country: FR >>> admin-c: AR10027-RIPE >>> tech-c: ER1049-RIPE >>> >>> inetnum: 90.96.0.0 - 90.96.199.255 >>> netname: ORANGEFRANCE-WFP >>> descr: Orange France - WFP >>> country: FR >>> admin-c: ER1049-RIPE >>> tech-c: ER1049-RIPE >>> >>> S'agit-il de plages d'adresses de mobiles, de livebox ou de >> connexions WIFI >>> partag?es (au moins pour la seconde) ? >>> >>> Merci d'avance, >>> >>> -- >>> J >>> >> >> >> >> -- >> Pierre-Yves Maunier > From dylan at dylannguyen.net Sun Nov 18 23:58:33 2012 From: dylan at dylannguyen.net (Dylan N) Date: Sun, 18 Nov 2012 18:58:33 -0500 Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: References: Message-ID: <50A97629.6030205@dylannguyen.net> IIRC, EDIS, at least, will give you large blocks and delegate reverse DNS authority (+ assign your v6 block to your RIPE handle/info) if you ask. On 11/18/2012 5:53 PM, Constantine A. Murenin wrote: > Dear NANOG@, > > I came across an interesting problem in trying to find an affordable > KVM provider with IPv6 support. > > It seems like several rather major and reputable providers in the > value sector do claim to have IPv6 support, but once you get your IPv6 > addresses or subnets from them, you might be rather disappointed. From mohamed.boucadair at orange.com Mon Nov 19 14:30:37 2012 From: mohamed.boucadair at orange.com (mohamed.boucadair at orange.com) Date: Mon, 19 Nov 2012 15:30:37 +0100 Subject: Generic IP Connectivity Provisioning Profile Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751E7FD@PUEXCB1B.nanterre.francetelecom.fr> Dear all, Ron suggested I share this document in this mailing list in order to assess whether there is interest from the nanog community to carry out this effort within IETF. If you are supporting this effort, please voice it. Your feedback will help Ron in making a decision to AD-sponsor this document in the IETF. This is an effort trying to capture and expose the IP connectivity service provided by the network layer to upper services, to adjacent networks, offered/delivered to customers, etc. The document focuses on the definition of the CPP itself and does not discuss for instance how this is translated into configuration data/policies to be enforced in underlying nodes. Abstract: This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP Template to capture IP connectivity requirements to be met in the context of delivery of services (e.g. Voice over IP or IP TV) which are to be plugged upon an IP/MPLS infrastructure. The CPP defines the set of IP transfer parameters to be supported by the underlying IP/MPLS transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics such as one-way delay, one-way delay variation are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP. Having the generic CPP template allows for (1) automating the process of service negotiation and activation, thus accelerating service provisioning, (2) setting the (traffic) objectives of Traffic Engineering functions and service management functions and (3) enriching service and network management systems with 'decision- making' capabilities based on negotiated/offered CPPs. https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-profile http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-profile-02 Comments are more than welcome. Cheers, Med From glauber at vescnet.com.br Mon Nov 19 16:55:37 2012 From: glauber at vescnet.com.br (Glauber Derlland) Date: Mon, 19 Nov 2012 13:55:37 -0300 Subject: Youtube Message-ID: Hi, Anyone know what's going to inform with Youtube here in Brazil this horrible, super slow it is already 14 days. -- Glauber Derlland 81-3497-7250 / 81-8859-3306 / 81-4062-9207 / 11-4063-0189 INOC-DBA.br: 262792*100 www.vescnet.com.br msn: vesc.net at hotmail. http://as262792.peeringdb.com/ From Jean-Francois.TremblayING at videotron.com Mon Nov 19 17:51:42 2012 From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com) Date: Mon, 19 Nov 2012 12:51:42 -0500 Subject: Plages d'adresses IP Orange In-Reply-To: <465966A5F5B867419F604CD3E604C1E520D1F209@PRA-DCA-MAIL.pra.ray.com> References: <465966A5F5B867419F604CD3E604C1E520D1F209@PRA-DCA-MAIL.pra.ray.com> Message-ID: Jamie Bowden a ?crit sur 19/11/2012 12:16:31 PM : > Having said that, I can't recall having seen any Quebecois posting > in French here, [snip] The intersection of Quebecois who speak only French and those who have anything to do with networking is hopefully very close to 0. That said, our typical first-encounter joke with a vendor is asking for a French version of their CLI. Always funny to see how they react. /JF Videotron, AS5769 From karlinkonig at gmail.com Mon Nov 19 18:02:12 2012 From: karlinkonig at gmail.com (=?ISO-8859-1?Q?Karlin_K=F6nig?=) Date: Mon, 19 Nov 2012 15:02:12 -0300 Subject: Youtube In-Reply-To: References: Message-ID: 2012/11/19 Glauber Derlland > Hi, > > Anyone know what's going to inform with Youtube here in Brazil this > horrible, super slow it is already 14 days. > > -- > > Glauber Derlland > 81-3497-7250 / 81-8859-3306 / 81-4062-9207 / 11-4063-0189 > INOC-DBA.br: 262792*100 > www.vescnet.com.br > msn: vesc.net at hotmail. > http://as262792.peeringdb.com/ > You'd be better of mailing LACNOG and your ISP about this. Or at least try to be more verbose on the "super slow" to try and make a relevant topic. Thank You, -- -Karlin From joly at punkcast.com Mon Nov 19 18:19:21 2012 From: joly at punkcast.com (Joly MacFie) Date: Mon, 19 Nov 2012 13:19:21 -0500 Subject: Google/Youtube problems In-Reply-To: <50AA647C.7090500@bogus.com> References: <50A96585.5010304@danysek.cz> <20121119080547.GA8020@pob.ytti.fi> <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> <20121119135922.GA8266@pob.ytti.fi> <50AA647C.7090500@bogus.com> Message-ID: WIth my limited understanding of such topics I've long been confused by something I read a couple of years back - in an Arbor report perhaps - to the effect that by being the originator of so much traffic, and as they built out their own network, Google were making money on transit. Can anyone elaborate or refute? On Mon, Nov 19, 2012 at 11:55 AM, joel jaeggli wrote: > On 11/19/12 5:59 AM, Saku Ytti wrote: > >> What I'm trying to say, I can't see youtube generating anywhere nearly >> enough revenue who shift 10% (or more) of Internet. And to explain this >> conundrum to myself, I've speculated accounting magic (which I'd frown >> upon) and leveraging market position to get free capacity (which is ok, I'd >> do the same, had I the leverage) >> > Or there's a simpler explanation. Which is that it makes money either > directly or as part of a salubrious interaction with other google > properties. > > They had about 2.5Billion left over for their trouble in the quarter > ending 9/30 which isn't too shabby on a gross of 14 billion. > > -- --------------------------------------------------------------- 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 mloftis at wgops.com Mon Nov 19 18:41:29 2012 From: mloftis at wgops.com (Michael Loftis) Date: Mon, 19 Nov 2012 10:41:29 -0800 Subject: Google/Youtube problems In-Reply-To: <20121119143025.GA99801@ussenterprise.ufp.org> References: <50A96585.5010304@danysek.cz> <20121119080547.GA8020@pob.ytti.fi> <073EF505-E6B7-49BB-BFC5-AAF17F7B1FA7@ianai.net> <20121119135922.GA8266@pob.ytti.fi> <20121119143025.GA99801@ussenterprise.ufp.org> Message-ID: On Mon, Nov 19, 2012 at 6:30 AM, Leo Bicknell wrote: > In a message written on Mon, Nov 19, 2012 at 03:59:22PM +0200, Saku Ytti > wrote: > > What I'm trying to say, I can't see youtube generating anywhere nearly > > enough revenue who shift 10% (or more) of Internet. And to explain this > > conundrum to myself, I've speculated accounting magic (which I'd frown > > upon) and leveraging market position to get free capacity (which is ok, > I'd > > do the same, had I the leverage) > > I suspect you're thinking about revenue in terms of say, the > advertisements they run with the videos. I beleive you're right, that > would never pay the bills. > > Consider a different model. Google checks out your gmail account, and > discovers you really like Red Bull and from your YouTube profile knows > you watch a lot of Ke$ha videos. It also discovers there are a lot more > folks with the same profile. They can now sell that data to a marketing > firm, that there is a strong link between energy drinks and Ke$ha > videos. > Actually GOOG doesn't allow this as policy. Different BUs are rather quite restricted on how they can obtain other BUs data. In general "if you can't do it as XYZ corp, you can't do it from inside of GOOG either" -- there's a sort of privacy/policy watchdog group inside of the puzzle palace with at least a few people who are *very* concerned with privacy and data protection. I know this just because I've met a handful of them over the years. The ones in the group charged with making sure your data isn't opened up to everyone and their brother, even inside of google, to this sort of thing are pretty fanatical too. Ads can't use any data in any other way than anyone else could from GMail. Same goes with search. They can (and clearly do) share technology, software, infrastructure, and methodologies, but, the actual data is a pretty touchy subject between BUs due to their own policy. Even if they disband the group, everyone I've ever met with any responsibility towards user data shared the attitude that doing something many of us would consider "icky" would be somethign they'd block against internally. (such as just opening up the gmail to any advertiser that came along, aggregating data between BUs to sell individual preferences, etc) Will this be the case forever? Dunno. The ethos/culture is what keeps all this in check right now and culture is known to change. All that said, they're quite profitable now, and so I don't know that there's a pressure from profit motive to improve that revenue stream by doing dirty pool. Especially if the world governments decide they're playing dirty pool and go looking. > > GOOG-411 - building a corpus of voice data for Android's voice > recognition. > > ReCaptcha - improving visual recognition for their book scanning > process. > > Most of the "free" services are simply the cheapest way to get the data > needed for some other service that can make much more money. It may > seem weird to write off all the costs of YouTube as data aquisition > costs, but there's far more money to be made selling marketing data than > ads against streaming videos... > From nick at flhsi.com Mon Nov 19 19:10:05 2012 From: nick at flhsi.com (Nick Olsen) Date: Mon, 19 Nov 2012 14:10:05 -0500 Subject: Google/Youtube problems Message-ID: <23c20c2a$6cff9a1b$473ebeb$@flhsi.com> I think this would be true if they offered some form of paid peering. Google want's a good fast route to your customers, And your customers want a good fast route to Google. IF Google ran its transit at or near congestion. This could degrade your customers performance. After so long, You'd contact Google and attempt to troubleshoot. And they would say if you want good peering with them, You should pay them to peer. Where you could control just how much traffic was on your port and expand it if needed. Pretty sure this was Comcast and level3/Netflix did. But Comcast had the winning leverage (more eyeballs) in the discussion. But, I don't think Google does this. My knowledge on AS15169 is limited. But I recall them having a very strict peering policy. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Joly MacFie" Sent: Monday, November 19, 2012 1:21 PM To: "joel jaeggli" Subject: Re: Google/Youtube problems WIth my limited understanding of such topics I've long been confused by something I read a couple of years back - in an Arbor report perhaps - to the effect that by being the originator of so much traffic, and as they built out their own network, Google were making money on transit. Can anyone elaborate or refute? On Mon, Nov 19, 2012 at 11:55 AM, joel jaeggli wrote: > On 11/19/12 5:59 AM, Saku Ytti wrote: > >> What I'm trying to say, I can't see youtube generating anywhere nearly >> enough revenue who shift 10% (or more) of Internet. And to explain this >> conundrum to myself, I've speculated accounting magic (which I'd frown >> upon) and leveraging market position to get free capacity (which is ok, I'd >> do the same, had I the leverage) >> > Or there's a simpler explanation. Which is that it makes money either > directly or as part of a salubrious interaction with other google > properties. > > They had about 2.5Billion left over for their trouble in the quarter > ending 9/30 which isn't too shabby on a gross of 14 billion. > > -- --------------------------------------------------------------- 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 foojipe at gmail.com Mon Nov 19 19:59:53 2012 From: foojipe at gmail.com (jipe) Date: Mon, 19 Nov 2012 20:59:53 +0100 Subject: Plages d'adresses IP Orange In-Reply-To: References: Message-ID: <7B19340B-C3D8-4AB5-BFD3-167985DF2C3A@gmail.com> Le 19 nov. 2012 ? 17:56, Pierre-Yves Maunier a ?crit : > Hi, > > I think few people understand French on this list. You should try FRnOG. Ouups, of course the message was intended to FRnoOG Sorry for the noise guys. -- J From surfer at mauigateway.com Mon Nov 19 21:20:06 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 19 Nov 2012 13:20:06 -0800 Subject: Plages d'adresses IP Orange Message-ID: <20121119132006.90D46FC2@m0005297.ppops.net> --- jlewis at lewis.org wrote: From: Jon Lewis Pourquoi demandez-vous des questions NANOG que Wanadoo peut r??pondre? Hopefully google translate hasn't butchered that too badly. ----------------------------------------------------- It said something about eggs? Were you hungry for some RA eggs? ;-) "Why do you ask questions that NANOG Wanadoo ? RA can lay eggs?" scott From rps at maine.edu Mon Nov 19 21:24:44 2012 From: rps at maine.edu (Ray Soucy) Date: Mon, 19 Nov 2012 16:24:44 -0500 Subject: Plages d'adresses IP Orange In-Reply-To: References: Message-ID: The universal translator is still a few years out it seems. Written that way it's borderline insulting. ;-) 2012/11/19 Jon Lewis : > Pourquoi demandez-vous des questions NANOG que Wanadoo peut r??pondre? > > Hopefully google translate hasn't butchered that too badly. > > > On Mon, 19 Nov 2012, Pierre-Yves Maunier wrote: > >> Hi, >> >> I think few people understand French on this list. You should try FRnOG. >> >> Pierre-Yves Maunier >> >> >> Le 19 novembre 2012 17:48, jipe foo a ?crit : >> >>> Bonjour ? tous, >>> >>> Quelqu'un d'Orange (ou autre) pourrait-il me donner plus d'info sur les >>> plages d'adresses suivantes: >>> >>> inetnum: 81.253.0.0 - 81.253.95.255 >>> netname: ORANGE-FRANCE-HSIAB >>> descr: Orange France / Wanadoo service >>> country: FR >>> admin-c: AR10027-RIPE >>> tech-c: ER1049-RIPE >>> >>> inetnum: 90.96.0.0 - 90.96.199.255 >>> netname: ORANGEFRANCE-WFP >>> descr: Orange France - WFP >>> country: FR >>> admin-c: ER1049-RIPE >>> tech-c: ER1049-RIPE >>> >>> S'agit-il de plages d'adresses de mobiles, de livebox ou de connexions >>> WIFI >>> partag?es (au moins pour la seconde) ? >>> >>> Merci d'avance, >>> >>> -- >>> J >>> >> >> >> >> -- >> Pierre-Yves Maunier >> > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From cabo at tzi.org Mon Nov 19 21:34:51 2012 From: cabo at tzi.org (Carsten Bormann) Date: Mon, 19 Nov 2012 22:34:51 +0100 Subject: Plages d'adresses IP Orange In-Reply-To: References: Message-ID: <5A438BAB-3611-4292-B7B5-AF2B99790712@tzi.org> On Nov 19, 2012, at 22:24, Ray Soucy wrote: > The universal translator is still a few years out it seems. The universal character set is widely deployed, though. The universal translator just can't do it's thing if people still don't manage to send the simplest emails without mojibake (google that, if you don't know what it means). If you transform > Pourquoi demandez-vous des questions NANOG que Wanadoo peut r??pondre? back into > Pourquoi demandez-vous des questions NANOG que Wanadoo peut r?pondre? the goog gives you: > Why do you ask questions that NANOG Wanadoo can answer? Well, almost, but no egg in your face :-) Gr??e, Carsten From jeff-kell at utc.edu Mon Nov 19 21:37:05 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 19 Nov 2012 16:37:05 -0500 Subject: Fiber terminations -- UPC vs APC Message-ID: <50AAA681.6020005@utc.edu> Looking for some guidance/references on the use of UPC versus APC terminations on fiber cabling. Traditionally we have done all of our fiber plant targeting data usage with UPC connectors. We are also looking at proposals for fiber distribution plant for video, and the possibility of using some of the existing fiber plant for that purpose; as well as any new fiber plant that gets installed for video potentially as data. The video folks are set, determined, and insistent that they need APC terminations. All data references I have found preach UPC. Cisco's SFP reference page even states (in bold): > *Note:* Only connections with patch cords with PC or UPC connectors are supported. > Patch cords with APC connectors are not supported. All cables and cable assemblies > used must be compliant with the standards specified in the standards section. So are we doomed to having physically separated fiber plants with suitable connectors / jumpers dedicated to video? Anyone been down this snaky looking path? Jeff From swhyte at gmail.com Mon Nov 19 21:48:44 2012 From: swhyte at gmail.com (Scott Whyte) Date: Mon, 19 Nov 2012 13:48:44 -0800 Subject: Google/Youtube problems In-Reply-To: <23c20c2a$6cff9a1b$473ebeb$@flhsi.com> References: <23c20c2a$6cff9a1b$473ebeb$@flhsi.com> Message-ID: On Mon, Nov 19, 2012 at 11:10 AM, Nick Olsen wrote: > I think this would be true if they offered some form of paid peering. > > Google want's a good fast route to your customers, And your customers want > a good fast route to Google. > > IF Google ran its transit at or near congestion. This could degrade your > customers performance. After so long, You'd contact Google and attempt to > troubleshoot. And they would say if you want good peering with them, You > should pay them to peer. Where you could control just how much traffic was > on your port and expand it if needed. Pretty sure this was Comcast and > level3/Netflix did. But Comcast had the winning leverage (more eyeballs) in > the discussion. > > But, I don't think Google does this. My knowledge on AS15169 is limited. > But I recall them having a very strict peering policy. Strict? Really? https://peering.google.com/about/peering_policy.html > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Joly MacFie" > Sent: Monday, November 19, 2012 1:21 PM > To: "joel jaeggli" > Subject: Re: Google/Youtube problems > > WIth my limited understanding of such topics I've long been confused by > something I read a couple of years back - in an Arbor report perhaps - to > the effect that by being the originator of so much traffic, and as they > built out their own network, Google were making money on transit. > > Can anyone elaborate or refute? > > On Mon, Nov 19, 2012 at 11:55 AM, joel jaeggli wrote: > >> On 11/19/12 5:59 AM, Saku Ytti wrote: >> >>> What I'm trying to say, I can't see youtube generating anywhere nearly >>> enough revenue who shift 10% (or more) of Internet. And to explain this >>> conundrum to myself, I've speculated accounting magic (which I'd frown >>> upon) and leveraging market position to get free capacity (which is ok, > I'd >>> do the same, had I the leverage) >>> >> Or there's a simpler explanation. Which is that it makes money either >> directly or as part of a salubrious interaction with other google >> properties. >> >> They had about 2.5Billion left over for their trouble in the quarter >> ending 9/30 which isn't too shabby on a gross of 14 billion. >> >> > > -- > --------------------------------------------------------------- > 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 Valdis.Kletnieks at vt.edu Mon Nov 19 21:48:56 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 19 Nov 2012 16:48:56 -0500 Subject: Fiber terminations -- UPC vs APC In-Reply-To: Your message of "Mon, 19 Nov 2012 16:37:05 -0500." <50AAA681.6020005@utc.edu> References: <50AAA681.6020005@utc.edu> Message-ID: <34914.1353361736@turing-police.cc.vt.edu> On Mon, 19 Nov 2012 16:37:05 -0500, Jeff Kell said: > The video folks are set, determined, and insistent that they need APC terminations. > > All data references I have found preach UPC. Remember - the nozzles on unleaded gas pumps aren't interchangeable with the ones that dispense leaded gas (if any of those still exist?). Perhaps somebody decided this was a good idea for video and data as well? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From walter.keen at rainierconnect.net Mon Nov 19 21:50:33 2012 From: walter.keen at rainierconnect.net (Walter Keen) Date: Mon, 19 Nov 2012 13:50:33 -0800 (PST) Subject: Fiber terminations -- UPC vs APC In-Reply-To: <50AAA681.6020005@utc.edu> Message-ID: <1603471326.5210575.1353361833340.JavaMail.root@zimbra01.rainierconnect.net> Where I work we maintain a mix of Telecom, Data, and CATV networking. APC is REQUIRED per many manufacturers for video. It reduces reflections of the signal which in the video world can cause quite a few headaches and has the potential to have severe impact on video quality. Also, if you're looking at GPON in the future, it also requires it. We're staring to standardize on all-APC patch panels. Cisco's SFP reference is not wrong. ONLY UPC is supported, but that is at the SFP interface. For us it means pre-ordering online quite a few LC/UPC -> SC/APC jumpers so we can interface with the patch panels. So, Both are right. You could just as easily use APC for only video and keep all UPC for data and SONET. We just are going slowly to all APC to keep the management of spare parts easier. ----- Original Message ----- From: "Jeff Kell" To: "nanog" Sent: Monday, November 19, 2012 1:37:05 PM Subject: Fiber terminations -- UPC vs APC Looking for some guidance/references on the use of UPC versus APC terminations on fiber cabling. Traditionally we have done all of our fiber plant targeting data usage with UPC connectors. We are also looking at proposals for fiber distribution plant for video, and the possibility of using some of the existing fiber plant for that purpose; as well as any new fiber plant that gets installed for video potentially as data. The video folks are set, determined, and insistent that they need APC terminations. All data references I have found preach UPC. Cisco's SFP reference page even states (in bold): > *Note:* Only connections with patch cords with PC or UPC connectors are supported. > Patch cords with APC connectors are not supported. All cables and cable assemblies > used must be compliant with the standards specified in the standards section. So are we doomed to having physically separated fiber plants with suitable connectors / jumpers dedicated to video? Anyone been down this snaky looking path? Jeff From nick at flhsi.com Mon Nov 19 21:51:59 2012 From: nick at flhsi.com (Nick Olsen) Date: Mon, 19 Nov 2012 16:51:59 -0500 Subject: Google/Youtube problems Message-ID: <75816ceb$34ab6bec$1da0b6a8$@flhsi.com> I stand corrected. That's what I get for going off memory. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Scott Whyte" Sent: Monday, November 19, 2012 4:48 PM To: nick at flhsi.com Subject: Re: Google/Youtube problems On Mon, Nov 19, 2012 at 11:10 AM, Nick Olsen wrote: > I think this would be true if they offered some form of paid peering. > > Google want's a good fast route to your customers, And your customers want > a good fast route to Google. > > IF Google ran its transit at or near congestion. This could degrade your > customers performance. After so long, You'd contact Google and attempt to > troubleshoot. And they would say if you want good peering with them, You > should pay them to peer. Where you could control just how much traffic was > on your port and expand it if needed. Pretty sure this was Comcast and > level3/Netflix did. But Comcast had the winning leverage (more eyeballs) in > the discussion. > > But, I don't think Google does this. My knowledge on AS15169 is limited. > But I recall them having a very strict peering policy. Strict? Really? https://peering.google.com/about/peering_policy.html > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Joly MacFie" > Sent: Monday, November 19, 2012 1:21 PM > To: "joel jaeggli" > Subject: Re: Google/Youtube problems > > WIth my limited understanding of such topics I've long been confused by > something I read a couple of years back - in an Arbor report perhaps - to > the effect that by being the originator of so much traffic, and as they > built out their own network, Google were making money on transit. > > Can anyone elaborate or refute? > > On Mon, Nov 19, 2012 at 11:55 AM, joel jaeggli wrote: > >> On 11/19/12 5:59 AM, Saku Ytti wrote: >> >>> What I'm trying to say, I can't see youtube generating anywhere nearly >>> enough revenue who shift 10% (or more) of Internet. And to explain this >>> conundrum to myself, I've speculated accounting magic (which I'd frown >>> upon) and leveraging market position to get free capacity (which is ok, > I'd >>> do the same, had I the leverage) >>> >> Or there's a simpler explanation. Which is that it makes money either >> directly or as part of a salubrious interaction with other google >> properties. >> >> They had about 2.5Billion left over for their trouble in the quarter >> ending 9/30 which isn't too shabby on a gross of 14 billion. >> >> > > -- > --------------------------------------------------------------- > 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 swmike at swm.pp.se Mon Nov 19 21:57:20 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 19 Nov 2012 22:57:20 +0100 (CET) Subject: Fiber terminations -- UPC vs APC In-Reply-To: <50AAA681.6020005@utc.edu> References: <50AAA681.6020005@utc.edu> Message-ID: On Mon, 19 Nov 2012, Jeff Kell wrote: > So are we doomed to having physically separated fiber plants with > suitable connectors / jumpers dedicated to video? Anyone been down this > snaky looking path? Yes. Someone comes up with the brilliant idea to have APC on all new installs, people end up using UPC patch cables anyway, and mayhem ensues. You end up with having to stock substantially more patch cables than otherwise, because now you need LC/UPC-SC/UPC and LC/UPC-SC-APC, you need SC/APC-SC/APC, you need SC/UPC-SC/APC and so on. It's a mess. If you need to do HFC in low-volume, do APC on those only. I believe it's going to be cheaper in the long run than trying to go APC everywhere. If a majority is going to be HFC, then you might be better off to go APC everywhere. -- Mikael Abrahamsson email: swmike at swm.pp.se From askoorb+nanog at gmail.com Mon Nov 19 22:05:08 2012 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Mon, 19 Nov 2012 22:05:08 +0000 Subject: Fiber terminations -- UPC vs APC In-Reply-To: <50AAA681.6020005@utc.edu> References: <50AAA681.6020005@utc.edu> Message-ID: Hi, On Mon, Nov 19, 2012 at 9:37 PM, Jeff Kell wrote: > Looking for some guidance/references on the use of UPC versus APC > terminations on fiber > cabling. Something similar has recently been discussed on NANOG. It might be worth having a look though that discussion as well if you want more background info and you missed it back in September: http://mailman.nanog.org/pipermail/nanog/2012-September/052330.html Alex From bill at herrin.us Mon Nov 19 22:06:04 2012 From: bill at herrin.us (William Herrin) Date: Mon, 19 Nov 2012 17:06:04 -0500 Subject: Fiber terminations -- UPC vs APC In-Reply-To: <50AAA681.6020005@utc.edu> References: <50AAA681.6020005@utc.edu> Message-ID: On Mon, Nov 19, 2012 at 4:37 PM, Jeff Kell wrote: > Looking for some guidance/references on the use of UPC versus APC terminations on fiber > cabling. Traditionally we have done all of our fiber plant targeting data usage with > UPC connectors. We are also looking at proposals for fiber distribution plant for > video, and the possibility of using some of the existing fiber plant for that purpose; > as well as any new fiber plant that gets installed for video potentially as data. > > The video folks are set, determined, and insistent that they need APC terminations. Over the lifetime of this fiber plant, you will find yourself using jumpers which convert to many different equipment-side connectors. So, give the equipment side connectors a very low priority in your equation and focus on capability. If you use APC terminations, can jumper cables adequately convert them to UPC connectors on the equipment side? Is the reverse true? That answer should drive your choice. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lowen at pari.edu Mon Nov 19 22:30:41 2012 From: lowen at pari.edu (Lamar Owen) Date: Mon, 19 Nov 2012 17:30:41 -0500 Subject: Fiber terminations -- UPC vs APC In-Reply-To: <50AAA681.6020005@utc.edu> References: <50AAA681.6020005@utc.edu> Message-ID: On Nov 19, 2012, at 4:37 PM, Jeff Kell wrote: > Looking for some guidance/references on the use of UPC versus APC > terminations on fiber > cabling. Traditionally we have done all of our fiber plant > targeting data usage with > UPC connectors. We are also looking at proposals for fiber > distribution plant for > video, and the possibility of using some of the existing fiber plant > for that purpose; > as well as any new fiber plant that gets installed for video > potentially as data. > > The video folks are set, determined, and insistent that they need > APC terminations. APC is pretty much the standard for high-power video distribution, and for very good reasons. The return loss is much better for APC than for UPC, for instance, and that can be very significant depending upon the equipment being used to drive. Much video distribution gear, including passive splitters and EDFA's, are only available with APC connectors. Mating an APC to a UPC will result in an 'air-gap attenuator' being created, and that may be a problem. A significant problem for some gear, in fact. Really high-power long-haul gear may need APC as well, even for networking stuff. Your choice boils down to parallel plants or only APC with UPC jumpers for non-APC equipment. You really really don't want to have any UPC connectors in a really high-power path that needs APC all the way; I have actually seen some warranty statements, for some older equipment, primarily EDFA modules, that indicate that the warranty would be voided if any non-APC connectors were in the path anywhere. The reflections from a UPC end can detune some of these lasers, and can, in theory at least, cause permanent transmitter damage that won't be under warranty. You could, though, provision half APC and half UPC, since the color coding is pretty clear. You can even use, say, all LC on your UPC patches and all SC on you APC patches or similar, and get both with little danger of intermating. I think I'd personally rather just provision all APC in the backbone fiber runs and install APC to UPC distribution runs to your network gear. But you'll have to train people to always plug green connectors into green connectors, and blue into blue, and never should green and blue mix. From vanwolfe at gmail.com Mon Nov 19 23:21:55 2012 From: vanwolfe at gmail.com (Van Wolfe) Date: Mon, 19 Nov 2012 16:21:55 -0700 Subject: NTP Issues Today Message-ID: Hello, Did anyone else experience issues with NTP today? We had our server times update to the year 2000 at around 3:30 MT, then revert back to 2012. Thanks, Van From surfer at mauigateway.com Mon Nov 19 23:32:07 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 19 Nov 2012 15:32:07 -0800 Subject: NTP Issues Today Message-ID: <20121119153207.90E1DC6B@m0005312.ppops.net> --- vanwolfe at gmail.com wrote: From: Van Wolfe Did anyone else experience issues with NTP today? We had our server times update to the year 2000 at around 3:30 MT, then revert back to 2012. ----------------------------------------- You need to provide more information. For example, what NTP source are you using? scott From chaynes at centracomm.net Mon Nov 19 23:37:28 2012 From: chaynes at centracomm.net (Clay Haynes) Date: Mon, 19 Nov 2012 23:37:28 +0000 Subject: NTP Issues Today In-Reply-To: <20121119153207.90E1DC6B@m0005312.ppops.net> Message-ID: Scott, I can confirm this had happened on one of my test servers - it was pointing to tick.usno.navy.mil and tock.usno.navy.mil at the time. - Clay On 11/19/12 6:32 PM, "Scott Weeks" wrote: > > >--- vanwolfe at gmail.com wrote: >From: Van Wolfe > >Did anyone else experience issues with NTP today? We had our server >times update to the year 2000 at around 3:30 MT, then revert back to 2012. >----------------------------------------- > > >You need to provide more information. For example, what NTP >source are you using? > >scott > From surfer at mauigateway.com Mon Nov 19 23:50:28 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 19 Nov 2012 15:50:28 -0800 Subject: NTP Issues Today Message-ID: <20121119155028.90E1DD8D@m0005312.ppops.net> On 11/19/12 6:32 PM, "Scott Weeks" wrote: >--- vanwolfe at gmail.com wrote: >From: Van Wolfe > >Did anyone else experience issues with NTP today? We had our server >times update to the year 2000 at around 3:30 MT, then revert back to 2012. >----------------------------------------- >You need to provide more information. For example, what NTP >source are you using? ------------------------------------------ --- chaynes at centracomm.net wrote: From: Clay Haynes I can confirm this had happened on one of my test servers - it was pointing to tick.usno.navy.mil and tock.usno.navy.mil at the time. ------------------------------------------- That's not a very diverse set of NTP servers. In the future if you think it might be an outage, you might try on the 'outages' list: http://puck.nether.net/mailman/listinfo/outages For this one, you might ask the server contact if there was a problem: http://support.ntp.org/bin/view/Servers/TockUsnoNavyMil That assumes you've done your homework first and made sure it wasn't something in your network. scott From jra at baylink.com Tue Nov 20 00:02:38 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 19 Nov 2012 19:02:38 -0500 (EST) Subject: Muni Fiber redux: nuts and volts In-Reply-To: <12200968.35786.1353369543491.JavaMail.root@benjamin.baylink.com> Message-ID: <31974814.35788.1353369758024.JavaMail.root@benjamin.baylink.com> Last May we talked at some length about municipally owned wholesale fiber, and whether it was a commercially feasible idea. For those who have a few minutes (I figure, it's a holiday; the Whacky Weekend starts early :-), I'd like some advice, input, pointers, or the like, on exactly how you *do* this these days. I'm looking at 2.8 square miles of city, about 10k connections or so. I'm inclined to say trunking should be underground; I'm not sure if the drops need to be as well, though this *is* Florida; One Big Storm probably eats up even the 6x differential I've been told trenching the drops cost. What sort of ONT would one use for this? I am assuming it's impractical to do layer 1 and just move patch cords around; I'll have to work at layer 2, and supply to my wholesale customers some termination interface that extends them to the GigE or DOCSIS coax coming out the other end of the box...? Are there installation contractors with packaged proposals for this sort of thing, at this point? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From surfer at mauigateway.com Tue Nov 20 00:12:29 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 19 Nov 2012 16:12:29 -0800 Subject: NTP Issues Today Message-ID: <20121119161229.90E1DF03@m0005312.ppops.net> --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey Or you could just concede the fact that the navy is playing with time travel again. ---------------------------------------------------------- To finish this thread off for the archives... Apparently something was up with the navy stuff as a post on the outages shows. Lesson learned: Use more than one NTP source. scott From oscarorosco at sanmar.com Mon Nov 19 23:52:47 2012 From: oscarorosco at sanmar.com (Oscar Orosco) Date: Mon, 19 Nov 2012 23:52:47 +0000 Subject: NTP Issues Today Message-ID: <34EE72B792D796489D80135CD8C6464A29959846@WAIEXMBX2.corp.sanmar.com> We had the same issue on our NTP server pointing to tick.usno.navy.mil. Set date back to year 2000. Date: Mon, 19 Nov 2012 16:21:55 -0700 From: Van Wolfe > To: nanog at nanog.org Subject: NTP Issues Today Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 Hello, Did anyone else experience issues with NTP today? We had our server times update to the year 2000 at around 3:30 MT, then revert back to 2012. Thanks, Van From wbailey at satelliteintelligencegroup.com Tue Nov 20 00:04:26 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 20 Nov 2012 00:04:26 +0000 Subject: NTP Issues Today Message-ID: <1xnjv5ahi70lhssfrrm068ev.1353369588863@email.android.com> Or you could just concede the fact that the navy is playing with time travel again. From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Scott Weeks Date: 11/19/2012 3:52 PM (GMT-08:00) To: nanog at nanog.org Subject: Re: NTP Issues Today On 11/19/12 6:32 PM, "Scott Weeks" wrote: >--- vanwolfe at gmail.com wrote: >From: Van Wolfe > >Did anyone else experience issues with NTP today? We had our server >times update to the year 2000 at around 3:30 MT, then revert back to 2012. >----------------------------------------- >You need to provide more information. For example, what NTP >source are you using? ------------------------------------------ --- chaynes at centracomm.net wrote: From: Clay Haynes I can confirm this had happened on one of my test servers - it was pointing to tick.usno.navy.mil and tock.usno.navy.mil at the time. ------------------------------------------- That's not a very diverse set of NTP servers. In the future if you think it might be an outage, you might try on the 'outages' list: http://puck.nether.net/mailman/listinfo/outages For this one, you might ask the server contact if there was a problem: http://support.ntp.org/bin/view/Servers/TockUsnoNavyMil That assumes you've done your homework first and made sure it wasn't something in your network. scott From marka at isc.org Tue Nov 20 01:41:49 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 20 Nov 2012 12:41:49 +1100 Subject: NTP Issues Today In-Reply-To: Your message of "Mon, 19 Nov 2012 16:21:55 PDT." References: Message-ID: <20121120014149.3C1242B698CC@drugs.dv.isc.org> In message , Van Wolfe writes: > Hello, > > Did anyone else experience issues with NTP today? We had our server > times update to the year 2000 at around 3:30 MT, then revert back to 2012. > > Thanks, > Van NTP should be immune from this sort of behaviour unless you did a ntpdate at the wrong moment. The clocks should have been marked as insane. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kwallace at pcconnection.com Tue Nov 20 02:08:57 2012 From: kwallace at pcconnection.com (Wallace Keith) Date: Mon, 19 Nov 2012 21:08:57 -0500 Subject: NTP Issues Today In-Reply-To: <20121120014149.3C1242B698CC@drugs.dv.isc.org> References: <20121120014149.3C1242B698CC@drugs.dv.isc.org> Message-ID: Just got paged with a pbx alarm that had 1970 as the year. By the time I logged in , it was showing 2012. Using GPS for time and date. -----Original Message----- From: Mark Andrews [mailto:marka at isc.org] Sent: Monday, November 19, 2012 8:42 PM To: Van Wolfe Cc: nanog at nanog.org Subject: Re: NTP Issues Today In message , Van Wolfe writes: > Hello, > > Did anyone else experience issues with NTP today? We had our server > times update to the year 2000 at around 3:30 MT, then revert back to 2012. > > Thanks, > Van NTP should be immune from this sort of behaviour unless you did a ntpdate at the wrong moment. The clocks should have been marked as insane. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From george.herbert at gmail.com Tue Nov 20 03:28:06 2012 From: george.herbert at gmail.com (George Herbert) Date: Mon, 19 Nov 2012 19:28:06 -0800 Subject: NTP Issues Today In-Reply-To: References: <20121120014149.3C1242B698CC@drugs.dv.isc.org> Message-ID: crossreplying to outages list. Is anyone ELSE seeing GPS issues? This could well have been an unrelated issue on that particular PBX. If this was real, then the mother of all infrastructure attacks might be underway... One glitch on tick and tock and one malfunctioning PBX is not sufficient evidence of pattern - much less hostile activity - to induce panic, but it would perhaps be a wise time to check time-related logs? -george On Mon, Nov 19, 2012 at 6:08 PM, Wallace Keith wrote: > Just got paged with a pbx alarm that had 1970 as the year. By the time I logged in , it was showing 2012. Using GPS for time and date. > > -----Original Message----- > From: Mark Andrews [mailto:marka at isc.org] > Sent: Monday, November 19, 2012 8:42 PM > To: Van Wolfe > Cc: nanog at nanog.org > Subject: Re: NTP Issues Today > > > In message > , Van Wolfe writes: >> Hello, >> >> Did anyone else experience issues with NTP today? We had our server >> times update to the year 2000 at around 3:30 MT, then revert back to 2012. >> >> Thanks, >> Van > > NTP should be immune from this sort of behaviour unless you did a ntpdate at the wrong moment. The clocks should have been marked as insane. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -- -george william herbert george.herbert at gmail.com From mike.lyon at gmail.com Tue Nov 20 04:17:11 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 19 Nov 2012 20:17:11 -0800 Subject: [outages] NTP Issues Today In-Reply-To: <8C51AAEB-E218-4BC8-A84B-72202AA87B5F@ctigroup.com> References: <20121120014149.3C1242B698CC@drugs.dv.isc.org> <8C51AAEB-E218-4BC8-A84B-72202AA87B5F@ctigroup.com> Message-ID: Anyone check out the NIST GPS Archive? http://www.nist.gov/pml/div688/grp40/gpsarchive.cfm -Mike On Mon, Nov 19, 2012 at 7:58 PM, Sid Rao wrote: > We had multiple servers synchronized with Windows/MS time change their > clock to the year 2000 today. It broke many things, including AD > authentication. > > These servers had been properly synchronized for years. > > They were synchronized with Microsoft and NIST NTP servers. > > This may not be isolated. > > Sid Rao | CTI Group | +1 (317) 262-4677 > > On Nov 19, 2012, at 10:29 PM, "George Herbert" > wrote: > > > crossreplying to outages list. > > > > Is anyone ELSE seeing GPS issues? This could well have been an > > unrelated issue on that particular PBX. > > > > If this was real, then the mother of all infrastructure attacks might > > be underway... > > > > One glitch on tick and tock and one malfunctioning PBX is not > > sufficient evidence of pattern - much less hostile activity - to > > induce panic, but it would perhaps be a wise time to check > > time-related logs? > > > > > > -george > > > > On Mon, Nov 19, 2012 at 6:08 PM, Wallace Keith > > wrote: > >> Just got paged with a pbx alarm that had 1970 as the year. By the time > I logged in , it was showing 2012. Using GPS for time and date. > >> > >> -----Original Message----- > >> From: Mark Andrews [mailto:marka at isc.org] > >> Sent: Monday, November 19, 2012 8:42 PM > >> To: Van Wolfe > >> Cc: nanog at nanog.org > >> Subject: Re: NTP Issues Today > >> > >> > >> In message < > CAMeggd4cDQwhxQE_JbvpNR-PKKe9LXqA+KzJ97anHFonjwZhdQ at mail.gmail.com> > >> , Van Wolfe writes: > >>> Hello, > >>> > >>> Did anyone else experience issues with NTP today? We had our server > >>> times update to the year 2000 at around 3:30 MT, then revert back to > 2012. > >>> > >>> Thanks, > >>> Van > >> > >> NTP should be immune from this sort of behaviour unless you did a > ntpdate at the wrong moment. The clocks should have been marked as insane. > >> > >> Mark > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > >> > >> > > > > > > > > -- > > -george william herbert > > george.herbert at gmail.com > > > > > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From jlewis at lewis.org Tue Nov 20 06:25:06 2012 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 20 Nov 2012 01:25:06 -0500 (EST) Subject: fiber termination tools Message-ID: We've always done our own fiber termination in-house using Corning Unicam (currently Unicam Pretium) tool kits and ends. Over the years I've dealt with fiber (primarily 62.5um mm FDDI), I've noticed that fiber seems to come in two "styles". Some lets me strip the buffer and coating easily in separate steps using the buffer/coating dual-notch mechanical stripper from our Corning tool kit. Some, it seems the buffer and coating are fused and the coating comes off with the buffer, but because both are being stripped at the same time, much more pulling force is needed, and the buffer/coating has to be removed in small steps or the fiber breaks :( First, I wonder if anyone knows why this is? Second, I wonder if a thermal stripper would help and is preferable to a strictly mechanical stripper? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From derek at derekivey.com Tue Nov 20 07:35:23 2012 From: derek at derekivey.com (Derek Ivey) Date: Tue, 20 Nov 2012 02:35:23 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan Message-ID: <50AB32BB.4010508@derekivey.com> I saw this on Reddit and thought it was fascinating. I figured I'd share it here too since no one else did. http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-manhattan-hurricane-sandy Derek From carlos at race.com Tue Nov 20 08:35:15 2012 From: carlos at race.com (Carlos Alcantar) Date: Tue, 20 Nov 2012 08:35:15 +0000 Subject: Fiber terminations -- UPC vs APC In-Reply-To: Message-ID: +1 here on going all APC on the panels, note we run a gpon network so making that choice was fairly easy for us. You do end up having to use a lot of sc or lc/upc - sc/apc patch cables on the colo equipment side of things but everything out in the field is 100% sc/apc. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com -----Original Message----- From: Lamar Owen Date: Monday, November 19, 2012 2:30 PM To: Jeff Kell Cc: "nanog at nanog.org" Subject: Re: Fiber terminations -- UPC vs APC On Nov 19, 2012, at 4:37 PM, Jeff Kell wrote: > Looking for some guidance/references on the use of UPC versus APC > terminations on fiber > cabling. Traditionally we have done all of our fiber plant > targeting data usage with > UPC connectors. We are also looking at proposals for fiber > distribution plant for > video, and the possibility of using some of the existing fiber plant > for that purpose; > as well as any new fiber plant that gets installed for video > potentially as data. > > The video folks are set, determined, and insistent that they need > APC terminations. APC is pretty much the standard for high-power video distribution, and for very good reasons. The return loss is much better for APC than for UPC, for instance, and that can be very significant depending upon the equipment being used to drive. Much video distribution gear, including passive splitters and EDFA's, are only available with APC connectors. Mating an APC to a UPC will result in an 'air-gap attenuator' being created, and that may be a problem. A significant problem for some gear, in fact. Really high-power long-haul gear may need APC as well, even for networking stuff. Your choice boils down to parallel plants or only APC with UPC jumpers for non-APC equipment. You really really don't want to have any UPC connectors in a really high-power path that needs APC all the way; I have actually seen some warranty statements, for some older equipment, primarily EDFA modules, that indicate that the warranty would be voided if any non-APC connectors were in the path anywhere. The reflections from a UPC end can detune some of these lasers, and can, in theory at least, cause permanent transmitter damage that won't be under warranty. You could, though, provision half APC and half UPC, since the color coding is pretty clear. You can even use, say, all LC on your UPC patches and all SC on you APC patches or similar, and get both with little danger of intermating. I think I'd personally rather just provision all APC in the backbone fiber runs and install APC to UPC distribution runs to your network gear. But you'll have to train people to always plug green connectors into green connectors, and blue into blue, and never should green and blue mix. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5571 bytes Desc: not available URL: From tpoder at cis.vutbr.cz Tue Nov 20 09:14:18 2012 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Tue, 20 Nov 2012 10:14:18 +0100 Subject: Big day for IPv6 - 1% native penetration Message-ID: <50AB49EA.3030101@cis.vutbr.cz> Hi, It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) T. From mail at danrl.de Tue Nov 20 12:01:46 2012 From: mail at danrl.de (Dan Luedtke) Date: Tue, 20 Nov 2012 13:01:46 +0100 Subject: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker In-Reply-To: <62D64EAC-80D1-4D85-BEB6-3F968705C5A2@delong.com> References: <50A97866.6080305@bryanfields.net> <62D64EAC-80D1-4D85-BEB6-3F968705C5A2@delong.com> Message-ID: <20121120130146.7b26ae5c@marvin.nonattached.net> On Sun, 18 Nov 2012 21:40:45 -0800 Owen DeLong wrote: > Setting up a proper IPv6 subnet and unique gateway for each VM is > probably insane, but, potentially less insane than some other > alternatives. I second that! I give out a proper configured /64 to every "customer" regardless of he has one, two or more VMs in his network. The alternatives did not work for us, furthermore scaling the networks is reduced to drop in more VMs until the /64 runs out of addresses (read: never) OR the situation calls for other setups anyway. Receiving a /112 should make one at least thinking about the underlying network design for a minute. It just looks awkward! Cheers Dan From aaron.toponce at gmail.com Tue Nov 20 13:31:44 2012 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Tue, 20 Nov 2012 06:31:44 -0700 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50AB49EA.3030101@cis.vutbr.cz> References: <50AB49EA.3030101@cis.vutbr.cz> Message-ID: <20121120133142.GP3070@irc.ae7.st> On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: > It seems that today is a "big day" for IPv6. It is the very first > time when native IPv6 on google statistics > (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some > might say it is tremendous success after 16 years of deploying IPv6 :-) And given the rate on that graph, we'll hit 2% before year-end 2013. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From owen at delong.com Tue Nov 20 13:45:48 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Nov 2012 05:45:48 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121120133142.GP3070@irc.ae7.st> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: It is entirely possible that Google's numbers are artificially low for a number of reasons. Owen On Nov 20, 2012, at 5:31 AM, Aaron Toponce wrote: > On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: >> It seems that today is a "big day" for IPv6. It is the very first >> time when native IPv6 on google statistics >> (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some >> might say it is tremendous success after 16 years of deploying IPv6 :-) > > And given the rate on that graph, we'll hit 2% before year-end 2013. > > -- > . o . o . o . . o o . . . o . > . . o . o o o . o . o o . . o > o o o . o . . o o o o . o o o From rps at maine.edu Tue Nov 20 13:58:21 2012 From: rps at maine.edu (Ray Soucy) Date: Tue, 20 Nov 2012 08:58:21 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: Or artificially high ... On Tue, Nov 20, 2012 at 8:45 AM, Owen DeLong wrote: > It is entirely possible that Google's numbers are artificially low for a number > of reasons. > > Owen > > On Nov 20, 2012, at 5:31 AM, Aaron Toponce wrote: > >> On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: >>> It seems that today is a "big day" for IPv6. It is the very first >>> time when native IPv6 on google statistics >>> (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some >>> might say it is tremendous success after 16 years of deploying IPv6 :-) >> >> And given the rate on that graph, we'll hit 2% before year-end 2013. >> >> -- >> . o . o . o . . o o . . . o . >> . . o . o o o . o . o o . . o >> o o o . o . . o o o o . o o o > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From wmaton at ottix.net Tue Nov 20 14:02:53 2012 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Tue, 20 Nov 2012 09:02:53 -0500 (EST) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: APNIC labs have an interesting set of numbers on IPv6 uptake as well. http://labs.apnic.net/measureipv6/ On Tue, 20 Nov 2012, Owen DeLong wrote: > It is entirely possible that Google's numbers are artificially low for a number > of reasons. > > Owen > > On Nov 20, 2012, at 5:31 AM, Aaron Toponce wrote: > >> On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: >>> It seems that today is a "big day" for IPv6. It is the very first >>> time when native IPv6 on google statistics >>> (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some >>> might say it is tremendous success after 16 years of deploying IPv6 :-) >> >> And given the rate on that graph, we'll hit 2% before year-end 2013. >> >> -- >> . o . o . o . . o o . . . o . >> . . o . o o o . o . o o . . o >> o o o . o . . o o o o . o o o > > > wfms From alh-ietf at tndh.net Tue Nov 20 14:53:54 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 20 Nov 2012 06:53:54 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50AB49EA.3030101@cis.vutbr.cz> References: <50AB49EA.3030101@cis.vutbr.cz> Message-ID: <006201cdc72e$dce4af10$96ae0d30$@tndh.net> Tomas Podermanski wrote: > > Hi, > > It seems that today is a "big day" for IPv6. It is the very first time when > native IPv6 on google statistics > (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some > might say it is tremendous success after 16 years of deploying IPv6 :-) > > T. Or one could look at it as; despite 16 years of lethargy and lack of deployment by access networks, the traffic still finds a way. ;) Tony From oliver at g.garraux.net Tue Nov 20 14:57:40 2012 From: oliver at g.garraux.net (Oliver Garraux) Date: Tue, 20 Nov 2012 09:57:40 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: So, I assume 6in4 tunnels like HE.net are included in the "native" percentage? Oliver ------------------------------------- Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux On Tue, Nov 20, 2012 at 9:02 AM, William F. Maton Sotomayor wrote: > > APNIC labs have an interesting set of numbers on IPv6 uptake as well. > > http://labs.apnic.net/measureipv6/ > > > On Tue, 20 Nov 2012, Owen DeLong wrote: > >> It is entirely possible that Google's numbers are artificially low for a >> number >> of reasons. >> >> Owen >> >> On Nov 20, 2012, at 5:31 AM, Aaron Toponce >> wrote: >> >>> On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: >>>> >>>> It seems that today is a "big day" for IPv6. It is the very first >>>> time when native IPv6 on google statistics >>>> (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some >>>> might say it is tremendous success after 16 years of deploying IPv6 :-) >>> >>> >>> And given the rate on that graph, we'll hit 2% before year-end 2013. >>> >>> -- >>> . o . o . o . . o o . . . o . >>> . . o . o o o . o . o o . . o >>> o o o . o . . o o o o . o o o >> >> >> >> > > wfms > From sander at steffann.nl Tue Nov 20 15:06:00 2012 From: sander at steffann.nl (Sander Steffann) Date: Tue, 20 Nov 2012 16:06:00 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: <85895738-B721-409D-ADEC-8620FBCB8B63@steffann.nl> Hi, > So, I assume 6in4 tunnels like HE.net are included in the "native" percentage? As the traffic is delivered as native traffic to Google I don't think Google can even see that there is a tunnel between them and the user. They might see a lower MTU, but to Google the traffic is native IPv6. - Sander From bmanning at vacation.karoshi.com Tue Nov 20 15:12:31 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 20 Nov 2012 15:12:31 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: <20121120151231.GA30432@vacation.karoshi.com.> Dr. Frederick Frankenstein: LIFE! DO YOU HEAR ME? GIVE MY CREATION... LIFE! > >> > >>> On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: > >>>> > >>>> It seems that today is a "big day" for IPv6. It is the very first > >>>> time when native IPv6 on google statistics > >>>> (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some > >>>> might say it is tremendous success after 16 years of deploying IPv6 :-) > >>> > >>> > >>> And given the rate on that graph, we'll hit 2% before year-end 2013. > >>> From tore.anderson at redpill-linpro.com Tue Nov 20 15:13:51 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 20 Nov 2012 16:13:51 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: <50AB9E2F.5020304@redpill-linpro.com> * Oliver Garraux > So, I assume 6in4 tunnels like HE.net are included in the "native" > percentage? Probably. Fortunately, they are a drop in the ocean (at least from my point of view). -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From owen at delong.com Tue Nov 20 15:23:34 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Nov 2012 07:23:34 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: 6to4 tunnels, no. 6in4 (such as tunnel broker), yes, those are part of the native count. Owen On Nov 20, 2012, at 6:57 AM, Oliver Garraux wrote: > So, I assume 6in4 tunnels like HE.net are included in the "native" percentage? > > Oliver > > ------------------------------------- > > Oliver Garraux > Check out my blog: www.GetSimpliciti.com/blog > Follow me on Twitter: twitter.com/olivergarraux > > > On Tue, Nov 20, 2012 at 9:02 AM, William F. Maton Sotomayor > wrote: >> >> APNIC labs have an interesting set of numbers on IPv6 uptake as well. >> >> http://labs.apnic.net/measureipv6/ >> >> >> On Tue, 20 Nov 2012, Owen DeLong wrote: >> >>> It is entirely possible that Google's numbers are artificially low for a >>> number >>> of reasons. >>> >>> Owen >>> >>> On Nov 20, 2012, at 5:31 AM, Aaron Toponce >>> wrote: >>> >>>> On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: >>>>> >>>>> It seems that today is a "big day" for IPv6. It is the very first >>>>> time when native IPv6 on google statistics >>>>> (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some >>>>> might say it is tremendous success after 16 years of deploying IPv6 :-) >>>> >>>> >>>> And given the rate on that graph, we'll hit 2% before year-end 2013. >>>> >>>> -- >>>> . o . o . o . . o o . . . o . >>>> . . o . o o o . o . o o . . o >>>> o o o . o . . o o o o . o o o >>> >>> >>> >>> >> >> wfms >> From owen at delong.com Tue Nov 20 15:24:30 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Nov 2012 07:24:30 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <85895738-B721-409D-ADEC-8620FBCB8B63@steffann.nl> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> <85895738-B721-409D-ADEC-8620FBCB8B63@steffann.nl> Message-ID: On Nov 20, 2012, at 7:06 AM, Sander Steffann wrote: > Hi, > >> So, I assume 6in4 tunnels like HE.net are included in the "native" percentage? > > As the traffic is delivered as native traffic to Google I don't think Google can even see that there is a tunnel between them and the user. They might see a lower MTU, but to Google the traffic is native IPv6. > > - Sander > That's only really true of the 6in4 (tunnel broker) tunnels. The 6to4 traffic that comes through our 6to4 or any other 6to4 gateways, OTOH, will have 2002::/16 addresses which makes it just as obvious as Teredo. Owen From morrowc.lists at gmail.com Tue Nov 20 15:30:12 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Nov 2012 10:30:12 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: <50AB32BB.4010508@derekivey.com> References: <50AB32BB.4010508@derekivey.com> Message-ID: On Tue, Nov 20, 2012 at 2:35 AM, Derek Ivey wrote: > I saw this on Reddit and thought it was fascinating. I figured I'd share it > here too since no one else did. > > http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-manhattan-hurricane-sandy > hey lookie! 'free uprades'! also, one wonders what the bill is for such upgrades, and what the implications are for state-run-disaster relief vs national-level-disaster-relief? Also, how much of the VZ issue (phone stuff) is going to end up being caught in VZ's financials vs disaster-relief-funds ? -chris From rol at witbe.net Tue Nov 20 15:32:14 2012 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Tue, 20 Nov 2012 16:32:14 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50AB49EA.3030101@cis.vutbr.cz> References: <50AB49EA.3030101@cis.vutbr.cz> Message-ID: <20121120163214.794af87b@tux.DEF.witbe.net> Hello, On Tue, 20 Nov 2012 10:14:18 +0100 Tomas Podermanski wrote: > It seems that today is a "big day" for IPv6. It is the very first > time when native IPv6 on google statistics > (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some > might say it is tremendous success after 16 years of deploying IPv6 :-) Funny enough, the peaks are indicating... week-ends ! Do people use more google during the WE, or do they have more IPv6 @ home ? Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From srao at ctigroup.com Tue Nov 20 03:58:15 2012 From: srao at ctigroup.com (Sid Rao) Date: Tue, 20 Nov 2012 03:58:15 +0000 Subject: NTP Issues Today In-Reply-To: References: <20121120014149.3C1242B698CC@drugs.dv.isc.org> , Message-ID: <8C51AAEB-E218-4BC8-A84B-72202AA87B5F@ctigroup.com> We had multiple servers synchronized with Windows/MS time change their clock to the year 2000 today. It broke many things, including AD authentication. These servers had been properly synchronized for years. They were synchronized with Microsoft and NIST NTP servers. This may not be isolated. Sid Rao | CTI Group | +1 (317) 262-4677 On Nov 19, 2012, at 10:29 PM, "George Herbert" wrote: > crossreplying to outages list. > > Is anyone ELSE seeing GPS issues? This could well have been an > unrelated issue on that particular PBX. > > If this was real, then the mother of all infrastructure attacks might > be underway... > > One glitch on tick and tock and one malfunctioning PBX is not > sufficient evidence of pattern - much less hostile activity - to > induce panic, but it would perhaps be a wise time to check > time-related logs? > > > -george > > On Mon, Nov 19, 2012 at 6:08 PM, Wallace Keith > wrote: >> Just got paged with a pbx alarm that had 1970 as the year. By the time I logged in , it was showing 2012. Using GPS for time and date. >> >> -----Original Message----- >> From: Mark Andrews [mailto:marka at isc.org] >> Sent: Monday, November 19, 2012 8:42 PM >> To: Van Wolfe >> Cc: nanog at nanog.org >> Subject: Re: NTP Issues Today >> >> >> In message >> , Van Wolfe writes: >>> Hello, >>> >>> Did anyone else experience issues with NTP today? We had our server >>> times update to the year 2000 at around 3:30 MT, then revert back to 2012. >>> >>> Thanks, >>> Van >> >> NTP should be immune from this sort of behaviour unless you did a ntpdate at the wrong moment. The clocks should have been marked as insane. >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> >> > > > > -- > -george william herbert > george.herbert at gmail.com > > From attilavekas at gmail.com Tue Nov 20 06:18:13 2012 From: attilavekas at gmail.com (Attila Vekas) Date: Tue, 20 Nov 2012 17:18:13 +1100 Subject: Technical help required to check routing or filtering of Gobal IP routing range: 1.128.0.0 - 1.159.255.255 in the Level 3 Network Space. Message-ID: Hi All, I need technicial assistance with either a routing or ip restrication problem impacting our mobile ip customers in Australia. Customers using our Mobile Network are allocated an address in the 1.128.0.0 - 1.159.255.255 range to allow communication on the internet. I have a customer's who can't reach websites hosted oversea where the like cause appears to be some were in the Level 3 routing domain (I suspect). 1. Customer A trying to get www.readingeggs.com.au fails when using a Mobile Internet connection. C:\Documents and Settings\c832677>tracert www.readingeggs.com.au Tracing route to readingeggs.com.au [209.251.186.131] over a maximum of 30 hops: 1 458 ms 419 ms 539 ms 10.5.81.50 2 * * * Request timed out. 3 * * * Request timed out. 4 350 ms 659 ms 659 ms bundle-ether12.pie8.perth.telstra.net[120.151.2 55.17] 5 578 ms 629 ms 449 ms bundle-ether1.pie-core1.perth.telstra.net[203.5 0.6.221] 6 448 ms 509 ms 539 ms bundle-ether6.way-core4.adelaide.telstra.net[20 3.50.11.16] 7 457 ms 549 ms 529 ms bundle-ether9.exi-core1.melbourne.telstra.net[2 03.50.11.93] 8 468 ms 509 ms 539 ms bundle-ether12.chw-core2.sydney.telstra.net[203 .50.11.74] 9 458 ms 709 ms 559 ms bundle-ether1.oxf-gw2.sydney.telstra.net[203.50 .6.90] 10 448 ms 519 ms 789 ms 203.50.13.174 11 597 ms 759 ms 709 ms i-0-0-0-0.paix-core01.bx.telstraglobal.net[202. 84.140.145] 12 649 ms 659 ms 730 ms i-0-0-0-0.eqnx-core01.bi.telstraglobal.net[202. 84.140.142] 13 579 ms 719 ms 709 ms i-0-0-0-3.eqnx03.bi.telstraglobal.net[202.84.25 1.126] 14 599 ms 689 ms 689 ms l3-peer.eqnx03.pr.telstraglobal.net[134.159.61. 6] 15 618 ms 689 ms 689 ms ae-22-70.car2.SanJose1.Level3.net[4.69.152.68] 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. A successful traceroute to www.readingeggs.com is shown below and was obtained from a fix-line connection to the internet: C:\Documents and Settings\c832677>tracert www.readingeggs.com.au Tracing route to readingeggs.com.au [209.251.186.131] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 10.0.0.1 2 1 ms 1 ms 1 ms gigabitethernet2-16.lon69.melbourne.telstra.net[139.130.43.29] 3 4 ms 2 ms 3 ms bundle-ether3.exi-core1.melbourne.telstra.net [203.50.80.1] 4 23 ms 23 ms 23 ms bundle-ether12.chw-core2.sydney.telstra.net[203 .50.11.74] 5 22 ms 23 ms 23 ms bundle-ether1.oxf-gw2.sydney.telstra.net[203.50 .6.90] 6 16 ms 16 ms 16 ms tengigabitethernet14-0.sydo-core01.sydney.reach.com [203.50.13.42] 7 159 ms 158 ms 158 ms i-0-6-2-0.paix-core01.bx.telstraglobal.net[202. 84.140.90] 8 193 ms 192 ms 192 ms i-0-7-2-0.eqnx-core01.bi.telstraglobal.net[202. 84.140.30] 9 193 ms 193 ms 193 ms i-0-0-0-1.eqnx03.bi.telstraglobal.net[202.84.25 1.50] 10 208 ms 191 ms 208 ms l3-peer.eqnx03.pr.telstraglobal.net[134.159.61. 6] 11 209 ms 209 ms 209 ms ae-42-90.car2.SanJose1.Level3.net[4.69.152.196] 12 193 ms 193 ms 193 ms DATA-RETURN.car2.SanJose1.Level3.net[4.53.18.13 4] 13 234 ms 234 ms 234 ms t0-0-0-1.br1.stc.terremark.net[66.165.161.169] 14 235 ms 234 ms 234 ms po14.br1.mia.terremark.net [66.165.160.225] 15 359 ms 248 ms 250 ms t8-1.gw1.mia.terremark.net [66.165.161.82] 16 234 ms 234 ms 237 ms 66.165.170.14 17 229 ms 229 ms 229 ms 72.46.239.94 18 233 ms 233 ms 232 ms 209.251.186.131 In the above examples the source IP for the failed traceroute from the Australia's Mobile Network was a 1.126.42.153 address (Telstra) and for the working traceroute from the fix-line it was 139.130.43.29. It appears the path is being treated differently between routers: ae-22-70.car2.SanJose1.Level3.net [4.69.152.68] & ae-42-90.car2.SanJose1.Level3.net [4.69.152.196] from the Telstra Global Router. I am looking for network help and confirmation that the source network 1.128.0.0 - 1.159.255.255 is being routed correctly back to Telstra's network in Australia correctly on the SanJose - Level3 routers. Also check if any bogan filtering is in the network that could be blocking the source ranges from reaching the hosting URL. Regards, Attila Vekas Telstra From robert at ufl.edu Tue Nov 20 16:04:46 2012 From: robert at ufl.edu (Scott, Robert D.) Date: Tue, 20 Nov 2012 16:04:46 +0000 Subject: Technical help required to check routing or filtering of Gobal IP routing range: 1.128.0.0 - 1.159.255.255 in the Level 3 Network Space. In-Reply-To: References: Message-ID: <14384A642243C34495DE884D7E13C83E229E9EE8@UFEXCH-MBXN04.ad.ufl.edu> http://lookingglass.level3.net/ Should get U what U need. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone UF Information Technology 352-392-2061 CNS Phone Tree CNS - Network Services 352-273-0743 FAX University of Florida 352-294-3571 FLR NOC Florida Lambda Rail 321-663-0421 Cell Gainesville, FL 32611 3216630421 at messaging.sprintpcs.com -----Original Message----- From: Attila Vekas [mailto:attilavekas at gmail.com] Sent: Tuesday, November 20, 2012 1:18 AM To: NANOG at nanog.org Subject: Technical help required to check routing or filtering of Gobal IP routing range: 1.128.0.0 - 1.159.255.255 in the Level 3 Network Space. Hi All, I need technicial assistance with either a routing or ip restrication problem impacting our mobile ip customers in Australia. Customers using our Mobile Network are allocated an address in the 1.128.0.0 - 1.159.255.255 range to allow communication on the internet. I have a customer's who can't reach websites hosted oversea where the like cause appears to be some were in the Level 3 routing domain (I suspect). 1. Customer A trying to get www.readingeggs.com.au fails when using a Mobile Internet connection. C:\Documents and Settings\c832677>tracert www.readingeggs.com.au Tracing route to readingeggs.com.au [209.251.186.131] over a maximum of 30 hops: 1 458 ms 419 ms 539 ms 10.5.81.50 2 * * * Request timed out. 3 * * * Request timed out. 4 350 ms 659 ms 659 ms bundle-ether12.pie8.perth.telstra.net[120.151.2 55.17] 5 578 ms 629 ms 449 ms bundle-ether1.pie-core1.perth.telstra.net[203.5 0.6.221] 6 448 ms 509 ms 539 ms bundle-ether6.way-core4.adelaide.telstra.net[20 3.50.11.16] 7 457 ms 549 ms 529 ms bundle-ether9.exi-core1.melbourne.telstra.net[2 03.50.11.93] 8 468 ms 509 ms 539 ms bundle-ether12.chw-core2.sydney.telstra.net[203 .50.11.74] 9 458 ms 709 ms 559 ms bundle-ether1.oxf-gw2.sydney.telstra.net[203.50 .6.90] 10 448 ms 519 ms 789 ms 203.50.13.174 11 597 ms 759 ms 709 ms i-0-0-0-0.paix-core01.bx.telstraglobal.net[202. 84.140.145] 12 649 ms 659 ms 730 ms i-0-0-0-0.eqnx-core01.bi.telstraglobal.net[202. 84.140.142] 13 579 ms 719 ms 709 ms i-0-0-0-3.eqnx03.bi.telstraglobal.net[202.84.25 1.126] 14 599 ms 689 ms 689 ms l3-peer.eqnx03.pr.telstraglobal.net[134.159.61. 6] 15 618 ms 689 ms 689 ms ae-22-70.car2.SanJose1.Level3.net[4.69.152.68] 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. A successful traceroute to www.readingeggs.com is shown below and was obtained from a fix-line connection to the internet: C:\Documents and Settings\c832677>tracert www.readingeggs.com.au Tracing route to readingeggs.com.au [209.251.186.131] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 10.0.0.1 2 1 ms 1 ms 1 ms gigabitethernet2-16.lon69.melbourne.telstra.net[139.130.43.29] 3 4 ms 2 ms 3 ms bundle-ether3.exi-core1.melbourne.telstra.net [203.50.80.1] 4 23 ms 23 ms 23 ms bundle-ether12.chw-core2.sydney.telstra.net[203 .50.11.74] 5 22 ms 23 ms 23 ms bundle-ether1.oxf-gw2.sydney.telstra.net[203.50 .6.90] 6 16 ms 16 ms 16 ms tengigabitethernet14-0.sydo-core01.sydney.reach.com [203.50.13.42] 7 159 ms 158 ms 158 ms i-0-6-2-0.paix-core01.bx.telstraglobal.net[202. 84.140.90] 8 193 ms 192 ms 192 ms i-0-7-2-0.eqnx-core01.bi.telstraglobal.net[202. 84.140.30] 9 193 ms 193 ms 193 ms i-0-0-0-1.eqnx03.bi.telstraglobal.net[202.84.25 1.50] 10 208 ms 191 ms 208 ms l3-peer.eqnx03.pr.telstraglobal.net[134.159.61. 6] 11 209 ms 209 ms 209 ms ae-42-90.car2.SanJose1.Level3.net[4.69.152.196] 12 193 ms 193 ms 193 ms DATA-RETURN.car2.SanJose1.Level3.net[4.53.18.13 4] 13 234 ms 234 ms 234 ms t0-0-0-1.br1.stc.terremark.net[66.165.161.169] 14 235 ms 234 ms 234 ms po14.br1.mia.terremark.net [66.165.160.225] 15 359 ms 248 ms 250 ms t8-1.gw1.mia.terremark.net [66.165.161.82] 16 234 ms 234 ms 237 ms 66.165.170.14 17 229 ms 229 ms 229 ms 72.46.239.94 18 233 ms 233 ms 232 ms 209.251.186.131 In the above examples the source IP for the failed traceroute from the Australia's Mobile Network was a 1.126.42.153 address (Telstra) and for the working traceroute from the fix-line it was 139.130.43.29. It appears the path is being treated differently between routers: ae-22-70.car2.SanJose1.Level3.net [4.69.152.68] & ae-42-90.car2.SanJose1.Level3.net [4.69.152.196] from the Telstra Global Router. I am looking for network help and confirmation that the source network 1.128.0.0 - 1.159.255.255 is being routed correctly back to Telstra's network in Australia correctly on the SanJose - Level3 routers. Also check if any bogan filtering is in the network that could be blocking the source ranges from reaching the hosting URL. Regards, Attila Vekas Telstra From patrick at ianai.net Tue Nov 20 16:05:26 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 20 Nov 2012 11:05:26 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: On Nov 20, 2012, at 08:45 , Owen DeLong wrote: > It is entirely possible that Google's numbers are artificially low for a number > of reasons. AMS-IX publishes stats too: This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%. Why do you think Google's numbers are lower than the real total? -- TTFN, patrick > On Nov 20, 2012, at 5:31 AM, Aaron Toponce wrote: >> On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: >>> It seems that today is a "big day" for IPv6. It is the very first >>> time when native IPv6 on google statistics >>> (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some >>> might say it is tremendous success after 16 years of deploying IPv6 :-) >> >> And given the rate on that graph, we'll hit 2% before year-end 2013. >> >> -- >> . o . o . o . . o o . . . o . >> . . o . o o o . o . o o . . o >> o o o . o . . o o o o . o o o > > From tom at cloudflare.com Tue Nov 20 16:25:43 2012 From: tom at cloudflare.com (Tom Paseka) Date: Tue, 20 Nov 2012 08:25:43 -0800 Subject: Technical help required to check routing or filtering of Gobal IP routing range: 1.128.0.0 - 1.159.255.255 in the Level 3 Network Space. In-Reply-To: References: Message-ID: G'day! On Mon, Nov 19, 2012 at 10:18 PM, Attila Vekas wrote: > Regards, > > Attila Vekas > > Telstra I'd say its AS23148 / Terremark with a bogon filter. your fixed line traceroute shows the next-hop being the connection between level3 and AS23148. >10 208 ms 191 ms 208 ms l3-peer.eqnx03.pr.telstraglobal.net[134.159.61.6] >11 209 ms 209 ms 209 ms ae-42-90.car2.SanJose1.Level3.net[4.69.152.196] >12 193 ms 193 ms 193 ms DATA-RETURN.car2.SanJose1.Level3.net[4.53.18.134] Cheers, Tom From bicknell at ufp.org Tue Nov 20 16:38:26 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 20 Nov 2012 08:38:26 -0800 Subject: NTP Issues Today In-Reply-To: References: Message-ID: <20121120163826.GA60716@ussenterprise.ufp.org> In a message written on Mon, Nov 19, 2012 at 04:21:55PM -0700, Van Wolfe wrote: > Did anyone else experience issues with NTP today? We had our server > times update to the year 2000 at around 3:30 MT, then revert back to 2012. I'm surprised the various time geeks aren't all posting their logs, so I'll kick off: /tmp/parse-peerstats.pl peerstats.20121119 56250 76367.354 192.5.41.41 91b4 -378691200.312258363 0.088274002 0.014835425 0.263515353 56250 77391.354 192.5.41.41 91b4 -378691200.312258363 0.088274002 0.018668790 0.263749719 56250 78204.354 192.5.41.40 90b4 -378691200.785377324 0.088179350 0.014812585 0.263668835 56250 78416.355 192.5.41.41 91b4 -378691200.785974681 0.088312507 0.014832943 0.209966600 56250 79229.355 192.5.41.40 90b4 -378691200.785377324 0.088179350 0.018668723 378691200.785523713 56250 79442.355 192.5.41.41 91b4 -378691200.785974681 0.088312507 0.018689918 378691200.786114931 Or in more human readable form: /tmp/parse-peerstats.pl peerstats.20121119 192.5.41.41 off by -378691200.312258363 192.5.41.41 off by -378691200.312258363 192.5.41.40 off by -378691200.785377324 192.5.41.41 off by -378691200.785974681 192.5.41.40 off by -378691200.785377324 192.5.41.41 off by -378691200.785974681 The script, if you want to run against your own stats: #!/usr/bin/perl while (<>) { chomp; ($day, $second, $addr, $status, $offset, $delay, $disp, $skew) = split; if (($offset > 10) || ($offset < -10)) { # print "$addr off by $offset\n"; # More human friendly print "$_\n"; # Full details } } It just looks for servers off by more than 10 econds and then prints the line. 378691200 seconds is ~12 years, which lines up with the year 2000 dates some are reporting. The IP's are tick.usno.navy.mil and tock.usno.navy.mil. I can confirm from my vantage point that tick and tock both went about 12 years wrong on Nov 19th for a bit, I can also report that my NTP server with sufficient sources correctly determined they were haywire and ignored them. If your machines switched dates yesterday it probably means you're NTP infrastructure is insufficiently peered and diversified. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mike at mikejones.in Tue Nov 20 16:42:10 2012 From: mike at mikejones.in (Mike Jones) Date: Tue, 20 Nov 2012 16:42:10 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: On 20 November 2012 16:05, Patrick W. Gilmore wrote: > On Nov 20, 2012, at 08:45 , Owen DeLong wrote: > >> It is entirely possible that Google's numbers are artificially low for a number >> of reasons. > > AMS-IX publishes stats too: > > > This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%. > > Why do you think Google's numbers are lower than the real total? > They are also different stats which is why they give such different numbers. In a theoretical world with evenly distributed traffic patterns if 1% of users were IPv6 enabled it would require 100% of content to be IPv6 enabled before your traffic stats would show 1% of traffic going over IPv6. If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement. - Mike From patrick at ianai.net Tue Nov 20 16:48:08 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 20 Nov 2012 11:48:08 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: On Nov 20, 2012, at 11:42 , Mike Jones wrote: > On 20 November 2012 16:05, Patrick W. Gilmore wrote: >> On Nov 20, 2012, at 08:45 , Owen DeLong wrote: >> >>> It is entirely possible that Google's numbers are artificially low for a number >>> of reasons. >> >> AMS-IX publishes stats too: >> >> >> This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%. >> >> Why do you think Google's numbers are lower than the real total? >> > > They are also different stats which is why they give such different numbers. > > In a theoretical world with evenly distributed traffic patterns if 1% > of users were IPv6 enabled it would require 100% of content to be IPv6 > enabled before your traffic stats would show 1% of traffic going over > IPv6. > > If these figures are representative (google saying 1% of users and > AMSIX saying 0.5% of traffic) then it would indicate that dual stacked > users can push ~50% of their traffic over IPv6. If this is even close > to reality then that would be quite an achievement. There is even more complexity. Remember the 6-to-4 stuff? Suppose a user on Network A used a tunnel broker on HE, and his traffic passed over AMS-IX encapsulated in v4? He would show up as v4 to AMS-IX and v6 to Google. Lies, damned lies, and graphs. :) -- TTFN, patrick From colinj at mx5.org.uk Tue Nov 20 17:02:06 2012 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 20 Nov 2012 17:02:06 +0000 Subject: [outages] NTP Issues Today In-Reply-To: <20121120153813.GA90675@icarus.home.lan> References: <20121120014149.3C1242B698CC@drugs.dv.isc.org> <8C51AAEB-E218-4BC8-A84B-72202AA87B5F@ctigroup.com> <20121120153813.GA90675@icarus.home.lan> Message-ID: <3B042CAD-265F-4E7D-9D44-FF4D97C60841@mx5.org.uk> On 20 Nov 2012, at 15:38, Jeremy Chadwick wrote: > I'm still waiting for someone who was affected by this to provide > coherent logs from ntpd showing exactly when the time change happened. > Getting these, at least on an *IX system, is far from difficult folks. > from firewall ntp logs Nov 19 09:58:06 [192.168.0.1.128.176] 2012:11:19-09:58:06 ntpd[21385]: ntpd exiting on signal 15 Nov 19 09:58:19 [192.168.0.1.128.176] 2012:11:19-09:58:19 selfmonng[3503]: W check Failed increment ntpd_running counter 3 - 3 Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W NOTIFYEVENT Name=ntpd_running Level=INFO Id=147 sent Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W triggerAction: 'cmd' Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W actionCmd(+): '/var/mdw/scripts/ntp restart' Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 ntpd[24120]: ntpd 4.2.4p8 at 1.1612-o Tue Feb 2 21:46:54 UTC 2010 (1) Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 selfmonng[3503]: W child returned status: exit='0' signal='0' Nov 19 09:58:35 [192.168.0.1.128.176] 2012:11:19-09:58:35 ntpd[24121]: kernel time sync status change 0001 was sync'd to 84.25.175.98, stratum 2 at the time I believe Colin From smeuse at mara.org Tue Nov 20 17:02:42 2012 From: smeuse at mara.org (Steve Meuse) Date: Tue, 20 Nov 2012 12:02:42 -0500 Subject: NTP Issues Today In-Reply-To: <20121120163826.GA60716@ussenterprise.ufp.org> References: <20121120163826.GA60716@ussenterprise.ufp.org> Message-ID: On Tue, Nov 20, 2012 at 11:38 AM, Leo Bicknell wrote: > > If your machines switched dates yesterday it probably means you're > NTP infrastructure is insufficiently peered and diversified. > If you take anything away from this thread, this is it.... -Steve From wesley.george at twcable.com Tue Nov 20 16:55:31 2012 From: wesley.george at twcable.com (George, Wes) Date: Tue, 20 Nov 2012 11:55:31 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: References: <50AB32BB.4010508@derekivey.com> Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > > > > http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-m > > anhattan-hurricane-sandy > > > > hey lookie! 'free uprades'! > [WEG] Better that than "we're going to replace all of this old technology with exactly the same stuff because that's what the standards document says to do" like happened in the rebuilding efforts for Katrina. I remember someone presenting about that rebuilding effort during NANOG years ago, and I asked about opportunities for improvement and upgrades and was really depressed at the missed opportunity it represented as they confirmed that they were in fact laying new copper... 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 colinj at mx5.org.uk Tue Nov 20 17:10:08 2012 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 20 Nov 2012 17:10:08 +0000 Subject: [outages] NTP Issues Today In-Reply-To: <20121120170545.GA92205@icarus.home.lan> References: <20121120014149.3C1242B698CC@drugs.dv.isc.org> <8C51AAEB-E218-4BC8-A84B-72202AA87B5F@ctigroup.com> <20121120153813.GA90675@icarus.home.lan> <3B042CAD-265F-4E7D-9D44-FF4D97C60841@mx5.org.uk> <20121120170545.GA92205@icarus.home.lan> Message-ID: <037DD709-D301-46CD-90F9-7C6F78F222EF@mx5.org.uk> no idea, re sigterm cause checked firewall system logs and could not see cause from that either times are GMT Colin On 20 Nov 2012, at 17:05, Jeremy Chadwick wrote: > Colin, > > Signal 15 = SIGTERM, so something intentionally shut ntpd down on your > side. The logs I'd be interested in would be prior to what you've > provided, i.e. what lead to the SIGTERM. > > Also, no timezone is mentioned anywhere in your timestamps, so please > provide that (UTC offset would be best). > > -- > | Jeremy Chadwick jdc at koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > On Tue, Nov 20, 2012 at 05:02:06PM +0000, Colin Johnston wrote: >> >> On 20 Nov 2012, at 15:38, Jeremy Chadwick wrote: >> >>> I'm still waiting for someone who was affected by this to provide >>> coherent logs from ntpd showing exactly when the time change happened. >>> Getting these, at least on an *IX system, is far from difficult folks. >>> >> >> from firewall ntp logs >> Nov 19 09:58:06 [192.168.0.1.128.176] 2012:11:19-09:58:06 ntpd[21385]: ntpd exiting on signal 15 >> Nov 19 09:58:19 [192.168.0.1.128.176] 2012:11:19-09:58:19 selfmonng[3503]: W check Failed increment ntpd_running counter 3 - 3 >> Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W NOTIFYEVENT Name=ntpd_running Level=INFO Id=147 sent >> Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W triggerAction: 'cmd' >> Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W actionCmd(+): '/var/mdw/scripts/ntp restart' >> Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 ntpd[24120]: ntpd 4.2.4p8 at 1.1612-o Tue Feb 2 21:46:54 UTC 2010 (1) >> Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 selfmonng[3503]: W child returned status: exit='0' signal='0' >> Nov 19 09:58:35 [192.168.0.1.128.176] 2012:11:19-09:58:35 ntpd[24121]: kernel time sync status change 0001 >> >> was sync'd to 84.25.175.98, stratum 2 at the time I believe >> >> Colin From morrowc.lists at gmail.com Tue Nov 20 17:10:27 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Nov 2012 12:10:27 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> Message-ID: On Tue, Nov 20, 2012 at 11:55 AM, George, Wes wrote: >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >> > >> > http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-m >> > anhattan-hurricane-sandy >> > >> >> hey lookie! 'free uprades'! >> > > [WEG] Better that than "we're going to replace all of this old technology with exactly the same stuff because that's what the standards document says to do" like happened in the rebuilding efforts for Katrina. I remember someone presenting about that rebuilding effort during NANOG years ago, and I asked about opportunities for improvement and upgrades and was really depressed at the missed opportunity it represented as they confirmed that they were in fact laying new copper... yea. it's acutally kinda nice that at least from CO -> building now there maybe more highspeed links... and maybe lower long term costs? Also, now VZ can sell the copper to all the rest of us for use in fiber camouflage! From joelja at bogus.com Tue Nov 20 17:26:41 2012 From: joelja at bogus.com (joel jaeggli) Date: Tue, 20 Nov 2012 09:26:41 -0800 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> Message-ID: <50ABBD51.8020502@bogus.com> On 11/20/12 9:10 AM, Christopher Morrow wrote: > On Tue, Nov 20, 2012 at 11:55 AM, George, Wes wrote: >>> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >>>> http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-m >>>> anhattan-hurricane-sandy >>>> >>> hey lookie! 'free uprades'! >>> >> [WEG] Better that than "we're going to replace all of this old technology with exactly the same stuff because that's what the standards document says to do" like happened in the rebuilding efforts for Katrina. I remember someone presenting about that rebuilding effort during NANOG years ago, and I asked about opportunities for improvement and upgrades and was really depressed at the missed opportunity it represented as they confirmed that they were in fact laying new copper... > yea. it's acutally kinda nice that at least from CO -> building now > there maybe more highspeed links... and maybe lower long term costs? > > Also, now VZ can sell the copper to all the rest of us for use in > fiber camouflage! 1200 pair is 5.5lbs per foot. That's somewhere in the neighborhood of $100k per mile at retail scrap prices. > > From faisal at snappydsl.net Tue Nov 20 17:49:09 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 20 Nov 2012 12:49:09 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> Message-ID: <50ABC295.10907@snappydsl.net> On 11/20/2012 12:10 PM, Christopher Morrow wrote: > it's acutally kinda nice that at least from CO -> building now > there maybe more highspeed links... and maybe lower long term costs? > Be careful of what you wish for...., Yes, you get fiber from the CO to the Building... however there is also a very big side-effect... Verizon is not obligated to provide equal access to Competitive providers (CLECs) on this Fiber.... Thus, you are also looking a significantly reduced competition..... which is very likely to equate to a higher cost for end users. :) Faisal Imtiaz Snappy Internet & Telecom From trejrco at gmail.com Tue Nov 20 17:53:55 2012 From: trejrco at gmail.com (TJ) Date: Tue, 20 Nov 2012 12:53:55 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121120163214.794af87b@tux.DEF.witbe.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> Message-ID: > On Tue, 20 Nov 2012 10:14:18 +0100 > Tomas Podermanski wrote: > > > It seems that today is a "big day" for IPv6. It is the very first > > time when native IPv6 on google statistics > > (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some > > might say it is tremendous success after 16 years of deploying IPv6 :-) > Funny enough, the peaks are indicating... week-ends ! > Do people use more google during the WE, or do they have more IPv6 @ home ? Purely anecdotally, I can say: Yes. Atleast in my case I have native IPv6 at home and via my mobile devices, but not at my client sites. *Sidenote: That's why I am at those client sites, helping 'fix' that. ;) ... * /TJ From sethm at rollernet.us Tue Nov 20 17:58:50 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 20 Nov 2012 09:58:50 -0800 Subject: NTP Issues Today In-Reply-To: References: <20121120014149.3C1242B698CC@drugs.dv.isc.org> Message-ID: <50ABC4DA.7010901@rollernet.us> On 11/19/12 6:08 PM, Wallace Keith wrote: > Just got paged with a pbx alarm that had 1970 as the year. By the time I logged in , it was showing 2012. Using GPS for time and date. > I use GPS for my NTP server and didn't notice anything, but it's PPS disciplined after initial sync so it doesn't matter as long as the pulse keeps going. ntp0# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 .LOCL. 12 l 10 64 377 0.000 0.000 0.015 +216.171.124.36 .ACTS. 1 u 167 1024 377 26.801 2.387 0.015 +127.127.20.0 .GPS. 0 l 45 64 377 0.000 -0.048 0.015 o127.127.22.0 .PPS. 0 l 27 64 377 0.000 -0.048 0.015 ~Seth From sethm at rollernet.us Tue Nov 20 18:05:53 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 20 Nov 2012 10:05:53 -0800 Subject: Plages d'adresses IP Orange In-Reply-To: <465966A5F5B867419F604CD3E604C1E520D1F209@PRA-DCA-MAIL.pra.ray.com> References: <465966A5F5B867419F604CD3E604C1E520D1F209@PRA-DCA-MAIL.pra.ray.com> Message-ID: <50ABC681.5040703@rollernet.us> On 11/19/12 9:16 AM, Jamie Bowden wrote: > Actually, this is kind of an interesting aside. Last time I checked, Canada counts as North America and large parts of Quebec are inhabited by folks who don't speak much, if any, English. Having said that, I can't recall having seen any Quebecois posting in French here, but I find it hard to believe those folks don't have use for a list like this. > Quebecois French and French aren't exactly the same. My dad once had to order "le pancakes" for breakfast because the waitress didn't understand "le crepes". ~Seth From morrowc.lists at gmail.com Tue Nov 20 18:20:08 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Nov 2012 13:20:08 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: <50ABC295.10907@snappydsl.net> References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> Message-ID: On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz wrote: > > On 11/20/2012 12:10 PM, Christopher Morrow wrote: >> >> it's acutally kinda nice that at least from CO -> building now >> there maybe more highspeed links... and maybe lower long term costs? >> > > Be careful of what you wish for...., Yes, you get fiber from the CO to the > Building... however there is also a very big side-effect... > Verizon is not obligated to provide equal access to Competitive providers > (CLECs) on this Fiber.... > > Thus, you are also looking a significantly reduced competition..... which is > very likely to equate to a higher cost for end users. right, so in the end vz gets what it wants... a return to monopoly. conspiracy theories about verizon starting the floods? From eric at ericheather.com Tue Nov 20 18:24:19 2012 From: eric at ericheather.com (Eric C. Miller) Date: Tue, 20 Nov 2012 18:24:19 +0000 Subject: AS 2379 Message-ID: Does anybody know of a list of BGP communities for AS2379 (EMBARK-WNPK now CenturyLink)? I haven't reached out to Centurylink yet, but I'm used to just finding them through Google Searches. Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 From blair.trosper at gmail.com Tue Nov 20 18:24:41 2012 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 20 Nov 2012 12:24:41 -0600 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> Message-ID: I've found myself becoming a snob about IPv6. I almost look down on IPv4-only networks in the same way that I won't go see a film that isn't projected on DLP unless my arm is twisted. I'm a convert, and I'm glad to see the adoption rate edging up. However, I still scratch my head on why most major US ISPs *have* robust IPv6 peering and infrastructure and are ready to go, but they have not turned it on for their fiber/cable/DSL customers for reasons that are not clear to me. I keep pestering my home ISP about turning it on (since their network is now 100% DOCSIS 3), but they just seem to think I'm making up words. One can hope, though. Blair On Tue, Nov 20, 2012 at 11:53 AM, TJ wrote: > > On Tue, 20 Nov 2012 10:14:18 +0100 > > Tomas Podermanski wrote: > > > > > It seems that today is a "big day" for IPv6. It is the very first > > > time when native IPv6 on google statistics > > > (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some > > > might say it is tremendous success after 16 years of deploying IPv6 :-) > > Funny enough, the peaks are indicating... week-ends ! > > Do people use more google during the WE, or do they have more IPv6 @ > home ? > > > Purely anecdotally, I can say: Yes. > Atleast in my case I have native IPv6 at home and via my mobile devices, > but not at my client sites. > *Sidenote: That's why I am at those client sites, helping 'fix' that. ;) > ... > * > > > /TJ > From morrowc.lists at gmail.com Tue Nov 20 18:27:42 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Nov 2012 13:27:42 -0500 Subject: AS 2379 In-Reply-To: References: Message-ID: On Tue, Nov 20, 2012 at 1:24 PM, Eric C. Miller wrote: > Does anybody know of a list of BGP communities for AS2379 (EMBARK-WNPK now CenturyLink)? > > > > I haven't reached out to Centurylink yet, but I'm used to just finding them through Google Searches. > http://onesc.net/communities/ bgp communities onesc .... see AS209. > > > > Eric Miller, CCNP > > Network Engineering Consultant > > (407) 257-5115 From joelja at bogus.com Tue Nov 20 18:27:43 2012 From: joelja at bogus.com (joel jaeggli) Date: Tue, 20 Nov 2012 10:27:43 -0800 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> Message-ID: <50ABCB9F.3090904@bogus.com> On 11/20/12 10:20 AM, Christopher Morrow wrote: > On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz wrote: >> On 11/20/2012 12:10 PM, Christopher Morrow wrote: >>> it's acutally kinda nice that at least from CO -> building now >>> there maybe more highspeed links... and maybe lower long term costs? >>> >> Be careful of what you wish for...., Yes, you get fiber from the CO to the >> Building... however there is also a very big side-effect... >> Verizon is not obligated to provide equal access to Competitive providers >> (CLECs) on this Fiber.... >> >> Thus, you are also looking a significantly reduced competition..... which is >> very likely to equate to a higher cost for end users. > right, so in the end vz gets what it wants... a return to monopoly. > > conspiracy theories about verizon starting the floods? The pressure on the regulatory front doesn't increase until the pain becomes acute... From tjc at ecs.soton.ac.uk Tue Nov 20 18:38:06 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 20 Nov 2012 18:38:06 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> <3F74AC11-0853-445B-9B06-EAEC365E27CC@ecs.soton.ac.uk> Message-ID: On 20 Nov 2012, at 16:42, Mike Jones wrote: > > If these figures are representative (google saying 1% of users and > AMSIX saying 0.5% of traffic) then it would indicate that dual stacked > users can push ~50% of their traffic over IPv6. If this is even close > to reality then that would be quite an achievement. Which ties in with the 50% or so figure you can see at http://6lab.cisco.com/stats/. tim From faisal at snappydsl.net Tue Nov 20 18:48:01 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 20 Nov 2012 13:48:01 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> Message-ID: <50ABD061.4030500@snappydsl.net> On 11/20/2012 1:20 PM, Christopher Morrow wrote: > On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz wrote: >> On 11/20/2012 12:10 PM, Christopher Morrow wrote: >>> it's acutally kinda nice that at least from CO -> building now >>> there maybe more highspeed links... and maybe lower long term costs? >>> >> Be careful of what you wish for...., Yes, you get fiber from the CO to the >> Building... however there is also a very big side-effect... >> Verizon is not obligated to provide equal access to Competitive providers >> (CLECs) on this Fiber.... >> >> Thus, you are also looking a significantly reduced competition..... which is >> very likely to equate to a higher cost for end users. > right, so in the end vz gets what it wants... a return to monopoly. > > > conspiracy theories about verizon starting the floods? No Conspiracy theories... just the simple facts on where things stand, based on current regulatory environment. (I / We have no horse in this race....) Faisal Imtiaz Snappy Internet & Telecom. From bicknell at ufp.org Tue Nov 20 19:00:11 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 20 Nov 2012 11:00:11 -0800 Subject: NTP Issues Today In-Reply-To: <20121120163826.GA60716@ussenterprise.ufp.org> References: <20121120163826.GA60716@ussenterprise.ufp.org> Message-ID: <20121120190011.GA67074@ussenterprise.ufp.org> After some private replies, I'm going to reply to my own post with some information here. It appears many people don't understand how the NTP protocol works. I suspect many people have configured a "primary" and a "backup" NTP server on many of their devices. It turns out this is the _WORST_ possible configuration if you want accurate time: http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3. To protect against two falseticking servers (tick and tock, as we saw on the 19th) you need _FIVE_ servers minimum configured if they are both in the list. More importantly, if you want to protect against a source (GPS, CDMA, IRIG, WWIV, ACTS, etc) false ticking, you need a minimum of _FOUR_ different source technologies in the list as well. It's not hard, my box that I posted the logs from peers with 18 servers using 8 source technologies, all freely available on the Internet... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jra at baylink.com Tue Nov 20 19:09:52 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 20 Nov 2012 14:09:52 -0500 (EST) Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: Message-ID: <1151963.35834.1353438592568.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Christopher Morrow" > On Tue, Nov 20, 2012 at 2:35 AM, Derek Ivey > wrote: > > I saw this on Reddit and thought it was fascinating. I figured I'd > > share it here too since no one else did. > > > > http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-manhattan-hurricane-sandy > > hey lookie! 'free upgrades'! Not having yet read the piece, I assume the "upgrades" are the same thing that you'd get if you tried, today, to warranty a 5 year old 250GB Seagate HD: They'd send you a 750G or 1T, simply because they don't have anything smaller in stock. (If your system is embedded, and won't talk to larger drives, their apologies. :-) It's likely the same thing happens here: we don't have that older gear, so you get the newer stuff with our compliments. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Nov 20 19:24:04 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 20 Nov 2012 14:24:04 -0500 (EST) Subject: NTP problems - (one) root cause Message-ID: <24719540.35842.1353439444768.JavaMail.root@benjamin.baylink.com> A subscriber to Outages who wishes to remain nameless passes along the pointer to this story: Apparently, either tick or tock got rebooted yesterday, and came up with its local clock set to 2000. And lots of people believed it. https://isc.sans.edu/diary.html?n&storyid=14548 Did you believe it? Why? (Yes, those are just rhetorical questions, intended to make people examine their NTP architecture more closely. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Nov 20 19:28:19 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 20 Nov 2012 14:28:19 -0500 (EST) Subject: NTP Issues Today In-Reply-To: <20121120190011.GA67074@ussenterprise.ufp.org> Message-ID: <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leo Bicknell" > To protect against two falseticking servers (tick and tock, as we saw on > the 19th) you need _FIVE_ servers minimum configured if they are both in > the list. More importantly, if you want to protect against a source > (GPS, CDMA, IRIG, WWIV, ACTS, etc) false ticking, you need a minimum of > _FOUR_ different source technologies in the list as well. > > It's not hard, my box that I posted the logs from peers with 18 > servers using 8 source technologies, all freely available on the Internet... I'm curious, Leo, what your internal setup looks like. Do you have an internal pair of masters, all slaved to those externals and one another, with your machines homed to them? Full mesh? Or something else? In my last big gig, it was recommended to me that I have all the machines which had to speak to my DBMS NTP *to it*, and have only it connect to the rest of my NTP infrastructure. It coming unstuck was of less operational impact than *pieces of it* going out of sync with one another... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jared at puck.nether.net Tue Nov 20 19:39:03 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 20 Nov 2012 14:39:03 -0500 Subject: NTP Issues Today In-Reply-To: <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> References: <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> Message-ID: <230747BB-6E8E-4B34-895E-6E594C4720C7@puck.nether.net> On Nov 20, 2012, at 2:28 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Leo Bicknell" > >> To protect against two falseticking servers (tick and tock, as we saw on >> the 19th) you need _FIVE_ servers minimum configured if they are both in >> the list. More importantly, if you want to protect against a source >> (GPS, CDMA, IRIG, WWIV, ACTS, etc) false ticking, you need a minimum of >> _FOUR_ different source technologies in the list as well. >> >> It's not hard, my box that I posted the logs from peers with 18 >> servers using 8 source technologies, all freely available on the Internet... > > I'm curious, Leo, what your internal setup looks like. Do you have an > internal pair of masters, all slaved to those externals and one another, > with your machines homed to them? Full mesh? Or something else? > > In my last big gig, it was recommended to me that I have all the machines > which had to speak to my DBMS NTP *to it*, and have only it connect to the > rest of my NTP infrastructure. It coming unstuck was of less operational > impact than *pieces of it* going out of sync with one another... here's a sample ntp config from one of my systems. -- snip -- # Use public servers from the pool.ntp.org project. # Please consider joining the pool (http://www.pool.ntp.org/join.html). server 0.fedora.pool.ntp.org server 1.fedora.pool.ntp.org server 2.fedora.pool.ntp.org server 3.fedora.pool.ntp.org # server 0.us.pool.ntp.org iburst maxpoll 9 server 1.us.pool.ntp.org iburst maxpoll 9 server 2.us.pool.ntp.org iburst maxpoll 9 server 129.250.35.250 iburst maxpoll 9 server 129.250.35.251 iburst maxpoll 9 -- snip -- You can audit its operation like this: nat:~$ ntpq -p -n -c ass remote refid st t when poll reach delay offset jitter ============================================================================== -129.250.35.250 164.244.221.197 2 u 68 512 377 19.248 -0.135 3.195 +129.250.35.251 192.5.41.40 2 u 439 512 377 41.817 1.109 15.660 -206.57.44.17 204.123.2.5 2 u 126 512 377 37.133 -6.443 9.631 +4.53.160.75 209.81.9.7 2 u 48 512 377 25.209 1.551 8.804 -64.73.32.135 192.5.41.41 2 u 349 512 377 23.418 -0.703 1.721 *50.116.38.157 64.250.177.145 2 u 380 512 377 43.021 1.267 2.136 +208.87.221.228 10.0.22.49 2 u 517 512 377 92.000 0.974 0.678 -206.212.242.132 128.252.19.1 2 u 323 512 377 21.781 -2.873 1.304 +38.229.71.1 204.123.2.72 2 u 211 512 377 21.977 -0.055 2.274 ind assid status conf reach auth condition last_event cnt =========================================================== 1 39973 931a yes yes none outlyer sys_peer 1 2 39974 941a yes yes none candidate sys_peer 1 3 39975 9324 yes yes none outlyer reachable 2 4 39976 942a yes yes none candidate sys_peer 2 5 39977 931a yes yes none outlyer sys_peer 1 6 39978 961a yes yes none sys.peer sys_peer 1 7 39979 9414 yes yes none candidate reachable 1 8 39980 931a yes yes none outlyer sys_peer 1 9 39981 941a yes yes none candidate sys_peer 1 What you would have seen is a falseticker from the impacted clocks. This is a fairly reasonable setup. I've also been looking at an item like this: http://www.netburnerstore.com/ProductDetails.asp?ProductCode=PK70EX-NTP which is about $300 + misc parts. Should be well worth it to avoid a 'major outage' that some folks had with needing to reboot their servers, etc. - Jared From alh-ietf at tndh.net Tue Nov 20 19:44:56 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 20 Nov 2012 11:44:56 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: <009f01cdc757$8553b470$8ffb1d50$@tndh.net> Mike Jones wrote: > > On 20 November 2012 16:05, Patrick W. Gilmore wrote: > > On Nov 20, 2012, at 08:45 , Owen DeLong wrote: > > > >> It is entirely possible that Google's numbers are artificially low > >> for a number of reasons. > > > > AMS-IX publishes stats too: > > > > > > This is probably a better view of overall percentage on the Internet than a > specific company's content. It shows order of 0.5%. > > > > Why do you think Google's numbers are lower than the real total? > > > > They are also different stats which is why they give such different numbers. > > In a theoretical world with evenly distributed traffic patterns if 1% of users > were IPv6 enabled it would require 100% of content to be IPv6 enabled > before your traffic stats would show 1% of traffic going over IPv6. > > If these figures are representative (google saying 1% of users and AMSIX > saying 0.5% of traffic) then it would indicate that dual stacked users can push > ~50% of their traffic over IPv6. If this is even close to reality then that would > be quite an achievement. If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, why wouldn't a dual stacked end point have half of its traffic as IPv6 after June??? Tony From chk at pobox.com Tue Nov 20 19:47:01 2012 From: chk at pobox.com (Harald Koch) Date: Tue, 20 Nov 2012 14:47:01 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> <3F74AC11-0853-445B-9B06-EAEC365E27CC@ecs.soton.ac.uk> Message-ID: While looking into the NTP chaos from Monday, I noticed that my personal servers have an NTP peer running IPv6. I have no idea how long that's been going on - it was a complete non-event ;). -- Harald From tpoder at cis.vutbr.cz Tue Nov 20 19:47:09 2012 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Tue, 20 Nov 2012 20:47:09 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> Message-ID: <50ABDE3D.5040505@cis.vutbr.cz> Hi, On 11/20/12 7:24 PM, Blair Trosper wrote: > I've found myself becoming a snob about IPv6. I almost look down on > IPv4-only networks in the same way that I won't go see a film that isn't > projected on DLP unless my arm is twisted. I'm a convert, and I'm glad to > see the adoption rate edging up. > > However, I still scratch my head on why most major US ISPs *have* robust > IPv6 peering and infrastructure and are ready to go, but they have not > turned it on for their fiber/cable/DSL customers for reasons that are not > clear to me. Turning IPv6 on at the basic/core of the infrastructure is the easiest part of the job. However turning IPv6 for customers requires a lot of effort and compromises. Some of the reasons are described in: http://6lab.cz/article/deploying-ipv6-practical-problems-from-the-campus-perspective/ and related presentation: http://6lab.cz/wordpress/wp-content/uploads/2012/05/tnc2012_slides_TncPresentation.pdf Tomas From morrowc.lists at gmail.com Tue Nov 20 19:58:56 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Nov 2012 14:58:56 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: <50ABD061.4030500@snappydsl.net> References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> <50ABD061.4030500@snappydsl.net> Message-ID: On Tue, Nov 20, 2012 at 1:48 PM, Faisal Imtiaz wrote: > > On 11/20/2012 1:20 PM, Christopher Morrow wrote: >> >> On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz >> wrote: >>> >>> On 11/20/2012 12:10 PM, Christopher Morrow wrote: >>>> >>>> it's acutally kinda nice that at least from CO -> building now >>>> there maybe more highspeed links... and maybe lower long term costs? >>>> >>> Be careful of what you wish for...., Yes, you get fiber from the CO to >>> the >>> Building... however there is also a very big side-effect... >>> Verizon is not obligated to provide equal access to Competitive providers >>> (CLECs) on this Fiber.... >>> >>> Thus, you are also looking a significantly reduced competition..... which >>> is >>> very likely to equate to a higher cost for end users. >> >> right, so in the end vz gets what it wants... a return to monopoly. >> >> >> conspiracy theories about verizon starting the floods? > > No Conspiracy theories... just the simple facts on where things stand, based > on current regulatory environment. > (I / We have no horse in this race....) apologies, I forgot the emoticons after my last comment. i really did mean it in jest... I don't think VZ has harnessed weather-changing-powers. (yet). From faisal at snappydsl.net Tue Nov 20 20:10:46 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 20 Nov 2012 15:10:46 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> <50ABD061.4030500@snappydsl.net> Message-ID: <50ABE3C6.6020001@snappydsl.net> On 11/20/2012 2:58 PM, Christopher Morrow wrote: > On Tue, Nov 20, 2012 at 1:48 PM, Faisal Imtiaz wrote: >> On 11/20/2012 1:20 PM, Christopher Morrow wrote: >>> On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz >>> wrote: >>>> On 11/20/2012 12:10 PM, Christopher Morrow wrote: >>>>> it's acutally kinda nice that at least from CO -> building now >>>>> there maybe more highspeed links... and maybe lower long term costs? >>>>> >>>> Be careful of what you wish for...., Yes, you get fiber from the CO to >>>> the >>>> Building... however there is also a very big side-effect... >>>> Verizon is not obligated to provide equal access to Competitive providers >>>> (CLECs) on this Fiber.... >>>> >>>> Thus, you are also looking a significantly reduced competition..... which >>>> is >>>> very likely to equate to a higher cost for end users. >>> right, so in the end vz gets what it wants... a return to monopoly. >>> >>> >>> conspiracy theories about verizon starting the floods? >> No Conspiracy theories... just the simple facts on where things stand, based >> on current regulatory environment. >> (I / We have no horse in this race....) > apologies, I forgot the emoticons after my last comment. i really did > mean it in jest... I don't think VZ has harnessed > weather-changing-powers. (yet). No Worries, some of us here are players in the arena, and some of us are spectators.... it is going to be interesting and fascinating at the same time to see how things develop. Faisal Imtiaz From bicknell at ufp.org Tue Nov 20 20:15:55 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 20 Nov 2012 12:15:55 -0800 Subject: NTP Issues Today In-Reply-To: <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> References: <20121120190011.GA67074@ussenterprise.ufp.org> <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> Message-ID: <20121120201555.GA69041@ussenterprise.ufp.org> In a message written on Tue, Nov 20, 2012 at 02:28:19PM -0500, Jay Ashworth wrote: > I'm curious, Leo, what your internal setup looks like. Do you have an > internal pair of masters, all slaved to those externals and one another, > with your machines homed to them? Full mesh? Or something else? My particular internal setup is a tad weird, and so rather than answer your question, I'm going to answer with some generalities. The right answer of course depends a lot on how important it is that boxes have the right time. If you have 4 or more physical sites, I believe the right answer is to have on the order of 8 NTP servers. 2 each in 4 sites reaches the minimum nicely with redundancy. These boxes can have GPS, CDMA or other technologies if you want, but MUST peer with at least 10 stratum-1 sources outside of your network. Of course if you have more sites, one server in each of 8 sites is peachy. Those on a budget could probably get by with 4 servers total, but never less! All "critical" devices should then be synced to the full set of internal servers. 4 boxes minimum, 8-10 preferred. NTP will only use the 10 best servers in it's calculations, so there is a steep dropoff of diminishing returns beyond 10. For most ISP's I would include all routers in this list. For the "non-critical" devices? Well, there it gets more complex. For most I would only configure one server, their default gateway router. Of course, pushing out a set of 4+ to themm if that is easy is a great thing to do. The interesting thing here is that no devices except for your NTP servers should ever peer with anything outside of your network. Why? Let's say your NTP servers all go crazy together. The outside world is cut off, GPS is spoofed, the world is ending. All that you have left is that all of your devices are in time to each other....so at least your logs still coorelate and such. So having every device under your master set of NTP servers is important. One guy with an external peer may choose to use that, and leave the hive mind, so to speak. For small players, less than 4 sites, typically just use the NTP pool servers, configuring 4 per box minimum. If you want the same protection I just outlined in the paragraph before, make 4 of your servers talk to the outside world, and make everything else talk to those. Want to give back to the community? Get a GPS/CDMA/Whatever box and make it part of the NTP pool. Want to step up your game (which is what I do), reach out to various Stratum-1's on the net (or find free, open ones) and peer up 8-20 of them. > In my last big gig, it was recommended to me that I have all the machines > which had to speak to my DBMS NTP *to it*, and have only it connect to the > rest of my NTP infrastructure. It coming unstuck was of less operational > impact than *pieces of it* going out of sync with one another... Yep, a prime example of the scenario I described above. Depending on your level of network redundancy, number of NTP servers, and so on, this is a fine solution. With one NTP server (the DBMS) the downstream will always use it, and stay in sync. It's a valid and good config in many situations. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mfidelman at meetinghouse.net Tue Nov 20 20:47:22 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 20 Nov 2012 15:47:22 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> <50ABD061.4030500@snappydsl.net> Message-ID: <50ABEC5A.20104@meetinghouse.net> Christopher Morrow wrote: > apologies, I forgot the emoticons after my last comment. i really did > mean it in jest... I don't think VZ has harnessed > weather-changing-powers. (yet). Well, they ARE The Phone Company! -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From george.herbert at gmail.com Tue Nov 20 20:52:45 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 20 Nov 2012 12:52:45 -0800 Subject: NTP Issues Today In-Reply-To: <230747BB-6E8E-4B34-895E-6E594C4720C7@puck.nether.net> References: <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> <230747BB-6E8E-4B34-895E-6E594C4720C7@puck.nether.net> Message-ID: <8E7439E3-599D-4B25-B7EC-58DDE1D0315E@gmail.com> On Nov 20, 2012, at 11:39 AM, Jared Mauch wrote: . > > I've also been looking at an item like this: > > http://www.netburnerstore.com/ProductDetails.asp?ProductCode=PK70EX-NTP > > which is about $300 + misc parts. > > Should be well worth it to avoid a 'major outage' that some folks had with needing to reboot their servers, etc. > > - Jared Caution - that Netburner decice is just GPS synced, so if GPS ever does go insane you're out of luck. It doesn't list a precision internal clock part. I am not sure what all is in the dev kit version, but I know the company owner and can ask if anyone cares. George William Herbert Sent from my iPhone From djahandarie at gmail.com Tue Nov 20 21:00:21 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Tue, 20 Nov 2012 16:00:21 -0500 Subject: NTP Issues Today In-Reply-To: <20121120201555.GA69041@ussenterprise.ufp.org> References: <20121120190011.GA67074@ussenterprise.ufp.org> <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> <20121120201555.GA69041@ussenterprise.ufp.org> Message-ID: On Tue, Nov 20, 2012 at 3:15 PM, Leo Bicknell wrote: > For small players, less than 4 sites, typically just use the NTP > pool servers, configuring 4 per box minimum. If you want the same > protection I just outlined in the paragraph before, make 4 of your > servers talk to the outside world, and make everything else talk > to those. Want to give back to the community? Get a GPS/CDMA/Whatever Choosing the first four servers is usually pretty straightforward: *.CC.pool.ntp.org But beyond that, I'm honestly rather curious what server selections are a good idea. A first thought would be an adjacent country, but maybe there is a benefit to picking things outside of the pool.ntp.org selection entirely? I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a specific reason for that or if my questions are even worth thinking about at all :-). Happy to hear thoughts. -- Darius Jahandarie From mike.lyon at gmail.com Tue Nov 20 21:04:43 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 20 Nov 2012 13:04:43 -0800 Subject: NTP Issues Today In-Reply-To: References: <20121120190011.GA67074@ussenterprise.ufp.org> <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> <20121120201555.GA69041@ussenterprise.ufp.org> Message-ID: I usually use time.nist.gov. On Tue, Nov 20, 2012 at 1:00 PM, Darius Jahandarie wrote: > On Tue, Nov 20, 2012 at 3:15 PM, Leo Bicknell wrote: > > For small players, less than 4 sites, typically just use the NTP > > pool servers, configuring 4 per box minimum. If you want the same > > protection I just outlined in the paragraph before, make 4 of your > > servers talk to the outside world, and make everything else talk > > to those. Want to give back to the community? Get a GPS/CDMA/Whatever > > Choosing the first four servers is usually pretty straightforward: > *.CC.pool.ntp.org > > But beyond that, I'm honestly rather curious what server selections > are a good idea. A first thought would be an adjacent country, but > maybe there is a benefit to picking things outside of the pool.ntp.org > selection entirely? > > I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a > specific reason for that or if my questions are even worth thinking > about at all :-). > > > Happy to hear thoughts. > > -- > Darius Jahandarie > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From Ben.Kessler at zenetra.com Tue Nov 20 21:07:22 2012 From: Ben.Kessler at zenetra.com (R. Benjamin Kessler) Date: Tue, 20 Nov 2012 21:07:22 +0000 Subject: [outages] NTP Issues Today In-Reply-To: <20121120153813.GA90675@icarus.home.lan> References: <20121120014149.3C1242B698CC@drugs.dv.isc.org> <8C51AAEB-E218-4BC8-A84B-72202AA87B5F@ctigroup.com> <20121120153813.GA90675@icarus.home.lan> Message-ID: <0CFF54003CD92945994CF0C0F90D81B601190B4C@EXCH1-FWA1.zenetra.local> Logs from a Juniper router in a customer network - we had hundreds of these affected. They all synchronize to internal hosts (172.20.167.251 and .252) which are configured to get time from NIST and USNO CORP-NTP-01#sh ntp as address ref clock st when poll reach delay offset disp *~192.5.41.41 .IRIG. 1 354 512 377 34.2 0.36 1.4 +~132.163.4.101 .ACTS. 1 336 512 377 35.0 -2.54 18.7 ~127.127.7.1 127.127.7.1 10 59 64 377 0.0 0.00 0.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured CORP-NTP-02#sh ntp as address ref clock st when poll reach delay offset disp *~192.5.41.41 .IRIG. 1 65 512 377 36.5 0.91 0.6 +~132.163.4.101 .ACTS. 1 95 512 377 34.3 -1.31 22.8 ~127.127.7.1 127.127.7.1 10 44 64 377 0.0 0.00 0.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured Here are the logs from one of the Junipers: Nov 19 14:24:48 XXXX xntpd[912]: kernel time sync enabled 2001 Nov 19 15:50:11 XXXX xntpd[912]: synchronized to 172.20.167.252, stratum=2 Nov 19 16:41:23 XXXX xntpd[912]: no servers reachable Nov 19 16:44:24 XXXX xntpd[912]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:44:24 XXXX xntpd[912]: time correction of -378691200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Nov 19 16:44:24 XXXX init: ntp (PID 912) exited with status=255 Nov 19 16:44:24 XXXX init: ntp (PID 70200) started Nov 19 16:44:24 XXXX xntpd[70200]: ntpd 4.2.0-a Sat Apr 10 00:32:46 UTC 2010 (1) Nov 19 16:44:24 XXXX xntpd[70200]: mlockall(): Resource temporarily unavailable Nov 19 16:44:24 XXXX xntpd[70200]: precision = 0.582 usec Nov 19 16:44:24 XXXX xntpd[70200]: Listening on interface ggsn_vpn, 128.0.0.1#123 Nov 19 16:44:24 XXXX xntpd[70200]: kernel time sync status 2040 Nov 19 16:44:24 XXXX xntpd[70200]: frequency initialized -64.931 PPM from /var/db/ntp.drift Nov 19 16:44:24 XXXX xntpd[70200]: Configuring iburst flag for server Nov 19 16:44:24 XXXX xntpd[70200]: Configuring iburst flag for server Nov 19 16:44:33 XXXX xntpd[70200]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:44:32 XXXX xntpd[70200]: time reset -378691200.411331 s Nov 19 16:44:32 XXXX xntpd[70200]: kernel time sync disabled 2041 Nov 19 16:45:44 XXXX xntpd[70200]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:45:51 XXXX xntpd[70200]: kernel time sync enabled 2001 Nov 19 16:45:56 XXXX xntpd[70200]: NTP Server Unreachable Nov 19 16:53:25 XXXX xntpd[70200]: no servers reachable Nov 19 17:03:09 XXXX xntpd[70200]: NTP Server Unreachable Nov 19 17:13:00 XXXX xntpd[70200]: NTP Server Unreachable Nov 19 17:20:27 XXXX xntpd[70200]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:20:27 XXXX xntpd[70200]: time correction of 378691200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Nov 19 17:20:27 XXXX init: ntp (PID 70200) exited with status=255 Nov 19 17:20:27 XXXX init: ntp (PID 70766) started Nov 19 17:20:27 XXXX xntpd[70766]: ntpd 4.2.0-a Sat Apr 10 00:32:46 UTC 2010 (1) Nov 19 17:20:27 XXXX xntpd[70766]: mlockall(): Resource temporarily unavailable Nov 19 17:20:27 XXXX xntpd[70766]: precision = 0.570 usec Nov 19 17:20:27 XXXX xntpd[70766]: Listening on interface ggsn_vpn, 128.0.0.1#123 Nov 19 17:20:27 XXXX xntpd[70766]: kernel time sync status 2040 Nov 19 17:20:27 XXXX xntpd[70766]: frequency initialized -64.931 PPM from /var/db/ntp.drift Nov 19 17:20:27 XXXX xntpd[70766]: Configuring iburst flag for server Nov 19 17:20:27 XXXX xntpd[70766]: Configuring iburst flag for server Nov 19 17:20:35 XXXX xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:20:36 XXXX xntpd[70766]: time reset +378691200.387434 s Nov 19 17:20:36 XXXX xntpd[70766]: kernel time sync disabled 6041 Nov 19 17:21:48 XXXX xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:21:48 XXXX xntpd[70766]: kernel time sync disabled 2041 Nov 19 17:21:52 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 00:02:29 XXXX xntpd[70766]: synchronized to 172.20.167.251, stratum=2 Nov 20 01:44:56 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 02:19:03 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 02:53:12 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 03:44:26 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 05:26:58 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 05:44:02 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 07:43:35 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 08:00:39 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 08:34:48 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 08:51:54 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 10:34:22 XXXX xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 20 11:25:16 XXXX xntpd[70766]: synchronized to 172.20.167.251, stratum=2 Nov 20 12:33:56 XXXX xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 20 14:16:05 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 14:33:10 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 15:07:19 XXXX xntpd[70766]: synchronized to 172.20.167.251, stratum=2 -----Original Message----- From: outages-bounces at outages.org [mailto:outages-bounces at outages.org] On Behalf Of Jeremy Chadwick Sent: Tuesday, November 20, 2012 10:38 AM To: Scott Voll Cc: Sid Rao; outages; nanog at nanog.org Subject: Re: [outages] NTP Issues Today I'm still waiting for someone who was affected by this to provide coherent logs from ntpd showing exactly when the time change happened. Getting these, at least on an *IX system, is far from difficult folks. Please don't omit anything from the logs either; for example if you know *exactly* what NTP servers were in use (not "ones you had configured" but which one was primarily chosen by ntpd ('*' mark) and which were secondary comparisons/fallbacks ('+' mark)), that would also be greatly helpful. This would be output from "ntpq -c peers" when run on your NTP server *at or around the time* the incident happened and recovered. What's been provided so far is that "something happened", with reports of clocks going back to year 2000, and other reports of clocks going back to (presumably) epoch time; those reporting it were using either usno.navy.mil, NIST, or Microsoft NTP servers. usno.navy.mil uses dedicated IRIG/AFNOR TCRs boxes, while NIST uses GPS. No idea what Microsoft uses. I asked on a public *IX forum if anyone saw anything NTP-wise that was out of the ordinary and not a single admin saw anything. I also saw nothing anomalous on either of my FreeBSD machines (9.1-PRERELEASE, running base system ntpd 4.2.4p8), but I sync with very specific stratum 1 and stratum 2 servers across the United States. As Mark Andrews from the ISC stated below (read slowly/carefully), ntpd will not allow large clock jumps -- the largest it'll allow out of the box is 1000s (and on some systems like Solaris ntpd, 500s) -- unless you're running with the -g flag (and shame on if you're you doing that). So I'm very surprised by this problem altogether. Can't deny what happened did, but figuring out *why* is important. Also, for Mike Lyon -- I looked at NIST's GPS graphs. Did you notice they have no data for 11/18, 11/19, or 11/20? I find that unnerving, do you not? -- | Jeremy Chadwick jdc at koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | On Tue, Nov 20, 2012 at 07:18:45AM -0800, Scott Voll wrote: > Same thing happened to us yesterday. ended up having to reboot > everything after we got time fixed. Major outage. > > Scott > > > On Mon, Nov 19, 2012 at 7:58 PM, Sid Rao wrote: > > > We had multiple servers synchronized with Windows/MS time change > > their clock to the year 2000 today. It broke many things, including > > AD authentication. > > > > These servers had been properly synchronized for years. > > > > They were synchronized with Microsoft and NIST NTP servers. > > > > This may not be isolated. > > > > Sid Rao | CTI Group | +1 (317) 262-4677 > > > > On Nov 19, 2012, at 10:29 PM, "George Herbert" > > > > wrote: > > > > > crossreplying to outages list. > > > > > > Is anyone ELSE seeing GPS issues? This could well have been an > > > unrelated issue on that particular PBX. > > > > > > If this was real, then the mother of all infrastructure attacks > > > might be underway... > > > > > > One glitch on tick and tock and one malfunctioning PBX is not > > > sufficient evidence of pattern - much less hostile activity - to > > > induce panic, but it would perhaps be a wise time to check > > > time-related logs? > > > > > > > > > -george > > > > > > On Mon, Nov 19, 2012 at 6:08 PM, Wallace Keith > > > wrote: > > >> Just got paged with a pbx alarm that had 1970 as the year. By the > > >> time > > I logged in , it was showing 2012. Using GPS for time and date. > > >> > > >> -----Original Message----- > > >> From: Mark Andrews [mailto:marka at isc.org] > > >> Sent: Monday, November 19, 2012 8:42 PM > > >> To: Van Wolfe > > >> Cc: nanog at nanog.org > > >> Subject: Re: NTP Issues Today > > >> > > >> > > >> In message < > > CAMeggd4cDQwhxQE_JbvpNR-PKKe9LXqA+KzJ97anHFonjwZhdQ at mail.gmail.com> > > >> , Van Wolfe writes: > > >>> Hello, > > >>> > > >>> Did anyone else experience issues with NTP today? We had our > > >>> server times update to the year 2000 at around 3:30 MT, then > > >>> revert back to > > 2012. > > >>> > > >>> Thanks, > > >>> Van > > >> > > >> NTP should be immune from this sort of behaviour unless you did a > > ntpdate at the wrong moment. The clocks should have been marked as insane. > > >> > > >> Mark > > >> -- > > >> Mark Andrews, ISC > > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > > >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > >> > > >> > > > > > > > > > > > > -- > > > -george william herbert > > > george.herbert at gmail.com > > > > > > > > > > > > _______________________________________________ > > Outages mailing list > > Outages at outages.org > > https://puck.nether.net/mailman/listinfo/outages > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages _______________________________________________ Outages mailing list Outages at outages.org https://puck.nether.net/mailman/listinfo/outages From jared at puck.nether.net Tue Nov 20 21:21:18 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 20 Nov 2012 16:21:18 -0500 Subject: NTP Issues Today In-Reply-To: References: <20121120190011.GA67074@ussenterprise.ufp.org> <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> <20121120201555.GA69041@ussenterprise.ufp.org> Message-ID: On Nov 20, 2012, at 4:00 PM, Darius Jahandarie wrote: > Choosing the first four servers is usually pretty straightforward: > *.CC.pool.ntp.org > > But beyond that, I'm honestly rather curious what server selections > are a good idea. A first thought would be an adjacent country, but > maybe there is a benefit to picking things outside of the pool.ntp.org > selection entirely? > > I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a > specific reason for that or if my questions are even worth thinking > about at all :-). I'm by no means a time geek, but ?. i have some ideas about what you want and can tell you why I picked the settings I did? 1) The 129.250 ones are my employer run clocks. It is a good idea to know how accurate they are. 2) The pool ones, some were default (e.g.: fedora) from my OS distro on the machine I took the example from. You will see freebsd, centOS and others based on your settings. You may even see time.apple.com if you are MacOS. 3) CC ntp pool were selected to provide additional clock diversity. 4) You want low jitter to your clocks. This will allow you to have an accurate timing source. This means don't congest that path. If you want something very reliable, don't run it on a server with the other "misc" functions you need (e.g.: DNS, etc). If it's important, dedicate some hardware to it. if it is of passing importance, use a fair number of peers. I was playing with the OWAMP software. Having consistent clocks is important for that, (even if they are all off by a few ms). It can be fun to play with and measure things? http://www.internet2.edu/performance/owamp/index.html 5) Monitor your NTP setup periodically. You may see clocks be rejected or outliers. Depending on how close your clocks are, you may see a fair number be unusable. Take this output: nat:~$ ntpq -n -p -c ass remote refid st t when poll reach delay offset jitter ============================================================================== *129.250.35.250 164.244.221.197 2 u 507 512 377 18.883 0.196 18.311 +129.250.35.251 209.51.161.238 2 u 366 512 377 41.349 0.429 2.184 -206.57.44.17 204.123.2.5 2 u 91 512 377 35.884 -5.982 7.099 -4.53.160.75 209.81.9.7 2 u 5 512 377 24.250 1.522 1.353 +64.73.32.135 164.67.62.194 2 u 296 512 377 26.405 -0.956 11.244 +50.116.38.157 64.250.177.145 2 u 897 1024 377 42.978 0.685 1.211 -208.87.221.228 10.0.22.51 2 u 390 512 377 83.858 -2.717 0.814 -206.212.242.132 128.252.19.1 2 u 262 512 377 22.278 -1.640 1.150 +38.229.71.1 204.123.2.72 2 u 95 512 377 20.688 0.113 1.878 ind assid status conf reach auth condition last_event cnt =========================================================== 1 39973 961a yes yes none sys.peer sys_peer 1 2 39974 941a yes yes none candidate sys_peer 1 3 39975 9324 yes yes none outlyer reachable 2 4 39976 932a yes yes none outlyer sys_peer 2 5 39977 941a yes yes none candidate sys_peer 1 6 39978 941a yes yes none candidate sys_peer 1 7 39979 9314 yes yes none outlyer reachable 1 8 39980 931a yes yes none outlyer sys_peer 1 9 39981 941a yes yes none candidate sys_peer 1 Only 5/9 clocks are 'candidate' for usage, or the actual reference clock. The jitter on the reference clock is equal to the delay (!). This is on a business class internet link/tier, but from one of the 'usual suspects' that offers residential services as well. I haven't been able to find them operating any customer accessible clocks, but they may exist. My config, or one resembling it will give you a fair amount of diversity of clocks. Syncing to one can easily result in being lied to and resetting the clock as everyone observed that went back to 2000. - Jared From jra at baylink.com Tue Nov 20 21:53:39 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 20 Nov 2012 16:53:39 -0500 (EST) Subject: Picking outside NTP servers (Re: NTP Issues Today) In-Reply-To: Message-ID: <21449665.36010.1353448419775.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Darius Jahandarie" > Choosing the first four servers is usually pretty straightforward: > *.CC.pool.ntp.org > > But beyond that, I'm honestly rather curious what server selections > are a good idea. A first thought would be an adjacent country, but > maybe there is a benefit to picking things outside of the pool.ntp.org > selection entirely? > > I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a > specific reason for that or if my questions are even worth thinking > about at all :-). Ah; the question that has plagued mankind since the beginning of.. time. :-) There are a couple of documents on this topic at ntp.org, and there's the traditional list -- of questionable accuracy at this point -- of open-acess Strat 1 and 2 servers. For myself, I usually pick the first three in us.pool.ntp.org, tick and tock, time.nist.gov, and a couple of regionally appropriate large universities. I have always aimed for 6 to 8 outside servers, and a pair inside, preferably in different locations, both talking to one another. If your site is in Internet Business, you should probably peer with your business partners. If you deal with Google Docs or AWS, you should probably peer with them, if they have servers for that. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From george.herbert at gmail.com Tue Nov 20 22:07:07 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 20 Nov 2012 14:07:07 -0800 Subject: Picking outside NTP servers (Re: NTP Issues Today) In-Reply-To: <21449665.36010.1353448419775.JavaMail.root@benjamin.baylink.com> References: <21449665.36010.1353448419775.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Nov 20, 2012 at 1:53 PM, Jay Ashworth wrote: >.... > For myself, I usually pick the first three in us.pool.ntp.org, tick and tock, > time.nist.gov, and a couple of regionally appropriate large universities. As this week indicated, perhaps tick and tock are not sufficiently far apart to be a good redundancy choice from a geographical failover point of view or common mode failure point of view. As part of a set of 8 servers as you indicate later, perhaps ok, but I fear for people who think "Ok, I want redundancy, so... Tick and Tock." Which, it turns out, was significant quantities. -- -george william herbert george.herbert at gmail.com From edux at qdns.com.ar Tue Nov 20 22:15:00 2012 From: edux at qdns.com.ar (Eduardo Casarero) Date: Tue, 20 Nov 2012 19:15:00 -0300 Subject: Brasil/Mexico/Argentina connectivity In-Reply-To: <51581.2001:1938:1ce:0:5054:ff:fead:107.1352995537.squirrel@laughton.us> References: <51581.2001:1938:1ce:0:5054:ff:fead:107.1352995537.squirrel@laughton.us> Message-ID: <50AC00E4.7@qdns.com.ar> El jueves, 15 de noviembre de 2012 01:05:37 p.m., Jima escribi?: > On Wednesday, November 14th, 2012, Olivier CALVANO wrote: >> I am search one or more carrier for connect 3 sites in Brasil, Mexico >> and Argentina to one of our pop >> in USA or Spain. > > I don't deal with it directly, but my employer has used MPLS offerings > from (in alphabetical order) BT, Level 3/Global Crossing, and Verizon in > a number of countries. I suspect any of the three have access in all of > the countries listed. I imagine there are others, but those are the ones > that sprung to mind. > > Jima > > I think Level3 is your best, as L3 bought Globalcrossing. Here in Argentina L3 has heavy weight in the carriers market, also in Brazil. What i dont know is in Mexico. From marka at isc.org Tue Nov 20 23:19:35 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 21 Nov 2012 10:19:35 +1100 Subject: Plages d'adresses IP Orange In-Reply-To: Your message of "Tue, 20 Nov 2012 10:05:53 -0800." <50ABC681.5040703@rollernet.us> References: <465966A5F5B867419F604CD3E604C1E520D1F209@PRA-DCA-MAIL.pra.ray.com> <50ABC681.5040703@rollernet.us> Message-ID: <20121120231936.1D6692B70C8A@drugs.dv.isc.org> In message <50ABC681.5040703 at rollernet.us>, Seth Mattinen writes: > On 11/19/12 9:16 AM, Jamie Bowden wrote: > > Actually, this is kind of an interesting aside. Last time I checked, Canad > a counts as North America and large parts of Quebec are inhabited by folks wh > o don't speak much, if any, English. Having said that, I can't recall having > seen any Quebecois posting in French here, but I find it hard to believe tho > se folks don't have use for a list like this. > > > > > Quebecois French and French aren't exactly the same. My dad once had to > order "le pancakes" for breakfast because the waitress didn't understand > "le crepes". Well pancakes are not crepes. Different receipe, different appearance, different texture, similar taste. If you ask for something that is not on the menu .... > ~Seth > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From msa at latt.net Tue Nov 20 23:22:35 2012 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 20 Nov 2012 18:22:35 -0500 Subject: Picking outside NTP servers (Re: NTP Issues Today) In-Reply-To: <21449665.36010.1353448419775.JavaMail.root@benjamin.baylink.com> References: <21449665.36010.1353448419775.JavaMail.root@benjamin.baylink.com> Message-ID: <20121120232234.GA16071@puck.nether.net> On Tue, Nov 20, 2012 at 04:53:39PM -0500, Jay Ashworth wrote: > For myself, I usually pick the first three in us.pool.ntp.org, tick and tock, > time.nist.gov, and a couple of regionally appropriate large universities. I'd advise going through the RR for a while, and pick servers close to you. ntpd won't select a server that's more than 128ms away. It also degrades accuracy. Select for minimum latency, as well as a diverse set of sources. [Watch their refid over time, and make sure they aren't slaving to the same set of servers, as well as others you may be using.] It requires a bit of effort, but over time you get an idea what public time servers are close to each of your locations, and diverse from each other. --msa From sethm at rollernet.us Tue Nov 20 23:27:18 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 20 Nov 2012 15:27:18 -0800 Subject: Plages d'adresses IP Orange In-Reply-To: <20121120231936.1D6692B70C8A@drugs.dv.isc.org> References: <465966A5F5B867419F604CD3E604C1E520D1F209@PRA-DCA-MAIL.pra.ray.com> <50ABC681.5040703@rollernet.us> <20121120231936.1D6692B70C8A@drugs.dv.isc.org> Message-ID: <50AC11D6.1000708@rollernet.us> On 11/20/12 3:19 PM, Mark Andrews wrote: > In message <50ABC681.5040703 at rollernet.us>, Seth Mattinen writes: >> On 11/19/12 9:16 AM, Jamie Bowden wrote: >>> Actually, this is kind of an interesting aside. Last time I checked, Canad >> a counts as North America and large parts of Quebec are inhabited by folks wh >> o don't speak much, if any, English. Having said that, I can't recall having >> seen any Quebecois posting in French here, but I find it hard to believe tho >> se folks don't have use for a list like this. >>> >> >> >> Quebecois French and French aren't exactly the same. My dad once had to >> order "le pancakes" for breakfast because the waitress didn't understand >> "le crepes". > > Well pancakes are not crepes. Different receipe, different appearance, > different texture, similar taste. > > If you ask for something that is not on the menu .... > No, this was the Quebecois waitress not understanding the French word, not semantics. It's probably illegal to print the word "pancake" in Quebec anyway. ~Seth From mysidia at gmail.com Wed Nov 21 00:49:47 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 20 Nov 2012 18:49:47 -0600 Subject: NTP Issues Today In-Reply-To: References: Message-ID: On 11/19/12, Van Wolfe wrote: > Did anyone else experience issues with NTP today? We had our server > times update to the year 2000 at around 3:30 MT, then revert back to 2012. Are you sure that you are actually using NTP to set your clock? For you to sync with 2000, you should have had multiple confused peers from multiple time sources; possibly a false radio signal.... NTP by default has a panic threshold of 1000 seconds. This _should_ have caused NTP to execute a panic shutdown, instead of setting the clock back 30 million seconds. > Thanks, > Van -- -JH From djahandarie at gmail.com Wed Nov 21 00:56:40 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Tue, 20 Nov 2012 19:56:40 -0500 Subject: NTP Issues Today In-Reply-To: References: Message-ID: On Tue, Nov 20, 2012 at 7:49 PM, Jimmy Hess wrote: > Are you sure that you are actually using NTP to set your clock? > For you to sync with 2000, you should have had multiple confused > peers from multiple time sources; possibly a false radio signal.... > > NTP by default has a panic threshold of 1000 seconds. > > This _should_ have caused NTP to execute a panic shutdown, > instead of setting the clock back 30 million seconds. For VMWare at least, their official recommendation[1] for NTP is to tinker panic 0 for suspend/resume reasons. I've seen it default in some places. [1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427 -- Darius Jahandarie From damian at google.com Wed Nov 21 00:59:13 2012 From: damian at google.com (Damian Menscher) Date: Tue, 20 Nov 2012 16:59:13 -0800 Subject: NTP Issues Today In-Reply-To: References: Message-ID: On Tue, Nov 20, 2012 at 4:49 PM, Jimmy Hess wrote: > On 11/19/12, Van Wolfe wrote: > > Did anyone else experience issues with NTP today? We had our server > > times update to the year 2000 at around 3:30 MT, then revert back to > 2012. > > Are you sure that you are actually using NTP to set your clock? > For you to sync with 2000, you should have had multiple confused > peers from multiple time sources; possibly a false radio signal.... > > NTP by default has a panic threshold of 1000 seconds. > > This _should_ have caused NTP to execute a panic shutdown, > instead of setting the clock back 30 million seconds. > >From logs various people have posted, it appears NTPd saw the excessive time shift and took the reasonable(?) step of killing itself. The OS detected ntpd's death and took the reasonable step of restarting it. On startup, ntpd can be reasonably(?) configured with the -g option to bypass the 1000s limit to set the starting time before going into the regular ntpd time adjustment code. In this case that would have set them back to 2000.... It's a good lesson on how a chain of reasonable decisions can lead to a bad outcome, so you really need to understand the interactions of the whole system. Damian From starthir at gmail.com Wed Nov 21 01:01:57 2012 From: starthir at gmail.com (Alvaro Pereira) Date: Tue, 20 Nov 2012 18:01:57 -0700 Subject: NTP Issues Today In-Reply-To: References: Message-ID: Looks like something bad has happened: Behind the Random NTP Bizarreness of Incorrect Year Being Set https://isc.sans.edu/diary.html?n&storyid=14548 --- "A few people have written in within the past 18 hours about their NTP server/clients getting set to the year 2000. The cause of this behavior is that an NTP server at the US Naval Observatory (pretty much the authoritative time source in the US) was rebooted and somehow reverted to the year 2000. This, then, propogated out for a limited time and downstream time sources also got this value. It's a transient problem and should already be rectified. Not much really to report except an error at the top of the food chain causing problems to the layers below. If you have a problem, just fix the year or resync your NTP server. Just goes to show how reliant NTP is that it is all but a "fire and forget" service once configured until "bad things happen". John Bambenek" --- Alvaro Pereira From ikiris at gmail.com Wed Nov 21 01:03:02 2012 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 20 Nov 2012 19:03:02 -0600 Subject: NTP Issues Today In-Reply-To: References: Message-ID: That's what happens when you just follow vendor recommendations blindly. If you do follow that on vm's (which can actually be a good practice), make sure they pull from your own time infrastructure, and not just the world at large, and that those servers behave in a sane fashion with regard to time jumps. On Tue, Nov 20, 2012 at 6:56 PM, Darius Jahandarie wrote: > On Tue, Nov 20, 2012 at 7:49 PM, Jimmy Hess wrote: > > Are you sure that you are actually using NTP to set your clock? > > For you to sync with 2000, you should have had multiple confused > > peers from multiple time sources; possibly a false radio signal.... > > > > NTP by default has a panic threshold of 1000 seconds. > > > > This _should_ have caused NTP to execute a panic shutdown, > > instead of setting the clock back 30 million seconds. > > For VMWare at least, their official recommendation[1] for NTP is to > > tinker panic 0 > > for suspend/resume reasons. I've seen it default in some places. > > [1] > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427 > > -- > Darius Jahandarie > > From george.herbert at gmail.com Wed Nov 21 01:14:48 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 20 Nov 2012 17:14:48 -0800 Subject: NTP Issues Today In-Reply-To: References: Message-ID: As a reminder - time infrastructure is not recommended for virtualization. Make them physicals. On Tue, Nov 20, 2012 at 5:03 PM, Blake Dunlap wrote: > That's what happens when you just follow vendor recommendations blindly. If > you do follow that on vm's (which can actually be a good practice), make > sure they pull from your own time infrastructure, and not just the world at > large, and that those servers behave in a sane fashion with regard to time > jumps. > > > On Tue, Nov 20, 2012 at 6:56 PM, Darius Jahandarie wrote: > >> On Tue, Nov 20, 2012 at 7:49 PM, Jimmy Hess wrote: >> > Are you sure that you are actually using NTP to set your clock? >> > For you to sync with 2000, you should have had multiple confused >> > peers from multiple time sources; possibly a false radio signal.... >> > >> > NTP by default has a panic threshold of 1000 seconds. >> > >> > This _should_ have caused NTP to execute a panic shutdown, >> > instead of setting the clock back 30 million seconds. >> >> For VMWare at least, their official recommendation[1] for NTP is to >> >> tinker panic 0 >> >> for suspend/resume reasons. I've seen it default in some places. >> >> [1] >> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427 >> >> -- >> Darius Jahandarie >> >> -- -george william herbert george.herbert at gmail.com From patrick at ianai.net Wed Nov 21 02:51:12 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 20 Nov 2012 21:51:12 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <009f01cdc757$8553b470$8ffb1d50$@tndh.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> <009f01cdc757$8553b470$8ffb1d50$@tndh.net> Message-ID: On Nov 20, 2012, at 14:44 , "Tony Hain" wrote: > If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, why wouldn't a dual stacked end point have half of its traffic as IPv6 after June??? "If you assume...". Kinda says it all right there. But more importantly, those three combined are not 50% of overall traffic. It _might_ be true in the US, for some times of the day, but certainly not world-wide overall traffic. If for no better reason than you cannot get NF in all countries. -- TTFN, patrick From frnkblk at iname.com Wed Nov 21 05:05:13 2012 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 20 Nov 2012 23:05:13 -0600 Subject: Fiber terminations -- UPC vs APC In-Reply-To: <50AAA681.6020005@utc.edu> References: <50AAA681.6020005@utc.edu> Message-ID: <002901cdc7a5$ca67bd60$5f373820$@iname.com> Good stuff here: http://www.n2prise.org/fiber002.htm and http://www.n2prise.org/fiber003.htm Frank -----Original Message----- From: Jeff Kell [mailto:jeff-kell at utc.edu] Sent: Monday, November 19, 2012 3:37 PM To: nanog Subject: Fiber terminations -- UPC vs APC Looking for some guidance/references on the use of UPC versus APC terminations on fiber cabling. Traditionally we have done all of our fiber plant targeting data usage with UPC connectors. We are also looking at proposals for fiber distribution plant for video, and the possibility of using some of the existing fiber plant for that purpose; as well as any new fiber plant that gets installed for video potentially as data. The video folks are set, determined, and insistent that they need APC terminations. All data references I have found preach UPC. Cisco's SFP reference page even states (in bold): > *Note:* Only connections with patch cords with PC or UPC connectors are supported. > Patch cords with APC connectors are not supported. All cables and cable assemblies > used must be compliant with the standards specified in the standards section. So are we doomed to having physically separated fiber plants with suitable connectors / jumpers dedicated to video? Anyone been down this snaky looking path? Jeff From MKratz at internode.com.au Wed Nov 21 08:09:19 2012 From: MKratz at internode.com.au (Michael Kratz) Date: Wed, 21 Nov 2012 08:09:19 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50ABDE3D.5040505@cis.vutbr.cz> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50ABDE3D.5040505@cis.vutbr.cz> Message-ID: <52F05643-0A36-43FF-8176-8484EB841834@internode.com.au> On 21/11/2012, at 6:17 AM, Tomas Podermanski wrote: > Hi, > > On 11/20/12 7:24 PM, Blair Trosper wrote: >> I've found myself becoming a snob about IPv6. I almost look down on >> IPv4-only networks in the same way that I won't go see a film that isn't >> projected on DLP unless my arm is twisted. I'm a convert, and I'm glad to >> see the adoption rate edging up. >> >> However, I still scratch my head on why most major US ISPs *have* robust >> IPv6 peering and infrastructure and are ready to go, but they have not >> turned it on for their fiber/cable/DSL customers for reasons that are not >> clear to me. > > Turning IPv6 on at the basic/core of the infrastructure is the easiest > part of the > job. However turning IPv6 for customers requires a lot of effort and > compromises. Some of the reasons are described in: > > http://6lab.cz/article/deploying-ipv6-practical-problems-from-the-campus-perspective/ > > and related presentation: > > http://6lab.cz/wordpress/wp-content/uploads/2012/05/tnc2012_slides_TncPresentation.pdf We (Internode), an Australian ISP, have native dual-stack enabled by default (and have done for a while) for almost all new broadband services (ADSL, FTTH, etc.). Our existing customers can turn it on via an online toolbox. All the broadband CPE that we sell, support it. It's largely a non-issue for us now. Most new customers running a 'current' operating system, who buy an ADSL or FTTH service and their modem/router from us, automatically get IPv6 from day dot without even necessarily realising it. We recently passed 5% of our customer base being on IPv6: http://www.internode.on.net/news/2012/10/288.php -- Michael From gih at apnic.net Wed Nov 21 12:12:46 2012 From: gih at apnic.net (Geoff Huston) Date: Wed, 21 Nov 2012 23:12:46 +1100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> Message-ID: On 21/11/2012, at 3:05 AM, Patrick W. Gilmore wrote: > On Nov 20, 2012, at 08:45 , Owen DeLong wrote: > >> It is entirely possible that Google's numbers are artificially low for a number >> of reasons. > > AMS-IX publishes stats too: > > > This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%. > > Why do you think Google's numbers are lower than the real total? It depends on what you are trying to measure and how you are measuring it. I don't know Google's methodology, but lets say its a simple form of the experiment: "When presented with a dual stack object what percentage of users prefer to retrieve that object using IPv6 as compared to IPv4?" Up so a year or so ago if a browser had access to IPv6 and IPv4 it would first attempt to connect using IPv6 and if the connection failed then it timed out and then tried to use IPv4. So the experiment would be roughly commensurate with measuring working IPv6 systems on end sites connected to workin ipv6 access networks of one sort or another. More recently some browsers (Safari on Mac OSX, Chrome, Firefox with config settings enabled) have adopted a different strategy and when presented with a dual stack object some clients may end up trying the connection using IPv4 first and then fall back to IPv6 if IPv4 fails or times out. If the experiment simply counts the percent of clients who prefer to connect using IPv6 in a Dual Stack scenario, then some of these users running more recent versions of the browser will not be counted. There are ways to compensate for this, including running a series of tests, and this form of approach is described at http://labs.apnic.net/measureipv6/ I personally have no knowledge if the numbers published by Google reflect the "prefers to use IPv6 in dual stack mode" or "is capable of using IPv6 (by virtue of being able to retrieve a IPv6 only object)" These days the second number is larger than the first. Geoff From rs at seastrom.com Wed Nov 21 12:20:47 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 21 Nov 2012 07:20:47 -0500 Subject: NTP Issues Today In-Reply-To: (Blake Dunlap's message of "Tue, 20 Nov 2012 19:03:02 -0600") References: Message-ID: <86ehjncfkw.fsf@seastrom.com> Blake Dunlap writes: > That's what happens when you just follow vendor recommendations blindly. If > you do follow that on vm's (which can actually be a good practice), make > sure they pull from your own time infrastructure, and not just the world at > large, and that those servers behave in a sane fashion with regard to time > jumps. Emphatically disagree on the "pull from your own infrastructure" point. You probably don't have the budget even in a big company for sufficient diversity of sources [*] for your NTP server and even if you do the NTP servers will probably be run by the same person/organization. Mills has called the latter practice out as bad in the past. As Leo pointed out, the key is having a large diverse set so that if a couple of them go nuts they can be voted off the island. If you have a requirement for super low jitter or holdover if you lose network, you're looking at on-site devices with OCXO or Rb frequency standards in them. That doesn't mean you shouldn't be talking to the rest of the world too though. What if your on-site sources go nuts? This happens periodically, say every 10 years or so, because of crappy implementations and worst-current-practices. A re-read of https://groups.google.com/forum/?fromgroups=#!search/mills$20ntp$20byzantine/comp.protocols.time.ntp/TryjqtAd1XM/R0zzzE13Tl8J may prove instructive. (reading list also includes http://www.amazon.com/dp/1439814635/ ) In my experience NTP beats out even DNS for "blatantly wrong configs in the wild that nevertheless seem to work well enough that dilettante tech folks don't notice". I might have replied to this thread yesterday but I was blissfully unaware of any problems: rs at bifrost [8] % ntpq -c peers | egrep -v '(===|remote)' | wc -l 11 rs at bifrost [9] % -r [*] particularly due to shortsighted US federal government choices on LORAN, GOES, WWVB time format, etc From malayter at gmail.com Wed Nov 21 12:30:26 2012 From: malayter at gmail.com (Ryan Malayter) Date: Wed, 21 Nov 2012 06:30:26 -0600 Subject: NTP Issues Today In-Reply-To: <20121119161229.90E1DF03@m0005312.ppops.net> References: <20121119161229.90E1DF03@m0005312.ppops.net> Message-ID: <929E6D39-FFEC-45B2-BAFC-B1782086D043@gmail.com> On Nov 19, 2012, at 6:12 PM, "Scott Weeks" wrote: > wbailey at satelliteintelligencegroup.com> > > Or you could just concede the fact that the navy is playing with time travel again. > ---------------------------------------------------------- > > > To finish this thread off for the archives... > > Apparently something was up with the navy stuff as a post on > the outages shows. From malayter at gmail.com Wed Nov 21 12:34:13 2012 From: malayter at gmail.com (Ryan Malayter) Date: Wed, 21 Nov 2012 06:34:13 -0600 Subject: NTP Issues Today In-Reply-To: <20121119161229.90E1DF03@m0005312.ppops.net> References: <20121119161229.90E1DF03@m0005312.ppops.net> Message-ID: On Nov 19, 2012, at 6:12 PM, "Scott Weeks" wrote: > Lesson learned: Use more than one NTP source. > The lesson is: use MORE THAN TWO diverse NTP sources. A man with two watches has no idea what the time it actually is. From neil at tonal.clara.co.uk Wed Nov 21 12:58:38 2012 From: neil at tonal.clara.co.uk (Neil Harris) Date: Wed, 21 Nov 2012 12:58:38 +0000 Subject: NTP Issues Today In-Reply-To: References: <20121119161229.90E1DF03@m0005312.ppops.net> Message-ID: <50ACCFFE.6080400@tonal.clara.co.uk> On 21/11/12 12:34, Ryan Malayter wrote: > > On Nov 19, 2012, at 6:12 PM, "Scott Weeks" wrote: > >> Lesson learned: Use more than one NTP source. >> > The lesson is: use MORE THAN TWO diverse NTP sources. > > A man with two watches has no idea what the time it actually is. > > Per David Mills, from the discussion linked upthread, this should be FOUR OR MORE... "Every critical server should have at least four sources, no two from the same organization and, as much as possible, reachable only via diverse, nonintersecting paths." Four, so that the remaining three can reach consensus even if one fails. -- Neil From srao at ctigroup.com Wed Nov 21 13:06:54 2012 From: srao at ctigroup.com (Sid Rao) Date: Wed, 21 Nov 2012 13:06:54 +0000 Subject: NTP Issues Today In-Reply-To: <50ACCFFE.6080400@tonal.clara.co.uk> References: <20121119161229.90E1DF03@m0005312.ppops.net> , <50ACCFFE.6080400@tonal.clara.co.uk> Message-ID: <74CD3E4E-13B1-441A-BA0B-7BFAFFA15800@ctigroup.com> Guys: We were synchronized against multiple sources. Unfortunately the Navy NTP source contaminated multiple downstream sources. Unless you can trace all your sources, if these sources all have a root source you will break. Sid Rao | CTI Group | +1 (317) 262-4677 On Nov 21, 2012, at 8:01 AM, "Neil Harris" wrote: > On 21/11/12 12:34, Ryan Malayter wrote: >> >> On Nov 19, 2012, at 6:12 PM, "Scott Weeks" wrote: >> >>> Lesson learned: Use more than one NTP source. >> The lesson is: use MORE THAN TWO diverse NTP sources. >> >> A man with two watches has no idea what the time it actually is. > > Per David Mills, from the discussion linked upthread, this should be FOUR OR MORE... > > "Every critical server should have at least four sources, no two from the > same organization and, as much as possible, reachable only via diverse, > nonintersecting paths." > > Four, so that the remaining three can reach consensus even if one fails. > > -- Neil > > > From chuckchurch at gmail.com Wed Nov 21 13:28:06 2012 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 21 Nov 2012 08:28:06 -0500 Subject: NTP Issues Today In-Reply-To: References: Message-ID: <003201cdc7ec$0e56ef00$2b04cd00$@gmail.com> -----Original Message----- >From: Jimmy Hess [mailto:mysidia at gmail.com] >Sent: Tuesday, November 20, 2012 7:50 PM >To: Van Wolfe >Cc: nanog at nanog.org >Subject: Re: NTP Issues Today >This _should_ have caused NTP to execute a panic shutdown, >instead of setting the clock back 30 million seconds. >-- >-JH Sounds like SNTP might have been on the client. Doesn't do much if any sanity checking. Windows used to use that, was more than happy to change the time by years if bad time received. Not sure if that is still the case. Chuck From os10rules at gmail.com Wed Nov 21 13:50:29 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Wed, 21 Nov 2012 08:50:29 -0500 Subject: NTP Issues Today In-Reply-To: <003201cdc7ec$0e56ef00$2b04cd00$@gmail.com> References: <003201cdc7ec$0e56ef00$2b04cd00$@gmail.com> Message-ID: It sounds like the Navy and who ever else they partner with (NIST?) need some egress filtering on their NTP servers to catch and prevent events like this. From jmaimon at ttec.com Wed Nov 21 14:40:25 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 21 Nov 2012 09:40:25 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <006201cdc72e$dce4af10$96ae0d30$@tndh.net> References: <50AB49EA.3030101@cis.vutbr.cz> <006201cdc72e$dce4af10$96ae0d30$@tndh.net> Message-ID: <50ACE7D9.8070106@ttec.com> Tony Hain wrote: > Tomas Podermanski wrote: >> >> Hi, >> >> It seems that today is a "big day" for IPv6. It is the very first time > when >> native IPv6 on google statistics >> (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some >> might say it is tremendous success after 16 years of deploying IPv6 :-) >> >> T. > > Or one could look at it as; despite 16 years of lethargy and lack of > deployment by access networks, the traffic still finds a way. ;) > > Tony I say we better hope and pray that the network effect works as well for IPv6 as it did for IPv4. Otherwise 1% after 16 years represents nothing so much as ongoing failure. I have had approximately 0.01% interest from any user base. That would be an interesting number to watch change. Joe From arturo.servin at gmail.com Wed Nov 21 15:27:54 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 21 Nov 2012 13:27:54 -0200 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50ACE7D9.8070106@ttec.com> References: <50AB49EA.3030101@cis.vutbr.cz> <006201cdc72e$dce4af10$96ae0d30$@tndh.net> <50ACE7D9.8070106@ttec.com> Message-ID: <50ACF2FA.2050409@gmail.com> It won't. Users do not care about IPv6 or IPv4. They want a fast and reliable Internet connection. If you think you can do that with IPv4, you don't need to do anything (well, just plan for some budget for your CGNs). If not, better start deploying IPv6. .as On 21/11/2012 12:40, Joe Maimon wrote: > I have had approximately 0.01% interest from any user base. That would > be an interesting number to watch change. From tech-lists at packet-labs.net Wed Nov 21 04:51:50 2012 From: tech-lists at packet-labs.net (Jay) Date: Tue, 20 Nov 2012 23:51:50 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> Message-ID: <50AC5DE6.4050107@packet-labs.net> On 11/20/2012 1:24 PM, Blair Trosper wrote: > However, I still scratch my head on why most major US ISPs *have* robust > IPv6 peering and infrastructure and are ready to go, but they have not > turned it on for their fiber/cable/DSL customers for reasons that are not > clear to me. > > I keep pestering my home ISP about turning it on (since their network is > now 100% DOCSIS 3), but they just seem to think I'm making up words. One > can hope, though. This has partially been a vendor issue, at least for cable providers. Two of the major CMTS vendors (one starts with C, the other A) have had IPv6 related bugs in fairly recent code releases. Both of the MSOs I've worked for have had to delay IPv6 deployment while those vendors get their waterfowl properly aligned. I know we're still waiting for one vendor to get it straightened out. J From jra at baylink.com Wed Nov 21 15:41:01 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 21 Nov 2012 10:41:01 -0500 (EST) Subject: NTP Issues Today In-Reply-To: <74CD3E4E-13B1-441A-BA0B-7BFAFFA15800@ctigroup.com> Message-ID: <13544180.36036.1353512461566.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Sid Rao" > We were synchronized against multiple sources. Unfortunately the Navy > NTP source contaminated multiple downstream sources. > > Unless you can trace all your sources, if these sources all have a > root source you will break. "... against multiple [Stratum 1] sources..." Baby, if you've ever wondered... whether it matters whether your sources are strat 1 or not, now you know -- since there's no real way to get provenance on down-strat time sources that I'm aware of. Does the NTP code, people who know, give any extra credence to strat-1 sources in it's byzantine code? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From dhubbard at dino.hostasaurus.com Wed Nov 21 19:16:38 2012 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 21 Nov 2012 14:16:38 -0500 Subject: Road Runner route server, AS20001 / 7843 Message-ID: Anyone know of a route server on either of those AS's? Attempting to troubleshoot an issue that they're blaming on a fiber cut in Texas so I have to get more useful evidence to get it escalated. Thanks, David From msa at latt.net Wed Nov 21 20:29:47 2012 From: msa at latt.net (Majdi S. Abbas) Date: Wed, 21 Nov 2012 15:29:47 -0500 Subject: NTP Issues Today In-Reply-To: <13544180.36036.1353512461566.JavaMail.root@benjamin.baylink.com> References: <74CD3E4E-13B1-441A-BA0B-7BFAFFA15800@ctigroup.com> <13544180.36036.1353512461566.JavaMail.root@benjamin.baylink.com> Message-ID: <20121121202947.GC16071@puck.nether.net> On Wed, Nov 21, 2012 at 10:41:01AM -0500, Jay Ashworth wrote: > "... against multiple [Stratum 1] sources..." > > Baby, if you've ever wondered... whether it matters whether your sources > are strat 1 or not, now you know -- since there's no real way to get > provenance on down-strat time sources that I'm aware of. > > Does the NTP code, people who know, give any extra credence to strat-1 > sources in it's byzantine code? Not in a way that matters if one of them suddenly becomes a falseticker. If a reference clock goes insane, it's pretty easily detected provided you have at least two more servers (or even peers configured.) Stratum 1 just means it thinks it has a reference clock attached, but those clocks fail, go into holdover, what have you all the time. NTP will happily select a stratum 2 or lower clock instead provided it appears stable (low jitter, responded to our last 255 queries, and is an eligible candidate.) To get an idea what your NTP server will do, try ntpq -p: msa at paladin:/home/msa (582)$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== -nist1.symmetric .ACTS. 1 u 304 1024 377 5.140 3.271 0.581 +nist1-sj.ustimi .ACTS. 1 u 307 1024 377 7.843 5.227 0.729 +64.147.116.229 .ACTS. 1 u 414 1024 377 9.406 5.742 0.068 *usno.pa-x.dec.c .USNO. 1 u 540 1024 377 1.373 4.242 0.032 -pegasus.latt.ne 64.250.177.145 2 u 304 1024 377 61.383 5.920 6.578 -pyramid.latt.ne 216.171.124.36 2 u 361 1024 377 1.076 4.181 0.066 This is a stratum 2 server in the public pool. It's peering with two other stratum 2 servers that I run. Those two are deselected (-). The server marked with a * is selected, and those with a + are included in a weighted averdage used to maintain the system clock. If the primary selected server does something wonky, it's going to select one of the candidates marked with a +. In this case it has enough stratum 1 servers that it's not likely to fall back to its peers, but it can do so if those servers suddenly give it a set of unexpected replies. --msa From frnkblk at iname.com Wed Nov 21 20:54:34 2012 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 21 Nov 2012 14:54:34 -0600 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50AC5DE6.4050107@packet-labs.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50AC5DE6.4050107@packet-labs.net> Message-ID: <007201cdc82a$695fa570$3c1ef050$@iname.com> We have cable broadband operations using vendor M and we're a little gun-shy because that vendor has lagged the other two with IPv6 support, and when Comcast and TimeWarner began their production IPv6 rollouts on their CMTes it wasn't with vendor M. Frank -----Original Message----- From: Jay [mailto:tech-lists at packet-labs.net] Sent: Tuesday, November 20, 2012 10:52 PM To: nanog at nanog.org Subject: Re: Big day for IPv6 - 1% native penetration On 11/20/2012 1:24 PM, Blair Trosper wrote: > However, I still scratch my head on why most major US ISPs *have* robust > IPv6 peering and infrastructure and are ready to go, but they have not > turned it on for their fiber/cable/DSL customers for reasons that are not > clear to me. > > I keep pestering my home ISP about turning it on (since their network is > now 100% DOCSIS 3), but they just seem to think I'm making up words. One > can hope, though. This has partially been a vendor issue, at least for cable providers. Two of the major CMTS vendors (one starts with C, the other A) have had IPv6 related bugs in fairly recent code releases. Both of the MSOs I've worked for have had to delay IPv6 deployment while those vendors get their waterfowl properly aligned. I know we're still waiting for one vendor to get it straightened out. J From kyle.creyts at gmail.com Wed Nov 21 21:45:49 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Wed, 21 Nov 2012 13:45:49 -0800 Subject: 25Mbps vs 4 Mbps In-Reply-To: <69a3f799$7b5e5fd7$3cb06967$@flhsi.com> References: <69a3f799$7b5e5fd7$3cb06967$@flhsi.com> Message-ID: Don't forget that in some cases, there are ISP-local cache boxes... i.e. the "Youtube Servers" to which you refer may live _at_ the ISP. On Mon, Nov 19, 2012 at 7:19 AM, Nick Olsen wrote: > It's all about if the bandwidth is there to use. > > I'm sure every youtube caching server has a connection which exceeds > 4Mb/s. > > How does a faster connection help? It allows the video to fill the buffer > faster. Allowing for smoother playback on less bandwidth consistent > circuits. Do you need it really if your video source is under 4Mb/s? In a > perfect scenario, No. > > Now, That's youtube. Using Netflix as an example. > > I can start streaming a movie. And it'll pull 50-60Mb/s for about 20 > seconds, And it's playing HD quality almost immediately. Where on a slower > connection it may not switch to HD until its filled its buffer more. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Glen Kent" > Sent: Monday, November 19, 2012 10:04 AM > To: "nanog at nanog.org" > Subject: 25Mbps vs 4 Mbps > > Hi, > > The service provider(s) pipe that takes all web traffic from my laptop to > the central servers (assume youtube) remain same whether i take a 4Mbps or > a 25Mbps connection from my service provider. This means that the internet > connection that i take from my service provider only affects the last mile > -- from my home network to my service providers first access router. Given > this, would one really see a 6 times improvement in a 25Mbps connection > over a 4Mbps connection? > > I assume that the service providers rate limit the traffic much > more aggressively in a 4Mbps connection. But this would only matter if the > traffic from my youtube server is greater than 4Mbps, which i suspect > would > be the case. > > The question then is that how does going for a higher BW connection from > the service provider help? > > Glen > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From ask at develooper.com Wed Nov 21 22:06:16 2012 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Wed, 21 Nov 2012 14:06:16 -0800 Subject: NTP Issues Today In-Reply-To: References: <20121120190011.GA67074@ussenterprise.ufp.org> <2918274.35844.1353439699241.JavaMail.root@benjamin.baylink.com> <20121120201555.GA69041@ussenterprise.ufp.org> Message-ID: On Nov 20, 2012, at 13:00, Darius Jahandarie wrote: Hi everyone, I run the NTP Pool system - http://www.pool.ntp.org/ - so I have some opinions on some of this. :-) > But beyond that, I'm honestly rather curious what server selections > are a good idea. A first thought would be an adjacent country, but > maybe there is a benefit to picking things outside of the pool.ntp.org > selection entirely? First of all: None of the ~3800 servers in the NTP Pool system were affected by this as far as I can tell from the (copious) monitoring data. The big benefit to adding some non-pool servers is that you wouldn't be depending basically on a bunch of volunteers (and to a large extent me) for your time keeping. Though likely you'd just be depending on another group of volunteers. In addition to depending on the server operators who run the ntpd servers you also depend on: 1) The monitoring system keeping accurate time. 2) The monitoring system does its job catching bad servers. 3) The process updating and distributing the DNS data working. 4) The DNS servers working (and not being under a DoS attack or similar). 5) Anything I haven't thought of! Empirically I believe we've done a better job than just about anyone with a similar scale, but past performance is no promise of the future. > I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a > specific reason for that or if my questions are even worth thinking > about at all :-). The servers for x.fedora.pool.ntp.org are in the same "group" as x.pool.ntp.org. If you are in a country with many servers in the pool then you'll very likely get different IPs for the two. If you are in a country with few servers your odds for that aren't so good and it'd be a bit pointless. Anyone using the NTP Pool in a default configuration (like Fedora does) must get a "vendor zone" setup - http://www.pool.ntp.org/en/vendors.html - so we have at least a little bit of a chance to monitor and mitigate problems. It also allows us to change what servers are selected, how many IPs are returned etc for a particular vendor. For example if Fedora in the future changes to use 'pool' instead of 'server' in the configuration we could optimize for that. Ask -- http://askask.com/ From kyle.creyts at gmail.com Wed Nov 21 22:16:10 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Wed, 21 Nov 2012 14:16:10 -0800 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: <50ABEC5A.20104@meetinghouse.net> References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> <50ABD061.4030500@snappydsl.net> <50ABEC5A.20104@meetinghouse.net> Message-ID: And they do have those towers all over the country... On Tue, Nov 20, 2012 at 12:47 PM, Miles Fidelman wrote: > Christopher Morrow wrote: >> >> apologies, I forgot the emoticons after my last comment. i really did mean >> it in jest... I don't think VZ has harnessed weather-changing-powers. (yet). > > > Well, they ARE The Phone Company! > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From sotnickd-nanog at ddv.com Thu Nov 22 01:53:19 2012 From: sotnickd-nanog at ddv.com (Dave Sotnick) Date: Wed, 21 Nov 2012 17:53:19 -0800 Subject: Recovering from spam resulting from compromised account Message-ID: Hello, oh knowledgeable NANOG. I am the technical lead for network for Pixar. (Note: I am not the mail admin, he's on vacation.) Yesterday we had an account compromise that resulted in ~2.5M messages being sent through our two MTAs. I have acknowledged/closed the two SpamCop incidents, and mail is starting to flow, slowly, however we are still receiving bounces (some hard!) and I am looking for assistance in getting Pixar's IPs cleared from the blacklists. I was pointed to: http://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a12.25.180.66 http://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a12.25.180.94 Which shows we're still listed on Backscatterer and SPAM Cannibal. Also had reports that we're still seeing bounces to Gmail, Comcast and Yahoo accounts. What can we do to speed things along? We have a ticket open with Gmail folks since we have a studio who uses Gmail for Corporate mail. Any Comcast or Gmail SMTP contacts on NANOG that can help? Would love to get all out stuck mail out of these folks' MTAs. Or do we need to just remove ourselves from the last two blacklists at mxtoolbox? Thanks, David Sotnick -- Pixar Emeryville, CA From ops.lists at gmail.com Thu Nov 22 02:01:59 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 22 Nov 2012 07:31:59 +0530 Subject: Recovering from spam resulting from compromised account In-Reply-To: References: Message-ID: So - 1. backscatterer and spamcannibal are obscure blocklists nobody ever uses. Spamcannibal is actually quite reasonable about removals if you declare the issue fixed 2. Gmail, comcast etc have their own blocklist removal procedures - based on you contacting their postmaster teams. postmaster.comcast.net, etc etc. 3. MXToolbox is merely a search engine for various publicly available blocklists. Gmail etc blocks wont show up there because those dont get exposed outside the provider's servers .. if you get listed on gmail you know because you see your mail bounced or bulk foldered. --srs On Thu, Nov 22, 2012 at 7:23 AM, Dave Sotnick wrote: > Hello, oh knowledgeable NANOG. > > I am the technical lead for network for Pixar. (Note: I am not the > mail admin, he's on vacation.) Yesterday we had an account compromise > that resulted in ~2.5M messages being sent through our two MTAs. > > I have acknowledged/closed the two SpamCop incidents, and mail is > starting to flow, slowly, however we are still receiving bounces (some > hard!) and I am looking for assistance in getting Pixar's IPs cleared > from the blacklists. > > I was pointed to: > > http://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a12.25.180.66 > http://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a12.25.180.94 > > Which shows we're still listed on Backscatterer and SPAM Cannibal. > > Also had reports that we're still seeing bounces to Gmail, Comcast and > Yahoo accounts. > > What can we do to speed things along? We have a ticket open with Gmail > folks since we have a studio who uses Gmail for Corporate mail. Any > Comcast or Gmail SMTP contacts on NANOG that can help? Would love to > get all out stuck mail out of these folks' MTAs. > > Or do we need to just remove ourselves from the last two blacklists at > mxtoolbox? > > Thanks, > David Sotnick > -- > Pixar > Emeryville, CA > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jtowne at slic.com Thu Nov 22 02:27:01 2012 From: jtowne at slic.com (Jonathan Towne) Date: Wed, 21 Nov 2012 21:27:01 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50AC5DE6.4050107@packet-labs.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50AC5DE6.4050107@packet-labs.net> Message-ID: <20121122022701.GU24172@hijacked.us> On Tue, Nov 20, 2012 at 11:51:50PM -0500, Jay scribbled: # On 11/20/2012 1:24 PM, Blair Trosper wrote: # >However, I still scratch my head on why most major US ISPs *have* robust # >IPv6 peering and infrastructure and are ready to go, but they have not # >turned it on for their fiber/cable/DSL customers for reasons that are not # >clear to me. # > # >I keep pestering my home ISP about turning it on (since their network is # >now 100% DOCSIS 3), but they just seem to think I'm making up words. One # >can hope, though. # # This has partially been a vendor issue, at least for cable # providers. Two of the major CMTS vendors (one starts with C, the # other A) have had IPv6 related bugs in fairly recent code releases. # Both of the MSOs I've worked for have had to delay IPv6 deployment # while those vendors get their waterfowl properly aligned. I know # we're still waiting for one vendor to get it straightened out. I know it to be a vendor issue for GPON FTTH gear, as well. At least with one major vendor (begins with a C also). They're definitely lagging. We have an IPv6 deployment in the core natively, as well built as our IPv4 infrastructure, and yet nothing on the access side. Any quarter now, I'm still hearing. Until then, we wait, and the pool of IPv4 dwindles. -- Jonathan Towne From sotnickd-nanog at ddv.com Thu Nov 22 02:29:18 2012 From: sotnickd-nanog at ddv.com (Dave Sotnick) Date: Wed, 21 Nov 2012 18:29:18 -0800 Subject: Recovering from spam resulting from compromised account In-Reply-To: References: Message-ID: Thanks Matthew. Sadly, most of the bounce responses have URLs that point you to a help page that doesn't have further contact information or just tells you to wait it out. e.g. http://postmaster.yahoo.com/421-ts03.html http://www.google.com/mail/help/bulk_mail.html I'll do the requisite digging and start contacting postmasters. -Dave On Wed, Nov 21, 2012 at 6:13 PM, Matthew Barr wrote: > > On Nov 21, 2012, at 8:53 PM, Dave Sotnick wrote: >> Also had reports that we're still seeing bounces to Gmail, Comcast and >> Yahoo accounts. > > > The best thing to do is to go ahead and look at the bounce messages from the various ISP's, and see if they have any instructions or URL's to contact. > > If you don't have any of those messages at hand, you can see the bounce codes in the logs of your mailserver. > > If you don't have any useful messages in the bounce code, then you can probably look at the site for each ISP, and google their postmaster group. > > Matthew > > > Matthew Barr > Technical Architect > Snap Interactive > mbarr at mbarr.net From aj at jonesy.com.au Thu Nov 22 02:36:27 2012 From: aj at jonesy.com.au (Andrew Jones) Date: Thu, 22 Nov 2012 13:36:27 +1100 Subject: Recovering from spam resulting from compromised account In-Reply-To: References: Message-ID: <79272fb73a3c6e05a70255dabfa43f8f@jonesy.com.au> Hi Dave, Try this page, linked from the google help page you referenced: https://support.google.com/mail/bin/answer.py?hl=en&answer=81126&rd=1 Hope that helps Andrew On 22.11.2012 13:29, Dave Sotnick wrote: > Thanks Matthew. Sadly, most of the bounce responses have URLs that > point you to a help page that doesn't have further contact > information > or just tells you to wait it out. > > e.g. > > http://postmaster.yahoo.com/421-ts03.html > http://www.google.com/mail/help/bulk_mail.html > > I'll do the requisite digging and start contacting postmasters. > > -Dave > > On Wed, Nov 21, 2012 at 6:13 PM, Matthew Barr > wrote: >> >> On Nov 21, 2012, at 8:53 PM, Dave Sotnick >> wrote: >>> Also had reports that we're still seeing bounces to Gmail, Comcast >>> and >>> Yahoo accounts. >> >> >> The best thing to do is to go ahead and look at the bounce messages >> from the various ISP's, and see if they have any instructions or URL's >> to contact. >> >> If you don't have any of those messages at hand, you can see the >> bounce codes in the logs of your mailserver. >> >> If you don't have any useful messages in the bounce code, then you >> can probably look at the site for each ISP, and google their >> postmaster group. >> >> Matthew >> >> >> Matthew Barr >> Technical Architect >> Snap Interactive >> mbarr at mbarr.net From ops.lists at gmail.com Thu Nov 22 02:42:07 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 22 Nov 2012 08:12:07 +0530 Subject: Recovering from spam resulting from compromised account In-Reply-To: References: Message-ID: Wait it out as in - you had better examine your mail queues and purge them of any of the spam that was sent and is still queued up. It'll still take a day or two after that's done for the blocks to subside. On Thu, Nov 22, 2012 at 7:59 AM, Dave Sotnick wrote: > Thanks Matthew. Sadly, most of the bounce responses have URLs that > point you to a help page that doesn't have further contact information > or just tells you to wait it out. > > e.g. > > http://postmaster.yahoo.com/421-ts03.html > http://www.google.com/mail/help/bulk_mail.html > > I'll do the requisite digging and start contacting postmasters. > > -Dave > > On Wed, Nov 21, 2012 at 6:13 PM, Matthew Barr > wrote: > > > > On Nov 21, 2012, at 8:53 PM, Dave Sotnick > wrote: > >> Also had reports that we're still seeing bounces to Gmail, Comcast and > >> Yahoo accounts. > > > > > > The best thing to do is to go ahead and look at the bounce messages from > the various ISP's, and see if they have any instructions or URL's to > contact. > > > > If you don't have any of those messages at hand, you can see the bounce > codes in the logs of your mailserver. > > > > If you don't have any useful messages in the bounce code, then you can > probably look at the site for each ISP, and google their postmaster group. > > > > Matthew > > > > > > Matthew Barr > > Technical Architect > > Snap Interactive > > mbarr at mbarr.net > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From skeeve at eintellego.net Thu Nov 22 05:07:46 2012 From: skeeve at eintellego.net (Skeeve Stevens) Date: Thu, 22 Nov 2012 16:07:46 +1100 Subject: H3C Technical List Message-ID: Hey all, Anyone know of a Mailing list like Cisco-NSP/Juniper-NSP for HP/H3C equipment? I have some questions regarding some H3C Switch spanning-tree behaviour, but I can't find anyone to ask. The couple of lists on puck have had almost no traffic for a ling time. Thanks all. * * *Skeeve Stevens, CEO - *eintellego Pty Ltd skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego ; linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net The Experts Who The Experts Call Juniper - Cisco ? IBM - Brocade - Cloud ----- Check out our Juniper promotion website for Oct/Nov! eintellego.mx Free Apple products during this promotion!!! From Neil at droopy.com Thu Nov 22 05:17:43 2012 From: Neil at droopy.com (Neil at droopy.com) Date: Thu, 22 Nov 2012 05:17:43 +0000 Subject: H3C Technical List In-Reply-To: References: Message-ID: <53B8C02E23F77A42A9DD20A7ADB17B59085BF6EB@A2Z-EXCH01.droopy.local> Hello there Skeeve! I'll see if I can help you out. I work on comware (HPN/H3C) based gear quite a bit. Neil Moore -----Original Message----- From: Skeeve Stevens [mailto:skeeve at eintellego.net] Sent: Wednesday, November 21, 2012 11:08 PM To: nanog at nanog.org Subject: H3C Technical List Hey all, Anyone know of a Mailing list like Cisco-NSP/Juniper-NSP for HP/H3C equipment? I have some questions regarding some H3C Switch spanning-tree behaviour, but I can't find anyone to ask. The couple of lists on puck have had almost no traffic for a ling time. Thanks all. * * *Skeeve Stevens, CEO - *eintellego Pty Ltd skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego ; linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net The Experts Who The Experts Call Juniper - Cisco - IBM - Brocade - Cloud ----- Check out our Juniper promotion website for Oct/Nov! eintellego.mx Free Apple products during this promotion!!! From Ben.Butler at c2internet.net Thu Nov 22 11:28:31 2012 From: Ben.Butler at c2internet.net (Ben S. Butler) Date: Thu, 22 Nov 2012 11:28:31 +0000 Subject: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E308@EXCHANGE.atlasbiz.com> References: <416A23FC91E34449999D047BF540B46901689658E2EE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2EF@EXCHANGE.atlasbiz.com> <50A3CD39.4020509@geier.ne.tz> <416A23FC91E34449999D047BF540B46901689658E2FB@EXCHANGE.atlasbiz.com> <744BC8D7-64D6-4390-9A6C-1F3AF50CB5FA@mac.com> <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com> <416A23FC91E34449999D047BF540B46901689658E2FC@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E2FE@EXCHANGE.atlasbiz.com> <416A23FC91E34449999D047BF540B46901689658E308@EXCHANGE.atlasbiz.com> Message-ID: <416A23FC91E34449999D047BF540B46901940A8E6AA1@EXCHANGE.atlasbiz.com> Hi, I have been thinking some more. Could we not solve the problem of legacy assignments of /32s that have been split to /48 with no covering route out of a RIR block with a /32 minimum with relative ease. AS operators that choose to filter these RIR blocks on /48 minimum have no problems, ISPs that choose to filter on /32 minimum do as they loose visibility of these "island networks" aka no covering route. If we were to extend peeringDB to add a field to indicate with there is a covering route or not, this could then be used to assign a peer to a peer-group with the associated filter as appropriate either permitting 48s or denying them. This enables the people that have deigned their networks in this fashion to indicate as such, and those who choose to use the information can accept their prefixes without having to accept any old 48. Peering DB could then also publish a RegExp string from their database of all the ASes that have indicated no covering route. This could then be used, if desired, by an AS operator to filter his BGP sessions which are not directly with the end AS, transit or peering, enabling the deployment of a route-map that would match the RegExp and prefix length of 48 and permit these, then match the Regexp with a prefix length <>48 and deny all of that (because there shouldn't be any), and then match what is left on a filter list that selected on RIR minimums. The island networks would be incentivised to register, those that choose to filter can, those that don't want to can accept all 48s. Filters can be used on RIR minimums and new assignments made out of the new non-contiguous address blocks with a 48 minimum size, and the legacy problem is handled. Everyone is happy. No technology needs to change and all that is needed is for someone such as peeringDB to keep a record of the ASes that indicate they don't have a covering route and this can be readily used when setting up direct peerings or used to construct a generic filter for all ASes in this category to be applied to other BGP sessions. Thoughts.... RIPE seems to be saying its upto the community to decide policy, ours is a /32 minimum and we strongly recommend you don't de-agregate but we are not going to tell you you can't. The legacy of island networks is the only thing that forces this issue to be dealt with one way or the other as it is not possible for them as they currently have things setup to announce the covering route. I think a BCP would be good that considered alternatives to the polarized debate of do or don't do minimum filters vs TE routes vs why should I carry your TE. I think something like the above could be simply implemented as an opt in system that could be used if operators choose to that would keep all three groups of AS operators happy. Ben -----Original Message----- From: Ben S. Butler Sent: 16 November 2012 00:54 To: 'Matthew Petach'; Ben S. Butler Cc: nanog at nanog.org Subject: RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. From cjp at 0x1.net Thu Nov 22 16:12:06 2012 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Thu, 22 Nov 2012 11:12:06 -0500 Subject: H3C Technical List In-Reply-To: References: Message-ID: <2694352677007146763@unknownmsgid> Also would be interested, we've a few H3C routers. On Nov 22, 2012, at 0:09, Skeeve Stevens wrote: > Hey all, > > Anyone know of a Mailing list like Cisco-NSP/Juniper-NSP for HP/H3C > equipment? > > I have some questions regarding some H3C Switch spanning-tree behaviour, > but I can't find anyone to ask. The couple of lists on puck have had > almost no traffic for a ling time. > > Thanks all. > > * > * > *Skeeve Stevens, CEO - *eintellego Pty Ltd > skeeve at eintellego.net ; www.eintellego.net > > Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellego ; > linkedin.com/in/skeeve > > twitter.com/networkceoau ; blog: www.network-ceo.net > > The Experts Who The Experts Call > Juniper - Cisco ? IBM - Brocade - Cloud > ----- > Check out our Juniper promotion website for Oct/Nov! eintellego.mx > Free Apple products during this promotion!!! From jared at puck.nether.net Thu Nov 22 16:23:56 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 Nov 2012 11:23:56 -0500 Subject: H3C Technical List In-Reply-To: References: Message-ID: <7FC7B858-DCA7-4D78-B22E-F9A890682CCE@puck.nether.net> Point people at the lists. If people need new lists just email me in private. Jared Mauch On Nov 22, 2012, at 12:07 AM, Skeeve Stevens wrote: > Hey all, > > Anyone know of a Mailing list like Cisco-NSP/Juniper-NSP for HP/H3C > equipment? > > I have some questions regarding some H3C Switch spanning-tree behaviour, > but I can't find anyone to ask. The couple of lists on puck have had > almost no traffic for a ling time. > > Thanks all. > > * > * > *Skeeve Stevens, CEO - *eintellego Pty Ltd > skeeve at eintellego.net ; www.eintellego.net > > Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellego ; > linkedin.com/in/skeeve > > twitter.com/networkceoau ; blog: www.network-ceo.net > > The Experts Who The Experts Call > Juniper - Cisco ? IBM - Brocade - Cloud > ----- > Check out our Juniper promotion website for Oct/Nov! eintellego.mx > Free Apple products during this promotion!!! From carlosm3011 at gmail.com Thu Nov 22 18:41:08 2012 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Thu, 22 Nov 2012 16:41:08 -0200 Subject: LACNIC RPKI RTA key rollover Message-ID: <50AE71C4.4010004@gmail.com> Folks, On Thursday, November 29, 2012 LACNIC will be performing a system migration to a new release of the RPKI system. We will take the opportunity to also perform a key rollover of LACNIC's RPKI trust anchor. The new TAL (trust anchor locator) file can be downloaded from [1]. Also a ready-to-use configuration file for RIPE-NCC's Validation Application is available at [2]. Both the certificate and repository this TAL points to are already active, but the main repository material (resource CAs and ROAs) will be migrated on the same date at 14.00 UTC. All relying-party operators are encouraged to download the TAL file and add it to their validation tool configuration before that time in order to maintain continuity of validation. [1] https://rpki.lacnic.net/tal/lacnic-201212.tal [2] https://rpki.lacnic.net/tal/lacnic-ripeval-201212.tal If you have any questions please do not hesitate to contact us at rpki-admin at lacnic.net Warm regards, Carlos From mkorourke+nanog at gmail.com Thu Nov 22 18:51:48 2012 From: mkorourke+nanog at gmail.com (Mick O'Rourke) Date: Fri, 23 Nov 2012 05:51:48 +1100 Subject: H3C Technical List In-Reply-To: References: Message-ID: HP-NSP. I've been subscribed for a couple of years, it's suffice to say volume is dead low. Guessing you've checked this and are after something with volume. https://puck.nether.net/mailman/listinfo/ Did you try the HP H3C web forums? That said last I checked they seemed almost as dead as the hp-nsp list. On Thu, Nov 22, 2012 at 4:07 PM, Skeeve Stevens wrote: > Hey all, > > Anyone know of a Mailing list like Cisco-NSP/Juniper-NSP for HP/H3C > equipment? > > I have some questions regarding some H3C Switch spanning-tree behaviour, > but I can't find anyone to ask. The couple of lists on puck have had > almost no traffic for a ling time. > > Thanks all. > > * > * > *Skeeve Stevens, CEO - *eintellego Pty Ltd > skeeve at eintellego.net ; www.eintellego.net > > Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellego ; > linkedin.com/in/skeeve > > twitter.com/networkceoau ; blog: www.network-ceo.net > > The Experts Who The Experts Call > Juniper - Cisco ? IBM - Brocade - Cloud > ----- > Check out our Juniper promotion website for Oct/Nov! eintellego.mx > Free Apple products during this promotion!!! > From nitzan.tzelniker at gmail.com Fri Nov 23 07:57:25 2012 From: nitzan.tzelniker at gmail.com (Nitzan Tzelniker) Date: Fri, 23 Nov 2012 09:57:25 +0200 Subject: H3C Technical List In-Reply-To: References: Message-ID: In this forum on HP site I see 5 post from last week http://h30499.www3.hp.com/t5/Comware-Based/bd-p/switching-a-series-forum Nitzan On Thu, Nov 22, 2012 at 8:51 PM, Mick O'Rourke wrote: > HP-NSP. I've been subscribed for a couple of years, it's suffice to say > volume is dead low. Guessing you've checked this and are after something > with volume. > > https://puck.nether.net/mailman/listinfo/ > > Did you try the HP H3C web forums? That said last I checked they seemed > almost as dead as the hp-nsp list. > > > > On Thu, Nov 22, 2012 at 4:07 PM, Skeeve Stevens >wrote: > > > Hey all, > > > > Anyone know of a Mailing list like Cisco-NSP/Juniper-NSP for HP/H3C > > equipment? > > > > I have some questions regarding some H3C Switch spanning-tree behaviour, > > but I can't find anyone to ask. The couple of lists on puck have had > > almost no traffic for a ling time. > > > > Thanks all. > > > > * > > * > > *Skeeve Stevens, CEO - *eintellego Pty Ltd > > skeeve at eintellego.net ; www.eintellego.net > > > > Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve > > > > facebook.com/eintellego ; > > linkedin.com/in/skeeve > > > > twitter.com/networkceoau ; blog: www.network-ceo.net > > > > The Experts Who The Experts Call > > Juniper - Cisco ? IBM - Brocade - Cloud > > ----- > > Check out our Juniper promotion website for Oct/Nov! eintellego.mx > > Free Apple products during this promotion!!! > > > From cja at daydream.com Fri Nov 23 14:46:59 2012 From: cja at daydream.com (CJ Aronson) Date: Fri, 23 Nov 2012 07:46:59 -0700 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50ACF2FA.2050409@gmail.com> References: <50AB49EA.3030101@cis.vutbr.cz> <006201cdc72e$dce4af10$96ae0d30$@tndh.net> <50ACE7D9.8070106@ttec.com> <50ACF2FA.2050409@gmail.com> Message-ID: Arturo is right.. Internet users could care less what protocol they use just like most of us could care less if the road we drive to work is asphalt, chip seal, or concrete. We just want it to be smooth and get us where we want to go at the speed we want to drive. I can see some things changing this, however, this sort of thing http://www.greentechmedia.com/articles/read/the-ipv6-addressable-light-bulb-goes-on-sale could make consumers interested in asking for IPv6. Mostly, however, if we're really waiting for folks to ask for it we're going to have to wait a very long time. ----Cathy On Wed, Nov 21, 2012 at 8:27 AM, Arturo Servin wrote: > > It won't. > > Users do not care about IPv6 or IPv4. They want a fast and reliable > Internet connection. > > If you think you can do that with IPv4, you don't need to do anything > (well, just plan for some budget for your CGNs). If not, better start > deploying IPv6. > > .as > > On 21/11/2012 12:40, Joe Maimon wrote: >> I have had approximately 0.01% interest from any user base. That would >> be an interesting number to watch change. > From cscora at apnic.net Fri Nov 23 18:52:49 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Nov 2012 04:52:49 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201211231852.qANIqn46010114@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 24 Nov, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 433102 Prefixes after maximum aggregation: 180255 Deaggregation factor: 2.40 Unique aggregates announced to Internet: 212958 Total ASes present in the Internet Routing Table: 42668 Prefixes per ASN: 10.15 Origin-only ASes present in the Internet Routing Table: 33846 Origin ASes announcing only one prefix: 15810 Transit ASes present in the Internet Routing Table: 5685 Transit-only ASes present in the Internet Routing Table: 146 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 36 Prefixes from unregistered ASNs in the Routing Table: 1075 Unregistered ASNs in the Routing Table: 391 Number of 32-bit ASNs allocated by the RIRs: 3517 Number of 32-bit ASNs visible in the Routing Table: 3137 Prefixes from 32-bit ASNs in the Routing Table: 8493 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 142 Number of addresses announced to Internet: 2614015436 Equivalent to 155 /8s, 206 /16s and 181 /24s Percentage of available address space announced: 70.6 Percentage of allocated address space announced: 70.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.9 Total number of prefixes smaller than registry allocations: 152688 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 104685 Total APNIC prefixes after maximum aggregation: 32638 APNIC Deaggregation factor: 3.21 Prefixes being announced from the APNIC address blocks: 105522 Unique aggregates announced from the APNIC address blocks: 43207 APNIC Region origin ASes present in the Internet Routing Table: 4790 APNIC Prefixes per ASN: 22.03 APNIC Region origin ASes announcing only one prefix: 1245 APNIC Region transit ASes present in the Internet Routing Table: 785 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 369 Number of APNIC addresses announced to Internet: 714988544 Equivalent to 42 /8s, 157 /16s and 220 /24s Percentage of available APNIC address space announced: 83.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, 131072-133119 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: 155445 Total ARIN prefixes after maximum aggregation: 78480 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 156204 Unique aggregates announced from the ARIN address blocks: 70101 ARIN Region origin ASes present in the Internet Routing Table: 15305 ARIN Prefixes per ASN: 10.21 ARIN Region origin ASes announcing only one prefix: 5768 ARIN Region transit ASes present in the Internet Routing Table: 1600 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1087357824 Equivalent to 64 /8s, 207 /16s and 195 /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, 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: 110433 Total RIPE prefixes after maximum aggregation: 57925 RIPE Deaggregation factor: 1.91 Prefixes being announced from the RIPE address blocks: 113258 Unique aggregates announced from the RIPE address blocks: 73050 RIPE Region origin ASes present in the Internet Routing Table: 16968 RIPE Prefixes per ASN: 6.67 RIPE Region origin ASes announcing only one prefix: 8133 RIPE Region transit ASes present in the Internet Routing Table: 2751 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2029 Number of RIPE addresses announced to Internet: 648840484 Equivalent to 38 /8s, 172 /16s and 133 /24s Percentage of available RIPE address space announced: 94.3 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, 196608-199679 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: 44379 Total LACNIC prefixes after maximum aggregation: 8880 LACNIC Deaggregation factor: 5.00 Prefixes being announced from the LACNIC address blocks: 47907 Unique aggregates announced from the LACNIC address blocks: 22966 LACNIC Region origin ASes present in the Internet Routing Table: 1715 LACNIC Prefixes per ASN: 27.93 LACNIC Region origin ASes announcing only one prefix: 487 LACNIC Region transit ASes present in the Internet Routing Table: 328 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 716 Number of LACNIC addresses announced to Internet: 119525160 Equivalent to 7 /8s, 31 /16s and 207 /24s Percentage of available LACNIC address space announced: 71.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 9551 Total AfriNIC prefixes after maximum aggregation: 2277 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 10069 Unique aggregates announced from the AfriNIC address blocks: 3511 AfriNIC Region origin ASes present in the Internet Routing Table: 574 AfriNIC Prefixes per ASN: 17.54 AfriNIC Region origin ASes announcing only one prefix: 177 AfriNIC Region transit ASes present in the Internet Routing Table: 129 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 43010560 Equivalent to 2 /8s, 144 /16s and 74 /24s Percentage of available AfriNIC address space announced: 42.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2949 11557 900 Korea Telecom (KIX) 17974 2431 826 46 PT TELEKOMUNIKASI INDONESIA 7545 1802 301 89 TPG Internet Pty Ltd 4755 1622 374 158 TATA Communications formerly 9829 1411 1155 42 BSNL National Internet Backbo 9583 1181 88 498 Sify Limited 7552 1140 1062 11 Vietel Corporation 4808 1126 2056 317 CNCGROUP IP network: China169 24560 1040 385 165 Bharti Airtel Ltd., Telemedia 9498 1028 310 75 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3201 991 190 Windstream Communications Inc 6389 3152 3720 151 bellsouth.net, inc. 18566 2084 382 180 Covad Communications 22773 1945 2931 129 Cox Communications, Inc. 1785 1932 678 126 PaeTec Communications, Inc. 20115 1684 1607 625 Charter Communications 4323 1587 1153 393 Time Warner Telecom 30036 1365 281 749 Mediacom Communications Corp 7018 1281 10276 851 AT&T WorldNet Services 7011 1222 334 692 Citizens Utilities 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 1765 544 16 Corbina telecom 12479 857 777 64 Uni2 Autonomous System 34984 848 210 214 BILISIM TELEKOM 13188 739 94 130 Educational Network 31148 731 37 9 FreeNet ISP 6830 716 2313 435 UPC Distribution Services 20940 710 228 548 Akamai Technologies European 58113 602 67 365 LIR DATACENTER TELECOM SRL 8551 601 367 39 Bezeq International 2118 595 97 14 EUnet/RELCOM Autonomous Syste Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2260 386 205 TVCABLE BOGOTA 28573 2178 1285 66 NET Servicos de Comunicao S.A 7303 1668 1138 201 Telecom Argentina Stet-France 8151 1600 3045 361 UniNet S.A. de C.V. 6503 1538 435 67 AVANTEL, S.A. 27947 752 77 92 Telconet S.A 3816 660 309 70 Empresa Nacional de Telecomun 11172 603 85 68 Servicios Alestra S.A de C.V 18881 594 716 18 Global Village Telecom 22047 579 326 15 VTR PUNTO NET 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 24863 871 274 36 LINKdotNET AS number 36998 772 48 3 MOBITEL 6713 518 666 20 Itissalat Al-MAGHRIB 8452 515 958 13 TEDATA 24835 289 80 8 RAYA Telecom - Egypt 3741 268 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 181 697 88 MTN Network Solutions 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 7029 3201 991 190 Windstream Communications Inc 6389 3152 3720 151 bellsouth.net, inc. 4766 2949 11557 900 Korea Telecom (KIX) 17974 2431 826 46 PT TELEKOMUNIKASI INDONESIA 10620 2260 386 205 TVCABLE BOGOTA 28573 2178 1285 66 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 22773 1945 2931 129 Cox Communications, Inc. 1785 1932 678 126 PaeTec Communications, Inc. 7545 1802 301 89 TPG Internet Pty Ltd 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 3152 3001 bellsouth.net, inc. 17974 2431 2385 PT TELEKOMUNIKASI INDONESIA 28573 2178 2112 NET Servicos de Comunicao S.A 10620 2260 2055 TVCABLE BOGOTA 4766 2949 2049 Korea Telecom (KIX) 18566 2084 1904 Covad Communications 22773 1945 1816 Cox Communications, Inc. 1785 1932 1806 PaeTec Communications, Inc. 8402 1765 1749 Corbina telecom 7545 1802 1713 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59530 UNALLOCATED 5.8.182.0/24 31261 GARS Telecom 61408 UNALLOCATED 5.56.0.0/21 174 Cogent Communication 61395 UNALLOCATED 5.83.56.0/22 3292 TDC Tele Danmark 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.222.80.0/21 37110 Moztel LDA 41.223.108.0/22 36966 >>UNKNOWN<< 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.66.32.0/20 18864 >>UNKNOWN<< 64.187.208.0/24 174 Cogent Communications 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:18 /9:13 /10:29 /11:88 /12:242 /13:477 /14:857 /15:1556 /16:12439 /17:6547 /18:10885 /19:21423 /20:30769 /21:32783 /22:43599 /23:40541 /24:226565 /25:1364 /26:1713 /27:894 /28:178 /29:79 /30:17 /31:0 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2641 3201 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1782 3152 bellsouth.net, inc. 8402 1483 1765 Corbina telecom 30036 1279 1365 Mediacom Communications Corp 22773 1275 1945 Cox Communications, Inc. 11492 1145 1180 Cable One 6503 1055 1538 AVANTEL, S.A. 1785 1017 1932 PaeTec Communications, Inc. 7011 957 1222 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:654 2:779 3:1 4:13 5:654 6:3 8:487 12:1958 13:3 14:698 15:11 16:3 17:6 20:27 23:213 24:1779 27:1417 31:1277 32:54 33:2 34:2 36:7 37:1042 38:843 39:2 40:140 41:2612 42:179 44:3 46:1668 47:2 49:506 50:612 52:12 54:27 55:4 57:28 58:1062 59:549 60:234 61:1284 62:1029 63:2025 64:4337 65:2200 66:4513 67:2101 68:1162 69:3232 70:928 71:556 72:1895 74:2617 75:484 76:299 77:993 78:1013 79:505 80:1234 81:985 82:622 83:539 84:523 85:1159 86:514 87:957 88:348 89:1745 90:305 91:5348 92:589 93:1530 94:1815 95:1413 96:409 97:323 98:976 99:40 100:31 101:291 103:1830 105:514 106:119 107:203 108:480 109:1653 110:821 111:983 112:459 113:735 114:686 115:901 116:887 117:779 118:961 119:1241 120:367 121:677 122:1739 123:1170 124:1327 125:1289 128:561 129:201 130:294 131:664 132:310 133:143 134:253 135:62 136:218 137:238 138:340 139:175 140:507 141:290 142:498 143:363 144:483 145:87 146:529 147:265 148:738 149:330 150:148 151:220 152:398 153:183 154:22 155:434 156:227 157:370 158:274 159:670 160:337 161:414 162:370 163:191 164:581 165:449 166:478 167:560 168:976 169:130 170:918 171:149 172:6 173:1707 174:636 175:436 176:735 177:1478 178:1671 180:1384 181:175 182:1113 183:302 184:638 185:90 186:2056 187:1410 188:1773 189:1593 190:5950 192:6050 193:5417 194:4260 195:3591 196:1233 197:270 198:3951 199:5115 200:5955 201:1926 202:8810 203:8714 204:4441 205:2547 206:2774 207:2814 208:4078 209:3590 210:2875 211:1520 212:2132 213:1864 214:868 215:75 216:5199 217:1600 218:583 219:311 220:1258 221:529 222:337 223:414 End of report From jmaimon at ttec.com Fri Nov 23 19:14:44 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 23 Nov 2012 14:14:44 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50ACF2FA.2050409@gmail.com> References: <50AB49EA.3030101@cis.vutbr.cz> <006201cdc72e$dce4af10$96ae0d30$@tndh.net> <50ACE7D9.8070106@ttec.com> <50ACF2FA.2050409@gmail.com> Message-ID: <50AFCB24.8030500@ttec.com> Arturo Servin wrote: > > It won't. > > Users do not care about IPv6 or IPv4. They want a fast and reliable > Internet connection. > Which likely decreases the network effect. Joe From owen at delong.com Fri Nov 23 21:06:02 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Nov 2012 13:06:02 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50AFCB24.8030500@ttec.com> References: <50AB49EA.3030101@cis.vutbr.cz> <006201cdc72e$dce4af10$96ae0d30$@tndh.net> <50ACE7D9.8070106@ttec.com> <50ACF2FA.2050409@gmail.com> <50AFCB24.8030500@ttec.com> Message-ID: <344D1042-4175-46A7-9E92-9ABAEB4C70A3@delong.com> On Nov 23, 2012, at 11:14 , Joe Maimon wrote: > > > Arturo Servin wrote: >> >> It won't. >> >> Users do not care about IPv6 or IPv4. They want a fast and reliable >> Internet connection. >> > > Which likely decreases the network effect. > > Joe I disagree. Because IPv4 will become connected to a progressively smaller fraction of the internet, eventually, users will come to care if we have not provided it for them. However, shame on any of us who allow it to reach that point. Owen From cidr-report at potaroo.net Fri Nov 23 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Nov 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201211232200.qANM00Fc077373@wattle.apnic.net> This report has been generated at Fri Nov 23 21:13:08 2012 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 16-11-12 434519 251393 17-11-12 434672 251137 18-11-12 434789 251260 19-11-12 434867 251325 20-11-12 434999 251649 21-11-12 435259 251782 22-11-12 435428 252036 23-11-12 435758 251501 AS Summary 42778 Number of ASes in routing system 17783 Number of ASes announcing only one prefix 3201 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 114148320 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 23Nov12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 435646 251860 183786 42.2% All ASes AS6389 3151 155 2996 95.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2168 67 2101 96.9% NET Servicos de Comunicao S.A. AS4766 2949 918 2031 68.9% KIXS-AS-KR Korea Telecom AS17974 2431 539 1892 77.8% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3201 1435 1766 55.2% WINDSTREAM - Windstream Communications Inc AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS22773 1945 292 1653 85.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2260 645 1615 71.5% Telmex Colombia S.A. AS7303 1668 396 1272 76.3% Telecom Argentina S.A. AS4323 1592 399 1193 74.9% TWTC - tw telecom holdings, inc. AS4755 1622 536 1086 67.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1140 201 939 82.4% VIETEL-AS-AP Vietel Corporation AS8151 1608 697 911 56.7% Uninet S.A. de C.V. AS18101 1017 173 844 83.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS1785 1931 1155 776 40.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1126 351 775 68.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 861 118 743 86.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 705 52 653 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1117 499 618 55.3% LEVEL3 Level 3 Communications AS17676 704 88 616 87.5% GIGAINFRA Softbank BB Corp. AS3549 1050 442 608 57.9% GBLX Global Crossing Ltd. AS22561 1040 432 608 58.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1004 405 599 59.7% VZGNI-TRANSIT - Verizon Online LLC AS36998 772 178 594 76.9% SDN-MOBITEL AS24560 1040 451 589 56.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22047 579 30 549 94.8% VTR BANDA ANCHA S.A. AS4780 843 298 545 64.7% SEEDNET Digital United Inc. AS18881 594 49 545 91.8% Global Village Telecom AS7011 1222 692 530 43.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4804 643 126 517 80.4% MPX-AS Microplex PTY LTD Total 44067 12242 31825 72.2% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.31.84.0/22 AS7642 DHIRAAGU-MV-AP Dhiraagu Internet Services 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 Nov 23 22:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Nov 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201211232200.qANM02IZ077386@wattle.apnic.net> BGP Update Report Interval: 15-Nov-12 -to- 22-Nov-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3909 40118 2.4% 13372.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - AS9829 32636 1.9% 40.1 -- BSNL-NIB National Internet Backbone 3 - AS8402 31212 1.8% 36.0 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS22561 22564 1.3% 410.3 -- DIGITAL-TELEPORT - Digital Teleport Inc. 5 - AS27738 16858 1.0% 30.0 -- Ecuadortelecom S.A. 6 - AS28263 15539 0.9% 1035.9 -- 7 - AS6503 15362 0.9% 11.9 -- Axtel, S.A.B. de C.V. 8 - AS13118 13302 0.8% 266.0 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS36998 12665 0.7% 20.4 -- SDN-MOBITEL 10 - AS2708 12152 0.7% 88.7 -- Universidad de Guanajuato 11 - AS7029 11280 0.7% 8.3 -- WINDSTREAM - Windstream Communications Inc 12 - AS37113 10853 0.6% 235.9 -- tangerine-ug-as 13 - AS28885 10058 0.6% 74.0 -- OMANTEL-NAP-AS OmanTel NAP 14 - AS4198 9733 0.6% 811.1 -- RADIXNET - RadixNet, Inc. 15 - AS34400 9162 0.5% 35.8 -- ASN-ETTIHADETISALAT Ettihad Etisalat 16 - AS17762 8838 0.5% 441.9 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 17 - AS29049 8759 0.5% 26.5 -- DELTA-TELECOM-AS Delta Telecom LTD. 18 - AS6629 8742 0.5% 4371.0 -- NOAA-AS - NOAA 19 - AS50710 8727 0.5% 34.9 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 20 - AS1637 8639 0.5% 97.1 -- DNIC-AS-01637 - Headquarters, USAISC TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3909 40118 2.4% 13372.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - AS43695 8595 0.5% 8595.0 -- LISNER_AS UNIQ LISNER Sp. z o.o. 3 - AS21599 8163 0.5% 8163.0 -- NETDIRECT S.A. 4 - AS6629 8742 0.5% 4371.0 -- NOAA-AS - NOAA 5 - AS19406 4154 0.2% 4154.0 -- TWRS-MA - Towerstream I, Inc. 6 - AS40946 3303 0.2% 3303.0 -- PROCON - Sat Track 7 - AS37023 5098 0.3% 2549.0 -- OCEANICBNK 8 - AS14680 6899 0.4% 2299.7 -- REALE-6 - Auction.com 9 - AS24057 2179 0.1% 2179.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 10 - AS37426 1845 0.1% 1845.0 -- Amcon 11 - AS57918 1339 0.1% 1339.0 -- ACOD-AS ACOD CJSC 12 - AS36529 2380 0.1% 1190.0 -- AXXA-RACKCO - Rackco.com 13 - AS28263 15539 0.9% 1035.9 -- 14 - AS6197 957 0.1% 957.0 -- BATI-ATL - BellSouth Network Solutions, Inc 15 - AS38278 1671 0.1% 835.5 -- VTELECOMNET-MY-AP VTelecoms Berhad - Metro Ethernet LL and Internet Service Provider, Malaysia 16 - AS4198 9733 0.6% 811.1 -- RADIXNET - RadixNet, Inc. 17 - AS32244 3774 0.2% 754.8 -- LIQUID-WEB-INC - Liquid Web, Inc. 18 - AS50478 1397 0.1% 698.5 -- BVOX BVOX AS 19 - AS52875 654 0.0% 654.0 -- 20 - AS28306 7724 0.5% 643.7 -- TC Net Inform?tica e Telecomunica??es LTDA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.18.0/24 13384 0.7% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.255.0/24 13367 0.7% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.254.0/24 13367 0.7% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 184.159.130.0/23 11238 0.6% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 5 - 184.157.224.0/19 10938 0.6% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 6 - 91.198.110.0/24 8595 0.5% AS43695 -- LISNER_AS UNIQ LISNER Sp. z o.o. 7 - 200.46.0.0/19 8163 0.5% AS21599 -- NETDIRECT S.A. 8 - 139.139.19.0/24 5889 0.3% AS1562 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 9 - 109.161.64.0/19 5648 0.3% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 10 - 12.139.133.0/24 5628 0.3% AS14680 -- REALE-6 - Auction.com 11 - 175.41.0.0/20 5026 0.3% AS36408 -- ASN-PANTHER Panther Express 12 - 194.63.9.0/24 4784 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 123.252.208.0/24 4586 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 14 - 192.58.232.0/24 4429 0.2% AS6629 -- NOAA-AS - NOAA 15 - 192.58.2.0/24 4313 0.2% AS6629 -- NOAA-AS - NOAA 16 - 49.248.72.0/21 4231 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 17 - 69.38.178.0/24 4154 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 18 - 208.92.131.0/24 3303 0.2% AS40946 -- PROCON - Sat Track 19 - 187.17.168.0/22 3166 0.2% AS28263 -- 20 - 187.17.164.0/22 3166 0.2% AS28263 -- 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 mbarr at snap-interactive.com Thu Nov 22 02:13:56 2012 From: mbarr at snap-interactive.com (Matthew Barr) Date: Wed, 21 Nov 2012 21:13:56 -0500 Subject: Recovering from spam resulting from compromised account In-Reply-To: References: Message-ID: On Nov 21, 2012, at 8:53 PM, Dave Sotnick wrote: > Also had reports that we're still seeing bounces to Gmail, Comcast and > Yahoo accounts. The best thing to do is to go ahead and look at the bounce messages from the various ISP's, and see if they have any instructions or URL's to contact. If you don't have any of those messages at hand, you can see the bounce codes in the logs of your mailserver. If you don't have any useful messages in the bounce code, then you can probably look at the site for each ISP, and google their postmaster group. Matthew Matthew Barr Technical Architect Snap Interactive mbarr at mbarr.net From ammar.salih at auis.edu.iq Thu Nov 22 11:59:59 2012 From: ammar.salih at auis.edu.iq (Ammar Salih) Date: Thu, 22 Nov 2012 14:59:59 +0300 Subject: Adding GPS location to IPv6 header Message-ID: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF website, your ideas and comments are most welcome! http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t ext=1 Thanks! Ammar Salih From jna at retina.net Sat Nov 24 21:18:08 2012 From: jna at retina.net (John Adams) Date: Sat, 24 Nov 2012 13:18:08 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> References: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> Message-ID: Don't conflate layer 5-7 needs with basic communication requirements. IP is not the place for this sort of header. This is not data that should be sent on every packet. It becomes redundant. Not to mention the serious privacy concerns such a header brings up in the protocol. You barely address this in your RFC. You write it away with a wishy-washy "Oh err um, users will have the option to turn it off". That's worked so well for opt-out advertising -- I'm sure it will work here. If there's a place where I can go and vote this down / debate it away, tell me where that is. -j On Thu, Nov 22, 2012 at 3:59 AM, Ammar Salih wrote: > Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF > website, your ideas and comments are most welcome! > > > > > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t > ext=1 > > > > Thanks! > > Ammar Salih > > > > > > From md1clv at md1clv.com Sat Nov 24 21:46:48 2012 From: md1clv at md1clv.com (Daniel Ankers) Date: Sat, 24 Nov 2012 21:46:48 +0000 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> Message-ID: It seems to me that there's a big problem with using this for rights enforcement. If the header is added by the user's device, then on certain operating systems it will be trivial for the user to set this to whatever they want it to be - which would defeat the purpose. If the header is added by devices out of the user's control so that the user cannot spoof their location (e.g. ISP routers) then for one thing they do not know the user's exact location, and for another there needs to be an additional mechanism for the user to switch the option off. The suggestion of using this to automatically get web pages in the right language also does not seem practical. My devices know that my preferred language is English. If I take one of those devices to China, I still want to see web pages in English. Additionally there is already an HTTP header to express your preferred language. Regards, Dan On 24 November 2012 21:18, John Adams wrote: > Don't conflate layer 5-7 needs with basic communication requirements. IP is > not the place for this sort of header. > > This is not data that should be sent on every packet. It becomes redundant. > Not to mention the serious privacy concerns such a header brings up in the > protocol. You barely address this in your RFC. You write it away with a > wishy-washy "Oh err um, users will have the option to turn it off". That's > worked so well for opt-out advertising -- I'm sure it will work here. > > If there's a place where I can go and vote this down / debate it away, tell > me where that is. > > -j > > On Thu, Nov 22, 2012 at 3:59 AM, Ammar Salih >wrote: > > > Dears, I've proposed a new IPv6 "extension header", it's now posted on > IETF > > website, your ideas and comments are most welcome! > > > > > > > > > > > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t > > ext=1 > > > > > > > > Thanks! > > > > Ammar Salih > > > > > > > > > > > > > From cabo at tzi.org Sat Nov 24 21:53:18 2012 From: cabo at tzi.org (Carsten Bormann) Date: Sat, 24 Nov 2012 22:53:18 +0100 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> Message-ID: <2E60FE51-4267-4C33-96E4-C690B63ABBB2@tzi.org> On Nov 24, 2012, at 22:18, John Adams wrote: > If there's a place where I can go and vote this down / debate it away, tell > me where that is. Not needed. It already has been completely shredded at the relevant IETF mailing lists, geopriv and ipv6 (6man WG). I have no idea why Ammar isn't listening to the great free advice he got there. Gr??e, Carsten From tammy-lists at wiztech.biz Sun Nov 25 01:46:11 2012 From: tammy-lists at wiztech.biz (Tammy A. Wisdom) Date: Sat, 24 Nov 2012 18:46:11 -0700 (MST) Subject: Adding GPS location to IPv6 header In-Reply-To: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> References: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> Message-ID: <962220598.8634.1353807971714.JavaMail.root@wiztech.biz> Im just going to come out and say this. This is a gigantic invasion of privacy and a really bad idea. ----- Original Message ----- > From: "Ammar Salih" > To: nanog at nanog.org > Sent: Thursday, November 22, 2012 4:59:59 AM > Subject: Adding GPS location to IPv6 header > > Dears, I've proposed a new IPv6 "extension header", it's now posted > on IETF > website, your ideas and comments are most welcome! > > > > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t > ext=1 > > > > Thanks! > > Ammar Salih > > > > > > From mysidia at gmail.com Sun Nov 25 01:57:30 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 24 Nov 2012 19:57:30 -0600 Subject: Recovering from spam resulting from compromised account In-Reply-To: References: Message-ID: On 11/21/12, Suresh Ramasubramanian wrote: > Wait it out as in - you had better examine your mail queues and purge them > of any of the spam that was sent and is still queued up. > > It'll still take a day or two after that's done for the blocks to subside. The majority of blocking should in most cases, eventually clear up after spamming stops, and you can work out delisting with the common RBLs, using URLs in the bounce response; the general rule is 72 hours, after there is a complete stoppage of bad traffic, and you completed these steps: you wipe all bad messages from queues, make certain spam has completely stopped, ensure dilligent 24 hour monitoring, and then proper delisting is requested from any common blocklists that a lookup was available on. It may be impossible for you to clean out some blocklist entries, or you may have a limited number of "reset requests" available, that take effect after 24+ hours, E.g. CSI. For some blocklists, entries autoexpire after 7 days or longer and don't take manual requests, or some blocklists require a fee for delisting requests, and blocklist entries might otherwise be permanent. You can inspect bounces and raise the issues with blocking providers on a case-by-case basis; it is unlikely you reach someone at Google or Yahoo who will manually intervene. You can also lookup various Hosted spam filtering services, there are some large trusted providers, that will provide an outgoing spam filtering option, by using their servers as a smarthost, you offload mail deliverability issues to your service provider; in exchange, inbound/outbound spam filtering services typically charge something such as $12/mailbox. Changing your outgoing IP address of SMTP mail to your service providers, or rerouting mail towards servers blocking you, through a different local mail relay, may provide a temporary quick fix that is faster than waiting a few days until "spam extermination", on your current mail server is fully acknowledged. > On Thu, Nov 22, 2012 at 7:59 AM, Dave Sotnick > wrote: >> Thanks Matthew. Sadly, most of the bounce responses have URLs that >> point you to a help page that doesn't have further contact information >> or just tells you to wait it out. -- -JH From imb at protected-networks.net Sun Nov 25 02:02:13 2012 From: imb at protected-networks.net (Michael Butler) Date: Sat, 24 Nov 2012 21:02:13 -0500 Subject: Adding GPS location to IPv6 header In-Reply-To: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> References: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> Message-ID: <50B17C25.609@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/22/12 06:59, Ammar Salih wrote: > Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF > website, your ideas and comments are most welcome! In a number of jurisdictions and particularly in the EU, IP addresses themselves (any version) are considered Personally Identifiable Information (PII) and are expected/required to be protected as such. This implies that Firewall and Intrusion Detection logs must not be conveyed across country borders, e.g. from Germany. Any attempt to introduce another flavour of PII into a transport mechanism (as distinct from an intended payload) is likely only to meet significant (and warranted) resistance at every level, carrier and legislative overseer alike, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlCxfCUACgkQQv9rrgRC1JKCYQCgkAHwtPImDXkj+mrKSQsn+GwR GG4An1Es8+3Nd7oSUYxUSIvjD71LpvLG =wQBu -----END PGP SIGNATURE----- From joelja at bogus.com Sun Nov 25 03:09:41 2012 From: joelja at bogus.com (joel jaeggli) Date: Sat, 24 Nov 2012 19:09:41 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121120163214.794af87b@tux.DEF.witbe.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> Message-ID: <50B18BF5.1090203@bogus.com> On 11/20/12 7:32 AM, Paul Rolland (???????) wrote: > Hello, > > On Tue, 20 Nov 2012 10:14:18 +0100 > Tomas Podermanski wrote: > >> It seems that today is a "big day" for IPv6. It is the very first >> time when native IPv6 on google statistics >> (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some >> might say it is tremendous success after 16 years of deploying IPv6 :-) > Funny enough, the peaks are indicating... week-ends ! > Do people use more google during the WE, or do they have more IPv6 @ home ? from goeff huston's data they have more v6 at home. > Paul From kenneth.mcrae at dreamhost.com Sun Nov 25 04:04:00 2012 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Sat, 24 Nov 2012 20:04:00 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> References: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> Message-ID: I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us? I don't particularly care for "smart" ads and three like.. On Nov 24, 2012 9:37 AM, "Ammar Salih" wrote: > Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF > website, your ideas and comments are most welcome! > > > > > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t > ext=1 > > > > Thanks! > > Ammar Salih > > > > > > From rdobbins at arbor.net Sun Nov 25 04:29:15 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 25 Nov 2012 04:29:15 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B18BF5.1090203@bogus.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> Message-ID: <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> On Nov 25, 2012, at 10:09 AM, joel jaeggli wrote: > from goeff huston's data they have more v6 at home. And not purposely, either - because it's enabled by default on recent client OSes. My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From joelja at bogus.com Sun Nov 25 04:33:47 2012 From: joelja at bogus.com (joel jaeggli) Date: Sat, 24 Nov 2012 20:33:47 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> Message-ID: <50B19FAB.9090807@bogus.com> On 11/24/12 8:29 PM, Dobbins, Roland wrote: > On Nov 25, 2012, at 10:09 AM, joel jaeggli wrote: > >> from goeff huston's data they have more v6 at home. > And not purposely, either - because it's enabled by default on recent client OSes. My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional. In their defense, they don't know they have ipv4 connectivity either. > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > From mysidia at gmail.com Sun Nov 25 06:28:54 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 25 Nov 2012 00:28:54 -0600 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> Message-ID: On 11/24/12, John Adams wrote: > Don't conflate layer 5-7 needs with basic communication requirements. IP is > not the place for this sort of header. IP is the logical place for this kind of header, as this information is node dependent, not application dependent. It would be useful for identifying the location of a server, when an IP address does not. For example, in the case of an anycasted service, the source IP address does not uniquely identify where the source came from. The requirement that the embedded location data, be GPS data, however: would seem to be overly restrictive; a simple 8-bit "Site number" identifier could be all the location data needed for diagnostic purposes. "Privacy issues" are policy considerations, that have no place in the determination of protocol header formats; providers of a service will generate location header extensions, if they are useful to them, if they are not, then they would choose to not support the extension. If a provider wants to attempt to implement rights management using header fields, then more power to them.... I never heard of a digital rights management provider implementing an open standards-based approach, and it would be a positive development if they did, but more likely than not, they will ignore header extension options, and implement rights management identification inside proprietary application layer payloads that contain the actual protected content, instead of IP packet headers, which are easily stripped off, and replaced with new IP headers containing the same packet data payload. -- -JH From regnauld at nsrc.org Sun Nov 25 10:48:56 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Sun, 25 Nov 2012 11:48:56 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B19FAB.9090807@bogus.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <50B19FAB.9090807@bogus.com> Message-ID: <20121125104856.GA50342@macbook.bluepipe.net> joel jaeggli (joelja) writes: > On 11/24/12 8:29 PM, Dobbins, Roland wrote: > >On Nov 25, 2012, at 10:09 AM, joel jaeggli wrote: > > > >>from goeff huston's data they have more v6 at home. > >And not purposely, either - because it's enabled by default on recent client OSes. My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional. > In their defense, they don't know they have ipv4 connectivity either. They don't know it's not real IPv4 either :) But yeah, if Joe Random enables 6to4 on his Airport Express without understanding what it means, it still translates to more IPv6 traffic during evenings and weekend from residential connections. It's be interesting to come up with a metric to compare "inadvertently" vs "on purpose" v6 traffic. Free.fr, for instance, enables v6 by default on their 6th gen freebox (set top box). Is that inadvertent ? For whom ? Phil From ammar.salih at auis.edu.iq Sun Nov 25 12:30:58 2012 From: ammar.salih at auis.edu.iq (Ammar Salih) Date: Sun, 25 Nov 2012 15:30:58 +0300 Subject: Adding GPS location to IPv6 header Message-ID: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any. > This is not data that should be sent on every packet. It becomes redundant. 1- It does not have to be in every IPv6 header, only when there is location update. 2- the host should have the option of not sending location updates. 3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to. ---------------------------------------------------- > A good alternative would be to create application layer protocols that could request and send GPS positions. 1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language. 2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible. 3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others .. that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications. [1] https://datatracker.ietf.org/wg/geopriv/charter/ [2] http://tools.ietf.org/html/rfc6442 [3] http://dev.w3.org/geo/api/spec-source.html ---------------------------------------------------------------------------- ------ > I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us? 1- The host should have the option of not sending location updates. 2- It's extension header, means it's up to the service provider to use the feature or not. 3- Users are being routed through ISPs, if we don't trust the ISP then I can assure you that ISP can get much more information than physical location, any un-encrypted traffic -which is the majority- can be analyzed at the ISP level (up to layer-7). Anythink you write on facebook for example *if you don't use https* can be detected, including location tags, relationships, activities, wall posts, friends ... and much more, all your http traffic, including documents you read, messages, usernames, passwords, bank accounts ...etc. Other than ISP, sniffers can be connected to the same layer-2/layer-3 device as mine, in this case I would worry about usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not location as the sniffer in this case is mostly sitting at the same physical location as mine. 4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates. ------------------------------------------- Thank you everyone for your time and professional feedback, I highly appreciate it! Please be informed that this is only a draft, and I am requesting comments, I also apologize for those who felt uncomfortable about the draft *they should not* as the whole feature is optional - in case its implemented. Thanks, Ammar From: Ammar Salih [mailto:ammar.salih at auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog at nanog.org' Subject: Adding GPS location to IPv6 header Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF website, your ideas and comments are most welcome! http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t ext=1 Thanks! Ammar Salih From mansaxel at besserwisser.org Sun Nov 25 12:42:31 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 25 Nov 2012 13:42:31 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> Message-ID: <20121125124231.GR17355@besserwisser.org> Subject: Re: Big day for IPv6 - 1% native penetration Date: Sun, Nov 25, 2012 at 04:29:15AM +0000 Quoting Dobbins, Roland (rdobbins at arbor.net): > > On Nov 25, 2012, at 10:09 AM, joel jaeggli wrote: > > > from goeff huston's data they have more v6 at home. > > And not purposely, either - because it's enabled by default on recent client OSes. My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional. This is excellent! It is not likely that any end-user traffic over IPv4 is intentionally sent over IPv4. It is sent to Facebook. (eh, faceb00c, of course) Likewise, the -4 and -6 options for SSH are there for debugging and fault mitigation, nothing else. I'm quite satisfied that this now is the norm. It's the only way we'll be able to restore e2e on the Internet and evolve beyond simple client-server models like TN3270^H^H^H^Hthe web. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I didn't order any WOO-WOO ... Maybe a YUBBA ... But no WOO-WOO! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nick at foobar.org Sun Nov 25 13:56:10 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 25 Nov 2012 13:56:10 +0000 Subject: Adding GPS location to IPv6 header In-Reply-To: <50B17C25.609@protected-networks.net> References: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> <50B17C25.609@protected-networks.net> Message-ID: <50B2237A.3070402@foobar.org> On 25/11/2012 02:02, Michael Butler wrote: > In a number of jurisdictions and particularly in the EU, IP addresses > themselves (any version) are considered Personally Identifiable > Information (PII) and are expected/required to be protected as such. actually no. The EU Article 29 Data Protection Working Party issued a controversial opinion a couple of years ago that IP address data in combination with an accurate timestamp constituted PII, but that IP addresses on their own did not. This opinion has been roundly rejected by several EU courts; for example see paragraph 12 of emi vs eircom in the irish high court (http://goo.gl/96xUY). Nick From dave at temk.in Sun Nov 25 15:10:41 2012 From: dave at temk.in (David Temkin) Date: Sun, 25 Nov 2012 10:10:41 -0500 Subject: Call for Presentations: NANOG 57 in Orlando, FL In-Reply-To: References: Message-ID: Just a friendly reminder that the RFP for NANOG 57 is approaching in just over two weeks. Best Regards, -Dave Temkin On Nov 8, 2012, at 11:48 AM, David Temkin wrote: > NANOG Community, > > I know that we all just left Dallas after NANOG 56, but the NANOG Program Committee is already hard at work preparing for NANOG 57 in Orlando! > > The North American Network Operators' Group (NANOG) will hold their 57th meeting in Orlando, FL on February 4th through the 6th. Of special note, this is the first meeting that will have a fully Monday through Wednesday agenda. Our host, CyrusOne is eagerly awaiting welcoming you to the Renaissance Orlando at SeaWorld. > > The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 57 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. NANOG 57 submissions are welcome at http://pc.nanog.org > > For further information on what the Program Committee is seeking, please see http://www.nanog.org/meetings/nanog57/callforpresentations.html > > This will also be our first meeting after the 2012 WCIT in early December, and we expect topical and timely presentations regarding the results > > When considering submitting a presentation, keep these important dates in mind: > > Presentation Abstracts and Draft Slides Due: 10-December-2012 > Final Slides Due: 7-January-2013 > Draft Program Published: 14-January-2013 > Final Agenda Published: 18-January-2013 > > Please submit your materials to http://pc.nanog.org > > Looking forward to seeing everyone in Orlando! > > -Dave Temkin From bill at herrin.us Sun Nov 25 17:08:15 2012 From: bill at herrin.us (William Herrin) Date: Sun, 25 Nov 2012 12:08:15 -0500 Subject: Adding GPS location to IPv6 header In-Reply-To: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Message-ID: On Sun, Nov 25, 2012 at 7:30 AM, Ammar Salih wrote: > 2- Layer 7 will not be detected by layer 3 devices (routers) .. so > location-based service on layer-3 will not be possible. Geographic-based layer 3 routing has been thoroughly discussed on the IRTF RRG and just as thoroughly rejected. It's wholly inadequate as an approximation for topographic locality within the network graph. Uses of geolocation information at layer 3 are similar to uses of the "evil bit." On Sun, Nov 25, 2012 at 1:28 AM, Jimmy Hess wrote: > On 11/24/12, John Adams wrote: >> Don't conflate layer 5-7 needs with basic communication requirements. IP is >> not the place for this sort of header. > > IP is the logical place for this kind of header, as this information > is node dependent, not application dependent. As is the user's legal name and social security number. If it isn't processed by the layer 3 protocols, if they don't use it for next hop selection, then it doesn't belong at layer 3. > For example, in the case of an anycasted service, the source IP > address does not uniquely identify where the source came from. Given appropriate construction of the layer 4 protocol, nothing stops an anycasted service from responding with a unicast IP address and using the unicast address during subsequent communication. An anycast service has far better mechanisms available to identify the responding server than stuffing a GPS header in the layer 3 packet. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From eugen at leitl.org Sun Nov 25 17:13:23 2012 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 25 Nov 2012 18:13:23 +0100 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Message-ID: <20121125171323.GZ9750@leitl.org> On Sun, Nov 25, 2012 at 12:08:15PM -0500, William Herrin wrote: > On Sun, Nov 25, 2012 at 7:30 AM, Ammar Salih wrote: > > 2- Layer 7 will not be detected by layer 3 devices (routers) .. so > > location-based service on layer-3 will not be possible. > > Geographic-based layer 3 routing has been thoroughly discussed on the > IRTF RRG and just as thoroughly rejected. It's wholly inadequate as an > approximation for topographic locality within the network graph. If relativistic latency component is measurable, that is information useful for mutual time of flight triangulation. WGS84 just gives you a convenient hinge to hang your information on. > Uses of geolocation information at layer 3 are similar to uses of the > "evil bit." You're correct. It's for layer 2 strictly. From jna at retina.net Sun Nov 25 22:19:48 2012 From: jna at retina.net (John Adams) Date: Sun, 25 Nov 2012 14:19:48 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Message-ID: Your proposal doesn't even give people a way to encrypt their location data; By moving geodata to a portion of the protocol which is not covered by commonly used encryption methods (i.e. HTTPS, which is up a few layers in the stack) people can't be protected should this data be monitored by a malicious intermediary. Think: Syria, China, Iran, or any other government which will kill you for your words online. Application protocols sending GPS data under say, HTTPS protect the end user from revealing their location to anyone on their path, forcing an intermediary to look up the IP in a common geo database which will be mostly inaccurate in pinpointing users, and hopefully will save lives. Companies like Twitter, Facebook, and some parts of google are going HTTPS by default for this very reason. This proposal is dead, you don't have the sense to lie down. From network.ipdog at gmail.com Sun Nov 25 23:16:39 2012 From: network.ipdog at gmail.com (Network IPdog) Date: Sun, 25 Nov 2012 15:16:39 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Message-ID: <50b2a6d2.2750420a.492e.0e6a@mx.google.com> Et al, There is one simple question that needs to be asked! Ammar Salih @ ammar.salih at auis.edu.iq Are you a terrorist? Ephesians 4:32 & Cheers!!! A password is like a... toothbrush ;^) Choose a good one, change it regularly and don't share it. -----Original Message----- From: John Adams [mailto:jna at retina.net] Sent: Sunday, November 25, 2012 2:20 PM To: Ammar Salih Cc: nanog at nanog.org list Subject: Re: Adding GPS location to IPv6 header Your proposal doesn't even give people a way to encrypt their location data; By moving geodata to a portion of the protocol which is not covered by commonly used encryption methods (i.e. HTTPS, which is up a few layers in the stack) people can't be protected should this data be monitored by a malicious intermediary. Think: Syria, China, Iran, or any other government which will kill you for your words online. Application protocols sending GPS data under say, HTTPS protect the end user from revealing their location to anyone on their path, forcing an intermediary to look up the IP in a common geo database which will be mostly inaccurate in pinpointing users, and hopefully will save lives. Companies like Twitter, Facebook, and some parts of google are going HTTPS by default for this very reason. This proposal is dead, you don't have the sense to lie down. From randy_94108 at yahoo.com Sun Nov 25 23:52:28 2012 From: randy_94108 at yahoo.com (Randy) Date: Sun, 25 Nov 2012 15:52:28 -0800 (PST) Subject: Adding GPS location to IPv6 header In-Reply-To: <50b2a6d2.2750420a.492e.0e6a@mx.google.com> Message-ID: <1353887548.86582.YahooMailClassic@web184704.mail.ne1.yahoo.com> WHAT??? Is this the extent to which This-List has DEGENERATED??? How dare you make such a horrendous accusation Sir? You may NOT like what OP has proposed. I don't either for more reasons than one! However, YOU are neither qualified NOR authorised to ask such an appallingly INSENSITIVE Question! Your so called "Freedom-of-Speech" DOES NOT translate to Character-Assasination on this or any other forum!! Follow me you ipdog? Find you own bitch to abuse. Don't do it here!! ./Randy --- On Sun, 11/25/12, Network IPdog wrote: > From: Network IPdog > Subject: RE: Adding GPS location to IPv6 header > To: "'John Adams'" , "'Ammar Salih'" > Cc: nanog at nanog.org > Date: Sunday, November 25, 2012, 3:16 PM > Et al, > > There is one simple question that needs to be asked! > > > Ammar Salih @ ammar.salih at auis.edu.iq > Are you a terrorist? > > > > Ephesians 4:32? &? Cheers!!! > > A password is like a... toothbrush? ;^) > Choose a good one, change it regularly and don't share it. > > > > -----Original Message----- > From: John Adams [mailto:jna at retina.net] > Sent: Sunday, November 25, 2012 2:20 PM > To: Ammar Salih > Cc: nanog at nanog.org > list > Subject: Re: Adding GPS location to IPv6 header > > Your proposal doesn't even give people a way to encrypt > their location data; > By moving geodata to a portion of the protocol which is not > covered by > commonly used encryption methods (i.e. HTTPS, which is up a > few layers in > the stack) people can't be protected should this data be > monitored by a > malicious intermediary. Think: Syria, China, Iran, or any > other government > which will kill you for your words online. > > Application protocols sending GPS data under say, HTTPS > protect the end user > from revealing their location to anyone on their path, > forcing an > intermediary to look up the IP in a common geo database > which will be mostly > inaccurate in pinpointing users, and hopefully will save > lives. > > Companies like Twitter, Facebook, and some parts of google > are going HTTPS > by default for this very reason. > > This proposal is dead, you don't have the sense to lie > down. > > > From mysidia at gmail.com Mon Nov 26 00:14:49 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 25 Nov 2012 18:14:49 -0600 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Message-ID: On 11/25/12, William Herrin wrote: > On Sun, Nov 25, 2012 at 7:30 AM, Ammar Salih > wrote: > Geographic-based layer 3 routing has been thoroughly discussed on the > IRTF RRG and just as thoroughly rejected. It's wholly inadequate as an > approximation for topographic locality within the network graph. Nevertheless, there are some applications in which it might have some merit. If there is even one such application, then it is sensible to have the required bits set aside, so there can be an extension in the limited cases where it is required. > On Sun, Nov 25, 2012 at 1:28 AM, Jimmy Hess wrote: >> On 11/24/12, John Adams wrote: >>> Don't conflate layer 5-7 needs with basic communication requirements. IP >> IP is the logical place for this kind of header, as this information >> is node dependent, not application dependent. > > As is the user's legal name and social security number. If it isn't > processed by the layer 3 protocols, if they don't use it for next hop > selection, then it doesn't belong at layer 3. An extension header at Layer 3 containing this information should be just fine. Or rather, an extension, allowing a reference to a lookup service for that information to be placed in IP headers, for network management should be just fine. The actual underlying plaintext PII best be protected with IPsec and additional measures, but that is the network implementor's responsibility. Not all Layer 3 headers have to influence path selection. There _ARE_ headers for strictly network management purposes. Examples would include the IP TOS header; Route record extensions; Hop limit; Timestamp. The IP TOS header identifies a value, which can be used to prioritize some packets; similarly, a network operator might have a need to prioritize packets with a certain geographical origin at L3, or grant certain throughput and performance characteristics based on source region, to ensure a degree of fairness with their application. >> For example, in the case of an anycasted service, the source IP >> address does not uniquely identify where the source came from. > Given appropriate construction of the layer 4 protocol, nothing stops > an anycasted service from responding with a unicast IP address and They generally will not. The mechanism of operation of an anycasted service is there are a small number of unicast addresses, with routes announced from various different points. If each region had its own unicast IP, it would just be a normal DNS-balanced service. Therefore, the same unicast IP address may be used from multiple regions, for example, the DNS servers in different regions may have identical IP addresses. For network management purposes, on the End user side, it would be useful in some cases, for the IP header of DNS and HTTP response packets, to identify which "node" or site is responding; even if this cannot be indicated in the IP address fields. It may help identify, if an issue accessing an any casted service is related to instability of which route is preferred (E.g. thrashing of the end user's site selection); if there is an extension option available for Recording or Tagging packets with a source ID, a situation, in which the Record Route IP extension is not a viable option. > Bill Herrin -- -JH From randy_94108 at yahoo.com Mon Nov 26 04:28:32 2012 From: randy_94108 at yahoo.com (Randy) Date: Sun, 25 Nov 2012 20:28:32 -0800 (PST) Subject: Adding GPS location to IPv6 header In-Reply-To: <50b2d756.43f1440a.2774.571e@mx.google.com> Message-ID: <1353904112.94748.YahooMailClassic@web184705.mail.ne1.yahoo.com> Just because it is from Iraq; does NOT mean by any streach of the imagination that OP is a terrorist! You need to get outside the box you are living in and learn to separate the forest from the trees! You are "entitled" to you private-opinions. Don't post said-garbage on NANOG! I do take exception to such garbage; while other's might not. ./Randy --- On Sun, 11/25/12, Network IPdog wrote: > From: Network IPdog > Subject: RE: Adding GPS location to IPv6 header > To: "'Randy'" > Date: Sunday, November 25, 2012, 6:43 PM > The email address is > from????auis.edu.iq = Iraq > > Sometimes persons living inside the box cannot see the > forest because of the > trees. > > PEACE > > > Ephesians 4:32? &? Cheers!!! > > A password is like a... toothbrush? ;^) > Choose a good one, change it regularly and don't share it. > > -----Original Message----- > From: Randy [mailto:randy_94108 at yahoo.com] > > Sent: Sunday, November 25, 2012 3:52 PM > To: Network IPdog > Cc: nanog at nanog.org > Subject: RE: Adding GPS location to IPv6 header > > WHAT??? > > Is this the extent to which This-List has DEGENERATED??? > > How dare you make such a horrendous accusation Sir? > > You may NOT like what OP has proposed. I don't either for > more reasons than > one! > > However, YOU are neither qualified NOR authorised to ask > such an appallingly > INSENSITIVE Question! > > Your so called "Freedom-of-Speech" DOES NOT translate to > Character-Assasination on this or any other forum!! > > Follow me you ipdog? Find you own bitch to abuse. Don't do > it here!! > > ./Randy > > --- On Sun, 11/25/12, Network IPdog > wrote: > > > From: Network IPdog > > Subject: RE: Adding GPS location to IPv6 header > > To: "'John Adams'" , > "'Ammar Salih'" > > > > Cc: nanog at nanog.org > > Date: Sunday, November 25, 2012, 3:16 PM Et al, > > > > There is one simple question that needs to be asked! > > > > > > Ammar Salih @ ammar.salih at auis.edu.iq > > Are you a terrorist? > > > > > > > > Ephesians 4:32? &? Cheers!!! > > > > A password is like a... toothbrush? ;^) Choose a good > one, change it > > regularly and don't share it. > > > > > > > > -----Original Message----- > > From: John Adams [mailto:jna at retina.net] > > Sent: Sunday, November 25, 2012 2:20 PM > > To: Ammar Salih > > Cc: nanog at nanog.org > > list > > Subject: Re: Adding GPS location to IPv6 header > > > > Your proposal doesn't even give people a way to encrypt > their location > > data; By moving geodata to a portion of the protocol > which is not > > covered by commonly used encryption methods (i.e. > HTTPS, which is up a > > few layers in the stack) people can't be protected > should this data be > > monitored by a malicious intermediary. Think: Syria, > China, Iran, or > > any other government which will kill you for your words > online. > > > > Application protocols sending GPS data under say, HTTPS > protect the > > end user from revealing their location to anyone on > their path, > > forcing an intermediary to look up the IP in a common > geo database > > which will be mostly inaccurate in pinpointing users, > and hopefully > > will save lives. > > > > Companies like Twitter, Facebook, and some parts of > google are going > > HTTPS by default for this very reason. > > > > This proposal is dead, you don't have the sense to lie > down. > > > > > > > > From crogers at real.com Mon Nov 26 04:32:45 2012 From: crogers at real.com (Christopher Rogers) Date: Sun, 25 Nov 2012 20:32:45 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: <1353904112.94748.YahooMailClassic@web184705.mail.ne1.yahoo.com> References: <50b2d756.43f1440a.2774.571e@mx.google.com>, <1353904112.94748.YahooMailClassic@web184705.mail.ne1.yahoo.com> Message-ID: <9D38581D8D431C4BBEA4E0EDCD5D5BFA174FC45628@SEAMBX.corp.real.com> I agree, this is entirely unacceptable discourse for nanog. Maybe you should take a closer look at your Ephesians quote there, Mister 'IPdog.' -chris ________________________________________ From: Randy [randy_94108 at yahoo.com] Sent: Sunday, November 25, 2012 20:28 To: Network IPdog Cc: nanog at nanog.org Subject: RE: Adding GPS location to IPv6 header Just because it is from Iraq; does NOT mean by any streach of the imagination that OP is a terrorist! You need to get outside the box you are living in and learn to separate the forest from the trees! You are "entitled" to you private-opinions. Don't post said-garbage on NANOG! I do take exception to such garbage; while other's might not. ./Randy --- On Sun, 11/25/12, Network IPdog wrote: > From: Network IPdog > Subject: RE: Adding GPS location to IPv6 header > To: "'Randy'" > Date: Sunday, November 25, 2012, 6:43 PM > The email address is > from? auis.edu.iq = Iraq > > Sometimes persons living inside the box cannot see the > forest because of the > trees. > > PEACE > > > Ephesians 4:32 &? Cheers!!! > > A password is like a... toothbrush ;^) > Choose a good one, change it regularly and don't share it. > > -----Original Message----- > From: Randy [mailto:randy_94108 at yahoo.com] > > Sent: Sunday, November 25, 2012 3:52 PM > To: Network IPdog > Cc: nanog at nanog.org > Subject: RE: Adding GPS location to IPv6 header > > WHAT??? > > Is this the extent to which This-List has DEGENERATED??? > > How dare you make such a horrendous accusation Sir? > > You may NOT like what OP has proposed. I don't either for > more reasons than > one! > > However, YOU are neither qualified NOR authorised to ask > such an appallingly > INSENSITIVE Question! > > Your so called "Freedom-of-Speech" DOES NOT translate to > Character-Assasination on this or any other forum!! > > Follow me you ipdog? Find you own bitch to abuse. Don't do > it here!! > > ./Randy > > --- On Sun, 11/25/12, Network IPdog > wrote: > > > From: Network IPdog > > Subject: RE: Adding GPS location to IPv6 header > > To: "'John Adams'" , > "'Ammar Salih'" > > > > Cc: nanog at nanog.org > > Date: Sunday, November 25, 2012, 3:16 PM Et al, > > > > There is one simple question that needs to be asked! > > > > > > Ammar Salih @ ammar.salih at auis.edu.iq > > Are you a terrorist? > > > > > > > > Ephesians 4:32 &? Cheers!!! > > > > A password is like a... toothbrush ;^) Choose a good > one, change it > > regularly and don't share it. > > > > > > > > -----Original Message----- > > From: John Adams [mailto:jna at retina.net] > > Sent: Sunday, November 25, 2012 2:20 PM > > To: Ammar Salih > > Cc: nanog at nanog.org > > list > > Subject: Re: Adding GPS location to IPv6 header > > > > Your proposal doesn't even give people a way to encrypt > their location > > data; By moving geodata to a portion of the protocol > which is not > > covered by commonly used encryption methods (i.e. > HTTPS, which is up a > > few layers in the stack) people can't be protected > should this data be > > monitored by a malicious intermediary. Think: Syria, > China, Iran, or > > any other government which will kill you for your words > online. > > > > Application protocols sending GPS data under say, HTTPS > protect the > > end user from revealing their location to anyone on > their path, > > forcing an intermediary to look up the IP in a common > geo database > > which will be mostly inaccurate in pinpointing users, > and hopefully > > will save lives. > > > > Companies like Twitter, Facebook, and some parts of > google are going > > HTTPS by default for this very reason. > > > > This proposal is dead, you don't have the sense to lie > down. > > > > > > > > From drc at virtualized.org Mon Nov 26 05:00:40 2012 From: drc at virtualized.org (David Conrad) Date: Sun, 25 Nov 2012 21:00:40 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: <1353904112.94748.YahooMailClassic@web184705.mail.ne1.yahoo.com> References: <1353904112.94748.YahooMailClassic@web184705.mail.ne1.yahoo.com> Message-ID: <2A6C96F1-4D0E-42B0-8597-5BF63D128056@virtualized.org> Please don't feed the bigoted hypocritical trolls. Regards, -drc On Nov 25, 2012, at 8:28 PM, Randy wrote: > Just because it is from Iraq; does NOT mean by any streach of the imagination that OP is a terrorist! > You need to get outside the box you are living in and learn to separate the forest from the trees! > > You are "entitled" to you private-opinions. Don't post said-garbage on NANOG! > > I do take exception to such garbage; while other's might not. > > ./Randy > > --- On Sun, 11/25/12, Network IPdog wrote: > >> From: Network IPdog >> Subject: RE: Adding GPS location to IPv6 header >> To: "'Randy'" >> Date: Sunday, November 25, 2012, 6:43 PM >> The email address is >> from? auis.edu.iq = Iraq >> >> Sometimes persons living inside the box cannot see the >> forest because of the >> trees. >> >> PEACE >> >> >> Ephesians 4:32 & Cheers!!! >> >> A password is like a... toothbrush ;^) >> Choose a good one, change it regularly and don't share it. >> >> -----Original Message----- >> From: Randy [mailto:randy_94108 at yahoo.com] >> >> Sent: Sunday, November 25, 2012 3:52 PM >> To: Network IPdog >> Cc: nanog at nanog.org >> Subject: RE: Adding GPS location to IPv6 header >> >> WHAT??? >> >> Is this the extent to which This-List has DEGENERATED??? >> >> How dare you make such a horrendous accusation Sir? >> >> You may NOT like what OP has proposed. I don't either for >> more reasons than >> one! >> >> However, YOU are neither qualified NOR authorised to ask >> such an appallingly >> INSENSITIVE Question! >> >> Your so called "Freedom-of-Speech" DOES NOT translate to >> Character-Assasination on this or any other forum!! >> >> Follow me you ipdog? Find you own bitch to abuse. Don't do >> it here!! >> >> ./Randy >> >> --- On Sun, 11/25/12, Network IPdog >> wrote: >> >>> From: Network IPdog >>> Subject: RE: Adding GPS location to IPv6 header >>> To: "'John Adams'" , >> "'Ammar Salih'" >>> >>> Cc: nanog at nanog.org >>> Date: Sunday, November 25, 2012, 3:16 PM Et al, >>> >>> There is one simple question that needs to be asked! >>> >>> >>> Ammar Salih @ ammar.salih at auis.edu.iq >>> Are you a terrorist? >>> >>> >>> >>> Ephesians 4:32 & Cheers!!! >>> >>> A password is like a... toothbrush ;^) Choose a good >> one, change it >>> regularly and don't share it. >>> >>> >>> >>> -----Original Message----- >>> From: John Adams [mailto:jna at retina.net] >>> Sent: Sunday, November 25, 2012 2:20 PM >>> To: Ammar Salih >>> Cc: nanog at nanog.org >>> list >>> Subject: Re: Adding GPS location to IPv6 header >>> >>> Your proposal doesn't even give people a way to encrypt >> their location >>> data; By moving geodata to a portion of the protocol >> which is not >>> covered by commonly used encryption methods (i.e. >> HTTPS, which is up a >>> few layers in the stack) people can't be protected >> should this data be >>> monitored by a malicious intermediary. Think: Syria, >> China, Iran, or >>> any other government which will kill you for your words >> online. >>> >>> Application protocols sending GPS data under say, HTTPS >> protect the >>> end user from revealing their location to anyone on >> their path, >>> forcing an intermediary to look up the IP in a common >> geo database >>> which will be mostly inaccurate in pinpointing users, >> and hopefully >>> will save lives. >>> >>> Companies like Twitter, Facebook, and some parts of >> google are going >>> HTTPS by default for this very reason. >>> >>> This proposal is dead, you don't have the sense to lie >> down. >>> >>> >>> >> >> > From dedelman at iname.com Mon Nov 26 04:32:26 2012 From: dedelman at iname.com (Dave Edelman) Date: Sun, 25 Nov 2012 23:32:26 -0500 Subject: Adding GPS location to IPv6 header In-Reply-To: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> References: <50ae13c5.b0eb440a.3c9b.ffffa9df@mx.google.com> Message-ID: <005401cdcb8f$09fdc400$1df94c00$@iname.com> This is the first reasonable, rational, and well-defined argument for not making the transition to IPv6. As to someone's question about "Are you a terrorist?" If there is such a construct as a transitive noun, then this might qualify. People rarely describe themselves as terrorists, typically non-disinterested third-parties describe them as such. --Dave > -----Original Message----- > From: Ammar Salih [mailto:ammar.salih at auis.edu.iq] > Sent: Thursday, November 22, 2012 7:00 AM > To: nanog at nanog.org > Subject: Adding GPS location to IPv6 header > > Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF > website, your ideas and comments are most welcome! > > > > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t > ext=1 > > > > Thanks! > > Ammar Salih > > > > From dreamwaverfx at yahoo.com Mon Nov 26 06:54:38 2012 From: dreamwaverfx at yahoo.com (Alex) Date: Mon, 26 Nov 2012 08:54:38 +0200 Subject: Adding GPS location to IPv6 header In-Reply-To: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Message-ID: <50B3122E.70008@yahoo.com> While most of the people are trying to save the internet from any form of "goverment" and let it be free, this would be like shooting yourself in the foot. This would be great for troubleshooting things...I agree, but other than that it would create a whole new plethora of privacy concerns. We use the internet to express ideas either through our real life names or through alter-egos that give us anonymity and let us say things we wouldn't dare otherwise. GPS data would just destroy any sort of anonymity that is left on the NET. I can see big companies paying large sums for this sort of info...imagine google, facebook,etc having access to this kind of data. "the host should have the option of not sending location updates." Lets face it...how many people really know what a IP is, what it can do and what you can turn off or on? Other than the IT sector, most other people do not care and they just plug-and-play. This would just create a window through which you could implement such a feature and throw out most security concerns, because the people that actually care understand the feature and can turn it off...the masses are not so lucky and they get the BIG BROTHER treatment. GPS header would have the same effect on IPv6 implementation as CGN. While CGN and GPS data have the potential to make alot of cash for the ISP who implements it...we don't really want that in our lives and it would deter the customers from switching to IPv6 even more. IMHO the Internet should just be free and offer full anonymity, else it would just come crashing down on our heads. On 11/25/2012 2:30 PM, Ammar Salih wrote: > Thank you everyone, I appreciate your feedback and will try to summarize few > points in one email to avoid duplication .. apologies if I missed any. > > > > > >> This is not data that should be sent on every packet. It becomes > redundant. > > > > 1- It does not have to be in every IPv6 header, only when there is location > update. > > 2- the host should have the option of not sending location updates. > > 3- I am suggesting an *extension header*, which means that operators will > have the option of not using it in case they don't want to. > > > > ---------------------------------------------------- > > > > > >> A good alternative would be to create application layer protocols that > could request and send GPS positions. > > 1- there are already several application-layer mechanisms which have been > created for this purpose, none of them has been considered by major service > providers, google for example is still using RIR info for determining > location-based settings like language. > > > 2- Layer 7 will not be detected by layer 3 devices (routers) .. so > location-based service on layer-3 will not be possible. > > > 3- Currently, many applications do not share same mechanisms to obtain > location or location-related data, GEOPRIV WG [1] works on http location > mechanism, but *for the sake of example* VoIP soft-switches may not support > http protocol, so a new mechanism needs to be developed- which has been done > [2] .. W3c has also specified another API that provides scripted access to > geographical location information [3] which has not been considered by > others .. > > that's why I am suggesting a unified lower layer *optional* mechanism which > is capable of supporting all other applications. > > > > [1] https://datatracker.ietf.org/wg/geopriv/charter/ > > [2] http://tools.ietf.org/html/rfc6442 > > [3] http://dev.w3.org/geo/api/spec-source.html > > > > ---------------------------------------------------------------------------- > ------ > > > > > >> I see major privacy issues with this. Why introduce more intelligence > which WILL eventually be used for more intrusion into the private lives of > all of us? > > > > 1- The host should have the option of not sending location updates. > > 2- It's extension header, means it's up to the service provider to use > the feature or not. > > 3- Users are being routed through ISPs, if we don't trust the ISP then I > can assure you that ISP can get much more information than physical > location, any un-encrypted traffic -which is the majority- can be analyzed > at the ISP level (up to layer-7). > > > > Anythink you write on facebook for example *if you don't use https* can be > detected, including location tags, relationships, activities, wall posts, > friends ... and much more, all your http traffic, including documents you > read, messages, usernames, passwords, bank accounts ...etc. > > > > Other than ISP, sniffers can be connected to the same layer-2/layer-3 device > as mine, in this case I would worry about > usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not > location as the sniffer in this case is mostly sitting at the same physical > location as mine. > > > > 4- our locations currently are being sent anyways through RIR info, without > our awareness or control, I am suggesting to have the end user control the > feature, still his/her option though not to send location updates. > > > > ------------------------------------------- > > > > > > Thank you everyone for your time and professional feedback, I highly > appreciate it! > > > > Please be informed that this is only a draft, and I am requesting comments, > I also apologize for those who felt uncomfortable about the draft *they > should not* as the whole feature is optional - in case its implemented. > > > > Thanks, > > Ammar > > > > > > > > From: Ammar Salih [mailto:ammar.salih at auis.edu.iq] > Sent: Thursday, November 22, 2012 3:00 PM > To: 'nanog at nanog.org' > Subject: Adding GPS location to IPv6 header > > > > Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF > website, your ideas and comments are most welcome! > > > > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t > ext=1 > > > > Thanks! > > Ammar Salih > > > > > From eugen at leitl.org Mon Nov 26 08:02:57 2012 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 26 Nov 2012 09:02:57 +0100 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Message-ID: <20121126080257.GI9750@leitl.org> On Sun, Nov 25, 2012 at 02:19:48PM -0800, John Adams wrote: > Your proposal doesn't even give people a way to encrypt their location > data; By moving geodata to a portion of the protocol which is not covered It's not possible to hide location. Anonymity and efficient transport don't mix. This will become even more so at TBit/s transport rates. That's no problem, as you can use e.g. mix networks to provide strong anonymity for those who need at a higher layer. The sooner everbody realizes this, the sooner we can move on. > by commonly used encryption methods (i.e. HTTPS, which is up a few layers > in the stack) people can't be protected should this data be monitored by a > malicious intermediary. Think: Syria, China, Iran, or any other government > which will kill you for your words online. > > Application protocols sending GPS data under say, HTTPS protect the end > user from revealing their location to anyone on their path, forcing an > intermediary to look up the IP in a common geo database which will be > mostly inaccurate in pinpointing users, and hopefully will save lives. > > Companies like Twitter, Facebook, and some parts of google are going HTTPS > by default for this very reason. > > This proposal is dead, you don't have the sense to lie down. From ripe at alfatelecom.cz Mon Nov 26 10:01:11 2012 From: ripe at alfatelecom.cz (Network Department) Date: Mon, 26 Nov 2012 11:01:11 +0100 Subject: AS12715 (Jazz Telecom S.A.) Peering contact Message-ID: Hello! Could somebody provide me peering contact for AS12715 (Jazz Telecom S.A.)? I see they have OPEN peering policy at AMS-IX and peering contact bgp at jazztel.com but there are no replies from this email. Maybe somebody knows private contact? Thanks. -- Network Department Alfa Telecom s.r.o. http://www.alfatelecom.cz email: ripe at alfatelecom.cz phone: +420 226 020 362 From aristidis.lambrianidis at ams-ix.net Mon Nov 26 10:09:44 2012 From: aristidis.lambrianidis at ams-ix.net (Aris Lambrianidis) Date: Mon, 26 Nov 2012 11:09:44 +0100 Subject: AS12715 (Jazz Telecom S.A.) Peering contact In-Reply-To: References: Message-ID: Hi, You could try noc at jazztel.com instead, hopefully they'll reply. Aris Lambrianidis AMS-IX B.V. http://www.ams-ix.net/ On Nov 26, 2012, at 11:01 PM, Network Department wrote: > Hello! > > Could somebody provide me peering contact for AS12715 (Jazz Telecom > S.A.)? I see they have OPEN peering policy at AMS-IX and peering > contact bgp at jazztel.com but there are no replies from this email. > > Maybe somebody knows private contact? > > Thanks. > > -- > Network Department > Alfa Telecom s.r.o. > http://www.alfatelecom.cz > email: ripe at alfatelecom.cz > phone: +420 226 020 362 > From ripe at alfatelecom.cz Mon Nov 26 10:19:09 2012 From: ripe at alfatelecom.cz (Network Department) Date: Mon, 26 Nov 2012 11:19:09 +0100 Subject: AS12715 (Jazz Telecom S.A.) Peering contact In-Reply-To: References: Message-ID: I sent email to this address but this is group contact email and I don't know when I'll be answered. I'm still interesting in direct contact email =) Thanks. On Mon, Nov 26, 2012 at 11:09 AM, Aris Lambrianidis wrote: > Hi, > > You could try noc at jazztel.com instead, hopefully they'll reply. > > Aris Lambrianidis > AMS-IX B.V. > http://www.ams-ix.net/ > > > On Nov 26, 2012, at 11:01 PM, Network Department wrote: > >> Hello! >> >> Could somebody provide me peering contact for AS12715 (Jazz Telecom >> S.A.)? I see they have OPEN peering policy at AMS-IX and peering >> contact bgp at jazztel.com but there are no replies from this email. >> >> Maybe somebody knows private contact? >> >> Thanks. >> >> -- >> Network Department >> Alfa Telecom s.r.o. >> http://www.alfatelecom.cz >> email: ripe at alfatelecom.cz >> phone: +420 226 020 362 >> > -- Network Department Alfa Telecom s.r.o. http://www.alfatelecom.cz email: ripe at alfatelecom.cz phone: +420 226 020 362 From randy at psg.com Mon Nov 26 10:57:51 2012 From: randy at psg.com (Randy Bush) Date: Mon, 26 Nov 2012 19:57:51 +0900 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> Message-ID: > My guess is that a non-trivial fraction of observed IPv6 traffic today > is unintentional. almost all ip traffic is unintentional. "i want my mtv. money for nothin' and the chicks are free." < from a friend in a big broadband provider > when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix. the brick wall is 'smart' tee vees etc, which do not speak v6, and will have a five+ year lifetime. randy From kuenzler at init7.net Mon Nov 26 11:07:30 2012 From: kuenzler at init7.net (Fredy Kuenzler) Date: Mon, 26 Nov 2012 12:07:30 +0100 Subject: AS12715 (Jazz Telecom S.A.) Peering contact In-Reply-To: References: Message-ID: <50B34D72.7060803@init7.net> Am 26.11.2012 11:01, schrieb Network Department: > Could somebody provide me peering contact for AS12715 (Jazz Telecom > S.A.)? I see they have OPEN peering policy at AMS-IX and peering contact > bgp at jazztel.com but there are no replies from this email. The address you mentioned is actually very responsive to me... -- Fredy K?nzler Init7 (Switzerland) AG AS13030 Elias-Canetti-Strasse 7 CH-8050 Z?rich Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 http://www.init7.net/ From mohacsi at niif.hu Mon Nov 26 11:20:04 2012 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 26 Nov 2012 12:20:04 +0100 (CET) Subject: Adding GPS location to IPv6 header In-Reply-To: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Message-ID: On Sun, 25 Nov 2012, Ammar Salih wrote: > Thank you everyone, I appreciate your feedback and will try to summarize few > points in one email to avoid duplication .. apologies if I missed any. > > > > > >> This is not data that should be sent on every packet. It becomes > redundant. > > > > 1- It does not have to be in every IPv6 header, only when there is location > update. It should not be in any IPv6 packet. It has to be in an upper layer protocol. > > 2- the host should have the option of not sending location updates. In worst case. Host should have an option to sending location update - probably not in IP headers, but upper layer protocol. > > 3- I am suggesting an *extension header*, which means that operators will > have the option of not using it in case they don't want to. I suggest an upper layer protocol. Something like HTTP, TCP or UDP option. The server can initiate a carry, and a client can decide to answer with location information. > > > > ---------------------------------------------------- > > > > > >> A good alternative would be to create application layer protocols that > could request and send GPS positions. > > 1- there are already several application-layer mechanisms which have been > created for this purpose, none of them has been considered by major service > providers, google for example is still using RIR info for determining > location-based settings like language. > > > 2- Layer 7 will not be detected by layer 3 devices (routers) .. so > location-based service on layer-3 will not be possible. > > > 3- Currently, many applications do not share same mechanisms to obtain > location or location-related data, GEOPRIV WG [1] works on http location > mechanism, but *for the sake of example* VoIP soft-switches may not support > http protocol, so a new mechanism needs to be developed- which has been done > [2] .. W3c has also specified another API that provides scripted access to > geographical location information [3] which has not been considered by > others .. > > that's why I am suggesting a unified lower layer *optional* mechanism which > is capable of supporting all other applications. > I prefer application and at most the transport layer protocol extension. > > > [1] https://datatracker.ietf.org/wg/geopriv/charter/ > > [2] http://tools.ietf.org/html/rfc6442 > > [3] http://dev.w3.org/geo/api/spec-source.html > > > > ---------------------------------------------------------------------------- > ------ > > > > > >> I see major privacy issues with this. Why introduce more intelligence > which WILL eventually be used for more intrusion into the private lives of > all of us? > > > > 1- The host should have the option of not sending location updates. > > 2- It's extension header, means it's up to the service provider to use > the feature or not. > > 3- Users are being routed through ISPs, if we don't trust the ISP then I > can assure you that ISP can get much more information than physical > location, any un-encrypted traffic -which is the majority- can be analyzed > at the ISP level (up to layer-7). > > > > Anythink you write on facebook for example *if you don't use https* can be > detected, including location tags, relationships, activities, wall posts, > friends ... and much more, all your http traffic, including documents you > read, messages, usernames, passwords, bank accounts ...etc. > > > > Other than ISP, sniffers can be connected to the same layer-2/layer-3 device > as mine, in this case I would worry about > usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not > location as the sniffer in this case is mostly sitting at the same physical > location as mine. > > > > 4- our locations currently are being sent anyways through RIR info, without > our awareness or control, I am suggesting to have the end user control the > feature, still his/her option though not to send location updates. > > > > ------------------------------------------- > > > > > > Thank you everyone for your time and professional feedback, I highly > appreciate it! > > > > Please be informed that this is only a draft, and I am requesting comments, > I also apologize for those who felt uncomfortable about the draft *they > should not* as the whole feature is optional - in case its implemented. > > > > Thanks, > > Ammar > > > > > > > > From: Ammar Salih [mailto:ammar.salih at auis.edu.iq] > Sent: Thursday, November 22, 2012 3:00 PM > To: 'nanog at nanog.org' > Subject: Adding GPS location to IPv6 header > > > > Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF > website, your ideas and comments are most welcome! > > > > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t > ext=1 > > > > Thanks! > > Ammar Salih > > > > > > From rdobbins at arbor.net Mon Nov 26 11:24:22 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 26 Nov 2012 11:24:22 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> Message-ID: <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> On Nov 26, 2012, at 5:57 PM, Randy Bush wrote: > almost all ip traffic is unintentional. Sure. But my point is the notion that observed IPv6 traffic volumes are due to deliberate migration is not correct. > when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix. 'When', or 'if'? The creeping proliferation of CGNs and the like, along with your example of TVs and oblique point about the sparsity of IPv6-enabled content/services/applications, does not necessarily support the conclusion that wholesale migration within the near- or medium-terms is inevitable. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From arturo.servin at gmail.com Mon Nov 26 12:10:51 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 26 Nov 2012 10:10:51 -0200 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> Message-ID: <50B35C4B.7090602@gmail.com> What do you mean with "deliberate migration"? Users do not care and they will never have a "deliberate migration". However ISPs do, if the user have IPv6 it is because the ISP deliberate migrate to v6 by enable it in their backbone, networks and user's CPEs. IMHO if the user choose to change or not it is the least important, the real important fact is that IPv6 is taking up no matter if it is or not deliberate used by the users. .as On 26/11/2012 09:24, Dobbins, Roland wrote: > > On Nov 26, 2012, at 5:57 PM, Randy Bush wrote: > >> almost all ip traffic is unintentional. > > Sure. But my point is the notion that observed IPv6 traffic volumes are due to deliberate migration is not correct. > >> when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix. > > 'When', or 'if'? The creeping proliferation of CGNs and the like, along with your example of TVs and oblique point about the sparsity of IPv6-enabled content/services/applications, does not necessarily support the conclusion that wholesale migration within the near- or medium-terms is inevitable. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > From rdobbins at arbor.net Mon Nov 26 12:57:31 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 26 Nov 2012 12:57:31 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B35C4B.7090602@gmail.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> Message-ID: On Nov 26, 2012, at 7:10 PM, Arturo Servin wrote: > Users do not care and they will never have a "deliberate migration". I understand this. However, the way that IPv6 migration is discussed in most contexts seems to be predicated upon the notion that there is some industry imperative to light up network with IPv6. My point is that there is not. > IMHO if the user choose to change or not it is the least important, the real important fact is that IPv6 is taking up no matter if it is or not deliberate used by the users. I disagree somewhat with this view. The significant question is whether the users are actually accessing apps/services/content via IPv6, or if it's essentially white noise. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From swmike at swm.pp.se Mon Nov 26 13:33:43 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 26 Nov 2012 14:33:43 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> Message-ID: On Mon, 26 Nov 2012, Dobbins, Roland wrote: > I understand this. However, the way that IPv6 migration is discussed in > most contexts seems to be predicated upon the notion that there is some > industry imperative to light up network with IPv6. My point is that > there is not. We'll all be better off if we all move to IPv6 and don't go the NAT44(44....) road longer than necessary. We can decide we want to wait for everybody else, which means we won't all be better off, ever. > I disagree somewhat with this view. The significant question is whether > the users are actually accessing apps/services/content via IPv6, or if > it's essentially white noise. Why is that a significant question? If they have IPv6, they will access a significant amount of content via IPv6. If they don't, then it's nothing. I don't get why people are arguing that we shouldn't do IPv6 because IPv6 is so little of total traffic. There is so little traffic because ISPs do not turn on IPv6. The content is there now. -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Mon Nov 26 13:53:10 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 26 Nov 2012 13:53:10 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> Message-ID: <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> On Nov 26, 2012, at 8:33 PM, Mikael Abrahamsson wrote: > Why is that a significant question? It is significant because it provides some rough measure of the relative *importance* of IPv6 connectivity to the users and to the content/app/services networks. We are not yet at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet in order to do their jobs. We are not even at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet for recreational purposes. Providing IPv6 capabilities for popular content/apps/services like Google, Netflix, and Facebook is one thing. Creating compelling content/apps/services which are *only* accessible via IPv6 is another. I believe gaming developers are probably in the best position to provide such a stimulus, should they determine that it makes economic sense for them to do so. > If they have IPv6, they will access a significant amount of content via IPv6. The definition of 'have IPv6' is somewhat nebulous, at present - that's part of the problem. > I don't get why people are arguing that we shouldn't do IPv6 because IPv6 is so little of total traffic. I'm not making that argument. > There is so little traffic because ISPs do not turn on IPv6. The content is there now. As Randy noted, some big destination networks have in fact enabled IPv6 connectivity to their properties. A lot haven't, however, and user application capabilities/behaviors also come into play. Again, where're the compelling IPv6-only content/apps/services? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From damian at google.com Mon Nov 26 14:25:47 2012 From: damian at google.com (Damian Menscher) Date: Mon, 26 Nov 2012 06:25:47 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: On Mon, Nov 26, 2012 at 5:53 AM, Dobbins, Roland wrote: > Again, where're the compelling IPv6-only content/apps/services? > To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Unsurprisingly, this does not drive user adoption, and major sites won't add IPv6-only content while a significant fraction of users are v4-only. Stalemate. Damian From eugen at leitl.org Mon Nov 26 14:37:16 2012 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 26 Nov 2012 15:37:16 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: <20121126143716.GB9750@leitl.org> On Mon, Nov 26, 2012 at 06:25:47AM -0800, Damian Menscher wrote: > On Mon, Nov 26, 2012 at 5:53 AM, Dobbins, Roland wrote: > > > Again, where're the compelling IPv6-only content/apps/services? > > > > To answer your rhetorical question, http://www.kame.net/ has a dancing > kame. To my knowledge, that's the most compelling IPv6-only content. > Unsurprisingly, this does not drive user adoption, and major sites won't > add IPv6-only content while a significant fraction of users are v4-only. Recently, due to IPv4 scarcity some large mass hosters (OVH, and soon Hetzner) have started to charge for IP use, with pricing probably moving from current 1 EUR/IPv4 address/month to somewhere 2-5 EUR/IPv4 address/month. This price pressure both allows an efficient use of existing networks (by forcing customers to relinquish unused resources) and also will drive adoption of IPv6-only models, as these addresses remain free, for time being. From sthaug at nethelp.no Mon Nov 26 14:53:51 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 26 Nov 2012 15:53:51 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: <20121126.155351.74727550.sthaug@nethelp.no> > > Again, where're the compelling IPv6-only content/apps/services? > > > > To answer your rhetorical question, http://www.kame.net/ has a dancing > kame. To my knowledge, that's the most compelling IPv6-only content. Don't forget http://loopsofzen.co.uk/ - that's definitely the most compelling IPv6-only content I've found. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From carlosm3011 at gmail.com Mon Nov 26 14:56:52 2012 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Mon, 26 Nov 2012 12:56:52 -0200 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> Message-ID: <50B38334.4060402@gmail.com> Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to switch. In Spanish we have a very strong adjective for this kind of ideas: "p?simo". I couldn't find a similar one in English without using foul words :-) In any case, and as it already has been pointed out, I can imagine an upper layer protocol, similar to NTP that reports GPS coordinates. Come to think of it, if NTP could be extended this would fit in nicely as there are already lots of NTP nodes which already have GPS sensors. Additionally, unless the proponents of this idea are expecting every router manufacturer to build GPS chips into their gear and us datacentre operators to drill holes on our roofs for the antennas, I don't see any real useful role for this extension header. cheers! ~Carlos On 11/26/12 9:20 AM, Mohacsi Janos wrote: > > > > On Sun, 25 Nov 2012, Ammar Salih wrote: > >> Thank you everyone, I appreciate your feedback and will try to >> summarize few >> points in one email to avoid duplication .. apologies if I missed any. >> >> >> >> >> >>> This is not data that should be sent on every packet. It becomes >> redundant. >> >> >> >> 1- It does not have to be in every IPv6 header, only when there is >> location >> update. > > It should not be in any IPv6 packet. It has to be in an upper layer > protocol. > > >> >> 2- the host should have the option of not sending location updates. > > In worst case. Host should have an option to sending location update - > probably not in IP headers, but upper layer protocol. > >> >> 3- I am suggesting an *extension header*, which means that operators will >> have the option of not using it in case they don't want to. > > > I suggest an upper layer protocol. Something like HTTP, TCP or UDP > option. The server can initiate a carry, and a client can decide to > answer with location information. > > >> >> >> >> ---------------------------------------------------- >> >> >> >> >> >>> A good alternative would be to create application layer protocols that >> could request and send GPS positions. >> >> 1- there are already several application-layer mechanisms which have been >> created for this purpose, none of them has been considered by major >> service >> providers, google for example is still using RIR info for determining >> location-based settings like language. >> >> >> 2- Layer 7 will not be detected by layer 3 devices (routers) .. so >> location-based service on layer-3 will not be possible. >> >> >> 3- Currently, many applications do not share same mechanisms to obtain >> location or location-related data, GEOPRIV WG [1] works on http location >> mechanism, but *for the sake of example* VoIP soft-switches may not >> support >> http protocol, so a new mechanism needs to be developed- which has >> been done >> [2] .. W3c has also specified another API that provides scripted >> access to >> geographical location information [3] which has not been considered by >> others .. >> >> that's why I am suggesting a unified lower layer *optional* mechanism >> which >> is capable of supporting all other applications. >> > > I prefer application and at most the transport layer protocol extension. > > > >> >> >> [1] https://datatracker.ietf.org/wg/geopriv/charter/ >> >> [2] http://tools.ietf.org/html/rfc6442 >> >> [3] http://dev.w3.org/geo/api/spec-source.html >> >> >> >> ---------------------------------------------------------------------------- >> >> ------ >> >> >> >> >> >>> I see major privacy issues with this. Why introduce more intelligence >> which WILL eventually be used for more intrusion into the private >> lives of >> all of us? >> >> >> >> 1- The host should have the option of not sending location updates. >> >> 2- It's extension header, means it's up to the service provider >> to use >> the feature or not. >> >> 3- Users are being routed through ISPs, if we don't trust the ISP then I >> can assure you that ISP can get much more information than physical >> location, any un-encrypted traffic -which is the majority- can be >> analyzed >> at the ISP level (up to layer-7). >> >> >> >> Anythink you write on facebook for example *if you don't use https* >> can be >> detected, including location tags, relationships, activities, wall posts, >> friends ... and much more, all your http traffic, including documents you >> read, messages, usernames, passwords, bank accounts ...etc. >> >> >> >> Other than ISP, sniffers can be connected to the same layer-2/layer-3 >> device >> as mine, in this case I would worry about >> usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not >> location as the sniffer in this case is mostly sitting at the same >> physical >> location as mine. >> >> >> >> 4- our locations currently are being sent anyways through RIR info, >> without >> our awareness or control, I am suggesting to have the end user control >> the >> feature, still his/her option though not to send location updates. >> >> >> >> ------------------------------------------- >> >> >> >> >> >> Thank you everyone for your time and professional feedback, I highly >> appreciate it! >> >> >> >> Please be informed that this is only a draft, and I am requesting >> comments, >> I also apologize for those who felt uncomfortable about the draft *they >> should not* as the whole feature is optional - in case its implemented. >> >> >> >> Thanks, >> >> Ammar >> >> >> >> >> >> >> >> From: Ammar Salih [mailto:ammar.salih at auis.edu.iq] >> Sent: Thursday, November 22, 2012 3:00 PM >> To: 'nanog at nanog.org' >> Subject: Adding GPS location to IPv6 header >> >> >> >> Dears, I've proposed a new IPv6 "extension header", it's now posted on >> IETF >> website, your ideas and comments are most welcome! >> >> >> >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t >> >> ext=1 >> >> >> >> Thanks! >> >> Ammar Salih >> >> >> >> >> >> > From swmike at swm.pp.se Mon Nov 26 14:58:04 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 26 Nov 2012 15:58:04 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: On Mon, 26 Nov 2012, Dobbins, Roland wrote: > Again, where're the compelling IPv6-only content/apps/services? There is none. Why is it needed? We need IPv6 to make the Internet continue working and scale for the future. We don't need IPv6 to solve an individuals need, we need it for the long term common good of the Internet. Nobody is going to have IPv6 only content in the near future. This is no reason to have it. Users and content providers are going to be dual stacked. -- Mikael Abrahamsson email: swmike at swm.pp.se From eugen at leitl.org Mon Nov 26 15:20:43 2012 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 26 Nov 2012 16:20:43 +0100 Subject: Adding GPS location to IPv6 header In-Reply-To: <50B38334.4060402@gmail.com> References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B38334.4060402@gmail.com> Message-ID: <20121126152043.GD9750@leitl.org> On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: > Just for redundancy's sake: No, L3 is **not** the place for this kind of > information. L3 is supposed to be simple, easy to implement, fast to I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint). Another such application could be http://en.wikipedia.org/wiki/European_Data_Relay_Satellite (the realtime precision tracking problem has been solved recently). > switch. In Spanish we have a very strong adjective for this kind of > ideas: "p?simo". I couldn't find a similar one in English without using > foul words :-) > > In any case, and as it already has been pointed out, I can imagine an > upper layer protocol, similar to NTP that reports GPS coordinates. Come > to think of it, if NTP could be extended this would fit in nicely as > there are already lots of NTP nodes which already have GPS sensors. Can you see any good uses for this? Area fencing, for games, maybe. I don't see why you couldn't just bind gpsd to port on a public IP, same as GPS sharing over WLAN tethering is done. So it's basically a solved problem, no need for RFC drafts. > Additionally, unless the proponents of this idea are expecting every > router manufacturer to build GPS chips into their gear and us datacentre > operators to drill holes on our roofs for the antennas, I don't see any Some routers *are* already on the roofs. Or on towers. Or in LEO. Visibility is pretty good once you're above few 10 km, and weather is just perfect in orbit. The only storms are of the proton particle variety. > real useful role for this extension header. > From streiner at cluebyfour.org Mon Nov 26 15:24:15 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 26 Nov 2012 10:24:15 -0500 (EST) Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: <50ABEC5A.20104@meetinghouse.net> References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> <50ABD061.4030500@snappydsl.net> <50ABEC5A.20104@meetinghouse.net> Message-ID: On Tue, 20 Nov 2012, Miles Fidelman wrote: > Christopher Morrow wrote: >> apologies, I forgot the emoticons after my last comment. i really did mean >> it in jest... I don't think VZ has harnessed weather-changing-powers. >> (yet). > > Well, they ARE The Phone Company! Makes me want to watch "The President's Analyst" again ;) jms From cb.list6 at gmail.com Mon Nov 26 15:36:22 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 26 Nov 2012 07:36:22 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: Sent from ipv6-only Android On Nov 26, 2012 5:54 AM, "Dobbins, Roland" wrote: > > > On Nov 26, 2012, at 8:33 PM, Mikael Abrahamsson wrote: > > > Why is that a significant question? > > It is significant because it provides some rough measure of the relative *importance* of IPv6 connectivity to the users and to the content/app/services networks. > Ipv6 is not important for users, it is important for network operators who want to sustain their business. > We are not yet at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet in order to do their jobs. > > We are not even at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet for recreational purposes. > > Providing IPv6 capabilities for popular content/apps/services like Google, Netflix, and Facebook is one thing. Creating compelling content/apps/services which are *only* accessible via IPv6 is another. > Dont hold your breath. It wont happen, and in the end means nothing. > I believe gaming developers are probably in the best position to provide such a stimulus, should they determine that it makes economic sense for them to do so. > Nope. Nobody will leave money on the table by alienating users. > > If they have IPv6, they will access a significant amount of content via IPv6. > > The definition of 'have IPv6' is somewhat nebulous, at present - that's part of the problem. > Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective. > > I don't get why people are arguing that we shouldn't do IPv6 because IPv6 is so little of total traffic. > > I'm not making that argument. > Good. > > There is so little traffic because ISPs do not turn on IPv6. The content is there now. > > As Randy noted, some big destination networks have in fact enabled IPv6 connectivity to their properties. A lot haven't, however, and user application capabilities/behaviors also come into play. > > Again, where're the compelling IPv6-only content/apps/services? > Does not matter. And it will not happen. The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ? Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype). CB > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From matthew at corp.crocker.com Mon Nov 26 15:38:21 2012 From: matthew at corp.crocker.com (Matthew Crocker) Date: Mon, 26 Nov 2012 10:38:21 -0500 Subject: CALEA options for a small ISP/ITSP Message-ID: <16830D14-587D-4721-B93E-A9ABCF8D2C9E@corp.crocker.com> I have a CALEA appliance from BearHill that I 'rent'. It has been in my network for years. I'm looking for other alternative solutions for CALEA compliance with a small ISP. It looks like OpenCalea is a dead project. What is everyone else using? My current solution is $1k/month and I rarely get subpoenas, I've never had a wiretap one. My ISP network is a mix of Cisco and Juniper gear. I have a couple GigE connections to my upstreams and push 300-400mbps through the network. I would think that wireshark pcap files would be enough :( Thanks -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com From sander at steffann.nl Mon Nov 26 15:38:18 2012 From: sander at steffann.nl (Sander Steffann) Date: Mon, 26 Nov 2012 16:38:18 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121126.155351.74727550.sthaug@nethelp.no> References: <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <20121126.155351.74727550.sthaug@nethelp.no> Message-ID: <50D6C21F-0B45-40FD-800C-AE5D6FE07140@steffann.nl> Hi, >>> Again, where're the compelling IPv6-only content/apps/services? >>> >> >> To answer your rhetorical question, http://www.kame.net/ has a dancing >> kame. To my knowledge, that's the most compelling IPv6-only content. > > Don't forget http://loopsofzen.co.uk/ - that's definitely the most > compelling IPv6-only content I've found. Wow. Nice one! Sander From mdavids at forfun.net Mon Nov 26 15:48:26 2012 From: mdavids at forfun.net (Marco Davids (Prive)) Date: Mon, 26 Nov 2012 16:48:26 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121126.155351.74727550.sthaug@nethelp.no> References: <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <20121126.155351.74727550.sthaug@nethelp.no> Message-ID: <50B38F4A.30403@forfun.net> On 11/26/12 15:53, sthaug at nethelp.no wrote: >>> Again, where're the compelling IPv6-only content/apps/services? >>> >> To answer your rhetorical question, http://www.kame.net/ has a dancing >> kame. To my knowledge, that's the most compelling IPv6-only content. > Don't forget http://loopsofzen.co.uk/ - that's definitely the most > compelling IPv6-only content I've found. > http:///thepiratebay/.se./ipv6/.sixxs.org was popular for a while, when major ISP's in the Netherlands where forced to block 'The Piratebay' overhere in the Netherlands, I believe... -- Marco From mfidelman at meetinghouse.net Mon Nov 26 16:04:27 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 26 Nov 2012 11:04:27 -0500 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> <50ABD061.4030500@snappydsl.net> <50ABEC5A.20104@meetinghouse.net> Message-ID: <50B3930B.6070008@meetinghouse.net> Justin M. Streiner wrote: > On Tue, 20 Nov 2012, Miles Fidelman wrote: > >> Christopher Morrow wrote: >>> apologies, I forgot the emoticons after my last comment. i really >>> did mean >>> it in jest... I don't think VZ has harnessed weather-changing-powers. >>> (yet). >> >> Well, they ARE The Phone Company! > > Makes me want to watch "The President's Analyst" again ;) Finally. Someone got the reference. :-) Cheers, Miles p.s. only $2.99 to rent in online, from Amazon: http://www.amazon.com/The-Presidents-Analyst-James-Coburn/dp/B0035JNSO8/ref=sr_1_1_vod_0_ren?ie=UTF8&qid=1353945793&sr=8-1 -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From lesmith at ecsis.net Mon Nov 26 16:05:32 2012 From: lesmith at ecsis.net (Larry Smith) Date: Mon, 26 Nov 2012 10:05:32 -0600 Subject: CALEA options for a small ISP/ITSP In-Reply-To: <16830D14-587D-4721-B93E-A9ABCF8D2C9E@corp.crocker.com> References: <16830D14-587D-4721-B93E-A9ABCF8D2C9E@corp.crocker.com> Message-ID: <201211261005.32168.lesmith@ecsis.net> On Mon November 26 2012 09:38, Matthew Crocker wrote: > I have a CALEA appliance from BearHill that I 'rent'. It has been in my > network for years. I'm looking for other alternative solutions for CALEA > compliance with a small ISP. It looks like OpenCalea is a dead project. > What is everyone else using? > > My current solution is $1k/month and I rarely get subpoenas, I've never had > a wiretap one. > > My ISP network is a mix of Cisco and Juniper gear. I have a couple GigE > connections to my upstreams and push 300-400mbps through the network. > > I would think that wireshark pcap files would be enough :( > Believe Mikrotik boxes support CALEA, you might check www.mikrotik.com -- Larry Smith lesmith at ecsis.net From rdobbins at arbor.net Mon Nov 26 16:27:06 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 26 Nov 2012 16:27:06 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote: > Ipv6 is not important for users, it is important for network operators who want to sustain their business. I agree with the first part; not sure I agree with the second part. > Nope. Nobody will leave money on the table by alienating users. I think it may be possible to make money with compelling IPv6-only content/services/applications. > Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective. I'm not very interested in their judgement. So, I'm quite happy with my perspective, thanks. > Does not matter. And it will not happen. Proof by repeated assertion doesn't sway me. > The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ? These are important, yes. > Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype). It's my contention that IPv6 won't be widely deployed unless/until end-customers call up their ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From cb.list6 at gmail.com Mon Nov 26 17:15:10 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 26 Nov 2012 09:15:10 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: On Mon, Nov 26, 2012 at 8:27 AM, Dobbins, Roland wrote: > > On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote: > >> Ipv6 is not important for users, it is important for network operators who want to sustain their business. > > I agree with the first part; not sure I agree with the second part. > >> Nope. Nobody will leave money on the table by alienating users. > > I think it may be possible to make money with compelling IPv6-only content/services/applications. > I disagree, i simply see an additional fee for IPv4 coming about. >> Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective. > > I'm not very interested in their judgement. So, I'm quite happy with my perspective, thanks. > >> Does not matter. And it will not happen. > > Proof by repeated assertion doesn't sway me. > >> The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ? > > These are important, yes. > >> Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype). > > It's my contention that IPv6 won't be widely deployed unless/until end-customers call up their ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have. > In face of your speculation i present to you facts: Google, Yahoo, Facebook, Bing (... other content and app providers) along with many access networks (VZW, Comcast, AT&T DSL, KDDI, DT, Free ...) now have quite meaningful IPv6 deployments. AT&T DSL and VZW LTE are in the millions of subs with IPv6 at this point. These are not the result of an IPv6-only service (i think there was some v6 p2p service at Free), and they are likely also not motivated by Grandma calling up and asking for IPv6 or she is switching providers. Why did they do this? Because IPv4 is run out and NAT is bad. I am not listing my own deployment since we are not default-on for IPv6 yet, but will be RSN. CB > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From r.engehausen at gmail.com Mon Nov 26 17:24:38 2012 From: r.engehausen at gmail.com (Roy) Date: Mon, 26 Nov 2012 09:24:38 -0800 Subject: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan In-Reply-To: <50B3930B.6070008@meetinghouse.net> References: <50AB32BB.4010508@derekivey.com> <2671C6CDFBB59E47B64C10B3E0BD5923033807F06A@PRVPEXVS15.corp.twcable.com> <50ABC295.10907@snappydsl.net> <50ABD061.4030500@snappydsl.net> <50ABEC5A.20104@meetinghouse.net> <50B3930B.6070008@meetinghouse.net> Message-ID: <50B3A5D6.7000903@gmail.com> On 11/26/2012 8:04 AM, Miles Fidelman wrote: > Justin M. Streiner wrote: >> On Tue, 20 Nov 2012, Miles Fidelman wrote: >> >>> Christopher Morrow wrote: >>>> apologies, I forgot the emoticons after my last comment. i really >>>> did mean >>>> it in jest... I don't think VZ has harnessed weather-changing-powers. >>>> (yet). >>> >>> Well, they ARE The Phone Company! >> >> Makes me want to watch "The President's Analyst" again ;) > > Finally. Someone got the reference. :-) > > Cheers, > > Miles > > I alway go for WKRP http://www.youtube.com/watch?v=cTPzTG1Lx60 From alh-ietf at tndh.net Mon Nov 26 17:38:32 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 26 Nov 2012 09:38:32 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: <010101cdcbfc$dab478b0$901d6a10$@tndh.net> Dobbins, Roland wrote: > On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote: > > > Ipv6 is not important for users, it is important for network operators who > want to sustain their business. > > I agree with the first part; not sure I agree with the second part. Operators are all free to choose their own planning horizons. History is littered with the remnants of those with limited vision. > > > Nope. Nobody will leave money on the table by alienating users. > > I think it may be possible to make money with compelling IPv6-only > content/services/applications. If you believe that is true you should do it and prove the point. Unfortunately most people that actually deploy and support applications can't make the math come out right when the access providers don't provide a path to 99% of the paying customers, then do just about everything they can to hobble bypass approaches. > > > Apple and msft os' s now make a clear judgement on that. So, you need to > update your perspective. > > I'm not very interested in their judgement. So, I'm quite happy with my > perspective, thanks. The overall system includes the perspective of app developers, not just BGP knob twisters, so the point of having a widespread api base is critical to making progress. > > > Does not matter. And it will not happen. > > Proof by repeated assertion doesn't sway me. It will happen, just not anytime soon. As the access networks get deployed, traffic will shift, so eventually the question about the expense of maintaining an ever more complex IPv4 version of the app to deal with multi-layer nat to support a dwindling user base will have to be answered. > > > The better question, for an isp, is what kind of ipv4 secondary market > budget do you have? How hot is your cgn running? Like ALGs much ? > Security and attribute much ? > > These are important, yes. > > > Again , users dont care or know about v4 or v6. This is purely a network > operator and app issue (cough cough ... skype). > > It's my contention that IPv6 won't be widely deployed unless/until end- > customers call up their ISPs demanding this 'IPv6 or whatever' thing they > need to accomplish some goal they have. And it is the contention of app developers that they can't make money on an app that that can't reach 99% of the intended user base. The entire point of tunnels is to break this absurd deadlock where access won't deploy without apps and apps won't deploy without access. Instead of getting on with it, there is an ongoing entrenchment and search for the utopian one-size-fits-all zero-cost transition plan. All this does is show how widespread the denial is, where people are refusing to let go of an entire career's worth of 'expertise' to keep up with the technology changes. Fortunately some have moved on, and are deploying despite the extra effort required in the short term. Once there are a substantial number of IPv6 access networks, the traffic volume will shift rapidly and people will start asking why the core is even aware of IPv4. At that point maintaining IPv4 will become the end user's problem, and they will have to find legacy tunnel providers if they want to keep that going. IPv4 won't die, it will just become an edge problem because the only reason to keep it running will be devices with embedded IPv4-only stacks which won't be replaced for 10 years. Tony From carlosm3011 at gmail.com Mon Nov 26 18:01:17 2012 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Mon, 26 Nov 2012 16:01:17 -0200 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120133142.GP3070@irc.ae7.st> <009f01cdc757$8553b470$8ffb1d50$@tndh.net> Message-ID: <50B3AE6D.6070003@gmail.com> We have numbers to share. We have performed two experiments at two different events LACNIC held this year: - June in Port-Au-Prince (~110 attendees) - October in Montevideo (~400 attendees) The question was: "What is the relation between IPv4 and IPv6 traffic in a fully dual-stacked network?". The answers were remarkably consistent. We got ~30% IPv6 in PAP and around 33% in MVD (actually in MVD we got over 40% in total byte counts, but we corrected for the IPv6 video feed that added a constant 1 Mbps/sec) This percentage is calculated as: 100*(bytes sent and received over IPv6) / (total bytes sent and received) In PAP we measured this using iftop and a couple of pcap filters on the Linux server we were using as 'router' (Owen was there and was of great help setting the whole thing up). In MVD we had a dual 7201s as routers and we measured traffic with Netflow. Warm regards, ~Carlos On 11/21/12 12:51 AM, Patrick W. Gilmore wrote: > On Nov 20, 2012, at 14:44 , "Tony Hain" wrote: > >> If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, why wouldn't a dual stacked end point have half of its traffic as IPv6 after June??? > > "If you assume...". Kinda says it all right there. > > But more importantly, those three combined are not 50% of overall traffic. It _might_ be true in the US, for some times of the day, but certainly not world-wide overall traffic. If for no better reason than you cannot get NF in all countries. > From jra at baylink.com Mon Nov 26 18:39:08 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 26 Nov 2012 13:39:08 -0500 (EST) Subject: LACNIC RPKI RTA key rollover In-Reply-To: <50AE71C4.4010004@gmail.com> Message-ID: <27578675.36706.1353955148882.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Carlos M. Martinez" > On Thursday, November 29, 2012 LACNIC will be performing a system > migration to a new release of the RPKI system. We will take the > opportunity to also perform a key rollover of LACNIC's RPKI trust > anchor. The new TAL (trust anchor locator) file can be downloaded from > [1]. Also a ready-to-use configuration file for RIPE-NCC's Validation > Application is available at [2]. Never make two big changes at the same time. If it comes apart on you, you won't know which thing to roll back. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From richard.barnes at gmail.com Mon Nov 26 18:54:48 2012 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 26 Nov 2012 13:54:48 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: On Mon, Nov 26, 2012 at 12:15 PM, Cameron Byrne wrote: > On Mon, Nov 26, 2012 at 8:27 AM, Dobbins, Roland > wrote: > > > > On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote: > > > >> Ipv6 is not important for users, it is important for network operators > who want to sustain their business. > > > > I agree with the first part; not sure I agree with the second part. > > > >> Nope. Nobody will leave money on the table by alienating users. > > > > I think it may be possible to make money with compelling IPv6-only > content/services/applications. > > > > I disagree, i simply see an additional fee for IPv4 coming about. +1 And that in itself seems like it would make IPv6-reachable things a lot more compelling. From owen at delong.com Mon Nov 26 19:52:17 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Nov 2012 11:52:17 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: <50B38334.4060402@gmail.com> References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B38334.4060402@gmail.com> Message-ID: <3B1C7CA3-2359-4B4B-943B-B86DD65C2CA2@delong.com> On Nov 26, 2012, at 06:56 , "Carlos M. Martinez" wrote: > Just for redundancy's sake: No, L3 is **not** the place for this kind of > information. L3 is supposed to be simple, easy to implement, fast to > switch. In Spanish we have a very strong adjective for this kind of > ideas: "p?simo". I couldn't find a similar one in English without using > foul words :-) > The rough translation of p?simo is "terrible". And it certainly applies here. FYI. Owen > In any case, and as it already has been pointed out, I can imagine an > upper layer protocol, similar to NTP that reports GPS coordinates. Come > to think of it, if NTP could be extended this would fit in nicely as > there are already lots of NTP nodes which already have GPS sensors. > > Additionally, unless the proponents of this idea are expecting every > router manufacturer to build GPS chips into their gear and us datacentre > operators to drill holes on our roofs for the antennas, I don't see any > real useful role for this extension header. > > cheers! > > ~Carlos > > On 11/26/12 9:20 AM, Mohacsi Janos wrote: >> >> >> >> On Sun, 25 Nov 2012, Ammar Salih wrote: >> >>> Thank you everyone, I appreciate your feedback and will try to >>> summarize few >>> points in one email to avoid duplication .. apologies if I missed any. >>> >>> >>> >>> >>> >>>> This is not data that should be sent on every packet. It becomes >>> redundant. >>> >>> >>> >>> 1- It does not have to be in every IPv6 header, only when there is >>> location >>> update. >> >> It should not be in any IPv6 packet. It has to be in an upper layer >> protocol. >> >> >>> >>> 2- the host should have the option of not sending location updates. >> >> In worst case. Host should have an option to sending location update - >> probably not in IP headers, but upper layer protocol. >> >>> >>> 3- I am suggesting an *extension header*, which means that operators will >>> have the option of not using it in case they don't want to. >> >> >> I suggest an upper layer protocol. Something like HTTP, TCP or UDP >> option. The server can initiate a carry, and a client can decide to >> answer with location information. >> >> >>> >>> >>> >>> ---------------------------------------------------- >>> >>> >>> >>> >>> >>>> A good alternative would be to create application layer protocols that >>> could request and send GPS positions. >>> >>> 1- there are already several application-layer mechanisms which have been >>> created for this purpose, none of them has been considered by major >>> service >>> providers, google for example is still using RIR info for determining >>> location-based settings like language. >>> >>> >>> 2- Layer 7 will not be detected by layer 3 devices (routers) .. so >>> location-based service on layer-3 will not be possible. >>> >>> >>> 3- Currently, many applications do not share same mechanisms to obtain >>> location or location-related data, GEOPRIV WG [1] works on http location >>> mechanism, but *for the sake of example* VoIP soft-switches may not >>> support >>> http protocol, so a new mechanism needs to be developed- which has >>> been done >>> [2] .. W3c has also specified another API that provides scripted >>> access to >>> geographical location information [3] which has not been considered by >>> others .. >>> >>> that's why I am suggesting a unified lower layer *optional* mechanism >>> which >>> is capable of supporting all other applications. >>> >> >> I prefer application and at most the transport layer protocol extension. >> >> >> >>> >>> >>> [1] https://datatracker.ietf.org/wg/geopriv/charter/ >>> >>> [2] http://tools.ietf.org/html/rfc6442 >>> >>> [3] http://dev.w3.org/geo/api/spec-source.html >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> ------ >>> >>> >>> >>> >>> >>>> I see major privacy issues with this. Why introduce more intelligence >>> which WILL eventually be used for more intrusion into the private >>> lives of >>> all of us? >>> >>> >>> >>> 1- The host should have the option of not sending location updates. >>> >>> 2- It's extension header, means it's up to the service provider >>> to use >>> the feature or not. >>> >>> 3- Users are being routed through ISPs, if we don't trust the ISP then I >>> can assure you that ISP can get much more information than physical >>> location, any un-encrypted traffic -which is the majority- can be >>> analyzed >>> at the ISP level (up to layer-7). >>> >>> >>> >>> Anythink you write on facebook for example *if you don't use https* >>> can be >>> detected, including location tags, relationships, activities, wall posts, >>> friends ... and much more, all your http traffic, including documents you >>> read, messages, usernames, passwords, bank accounts ...etc. >>> >>> >>> >>> Other than ISP, sniffers can be connected to the same layer-2/layer-3 >>> device >>> as mine, in this case I would worry about >>> usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not >>> location as the sniffer in this case is mostly sitting at the same >>> physical >>> location as mine. >>> >>> >>> >>> 4- our locations currently are being sent anyways through RIR info, >>> without >>> our awareness or control, I am suggesting to have the end user control >>> the >>> feature, still his/her option though not to send location updates. >>> >>> >>> >>> ------------------------------------------- >>> >>> >>> >>> >>> >>> Thank you everyone for your time and professional feedback, I highly >>> appreciate it! >>> >>> >>> >>> Please be informed that this is only a draft, and I am requesting >>> comments, >>> I also apologize for those who felt uncomfortable about the draft *they >>> should not* as the whole feature is optional - in case its implemented. >>> >>> >>> >>> Thanks, >>> >>> Ammar >>> >>> >>> >>> >>> >>> >>> >>> From: Ammar Salih [mailto:ammar.salih at auis.edu.iq] >>> Sent: Thursday, November 22, 2012 3:00 PM >>> To: 'nanog at nanog.org' >>> Subject: Adding GPS location to IPv6 header >>> >>> >>> >>> Dears, I've proposed a new IPv6 "extension header", it's now posted on >>> IETF >>> website, your ideas and comments are most welcome! >>> >>> >>> >>> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t >>> >>> ext=1 >>> >>> >>> >>> Thanks! >>> >>> Ammar Salih >>> >>> >>> >>> >>> >>> >> From owen at delong.com Mon Nov 26 20:37:45 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Nov 2012 12:37:45 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> Message-ID: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> On Nov 26, 2012, at 04:57 , "Dobbins, Roland" wrote: > > On Nov 26, 2012, at 7:10 PM, Arturo Servin wrote: > >> Users do not care and they will never have a "deliberate migration". > > I understand this. However, the way that IPv6 migration is discussed in most contexts seems to be predicated upon the notion that there is some industry imperative to light up network with IPv6. My point is that there is not. There is, actually. The fact that more users are constantly connecting more devices creates an industry imperative to light up a larger address space. CGN does not scale and cannot scale. At best, it's a hack that might allow us to cope with a few years of transition while there are still devices in homes that are IPv4-only, but it certainly doesn't reduce or remove the imperative. Any ISP that fails to light up its customers with IPv6 in the next 3 years is at serious risk of having its customers notice that they are no longer connected to the entire internet. Since 2011, IPv4 has been becoming a progressively smaller fraction of the internet. Today, that progression is very slow and it's still north of 99%. However, there is notable acceleration and given the rate of internet growth, within 5 years, I suspect that even if everything that is currently IPv4 remains IPv4 and all new services are still deployed with IPv4 in addition to IPv6, less than 60% of the internet will still be IPv4 at that time. >> IMHO if the user choose to change or not it is the least important, the real important fact is that IPv6 is taking up no matter if it is or not deliberate used by the users. > > I disagree somewhat with this view. The significant question is whether the users are actually accessing apps/services/content via IPv6, or if it's essentially white noise. Really, this isn't the important question, either. The important question is what is the rate of growth of the ability of users to access content/apps/services via IPv6? Further, what is the rate of growth in the provision of content/apps/services on dual-stack vs. IPv4-only? Later, the important question will become what fraction of users can still access the IPv4 internet through <2 layers of NAT? As I said, at current growth rates, by q4 2017, that final figure will be less than 60%. If you don't think that the need to sustain the growth in the number of devices attached to the network (never mind the number of things causing that rate to accelerate[1]) makes IPv6 inevitable at this point, you really aren't paying attention. Owen [1] Things causing growth in the rate of internet attachment: IPv6-enabled light bulbs and other small appliances/sensors/etc. Smart-Grid/Smart-Meters Environmental Monitoring Sensor Arrays (things like projects to deploy literally millions of sensors in the oceans) Various 6lowpan based projects The eventual migration of what is currently Zigbee towards 6lowpan (OK, this one might be questionable, but it's certainly better for everyone except the Zigbee licensing folks if it goes that way) Public Safety applications (think telemetry-enabled ambulances) Bio-sensors (think remote patient monitoring, IPv6-enabled pace-makers and automatic-internal-defibrulators, etc.) Home automation Applications we haven't even thought of yet From rsk at gsp.org Mon Nov 26 20:48:30 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 26 Nov 2012 15:48:30 -0500 Subject: Fwd: (via Dave Farber's IP list): Mark Crispin Message-ID: <20121126204830.GA31228@gsp.org> Careful with followups, please, am sending this to multiple lists. ---rsk ----- Forwarded message ----- > ? From: Barry Leiba > ? To: imap5 at ietf.org, imapext at ietf.org, imap-protocol at u.washington.edu, imap-use at u.washington.edu > ? Date: Mon, 19 Nov 2012 19:44:51 -0500 > > Everyone here knows Mark Crispin -- or at least knows who he is: > Mark is the author of the original IMAP specification, and has taken it > through its different versions to the present IMAP4rev1. He's written > reference implementations of both server and client, and has been a > vocal participant on all the mailing lists I'm posting this to. > > I'm sad to have to report that Mark is now terminally ill, and is in > hospice care. > > For now, at least, I'm told that Mark is at least somewhat aware. If > anyone has brief well-wishing messages they'd like to send him, please > post them to the mailing list, and I'll forward them > to Mark's long-term companion, Annie. I will also post updates to that > list as I get them > > Barry Leiba > ----- End forwarded message ----- From owen at delong.com Mon Nov 26 21:14:35 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Nov 2012 13:14:35 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: Compulsion won't come from IPv6-only content. It will come from IPv6-only users. Any content/apps/service providers who fail to provide for this fact before we reach that point are making a bet-the-business gamble on the theory that NAT44(4...) will somehow scale well beyond what is likely IMHO. When we reach compulsion, it will not happen slowly or gracefully. We will have hit a wall with IPv4 and IPv4 will simply and suddenly stop growing. Likely in a rather graphic and unpleasant way because it will likely be when we hit some form of scaling limit on the NAT infrastructure where it suddenly keels over and IPv4 only users are down for a series of outages while everyone scrambles to remove load from the IPv4 network in order to get it running again. The alternative is to recognize the coming problem, deploy IPv6 proactively to content/apps/services and then wait for ISPs and end-users to catch up and begin using those IPv6 capabilities. Owen On Nov 26, 2012, at 06:25 , Damian Menscher wrote: > On Mon, Nov 26, 2012 at 5:53 AM, Dobbins, Roland wrote: > >> Again, where're the compelling IPv6-only content/apps/services? >> > > To answer your rhetorical question, http://www.kame.net/ has a dancing > kame. To my knowledge, that's the most compelling IPv6-only content. > Unsurprisingly, this does not drive user adoption, and major sites won't > add IPv6-only content while a significant fraction of users are v4-only. > > Stalemate. > > Damian From jmaimon at ttec.com Mon Nov 26 21:52:25 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 26 Nov 2012 16:52:25 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> Message-ID: <50B3E499.7030302@ttec.com> Owen DeLong wrote: > > less than 60% of the internet will still be IPv4 at that time. Do you mean "IPv4" or "IPv4 Only"? Because unless the remaining percentage of IPv4 is noticeably less usable, it will still not incur any user demand, and IPv6 is still a cost mitigation strategy, and unless you wish to give up on connecting your users to that 40% you still need CGN, 644, what have you. Joe From bill at herrin.us Mon Nov 26 22:36:06 2012 From: bill at herrin.us (William Herrin) Date: Mon, 26 Nov 2012 17:36:06 -0500 Subject: Adding GPS location to IPv6 header In-Reply-To: <20121126152043.GD9750@leitl.org> References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B38334.4060402@gmail.com> <20121126152043.GD9750@leitl.org> Message-ID: On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl wrote: > On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: >> Just for redundancy's sake: No, L3 is **not** the place for this kind of >> information. L3 is supposed to be simple, easy to implement, fast to > > I agree. You need to put it into L2, and the core usage would > be for wireless meshes. Consider cases like Serval or cjdns, > which run on Android headsets and equivalent embeddeds. > Technically you wouldn't need GPS everywhere if you could > do ~m scale time domain reflectometry in free space. > It is possible to build a local contiguous map via > mutual time of flight triangulation (actually, just visibility > gives you a very good hint). Actually, I think you just articulated the first use for Ammar's idea that's not either wrong, absurd on its face or obviously better handled at a different location within the protocol stack. Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them. By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location. There are some assumptions in this model which are problematic. Key ones are: 1. Only valid as an interior gateway protocol (IGP). Geographic routing has been proven false for an EGP because it induces traffic to cross links for which neither source nor destination has permitted access. 2. Requires the application at the landed end to copy the IP option information into the outbound packets as well. This behavior is not presently guaranteed. 3. Assumes that the device will originate communication, receiving only replies from the landed end, or will use some intermediary to communicate current geographic information if inbound origination is required. At any rate, I think that discussion of adding a geographic option header to IPv6 should be tied up in the discussion of a routing protocol which critically depends on its presence and can't reasonably be built another way. Otherwise when a needful use case finally comes along, you'll discover that the option's rules of operation don't adequately enable it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From chk at pobox.com Mon Nov 26 22:46:33 2012 From: chk at pobox.com (Harald Koch) Date: Mon, 26 Nov 2012 17:46:33 -0500 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B38334.4060402@gmail.com> <20121126152043.GD9750@leitl.org> Message-ID: This also naively assumes that wireless network topology correlates with geographic location. Any radio engineer (or cell phone user) can explain why that doesn't work. On 26 November 2012 17:36, William Herrin wrote: > On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl wrote: > > On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: > >> Just for redundancy's sake: No, L3 is **not** the place for this kind of > >> information. L3 is supposed to be simple, easy to implement, fast to > > > > I agree. You need to put it into L2, and the core usage would > > be for wireless meshes. Consider cases like Serval or cjdns, > > which run on Android headsets and equivalent embeddeds. > > Technically you wouldn't need GPS everywhere if you could > > do ~m scale time domain reflectometry in free space. > > It is possible to build a local contiguous map via > > mutual time of flight triangulation (actually, just visibility > > gives you a very good hint). > > Actually, I think you just articulated the first use for Ammar's idea > that's not either wrong, absurd on its face or obviously better > handled at a different location within the protocol stack. > > Suppose you have a large single-owner mesh network, such as a folks > walking around with cell phones. If you want them to have a stable > layer 3 address (and you do) then you're handling what amounts to /128 > routes for tens of millions of devices. If you can guarantee that any > packet *to* that address also contains a rough geographic location > then you can discard any routes internally once they're more than a > short geographic distance from the origin and route on the geography > until you're close enough to find a specific /128 route. Tens of > millions of routes is no problem if no single router needs to know > more than a few thousand of them. > > By putting geographic location at layer 3, you're also handling it end > to end which means you don't need a stateful border device to track > the current location of all of those /128 routes. The device itself > doesn't need to add location if it doesn't have the data; it's good > enough for the receiving tower to attach a rough location. > > There are some assumptions in this model which are problematic. Key ones > are: > > 1. Only valid as an interior gateway protocol (IGP). Geographic > routing has been proven false for an EGP because it induces traffic to > cross links for which neither source nor destination has permitted > access. > > 2. Requires the application at the landed end to copy the IP option > information into the outbound packets as well. This behavior is not > presently guaranteed. > > 3. Assumes that the device will originate communication, receiving > only replies from the landed end, or will use some intermediary to > communicate current geographic information if inbound origination is > required. > > > At any rate, I think that discussion of adding a geographic option > header to IPv6 should be tied up in the discussion of a routing > protocol which critically depends on its presence and can't reasonably > be built another way. Otherwise when a needful use case finally comes > along, you'll discover that the option's rules of operation don't > adequately enable it. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From george.herbert at gmail.com Mon Nov 26 22:51:57 2012 From: george.herbert at gmail.com (George Herbert) Date: Mon, 26 Nov 2012 14:51:57 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B38334.4060402@gmail.com> <20121126152043.GD9750@leitl.org> Message-ID: The utility of this is somewhat moderated by limited geographical mobility while a phone's active in a single session. One rarely drives from San Francisco to LA typing all the way on their smartphone data connection, for example. To the extent that you may apply IP ranges to wider geographical areas, and limit the search space to a few % of the total, beyond which devices get a new address pushed as they travel, this is entirely manageable without the new header. Some services dislike the endpoint renumbering like that, and some connections go kerfluey, but most web based activities handle the endpoint getting a new IP just fine; this is what cookies are for. Your SSH connections will remind you that you should be using screen, or not type and drive. But the CHP and road hazards will already do that. Eventually being allowed to use air-to-ground cell data on airliners will be slightly worse, but again, most protocols shrug at this problem. -george On Mon, Nov 26, 2012 at 2:36 PM, William Herrin wrote: > On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl wrote: >> On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: >>> Just for redundancy's sake: No, L3 is **not** the place for this kind of >>> information. L3 is supposed to be simple, easy to implement, fast to >> >> I agree. You need to put it into L2, and the core usage would >> be for wireless meshes. Consider cases like Serval or cjdns, >> which run on Android headsets and equivalent embeddeds. >> Technically you wouldn't need GPS everywhere if you could >> do ~m scale time domain reflectometry in free space. >> It is possible to build a local contiguous map via >> mutual time of flight triangulation (actually, just visibility >> gives you a very good hint). > > Actually, I think you just articulated the first use for Ammar's idea > that's not either wrong, absurd on its face or obviously better > handled at a different location within the protocol stack. > > Suppose you have a large single-owner mesh network, such as a folks > walking around with cell phones. If you want them to have a stable > layer 3 address (and you do) then you're handling what amounts to /128 > routes for tens of millions of devices. If you can guarantee that any > packet *to* that address also contains a rough geographic location > then you can discard any routes internally once they're more than a > short geographic distance from the origin and route on the geography > until you're close enough to find a specific /128 route. Tens of > millions of routes is no problem if no single router needs to know > more than a few thousand of them. > > By putting geographic location at layer 3, you're also handling it end > to end which means you don't need a stateful border device to track > the current location of all of those /128 routes. The device itself > doesn't need to add location if it doesn't have the data; it's good > enough for the receiving tower to attach a rough location. > > There are some assumptions in this model which are problematic. Key ones are: > > 1. Only valid as an interior gateway protocol (IGP). Geographic > routing has been proven false for an EGP because it induces traffic to > cross links for which neither source nor destination has permitted > access. > > 2. Requires the application at the landed end to copy the IP option > information into the outbound packets as well. This behavior is not > presently guaranteed. > > 3. Assumes that the device will originate communication, receiving > only replies from the landed end, or will use some intermediary to > communicate current geographic information if inbound origination is > required. > > > At any rate, I think that discussion of adding a geographic option > header to IPv6 should be tied up in the discussion of a routing > protocol which critically depends on its presence and can't reasonably > be built another way. Otherwise when a needful use case finally comes > along, you'll discover that the option's rules of operation don't > adequately enable it. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- -george william herbert george.herbert at gmail.com From rdobbins at arbor.net Mon Nov 26 23:02:08 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 26 Nov 2012 23:02:08 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> Message-ID: <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote: > If you don't think that the need to sustain the growth in the number of devices attached to the network (never mind the number of things causing that rate to accelerate[1]) makes IPv6 inevitable at this point, you really aren't paying attention. What people ought to do and what they actually do are often quite different things. Again, all the attention being lavished upon CGNs and 444 and whatnot are quite interesting indicators of perceived priorities. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Nov 26 23:05:45 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 26 Nov 2012 23:05:45 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: <2F92F257-4AFF-4025-8AC3-5B22BF29027E@arbor.net> On Nov 27, 2012, at 12:15 AM, Cameron Byrne wrote: > NAT is bad. I agree wholeheartedly with this sentiment. I'm unsure whether or not this is the prevalent view amongst those who control the pursestrings within network operators, however. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From eugen at leitl.org Mon Nov 26 23:10:11 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 27 Nov 2012 00:10:11 +0100 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B38334.4060402@gmail.com> <20121126152043.GD9750@leitl.org> Message-ID: <20121126231011.GD9750@leitl.org> On Mon, Nov 26, 2012 at 05:46:33PM -0500, Harald Koch wrote: > This also naively assumes that wireless network topology correlates with > geographic location. Any radio engineer (or cell phone user) can explain > why that doesn't work. Serval has about 200 m line of sight range. In general LoS visibility e.g. with pole-mounted directional Ubiquity gear is always as the crow flies. From rdobbins at arbor.net Mon Nov 26 23:10:29 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 26 Nov 2012 23:10:29 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> Message-ID: <922F1ABF-7A2B-43CF-97DB-C0A859556A3F@arbor.net> On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote: > CGN does not scale and cannot scale. At best, it's a hack that might allow us to cope with a few years of transition while there are still devices in homes that are IPv4-only, but it certainly doesn't reduce or remove the imperative. I agree wholeheartedly, but I'm unsure whether or not this view is held by those who control spending and prioritization within most, or even many, ISPs. Mobility (and everything is inexorably becoming mobile) is an obvious place where IPv6 makes a lot of sense, for example. But native IPv6 on one's own access networks and then gatewaying/proxying to IPv4 for actual 'Internet' connectivity seems to be a significant direction. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Nov 26 23:18:13 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 26 Nov 2012 23:18:13 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <010101cdcbfc$dab478b0$901d6a10$@tndh.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> Message-ID: <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> On Nov 27, 2012, at 12:38 AM, Tony Hain wrote: > Unfortunately most people that actually deploy and support applications can't make the math come out right when the access providers don't provide a > path to 99% of the paying customers, then do just about everything they can to hobble bypass approaches. AFAICT, most people who actually develop, deploy, and support applications don't do the math at all. It isn't an issue of perceived importance within their worldviews. In fact, it isn't an issue of which most of them are even peripherally aware. > The overall system includes the perspective of app developers, not just BGP knob twisters, so the point of having a widespread api base is critical to > making progress. Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases? How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? Maybe they're hiding in plain sight. But I don't think so. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bill at herrin.us Mon Nov 26 23:45:23 2012 From: bill at herrin.us (William Herrin) Date: Mon, 26 Nov 2012 18:45:23 -0500 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B38334.4060402@gmail.com> <20121126152043.GD9750@leitl.org> Message-ID: On Mon, Nov 26, 2012 at 5:46 PM, Harald Koch wrote: > On 26 November 2012 17:36, William Herrin wrote: >> Suppose you have a large single-owner mesh network, such as a folks >> walking around with cell phones. If you want them to have a stable >> layer 3 address (and you do) then you're handling what amounts to /128 >> routes for tens of millions of devices. If you can guarantee that any >> packet *to* that address also contains a rough geographic location >> then you can discard any routes internally once they're more than a >> short geographic distance from the origin and route on the geography >> until you're close enough to find a specific /128 route. Tens of >> millions of routes is no problem if no single router needs to know >> more than a few thousand of them. >> >> By putting geographic location at layer 3, you're also handling it end >> to end which means you don't need a stateful border device to track >> the current location of all of those /128 routes. The device itself >> doesn't need to add location if it doesn't have the data; it's good >> enough for the receiving tower to attach a rough location. > This also naively assumes that wireless network topology correlates with > geographic location. Any radio engineer (or cell phone user) can explain > why that doesn't work. No. It assumes that the /128 route propagates far enough that every router (read: radio tower) operated by the service provider within the rough geographic locality has that route so that wherever the packet lands in the general area, it can make its way to the origin router currently talking to the device. It makes no assumptions about the particular path or paths between those two routers which could be terrestrial radio, satellite, wired or even a VPN across who knows what Internet path. It does set a requirement on the network architecture that at least one such path must exist: network partitions appear deadly to this architecture. I'm not saying this is a good idea. I'm just saying it's a legitimate topic for research and investigation which, if it shows any promise, would support the addition of a geolocation option header to IPv6's layer 3. By contrast, Ammar's other rationale for why to put it there (common interest at layer 7) aren't legitimate reasons for adding data to layer 3. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mtcc.com Mon Nov 26 23:56:13 2012 From: mike at mtcc.com (Michael Thomas) Date: Mon, 26 Nov 2012 15:56:13 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> Message-ID: <50B4019D.9080807@mtcc.com> On 11/26/2012 03:18 PM, Dobbins, Roland wrote: > > Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases? I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6. I'm all for bagging on those two, but it seems pretty unjustified here. > > How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? > > Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? Er, uh, huh? v6 has been available forever on the usual suspect host operating systems, and most server side apps don't need to do much to support lighting v6 support up that I can think of. I turned it on and it was pretty much a big ho-hum, cool it works. Mike From john at razorservers.com Mon Nov 26 22:11:14 2012 From: john at razorservers.com (John Zettlemoyer) Date: Mon, 26 Nov 2012 17:11:14 -0500 Subject: Cloudmark Message-ID: Hi, Could someone from Cloudmark please contact me off list. I've been trying to get someone from sales to call me back for 3 weeks with no response. Thanks John Zettlemoyer From cabo at tzi.org Tue Nov 27 00:12:33 2012 From: cabo at tzi.org (Carsten Bormann) Date: Tue, 27 Nov 2012 01:12:33 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: <9138A820-D5E4-4BEF-892E-48E1BCEB08DA@tzi.org> On Nov 26, 2012, at 14:53, "Dobbins, Roland" wrote: > It is significant because Why*) do you believe it is important to waste everybody's time with these kinds of arguments? We have seen your kind of thinking. First, the Internet was never going to replace X.25/Frame Relay/leased lines and baling wire. Then you didn't need a web presence. Then it wasn't necessary to enable Web access out of the corporate networks. Then it wasn't necessary to accommodate user-owned equipment in enterprise networks. And so on, and so on. While these great arguments are going on in the board rooms, we are building out the technology. So it's there when you finally decide to shut up and give us the money. You are much better off using your energy to plan ahead for that and ease the transitions, instead of inventing scales of significance that somehow prove to yourself you can continue doing nothing. Gr??e, Carsten *) Well, I think I can guess the answer, so this is mostly a rhetorical question. The need for rationalizing one's own bad decisions is one of the most powerful ways to cloud critical thinking. From rdobbins at arbor.net Tue Nov 27 00:24:02 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 00:24:02 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B4019D.9080807@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> Message-ID: <147EB003-A853-4890-B3D7-8D2528EC8FB5@arbor.net> On Nov 27, 2012, at 6:56 AM, Michael Thomas wrote: > Er, uh, huh? v6 has been available forever on the usual suspect host operating systems, and most server side apps don't need to do much to support lighting > v6 support up that I can think of. Where are the *deployments*, though? And lighting up IPv6 within enterprises is not a trivial task. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From james.cutler at consultant.com Tue Nov 27 00:27:00 2012 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 26 Nov 2012 19:27:00 -0500 Subject: Fwd: Big day for IPv6 - 1% native penetration References: <50B4019D.9080807@mtcc.com> Message-ID: <8C09C556-6A59-4B46-84EC-61069ED309C5@consultant.com> On 11/26/2012 03:18 PM, Dobbins, Roland wrote: > > Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases? > > How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? > > Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? How much of a priority? I would say lots for Apple. Have you looked at the current Apple software? It pretty much "just works" on IPv6. IPv6 is on by default on end systems. Airport Extreme is listed as IPv6 compatible by, among other companies, Comcast. In Terminal, open an New Remote Connection to another Mac, do netstat -f inet6 and see that it is an IPv6 connection. Actually, it is more than a priority. It is pretty much a done deal. As for corporate IT departments, it depends on whether management is measured on monthly cash flow or by long term growth. I must note that many corporate IT departments have evolved from "No one gets fired for buying IBM." to "One might get fired for not buying Microsoft." This also automatically brings along IPv6 capabilities. Elsewhere it has been said that end users don't care about IPv6. Well, that is generally true. They also don't care about IPv4, DOCSIS 3, ATM, PPPOE, and lots of other technical acronyms. What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family. To meet these expectations in a long term cost-effective manner, it behooves us network and content providers to remove all IPv4-forced hacks impeding easy end-system to end-system connections like all those 'wonderful' variants of NAT and artificially high pricing for IPv6. When the marketing folks begins to treat IPv6 as a sales enabler rather than a fanciful cost item, then we may see accelerated deployment of IPv6 alongside IPv4. From mike at mtcc.com Tue Nov 27 00:35:03 2012 From: mike at mtcc.com (Michael Thomas) Date: Mon, 26 Nov 2012 16:35:03 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <147EB003-A853-4890-B3D7-8D2528EC8FB5@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <147EB003-A853-4890-B3D7-8D2528EC8FB5@arbor.net> Message-ID: <50B40AB7.4050809@mtcc.com> On 11/26/2012 04:24 PM, Dobbins, Roland wrote: > On Nov 27, 2012, at 6:56 AM, Michael Thomas wrote: > >> Er, uh, huh? v6 has been available forever on the usual suspect host operating systems, and most server side apps don't need to do much to support lighting >> v6 support up that I can think of. > Where are the *deployments*, though? Google and Facebook support ipv6. What more do we need? > > And lighting up IPv6 within enterprises is not a trivial task. > Not on the server side that I can see. It's a network problem first and foremost, and starts by having the excuse that they can't get v6 upstream from their ISP's. Mike From rdobbins at arbor.net Tue Nov 27 00:36:39 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 00:36:39 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <9138A820-D5E4-4BEF-892E-48E1BCEB08DA@tzi.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <9138A820-D5E4-4BEF-892E-48E1BCEB08DA@tzi.org> Message-ID: On Nov 27, 2012, at 7:12 AM, Carsten Bormann wrote: > We have seen your kind of thinking. You totally mischaracterize my 'kind of thinking'. My entire career arc has been that of a technological evangelist. Yes, I think there's a lot that's wrong with IPv6, but it appears that it's the only path forward we have, for the foreseeable future. It is very interesting that merely expressing skepticism regarding the rate, breadth, and depth of IPv6 deployment, and floating the proposition that some 'killer app' is needed in order to stimulate IPv6 deployment, is met with such over-the-top rhetoric and vitriol. > So it's there when you finally decide to shut up and give us the money. As a consumer, I currently don't have the choice of paying for native IPv6 connectivity because it simply isn't available in the part of the world where I reside. Which is the part of the world that everyone says should benefit the most from IPv6 - i.e., Asia - but is also a part of the world which has practically zero consumer-grade IPv6 connectivity options, and precious few commercial-grade ones. > You are much better off using your energy to plan ahead for that and ease the transitions, instead of inventing scales of significance that somehow prove to yourself you can continue doing nothing. Why do you think I am 'doing nothing'? When I was at Cisco, I relentlessly pushed for IPv4/IPv6 feature and performance parity, especially with regards to security and resiliency (much good that it did me, heh). I continue to advocate this stance. I am trying to point out that there are a lot of barriers to the near-universal deployment, or at least availability, of end-to-end IPv6 connectivity. It seems to me that many folks are overly optimistic in this regard, and that there must be some kind of incentive for ordinary users to push for IPv6 connectivity in order for it to achieve critical mass. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Tue Nov 27 00:38:25 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 00:38:25 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B40AB7.4050809@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <147EB003-A853-4890-B3D7-8D2528EC8FB5@arbor.net> <50B40AB7.4050809@mtcc.com> Message-ID: On Nov 27, 2012, at 7:35 AM, Michael Thomas wrote: > Not on the server side that I can see. It's a network problem first and foremost, and starts by having the excuse that they can't get v6 upstream from their ISP's. It's hugely problematic to accomplish internally, never mind for external connectivity. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Tue Nov 27 00:47:02 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 00:47:02 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <8C09C556-6A59-4B46-84EC-61069ED309C5@consultant.com> References: <50B4019D.9080807@mtcc.com> <8C09C556-6A59-4B46-84EC-61069ED309C5@consultant.com> Message-ID: On Nov 27, 2012, at 7:27 AM, Cutler James R wrote: > Have you looked at the current Apple software? It pretty much "just works" on IPv6. Yes, but it doesn't do or enable anything via IPv6 that it doesn't do or enable via IPv4. > This also automatically brings along IPv6 capabilities. Capabilities <> deployment. Again, the most energy almost all enterprise IT departments are putting into IPv6 is to include an undefined 'IPv6-capable' checkbox on RFPs. That's it. > What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family. And it is these 'killer apps' which have driven the global deployment of IPv4 and the growth of the modern commercial IPv4-based public Internet, as well as the near-universal adoption of IPv4 transport within private networks. The huge economic benefits of mobile voice and data connectivity are the reasons behind its spectacular growth and increasing ubiquity. Mobile voice and data allow people to do things that they simply couldn't do before, and to do things which they didn't even view as possibilities before. My contention is that in order for IPv6 to become widely deployed within any foreseeable time-frame, it may well prove that there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6 in order to provide the requisite economic stimulus. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mike at mtcc.com Tue Nov 27 00:53:55 2012 From: mike at mtcc.com (Michael Thomas) Date: Mon, 26 Nov 2012 16:53:55 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <147EB003-A853-4890-B3D7-8D2528EC8FB5@arbor.net> <50B40AB7.4050809@mtcc.com> Message-ID: <50B40F23.6080900@mtcc.com> On 11/26/2012 04:38 PM, Dobbins, Roland wrote: > On Nov 27, 2012, at 7:35 AM, Michael Thomas wrote: > >> Not on the server side that I can see. It's a network problem first and foremost, and starts by having the excuse that they can't get v6 upstream from their ISP's. > It's hugely problematic to accomplish internally, never mind for external connectivity. > But not because servers and client devices don't support it; they do. Bag on where the problem actually is: the death spiral of network vendors, ISP's and IT departments not wanting to commit and blaming each other. I primarily fault ISP's because they are, you know, the backbone. If they don't commit, the game of chicken continues. Mike From owen at delong.com Tue Nov 27 00:53:46 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Nov 2012 16:53:46 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B38334.4060402@gmail.com> <20121126152043.GD9750@leitl.org> Message-ID: On Nov 26, 2012, at 14:51 , George Herbert wrote: > The utility of this is somewhat moderated by limited geographical > mobility while a phone's active in a single session. One rarely > drives from San Francisco to LA typing all the way on their smartphone > data connection, for example. > That's true to a limited extent today. It's not likely to remain true. (No, it won't be the driver typing on their smartphone data connection, but it will be the busload or high-speed trainload of people typing, gaming, etc. all the way from SF to LA and/or other non-interactive data usages that are becoming more and more prevalent. Further, the speed of handoffs will have to get faster and the address stability area larger as that starts to include things like airplanes. Owen From rdobbins at arbor.net Tue Nov 27 01:01:14 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 01:01:14 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B40F23.6080900@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <147EB003-A853-4890-B3D7-8D2528EC8FB5@arbor.net> <50B40AB7.4050809@mtcc.com> <50B40F23.6080900@mtcc.com> Message-ID: <5C9262CC-BEE1-408C-88E5-1CFE1CF816CB@arbor.net> On Nov 27, 2012, at 7:53 AM, Michael Thomas wrote: > If they don't commit, the game of chicken continues. Right - so, what new capabilities/economies of scale/essential conveniences are made possible by IPv6 but not IPv4, pour encourager les autres? This is not a rhetorical question. I believe it is a very relevant question that most of those who have the most pecuniary interests in ubiquitous IPv6 deployment are not even considering. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From james.cutler at consultant.com Tue Nov 27 01:07:13 2012 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 26 Nov 2012 20:07:13 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50B4019D.9080807@mtcc.com> <8C09C556-6A59-4B46-84EC-61069ED309C5@consultant.com> Message-ID: <9A395128-2A61-4A17-85B1-17890D1ACC2C@consultant.com> On Nov 26, 2012, at 7:47 PM, "Dobbins, Roland" wrote: > On Nov 27, 2012, at 7:27 AM, Cutler James R wrote: > >> Have you looked at the current Apple software? It pretty much "just works" on IPv6. > > Yes, but it doesn't do or enable anything via IPv6 that it doesn't do or enable via IPv4. > >> This also automatically brings along IPv6 capabilities. > > Capabilities <> deployment. > > Again, the most energy almost all enterprise IT departments are putting into IPv6 is to include an undefined 'IPv6-capable' checkbox on RFPs. That's it. > >> What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family. > > And it is these 'killer apps' which have driven the global deployment of IPv4 and the growth of the modern commercial IPv4-based public Internet, as well as the near-universal adoption of IPv4 transport within private networks. > > The huge economic benefits of mobile voice and data connectivity are the reasons behind its spectacular growth and increasing ubiquity. Mobile voice and data allow people to do things that they simply couldn't do before, and to do things which they didn't even view as possibilities before. > > My contention is that in order for IPv6 to become widely deployed within any foreseeable time-frame, it may well prove that there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6 in order to provide the requisite economic stimulus. Well, at least you and I agree that IPv6 and IPv4 are simply Layer 3 protocols. Regarding "there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6", your viewpoint ignores the millions and millions of end users/systems which will join networks around the globe in the near future. Those content/services/applications will only be reachable via IPv6 because that is all that can be deployed without truly horrendous and costly mismanagement of IPv4 address space. From a longer-than-next-month business viewpoint, it is more cost effective to deploy IPv6 than to continue the crude IPv4 hacks previously mentioned. Please note that this does not imply instant turndown of existing IPv4. From george.herbert at gmail.com Tue Nov 27 01:13:56 2012 From: george.herbert at gmail.com (George Herbert) Date: Mon, 26 Nov 2012 17:13:56 -0800 Subject: Adding GPS location to IPv6 header In-Reply-To: References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B38334.4060402@gmail.com> <20121126152043.GD9750@leitl.org> Message-ID: On Mon, Nov 26, 2012 at 4:53 PM, Owen DeLong wrote: > > On Nov 26, 2012, at 14:51 , George Herbert wrote: > >> The utility of this is somewhat moderated by limited geographical >> mobility while a phone's active in a single session. One rarely >> drives from San Francisco to LA typing all the way on their smartphone >> data connection, for example. >> > > That's true to a limited extent today. > > It's not likely to remain true. > > (No, it won't be the driver typing on their smartphone data connection, but > it will be the busload or high-speed trainload of people typing, gaming, etc. > all the way from SF to LA and/or other non-interactive data usages that are > becoming more and more prevalent. > > Further, the speed of handoffs will have to get faster and the address stability > area larger as that starts to include things like airplanes. > > Owen Right, but GPS location in these scenarios is not helpful. Because the network provider has plenty of evidence you're on the move - your cell location starts hopping at significant speeds, it's kind of obvious. You can either handle this with L3/4 stuff - painfully, but one can establish a regional forwarder net which is a downwards-looking default in each region, to handle L3 traffic for nodes that went off the reservation. Or you can handle this at L5 or above, in which case this is not our problem per se; it's the device and consumer services' website or central services site, or P2P type protocols designers problem to handle IP address flips etc. Which, frankly, already is being handled (most mobile users, anyone who uses WiFi in multiple locations + a phone data connection, etc). It's not totally seamless, but it works, and it's good enough. In either case, knowing the GPS location of the phone or device is not relevant to handling the problem or detecting it, beyond what the cell site data gives you naturally. As you already have to support devices hopping IPs, adding network foo (with evident significant downsides) which does not make that hopping IPs problem go away seems like it's a no-answer. -- -george william herbert george.herbert at gmail.com From owen at delong.com Tue Nov 27 01:15:00 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Nov 2012 17:15:00 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <922F1ABF-7A2B-43CF-97DB-C0A859556A3F@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <922F1ABF-7A2B-43CF-97DB-C0A859556A3F@arbor.net> Message-ID: <1008028D-E7DF-4688-9861-1ECE5FCC93EE@delong.com> On Nov 26, 2012, at 15:10 , "Dobbins, Roland" wrote: > > On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote: > >> CGN does not scale and cannot scale. At best, it's a hack that might allow us to cope with a few years of transition while there are still devices in homes that are IPv4-only, but it certainly doesn't reduce or remove the imperative. > > I agree wholeheartedly, but I'm unsure whether or not this view is held by those who control spending and prioritization within most, or even many, ISPs. > > Mobility (and everything is inexorably becoming mobile) is an obvious place where IPv6 makes a lot of sense, for example. But native IPv6 on one's own access networks and then gatewaying/proxying to IPv4 for actual 'Internet' connectivity seems to be a significant direction. Interesting. All the IPv6 capable carriers I talk to are only gatewaying/proxying to IPv4 for things unreachable via IPv6. If you've got an IPv6 capable cell phone on an IPv6 capable mobile network, I doubt that you get to google through an IPv4 proxy. Owen From rdobbins at arbor.net Tue Nov 27 01:20:39 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 01:20:39 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <1008028D-E7DF-4688-9861-1ECE5FCC93EE@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <922F1ABF-7A2B-43CF-97DB-C0A859556A3F@arbor.net> <1008028D-E7DF-4688-9861-1ECE5FCC93EE@delong.com> Message-ID: <30E54F0A-0E79-4608-9459-0D2C2F1840CB@arbor.net> On Nov 27, 2012, at 8:15 AM, Owen DeLong wrote: > Interesting. All the IPv6 capable carriers I talk to are only gatewaying/proxying to IPv4 for things unreachable via IPv6. Which is pretty much everything on the Internet. > If you've got an IPv6 capable cell phone on an IPv6 capable mobile network, I doubt that you get to google through an IPv4 proxy. While I would be very surprised if you didn't, heh. Also, just how widely-deployed is IPv6 now for mobile networks? It would be very edifying to get some data around this . . . ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Tue Nov 27 01:25:53 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 01:25:53 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <9A395128-2A61-4A17-85B1-17890D1ACC2C@consultant.com> References: <50B4019D.9080807@mtcc.com> <8C09C556-6A59-4B46-84EC-61069ED309C5@consultant.com> <9A395128-2A61-4A17-85B1-17890D1ACC2C@consultant.com> Message-ID: On Nov 27, 2012, at 8:07 AM, Cutler James R wrote: > Those content/services/applications will only be reachable via IPv6 because that is all that can be deployed without truly horrendous and costly mismanagement of IPv4 address space. Our views differ in that it is my belief that said truly horrendous and costly mismanagement of IPv4 address space is the norm now and will continue to be the norm for the foreseeable future, absent some positive economic stimulus to do otherwise. > From a longer-than-next-month business viewpoint, it is more cost effective to deploy IPv6 than to continue the crude IPv4 hacks previously mentioned. When considering the entire value chain of Internet connectivity, I'm not sure if that's a true statement, or that it will become a true statement in the foreseeable future. > Please note that this does not imply instant turndown of existing IPv4. Which is part of the problem. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mysidia at gmail.com Tue Nov 27 01:33:02 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 26 Nov 2012 19:33:02 -0600 Subject: Adding GPS location to IPv6 header In-Reply-To: <50B3122E.70008@yahoo.com> References: <50b20f8b.0448420a.2367.ffffc880@mx.google.com> <50B3122E.70008@yahoo.com> Message-ID: On 11/26/12, Alex wrote: > This would be great for troubleshooting things...I agree, but other than > that it would create a whole new plethora of privacy concerns. Just about every new technology, IP itself included has privacy concerns, related to it; which is really just a fancy new name for security confidentiality concerns, regarding WHO is doing what things on the network. That doesn't mean you blacklist those technologies.... In fact, in some cases _identification_ of network nodes is a very good thing. I would like very much for spammers to be identifiable, even at the cost of some so-called "privacy" (not that embedding IP location data helps with that).... Heck, HTTPS has privacy concerns, because it requires a certificate, containing personal details of the server to operate. I suppose it would be rather interesting if the certificate contained GPS details as well, if end hosts' IP stacks were required to verify the GPS data is either accurate or not present, and SSL clients were expected to validate that the details in the IP packets matched, and if a list of GPS positions was declared as a critical X509 extension. Then a third-party hosting provider would not be able to be used to spoof a HTTPS site (without the intruder gaining root access, in order to spoof IP packets). The existence of privacy concerns, does not mean you hesitate to implement a protocol in any way, shape or form. Privacy concerns,mean you as a user of that technology, pull out your handy dandy risk calculator, and weight the details carefully consider, what the probability and impact of the various risks actually are -- what bad things can actually happen, if the detail X is exposed, and what (if any) mitigations you choose for your particular scenario. Which will for end users typically involve setting a local policy such as: o Don't turn on the "Populate Packet headers with Location data" Or: o Don't stamp packets with location data, except to trusted hosts, when stamped packets are sent with headers encrypted over VPN in tunnel mode Or: o Introduce sufficient error, that the GPS data does not significantly compromise location -- -JH From security at hostmatters.com Tue Nov 27 03:59:45 2012 From: security at hostmatters.com (A Howard) Date: Mon, 26 Nov 2012 22:59:45 -0500 Subject: AT&T postmaster/mail admin Message-ID: <20121126225945.19546c5c2uv6mylt@hostmatters.com> If there are eyeballs from AT&T's postmaster group here, would you please contact me off list regarding a rather major blocking issue. Thanks. Regards, Annette From swmike at swm.pp.se Tue Nov 27 04:57:42 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 27 Nov 2012 05:57:42 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> Message-ID: On Mon, 26 Nov 2012, Dobbins, Roland wrote: > Again, all the attention being lavished upon CGNs and 444 and whatnot > are quite interesting indicators of perceived priorities. The problem is that CGN and NAT444 works with todays devices, whereas IPv6 does not (thinking mobile devices and residential CPEs). IPv6 is not today a viable alternative to CGN, one has to do both for a while before hopefully devices can do IPv6-only access and one can then have a centrally placed NAT64 (or similar) gateway. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Tue Nov 27 04:59:37 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 27 Nov 2012 05:59:37 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B4019D.9080807@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> Message-ID: On Mon, 26 Nov 2012, Michael Thomas wrote: > I don't see either Apple or Microsoft as being the hindrance. In fact, > both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. > But I'm pretty sure that both iPhones and Androids are pretty happy > about being in v6 land since I see them showing up in my logs all the > time, for the few providers that have lit up v6. Not on the mobile side. Wifi yes, mobile no. > I'm all for bagging on those two, but it seems pretty unjustified here. What they need to start doing is testing Apps for IPv6 only access capabilitity. This doesn't work today, Apps like Waze, Spotify and others do not work on IPv6 only access. -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Tue Nov 27 05:07:48 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 05:07:48 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> Message-ID: On Nov 27, 2012, at 11:57 AM, Mikael Abrahamsson wrote: > The problem is that CGN and NAT444 works with todays devices, whereas IPv6 does not (thinking mobile devices and residential CPEs). Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh. It sort of reminds me of how artificial intelligence has been only 10 years away for the last 60 years or so. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From swmike at swm.pp.se Tue Nov 27 05:32:27 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 27 Nov 2012 06:32:27 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> Message-ID: On Tue, 27 Nov 2012, Dobbins, Roland wrote: > Yet everyone (except you) insist that it does work with everything, and > that all this CGN and 444 stuff and 644 stuff isn't necessary, and that > I'm a fool for doubting all these (to me) wildly overoptimistic > assertions about the coming ubiquity of native IPv6, end-to-end, heh. Dual stack works with "everything". IPv6 only access does not (with 464XLAT it might). However, people are complaining that operators are focusing more on CGN and NAT44(4) than they are on IPv6. Which I can understand, but I believe we're getting closer to getting out of the dead lock. My hope is that 2013 is going to be the year we're going to see widespread IPv6 (dual stack) adoption on mobile devices outside of the US. It's looking good so far. People are advocating dual stack now (at least that's what I do), for a future goal of IPv6 only. The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done. -- Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Tue Nov 27 05:34:59 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 27 Nov 2012 16:34:59 +1100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: Your message of "Tue, 27 Nov 2012 05:59:37 BST." References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> Message-ID: <20121127053459.AA20C2C3248D@drugs.dv.isc.org> In message , Mikael Abrah amsson writes: > On Mon, 26 Nov 2012, Michael Thomas wrote: > > > I don't see either Apple or Microsoft as being the hindrance. In fact, > > both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. > > But I'm pretty sure that both iPhones and Androids are pretty happy > > about being in v6 land since I see them showing up in my logs all the > > time, for the few providers that have lit up v6. > > Not on the mobile side. Wifi yes, mobile no. > > > I'm all for bagging on those two, but it seems pretty unjustified here. > > What they need to start doing is testing Apps for IPv6 only access > capabilitity. This doesn't work today, Apps like Waze, Spotify and others > do not work on IPv6 only access. One could just start adding negative reviews to any product that doesn't work in a IPv6 only network. > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bmanning at vacation.karoshi.com Tue Nov 27 05:52:30 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 27 Nov 2012 05:52:30 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> Message-ID: <20121127055230.GA27197@vacation.karoshi.com.> 2013 - the year of the NAT. (the only way a single stacked address family is going to be able to talk to a single stacked member of a different address family... and unless we start agressive reuse of v4, this will happen sooner than later (dual-stack is rate limited to the smaller of the address families -UNLESS- NAT makes reuse possible... :) But since NAT is going to be required -anyway-.... 2013 will be the year of the NAT. /bill On Tue, Nov 27, 2012 at 06:32:27AM +0100, Mikael Abrahamsson wrote: > On Tue, 27 Nov 2012, Dobbins, Roland wrote: > > >Yet everyone (except you) insist that it does work with everything, and > >that all this CGN and 444 stuff and 644 stuff isn't necessary, and that > >I'm a fool for doubting all these (to me) wildly overoptimistic > >assertions about the coming ubiquity of native IPv6, end-to-end, heh. > > Dual stack works with "everything". IPv6 only access does not (with > 464XLAT it might). However, people are complaining that operators are > focusing more on CGN and NAT44(4) than they are on IPv6. Which I can > understand, but I believe we're getting closer to getting out of the dead > lock. My hope is that 2013 is going to be the year we're going to see > widespread IPv6 (dual stack) adoption on mobile devices outside of the US. > It's looking good so far. > > People are advocating dual stack now (at least that's what I do), for a > future goal of IPv6 only. > > The main problem with IPv6 only is that most app developers (most > programmers totally) do not really have access to this, so no testing is > being done. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Tue Nov 27 05:56:32 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 27 Nov 2012 16:56:32 +1100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: Your message of "Tue, 27 Nov 2012 06:32:27 BST." References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> Message-ID: <20121127055632.8F2E12C326FF@drugs.dv.isc.org> In message , Mikael Abrah amsson writes: > On Tue, 27 Nov 2012, Dobbins, Roland wrote: > > > Yet everyone (except you) insist that it does work with everything, and > > that all this CGN and 444 stuff and 644 stuff isn't necessary, and that > > I'm a fool for doubting all these (to me) wildly overoptimistic > > assertions about the coming ubiquity of native IPv6, end-to-end, heh. > > Dual stack works with "everything". IPv6 only access does not (with > 464XLAT it might). However, people are complaining that operators are > focusing more on CGN and NAT44(4) than they are on IPv6. Which I can > understand, but I believe we're getting closer to getting out of the dead > lock. My hope is that 2013 is going to be the year we're going to see > widespread IPv6 (dual stack) adoption on mobile devices outside of the US. > It's looking good so far. > > People are advocating dual stack now (at least that's what I do), for a > future goal of IPv6 only. > > The main problem with IPv6 only is that most app developers (most > programmers totally) do not really have access to this, so no testing is > being done. IPv6 only is easy to setup if you already have dual stack. On my Mac it is "System Preferences", "Network Preferences", "Advanced", "TCP/IP", "IPv4 -> Off" then reboot to clear any lingering IPv4 references. It's about as easy on a Linux and a *BSD box. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From eugen at leitl.org Tue Nov 27 07:12:47 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 27 Nov 2012 08:12:47 +0100 Subject: [serval-project-dev] Re: Adding GPS location to IPv6 header Message-ID: <20121127071246.GH9750@leitl.org> ----- Forwarded message from Jeremy Lakeman ----- From: Jeremy Lakeman Date: Tue, 27 Nov 2012 11:10:26 +1030 To: serval-project-developers at googlegroups.com Subject: Re: [serval-project-dev] Re: Adding GPS location to IPv6 header Reply-To: serval-project-developers at googlegroups.com Allocate an IPv6 private network range using a scheme like this; http://tools.ietf.org/html/draft-hain-ipv6-geo-addr-01 Probably with around 36 bits (100m) of precision, leaving the rest of the /64 to flag that it's private and geographically based. Internet gateways have their own "real" /64. Internet traffic would be routed to the correct gateway based on the network of the source address. If each device uses the same 64bit host id on each network. Local mesh route calculations can be based on a single main address per device, with an additional routing entry added for each network we believe that host should have. A protocol like SCTP will also allow both parties to change networks without needing to re-establish links. Then the biggest scalability problem for routing packets world-wide to an individual is a directory service for publishing and resolving current network locations. On Tue, Nov 27, 2012 at 9:40 AM, Eugen Leitl wrote: > ----- Forwarded message from George Herbert ----- > > From: George Herbert > Date: Mon, 26 Nov 2012 14:51:57 -0800 > To: William Herrin > Cc: Eugen Leitl , nanog at nanog.org > Subject: Re: Adding GPS location to IPv6 header > > The utility of this is somewhat moderated by limited geographical > mobility while a phone's active in a single session. One rarely > drives from San Francisco to LA typing all the way on their smartphone > data connection, for example. > > To the extent that you may apply IP ranges to wider geographical > areas, and limit the search space to a few % of the total, beyond > which devices get a new address pushed as they travel, this is > entirely manageable without the new header. > > Some services dislike the endpoint renumbering like that, and some > connections go kerfluey, but most web based activities handle the > endpoint getting a new IP just fine; this is what cookies are for. > Your SSH connections will remind you that you should be using screen, > or not type and drive. But the CHP and road hazards will already do > that. > > Eventually being allowed to use air-to-ground cell data on airliners > will be slightly worse, but again, most protocols shrug at this > problem. > > > -george > > On Mon, Nov 26, 2012 at 2:36 PM, William Herrin wrote: >> On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl wrote: >>> On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: >>>> Just for redundancy's sake: No, L3 is **not** the place for this kind of >>>> information. L3 is supposed to be simple, easy to implement, fast to >>> >>> I agree. You need to put it into L2, and the core usage would >>> be for wireless meshes. Consider cases like Serval or cjdns, >>> which run on Android headsets and equivalent embeddeds. >>> Technically you wouldn't need GPS everywhere if you could >>> do ~m scale time domain reflectometry in free space. >>> It is possible to build a local contiguous map via >>> mutual time of flight triangulation (actually, just visibility >>> gives you a very good hint). >> >> Actually, I think you just articulated the first use for Ammar's idea >> that's not either wrong, absurd on its face or obviously better >> handled at a different location within the protocol stack. >> >> Suppose you have a large single-owner mesh network, such as a folks >> walking around with cell phones. If you want them to have a stable >> layer 3 address (and you do) then you're handling what amounts to /128 >> routes for tens of millions of devices. If you can guarantee that any >> packet *to* that address also contains a rough geographic location >> then you can discard any routes internally once they're more than a >> short geographic distance from the origin and route on the geography >> until you're close enough to find a specific /128 route. Tens of >> millions of routes is no problem if no single router needs to know >> more than a few thousand of them. >> >> By putting geographic location at layer 3, you're also handling it end >> to end which means you don't need a stateful border device to track >> the current location of all of those /128 routes. The device itself >> doesn't need to add location if it doesn't have the data; it's good >> enough for the receiving tower to attach a rough location. >> >> There are some assumptions in this model which are problematic. Key ones are: >> >> 1. Only valid as an interior gateway protocol (IGP). Geographic >> routing has been proven false for an EGP because it induces traffic to >> cross links for which neither source nor destination has permitted >> access. >> >> 2. Requires the application at the landed end to copy the IP option >> information into the outbound packets as well. This behavior is not >> presently guaranteed. >> >> 3. Assumes that the device will originate communication, receiving >> only replies from the landed end, or will use some intermediary to >> communicate current geographic information if inbound origination is >> required. >> >> >> At any rate, I think that discussion of adding a geographic option >> header to IPv6 should be tied up in the discussion of a routing >> protocol which critically depends on its presence and can't reasonably >> be built another way. Otherwise when a needful use case finally comes >> along, you'll discover that the option's rules of operation don't >> adequately enable it. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> > > > > -- > -george william herbert > george.herbert at gmail.com > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > -- > You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. > To post to this group, send email to serval-project-developers at googlegroups.com. > To unsubscribe from this group, send email to serval-project-developers+unsubscribe at googlegroups.com. > For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers at googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe at googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From mansaxel at besserwisser.org Tue Nov 27 07:29:23 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Tue, 27 Nov 2012 08:29:23 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> References: <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> Message-ID: <20121127072923.GA25469@besserwisser.org> Subject: Re: Big day for IPv6 - 1% native penetration Date: Mon, Nov 26, 2012 at 11:18:13PM +0000 Quoting Dobbins, Roland (rdobbins at arbor.net): > How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? I am -- in addition to running eBGP for my employer -- also the acting network strategist and proper IP networking evangelist at my employer. We have been buying v6 compatible gear and connections for four years now. We are configuring IPv6 on all backbone links and are carefully deploying v6 to workstation and server networks all over the enterprise. > Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? There are no v6-only deployments of SQL Server. The admins request and setup v4, the server requests and sets up v6, and the clients use whatever is in the DNS. The server will register in DNS so v6 has a fair chanche of getting chosen. > Maybe they're hiding in plain sight. But I don't think so. We discovered that the HUB/TRANSPORT nodes in the Exchange collective talked Link-local v6 to the MBOX nodes. Service discovery. Magic. The Exchange admins had no idea, but that probably was because they are good, obedient employees and use the mandated email client, which makes viewing headers something of a challenge. V6 will, given a few careful pushes, deploy itself. Slightly exaggerated, but that's how it is. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I love ROCK 'N ROLL! I memorized the all WORDS to "WIPE-OUT" in 1965!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From swmike at swm.pp.se Tue Nov 27 07:38:13 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 27 Nov 2012 08:38:13 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121127055632.8F2E12C326FF@drugs.dv.isc.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <20121127055632.8F2E12C326FF@drugs.dv.isc.org> Message-ID: On Tue, 27 Nov 2012, Mark Andrews wrote: >> The main problem with IPv6 only is that most app developers (most >> programmers totally) do not really have access to this, so no testing is >> being done. > > IPv6 only is easy to setup if you already have dual stack. > > On my Mac it is "System Preferences", "Network Preferences", > "Advanced", "TCP/IP", "IPv4 -> Off" then reboot to clear any lingering > IPv4 references. > > It's about as easy on a Linux and a *BSD box. Well, they don't really have access to dual stack either, so... -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Tue Nov 27 09:13:17 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 09:13:17 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121127072923.GA25469@besserwisser.org> References: <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <20121127072923.GA25469@besserwisser.org> Message-ID: <94365A8B-42D5-43CB-8DA5-1A38802A45A7@arbor.net> On Nov 27, 2012, at 2:29 PM, M?ns Nilsson wrote: > I am -- in addition to running eBGP for my employer -- also the acting network strategist and proper IP networking evangelist at my employer. Thereby demonstrating how far out of the mainstream your enterprise is, given that those roles generally don't exist even within the largest enterprises. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From randy at psg.com Tue Nov 27 10:20:25 2012 From: randy at psg.com (Randy Bush) Date: Tue, 27 Nov 2012 19:20:25 +0900 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: >> I disagree, i simply see an additional fee for IPv4 coming about. > And that in itself seems like it would make IPv6-reachable things a > lot more compelling. could be. but ... i am a consumer end user. i wish to keep my bill down. unless there is a means for the user to exercise a meaningful method of billable v4 use minimization, given that there is still v4-only content out there, there is no economic incentive. randy From randy at psg.com Tue Nov 27 10:26:12 2012 From: randy at psg.com (Randy Bush) Date: Tue, 27 Nov 2012 19:26:12 +0900 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> Message-ID: >> when the average consumer (real) broadband connection becomes v6 >> capable, about 40% of the traffic is instantly ipv6, thank you >> netflix, facebook, netflix, google, netflix, and netflix. > 'When', or 'if'? The creeping proliferation of CGNs and the like, > along with your example of TVs and oblique point about the sparsity of > IPv6-enabled content/services/applications, does not necessarily > support the conclusion that wholesale migration within the near- or > medium-terms is inevitable. sorry if the facts did not support your conclusion. they do support mine. big initial ipv6 traffic bump but long ipv4 tail. randy From rdobbins at arbor.net Tue Nov 27 10:32:02 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 10:32:02 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> Message-ID: <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> On Nov 27, 2012, at 5:26 PM, Randy Bush wrote: > sorry if the facts did not support your conclusion. they do support mine. Pointers to these facts would be greatly appreciated, especially as no one else seems to know where to find them. ;> > big initial ipv6 traffic bump This is what I question. > but long ipv4 tail. I agree with this one, of course. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From eugen at leitl.org Tue Nov 27 13:32:29 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 27 Nov 2012 14:32:29 +0100 Subject: Spanner: synchronizing the largest global database with GPSDO stratum 1 in every datacenter Message-ID: <20121127133229.GO9750@leitl.org> (GPSDO for local data center as stratum 1) http://www.wired.com/wiredenterprise/2012/11/google-spanner-time/all/ Exclusive: Inside Google Spanner, the Largest Single Database on Earth By Cade Metz 11.26.12 6:30 AM Each morning, when Andrew Fikes sat down at his desk inside Google headquarters in Mountain View, California, he turned on the ?VC? link to New York. VC is Google shorthand for video conference. Looking up at the screen on his desk, Fikes could see Wilson Hsieh sitting inside a Google office in Manhattan, and Hsieh could see him. They also ran VC links to a Google office in Kirkland, Washington, near Seattle. Their engineering team spanned three offices in three different parts of the country, but everyone could still chat and brainstorm and troubleshoot without a moment?s delay, and this is how Google built Spanner. ?You walk into our cubes, and we?ve got VC on ? all the time,? says Fikes, who joined Google in 2001 and now ranks among the company?s distinguished software engineers. ?We?ve been doing this for years. It lowers all the barriers to communication that you typically have.? ?As a distributed-systems developer, you?re taught from ? I want to say childhood ? not to trust time. What we did is find a way that we could trust time ? and understand what it meant to trust time.? ? Andrew Fikes The arrangement is only appropriate. Much like the engineering team that created it, Spanner is something that stretches across the globe while behaving as if it?s all in one place. Unveiled this fall after years of hints and rumors, it?s the first worldwide database worthy of the name ? a database designed to seamlessly operate across hundreds of data centers and millions of machines and trillions of rows of information. Spanner is a creation so large, some have trouble wrapping their heads around it. But the end result is easily explained: With Spanner, Google can offer a web service to a worldwide audience, but still ensure that something happening on the service in one part of the world doesn?t contradict what?s happening in another. Google?s new-age database is already part of the company?s online ad system ? the system that makes its millions ? and it could signal where the rest of the web is going. Google caused a stir when it published a research paper detailing Spanner in mid-September, and the buzz was palpable among the hard-core computer systems engineers when Wilson Hsieh presented the paper at a conference in Hollywood, California, a few weeks later. ?It?s definitely interesting,? says Raghu Murty, one of the chief engineers working on the massive software platform that underpins Facebook ? though he adds that Facebook has yet to explore the possibility of actually building something similar. Google?s web operation is significantly more complex than most, and it?s forced to build custom software that?s well beyond the scope of most online outfits. But as the web grows, its creations so often trickle down to the rest of the world. Before Spanner was revealed, many didn?t even think it was possible. Yes, we had ?NoSQL? databases capable of storing information across multiple data centers, but they couldn?t do so while keeping that information ?consistent? ? meaning that someone looking at the data on one side of the world sees the same thing as someone on the other side. The assumption was that consistency was barred by the inherent delays that come when sending information between data centers. But in building a database that was both global and consistent, Google?s Spanner engineers did something completely unexpected. They have a history of doing the unexpected. The team includes not only Fikes and Hsieh, who oversaw the development of BigTable, Google?s seminal NoSQL database, but also legendary Googlers Jeff Dean and Sanjay Ghemawat and a long list of other engineers who worked on such groundbreaking data-center platforms as Megastore and Dremel. This time around, they found a new way of keeping time. ?As a distributed systems developer, you?re taught from ? I want to say childhood ? not to trust time,? says Fikes. ?What we did is find a way that we could trust time ? and understand what it meant to trust time.? Time Is of the Essence On the net, time is of the essence. Yes, in running a massive web service, you need things to happen quickly. But you also need a means of accurately keeping track of time across the many machines that underpin your service. You have to synchronize the many processes running on each server, and you have to synchronize the servers themselves, so that they too can work in tandem. And that?s easier said than done. Typically, data-center operators keep their servers in sync using what?s called the Network Time Protocol, or NTP. This is essentially an online service that connects machines to the official atomic clocks that keep time for organizations across the world. But because it takes time to move information across a network, this method is never completely accurate, and sometimes, it breaks altogether. In July, several big-name web operations experienced problems ? including Reddit, Gawker, and Mozilla ? because their software wasn?t prepared to handle a ?leap second? that was added to the world?s atomic clocks. ?We wanted something that we were confident in. It?s a time reference that?s owned by Google.? ? Andrew Fikes But with Spanner, Google discarded the NTP in favor of its own time-keeping mechanism. It?s called the TrueTime API. ?We wanted something that we were confident in,? Fikes says. ?It?s a time reference that?s owned by Google.? Rather than rely on outside clocks, Google equips its Spannerized data centers with its own atomic clocks and GPS (global positioning system) receivers, not unlike the one in your iPhone. Tapping into a network of satellites orbiting the Earth, a GPS receiver can pinpoint your location, but it can also tell time. These time-keeping devices connect to a certain number of master servers, and the master servers shuttle time readings to other machines running across the Google network. Basically, each machine on the network runs a daemon ? a background software process ? that is constantly checking with masters in the same data center and in other Google data centers, trying to reach a consensus on what time it is. In this way, machines across the Google network can come pretty close to running a common clock. ?The System Responds ? And Not a Human? How does this bootstrap a worldwide database? Thanks to the TrueTime service, Google can keep its many machines in sync ? even when they span multiple data centers ? and this means they can quickly store and retrieve data without stepping on each other?s toes. ?We can commit data at two different locations ? say the West Coast [of the United States] and Europe ? and still have some agreed upon ordering between them,? Fikes says, ?So, if the West Coast write happens first and then the one in Europe happens, the whole system knows that ? and there?s no possibility of them being viewed in a different order.? ?By using highly accurate clocks and a very clever time API, Spanner allows server nodes to coordinate without a whole lot of communication.? ? Andy Gross According to Andy Gross ? the principal architect at Basho, an outfit that builds an open source database called Riak that?s designed to run across thousands of servers ? database designers typically seek to synchronize information across machines by having them talk to each other. ?You have to a do a whole lot of communication to decide the correct order for all the transactions,? he told us this fall, when Spanner was first revealed. The problem is that this communication can bog down the network ? and the database. As Max Schireson ? the president of 10gen, maker of the NoSQL database MongoDB ? told us: ?If you have large numbers of people accessing large numbers of systems that are globally distributed so that the delay in communications between them is relatively long, it becomes very hard to keep everything synchronized. If you increase those factors, it gets even harder.? So Google took a completely different tack. Rather than struggle to improve communication between servers, it gave them a new way to tell time. ?That was probably the coolest thing about the paper: using atomic clocks and GPS to provide a time API,? says Facebook?s Raghu Murty. In harnessing time, Google can build a database that?s both global and consistent, but it can also make its services more resistant in the face of network delays, data-center outages, and other software and hardware snafus. Basically, Google uses Spanner to accurately replicate its data across multiple data centers ? and quickly move between replicas as need be. In other words, the replicas are consistent too. When one replica is unavailable, Spanner can rapidly shift to another. But it will also move between replicas simply to improve performance. ?If you have one replica and it gets busy, your latency is going to be high. But if you have four other replicas, you can choose to go to a different one, and trim that latency,? Fikes says. One effect, Fikes explains, is that Google spends less money managing its system. ?When there are outages, things just sort of flip ? client machines access other servers in the system,? he says. ?It?s a much easier service story?. The system responds ? and not a human.? Spanning Google?s Footsteps Some have questioned whether others can follow in Google?s footsteps ? and whether they would even want to. When we spoke to Andy Gross, he guessed that even Google?s atomic clocks and GPS receivers would be prohibitively expensive for most operations. Yes, rebuilding the platform would be a massive undertaking. Google has already spent four and half years on the project, and Fikes ? who helped build Google?s web history tool, its first product search service, and Google Answers, as well as BigTable ? calls Spanner the most difficult thing he has ever worked on. What?s more, there are countless logistical issues that need dealing with. ?The important thing to think about is that this is a service that is provided to the data center. The costs of that are amortized across all the servers in your fleet. The cost per server is some incremental amount ? and you weigh that against the types of things we can do for that.? ? Andrew Fikes As Fikes points out, Google had to install GPS antennas on the roofs of its data centers and connect them to the hardware below. And, yes, you do need two separate types of time keepers. Hardware always fails, and your time keepers must fail at, well, different times. ?The atomic clocks provide stability if there is a GPS issue,? he says. But according to Fikes, these are relatively inexpensive devices. The GPS units aren?t as cheap as those in your iPhone, but like Google?s atomic clocks, they cost no more than a few thousand dollars apiece. ?They?re sort of in the order of the cost of an enterprise server,? he says, ?and there are a lot of different vendors of these devices.? When we discussed the matter with Jeff Dean ? one of Google primary infrastructure engineers and another name on the Spanner paper ? he indicated much the same. Fikes also makes a point of saying that the TrueTime service does not require specialized servers. The time keepers are kept in racks onside the servers, and again, they need only connect to some machines in the data center. ?You can think of it as only a handful of these devices being in each data center. They?re boxes. You buy them. You plug them into your rack. And you?re going to connect to them over Ethernet,? Fikes says. ?The important thing to think about is that this is a service that is provided to the data center. The costs of that are amortized across all the servers in your fleet. The cost per server is some incremental amount ? and you weigh that against the types of things we can do for that.? No, Spanner isn?t something every website needs today. But the world is moving in its general direction. Though Facebook has yet to explore something like Spanner, it is building a software platform called Prism that will run the company?s massive number crunching tasks across multiple data centers. Yes, Google?s ad system is enormous, but it benefits from Spanner in ways that could benefit so many other web services. The Google ad system is an online auction ? where advertisers bid to have their ads displayed as someone searches for a particular item or visits particular websites ? and the appearance of each ad depends on data describing the behavior of countless advertisers and web surfers across the net. With Spanner, Google can juggle this data on a global scale, and it can still keep the whole system in sync. As Fikes put it, Spanner is just the first example of Google taking advantage of its new hold on time. ?I expect there will be many others,? he says. He means other Google services, but there?s a reason the company has now shared its Spanner paper with the rest of the world. Illustration by Ross Patton From sebastian.abt at h-da.de Tue Nov 27 08:48:20 2012 From: sebastian.abt at h-da.de (Sebastian Abt) Date: Tue, 27 Nov 2012 09:48:20 +0100 Subject: CfP: Survey on network attack detection and mitigation Message-ID: <20121127084820.GM48641@sephina.sabt.net> Dear NANOG, I'd like to draw your attention to a survey we're conducting in context of several research projects: +----------------------- Call for Participation -----------------------+ | Survey on network attack detection and mitigation | +----------------------------------------------------------------------+ | opened from 14.11.12 - 04.12.12 | +--------------> http://www.dasec.h-da.de/survey/netsec <--------------+ Network-based attacks pose a strong threat to the Internet landscape and academia is working towards different approaches on attack detection and mitigation. Yet, a clear understanding of possibilities and issues in commercial networks is missing. Hence, this survey aims at gaining insight in real-world processes, structures and capabilities of IT companies and the computer networks they run. This survey is conducted in context of different publicly funded research projects of the da/sec Biometrics and Internet Security research group [1], as well as work done in the combined eco e.V. and DE-CIX competence group security. Results of this survey shall frame future research and community activities in the area of Internet security. The survey targets at companies of all size and colour running an own computer network. Questions within this survey address some organizational aspects, as well as processes, techniques and tools you may have employed in order to perform network attack detection and mitigation. Filling the survey should not last longer than 5 - 10 minutes. Thus, this survey can ideally be answered during a short and relaxing coffee/tea break ;-) Thank you all for your help to advance Internet security research! [1] http://www.dasec.h-da.de/ +----------------------------------------------------------------------+ It would be nice if you would support our work by participating in this survey. If you may have any particular questions regarding this survey or our work, please do not hesitate to contact me off-list. Thanks and best regards sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4403 bytes Desc: not available URL: From randy at psg.com Tue Nov 27 14:50:52 2012 From: randy at psg.com (Randy Bush) Date: Tue, 27 Nov 2012 23:50:52 +0900 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> Message-ID: >> sorry if the facts did not support your conclusion. they do support >> mine. > Pointers to these facts would be greatly appreciated, especially as no > one else seems to know where to find them. to repeat, a very large broadband provider has said semi-publicly, and another has corroborated, when they enable ipv6 to an average consumer, 40% of the traffic immediately switches to ipv6. the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble. content is queen. randy From rdobbins at arbor.net Tue Nov 27 15:16:27 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Nov 2012 15:16:27 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> Message-ID: On Nov 27, 2012, at 9:50 PM, Randy Bush wrote: > the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble. Just because their users can reach popular content-rich/high-bandwidth endpoint sites via IPv6 *that they can also reach via IPv4* doesn't seem to provide much of an incentive in and of itself for IPv6 deployment. Obviously, they deployed IPv6 for other reasons, and it would be far more useful to know *why* they deployed it in the first place (i.e., as an experiment, because their user base is outstripping their IPv4 allocations, etc.). ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From dreamwaverfx at yahoo.com Tue Nov 27 15:57:40 2012 From: dreamwaverfx at yahoo.com (Alex) Date: Tue, 27 Nov 2012 17:57:40 +0200 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> Message-ID: <50B4E2F4.8040006@yahoo.com> You can look back on Nanog56 and watch Liviu's presentation regarding implementation in the RCS-RDS network. Why, you ask? Because they/we can do it. IPv4 exhaustion is upon us. CGN will break some of the fuctionality of current day networks or rather APPs running on those networks. Because you have unlimited IPs with increased security... I could continue with the list of "why"s. The only "why not" in this entire talk is due to vendors. Core and distribution vendors have been supporting IPv6 for quite some time now while ACCESS vendors are still lagging behind. Most OS's(Windows,*nix,etc) run IPv6 this days and they have been for a few years now. PS: although this might sound silly here is a idea...have all the porn sites switch to IPv6 and you'll see a 20-30 fold increase in IPv6 traffic :)). On 11/27/2012 5:16 PM, Dobbins, Roland wrote: > On Nov 27, 2012, at 9:50 PM, Randy Bush wrote: > >> the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble. > > Just because their users can reach popular content-rich/high-bandwidth endpoint sites via IPv6 *that they can also reach via IPv4* doesn't seem to provide much of an incentive in and of itself for IPv6 deployment. > > Obviously, they deployed IPv6 for other reasons, and it would be far more useful to know *why* they deployed it in the first place (i.e., as an experiment, because their user base is outstripping their IPv4 allocations, etc.). > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From dwcarder at wisc.edu Tue Nov 27 16:19:35 2012 From: dwcarder at wisc.edu (Dale W. Carder) Date: Tue, 27 Nov 2012 10:19:35 -0600 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> Message-ID: <20121127161935.GC84087@ricotta.doit.wisc.edu> Thus spake Dobbins, Roland (rdobbins at arbor.net) on Tue, Nov 27, 2012 at 03:16:27PM +0000: > > On Nov 27, 2012, at 9:50 PM, Randy Bush wrote: > > > the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble. > > Just because their users can reach popular content-rich/high-bandwidth endpoint sites via IPv6 *that they can also reach via IPv4* doesn't seem to provide much of an incentive in and of itself for IPv6 deployment. I would consider 40% offload from your expensive CGN to be incentive in and of itself. Dale From cb.list6 at gmail.com Tue Nov 27 16:22:05 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 27 Nov 2012 08:22:05 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121127053459.AA20C2C3248D@drugs.dv.isc.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <20121127053459.AA20C2C3248D@drugs.dv.isc.org> Message-ID: On Mon, Nov 26, 2012 at 9:34 PM, Mark Andrews wrote: > > In message , Mikael Abrah > amsson writes: >> On Mon, 26 Nov 2012, Michael Thomas wrote: >> >> > I don't see either Apple or Microsoft as being the hindrance. In fact, >> > both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. >> > But I'm pretty sure that both iPhones and Androids are pretty happy >> > about being in v6 land since I see them showing up in my logs all the >> > time, for the few providers that have lit up v6. >> >> Not on the mobile side. Wifi yes, mobile no. >> >> > I'm all for bagging on those two, but it seems pretty unjustified here. >> >> What they need to start doing is testing Apps for IPv6 only access >> capabilitity. This doesn't work today, Apps like Waze, Spotify and others >> do not work on IPv6 only access. > > One could just start adding negative reviews to any product that > doesn't work in a IPv6 only network. > Yes, you can start your reviews on Android with Skype, Netflix, and Spotify all fail to work in an IPv6-only NAT64/DNS64 3G/4G network This list needs to be updated, but it is a fair starting point https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc#gid=0 It is also worth noting that folks can certainly test IPv6-only apps using T-Mobile in the USA https://sites.google.com/site/tmoipv6/lg-mytouch, that's just one data point. And, 464XLAT on Android does enable these broken application to work correctly on an IPv6-only NAT64/DNS64 network http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-08 464XLAT and IPv6 tethering code for Android here http://dan.drown.org/android/clat/ CB >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From swmike at swm.pp.se Tue Nov 27 16:47:00 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 27 Nov 2012 17:47:00 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> Message-ID: On Tue, 27 Nov 2012, Dobbins, Roland wrote: > Obviously, they deployed IPv6 for other reasons, and it would be far > more useful to know *why* they deployed it in the first place (i.e., as > an experiment, because their user base is outstripping their IPv4 > allocations, etc.). IPv6 deployment is not a short-term answer to IPv4 exhaustion. Can we please just put this to rest? -- Mikael Abrahamsson email: swmike at swm.pp.se From tglassey at earthlink.net Tue Nov 27 17:03:34 2012 From: tglassey at earthlink.net (tglassey) Date: Tue, 27 Nov 2012 09:03:34 -0800 Subject: Folks - changes to USTiming.ORG NIST Time Servers access names... Message-ID: <50B4F266.1060905@earthlink.net> So I wanted to bring up we are making some changes in the NIST Server addresses and creating two pools they are: east-pool.ustiming.org west-pool.ustiming.org Also there is a new VLAN which can provide you your own /24 of access space for the NIST infrastructure anywhere in the NY/NJ corridor. If your in 60 Hudson, 100 William, NJ2, NY4, or our anchor spots with NYI at 100 William or 999 Frontier we can wire you for time... Anyway - for internet access please feel free to use the two pools. The East Pool is all of the external NIST UTC ITS systems we operate there under USTiming.ORG banners. Have fun Todd -- Regards TSG "Ex-Cruce-Leo" //Confidential Mailing - Please destroy this if you are not the intended recipient. From ben at bjencks.net Tue Nov 27 18:03:03 2012 From: ben at bjencks.net (Ben Jencks) Date: Tue, 27 Nov 2012 13:03:03 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121127161935.GC84087@ricotta.doit.wisc.edu> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> <20121127161935.GC84087@ricotta.doit.wisc.edu> Message-ID: <50B50057.6060008@bjencks.net> On 11/27/2012 11:19 AM, Dale W. Carder wrote: > Thus spake Dobbins, Roland (rdobbins at arbor.net) on Tue, Nov 27, 2012 at 03:16:27PM +0000: >> >> On Nov 27, 2012, at 9:50 PM, Randy Bush wrote: >> >>> the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble. >> >> Just because their users can reach popular content-rich/high-bandwidth endpoint sites via IPv6 *that they can also reach via IPv4* doesn't seem to provide much of an incentive in and of itself for IPv6 deployment. > > I would consider 40% offload from your expensive CGN to be incentive in and of itself. Just a thought -- what percentage of flows is that 40% of traffic? Since it's mostly video I'd assume the bytes/flow would be far higher than the median. If you can get a reasonably high percentage of flows on IPv6, not only do take load off your CGN box, you can get higher users per public IPv4 address ratios and stretch your v4 allocation further. No idea if the numbers work out to make this a useful effect in the timeframe when it would be necessary, but it's a benefit I haven't heard voiced before. -Ben From blake at pfankuch.me Tue Nov 27 18:01:21 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Tue, 27 Nov 2012 18:01:21 +0000 Subject: Looking for an Optimum Online engineer Message-ID: We have been fighting with an issue with a customer who is having issues on a business Cable Line in Wyoming, is there someone out there who might be able to help up troubleshoot a little? We have been through normal routes, but because it is not a consistent issue, we cant actually see what is going on or trend it so we get a ticket closed. Thanks! Blake Pfankuch From mike at mtcc.com Tue Nov 27 19:21:26 2012 From: mike at mtcc.com (mike) Date: Tue, 27 Nov 2012 11:21:26 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> Message-ID: <50B512B6.1010701@mtcc.com> On 11/26/12 9:32 PM, Mikael Abrahamsson wrote: > > The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done. > This is a point that is probably more significant than is appreciated. If the app, IT, and networking ecosystem don't even have access to ipv6 to play around with, you can be guaranteed that they are going to be hesitant about lighting v6 up in real life. Mike From mike at mtcc.com Tue Nov 27 19:28:59 2012 From: mike at mtcc.com (mike) Date: Tue, 27 Nov 2012 11:28:59 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> Message-ID: <50B5147B.7050504@mtcc.com> On 11/26/12 8:59 PM, Mikael Abrahamsson wrote: > On Mon, 26 Nov 2012, Michael Thomas wrote: > >> I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But >> I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the >> few providers that have lit up v6. > > Not on the mobile side. Wifi yes, mobile no. You're saying there are no cellular v6 deployments? I'm about 99% certain that you're wrong. I see v6 addresses in my apache logs all the time and they're almost definitely while they're not on wifi (my site uploads gps data while people are skiing, so they're usually on cellular). > >> I'm all for bagging on those two, but it seems pretty unjustified here. > > What they need to start doing is testing Apps for IPv6 only access capabilitity. This doesn't work today, Apps like Waze, Spotify and others do not > work on IPv6 only access. Is this the app's fault? What are they doing wrong? Mike From cb.list6 at gmail.com Tue Nov 27 19:58:58 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 27 Nov 2012 11:58:58 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B5147B.7050504@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> Message-ID: On Tue, Nov 27, 2012 at 11:28 AM, mike wrote: > On 11/26/12 8:59 PM, Mikael Abrahamsson wrote: >> >> On Mon, 26 Nov 2012, Michael Thomas wrote: >> >>> I don't see either Apple or Microsoft as being the hindrance. In fact, >>> both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But >>> I'm pretty sure that both iPhones and Androids are pretty happy about being >>> in v6 land since I see them showing up in my logs all the time, for the few >>> providers that have lit up v6. >> >> >> Not on the mobile side. Wifi yes, mobile no. > > > You're saying there are no cellular v6 deployments? I'm about 99% certain > that > you're wrong. I see v6 addresses in my apache logs all the time and they're > almost > definitely while they're not on wifi (my site uploads gps data while people > are skiing, > so they're usually on cellular). > >> >>> I'm all for bagging on those two, but it seems pretty unjustified here. >> >> >> What they need to start doing is testing Apps for IPv6 only access >> capabilitity. This doesn't work today, Apps like Waze, Spotify and others do >> not work on IPv6 only access. > > > Is this the app's fault? What are they doing wrong? > Yes, it is the app's fault. They are either doing IPv4 literals or IPv4-only sockets The IPv4 literal issues is when they do "wget http://192.168.1.1" ... hard coding IPv4 addresses... instead of using an FQDN like "wget http://example.com". Using an FQDN allows the DNS64 to work correctly. The IPv4 literals fail since the IPv6-only host do not have an ipv4 address to bind to or an ipv4 route to follow. This is the issue that i believe Skype has ... since they use IPv4 addresses as part of their signalling. Another one is the URL re-director http://cs.co at Cisco. For example http://cs.co/6017pZhN will bounce you via an IPv4 address literal .... which means an IPv6-only user gets a webpage that tries to load an IPv4 address and fails. The other issue is that the developers choose to use IPv4-only socket APIs instead of a generic network socket APIs that would allow v4 or v6. This is usually an education issue. This is what i think is wrong with the Netflix Android app, they tried to do some low level network tweaks using the Android NDK but in doing these tweaks they only used IPv4 socket APIs and fail to work on IPv6 natively or via NAT64/DNS64. CB > Mike > From mike at mtcc.com Tue Nov 27 20:30:50 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 27 Nov 2012 12:30:50 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> Message-ID: <50B522FA.9060105@mtcc.com> On 11/27/2012 11:58 AM, Cameron Byrne wrote: > On Tue, Nov 27, 2012 at 11:28 AM, mike wrote: >> >> >> Is this the app's fault? What are they doing wrong? >> > > Yes, it is the app's fault. > > They are either doing IPv4 literals or IPv4-only sockets > > The IPv4 literal issues is when they do "wget http://192.168.1.1" ... > hard coding IPv4 addresses... instead of using an FQDN like "wget > http://example.com". Using an FQDN allows the DNS64 to work > correctly. I can understand spotify, but don't really understand why waze would have a problem unless they're doing some sort of rendezvous like protocol that embeds ip addresses. That said, I'd say that the vast majority of apps don't have this sort of problem and will quite unknowingly and correctly work with v6. Mike From marka at isc.org Tue Nov 27 20:34:24 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Nov 2012 07:34:24 +1100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: Your message of "Tue, 27 Nov 2012 17:47:00 BST." References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> Message-ID: <20121127203424.3C0F92C357BB@drugs.dv.isc.org> In message , Mikael Abrahamsson writes: > On Tue, 27 Nov 2012, Dobbins, Roland wrote: > > > Obviously, they deployed IPv6 for other reasons, and it would be far > > more useful to know *why* they deployed it in the first place (i.e., as > > an experiment, because their user base is outstripping their IPv4 > > allocations, etc.). > > IPv6 deployment is not a short-term answer to IPv4 exhaustion. Can we > please just put this to rest? But it will reduce the dollars that need to be spent to continue to prop up IPv4. Every IPv6 packet sent is one less packet that needs to be processed by the CGN *farm*. Split the bill so you can see the IPv4 and IPv6 traffic components and add a CGN loading on the IPv4 traffic. Mark > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Tue Nov 27 20:41:13 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Nov 2012 07:41:13 +1100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: Your message of "Tue, 27 Nov 2012 11:21:26 -0800." <50B512B6.1010701@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> Message-ID: <20121127204113.EA02F2C35877@drugs.dv.isc.org> In message <50B512B6.1010701 at mtcc.com>, mike writes: > On 11/26/12 9:32 PM, Mikael Abrahamsson wrote: > > > > The main problem with IPv6 only is that most app developers (most programme > rs totally) do not really have access to this, so no testing is being done. > > > This is a point that is probably more significant than is appreciated. If the > app, > IT, and networking ecosystem don't even have access to ipv6 to play around wi > th, > you can be guaranteed that they are going to be hesitant about lighting v6 up > in real life. > > Mike I've had IPv6 for nearly a decade with no help from my ISP. I needed it to do IPv6 developement. It isn't hard to get IPv6 if you need it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mike at mtcc.com Tue Nov 27 20:46:12 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 27 Nov 2012 12:46:12 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <20121127204113.EA02F2C35877@drugs.dv.isc.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <20121127204113.EA02F2C35877@drugs.dv.isc.org> Message-ID: <50B52694.4060009@mtcc.com> On 11/27/2012 12:41 PM, Mark Andrews wrote: > In message <50B512B6.1010701 at mtcc.com>, mike writes: >> On 11/26/12 9:32 PM, Mikael Abrahamsson wrote: >>> The main problem with IPv6 only is that most app developers (most programme >> rs totally) do not really have access to this, so no testing is being done. >> This is a point that is probably more significant than is appreciated. If the >> app, >> IT, and networking ecosystem don't even have access to ipv6 to play around wi >> th, >> you can be guaranteed that they are going to be hesitant about lighting v6 up >> in real life. >> >> Mike > I've had IPv6 for nearly a decade with no help from my ISP. I > needed it to do IPv6 developement. It isn't hard to get IPv6 if > you need it. > The point is that most developers and others don't think they "need" it so they don't seek it out. If there were far more native v6 (ie, that it's there without having to do something proactive), the app problems would almost certainly work themselves out because it would become apparent. Mike From jeroen at unfix.org Tue Nov 27 21:07:00 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Nov 2012 22:07:00 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B512B6.1010701@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> Message-ID: <50B52B74.4070606@unfix.org> On 2012-11-27 20:21, mike wrote: > On 11/26/12 9:32 PM, Mikael Abrahamsson wrote: >> >> The main problem with IPv6 only is that most app developers (most >> programmers totally) do not really have access to this, so no testing >> is being done. >> > This is a point that is probably more significant than is > appreciated. If the app, IT, and networking ecosystem don't even have > access to ipv6 to play around with, you can be guaranteed that they > are going to be hesitant about lighting v6 up in real life. I cannot be saf for the people who claim to be programmers who do things with networking and who do not care to follow the heavy hints that they have been getting for at least the last 10 years that their applications need to start supporting IPv6. Especially as APIs like getaddrinfo() make it really easy to do so. The following excellent article by our beloved true IPv6 Samuarai Itojun is from 1998: http://www.kame.net/newsletter/19980604/ Thus it is not like the information is not out there either. As for actually getting IPv6 at home or at work, there are so many ways to get that, thus not having it is a completely ridiculous excuse. (It might not be native, so wh00p, you can test fine also on a local link in the extreme case) Remember that silly thing called the 6bone and what the purpose of that was back then, indeed, for getting connectivity to the people so that they could fix their code and that ran from 1996 till 2006, 10 years where one could have fixed up those apps that was already 6 years ago again. As such, if an application does not do proper IPv6 today the people in charge of the thing simply did not care... Greets, Jeroen who proudly has been providing IPv6 connectivity and IPv6 patches for over more than a decade... From cb.list6 at gmail.com Tue Nov 27 21:11:42 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 27 Nov 2012 13:11:42 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B522FA.9060105@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> <50B522FA.9060105@mtcc.com> Message-ID: On Tue, Nov 27, 2012 at 12:30 PM, Michael Thomas wrote: > On 11/27/2012 11:58 AM, Cameron Byrne wrote: >> >> On Tue, Nov 27, 2012 at 11:28 AM, mike wrote: >>> >>> >>> >>> Is this the app's fault? What are they doing wrong? >>> >> >> Yes, it is the app's fault. >> >> They are either doing IPv4 literals or IPv4-only sockets >> >> The IPv4 literal issues is when they do "wget http://192.168.1.1" ... >> hard coding IPv4 addresses... instead of using an FQDN like "wget >> http://example.com". Using an FQDN allows the DNS64 to work >> correctly. > > > I can understand spotify, but don't really understand why waze Why can you understand Spotify not working on IPv6? Are they known for having a generally shoddy product? Pandora works fine on my IPv6-only NAT64/DNS64 setup. As does Youtube and many other multimedia services. Is Waze much different from Google Maps? Google Maps works great, as does Mapquest on ipv6-only And this is the conversation folks will have...: "Oh... Waze does not work, you should try their competitor it works great" and " I used to use Spotify, then i changed networks and it stopped working... now i use Pandora or Google Music" > would have a problem unless they're doing some sort of rendezvous > like protocol that embeds ip addresses. That said, I'd say that the > vast majority of apps don't have this sort of problem and will quite > unknowingly and correctly work with v6. > Yes, 85% of the Android apps i have tested (sample of over 200) work fine on IPv6-only ... likely due to just good coding practices ... not due to specific IPv6 engineering. CB > Mike From joseph at josephholsten.com Tue Nov 27 21:23:55 2012 From: joseph at josephholsten.com (Joseph Holsten) Date: Tue, 27 Nov 2012 21:23:55 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B52B74.4070606@unfix.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> On 2012-11-27, at 21:07, Jeroen Massar wrote: > As such, if an application does not do proper IPv6 today the people in > charge of the thing simply did not care... Or do care. From http://wiki.apache.org/hadoop/HadoopIPv6: > Apache Hadoop does not currently support IPv6 networks, it uses IPv4 addresses for communicating between nodes. This is because Hadoop is designed to work in private datacenters, which usually have private IP addresses in the 10.x.x.x address space. > > ? Using IPv4 addresses everywhere provides a single form of TCP addressing for all our tests. Different network configurations (DNS, reverse DNS, DNS caching) still provide lots of problems and performance issues, but there is no need to worry about which IP protocol version is used. > ? Shorter addresses make for shorter packets, which can have a benefit on busy networks. > > This does not mean that the Hadoop team thinks that IPv4 is the best ever network protocol and that there is no reason to upgrade ever, only that it works well in datacenters. (Yes, I am technically trolling. But mostly because I don't have the energy to fight for IPv6 any more. Maybe you do?) -- http://josephholsten.com From drais at icantclick.org Tue Nov 27 21:26:26 2012 From: drais at icantclick.org (david raistrick) Date: Tue, 27 Nov 2012 16:26:26 -0500 (EST) Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B52B74.4070606@unfix.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: On Tue, 27 Nov 2012, Jeroen Massar wrote: > As for actually getting IPv6 at home or at work, there are so many ways > to get that, thus not having it is a completely ridiculous excuse. bull. explain using a tunnel broker to anyone who isn't a network engineer. oh, and then make that work inside a typical F500 corp network with restrictions on inbound and outbound ports, no admin user access to desktop machines, etc. Until the orgs that support the developers find that v6 is a priority (through whatever means it happens - neteng/IT/etc pushing it up the chain or politics/marketing pushing it down the chain) and it's functional on the typical corp desktop, the typical corp application engineer is going to have no motivation (not to mention no time in his/her schedule to reengineer their platform) to support v6. ...david (who hasn't read the rest of the thread. but is it really any different than any other?) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From lee at asgard.org Tue Nov 27 21:28:23 2012 From: lee at asgard.org (Lee Howard) Date: Tue, 27 Nov 2012 16:28:23 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> Message-ID: <007201cdcce6$213f3fb0$63bdbf10$@asgard.org> > > The better question, for an isp, is what kind of ipv4 secondary market budget do you have? > How hot is your cgn running? Like ALGs much ? Security and attribute much ? > > These are important, yes. > > > Again , users dont care or know about v4 or v6. This is purely a network operator and app > issue (cough cough ... skype). > > It's my contention that IPv6 won't be widely deployed unless/until end-customers call up their > ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have. There are two basic value propositions: IPv6 is better, or IPv6 is cheaper. You argue that it must be better. I presented my argument in Dallas, that IPv6 will be cheaper than IPv4 when ISPs' costs to expand an IPv4 network rise. Some ISPs will, no doubt, raise prices for IPv4 service. Then IPv6 will be in demand. We can even express this now to app developers and consumer electronics makers: "Don't let your app/device be the one that costs your customer extra dollars every month. Especially if your competitor's app/device does support IPv6." There are significant deployments of residential IPv6 now. http://www.worldipv6launch.org/measurements/ I'm not expecting content over IPv6 just yet (unless it's a pre-release publicity stunt). I do expect some ISP in the next two years to offer an IPv6-only service at a discount to dual-stack. Lee From contact at nullivex.com Tue Nov 27 21:30:43 2012 From: contact at nullivex.com (Bryan Tong) Date: Tue, 27 Nov 2012 14:30:43 -0700 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> Message-ID: Personally I have ran into this dilema a few times. The code just like network equipment needs dual stacks which is double the amount of code and since IPv4 and IPv6 do not share a native topology just supporting both kinds of addresses isnt sufficient. I agree that some of it comes down to knowledge; most programmers learn from experience and lets face it unless you go looking your unlikely to run into IPv6 even as of yet. I believe as the ISP implements IPv6 and companies get more demand on the customer facing side of things it will pick up quickly. In our datacenters all our software is built with IPv6 addressing supported but we have yet to build the logic stack as we are waiting for the demand. It makes no sense to build all the support just because when there are other important things to do. Just my thoughts. On Tue, Nov 27, 2012 at 2:23 PM, Joseph Holsten wrote: > On 2012-11-27, at 21:07, Jeroen Massar wrote: >> As such, if an application does not do proper IPv6 today the people in >> charge of the thing simply did not care... > > Or do care. > > From http://wiki.apache.org/hadoop/HadoopIPv6: >> Apache Hadoop does not currently support IPv6 networks, it uses IPv4 addresses for communicating between nodes. This is because Hadoop is designed to work in private datacenters, which usually have private IP addresses in the 10.x.x.x address space. >> >> ? Using IPv4 addresses everywhere provides a single form of TCP addressing for all our tests. Different network configurations (DNS, reverse DNS, DNS caching) still provide lots of problems and performance issues, but there is no need to worry about which IP protocol version is used. >> ? Shorter addresses make for shorter packets, which can have a benefit on busy networks. >> >> This does not mean that the Hadoop team thinks that IPv4 is the best ever network protocol and that there is no reason to upgrade ever, only that it works well in datacenters. > > (Yes, I am technically trolling. But mostly because I don't have the energy to fight for IPv6 any more. Maybe you do?) > -- > http://josephholsten.com -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From lee at asgard.org Tue Nov 27 21:31:07 2012 From: lee at asgard.org (Lee Howard) Date: Tue, 27 Nov 2012 16:31:07 -0500 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> Message-ID: <007301cdcce6$8315c9c0$89415d40$@asgard.org> > From: Dobbins, Roland [mailto:rdobbins at arbor.net] > On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote: > > > If you don't think that the need to sustain the growth in the number of devices attached to > the network (never mind the number of things causing that rate to accelerate[1]) makes IPv6 > inevitable at this point, you really aren't paying attention. > > What people ought to do and what they actually do are often quite different things. > > Again, all the attention being lavished upon CGNs and 444 and whatnot are quite interesting > indicators of perceived priorities. A lot of attention was lavished on ISDN, too. More attention is lavished on IPv6. So a) attention level doesn't indicate priority, and b) even if it did, IPv6 wins. Also, CGN does not preclude IPv6; it makes most sense (if at all) as a backstop for situations when IPv6 doesn't work and IPv4 addresses are too expensive. Lee From marka at isc.org Tue Nov 27 21:31:51 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Nov 2012 08:31:51 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Tue, 27 Nov 2012 21:23:55 -0000." <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> Message-ID: <20121127213151.88C7F2C35ED0@drugs.dv.isc.org> In message <84F8DEBC-C754-4D06-99B0-405CC8A358BD at josephholsten.com>, Joseph Hol sten writes: > On 2012-11-27, at 21:07, Jeroen Massar wrote: > > As such, if an application does not do proper IPv6 today the people in > > charge of the thing simply did not care... > > Or do care.=20 > > =46rom http://wiki.apache.org/hadoop/HadoopIPv6: > > Apache Hadoop does not currently support IPv6 networks, it uses IPv4 = > addresses for communicating between nodes. This is because Hadoop is = > designed to work in private datacenters, which usually have private IP = > addresses in the 10.x.x.x address space. > >=20 > > =95 Using IPv4 addresses everywhere provides a single form of = > TCP addressing for all our tests. Different network configurations (DNS, = > reverse DNS, DNS caching) still provide lots of problems and performance = > issues, but there is no need to worry about which IP protocol version is = > used. > > =95 Shorter addresses make for shorter packets, which can have a = > benefit on busy networks. > >=20 > > This does not mean that the Hadoop team thinks that IPv4 is the best = > ever network protocol and that there is no reason to upgrade ever, only = > that it works well in datacenters.=20 > > (Yes, I am technically trolling. But mostly because I don't have the = > energy to fight for IPv6 any more. Maybe you do?) Most of which is just FUD. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mike at mtcc.com Tue Nov 27 21:40:00 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 27 Nov 2012 13:40:00 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B52B74.4070606@unfix.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: <50B53330.1090003@mtcc.com> On 11/27/2012 01:07 PM, Jeroen Massar wrote: > On 2012-11-27 20:21, mike wrote: >> This is a point that is probably more significant than is >> appreciated. If the app, IT, and networking ecosystem don't even have >> access to ipv6 to play around with, you can be guaranteed that they >> are going to be hesitant about lighting v6 up in real life. > I cannot be saf for the people who claim to be programmers who do things > with networking and who do not care to follow the heavy hints that they > have been getting for at least the last 10 years that their applications > need to start supporting IPv6. Especially as APIs like getaddrinfo() > make it really easy to do so. > I think you vastly overestimate that developers will a) know about v6 and b) care even if they do if it's not affecting them. Asking mortals to understand tunnel brokers -- even developer mortals -- just isn't going to happen. If we want the small percentage of apps that break with v6 to be fixed, it needs to a) show up as a bug report from enough people to matter and b) need to be testable by your average developer. This chicken and egg problem can really only be solved by ISP's, IMO. Mike From marka at isc.org Tue Nov 27 21:41:13 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Nov 2012 08:41:13 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Tue, 27 Nov 2012 16:26:26 CDT." References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: <20121127214113.E113E2C35F6D@drugs.dv.isc.org> In message , david rai strick writes: > On Tue, 27 Nov 2012, Jeroen Massar wrote: > > > As for actually getting IPv6 at home or at work, there are so many ways > > to get that, thus not having it is a completely ridiculous excuse. > > bull. explain using a tunnel broker to anyone who isn't a network > engineer. If they are writing network based code a tunnel broker should not be a issue. Tunnel brokers are not that hard to use. They are after all just a VPN and millions of road warriers use them everyday. > oh, and then make that work inside a typical F500 corp network with > restrictions on inbound and outbound ports, no admin user access to > desktop machines, etc. And if they are developing a product for the company there are procedures to get the changes needed to do the development. > Until the orgs that support the developers find that v6 is a priority > (through whatever means it happens - neteng/IT/etc pushing it up the chain > or politics/marketing pushing it down the chain) and it's functional on > the typical corp desktop, the typical corp application engineer is going > to have no motivation (not to mention no time in his/her schedule to > reengineer their platform) to support v6. > > > ...david (who hasn't read the rest of the thread. but is it really any > different than any other?) > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org ascii ribbon campaign - stop html mail > http://www.asciiribbon.org/ > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.nether.net Tue Nov 27 22:27:56 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 27 Nov 2012 17:27:56 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> Message-ID: <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> On Nov 27, 2012, at 4:30 PM, Bryan Tong wrote: > Personally I have ran into this dilema a few times. > > The code just like network equipment needs dual stacks which is double > the amount of code and since IPv4 and IPv6 do not share a native > topology just supporting both kinds of addresses isnt sufficient. I reject the above statement having operated networks with congruent v4+v6 topologies for over a decade. Doing dual-stack is the easiest method. Any modern hardware supports it. If your upstream doesn't support IPv6, replace them. There are plenty of choices these days for IPv6 services. I've seen very large customer flows on single ports of IPv6 traffic (8-10Gb/s), so there is real traffic out there. While this may not be feasible for all use cases, I found myself looking for internet access about a year ago and each ISP I contacted had simple checkboxes on their forms for IPv6 and it was a breeze to turn up. (174/6461). I know many others can deliver this service as well (7922, 2914, 3561, 7018, 3549, 6453) amongst others. Even server hosting folks offer it as a checkbox as seen here: https://outlet.softlayer.com/Sales/orderServer/35/14015 Single IPv6 address is free.. a /64 is $5/mo Its readily available and you can get it via VPN while traveling if it's not already native (my Verizon LTE iPad does native IPv6). It sounds like the threshold is "Didn't pay for a server to host my application with IPv6 and can't spend $20/mo for LTE access to have native IPv6". > I agree that some of it comes down to knowledge; most programmers > learn from experience and lets face it unless you go looking your > unlikely to run into IPv6 even as of yet. I believe as the ISP > implements IPv6 and companies get more demand on the customer facing > side of things it will pick up quickly. Sure, using gethostbyname() is certainly easier to find code examples, but not impossible to find other examples. > In our datacenters all our software is built with IPv6 addressing > supported but we have yet to build the logic stack as we are waiting > for the demand. It makes no sense to build all the support just > because when there are other important things to do. There is something else. Many people "cheated" and stuck a 2^32 number in an integer datatype for their SQL or other servers. They don't work as well with 2^128 sized IPs. They have to undertake the actual effort of storing their data in a proper datatype instead of cheating. I've seen this over-and-over and likely is a significant impediment just as the gethostbyname vs getaddrinfo() system call translations may be. - Jared From bill at herrin.us Tue Nov 27 22:29:45 2012 From: bill at herrin.us (William Herrin) Date: Tue, 27 Nov 2012 17:29:45 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B52B74.4070606@unfix.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: On Tue, Nov 27, 2012 at 4:07 PM, Jeroen Massar wrote: > I cannot be saf for the people who claim to be programmers who do things > with networking and who do not care to follow the heavy hints that they > have been getting for at least the last 10 years that their applications > need to start supporting IPv6. Your lack of sorrow is immaterial to the programmers in question. And in the vast majority of cases the network is incidental to their software's role. The network is the tool not the product. They'll use the available tool. > As for actually getting IPv6 at home or at work, there are so many ways > to get that, thus not having it is a completely ridiculous excuse. At home sure. If they're willing to go to a little bit of effort they can have a tunnel. At work, few programmers have any control whatsoever over the available network resources in their development environment. Heck, most count it a win if they can get corporate IT to disable realtime virus checking in the compile tree so that they can compile an application in a reasonable length of time. Control fine details of the network environment? You must kidding. > (It might not be native, so wh00p, you can test fine also on a local > link in the extreme case) You know better. You can't test worth sh*t without a real network connection with hosts on the other side that do things you weren't expecting. > As such, if an application does not do proper IPv6 today the people in > charge of the thing simply did not care... did not care = true simply = false Deciding which of the nice-to-haves you're just not going to care about is rarely a simple question. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drais at icantclick.org Tue Nov 27 22:58:57 2012 From: drais at icantclick.org (david raistrick) Date: Tue, 27 Nov 2012 17:58:57 -0500 (EST) Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <20121127214113.E113E2C35F6D@drugs.dv.isc.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> Message-ID: On Wed, 28 Nov 2012, Mark Andrews wrote: >> oh, and then make that work inside a typical F500 corp network with >> restrictions on inbound and outbound ports, no admin user access to >> desktop machines, etc. > > And if they are developing a product for the company there are > procedures to get the changes needed to do the development. ...only if v6 support is on their development roadmap. For our latest released product, which had a 3 month timeline, there definitely would have been no software engineering support for building v6 support into a server framework that never had to support it before, nor 2 (or 3) client frameworks. ...david (who supports a bunch of software engineers for one of many arms of an F500 company) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From owen at delong.com Tue Nov 27 23:00:13 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Nov 2012 15:00:13 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> Message-ID: <74CAC386-E96D-4C82-91C2-5E69433D6C67@delong.com> On Nov 27, 2012, at 8:47 AM, Mikael Abrahamsson wrote: > On Tue, 27 Nov 2012, Dobbins, Roland wrote: > >> Obviously, they deployed IPv6 for other reasons, and it would be far more useful to know *why* they deployed it in the first place (i.e., as an experiment, because their user base is outstripping their IPv4 allocations, etc.). > > IPv6 deployment is not a short-term answer to IPv4 exhaustion. Can we please just put this to rest? > It's the only answer we have. Yes, it's not short enough term, so we will have to deploy some hacks along the way to try and keep things running, but, if we don't also continue (and seriously accelerate) IPv6 deployment in parallel, we're in for some serious hurt in the near future. Owen From tjc at ecs.soton.ac.uk Tue Nov 27 23:14:14 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 27 Nov 2012 23:14:14 +0000 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <2F1B5C04-0AAE-4607-A7EC-D24C88B9C1E6@arbor.net> <4852EB6F-7DBB-41E8-B955-4BDE737B32AE@ecs.soton.ac.uk> Message-ID: On 27 Nov 2012, at 14:50, Randy Bush wrote: >>> sorry if the facts did not support your conclusion. they do support >>> mine. >> Pointers to these facts would be greatly appreciated, especially as no >> one else seems to know where to find them. > > to repeat, a very large broadband provider has said semi-publicly, and > another has corroborated, when they enable ipv6 to an average consumer, > 40% of the traffic immediately switches to ipv6. the cause is netflix > and youtube, with a bit of help from fb and non-youtube gobble. content > is queen. http://6lab.cisco.com/stats/ suggests the figure is even higher, over 50% in some cases. Tim From marka at isc.org Tue Nov 27 23:29:11 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Nov 2012 10:29:11 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Tue, 27 Nov 2012 17:29:45 CDT." References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: <20121127232911.5DF232C37771@drugs.dv.isc.org> In message , William Herrin writes: > On Tue, Nov 27, 2012 at 4:07 PM, Jeroen Massar wrote: > > I cannot be saf for the people who claim to be programmers who do things > > with networking and who do not care to follow the heavy hints that they > > have been getting for at least the last 10 years that their applications > > need to start supporting IPv6. > > Your lack of sorrow is immaterial to the programmers in question. And > in the vast majority of cases the network is incidental to their > software's role. The network is the tool not the product. They'll use > the available tool. > > > > As for actually getting IPv6 at home or at work, there are so many ways > > to get that, thus not having it is a completely ridiculous excuse. > > At home sure. If they're willing to go to a little bit of effort they > can have a tunnel. > > At work, few programmers have any control whatsoever over the > available network resources in their development environment. Heck, > most count it a win if they can get corporate IT to disable realtime > virus checking in the compile tree so that they can compile an > application in a reasonable length of time. Control fine details of > the network environment? You must kidding. > > > > (It might not be native, so wh00p, you can test fine also on a local > > link in the extreme case) > > You know better. You can't test worth sh*t without a real network > connection with hosts on the other side that do things you weren't > expecting. > > > > As such, if an application does not do proper IPv6 today the people in > > charge of the thing simply did not care... > > did not care = true > simply = false > > Deciding which of the nice-to-haves you're just not going to care > about is rarely a simple question. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > And for 99% of apps using getaddrinfo() instead of gethostbyname() is all that is required to make them work with IPv6 and the documentation for getaddrinfo() has example code. getaddrinfo() works on a IPv4 only network. You read the API specfication, you write to it and it works 99.9% of the time and when it doesn't you file a bug report with the API vendor. I've reported bugs to all the major OS vendors over the years. IPv4 and IPv6 bugs. I've just reported bugs to Apple and FreeBSD over the iteraction, or lack of it, between IPV6_USE_MIN_MTU and TCP segment sizes. Havn't tested Linux's equivalent setsockopt yet. The fix to the BSD kernel to adjust the segment size is about 4 lines of additional code. One of the advantages of oss, you can go in there and fix it if you need to. I've coded for platforms that I have never worked on. It's a little more difficult but not impossible. I've debugged problems on machines that I don't have access to. Again it is more difficult but not impossible. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Tue Nov 27 23:44:37 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Nov 2012 15:44:37 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: <329CE7A3-7995-497C-8B03-A3EB3CDEAE36@delong.com> On Nov 27, 2012, at 1:26 PM, david raistrick wrote: > On Tue, 27 Nov 2012, Jeroen Massar wrote: > >> As for actually getting IPv6 at home or at work, there are so many ways >> to get that, thus not having it is a completely ridiculous excuse. > > bull. explain using a tunnel broker to anyone who isn't a network engineer. > Given the number of network engineers compared to the number of tunnel broker subscribers just at Hurricane Electric, I don't think that argument holds water. We have actually made using a tunnel broker very easy and provide pretty complete configuration examples for many many platforms. The examples are customized to contain the configuration elements for your particular tunnel so in most cases they are basically copy-and-paste configurations. > oh, and then make that work inside a typical F500 corp network with restrictions on inbound and outbound ports, no admin user access to desktop machines, etc. > At work you may be limited to Teredo or not at all. In such a case, it's time to have a conversation with your networking group and raise awareness. > Until the orgs that support the developers find that v6 is a priority (through whatever means it happens - neteng/IT/etc pushing it up the chain or politics/marketing pushing it down the chain) and it's functional on the typical corp desktop, the typical corp application engineer is going to have no motivation (not to mention no time in his/her schedule to reengineer their platform) to support v6. I would think that a developer of corporate network-based applications that is worth his salt would be one of the people pushing the IT/Neteng group to give him the tools to do his job. If he waits until they are implementing IPv6 on corporate desktops, he guarantees himself a really bad game of catch-up once that time arrives. Owen From owen at delong.com Tue Nov 27 23:48:20 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Nov 2012 15:48:20 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> Message-ID: <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> > >> I agree that some of it comes down to knowledge; most programmers >> learn from experience and lets face it unless you go looking your >> unlikely to run into IPv6 even as of yet. I believe as the ISP >> implements IPv6 and companies get more demand on the customer facing >> side of things it will pick up quickly. > > Sure, using gethostbyname() is certainly easier to find code examples, but not impossible to find other examples. > http://owend.corp.he.net/ipv6 Pretty much everything you need to know about taking your applications from mono-stack to dual-stack. Includes an example application implemented in IPv4 only and ported to dual stack in C, PERL, and Python. >> In our datacenters all our software is built with IPv6 addressing >> supported but we have yet to build the logic stack as we are waiting >> for the demand. It makes no sense to build all the support just >> because when there are other important things to do. > > There is something else. Many people "cheated" and stuck a 2^32 number in an integer datatype for their SQL or other servers. They don't work as well with 2^128 sized IPs. They have to undertake the actual effort of storing their data in a proper datatype instead of cheating. I've seen this over-and-over and likely is a significant impediment just as the gethostbyname vs getaddrinfo() system call translations may be. > It's actually pretty easy to change the datatype in an SQL database, so that shouldn't be that much of an impediment. Owen From tjc at ecs.soton.ac.uk Tue Nov 27 23:57:09 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 27 Nov 2012 23:57:09 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <329CE7A3-7995-497C-8B03-A3EB3CDEAE36@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <329CE7A3-7995-497C-8B03-A3EB3CDEAE36@delong.com> Message-ID: On 27 Nov 2012, at 23:44, Owen DeLong wrote: > Given the number of network engineers compared to the number of tunnel broker subscribers just at Hurricane Electric, I don't think that argument holds water. > > We have actually made using a tunnel broker very easy and provide pretty complete configuration examples for many many platforms. The examples are customized to contain the configuration elements for your particular tunnel so in most cases they are basically copy-and-paste configurations. Indeed. Our students find it pretty straightforward, and they're (relatively) novice developers. > I would think that a developer of corporate network-based applications that is worth his salt would be one of the people pushing the IT/Neteng group to give him the tools to do his job. If he waits until they are implementing IPv6 on corporate desktops, he guarantees himself a really bad game of catch-up once that time arrives. I would hope so too. That said if applications are written well, much of the problems can be abstracted. There's been guidance out there for several years, e.g. RFC4038 and many similar white papers etc etc. Tim From mike at mtcc.com Tue Nov 27 23:59:24 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 27 Nov 2012 15:59:24 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <329CE7A3-7995-497C-8B03-A3EB3CDEAE36@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <329CE7A3-7995-497C-8B03-A3EB3CDEAE36@delong.com> Message-ID: <50B553DC.1010709@mtcc.com> On 11/27/2012 03:44 PM, Owen DeLong wrote: > > I would think that a developer of corporate network-based applications that is worth his salt would be one of the people pushing the IT/Neteng group to give him the tools to do his job. If he waits until they are implementing IPv6 on corporate desktops, he guarantees himself a really bad game of catch-up once that time arrives. > the only pushing that is generally possible is of the 'on string' variety. Mike From bill at herrin.us Wed Nov 28 01:23:23 2012 From: bill at herrin.us (William Herrin) Date: Tue, 27 Nov 2012 20:23:23 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <20121127232911.5DF232C37771@drugs.dv.isc.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127232911.5DF232C37771@drugs.dv.isc.org> Message-ID: On Tue, Nov 27, 2012 at 6:29 PM, Mark Andrews wrote: > I've coded for platforms that I have never worked on. It's a little > more difficult but not impossible. I've debugged problems on > machines that I don't have access to. Again it is more difficult > but not impossible. Sure, but like me you're comfortably inside the 95th percentile. Expecting folks down under the 75th percentile to program IPv6 without a solid working IPv6 Internet link is crazy talk. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeroen at mompl.net Wed Nov 28 02:25:46 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 27 Nov 2012 18:25:46 -0800 Subject: juniper vpn Message-ID: <50B5762A.6000705@mompl.net> Hello, Does anyone know a practical and somewhat user friendly way of connecting to juniper vpn using linux? I have happily used http://www.unix-ag.uni-kl.de/~massar/vpnc/ a allow linux users to connect cisco vpn boxes where a crappy cisco vpn client would be needed otherwise, and it works very nicely. I was hoping there exists a similar tool for juniper vpn. Thank you, Jeroen -- Earthquake Magnitude: 4.0 Date: Wednesday, November 28, 2012 00:20:46 UTC Location: Dominican Republic region Latitude: 19.3090; Longitude: -68.8393 Depth: 139.00 km From gregori.parker at gmail.com Wed Nov 28 02:34:11 2012 From: gregori.parker at gmail.com (Gregori Parker) Date: Tue, 27 Nov 2012 18:34:11 -0800 Subject: juniper vpn In-Reply-To: <50B5762A.6000705@mompl.net> References: <50B5762A.6000705@mompl.net> Message-ID: There's a linux nc connect client if you're using ive's...used to be tricky with supplicants, but last time I tried it was pretty user friendly On Nov 27, 2012 6:28 PM, "Jeroen van Aart" wrote: > Hello, > > Does anyone know a practical and somewhat user friendly way of connecting > to juniper vpn using linux? > > I have happily used http://www.unix-ag.uni-kl.de/~**massar/vpnc/a allow linux users to connect cisco vpn boxes where a crappy cisco vpn > client would be needed otherwise, and it works very nicely. I was hoping > there exists a similar tool for juniper vpn. > > Thank you, > Jeroen > > -- > Earthquake Magnitude: 4.0 > Date: Wednesday, November 28, 2012 00:20:46 UTC > Location: Dominican Republic region > Latitude: 19.3090; Longitude: -68.8393 > Depth: 139.00 km > > From cody at killsudo.info Wed Nov 28 03:14:40 2012 From: cody at killsudo.info (Cody Rose) Date: Tue, 27 Nov 2012 21:14:40 -0600 Subject: juniper vpn In-Reply-To: <50B5762A.6000705@mompl.net> References: <50B5762A.6000705@mompl.net> Message-ID: On Tue, 27 Nov 2012 18:25:46 -0800, Jeroen van Aart wrote: > Hello, > > Does anyone know a practical and somewhat user friendly way of > connecting to juniper vpn using linux? > > I have happily used http://www.unix-ag.uni-kl.de/~massar/vpnc/ a > allow linux users to connect cisco vpn boxes where a crappy cisco vpn > client would be needed otherwise, and it works very nicely. I was > hoping there exists a similar tool for juniper vpn. > > Thank you, > Jeroen I have had great success with the Shrew Soft vpn client and if you are using Fedora it is only a 'yum install ike' away and works without root and properly utilizes the tap interface while installing the proper routes needed to get traffic going. For aggressive mode dial-up vpn's against older Netscreen/Juniper gear the Shrew Soft client can't be beat for easy of setup under Linux and Windows. I have tried multiple different vpn configs from policy to route-based vpns on Juniper/Netscreens and have never had luck getting the Linux vpnc clients to properly work though others have claimed success. The vpnc client will establish the tunnel but getting traffic to properly pass even in the simplest of networks is to big of pain. Since Shrew Soft has both Windows and Linux support, exporting a config from a Linux client and emailing it to a friend on Windows just works. http://www.shrew.net/home Regards, Cody From dedelman at iname.com Wed Nov 28 03:18:59 2012 From: dedelman at iname.com (Dave Edelman) Date: Tue, 27 Nov 2012 22:18:59 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> Message-ID: <01db01cdcd17$1d0e7100$572b5300$@iname.com> I think that we are missing a significant part of this conversation. Even if programmers never write a line of code that invokes IPv6, they need to accommodate the effects of all the other programmers who aren't writing a line of IPv6 code. CGN renders most application logs useless unless they record source port as well as address. For many industries, logging of transactions in a manner that allows you to track back to the originator of the transaction is not optional. And yes that does translate to track back to the ISP who (when presented with the appropriate piece of paper) can convert the timestamp /IP address/ port combination to the customer who is responsible for the account. Even if programmers never write a line of code that invokes IPv6, they had better be testing their Internet facing applications against users in pure IPv4 environments; users in pure IPv6 environment using each of the transition mechanism, and users in dual-stack environments. I've spent more than a small amount of time explaining to vendors that AI_ADDRCONFIG is a really good hint flag to have set. One vendor responded that the change would require retesting everything. I'm afraid that he wasn't happy when I pointed out that they obviously hadn't tested the first time and that as the customer, I was entitled to at least one full set of (successful) pre-delivery testing. --Dave > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, November 27, 2012 6:48 PM > To: Jared Mauch > Cc: nanog at nanog.org > Subject: Re: "Programmers can't get IPv6 thus that is why they do not have > IPv6 in their applications".... > > > > >> I agree that some of it comes down to knowledge; most programmers > >> learn from experience and lets face it unless you go looking your > >> unlikely to run into IPv6 even as of yet. I believe as the ISP > >> implements IPv6 and companies get more demand on the customer facing > >> side of things it will pick up quickly. > > > > Sure, using gethostbyname() is certainly easier to find code examples, but > not impossible to find other examples. > > > > http://owend.corp.he.net/ipv6 > > Pretty much everything you need to know about taking your applications > from mono-stack to dual-stack. > > Includes an example application implemented in IPv4 only and ported to dual > stack in C, PERL, and Python. > > >> In our datacenters all our software is built with IPv6 addressing > >> supported but we have yet to build the logic stack as we are waiting > >> for the demand. It makes no sense to build all the support just > >> because when there are other important things to do. > > > > There is something else. Many people "cheated" and stuck a 2^32 number > in an integer datatype for their SQL or other servers. They don't work as well > with 2^128 sized IPs. They have to undertake the actual effort of storing > their data in a proper datatype instead of cheating. I've seen this over-and- > over and likely is a significant impediment just as the gethostbyname vs > getaddrinfo() system call translations may be. > > > > It's actually pretty easy to change the datatype in an SQL database, so that > shouldn't be that much of an impediment. > > Owen > From owen at delong.com Wed Nov 28 03:27:52 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Nov 2012 19:27:52 -0800 Subject: juniper vpn In-Reply-To: <50B5762A.6000705@mompl.net> References: <50B5762A.6000705@mompl.net> Message-ID: <60911748-6271-42A3-A47F-2A53F23A79B9@delong.com> Do you want one for IPSEC or for the SSL VPN Appliance that Juniper is pushing nowadays? Owen On Nov 27, 2012, at 18:25 , Jeroen van Aart wrote: > Hello, > > Does anyone know a practical and somewhat user friendly way of connecting to juniper vpn using linux? > > I have happily used http://www.unix-ag.uni-kl.de/~massar/vpnc/ a allow linux users to connect cisco vpn boxes where a crappy cisco vpn client would be needed otherwise, and it works very nicely. I was hoping there exists a similar tool for juniper vpn. > > Thank you, > Jeroen > > -- > Earthquake Magnitude: 4.0 > Date: Wednesday, November 28, 2012 00:20:46 UTC > Location: Dominican Republic region > Latitude: 19.3090; Longitude: -68.8393 > Depth: 139.00 km From james at freedomnet.co.nz Wed Nov 28 03:38:01 2012 From: james at freedomnet.co.nz (james jones) Date: Tue, 27 Nov 2012 22:38:01 -0500 Subject: juniper vpn In-Reply-To: <60911748-6271-42A3-A47F-2A53F23A79B9@delong.com> References: <50B5762A.6000705@mompl.net> <60911748-6271-42A3-A47F-2A53F23A79B9@delong.com> Message-ID: On Tue, Nov 27, 2012 at 10:27 PM, Owen DeLong wrote: > Do you want one for IPSEC or for the SSL VPN Appliance that Juniper is > pushing nowadays? > > Owen > > On Nov 27, 2012, at 18:25 , Jeroen van Aart wrote: > > > Hello, > > > > Does anyone know a practical and somewhat user friendly way of > connecting to juniper vpn using linux? > > > > I have happily used http://www.unix-ag.uni-kl.de/~massar/vpnc/ a allow > linux users to connect cisco vpn boxes where a crappy cisco vpn client > would be needed otherwise, and it works very nicely. I was hoping there > exists a similar tool for juniper vpn. > > > > Thank you, > > Jeroen > > > > -- > > Earthquake Magnitude: 4.0 > > Date: Wednesday, November 28, 2012 00:20:46 UTC > > Location: Dominican Republic region > > Latitude: 19.3090; Longitude: -68.8393 > > Depth: 139.00 km > > > If you are using the SSL VPN and you should just be able login via the web site. It does require the Sun....eerrr Oracle JRE plugin. From owen at delong.com Wed Nov 28 03:38:22 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Nov 2012 19:38:22 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <01db01cdcd17$1d0e7100$572b5300$@iname.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> <01db01cdcd17$1d0e7100$572b5300$@iname.com> Message-ID: <69ADB141-D40B-4DFB-8FBC-D0863897B78C@delong.com> On Nov 27, 2012, at 19:18 , "Dave Edelman" wrote: > I think that we are missing a significant part of this conversation. > > Even if programmers never write a line of code that invokes IPv6, they need > to accommodate the effects of all the other programmers who aren't writing a > line of IPv6 code. CGN renders most application logs useless unless they > record source port as well as address. For many industries, logging of > transactions in a manner that allows you to track back to the originator of > the transaction is not optional. And yes that does translate to track back > to the ISP who (when presented with the appropriate piece of paper) can > convert the timestamp /IP address/ port combination to the customer who is > responsible for the account. > That won't help. Think about it this way. A session state log entry is roughly 512 bytes. I'm told (by several of the large residential providers) that the average session rate per subscriber is around 33,000 connections/subscriber/day for roughly 17Kbytes/day of log entries per day. Take a carrier like Comcast that has ~20,000,000 subscribers. That's 660,000,000,000 or 660 Terabytes per day of log files. Now, imagine trying to keep that data set for 7 years worth of data. That's a 660*365*7 = 1,686,300 Terabyte (or 1.7 Exabyte) storage array. I'm sure EMC would love to build something like that, but, I'm willing to bet that any economic analysis of that problem against CALEA reveals the relatively swift conclusion that the fines cost less than the infrastructure to preserve the logs. Even if you can cut the session state log entry down to 26 octets (which is only room for 2xSource IPv4 address, 1x destination IPv4 address, 2x Source port#, 1x destination port#, a 32-bit timestamp and a 32-bit subscriber ID), you're still looking at roughly 85 Petabytes of storage required to meet CALEA standards. This doesn't account for the additional costs involved in managing that kind of logging infrastructure, etc. > Even if programmers never write a line of code that invokes IPv6, they had > better be testing their Internet facing applications against users in pure > IPv4 environments; users in pure IPv6 environment using each of the > transition mechanism, and users in dual-stack environments. > That would be ideal, but if they aren't writing any IPv6 code, they probably lack the understanding required in order to do so. > I've spent more than a small amount of time explaining to vendors that > AI_ADDRCONFIG is a really good hint flag to have set. One vendor responded > that the change would require retesting everything. I'm afraid that he > wasn't happy when I pointed out that they obviously hadn't tested the first > time and that as the customer, I was entitled to at least one full set of > (successful) pre-delivery testing. ROFL Owen > > --Dave > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Tuesday, November 27, 2012 6:48 PM >> To: Jared Mauch >> Cc: nanog at nanog.org >> Subject: Re: "Programmers can't get IPv6 thus that is why they do not have >> IPv6 in their applications".... >> >>> >>>> I agree that some of it comes down to knowledge; most programmers >>>> learn from experience and lets face it unless you go looking your >>>> unlikely to run into IPv6 even as of yet. I believe as the ISP >>>> implements IPv6 and companies get more demand on the customer facing >>>> side of things it will pick up quickly. >>> >>> Sure, using gethostbyname() is certainly easier to find code examples, > but >> not impossible to find other examples. >>> >> >> http://owend.corp.he.net/ipv6 >> >> Pretty much everything you need to know about taking your applications >> from mono-stack to dual-stack. >> >> Includes an example application implemented in IPv4 only and ported to > dual >> stack in C, PERL, and Python. >> >>>> In our datacenters all our software is built with IPv6 addressing >>>> supported but we have yet to build the logic stack as we are waiting >>>> for the demand. It makes no sense to build all the support just >>>> because when there are other important things to do. >>> >>> There is something else. Many people "cheated" and stuck a 2^32 number >> in an integer datatype for their SQL or other servers. They don't work as > well >> with 2^128 sized IPs. They have to undertake the actual effort of storing >> their data in a proper datatype instead of cheating. I've seen this > over-and- >> over and likely is a significant impediment just as the gethostbyname vs >> getaddrinfo() system call translations may be. >>> >> >> It's actually pretty easy to change the datatype in an SQL database, so > that >> shouldn't be that much of an impediment. >> >> Owen >> > From asullivan at dyn.com Wed Nov 28 04:18:17 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Tue, 27 Nov 2012 23:18:17 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <20121127214113.E113E2C35F6D@drugs.dv.isc.org> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> Message-ID: <20121128041816.GF1304@dyn.com> On Wed, Nov 28, 2012 at 08:41:13AM +1100, Mark Andrews wrote: > > If they are writing network based code a tunnel broker should not > be a issue. Tunnel brokers are not that hard to use. They are > after all just a VPN and millions of road warriers use them everyday. Oh, for crumb's sake. You're quite right: millions of road worriers use VPNs every day, because they involve downloading a program and the config your IT dept says to use and that's it. Tunnel brokers are the moral equivalent of telling the road warriors, "Go download OpenVPN. Here are credentials. Have a nice day." This is not to criticise tunnel brokers: they're providing a useful service. But really, saying, "Stupid users," is not going to help deployment. Yes, those users include application developers. There is no -- "approaching zero" -- reason for someone in the user-application layer of the stack to care about this today. So the intellectual burden on checking that it works needs to be close to zero, rather than close to whatever the burden is for being an IPv6 early implementer. Manning is right upthread. If the entire deployment path automatically requires 84 layers of NAT sludge, that's what gets tested, cause it "works" for "everybody". A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From rdobbins at arbor.net Wed Nov 28 04:29:08 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 28 Nov 2012 04:29:08 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <20121128041816.GF1304@dyn.com> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> Message-ID: <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> On Nov 28, 2012, at 11:18 AM, Andrew Sullivan wrote: > If the entire deployment path automatically requires 84 layers of NAT sludge, that's what gets tested, cause it "works" for "everybody". Hence my questions regarding the actual momentum behind end-to-end native IPv6 deployment. Inertia is generally only overcome when there's a clear positive economic benefit to doing so - 'savings', assuming there actually are any, are a) almost always exaggerated and b) generally not a powerful enough incentive to alter the status quo. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From swmike at swm.pp.se Wed Nov 28 04:38:24 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 28 Nov 2012 05:38:24 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <50B5147B.7050504@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> Message-ID: On Tue, 27 Nov 2012, mike wrote: > You're saying there are no cellular v6 deployments? I'm about 99% > certain that you're wrong. I see v6 addresses in my apache logs all the > time and they're almost definitely while they're not on wifi (my site > uploads gps data while people are skiing, so they're usually on > cellular). I am in Europe. None of Apple och Microsoft mobile devices will do IPv6 on the mobile side. I don't know if they do special versions for the US market, but for general 3GPP networks, it doesn't work. > Is this the app's fault? What are they doing wrong? They try to detect if there is Internet connectivity and check only IPv4, they use IPv4 literals and other things. I am not an app developer, I do networking, and when I connect IPv6 only to Android or Windows, a lot of things stop working. I haven't tried iPhone but I would believe the situation is similar there. -- Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Wed Nov 28 05:00:24 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Nov 2012 16:00:24 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Tue, 27 Nov 2012 23:18:17 CDT." <20121128041816.GF1304@dyn.com> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> Message-ID: <20121128050025.13ECD2C3A132@drugs.dv.isc.org> In message <20121128041816.GF1304 at dyn.com>, Andrew Sullivan writes: > On Wed, Nov 28, 2012 at 08:41:13AM +1100, Mark Andrews wrote: > > > > If they are writing network based code a tunnel broker should not > > be a issue. Tunnel brokers are not that hard to use. They are > > after all just a VPN and millions of road warriers use them everyday. > > Oh, for crumb's sake. You're quite right: millions of road worriers > use VPNs every day, because they involve downloading a program and > the config your IT dept says to use and that's it. And using some tunnel brokers are just as easy. Even manual config isn't that hard and is a lot easier that getting dialup networking was before ppp was available. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mike at mtcc.com Wed Nov 28 05:04:56 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 27 Nov 2012 21:04:56 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <20121128050025.13ECD2C3A132@drugs.dv.isc.org> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <20121128050025.13ECD2C3A132@drugs.dv.isc.org> Message-ID: <50B59B78.4020807@mtcc.com> On 11/27/2012 09:00 PM, Mark Andrews wrote: > In message <20121128041816.GF1304 at dyn.com>, Andrew Sullivan writes: >> On Wed, Nov 28, 2012 at 08:41:13AM +1100, Mark Andrews wrote: >>> If they are writing network based code a tunnel broker should not >>> be a issue. Tunnel brokers are not that hard to use. They are >>> after all just a VPN and millions of road warriers use them everyday. >> Oh, for crumb's sake. You're quite right: millions of road worriers >> use VPNs every day, because they involve downloading a program and >> the config your IT dept says to use and that's it. > And using some tunnel brokers are just as easy. > > Even manual config isn't that hard and is a lot easier that getting > dialup networking was before ppp was available. > Let's be clear: nobody sets up a VPN because they want to. Mike From rdobbins at arbor.net Wed Nov 28 05:20:39 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 28 Nov 2012 05:20:39 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <20121128050025.13ECD2C3A132@drugs.dv.isc.org> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <20121128050025.13ECD2C3A132@drugs.dv.isc.org> Message-ID: On Nov 28, 2012, at 12:00 PM, Mark Andrews wrote: > And using some tunnel brokers are just as easy. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From asullivan at dyn.com Wed Nov 28 05:24:57 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 28 Nov 2012 00:24:57 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B59B78.4020807@mtcc.com> References: <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <20121128050025.13ECD2C3A132@drugs.dv.isc.org> <50B59B78.4020807@mtcc.com> Message-ID: <20121128052456.GI1304@dyn.com> On Tue, Nov 27, 2012 at 09:04:56PM -0800, Michael Thomas wrote: > Let's be clear: nobody sets up a VPN because they want to. And further, only people who think cell phones are newfangled think that "configuring dial-up before ppp was available" is a test we can apply to _anything_ for the quality "being easy". If any of us seriously thinks that "set up VPN", "configure dial-up by hand", or any other such "easy" things are the bar we have to jump, we are doomed. Big Fat Checkbox that says "Disable Old-Fashioned Network" is about the level we can expect. Past that, forget it. Too much work. Too risky. Boss won't authorize the time. The question upthread about costs is dead on. One of those costs is, "How much do I need to think?" If the answer is, "Oh, just set up a tunnel," the fish is already off the hook and in another river. If your response to that is, "I've been an application developer, and they need to be more responsible," I would like to know your company's stock symbol so I may bet against you. Best, A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From stepp at atistar.net Wed Nov 28 05:32:53 2012 From: stepp at atistar.net (Nigel Stepp) Date: Tue, 27 Nov 2012 21:32:53 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <20121128050025.13ECD2C3A132@drugs.dv.isc.org> Message-ID: <50B5A205.6070204@atistar.net> On 11/27/2012 09:20 PM, Dobbins, Roland wrote: > > On Nov 28, 2012, at 12:00 PM, Mark Andrews wrote: > >> And using some tunnel brokers are just as easy. > > > > ;> When I subscribed I never dreamed I would post anything, as I am not a network engineer, but that also means I'm not cursed in the sense above ;) Just to add some anecdotal fuel to the fire, I'm a programmer who has had an HE tunnel working for several years. None of the programmers I know would have difficulty with that level of configuration. Programmers very often use various kinds of UNIX, and to my eye tunnel configuration is right about at the level of typical UNIX administration. We are also used to reading man pages. So there's one data point with the promise of others. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > -- 1024D/AA1FE38A http://www.atistar.net/~stepp/pgp.html :wq From rdobbins at arbor.net Wed Nov 28 05:47:58 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 28 Nov 2012 05:47:58 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B5A205.6070204@atistar.net> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <20121128050025.13ECD2C3A132@drugs.dv.isc.org> <50B5A205.6070204@atistar.net> Message-ID: <8788D16D-E0FC-4C9D-947E-1019C8C8B806@arbor.net> On Nov 28, 2012, at 12:32 PM, Nigel Stepp wrote: > So there's one data point with the promise of others. You are atypical in comparison the the legions of ordinary developers within enterprise organizations, in terms of your skillset, your breadth of perspective, and your ability to effectuate change within your organization.. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From cb.list6 at gmail.com Wed Nov 28 05:56:50 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 27 Nov 2012 21:56:50 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> Message-ID: Sent from ipv6-only Android On Nov 27, 2012 8:39 PM, "Mikael Abrahamsson" wrote: > > On Tue, 27 Nov 2012, mike wrote: > >> You're saying there are no cellular v6 deployments? I'm about 99% certain that you're wrong. I see v6 addresses in my apache logs all the time and they're almost definitely while they're not on wifi (my site uploads gps data while people are skiing, so they're usually on cellular). > > > I am in Europe. None of Apple och Microsoft mobile devices will do IPv6 on the mobile side. I don't know if they do special versions for the US market, but for general 3GPP networks, it doesn't work. > Verizon in the USA does have iOS on ipv6. Afaik, the network must ask for it the same way all Android Samsung devices on t-mobile now have ipv6 as a user option because it is part of the requirements for the oems. Win phone 8 has a menu option for ipv6 but I don't think it works .... > >> Is this the app's fault? What are they doing wrong? > > > They try to detect if there is Internet connectivity and check only IPv4, they use IPv4 literals and other things. I am not an app developer, I do networking, and when I connect IPv6 only to Android or Windows, a lot of things stop working. I haven't tried iPhone but I would believe the situation is similar there. > Just to quantify, a lot of things stop working = about 15% of the top 200 apps ... names like Skype, Spotify, tango and Netflix fail. Sorry to nit pick, but I want to make sure the scope of the issue is well understood. Meanwhile, 85% of the apps work fine like email (smtp, pop, imap, exchange), gmail, chrome/firefox/opera, facebook, twitter, youtube, words with friends, Google maps, mapquest ... I have been v6-only on mobile for 2 years now, and I feel fine. I am sending this email using a v6-only note2... dogfooding it. Yet, the rotten apples spoil the bunch as the saying goes... and hence 464xlat. CB > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From marka at isc.org Wed Nov 28 06:08:42 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 28 Nov 2012 17:08:42 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Tue, 27 Nov 2012 19:38:22 -0800." <69ADB141-D40B-4DFB-8FBC-D0863897B78C@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> <01db01cdcd17$1d0e7100$572b5300$@iname.com> <69ADB141-D40B-4DFB-8FBC-D0863897B78C@delong.com> Message-ID: <20121128060842.528562C3A89B@drugs.dv.isc.org> In message <69ADB141-D40B-4DFB-8FBC-D0863897B78C at delong.com>, Owen DeLong write s: > > On Nov 27, 2012, at 19:18 , "Dave Edelman" wrote: > > > I think that we are missing a significant part of this conversation.=20= > > >=20 > > Even if programmers never write a line of code that invokes IPv6, they = > need > > to accommodate the effects of all the other programmers who aren't = > writing a > > line of IPv6 code. CGN renders most application logs useless unless = > they > > record source port as well as address. For many industries, logging of > > transactions in a manner that allows you to track back to the = > originator of > > the transaction is not optional. And yes that does translate to track = > back > > to the ISP who (when presented with the appropriate piece of paper) = > can > > convert the timestamp /IP address/ port combination to the customer = > who is > > responsible for the account. > >=20 > > That won't help. Think about it this way. A session state log entry is = > roughly 512 bytes. > > I'm told (by several of the large residential providers) that the = > average session rate per > subscriber is around 33,000 connections/subscriber/day for roughly = > 17Kbytes/day of > log entries per day. > > Take a carrier like Comcast that has ~20,000,000 subscribers. That's = > 660,000,000,000 > or 660 Terabytes per day of log files. Now, imagine trying to keep that = > data set for > 7 years worth of data. That's a 660*365*7 =3D 1,686,300 Terabyte (or 1.7 = > Exabyte) > storage array. I'm sure EMC would love to build something like that, = > but, I'm willing > to bet that any economic analysis of that problem against CALEA reveals = > the > relatively swift conclusion that the fines cost less than the = > infrastructure to preserve > the logs. The fine will be first then the court order to move all the customers to IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From swmike at swm.pp.se Wed Nov 28 06:57:00 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 28 Nov 2012 07:57:00 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> Message-ID: On Tue, 27 Nov 2012, Cameron Byrne wrote: > Verizon in the USA does have iOS on ipv6. Afaik, the network must ask for > it the same way all Android Samsung devices on t-mobile now have ipv6 as a > user option because it is part of the requirements for the oems. I have been trying to locate someone within Apple for months now to speak about IPv6 on their mobile devices. The wall of silence is impressive. The android manufacturers at last respond, even though it's not always the answer I want :P > Win phone 8 has a menu option for ipv6 but I don't think it works .... Yeah, it's like the Galaxy Nexus which has IPv4v6 in the menu but if you use it it asks for an IPv4 PDP context and when it gets it, it falls over and needs to be rebooted. > I have been v6-only on mobile for 2 years now, and I feel fine. I am > sending this email using a v6-only note2... dogfooding it. Yet, the > rotten apples spoil the bunch as the saying goes... and hence 464xlat. Any progress with this, to get this into mainline? Then again, I feel we'll have proper IPv4v6 PDP context before there is any worthwile 464XLAT deployment, but for the long tail I would like to have 464XLAT in all devices. -- Mikael Abrahamsson email: swmike at swm.pp.se From bygg at cafax.se Wed Nov 28 08:53:10 2012 From: bygg at cafax.se (Johnny Eriksson) Date: Wed, 28 Nov 2012 8:53:10 WET Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of Tue, 27 Nov 2012 19:38:22 -0800 Message-ID: Owen DeLong wrote: > Take a carrier like Comcast that has ~20,000,000 subscribers. That's > 660,000,000,000 or 660 Terabytes per day of log files. Now, imagine > trying to keep that data set for 7 years worth of data. That's a > 660*365*7 = 1,686,300 Terabyte (or 1.7 Exabyte) storage array. On my side of the Atlantic pond 660,000,000,000 is 660 Gigabytes. --Johnny From eugen at leitl.org Wed Nov 28 09:41:31 2012 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 28 Nov 2012 10:41:31 +0100 Subject: Integrity of Internet Is Crux of Global Conference Message-ID: <20121128094131.GH9750@leitl.org> http://www.nytimes.com/2012/11/28/technology/dark-warnings-about-future-of-internet-access.html?pagewanted=print November 27, 2012 Integrity of Internet Is Crux of Global Conference By ERIC PFANNER PARIS ? A commercial and ideological clash is set for next week, when representatives of more than 190 governments, along with telecommunications companies and Internet groups, gather in Dubai for a once-in-a-generation meeting. The subject: Control of the Internet, politically and commercially. The stated purpose of the World Conference on International Telecommunications is to update a global treaty on technical standards needed to, say, connect a telephone call from Tokyo to Timbuktu. The previous conference took place in 1988, when the Internet was in its infancy and telecommunications remained a highly regulated, mostly analog-technology business. Now the Internet is the backbone for worldwide communications and commerce. Critics of the International Telecommunication Union, the agency of the United Nations that is organizing the meeting, see a dark agenda in the meeting. The blogosphere has been raging over supposed plans led by Russia to snatch control of the Internet and hand it to the U.N. agency. That seems unlikely. Any such move would require an international consensus, and opposition is widespread. Terry D. Kramer, the former Vodafone executive who is the United States ambassador to the conference, has vowed to veto any change in how the Internet is overseen. Analysts say the real business of the conference is business. ?The far bigger issue ? largely obscured by this discussion ? are proposals that are more likely to succeed that envision changing the way we pay for Internet services,? Michael Geist, an Internet law professor at the University of Ottawa, said by e-mail. Hamadoun Tour?, secretary general of the I.T.U., has repeatedly said that the U.N. group has no desire to take over the Internet or to stifle its growth. On the contrary, he says, one of the main objectives of the conference is to spread Internet access to more of the four and a half billion people around the world who still do not use it. And yet, groups as diverse as Google, the Internet Society, the International Trade Union Confederation and Greenpeace warn that the discussions could set a bad precedent, encouraging governments to step up censorship or take other actions that would threaten the integrity of the Internet. ?This is a very important moment in the history of the Internet, because this conference may introduce practices that are inimical to its continued growth and openness,? Vinton G. Cerf, vice president and chief Internet evangelist at Google, said in a conference call. Google set up a Web site last week, ?Take Action,? encouraging visitors to sign a petition for a ?free and open Internet.? The campaign is modeled on the successful drive last winter to defeat legislative proposals to crack down on Internet piracy in the United States. More energy is expected to be spent on how companies make money off the Internet. In one submission to the conference, the European Telecommunications Network Operators? Association, a lobbying group based in Brussels that represents companies like France T?l?com, Deutsche Telekom and Telecom Italia, proposed that network operators be permitted to assess charges for content providers like Internet video companies that use a lot of bandwidth. Analysts say the proposal is an acknowledgment by European telecommunications companies that they cannot hope to provide digital content. ?The telecoms realize that they have lost the battle,? said Paul Budde, an independent telecommunications analyst in Australia. ?They are saying, ?We can?t beat the Googles and the Facebooks, so let?s try to charge them.? ? The European lobbying group says that without the new fees, there will be no money to invest in network upgrades needed to deal with a surge in traffic. Regulators have required European telecommunications operators to open their networks to rivals, and the market for broadband is fiercely competitive, with rock-bottom prices. In the United States, by contrast, most telecommunications companies have been permitted to maintain local monopolies ? or duopolies, with cable companies ? in broadband, keeping prices higher. And American regulators have ordered broadband providers to give equal priority to all Internet traffic. Such ?network neutrality? is incompatible with charging content providers for moving their bits of data. Analysts say this may explain why American telecommunications companies have not joined the European call for a new business model. ?Models that try to force payment terms between nations and telecom operators run a huge risk of cutting off traffic,? Mr. Kramer said in an interview. ?Liberalized markets are the only way to expand the success of the Internet.? People who have been briefed on the conference submissions say that not a single European government delegation has endorsed the telecommunications operators? proposal, and the European Parliament has passed a resolution denouncing it. Only governments, not private groups or companies, can put items on the meeting agenda. From bjorn at mork.no Wed Nov 28 09:52:32 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 28 Nov 2012 10:52:32 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: (david raistrick's message of "Tue, 27 Nov 2012 16:26:26 -0500 (EST)") References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: <87zk222gwv.fsf@nemi.mork.no> david raistrick writes: > On Tue, 27 Nov 2012, Jeroen Massar wrote: > >> As for actually getting IPv6 at home or at work, there are so many ways >> to get that, thus not having it is a completely ridiculous excuse. > > bull. explain using a tunnel broker to anyone who isn't a network > engineer. Do you really want to run netowrking software written by someone incapable of setting up a test network? This doesn't have anything with tunnel brokers or native access to do at all. Bj?rn From rdobbins at arbor.net Wed Nov 28 09:57:55 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 28 Nov 2012 09:57:55 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <87zk222gwv.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> Message-ID: <0E8931FD-2C82-4A85-BC05-353408DF05CD@arbor.net> On Nov 28, 2012, at 4:52 PM, Bj?rn Mork wrote: > Do you really want to run netowrking software written by someone incapable of setting up a test network? If you don't think you're running some piece or another of software right this minute which was coded by someone incapable of setting up a test network, you're mistaken. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From contact at nullivex.com Wed Nov 28 09:59:18 2012 From: contact at nullivex.com (Bryan Tong) Date: Wed, 28 Nov 2012 02:59:18 -0700 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <87zk222gwv.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> Message-ID: On Wed, Nov 28, 2012 at 2:52 AM, Bj?rn Mork wrote: > david raistrick writes: >> On Tue, 27 Nov 2012, Jeroen Massar wrote: >> >>> As for actually getting IPv6 at home or at work, there are so many ways >>> to get that, thus not having it is a completely ridiculous excuse. >> >> bull. explain using a tunnel broker to anyone who isn't a network >> engineer. > > Do you really want to run netowrking software written by someone > incapable of setting up a test network? This doesn't have anything with > tunnel brokers or native access to do at all. > > I would argue that creating software accesses the network requires some network engineering knowledge to some degree. And if a developer doesnt have that they can depend on a library written by someone who does. > Bj?rn > -- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 From bjorn at mork.no Wed Nov 28 10:05:27 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 28 Nov 2012 11:05:27 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: (Mikael Abrahamsson's message of "Wed, 28 Nov 2012 05:38:24 +0100 (CET)") References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> Message-ID: <87vccq2gbc.fsf@nemi.mork.no> Mikael Abrahamsson writes: > On Tue, 27 Nov 2012, mike wrote: > >> You're saying there are no cellular v6 deployments? I'm about 99% >> certain that you're wrong. I see v6 addresses in my apache logs all >> the time and they're almost definitely while they're not on wifi (my >> site uploads gps data while people are skiing, so they're usually on >> cellular). > > I am in Europe. None of Apple och Microsoft mobile devices will do > IPv6 on the mobile side. They won't do maps either. Does that mean that maps don't exist? Try to keep device bugs and network deployment issues separate. > I don't know if they do special versions for > the US market, but for general 3GPP networks, it doesn't work. IPv6 work just fine in 3GPP networks. Also in Europe. Bj?rn From swmike at swm.pp.se Wed Nov 28 11:01:39 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 28 Nov 2012 12:01:39 +0100 (CET) Subject: Big day for IPv6 - 1% native penetration In-Reply-To: <87vccq2gbc.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> <87vccq2gbc.fsf@nemi.mork.no> Message-ID: On Wed, 28 Nov 2012, Bj?rn Mork wrote: > Try to keep device bugs and network deployment issues separate. Please elaborate. What is a "bug" here? That Galaxy Nexus exposes "IPv4v6" when the baseband module doesn't support it? >> I don't know if they do special versions for >> the US market, but for general 3GPP networks, it doesn't work. > > IPv6 work just fine in 3GPP networks. Also in Europe. I am well aware of this, I work for a mobile provider, trying to deploy IPv6. I have a few devices (usb dongles) that work properly, I have a lot of others that do not. But in order to deploy this in any meaningful way, there need to be handsets that support IPv4v6 bearer continuity on 2G/3G/4G. Until that happens, NAT44 using CGN gives better customer experience. -- Mikael Abrahamsson email: swmike at swm.pp.se From shaavik at soc.lib.md.us Wed Nov 28 11:17:05 2012 From: shaavik at soc.lib.md.us (Steve Haavik) Date: Wed, 28 Nov 2012 06:17:05 -0500 (EST) Subject: juniper vpn In-Reply-To: References: <50B5762A.6000705@mompl.net> <60911748-6271-42A3-A47F-2A53F23A79B9@delong.com> Message-ID: On Tue, 27 Nov 2012, james jones wrote: > If you are using the SSL VPN and you should just be able login via the web > site. It does require the Sun....eerrr Oracle JRE plugin. I'm using a 64-bit Debian install. The version we have here mostly works. Unfortunately Network Connect is the one thing that doesn't work. There is a nice script and instructions at http://mad-scientist.net/juniper.html that does the job for me. If I remember correctly, it'll ask you where you keep your JRE if it can't find the 32-bit version when it starts. From joly at punkcast.com Wed Nov 28 11:55:14 2012 From: joly at punkcast.com (Joly MacFie) Date: Wed, 28 Nov 2012 06:55:14 -0500 Subject: =?windows-1252?Q?Mitigating_DDoS_Attacks=3A_Best_Practices_for_an_Evolv?= =?windows-1252?Q?ing_Threat_Landscape_=96_NYC_12=2F5?= Message-ID: [I wouldn't normally post our event notices to NANOG but I figure this might be of interest. Any of you in the NYC area we'd very much like to see you. I will tape it and post again when that's up -j] The Internet Society?s New York Chapter (ISOC-NY ) and the New York Technology Council (NYTECH ) will join the Public Interest Registry (PIR ) in presenting a midday symposium ?Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape ? in New York City on December 5 2012. Participating organizations include Afilias, Google, Neustar, M3AAWG, Symantec, EFF, and De Natris Consult. As a public service PIR are generously covering the $99 fee for all attendees ? thus registration is free! The event will be webcast live via the Internet Society Chapters Livestream Channel. Distributed Denial of Service (DDoS) attacks are an all-too-common reality in today?s Internet landscape and are an escalating global problem. Whether a DDoS attack is motivated by criminal intent, like cyber extortion, or is executed as an extreme form of free expression, the resulting service interruptions can have wide-ranging effects. This program will address the motives behind and targets of DDoS attacks. It will also explore the various ways attacks are carried out, as well as mitigation techniques and the risks of ?unintended consequences.? The goal is to foster a discussion and provide a platform for developing a framework of best practices to mitigate DDoS attacks. *What*: Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape *When*: Wednesday December 5 2012 1000-1300 EST | 1500-1800 UTC *Where*: AMA Executive Conference Center, 1601 Broadway, 8th Floor, New York, NY 10019 *Program*: http://www.pir.org/why/security/ddos *Webcast*: http://www.livestream.com/internetsocietychapters *Register*: http://www.regonline.com/Register/Checkin.aspx?EventId=1108367 * **** *Twitter*: #DDoS **** Registration is not required for the webcast, just for in person attendance. Space is limited, please do not register unless you truly intend to come.**** -- --------------------------------------------------------------- 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 bjorn at mork.no Wed Nov 28 12:23:39 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 28 Nov 2012 13:23:39 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <0E8931FD-2C82-4A85-BC05-353408DF05CD@arbor.net> (Roland Dobbins's message of "Wed, 28 Nov 2012 09:57:55 +0000") References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <0E8931FD-2C82-4A85-BC05-353408DF05CD@arbor.net> Message-ID: <878v9l3ohg.fsf@nemi.mork.no> "Dobbins, Roland" writes: > On Nov 28, 2012, at 4:52 PM, Bj?rn Mork wrote: > >> Do you really want to run netowrking software written by someone incapable of setting up a test network? > > If you don't think you're running some piece or another of software > right this minute which was coded by someone incapable of setting up a > test network, you're mistaken. Maybe so. But do I _want_ do run that software? No. Anyway, I am not sure which programs that would be. The applications with open sockets on my laptop are currently: cupsd dhclient emacs gpsd gvfsd-http inetd mysqld named netserver ntpd rpcbind rpc.statd (squid) ssh sshd This is of course not a complete list of all applications I need to verify. I should add a number of client applications not currently running, and inetd may fire up proftpd and atftpd when necessary. But FWIW the only suspicious application I can see on that initial list is gvfsd-http. I don't know anything about the programmers behind that. I am pretty sure the people behind the rest of the software are capable of setting up a test network. Bj?rn From david.binet at orange.com Wed Nov 28 13:33:50 2012 From: david.binet at orange.com (david.binet at orange.com) Date: Wed, 28 Nov 2012 14:33:50 +0100 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> Message-ID: <17240_1354109633_50B612C1_17240_58_1_1B2E7539FECD9048B261B791B1B24A7C3EF6139C97@PUEXCB1A.nanterre.francetelecom.fr> Hi, > -----Message d'origine----- > De : Mikael Abrahamsson [mailto:swmike at swm.pp.se] > Envoy? : mercredi 28 novembre 2012 07:57 > ? : nanog at nanog.org > Objet : Re: Big day for IPv6 - 1% native penetration > > On Tue, 27 Nov 2012, Cameron Byrne wrote: > > > Verizon in the USA does have iOS on ipv6. Afaik, the > network must ask > > for it the same way all Android Samsung devices on t-mobile > now have > > ipv6 as a user option because it is part of the > requirements for the oems. > > I have been trying to locate someone within Apple for months > now to speak about IPv6 on their mobile devices. The wall of > silence is impressive. > > The android manufacturers at last respond, even though it's > not always the answer I want :P Mobile operators have some difficulties to get some IPv6 terminals.It is the reason why we have proposed an IETF draft to define some IPv6 profile for mobile terminals (https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirements/) IMHO it is strategic to get a document that specifies such profile. It is important that such draft becomes a WG document so all support for such draft on IETF v6ops ML is welcome. Such document will not replace discussions we may have with vendors but it is for sure a useful contribution to our common objective. > > > Win phone 8 has a menu option for ipv6 but I don't think it > works .... > > Yeah, it's like the Galaxy Nexus which has IPv4v6 in the menu > but if you use it it asks for an IPv4 PDP context and when it > gets it, it falls over and needs to be rebooted. > > > I have been v6-only on mobile for 2 years now, and I feel > fine. I am > > sending this email using a v6-only note2... dogfooding it. Yet, the > > rotten apples spoil the bunch as the saying goes... and > hence 464xlat. > > Any progress with this, to get this into mainline? > > Then again, I feel we'll have proper IPv4v6 PDP context > before there is any worthwile 464XLAT deployment, but for the > long tail I would like to have 464XLAT in all devices. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. From tdurack at gmail.com Wed Nov 28 14:05:03 2012 From: tdurack at gmail.com (Tim Durack) Date: Wed, 28 Nov 2012 09:05:03 -0500 Subject: 1310nm optics over Corning LEAF G.655? In-Reply-To: References: Message-ID: On Fri, Jun 1, 2012 at 2:18 PM, Tim Durack wrote: > Anyone run 1000BASE-LX/10GBASE-LR 1310nm optics over a ~10km Corning > LEAF G.655 span? > > I understand this fiber is not optimized for such usage, but what is > the real-world behaviour? I'm having a hard time finding hard data. > > (Normal optics will be 1550nm and DWDM over ~40-100km spans.) > > -- > Tim:> > For the record, 1000BASE-LX 1310nm 10km and 20km rated optics did not work across this span. Based on loss measurements, this was not due to optical budget. This may be due to the cutoff wavelength of this fiber being 1360nm. 1000BASE-LX 1310nm 40km rated optics worked (with a 10dB attenuator.) 1000BASE-ZX 1550nm 80km rated optics worked (with a 10dB attenuator.) Hope that helps someone in the future. If anyone has any comments, I would be interested to hear (either pm or public.) Thanks, -- Tim:> From cb.list6 at gmail.com Wed Nov 28 14:35:29 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 28 Nov 2012 06:35:29 -0800 Subject: Big day for IPv6 - 1% native penetration In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <1BB79A88-7C7F-4B1A-BE50-6B7DC33199B7@arbor.net> <010101cdcbfc$dab478b0$901d6a10$@tndh.net> <38EB330C-0FE2-4EFA-A61A-E4A6C0422806@arbor.net> <50B4019D.9080807@mtcc.com> <50B5147B.7050504@mtcc.com> Message-ID: Sent from ipv6-only Android On Nov 27, 2012 10:57 PM, "Mikael Abrahamsson" wrote: > > On Tue, 27 Nov 2012, Cameron Byrne wrote: > >> Verizon in the USA does have iOS on ipv6. Afaik, the network must ask for >> it the same way all Android Samsung devices on t-mobile now have ipv6 as a >> user option because it is part of the requirements for the oems. > > > I have been trying to locate someone within Apple for months now to speak about IPv6 on their mobile devices. The wall of silence is impressive. > > The android manufacturers at last respond, even though it's not always the answer I want :P > > >> Win phone 8 has a menu option for ipv6 but I don't think it works .... > > > Yeah, it's like the Galaxy Nexus which has IPv4v6 in the menu but if you use it it asks for an IPv4 PDP context and when it gets it, it falls over and needs to be rebooted. > > >> I have been v6-only on mobile for 2 years now, and I feel fine. I am sending this email using a v6-only note2... dogfooding it. Yet, the rotten apples spoil the bunch as the saying goes... and hence 464xlat. > > > Any progress with this, to get this into mainline? > Yes, there has been progress. These code parts have been merged into mainline Android code base. Time to start bugging the oems, since it is merged at the aosp level. There are still a peice pending review, but there is enough merged code to get the ball rolling for sure https://android-review.googlesource.com/#/q/owner:dan-android%2540drown.org+status:merged,n,z > Then again, I feel we'll have proper IPv4v6 PDP context before there is any worthwile 464XLAT deployment, but for the long tail I would like to have 464XLAT in all devices. > > Maybe. But the goal is to get rid of ipv4 constraints on the ue, not simply a foot race. But if 464xlat wins that race too, great. CB > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From 2asx1y702 at sneakemail.com Wed Nov 28 14:53:42 2012 From: 2asx1y702 at sneakemail.com (2asx1y702 at sneakemail.com) Date: Wed, 28 Nov 2012 14:53:42 +0000 Subject: Middle East MPLS Message-ID: <28372-1354114422-467659@sneakemail.com> Anyone from Etisalat on list? I'm interested in some MPLS connectivity into Dubai. kyle(at)epic(dot)com From rdobbins at arbor.net Wed Nov 28 15:27:44 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 28 Nov 2012 15:27:44 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <878v9l3ohg.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <0E8931FD-2C82-4A85-BC05-353408DF05CD@arbor.net> <878v9l3ohg.fsf@nemi.mork.no> Message-ID: <6C528AD9-5392-402B-BC70-37708998AEB4@arbor.net> On Nov 28, 2012, at 7:23 PM, Bj?rn Mork wrote: > Anyway, I am not sure which programs that would be. You run a lot more than that in your everyday life. And if you don't, you're atypical. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From tony.mccrory at gmail.com Wed Nov 28 15:32:09 2012 From: tony.mccrory at gmail.com (Tony McCrory) Date: Wed, 28 Nov 2012 15:32:09 +0000 Subject: Middle East MPLS In-Reply-To: <28372-1354114422-467659@sneakemail.com> References: <28372-1354114422-467659@sneakemail.com> Message-ID: Make sure you're sitting down when you read the quote. On 28 November 2012 14:53, <2asx1y702 at sneakemail.com> wrote: > Anyone from Etisalat on list? I'm interested in some MPLS connectivity > into Dubai. > > kyle(at)epic(dot)com > > From rps at maine.edu Wed Nov 28 15:35:13 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Nov 2012 10:35:13 -0500 Subject: PHP library for IOS devices Message-ID: Quick note as many on-list may find this useful. I've maintained a PHP class to connect to IOS devices over telnet and parse the output into something useful for various internal tools for a few years now. I've recently worked with the author of phpseclib to create an SSH version of the library. It's still in a pre-release state until I have time to clean it up, but I've uploaded an archive of the SSH version and the modified phpseclib for anyone who needs in the meantime. You can find it at the bottom of the Cisco for PHP page: http://soucy.org/project/cisco/ -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From drais at icantclick.org Wed Nov 28 16:30:32 2012 From: drais at icantclick.org (david raistrick) Date: Wed, 28 Nov 2012 11:30:32 -0500 (EST) Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <87zk222gwv.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> Message-ID: On Wed, 28 Nov 2012, Bj?rn Mork wrote: > Do you really want to run netowrking software written by someone > incapable of setting up a test network? This doesn't have anything with > tunnel brokers or native access to do at all. So the software engineer should now -also- be responsible for, and capable of, recreating both the network as well as 3rd party systems that he/she has to code against? again focusing on just our last title release - 20+ 3rd party interfaces run by 6 different companies. Is the software engineer really responsible for faking things like xbox live, PSN, facebook, twitter, google, etc on a test network? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From jeroen at unfix.org Wed Nov 28 17:00:00 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 28 Nov 2012 18:00:00 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> Message-ID: <50B64310.50905@unfix.org> On 2012-11-28 17:30 , david raistrick wrote: > On Wed, 28 Nov 2012, Bj?rn Mork wrote: > >> Do you really want to run netowrking software written by someone >> incapable of setting up a test network? This doesn't have anything with >> tunnel brokers or native access to do at all. > > So the software engineer should now -also- be responsible for, and > capable of, recreating both the network as well as 3rd party systems > that he/she has to code against? > > again focusing on just our last title release - 20+ 3rd party interfaces > run by 6 different companies. Is the software engineer really > responsible for faking things like xbox live, PSN, facebook, twitter, > google, etc on a test network? Not for faking it, but in the case you mention it is very obvious that the software engineer should be able to ask their network team to make sure that they can access those API's if only for testing... In IPv6 that goes the same way: - either ask the local network team to get it for you - do it yourself Which might mean the person actually arranging it gets native or some kind of tunnel. And still, if you as a proper engineer where not able to test/add IPv6 code in the last 10++ years, then you did something very very wrong in your job, the least of which is to file a ticket for IPv6 support in the ticket tracking system so that one could state "I thought of it, company did not want it". Oh and remember: one can EASILY test this on a local network, link-local works fine, and one can also set up ULA or heck fake addresses to test this, or heck, loopback is also a great thing. Yes, that does not cover all scenarios, but it does cover most basic connectivity. Greets, Jeroen From drais at icantclick.org Wed Nov 28 17:11:23 2012 From: drais at icantclick.org (david raistrick) Date: Wed, 28 Nov 2012 12:11:23 -0500 (EST) Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B64310.50905@unfix.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <50B64310.50905@unfix.org> Message-ID: On Wed, 28 Nov 2012, Jeroen Massar wrote: > Not for faking it, but in the case you mention it is very obvious that > the software engineer should be able to ask their network team to make > sure that they can access those API's if only for testing... You're assuming, now, that the network team either a) works for the same arm of the company as the development team, and therefor can apply pressure on them or b) has support to build v6 into the system already (so they have time and resources to support the dev team), or c) gives a foo at all. Not to mention the time the dev team will spend spinning its wheels. Now, yes - if "ipv6 support" is a feature of the product they're building (and so driven and supported by management or marketing teams) then things could work as you suggest. But until such time as v6 support is something that they care about upstream...well. The 2 days of time you were budgeted to build the tool/feature/etc you're supposed to be working on isn't really going to include time to get v6 support in. > your job, the least of which is to file a ticket for IPv6 support in the > ticket tracking system so that one could state "I thought of it, company > did not want it". funnily enough that's -exactly- what I've been doing for the last 3 years. So, until it comes down from the top, the company doesn't want it. ...david (who is not a developer and is a network engineer, but not in this job) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From bjorn at mork.no Wed Nov 28 17:18:25 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 28 Nov 2012 18:18:25 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: (david raistrick's message of "Wed, 28 Nov 2012 11:30:32 -0500 (EST)") References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> Message-ID: <87lidl1w9q.fsf@nemi.mork.no> david raistrick writes: > On Wed, 28 Nov 2012, Bj?rn Mork wrote: > >> Do you really want to run netowrking software written by someone >> incapable of setting up a test network? This doesn't have anything with >> tunnel brokers or native access to do at all. > > So the software engineer should now -also- be responsible for, and > capable of, recreating both the network as well as 3rd party systems > that he/she has to code against? I am not claiming that every engineer in a big project should have all knowledge necessary to complete the project, or have the responsibility for every task in the project. But defining and configuring a suitable test environment is an absolute requirement for any software project. So *someone* in a network software development project will need to know how to set up networking for the testing. > again focusing on just our last title release - 20+ 3rd party > interfaces run by 6 different companies. Is the software engineer > really responsible for faking things like xbox live, PSN, facebook, > twitter, google, etc on a test network? If your application interface with those services and you expect those parts of the application to work, then I'd say so, yes. There may be occasional exceptions from this rule, but most of the time you'll find that any untested parts of an application does not work. Now I'd guess that most of those services also offer a test environment. You will of course primarily use that. The claim wrt IPv6 was that it was too difficult to use existing test enviroments. The degree of real world simulation you need for testing will of course vary. It's not like a hobbyist Android app developer must set up his own cellular network. Running the app in an emulator is likely enough for most uses, including IPv6 testing. This discussion seem to go off into the wild, so I am not sure there is any point continuing it. But I will absolutely refuse the idea that anyone incapable of getting their application tested with IPv6 are able to create any useful networking software. That's simply not possible. If it fails on IPv6 then it is guaranteed to fail on IPv4 as well, only less obvious ond therefore more dangerous. The claim that missing IPv6 support in software has anything to do with the lack of native IPv6 internet access is just stupid. You may wonder how anyone could develop a new protocol, or microcode for a new CPU, or a driver for a new hardware device, or anything at all really. You just cannot count on having access to a full scale production environment during software development. You will have to find some way to simulate the missing parts. Native IPv6 internet access has never been a requirement for developing IPv6 aware applications. That was a bad excuse even 10 years ago. Today it is just ridiculous. Bj?rn From drais at icantclick.org Wed Nov 28 17:21:10 2012 From: drais at icantclick.org (david raistrick) Date: Wed, 28 Nov 2012 12:21:10 -0500 (EST) Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <878v9l3ohg.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <0E8931FD-2C82-4A85-BC05-353408DF05CD@arbor.net> <878v9l3ohg.fsf@nemi.mork.no> Message-ID: On Wed, 28 Nov 2012, Bj?rn Mork wrote: > Maybe so. But do I _want_ do run that software? No. > > Anyway, I am not sure which programs that would be. The applications > with open sockets on my laptop are currently: I take it you're in the minority who don't play games, use mobile apps on your phone, use a dvr....... or any SaaS applications accessable via the web, or indeed visit websites with shopping cart software, or CRM software, or blogs, or.... the large majority of software that interfaces to v4 networks does so through libraries and frameworks that seperate that part of the application stack from the part that the developer is building his code in. So really and truly most software is written by developers who can barely plug and play their home networks, much less actually understand what dhcp means. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From mike at mtcc.com Wed Nov 28 17:26:05 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 28 Nov 2012 09:26:05 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B64310.50905@unfix.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <50B64310.50905@unfix.org> Message-ID: <50B6492D.1050804@mtcc.com> On 11/28/2012 09:00 AM, Jeroen Massar wrote: > > And still, if you as a proper engineer where not able to test/add IPv6 > code in the last 10++ years, then you did something very very wrong in > your job, the least of which is to file a ticket for IPv6 support in the > ticket tracking system so that one could state "I thought of it, company > did not want it". > It's very presumptuous for you to tell me what my development/test priorities ought to be, and I can tell you for absolute certain that any such badgering will be met with rolled eyes and quick dismissal. The only way that things will get fixed is if there's a perceived need to fix them. Getting corpro-IT to upgrade to v6 -- as if there is even a corpro-anything with most phone apps -- just to be able to test against v6 is a fantasy. Any developer who told me that we can't ship because we don't have a v6 testbed without clear feedback via bug reports, etc would be instructed on the difficulties of applying sufficient thermal energy to large bodies of water. The only way things are going to change is to make v6 a part of everybody's day-to-day life. That means ISP's giving me and every other developer a /64 at home at the very least. Mike From drais at icantclick.org Wed Nov 28 17:28:56 2012 From: drais at icantclick.org (david raistrick) Date: Wed, 28 Nov 2012 12:28:56 -0500 (EST) Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <87lidl1w9q.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> Message-ID: On Wed, 28 Nov 2012, Bj?rn Mork wrote: > Native IPv6 internet access has never been a requirement for developing > IPv6 aware applications. That was a bad excuse even 10 years ago. Today > it is just ridiculous. I certainly never said that was the case. I built v6 test networks, and helped kernel devs build v6 support into firewall appliances 10 years ago. But it wasn't a feature that drove sales... My argument is that a) typical developers don't develop microcode, kernel drivers, or protocols. But they DO build a lot of applications that sit on top of them. They build them because someone is paying them to do it. The folks that sign the checks ask for A B and C. And v6 isn't one of those things yet. Some day, maybe it will be. We're just not there yet. (yes. when we get there it's going to be too late. no argument.) in the meantime there's still a ton of new and old stuff to build w/o v6 support from our internal or external vendors. ...david -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From swmike at swm.pp.se Wed Nov 28 17:45:54 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 28 Nov 2012 18:45:54 +0100 (CET) Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> Message-ID: On Wed, 28 Nov 2012, david raistrick wrote: > folks that sign the checks ask for A B and C. And v6 isn't one of those > things yet. I believe they ask for the apps to work on the "Internet". Part of that requirement is soon to be a requirement for IPv6 support. I believe the person signing the checks never asked for IPv4 support. -- Mikael Abrahamsson email: swmike at swm.pp.se From mansaxel at besserwisser.org Wed Nov 28 18:29:54 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 28 Nov 2012 19:29:54 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> Message-ID: <20121128182954.GB25469@besserwisser.org> Subject: Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... Date: Wed, Nov 28, 2012 at 06:45:54PM +0100 Quoting Mikael Abrahamsson (swmike at swm.pp.se): > I believe they ask for the apps to work on the "Internet". Part of > that requirement is soon to be a requirement for IPv6 support. It is so already. IPv6 Support Required for All IP-Capable Nodes Abstract Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application. RFC 6540 / BCP 177 > I believe the person signing the checks never asked for IPv4 support. Probably not. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... this must be what it's like to be a COLLEGE GRADUATE!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From davidpeahi at gmail.com Wed Nov 28 18:30:50 2012 From: davidpeahi at gmail.com (david peahi) Date: Wed, 28 Nov 2012 10:30:50 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B52B74.4070606@unfix.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: Many years ago the standard books on application network programming were based on C language. Books such as "Adventures in UNIX Network Programming", and Professor Comer's "Internetworking with TCP/IP Vol 3" detailed how to write C programs using BSD sockets where binding to a socket brought the program up in listening mode on an 2 tuple IP v4 IP address/TCP well known port. Once the program opened and bound to a socket "netstat -n" would show that program to be "listening" on the 2-tuple. Do today's programmers still use basic BSD socket programming? Is there an equivalent set of called procedures for IPv6 network application programming? On the practical side: Have all programmers created a 128 bit field to store the IPv6 address, where IPv4 programs use a 32 bit field to store the IP address? This would seem to be similar to the year 2000 case where almost all programs required auditing to see if they took into account dates after 1999. David On Tue, Nov 27, 2012 at 1:07 PM, Jeroen Massar wrote: > On 2012-11-27 20:21, mike wrote: > > On 11/26/12 9:32 PM, Mikael Abrahamsson wrote: > >> > >> The main problem with IPv6 only is that most app developers (most > >> programmers totally) do not really have access to this, so no testing > >> is being done. > >> > > This is a point that is probably more significant than is > > appreciated. If the app, IT, and networking ecosystem don't even have > > access to ipv6 to play around with, you can be guaranteed that they > > are going to be hesitant about lighting v6 up in real life. > > I cannot be saf for the people who claim to be programmers who do things > with networking and who do not care to follow the heavy hints that they > have been getting for at least the last 10 years that their applications > need to start supporting IPv6. Especially as APIs like getaddrinfo() > make it really easy to do so. > > The following excellent article by our beloved true IPv6 Samuarai Itojun > is from 1998: http://www.kame.net/newsletter/19980604/ > > Thus it is not like the information is not out there either. > > As for actually getting IPv6 at home or at work, there are so many ways > to get that, thus not having it is a completely ridiculous excuse. > (It might not be native, so wh00p, you can test fine also on a local > link in the extreme case) > > Remember that silly thing called the 6bone and what the purpose of that > was back then, indeed, for getting connectivity to the people so that > they could fix their code and that ran from 1996 till 2006, 10 years > where one could have fixed up those apps that was already 6 years ago > again. > > As such, if an application does not do proper IPv6 today the people in > charge of the thing simply did not care... > > Greets, > Jeroen > who proudly has been providing IPv6 connectivity and IPv6 patches for > over more than a decade... > > > From swmike at swm.pp.se Wed Nov 28 18:47:06 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 28 Nov 2012 19:47:06 +0100 (CET) Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: On Wed, 28 Nov 2012, david peahi wrote: > On the practical side: Have all programmers created a 128 bit field to > store the IPv6 address, where IPv4 programs use a 32 bit field to store > the IP address? This would seem to be similar to the year 2000 case > where almost all programs required auditing to see if they took into > account dates after 1999. The new APIs have been around since about that time ~2000. ... but a few. I am sure there is a lot of new and old code using the old APIs. I wish there would be a WARN or equivalent in the APIs to tell the devs that they're using a old (should be deprecated :P) API call. -- Mikael Abrahamsson email: swmike at swm.pp.se From if at xip.at Wed Nov 28 18:47:37 2012 From: if at xip.at (Ingo Flaschberger) Date: Wed, 28 Nov 2012 19:47:37 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: <50B65C49.6070909@xip.at> Am 28.11.2012 19:30, schrieb david peahi: > Many years ago the standard books on application network programming were > based on C language. Books such as "Adventures in UNIX Network > Programming", and Professor Comer's "Internetworking with TCP/IP Vol 3" > detailed how to write C programs using BSD sockets where binding to a > socket brought the program up in listening mode on an 2 tuple IP v4 IP > address/TCP well known port. Once the program opened and bound to a socket > "netstat -n" would show that program to be "listening" on the 2-tuple. > > Do today's programmers still use basic BSD socket programming? Is there an > equivalent set of called procedures for IPv6 network application > programming? > > On the practical side: Have all programmers created a 128 bit field to > store the IPv6 address, where IPv4 programs use a 32 bit field to store the > IP address? This would seem to be similar to the year 2000 case where > almost all programs required auditing to see if they took into account > dates after 1999. on linux/unix: if the program only opens a tcp-connection or listen on it, it's simple. socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) -> socket = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) It's more work, to build a dual-stack program - then 2 sockets needs to be opened and handled. But overall - it's trivial. y2k: the will be app's that will it never made to ipv6 - but you can do ipv6->ipv4 translation NAT-PT (RFC2766) Kind regards, Ingo Flaschberger From owen at delong.com Wed Nov 28 19:37:10 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Nov 2012 11:37:10 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B65C49.6070909@xip.at> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <50B65C49.6070909@xip.at> Message-ID: On Nov 28, 2012, at 10:47 AM, Ingo Flaschberger wrote: > Am 28.11.2012 19:30, schrieb david peahi: >> Many years ago the standard books on application network programming were >> based on C language. Books such as "Adventures in UNIX Network >> Programming", and Professor Comer's "Internetworking with TCP/IP Vol 3" >> detailed how to write C programs using BSD sockets where binding to a >> socket brought the program up in listening mode on an 2 tuple IP v4 IP >> address/TCP well known port. Once the program opened and bound to a socket >> "netstat -n" would show that program to be "listening" on the 2-tuple. >> >> Do today's programmers still use basic BSD socket programming? Is there an >> equivalent set of called procedures for IPv6 network application >> programming? >> >> On the practical side: Have all programmers created a 128 bit field to >> store the IPv6 address, where IPv4 programs use a 32 bit field to store the >> IP address? This would seem to be similar to the year 2000 case where >> almost all programs required auditing to see if they took into account >> dates after 1999. > > on linux/unix: if the program only opens a tcp-connection or listen on it, it's simple. > socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) -> socket = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) > You left out some structure changes an the need to use getaddrinfo()/getnameinfo() in place of get*by*(). Depending on your implementation, you might also need to make some changes to your bind() call and/or the way you iterate through the returns from getaddrinfo() calling connect(). > It's more work, to build a dual-stack program - then 2 sockets needs to be opened and handled. > But overall - it's trivial. Not if your system properly supports IPV6_V6ONLY=false default sock opt. If you're stuck on something based on BSD or WinSock where this is broken, then, yes, you may have to open 2 sockets or at the very least make a deliberate setsockopt() call or specify the option in the socket() call. Owen From alh-ietf at tndh.net Wed Nov 28 20:04:08 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 28 Nov 2012 12:04:08 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> Message-ID: <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> Dobbins, Roland wrote: > On Nov 28, 2012, at 11:18 AM, Andrew Sullivan wrote: > > > If the entire deployment path automatically requires 84 layers of NAT > sludge, that's what gets tested, cause it "works" for "everybody". > > Hence my questions regarding the actual momentum behind end-to-end > native IPv6 deployment. Inertia is generally only overcome when there's a > clear positive economic benefit to doing so - 'savings', assuming there > actually are any, are a) almost always exaggerated and b) generally not a > powerful enough incentive to alter the status quo. That is why the preference is biased toward IPv6 when it is available. If you expect the end users to make a conscious choice it will never happen. If the underlying OS components make that choice for them, you end up with a transition. Open the page that Tim Chown sent out : http://6lab.cisco.com/stats/ Select World-scale data : then open IPv6 Prefix & User graphs. Look at the correlation between IPv6-alive prefixes & user %. Those users never made a conscious choice, the OS did it as soon as it had a path to the target. As more prefixes light up, the 'unconscious pent up demand' will make that User curve even steeper. The primary bottleneck at this point is and will be CPE. Fixing that will likely require a financial incentive to get consumers to 'upgrade' their working box. Normal lifecycle replacements will take a long time, requiring larger investments in cgn's, so as soon as the new cpe is available in sufficient quantity at a reasonable price point, any MBA can go make the case you are looking for about why it is cheaper to do a cpe subsidy than it is to invest in a never-ending cgn saga (if they can't figure it out have someone hire an MBA from the mobile providers who transition handsets off the old network all the time). Getting the cpe vendors to ship in quantity requires the ISP engineering organizations to say in unison "we are deploying IPv6 and will only recommend products that pass testing". As long as there are voices calling for 444nat in the flavor-of-the-week, cpe vendors will not focus on the long term goal, because they will see the interim steps as opportunity to extract more cash for short-life products. So will infrastructure vendors for that matter. Indecision and scatter-shot approaches only increase the number of things that need to be bought, deployed, and operated. That overall additional cost is a complete waste to the operator / end user, and clear profit for the vendors. You claim to be looking for the economic incentive, but are looking with such a short time horizon that all you see are the 'waste' products vendors are pushing to make a quick sale, knowing that you will eventually come back for yet-another-hack to delay transition, and prop up your expertise in a legacy technology. The same thing happened with the SNA faithful 15 years ago, and history shows what happened there. Tony From jeroen at mompl.net Wed Nov 28 20:09:07 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 28 Nov 2012 12:09:07 -0800 Subject: juniper vpn In-Reply-To: References: <50B5762A.6000705@mompl.net> Message-ID: <50B66F63.30601@mompl.net> On 11/27/2012 07:14 PM, Cody Rose wrote: > I have had great success with the Shrew Soft vpn client and if you are > using Fedora it is only a 'yum install ike' away and works without root > and properly utilizes the tap interface while installing the proper > routes needed to get traffic going. > http://www.shrew.net/home Thank you I will try it out. To answer another question, I am not sure whether it is ipsec or ssl vpn, however since it's known that the en user experience is less than optimal I presume it's the ipsec variety. Thank you, Jeroen -- Earthquake Magnitude: 4.8 Date: Wednesday, November 28, 2012 18:05:30 UTC Location: Catamarca, Argentina Latitude: -27.8486; Longitude: -66.4048 Depth: 154.40 km From surfer at mauigateway.com Wed Nov 28 20:31:07 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 28 Nov 2012 12:31:07 -0800 Subject: Middle East MPLS Message-ID: <20121128123107.4169E09C@m0005312.ppops.net> --- 2asx1y702 at sneakemail.com wrote: Anyone from Etisalat on list? I'm interested in some MPLS connectivity into Dubai. ------------------------------------ Try on the MENOG list. scott From richard.barnes at gmail.com Wed Nov 28 20:36:50 2012 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 28 Nov 2012 15:36:50 -0500 Subject: Middle East MPLS In-Reply-To: <20121128123107.4169E09C@m0005312.ppops.net> References: <20121128123107.4169E09C@m0005312.ppops.net> Message-ID: Where MENOG list == menog at menog.net http://www.menog.org/ On Wed, Nov 28, 2012 at 3:31 PM, Scott Weeks wrote: > > > --- 2asx1y702 at sneakemail.com wrote: > > Anyone from Etisalat on list? I'm interested in some MPLS connectivity > into Dubai. > ------------------------------------ > > > > Try on the MENOG list. > > scott > > > > From wbailey at satelliteintelligencegroup.com Wed Nov 28 21:09:37 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 28 Nov 2012 21:09:37 +0000 Subject: Middle East MPLS In-Reply-To: <20121128123107.4169E09C@m0005312.ppops.net> References: <20121128123107.4169E09C@m0005312.ppops.net> Message-ID: Go through a middle man. Getting anything in the UAE is really difficult and usually requires a ton of interaction with the government. Also, I try to keep the capacity private, in that a POP to the Internet in Dubai generally goes through their firewalls. I think we used Verizon Business or reach. >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Scott Weeks Date: 11/28/2012 12:33 PM (GMT-08:00) To: nanog at nanog.org Subject: Re: Middle East MPLS --- 2asx1y702 at sneakemail.com wrote: Anyone from Etisalat on list? I'm interested in some MPLS connectivity into Dubai. ------------------------------------ Try on the MENOG list. scott From jeroen at mompl.net Wed Nov 28 21:19:59 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 28 Nov 2012 13:19:59 -0800 Subject: juniper vpn In-Reply-To: <60911748-6271-42A3-A47F-2A53F23A79B9@delong.com> References: <50B5762A.6000705@mompl.net> <60911748-6271-42A3-A47F-2A53F23A79B9@delong.com> Message-ID: <50B67FFF.1030205@mompl.net> On 11/27/2012 07:27 PM, Owen DeLong wrote: > Do you want one for IPSEC or for the SSL VPN Appliance that Juniper is pushing nowadays? I just checked, the script i am looking at calls the ncscv tool which I believe is made by juniper? It needs amongst other things an ssl certificate. So I presume it's using the latter. This tool/script did download a certificate, however it appears to be a binary file, not the usual plain text file. Is there a way to retrieve the plaintext one or extract it from the binary file? Using "file" identifies it as a data file. Thanks, Jeroen -- Earthquake Magnitude: 4.8 Date: Wednesday, November 28, 2012 18:05:30 UTC Location: Catamarca, Argentina Latitude: -27.8486; Longitude: -66.4048 Depth: 154.40 km From mike at mtcc.com Wed Nov 28 21:28:16 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 28 Nov 2012 13:28:16 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: <50B681F0.9010000@mtcc.com> On 11/28/2012 10:30 AM, david peahi wrote: > On the practical side: Have all programmers created a 128 bit field to > store the IPv6 address, where IPv4 programs use a 32 bit field to store the > IP address? This would seem to be similar to the year 2000 case where > almost all programs required auditing to see if they took into account > dates after 1999. > Surely you mean varchar(15), right? :) Mike From lee at asgard.org Wed Nov 28 21:54:08 2012 From: lee at asgard.org (Lee Howard) Date: Wed, 28 Nov 2012 16:54:08 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <69ADB141-D40B-4DFB-8FBC-D0863897B78C@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> <01db01cdcd17$1d0e7100$572b5300$@iname.com> <69ADB141-D40B-4DFB-8FBC-D0863897B78C@delong.com> Message-ID: <009301cdcdb2$e4f55ad0$aee01070$@asgard.org> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > > That won't help. Think about it this way. A session state log entry is roughly 512 bytes. [math redacted] > you're still looking at roughly 85 Petabytes of > storage required to meet CALEA standards. I've done my share of shoveling dirt on the CGN coffin, but in the interest of fact-based decision-making: nobody is going to create a separate log entry for every session/flow. You do bulk port assignment or deterministic NAT, so whenever you assign an address, you know what ports you'll be mapping that address to. One entry per Lease_Time. Doesn't matter, because the servers aren't logging port number, so nobody will ever need to see those logs. * Unless Geoff Huston's wackiness finds support, and somebody will pay you to keep that kind of log. Although if somebody would pay, I'd expect them to be paying for DPI deployment already. Lee From edward.dore at freethought-internet.co.uk Wed Nov 28 22:03:47 2012 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Wed, 28 Nov 2012 22:03:47 +0000 Subject: juniper vpn In-Reply-To: <50B67FFF.1030205@mompl.net> References: <50B5762A.6000705@mompl.net> <60911748-6271-42A3-A47F-2A53F23A79B9@delong.com> <50B67FFF.1030205@mompl.net> Message-ID: Assuming that it's a binary DER encoded x509 certificate, you can use OpenSSL to convert it to a base64 encoded PEM certificate with: openssl x509 -inform DER -in -outform PEM -out Edward Dore Freethought Internet On 28 Nov 2012, at 21:19, Jeroen van Aart wrote: > On 11/27/2012 07:27 PM, Owen DeLong wrote: >> Do you want one for IPSEC or for the SSL VPN Appliance that Juniper is pushing nowadays? > > I just checked, the script i am looking at calls the ncscv tool which I believe is made by juniper? It needs amongst other things an ssl certificate. So I presume it's using the latter. > > This tool/script did download a certificate, however it appears to be a binary file, not the usual plain text file. Is there a way to retrieve the plaintext one or extract it from the binary file? Using "file" identifies it as a data file. > > Thanks, > Jeroen > > -- > Earthquake Magnitude: 4.8 > Date: Wednesday, November 28, 2012 18:05:30 UTC > Location: Catamarca, Argentina > Latitude: -27.8486; Longitude: -66.4048 > Depth: 154.40 km > From marka at isc.org Wed Nov 28 22:13:39 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 29 Nov 2012 09:13:39 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Wed, 28 Nov 2012 16:54:08 CDT." <009301cdcdb2$e4f55ad0$aee01070$@asgard.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> <01db01cdcd17$1d0e7100$572b5300$@iname.com> <69ADB141-D40B-4DFB-8FBC-D0863897B78C@delong.com> <009301cdcdb2$e4f55ad0$aee 01070$@a sgard.org> Message-ID: <20121128221339.5D40F2C4260C@drugs.dv.isc.org> In message <009301cdcdb2$e4f55ad0$aee01070$@asgard.org>, "Lee Howard" writes: > Doesn't matter, because the servers aren't logging port number, so nobody > will ever need > to see those logs. We log port numbers along with addresses in named as it is necessary to trouble shoot problems. We have been doing this for over a decade. I'm sure you will find other applications that log port number as well as the address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tmikelson at gmail.com Wed Nov 28 22:50:43 2012 From: tmikelson at gmail.com (Tom Mikelson) Date: Wed, 28 Nov 2012 15:50:43 -0700 Subject: Looking for Alcatel GPON sales Message-ID: Having trouble contacting anyone in Alcatel GPON sales, please contact me off-list. From rdobbins at arbor.net Thu Nov 29 00:17:55 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 29 Nov 2012 00:17:55 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> Message-ID: <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> On Nov 29, 2012, at 3:04 AM, Tony Hain wrote: > Getting the cpe vendors to ship in quantity requires the ISP engineering organizations to say in unison "we are deploying IPv6 and will only recommend products that pass testing". Do you see any evidence of that occurring? I don't. Also, a lot of broadband consumers and enterprise organizations buy and deploy their own CPE. Do you see a lot of IPv6 activity there? I don't, excepting an IPv6 RFP checkbox for enterprises, which doesn't have any formal requirements and is essentially meaningless because of that fact. > You claim to be looking for the economic incentive, but are looking with such a short time horizon that all you see are the 'waste' products vendors > are pushing to make a quick sale, knowing that you will eventually come back for yet-another-hack to delay transition, and prop up your expertise in a > legacy technology. No. What I am looking for is an economic incentive which will justify the [IMHO] wildly overoptimisitic claims which some are making in re ubiquitous end-to-end native IPv6 deployment. Otherwise, I believe it will be a much more gradual adoption curve, as you indicate. > The same thing happened with the SNA faithful 15 years ago, and history shows what happened there. You attribute circumstances and motivations to me which do not apply. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Thu Nov 29 00:28:06 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 29 Nov 2012 00:28:06 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <87lidl1w9q.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> Message-ID: On Nov 29, 2012, at 12:18 AM, Bj?rn Mork wrote: > But I will absolutely refuse the idea that anyone incapable of getting their application tested with IPv6 are able to create any useful networking software. Who's talking about 'networking software'? 'Networking software' is irrelevant for the vast majority of the userbase. I'm talking about ordinary applications which do stupid things like edit documents and calculate payroll runs. The main points I've taken away from this discussion is that a non-trivial proportion of ISP operational personnel have no idea what life is like within the enterprise organizations which are their customers; that they have a grossly exaggerated view of the skillsets, levels of engagement, and degrees of empowerment amongst run-of-the-mill software developers; and that they are either incapable of or are unwilling to step down from the rarified atmospheres of the technical heights they inhabit relative to the hoi polloi and even attempt to understand the constraints under which they operate. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From marka at isc.org Thu Nov 29 00:42:33 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 29 Nov 2012 11:42:33 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Thu, 29 Nov 2012 00:28:06 -0000." References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> Message-ID: <20121129004234.107662C45894@drugs.dv.isc.org> In message , "Dobbins, Roland" writes: > On Nov 29, 2012, at 12:18 AM, Bj=F8rn Mork wrote: > > > But I will absolutely refuse the idea that anyone incapable of getting > their application tested with IPv6 are able to create any useful > networking software. > > Who's talking about 'networking software'? Read the Subject. > 'Networking software' is irrelevant for the vast majority of the > userbase. I'm talking about ordinary applications which do stupid things > like edit documents and calculate payroll runs. > > The main points I've taken away from this discussion is that a > non-trivial proportion of ISP operational personnel have no idea what > life is like within the enterprise organizations which are their > customers; that they have a grossly exaggerated view of the skillsets, > levels of engagement, and degrees of empowerment amongst run-of-the-mill > software developers; and that they are either incapable of or are > unwilling to step down from the rarified atmospheres of the technical > heights they inhabit relative to the hoi polloi and even attempt to > understand the constraints under which they operate. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rdobbins at arbor.net Thu Nov 29 00:57:43 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 29 Nov 2012 00:57:43 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <20121129004234.107662C45894@drugs.dv.isc.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <20121129004234.107662C45894@drugs.dv.isc.org> Message-ID: <35EB5531-032F-4B7C-8001-7CF7A9816917@arbor.net> On Nov 29, 2012, at 7:42 AM, Mark Andrews wrote: > Read the Subject. Nothing about 'networking software' there . . . Unless your definition of 'networking software' is 'software which has an inherent capability to transmit/receive data over the network', which would include lots of lots of software. To me, 'networking software' means 'software which is intended to facilitate network communications', which is a more restricted subset. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jeroen at mompl.net Thu Nov 29 02:50:46 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 28 Nov 2012 18:50:46 -0800 Subject: juniper vpn In-Reply-To: References: <50B5762A.6000705@mompl.net> <60911748-6271-42A3-A47F-2A53F23A79B9@delong.com> <50B67FFF.1030205@mompl.net> Message-ID: <50B6CD86.8050803@mompl.net> On 11/28/2012 02:03 PM, Edward Dore wrote: > openssl x509 -inform DER -in -outform PEM -out Thanks, that did the trick. -- Earthquake Magnitude: 4.6 Date: Thursday, November 29, 2012 02:23:59 UTC Location: Jan Mayen Island region Latitude: 71.0240; Longitude: -6.5291 Depth: 13.50 km From owen at delong.com Thu Nov 29 05:27:41 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Nov 2012 21:27:41 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> Message-ID: On Nov 28, 2012, at 4:17 PM, "Dobbins, Roland" wrote: > > On Nov 29, 2012, at 3:04 AM, Tony Hain wrote: > >> Getting the cpe vendors to ship in quantity requires the ISP engineering organizations to say in unison "we are deploying IPv6 and will only recommend products that pass testing". > > Do you see any evidence of that occurring? I don't. > Yes. Comcast, Cable Labs, Time Warner are doing pretty well at this now. Others there is room for improvement, but it's definitely better than a year ago. > Also, a lot of broadband consumers and enterprise organizations buy and deploy their own CPE. Do you see a lot of IPv6 activity there? I don't, excepting an IPv6 RFP checkbox for enterprises, which doesn't have any formal requirements and is essentially meaningless because of that fact. Very little, but, most of those buy based on the "supported device" list from their carrier, so? > >> You claim to be looking for the economic incentive, but are looking with such a short time horizon that all you see are the 'waste' products vendors >> are pushing to make a quick sale, knowing that you will eventually come back for yet-another-hack to delay transition, and prop up your expertise in a >> legacy technology. > > No. > > What I am looking for is an economic incentive which will justify the [IMHO] wildly overoptimisitic claims which some are making in re ubiquitous end-to-end native IPv6 deployment. > > Otherwise, I believe it will be a much more gradual adoption curve, as you indicate. > The inability to add customers to IPv4 will become a factor in this. 60% of the world's population still isn't on the internet and I expect a significant fraction of that will be coming on in the next 2-4 years. Owen From jeroen at unfix.org Thu Nov 29 05:40:57 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 29 Nov 2012 06:40:57 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B6492D.1050804@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <50B64310.50905@unfix.org> <50B6492D.1050804@mtcc.com> Message-ID: <50B6F569.5070306@unfix.org> On 2012-11-28 18:26, Michael Thomas wrote: > On 11/28/2012 09:00 AM, Jeroen Massar wrote: >> >> And still, if you as a proper engineer where not able to test/add IPv6 >> code in the last 10++ years, then you did something very very wrong in >> your job, the least of which is to file a ticket for IPv6 support in the >> ticket tracking system so that one could state "I thought of it, company >> did not want it". >> > > It's very presumptuous for you to tell me what my development/test > priorities ought to be, and I can tell you for absolute certain that any > such badgering will be met with rolled eyes and quick dismissal. You are missing the point that people have been told already for a decade to add IPv6 support to their products. As such, if you do not care, the only thing left when it does hit you is: the Internets told you so. See the rest of this thread which contains nice links to RFCs which also indicate that one should have been supporting IPv6 already years ago. > The > only way that things will get fixed is if there's a perceived need to > fix them. I fully agree, but instead of waiting till the last moment you can also plan ahead and be ahead of the game. Do remember why there where so many of these "IPv4 address space is running out" counters and announcements. It is all to make you aware. Obviously you quickly dismissed that. That is your choice though. > Getting corpro-IT to upgrade to v6 -- as if there is even a > corpro-anything with most phone apps -- just to be able to test against > v6 is a fantasy. Adding the infrastructure to be 99% there is already a good start. And that you already had a decade for to do. Phone Apps btw are only something from the last few years, thus you can't even claim there is a 'legacy' there and "IPv6 didn't exist yet" arguments don't go either. Note also that most devkits (Android/IOS) provide IP-agnostic APIs, thus if used you at least have nothing IPv6-specific in that code. Also, google(eva ipv6) for a very nice simple tutorial on moving your apps from IPv4 to IPv4/IPv6. You do not need to test on IPv6 or fully support it yet, but at least you know that when you get IPv6 connectivity it most very likely just works. > The only way things are going to change is to make v6 a part of everybody's > day-to-day life. That means ISP's giving me and every other developer a > /64 at home at the very least. And that is happening, I hope you are ready to support those users because well, everybody told you it would happen, thus don't cry when you are too late at the game... (of course, some people simply do not care about the job they deliver, but in that case, it is also wise to not comment on a public list about things ;) Greets, Jeroen From andra.lutu at imdea.org Thu Nov 29 05:48:04 2012 From: andra.lutu at imdea.org (andra.lutu at imdea.org) Date: Thu, 29 Nov 2012 05:48:04 +0000 Subject: No subject Message-ID: <201211290548.qAT5m4Q4008856@smtp1.lhr.hosting-ops.com> Sent from my Nokia phone From jsw at inconcepts.biz Thu Nov 29 08:44:32 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 29 Nov 2012 03:44:32 -0500 Subject: OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field Message-ID: I had two downstream BGP customers experience problem with an OpenBGPd bug tonight. Before diving into detail, I would like to link this mailing list thread, because this is not a new issue and a patch is available: http://www.mail-archive.com/misc at openbsd.org/msg115071.html For the following DFZ routes, I see wrong use of the fifth bit in the Attribute Flags field: Aggregator (7), length: 8, Flags [OT+8]: AS #68, origin 192.65.95.253 0x0000: 0000 0044 c041 5ffd Updated routes: 128.165.0.0/16 141.111.0.0/16 192.65.95.0/24 192.12.184.0/24 204.121.0.0/16 According to RFC 4271 page 17, "the low-order four bits of the Attribute Flags octet are unused. They MUST be zero when sent and MUST be ignored when received." I read "ignored" to mean, don't tear down the BGP session and print a cryptic error that the user probably will be unable to debug. The OpenBGPd guys clearly agree and have supplied a patch, so affected users should visit the above mailing list link, and install it. Here are my notes for this RFC page and a small diagram of the packet header, because surprisingly, there isn't one in the RFC already http://inconcepts.biz/~jsw/img/1121129aa-rfc4271pg17scan.jpg Sorry about the poor quality of this, but it is past 3am here, and I know of several operators (besides my downstream customers) who are experiencing this problem right now. If I were someone who is broken by this right now, I would either patch my OpenBGPd or ask your eBGP neighbors not to send you the above five routes (filtering it on your own OpenBGPd router probably won't help.) Thanks, I hope this is helpful -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From bjorn at mork.no Thu Nov 29 09:28:54 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 29 Nov 2012 10:28:54 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: (Roland Dobbins's message of "Thu, 29 Nov 2012 00:28:06 +0000") References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> Message-ID: <871ufc21wp.fsf@nemi.mork.no> "Dobbins, Roland" writes: > On Nov 29, 2012, at 12:18 AM, Bj?rn Mork wrote: > >> But I will absolutely refuse the idea that anyone incapable of >> getting their application tested with IPv6 are able to create any >> useful networking software. > > Who's talking about 'networking software'? 'Networking software' is > irrelevant for the vast majority of the userbase. I'm talking about > ordinary applications which do stupid things like edit documents and > calculate payroll runs. If it doesn't do IPv4 then I don't see the need for IPv6 support. Bj?rn From rdobbins at arbor.net Thu Nov 29 10:49:34 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 29 Nov 2012 10:49:34 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <871ufc21wp.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> Message-ID: <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> On Nov 29, 2012, at 4:28 PM, Bj?rn Mork wrote: > If it doesn't do IPv4 then I don't see the need for IPv6 support. To me, 'networking software' <> software which happens to access the network. Quagga is an example of 'networking software'. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bjorn at mork.no Thu Nov 29 11:47:27 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 29 Nov 2012 12:47:27 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> (Roland Dobbins's message of "Thu, 29 Nov 2012 10:49:34 +0000") References: <50AB49EA.3030101@cis.vutbr.cz> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> Message-ID: <87sj7szl4g.fsf@nemi.mork.no> "Dobbins, Roland" writes: > On Nov 29, 2012, at 4:28 PM, Bj?rn Mork wrote: > >> If it doesn't do IPv4 then I don't see the need for IPv6 support. > > To me, 'networking software' <> software which happens to access the > network. Quagga is an example of 'networking software'. OK, that makes sense. What's the proper term for software which happens to access the network? Bj?rn From rdobbins at arbor.net Thu Nov 29 11:48:43 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 29 Nov 2012 11:48:43 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <87sj7szl4g.fsf@nemi.mork.no> References: <50AB49EA.3030101@cis.vutbr.cz> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> Message-ID: <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> On Nov 29, 2012, at 6:47 PM, Bj?rn Mork wrote: > What's the proper term for software which happens to access the network? Just about anything, these days. ;> 'Network-enabled' or 'network-capable' software, maybe? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From oscar.vives at gmail.com Thu Nov 29 12:53:20 2012 From: oscar.vives at gmail.com ( .) Date: Thu, 29 Nov 2012 13:53:20 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> References: <50AB49EA.3030101@cis.vutbr.cz> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> Message-ID: On 29 November 2012 12:48, Dobbins, Roland wrote: > > On Nov 29, 2012, at 6:47 PM, Bj?rn Mork wrote: > >> What's the proper term for software which happens to access the network? > > Just about anything, these days. > > ;> > > 'Network-enabled' or 'network-capable' software, maybe? > Connecting a app to a network is a fundamental change, so perhaps change the app to become a "network app". A piece of software connected to a network turns from a product into a service. "Programmers" is to a wide group of people. I am PHP programmer. How will ipv6 impact me? nothing, probably. Having to deal with ip stuff and low level networking stuff only affect a subset of programmers. It may break curl, or some sockets implementation of this and that, then I will download a replacement class that is ipv6 aware. There are two groups of programmers, a) these that have programming only as a job, and b) these that invest time beyond that. The first group is obviously not ready for ipv6 at all, maybe have not even heard about ipv6...and will not know anything about it until is something obligatory. Perhaps this also happens in other groups of people... most people reading mail-list are probably of the B group. -- -- ?in del ?ensaje. From caldcv at gmail.com Thu Nov 29 13:04:02 2012 From: caldcv at gmail.com (Chris) Date: Thu, 29 Nov 2012 08:04:02 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. Message-ID: I'm not William and a friend pasted a link on IRC to me. I'm going to send him a few bucks because I know how it feels to get blindsided by the police on one random day and your world is turned upside down. Source: http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exit-accepting-donations-for-legal-expenses >From the URL: Yes, it happened to me now as well - Yesterday i got raided for someone sharing child pornography over one of my Tor exits. I'm good so far, not in jail, but all my computers and hardware have been confiscated. (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) If convicted i could face up to 6 years in jail, of course i do not want that and i also want to try to set a legal base for running Tor exit nodes in Austria or even the EU. Sadly we have nothing like the EFF here that could help me in this case by legal assistance, so i'm on my own and require a good lawyer. Thus i'm accepting donations for my legal expenses which i expect to be around 5000-10000 EUR. If you can i would appreciate if you could donate a bit (every amount helps, even the smallest) either by PayPal (any currency is ok): https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZNBBD7EH4 Or by Bank Transfer (EUR only please): Holder: William Weber Bank: EasyBank AG (Vienna, Austria) Account: 20011351213 Bank sort number: 14200 IBAN: AT031420020011351213 BIC: EASYATW1 I will try to pay them back when i'm out of this (or even before) but i can obviously not guarantee this, please keep this in mind. This money will only be used for legal expenses related to this case. If you have any questions or want to donate by another way (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel free to send me a mail (william at william.si) or a PM, or contact me in LET IRC. Thanks! William -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From jeroen at unfix.org Thu Nov 29 13:15:52 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 29 Nov 2012 14:15:52 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> Message-ID: <50B76008.9030603@unfix.org> On 2012-11-29 13:53 , . wrote: > On 29 November 2012 12:48, Dobbins, Roland wrote: >> >> On Nov 29, 2012, at 6:47 PM, Bj?rn Mork wrote: >> >>> What's the proper term for software which happens to access the network? >> >> Just about anything, these days. >> >> ;> >> >> 'Network-enabled' or 'network-capable' software, maybe? >> > > Connecting a app to a network is a fundamental change, so perhaps > change the app to become a "network app". A piece of software > connected to a network turns from a product into a service. > > "Programmers" is to a wide group of people. I am PHP programmer. How > will ipv6 impact me? nothing, probably. *ahem* As Owen already alluded to, some programs (PHP also) actually store IP addresses in databases. Thus if you where storing those as 32bit, you are out of luck. [..] > There are two groups of programmers, a) these that have programming > only as a job, and b) these that invest time beyond that. Group a for you? :) Greets, Jeroen From rps at maine.edu Thu Nov 29 13:42:17 2012 From: rps at maine.edu (Ray Soucy) Date: Thu, 29 Nov 2012 08:42:17 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: If you run Tor, then you should probably accept that it might be used for activity that you don't approve of or even is in violation of the law. I'm not saying Tor is good or bad, just that if you're using it you probably know what you're getting into. In order to catch someone in a criminal case, most law enforcement will certainly take whatever they think could be used as evidence, perform forensic analysis on it, and retain it as long as they think necessary. Depending on how well your laws are written, you might be not be protected from them discovering "other" activity that is outside the scope and bringing a separate criminal case against you directly. Got any pirated music or movies? On Thu, Nov 29, 2012 at 8:04 AM, Chris wrote: > I'm not William and a friend pasted a link on IRC to me. I'm going to > send him a few bucks because I know how it feels to get blindsided by > the police on one random day and your world is turned upside down. > > Source: http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exit-accepting-donations-for-legal-expenses > > From the URL: > > Yes, it happened to me now as well - Yesterday i got raided for > someone sharing child pornography over one of my Tor exits. > I'm good so far, not in jail, but all my computers and hardware have > been confiscated. > (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) > > If convicted i could face up to 6 years in jail, of course i do not > want that and i also want to try to set a legal base for running Tor > exit nodes in Austria or even the EU. > > Sadly we have nothing like the EFF here that could help me in this > case by legal assistance, so i'm on my own and require a good lawyer. > Thus i'm accepting donations for my legal expenses which i expect to > be around 5000-10000 EUR. > > If you can i would appreciate if you could donate a bit (every amount > helps, even the smallest) either by PayPal (any currency is ok): > https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZNBBD7EH4 > > Or by Bank Transfer (EUR only please): > > Holder: William Weber > Bank: EasyBank AG (Vienna, Austria) > Account: 20011351213 > Bank sort number: 14200 > IBAN: AT031420020011351213 > BIC: EASYATW1 > > I will try to pay them back when i'm out of this (or even before) but > i can obviously not guarantee this, please keep this in mind. > This money will only be used for legal expenses related to this case. > > If you have any questions or want to donate by another way > (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel free > to send me a mail (william at william.si) or a PM, or contact me in LET > IRC. > > Thanks! > William > > > > > -- > --C > > "The dumber people think you are, the more surprised they're going to > be when you kill them." - Sir William Clayton > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From rps at maine.edu Thu Nov 29 14:01:30 2012 From: rps at maine.edu (Ray Soucy) Date: Thu, 29 Nov 2012 09:01:30 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B76008.9030603@unfix.org> References: <50AB49EA.3030101@cis.vutbr.cz> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> Message-ID: You should store IPv6 as a pair of 64-bit integers. While PHP lacks the function set to do this on its own, it's not very difficult to do. Here are a set of functions I wrote a while back to do just that (though I admit I should spend some time to try and make it more elegant and I'm not sure it's completely up to date compared to my local copy ... I would love some eyes on it to make some improvements). http://soucy.org/project/inet6/ I would point out that many developers don't even store IP addresses correctly and just treat them as a string. In regards to storing as a pair of 64-bit integers, I would caution against the temptation of treating one field as the prefix and the other as the host segment. While the 64-bit boundary is most common, it is certainly not required, so please write your IPv6 support in a way that will allow any valid prefix-length. While PHP hasn't been my language of choice in the past, it seems to be something that almost everyone knows, or can learn very quickly. I've started using it as a command line scripting language quite a bit as a result ... pretty much a cleaner Perl, the upshot is that you don't have all the pre-written libraries that you'd find with Perl. I've tried switching to Python for some things, but I got annoyed with the specification being in a constant state of drastic syntax change. But back to the topic at hand. I think the OP was expressing that until developers have native IPv6 access at home, they just won't care about IPv6 support, or won't test it as well as IPv4 support. That's pretty much expected and I'm not even sure why it's being stated as some revelation. As many have pointed out, there are tunnel brokers available to developers to test IPv6 with, but at the end of the day, most people don't want to use a slow tunnel for anything byond testing, and if they don't have a lot of users asking for IPv6 they're probably not going to give it much attention until they see a need for it. The majority of larger applications support IPv6 just fine because there are enough users asking for IPv6 support. I suspect once you see native IPv6 for residential users become more common you'll see the developers who have been dragging their feet give in and add IPv6 support. As mentioned with a shift to web applications though the browser, it's been a lot less work. Just throw your application on a server with IPv6 and it will generally work. You might need to modify a few places that interact with IP addresses, but usually they're pretty trivial (like logging) unless it's a network management oriented application. On Thu, Nov 29, 2012 at 8:15 AM, Jeroen Massar wrote: > On 2012-11-29 13:53 , . wrote: >> On 29 November 2012 12:48, Dobbins, Roland wrote: >>> >>> On Nov 29, 2012, at 6:47 PM, Bj?rn Mork wrote: >>> >>>> What's the proper term for software which happens to access the network? >>> >>> Just about anything, these days. >>> >>> ;> >>> >>> 'Network-enabled' or 'network-capable' software, maybe? >>> >> >> Connecting a app to a network is a fundamental change, so perhaps >> change the app to become a "network app". A piece of software >> connected to a network turns from a product into a service. >> >> "Programmers" is to a wide group of people. I am PHP programmer. How >> will ipv6 impact me? nothing, probably. > > *ahem* > > As Owen already alluded to, some programs (PHP also) actually store IP > addresses in databases. Thus if you where storing those as 32bit, you > are out of luck. > > [..] >> There are two groups of programmers, a) these that have programming >> only as a job, and b) these that invest time beyond that. > > Group a for you? :) > > Greets, > Jeroen > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From bill at herrin.us Thu Nov 29 14:30:03 2012 From: bill at herrin.us (William Herrin) Date: Thu, 29 Nov 2012 09:30:03 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: On Wed, Nov 28, 2012 at 1:30 PM, david peahi wrote: > Do today's programmers still use basic BSD socket programming? Is there an > equivalent set of called procedures for IPv6 network application > programming? The IPv6 API is BSD sockets. However, unless you were a particularly advanced sockets programmer you'll find that the way you used sockets for IPv4 (assuming that multiple IP addresses for a host was the exception rather than the rule) is wholly ineffective for writing useful IPv6-compatible code. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Nov 29 14:55:19 2012 From: bill at herrin.us (William Herrin) Date: Thu, 29 Nov 2012 09:55:19 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> Message-ID: On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy wrote: > You should store IPv6 as a pair of 64-bit integers. While PHP lacks > the function set to do this on its own, it's not very difficult to do. Hi Ray, I have to disagree. In your SQL database you should store addresses as a fixed length character string containing a zero-padded hexadecimal representation of the IPv4 or IPv6 address with A through F forced to the consistent case of your choice. Expand :: and optionally strip the colons entirely. If you want to store a block of addresses, store it as two character strings: start and end of the range. Bytes are cheap and query simplicity is important. Multi-element indexes are messy and the code to manage an array of integers is messier than managing a character string in most programming languages. memcmp() that integer array for less or greater than? Not on a little endian machine! > Here are a set of functions I wrote a while back to do just that > (though I admit I should spend some time to try and make it more > elegant and I'm not sure it's completely up to date compared to my > local copy ... I would love some eyes on it to make some > improvements). > > http://soucy.org/project/inet6/ If we're plugging our code, give my public domain libeasyv6 a try. It eases entry into dual stack programming for anyone used to doing gethostbyname followed by a blocking connect(). Just do a connectbyname() with the hostname or textual IP address, the port, a timeout and null options. The library takes care of finding a working IPv4 or IPv6 address for the host and connecting to it in a timely manner. http://bill.herrin.us/freebies/ Currently Linux only but if you're willing to lose timeout control on the DNS lookup you can replace getaddrinfo_a() with standard getaddrinfo() and the code should run anywhere. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ikiris at gmail.com Thu Nov 29 15:51:49 2012 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 29 Nov 2012 09:51:49 -0600 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> Message-ID: Hadn't thought about it that way before. This was a useful bit of info, thanks. -Blake On Thu, Nov 29, 2012 at 8:55 AM, William Herrin wrote: > On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy wrote: > > You should store IPv6 as a pair of 64-bit integers. While PHP lacks > > the function set to do this on its own, it's not very difficult to do. > > Hi Ray, > > I have to disagree. In your SQL database you should store addresses as > a fixed length character string containing a zero-padded hexadecimal > representation of the IPv4 or IPv6 address with A through F forced to > the consistent case of your choice. Expand :: and optionally strip the > colons entirely. If you want to store a block of addresses, store it > as two character strings: start and end of the range. > > Bytes are cheap and query simplicity is important. Multi-element > indexes are messy and the code to manage an array of integers is > messier than managing a character string in most programming > languages. memcmp() that integer array for less or greater than? Not > on a little endian machine! > > > > Here are a set of functions I wrote a while back to do just that > > (though I admit I should spend some time to try and make it more > > elegant and I'm not sure it's completely up to date compared to my > > local copy ... I would love some eyes on it to make some > > improvements). > > > > http://soucy.org/project/inet6/ > > If we're plugging our code, give my public domain libeasyv6 a try. It > eases entry into dual stack programming for anyone used to doing > gethostbyname followed by a blocking connect(). Just do a > connectbyname() with the hostname or textual IP address, the port, a > timeout and null options. The library takes care of finding a working > IPv4 or IPv6 address for the host and connecting to it in a timely > manner. > > http://bill.herrin.us/freebies/ > > Currently Linux only but if you're willing to lose timeout control on > the DNS lookup you can replace getaddrinfo_a() with standard > getaddrinfo() and the code should run anywhere. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From bzs at world.std.com Thu Nov 29 16:17:27 2012 From: bzs at world.std.com (Barry Shein) Date: Thu, 29 Nov 2012 11:17:27 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: <20663.35479.561328.722417@world.std.com> Back in the early days of the public internet we didn't require any id to create an account, just that you found a way to pay us. We had anonymous accts some of whom dropped by personally to pay their bill, some said hello but I usually didn't know their names and that's how they wanted it, I'd answer "hello ", whatever their login was if I recognized them. Some mailed in something, a mail order, even currency tho that was rare but it did happen, or had someone else drop by to pay in cash (that is, no idea if they were local.) LEO occasionally served a warrant for information, usually child porn biz (more than just accessing child porn, selling it) tho I don't remember any anonymous accts being involved. I never expected to be held accountable for anyone's behavior unless I was knowingly involved somehow (just the usual caveat.) LEO never showed any particular interest in the fact that we were ok with anonymous accounts. If I was made aware of illegal activities we'd shut them off, didn't really happen much, maybe some credible "hacking" complaint on occasion. It's funny, it's all illusion like show business. It's not hard to set up anonymous service, crap, just drop in at any wi-fi hotspot, many just ask you to click that you accept their T&Cs and you're on. Would they raid them, I was just using one at a major hospital this week that was just like that, if someone used that for child porn etc? But I guess stick your nose out and say you're specifically offering anon accts and watch out I guess. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From mike at mtcc.com Thu Nov 29 16:19:30 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 29 Nov 2012 08:19:30 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B6F569.5070306@unfix.org> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <50B64310.50905@unfix.org> <50B6492D.1050804@mtcc.com> <50B6F569.5070306@unfix.org> Message-ID: <50B78B12.9090209@mtcc.com> On 11/28/2012 09:40 PM, Jeroen Massar wrote: > On 2012-11-28 18:26, Michael Thomas wrote: >> >> It's very presumptuous for you to tell me what my development/test >> priorities ought to be, and I can tell you for absolute certain that any >> such badgering will be met with rolled eyes and quick dismissal. > You are missing the point that people have been told already for a > decade to add IPv6 support to their products. Programmers are routinely "told" all manner of apocalyptic things, and that they're idiots for not heeding the soothsayers. Ho Hum. At least Y2K had a finite stopping point. When v6 gets one of those, maybe you'll have more luck. >> The >> only way that things will get fixed is if there's a perceived need to >> fix them. > I fully agree, but instead of waiting till the last moment you can also > plan ahead and be ahead of the game. Please. When there's deployment, there will be fixes. The *vast* majority of the problem is with ISP's. This isn't even an 80-20 problem, it's a 1% problem. All you're managing to do here is tick off developers as if they are in any way, shape, or form responsible for the lack of v6 deployment. > > Phone Apps btw are only something from the last few years, thus you > can't even claim there is a 'legacy' there and "IPv6 didn't exist yet" > arguments don't go either. Note also that most devkits (Android/IOS) > provide IP-agnostic APIs, thus if used you at least have nothing > IPv6-specific in that code. Phone apps, by and large, are designed by people in homes or small companies. They do not have v6 connectivity. Full stop. They don't care about v6. Full stop. It's not their fault, even if you think they should invest a significant amount of time to fix theoretical problems. >> The only way things are going to change is to make v6 a part of everybody's >> day-to-day life. That means ISP's giving me and every other developer a >> /64 at home at the very least. > And that is happening, I hope you are ready to support those users > because well, everybody told you it would happen, thus don't cry when > you are too late at the game... It sure isn't happening in Silly Valley or San Francisco that I've seen. > > (of course, some people simply do not care about the job they deliver, > but in that case, it is also wise to not comment on a public list about > things ;) > All your patronizing tone does is fix you for a religious zealot. You're a dime a dozen and ignorable. Telling people they're incompetent because they won't fix your hobby-horse theoretical problem does exactly the opposite of what you want. Developers and the companies that employ them react to perceived need for bugs and features. When there is a perceived need, the bugs will be fixed. Until then, by all means rant on while the actual problem (ISP's) do nothing. Mike From patrick at ianai.net Thu Nov 29 16:45:18 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 29 Nov 2012 11:45:18 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20663.35479.561328.722417@world.std.com> References: <20663.35479.561328.722417@world.std.com> Message-ID: On Nov 29, 2012, at 11:17 , Barry Shein wrote: > Back in the early days of the public internet we didn't require any id > to create an account, just that you found a way to pay us. We had > anonymous accts some of whom dropped by personally to pay their bill, > some said hello but I usually didn't know their names and that's how > they wanted it, I'd answer "hello ", whatever their login was > if I recognized them. Some mailed in something, a mail order, even > currency tho that was rare but it did happen, or had someone else drop > by to pay in cash (that is, no idea if they were local.) > > LEO occasionally served a warrant for information, usually child porn > biz (more than just accessing child porn, selling it) tho I don't > remember any anonymous accts being involved. "Mere conduit" defense. (Please do not anyone mention "common carrier status" or the like, ISPs are _not_ common carriers.) > I never expected to be held accountable for anyone's behavior unless I > was knowingly involved somehow (just the usual caveat.) LEO never > showed any particular interest in the fact that we were ok with > anonymous accounts. If I was made aware of illegal activities we'd > shut them off, didn't really happen much, maybe some credible > "hacking" complaint on occasion. How do you "shut off" a Tor "account"? > It's funny, it's all illusion like show business. It's not hard to set > up anonymous service, crap, just drop in at any wi-fi hotspot, many > just ask you to click that you accept their T&Cs and you're on. Would > they raid them, I was just using one at a major hospital this week > that was just like that, if someone used that for child porn etc? But > I guess stick your nose out and say you're specifically offering anon > accts and watch out I guess. Do you think if the police found out child pr0n was being served from a starbux they wouldn't confiscate the equipment from that store? -- TTFN, patrick From george.herbert at gmail.com Thu Nov 29 16:58:26 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 29 Nov 2012 08:58:26 -0800 Subject: Syria off the net Message-ID: <837A33AB-3E76-42F6-8A72-226779E0B7CF@gmail.com> The press is reporting on Renesys' report that Syria has finally dropped all its internet connectivity earlier this morning: http://www.renesys.com/blog/2012/11/syria-off-the-air.shtml http://m.washingtonpost.com/blogs/worldviews/wp/2012/11/29/web-monitor-100-percent-of-syrias-internet-just-shut-down/ George William Herbert Sent from my iPhone From mansaxel at besserwisser.org Thu Nov 29 17:26:26 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 29 Nov 2012 18:26:26 +0100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> Message-ID: <20121129172626.GD25469@besserwisser.org> Subject: Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... Date: Thu, Nov 29, 2012 at 09:55:19AM -0500 Quoting William Herrin (bill at herrin.us): > On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy wrote: > > You should store IPv6 as a pair of 64-bit integers. While PHP lacks > > the function set to do this on its own, it's not very difficult to do. > > Hi Ray, > > I have to disagree. In your SQL database you should store addresses as > a fixed length character string containing a zero-padded hexadecimal > representation of the IPv4 or IPv6 address with A through F forced to > the consistent case of your choice. Expand :: and optionally strip the > colons entirely. If you want to store a block of addresses, store it > as two character strings: start and end of the range. No, you are both worng. The answer is simple and practical: Use a database that has a modern IP adress database type. Like Postgres. Its IP-adress data types understand and parse both adress strings and network strings (and, of course -- a network with the proper netmask set might be interpreted like a host.) The 32-bit integer trick might, just might make do for IPv4, but a proper data type is so much simpler to use. Also, stepping away from MySQL or Oracle makes Larry less powerful. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I am covered with pure vegetable oil and I am writing a best seller! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From michael at rancid.berkeley.edu Thu Nov 29 17:34:34 2012 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Thu, 29 Nov 2012 09:34:34 -0800 Subject: OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field In-Reply-To: References: Message-ID: <50B79CAA.3000703@rancid.berkeley.edu> Hi Jeff (and NANOG) This is one of our customers, and we're going to get it fixed (or worked around) ASAP. michael On 11/29/12 12:44 AM, Jeff Wheeler wrote: > I had two downstream BGP customers experience problem with an OpenBGPd bug > tonight. Before diving into detail, I would like to link this mailing list > thread, because this is not a new issue and a patch is available: > http://www.mail-archive.com/misc at openbsd.org/msg115071.html > > For the following DFZ routes, I see wrong use of the fifth bit in the > Attribute Flags field: > Aggregator (7), length: 8, Flags [OT+8]: AS #68, origin > 192.65.95.253 > 0x0000: 0000 0044 c041 5ffd > Updated routes: > 128.165.0.0/16 > 141.111.0.0/16 > 192.65.95.0/24 > 192.12.184.0/24 > 204.121.0.0/16 > > According to RFC 4271 page 17, "the low-order four bits of the Attribute > Flags octet are unused. They MUST be zero when sent and MUST be ignored > when received." I read "ignored" to mean, don't tear down the BGP session > and print a cryptic error that the user probably will be unable to debug. > The OpenBGPd guys clearly agree and have supplied a patch, so affected > users should visit the above mailing list link, and install it. > > Here are my notes for this RFC page and a small diagram of the packet > header, because surprisingly, there isn't one in the RFC already > http://inconcepts.biz/~jsw/img/1121129aa-rfc4271pg17scan.jpg Sorry about > the poor quality of this, but it is past 3am here, and I know of several > operators (besides my downstream customers) who are experiencing this > problem right now. > > If I were someone who is broken by this right now, I would either patch my > OpenBGPd or ask your eBGP neighbors not to send you the above five routes > (filtering it on your own OpenBGPd router probably won't help.) > > Thanks, I hope this is helpful > From bzs at world.std.com Thu Nov 29 17:58:22 2012 From: bzs at world.std.com (Barry Shein) Date: Thu, 29 Nov 2012 12:58:22 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: <20663.41534.80038.454363@world.std.com> On November 29, 2012 at 11:45 patrick at ianai.net (Patrick W. Gilmore) wrote: > On Nov 29, 2012, at 11:17 , Barry Shein wrote: > > > It's funny, it's all illusion like show business. It's not hard to set > > up anonymous service, crap, just drop in at any wi-fi hotspot, many > > just ask you to click that you accept their T&Cs and you're on. Would > > they raid them, I was just using one at a major hospital this week > > that was just like that, if someone used that for child porn etc? But > > I guess stick your nose out and say you're specifically offering anon > > accts and watch out I guess. > > Do you think if the police found out child pr0n was being served from a starbux they wouldn't confiscate the equipment from that store? I dunno, has it ever happened? I mean confiscated the store's equipment, I assume that's what you mean. Is that because no one has ever been involved with child porn etc from a Starbucks? Does that seem likely? I don't know, really. And why would confiscating it from one location address the issue if they offer anonymous hotspots (I don't know if they do but whatever, there are plenty of others) at all locations and they're one company? It would seem like they'd have to confiscate the equipment at every Starbucks in their jurisdiction, which could be every one in the US for example. -b From cb.list6 at gmail.com Thu Nov 29 18:36:29 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 29 Nov 2012 10:36:29 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B78B12.9090209@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <50B64310.50905@unfix.org> <50B6492D.1050804@mtcc.com> <50B6F569.5070306@unfix.org> <50B78B12.9090209@mtcc.com> Message-ID: Got some bad data here. Let me help. Sent from ipv6-only Android On Nov 29, 2012 8:22 AM, "Michael Thomas" wrote: > Phone apps, by and large, are designed by people in homes or > small companies. They do not have v6 connectivity. Full stop. > They don't care about v6. Full stop. It's not their fault, even if > you think they should invest a significant amount of time to fix > theoretical problems. > Phone apps generally work with ipv6 since they are developed using high level and modern sdk's. My sample says over 85% of Android Market top apps work fine on ipv6. For folks to really get in trouble they need to be using NDK... that is where the ipv4-only apis live, not SDK afaik ... NDK implies greater knowledge and risk in Android. The apps that fail are not from noobies in a garage. The failures are from Microsoft/Skype , Netflix , Amazon Prime streaming , Spotify and other well heeled folks that are expected to champion technology evolution. And, Microsoft and Netflix were certainly part of world v6 launch. They just have more work to do. I have more work to do. Vzw and T-mobile USA both have ipv6. So, please note: most Android apps work on v6. Millions of mobile phone subscribers have ipv6 (all vzw LTE by default, all t-mobile samsung by phone configuration). The problem apps are from top tech companies, not garage devs. CB From patrick at ianai.net Thu Nov 29 18:45:59 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 29 Nov 2012 13:45:59 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20663.41534.80038.454363@world.std.com> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> Message-ID: On Nov 29, 2012, at 12:58 , Barry Shein wrote: > On November 29, 2012 at 11:45 patrick at ianai.net (Patrick W. Gilmore) wrote: >> On Nov 29, 2012, at 11:17 , Barry Shein wrote: >> >>> It's funny, it's all illusion like show business. It's not hard to set >>> up anonymous service, crap, just drop in at any wi-fi hotspot, many >>> just ask you to click that you accept their T&Cs and you're on. Would >>> they raid them, I was just using one at a major hospital this week >>> that was just like that, if someone used that for child porn etc? But >>> I guess stick your nose out and say you're specifically offering anon >>> accts and watch out I guess. >> >> Do you think if the police found out child pr0n was being served from a starbux they wouldn't confiscate the equipment from that store? > > I dunno, has it ever happened? No idea. However, I would not be the least bit surprised. In fact, I would be surprised if they failed to do so, after having "proof" that child pr0n was served from one. > I mean confiscated the store's > equipment, I assume that's what you mean. Is that because no one has > ever been involved with child porn etc from a Starbucks? Does that > seem likely? I don't know, really. > > And why would confiscating it from one location address the issue if > they offer anonymous hotspots (I don't know if they do but whatever, > there are plenty of others) at all locations and they're one company? > > It would seem like they'd have to confiscate the equipment at every > Starbucks in their jurisdiction, which could be every one in the US > for example. They didn't confiscate every Tor exit node in the US once they found something nefarious emanating from one. -- TTFN, patrick From wingar at team-metro.net Thu Nov 29 14:14:08 2012 From: wingar at team-metro.net (Emily Ozols) Date: Fri, 30 Nov 2012 01:14:08 +1100 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: Hi, I gotta ask and I'm sure someone would if I didn't, but how do we know this guy is legit? He's jumped up on a forum saying, "Hey, police raided me, help. gib mone plz" and failed to provide and reason as to how he's real and not just making it up. Maybe if there's a way to know this guy is legit, I'll help out if possible, but until then I'm just going to watch others with caution and I suggest others do as well. On Fri, Nov 30, 2012 at 12:04 AM, Chris wrote: > I'm not William and a friend pasted a link on IRC to me. I'm going to > send him a few bucks because I know how it feels to get blindsided by > the police on one random day and your world is turned upside down. > > Source: http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exit-accepting-donations-for-legal-expenses > > From the URL: > > Yes, it happened to me now as well - Yesterday i got raided for > someone sharing child pornography over one of my Tor exits. > I'm good so far, not in jail, but all my computers and hardware have > been confiscated. > (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) > > If convicted i could face up to 6 years in jail, of course i do not > want that and i also want to try to set a legal base for running Tor > exit nodes in Austria or even the EU. > > Sadly we have nothing like the EFF here that could help me in this > case by legal assistance, so i'm on my own and require a good lawyer. > Thus i'm accepting donations for my legal expenses which i expect to > be around 5000-10000 EUR. > > If you can i would appreciate if you could donate a bit (every amount > helps, even the smallest) either by PayPal (any currency is ok): > https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZNBBD7EH4 > > Or by Bank Transfer (EUR only please): > > Holder: William Weber > Bank: EasyBank AG (Vienna, Austria) > Account: 20011351213 > Bank sort number: 14200 > IBAN: AT031420020011351213 > BIC: EASYATW1 > > I will try to pay them back when i'm out of this (or even before) but > i can obviously not guarantee this, please keep this in mind. > This money will only be used for legal expenses related to this case. > > If you have any questions or want to donate by another way > (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel free > to send me a mail (william at william.si) or a PM, or contact me in LET > IRC. > > Thanks! > William > > > > > -- > --C > > "The dumber people think you are, the more surprised they're going to > be when you kill them." - Sir William Clayton > -- ~Em From bill at herrin.us Thu Nov 29 18:57:36 2012 From: bill at herrin.us (William Herrin) Date: Thu, 29 Nov 2012 13:57:36 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: On Thu, Nov 29, 2012 at 11:45 AM, Patrick W. Gilmore wrote: > Do you think if the police found out child pr0n was > being served from a starbux they wouldn't > confiscate the equipment from that store? I think if they took the cash registers too the Starbucks lawyer would be in court an hour later with a motion to quash in one hand and an offer of full cooperation in the other. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mtcc.com Thu Nov 29 19:00:24 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 29 Nov 2012 11:00:24 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <50B64310.50905@unfix.org> <50B6492D.1050804@mtcc.com> <50B6F569.5070306@unfix.org> <50B78B12.9090209@mtcc.com> Message-ID: <50B7B0C8.6050700@mtcc.com> On 11/29/2012 10:36 AM, Cameron Byrne wrote: > > Got some bad data here. Let me help. > > Sent from ipv6-only Android > On Nov 29, 2012 8:22 AM, "Michael Thomas" > wrote: > > > Phone apps, by and large, are designed by people in homes or > > small companies. They do not have v6 connectivity. Full stop. > > They don't care about v6. Full stop. It's not their fault, even if > > you think they should invest a significant amount of time to fix > > theoretical problems. > > > > Phone apps generally work with ipv6 since they are developed using high level and modern sdk's. > > My sample says over 85% of Android Market top apps work fine on ipv6. For folks to really get in trouble they need to be using NDK... that is where the ipv4-only apis live, not SDK afaik ... NDK implies greater knowledge and risk in Android. > > The apps that fail are not from noobies in a garage. The failures are from Microsoft/Skype , Netflix , Amazon Prime streaming , Spotify and other well heeled folks that are expected to champion technology evolution. And, Microsoft and Netflix were certainly part of world v6 launch. They just have more work to do. > Ie, the referral problem. One would expect those to have problems because referrals suck generally, and are tangled up horrifically with NAT traversal. I don't really worry about those guys so much because it's just a business case rather than cluelessness. The fact that they aren't getting bit hard enough to make that business case says something. Which is why all of this gnashing of the teeth toward developers is wildly off the mark. It's the network that's the problem. > So, please note: most Android apps work on v6. Millions of mobile phone subscribers have ipv6 (all vzw LTE by default, all t-mobile samsung by phone configuration). The problem apps are from top tech companies, not garage devs. > > Yeah, I just checked having switch to vzw yesterday: Galaxy S3 ipv6, iphone5 ipv4. Mike From wbailey at satelliteintelligencegroup.com Thu Nov 29 19:02:18 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 29 Nov 2012 19:02:18 +0000 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: Message-ID: <8200F04ED2C5EF40B246388AD4B822A512D5B933@BL2PRD0512MB662.namprd05.prod.outlook.com> It's difficult to compare a guy in Austria to a multi-billion dollar corporation. Here in the US, the fed has charged 3 men with involuntary manslaughter for their parts in the Gulf of Mexico Rig explosion. BP received a slap on the wrist, and a decent (to us, not them) sized fine. On 11/29/12 10:57 AM, "William Herrin" wrote: >On Thu, Nov 29, 2012 at 11:45 AM, Patrick W. Gilmore >wrote: >> Do you think if the police found out child pr0n was >> being served from a starbux they wouldn't >> confiscate the equipment from that store? > >I think if they took the cash registers too the Starbucks lawyer would >be in court an hour later with a motion to quash in one hand and an >offer of full cooperation in the other. > >Regards, >Bill Herrin > > >-- >William D. Herrin ................ herrin at dirtside.com bill at herrin.us >3005 Crane Dr. ...................... Web: >Falls Church, VA 22042-3004 > > From patrick at ianai.net Thu Nov 29 19:06:19 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 29 Nov 2012 14:06:19 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: On Nov 29, 2012, at 13:57 , William Herrin wrote: > On Thu, Nov 29, 2012 at 11:45 AM, Patrick W. Gilmore wrote: >> Do you think if the police found out child pr0n was >> being served from a starbux they wouldn't >> confiscate the equipment from that store? > > I think if they took the cash registers too the Starbucks lawyer would > be in court an hour later with a motion to quash in one hand and an > offer of full cooperation in the other. And if the sky were orange.... Any other non-sequitors? :) -- TTFN, patrick P.S. I can come up with some examples where the cash registers would be fair game, such as when the manager was charging the hosting provider extra to sit in the corner and host the 'bad content'. But it is still a non-sequitor w/r/t this thread. From SNaslund at medline.com Thu Nov 29 19:06:48 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 29 Nov 2012 13:06:48 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7117E5@MUNEXBE1.medline.com> How would this be legally different than receiving the illegal content in an envelope and anonymously forwarding the envelope via the post office? I am pretty sure you are still liable since you were the sender. I realize that there are special postal regulations but I think that agreeing to forward anything for anyone sight unseen is pretty risky and I think you will have a hard time pulling of the "service provider" defense if you are not selling services and are not licensed as a carrier. Steven Naslund -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Thursday, November 29, 2012 10:45 AM To: NANOG list Subject: Re: William was raided for running a Tor exit node. Please help if you can. On Nov 29, 2012, at 11:17 , Barry Shein wrote: > Back in the early days of the public internet we didn't require any > id to create an account, just that you found a way to pay us. We had > anonymous accts some of whom dropped by personally to pay their bill, > some said hello but I usually didn't know their names and that's how > they wanted it, I'd answer "hello ", whatever their login was > if I recognized them. Some mailed in something, a mail order, even > currency tho that was rare but it did happen, or had someone else drop > by to pay in cash (that is, no idea if they were local.) > > LEO occasionally served a warrant for information, usually child porn > biz (more than just accessing child porn, selling it) tho I don't > remember any anonymous accts being involved. "Mere conduit" defense. (Please do not anyone mention "common carrier status" or the like, ISPs are _not_ common carriers.) > I never expected to be held accountable for anyone's behavior unless I > was knowingly involved somehow (just the usual caveat.) LEO never > showed any particular interest in the fact that we were ok with > anonymous accounts. If I was made aware of illegal activities we'd > shut them off, didn't really happen much, maybe some credible > "hacking" complaint on occasion. How do you "shut off" a Tor "account"? > It's funny, it's all illusion like show business. It's not hard to set > up anonymous service, crap, just drop in at any wi-fi hotspot, many > just ask you to click that you accept their T&Cs and you're on. Would > they raid them, I was just using one at a major hospital this week > that was just like that, if someone used that for child porn etc? But > I guess stick your nose out and say you're specifically offering anon > accts and watch out I guess. Do you think if the police found out child pr0n was being served from a starbux they wouldn't confiscate the equipment from that store? -- TTFN, patrick From tbeecher at localnet.com Thu Nov 29 19:18:49 2012 From: tbeecher at localnet.com (Tom Beecher) Date: Thu, 29 Nov 2012 14:18:49 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: <50B7B519.8050608@localnet.com> Assuming it's true, it was bound to happen. Running anything , TOR or otherwise, that allows strangers to do whatever they want is just folly. People will spend time and money securing their home wireless so their neighbor can't steal their internet, but willingly allow strangers from anywhere in the world to use their connections no strings attached. It's hilarious. On 11/29/2012 8:04 AM, Chris wrote: > I'm not William and a friend pasted a link on IRC to me. I'm going to > send him a few bucks because I know how it feels to get blindsided by > the police on one random day and your world is turned upside down. > > Source: http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exit-accepting-donations-for-legal-expenses > > From the URL: > > Yes, it happened to me now as well - Yesterday i got raided for > someone sharing child pornography over one of my Tor exits. > I'm good so far, not in jail, but all my computers and hardware have > been confiscated. > (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) > > If convicted i could face up to 6 years in jail, of course i do not > want that and i also want to try to set a legal base for running Tor > exit nodes in Austria or even the EU. > > Sadly we have nothing like the EFF here that could help me in this > case by legal assistance, so i'm on my own and require a good lawyer. > Thus i'm accepting donations for my legal expenses which i expect to > be around 5000-10000 EUR. > > If you can i would appreciate if you could donate a bit (every amount > helps, even the smallest) either by PayPal (any currency is ok): > https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZNBBD7EH4 > > Or by Bank Transfer (EUR only please): > > Holder: William Weber > Bank: EasyBank AG (Vienna, Austria) > Account: 20011351213 > Bank sort number: 14200 > IBAN: AT031420020011351213 > BIC: EASYATW1 > > I will try to pay them back when i'm out of this (or even before) but > i can obviously not guarantee this, please keep this in mind. > This money will only be used for legal expenses related to this case. > > If you have any questions or want to donate by another way > (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel free > to send me a mail (william at william.si) or a PM, or contact me in LET > IRC. > > Thanks! > William > > > > > -- > --C > > "The dumber people think you are, the more surprised they're going to > be when you kill them." - Sir William Clayton > From SNaslund at medline.com Thu Nov 29 19:19:19 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 29 Nov 2012 13:19:19 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20663.35479.561328.722417@world.std.com> References: <20663.35479.561328.722417@world.std.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D71181A@MUNEXBE1.medline.com> I think the best analogy I would use in defense is something like the pre-paid cellular phones that are sold. That is about the only anonymous communications service I can think of off the top of my head. Problem is that most people are not licensed carriers and may not be able to hide behind that protection. I can see an argument both ways with the feds saying that you are running a service for the express service of concealing the identity of a person allowing them to avoid law enforcement (among other uses). On the other hand, the makers of guns do not get charged with murder even though their tool enabled a criminal. Could go either way but the problem is that in any case it will be expensive to defend so win or lose, you lose. I guess you can't run a Tor exit unless you have a legal defense fund set up. I understand the legit uses of Tor but wonder what the actual percentage of good vs. evil use really is. Steven Naslund -----Original Message----- From: Barry Shein [mailto:bzs at world.std.com] Sent: Thursday, November 29, 2012 10:17 AM To: NANOG list Subject: Re: William was raided for running a Tor exit node. Please help if you can. Back in the early days of the public internet we didn't require any id to create an account, just that you found a way to pay us. We had anonymous accts some of whom dropped by personally to pay their bill, some said hello but I usually didn't know their names and that's how they wanted it, I'd answer "hello ", whatever their login was if I recognized them. Some mailed in something, a mail order, even currency tho that was rare but it did happen, or had someone else drop by to pay in cash (that is, no idea if they were local.) LEO occasionally served a warrant for information, usually child porn biz (more than just accessing child porn, selling it) tho I don't remember any anonymous accts being involved. I never expected to be held accountable for anyone's behavior unless I was knowingly involved somehow (just the usual caveat.) LEO never showed any particular interest in the fact that we were ok with anonymous accounts. If I was made aware of illegal activities we'd shut them off, didn't really happen much, maybe some credible "hacking" complaint on occasion. It's funny, it's all illusion like show business. It's not hard to set up anonymous service, crap, just drop in at any wi-fi hotspot, many just ask you to click that you accept their T&Cs and you're on. Would they raid them, I was just using one at a major hospital this week that was just like that, if someone used that for child porn etc? But I guess stick your nose out and say you're specifically offering anon accts and watch out I guess. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From eugen at leitl.org Thu Nov 29 19:22:33 2012 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 29 Nov 2012 20:22:33 +0100 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: <20121129192233.GQ9750@leitl.org> On Fri, Nov 30, 2012 at 01:14:08AM +1100, Emily Ozols wrote: > Hi, > > I gotta ask and I'm sure someone would if I didn't, but how do we know > this guy is legit? > He's jumped up on a forum saying, "Hey, police raided me, help. gib > mone plz" and failed to provide and reason as to how he's real and not > just making it up. > > Maybe if there's a way to know this guy is legit, I'll help out if > possible, but until then I'm just going to watch others with caution > and I suggest others do as well. This matter is being investigated by the Tor developers. It looks legitimate, so far. > On Fri, Nov 30, 2012 at 12:04 AM, Chris wrote: > > I'm not William and a friend pasted a link on IRC to me. I'm going to > > send him a few bucks because I know how it feels to get blindsided by > > the police on one random day and your world is turned upside down. > > > > Source: http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exit-accepting-donations-for-legal-expenses > > > > From the URL: > > > > Yes, it happened to me now as well - Yesterday i got raided for > > someone sharing child pornography over one of my Tor exits. > > I'm good so far, not in jail, but all my computers and hardware have > > been confiscated. > > (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) > > > > If convicted i could face up to 6 years in jail, of course i do not > > want that and i also want to try to set a legal base for running Tor > > exit nodes in Austria or even the EU. > > > > Sadly we have nothing like the EFF here that could help me in this > > case by legal assistance, so i'm on my own and require a good lawyer. > > Thus i'm accepting donations for my legal expenses which i expect to > > be around 5000-10000 EUR. > > > > If you can i would appreciate if you could donate a bit (every amount > > helps, even the smallest) either by PayPal (any currency is ok): > > https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZNBBD7EH4 > > > > Or by Bank Transfer (EUR only please): > > > > Holder: William Weber > > Bank: EasyBank AG (Vienna, Austria) > > Account: 20011351213 > > Bank sort number: 14200 > > IBAN: AT031420020011351213 > > BIC: EASYATW1 > > > > I will try to pay them back when i'm out of this (or even before) but > > i can obviously not guarantee this, please keep this in mind. > > This money will only be used for legal expenses related to this case. > > > > If you have any questions or want to donate by another way > > (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel free > > to send me a mail (william at william.si) or a PM, or contact me in LET > > IRC. > > > > Thanks! > > William > > > > > > > > > > -- > > --C > > > > "The dumber people think you are, the more surprised they're going to > > be when you kill them." - Sir William Clayton > > > > > > -- > ~Em -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From michael at rancid.berkeley.edu Thu Nov 29 19:33:38 2012 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Thu, 29 Nov 2012 11:33:38 -0800 Subject: OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field In-Reply-To: References: Message-ID: <50B7B892.8060409@rancid.berkeley.edu> Jeff and NANOG: We are currently dropping the bad attribute within our network (as293) and are working with the customer to determine the origin of the attribute (equipment, code rev, etc.). The bad attribute should not be leaking beyond our AS at all. If you're filtering routes from AS68, you should be able to resume accepting routes from that AS. michael On 11/29/12 12:44 AM, Jeff Wheeler wrote: > I had two downstream BGP customers experience problem with an OpenBGPd bug > tonight. Before diving into detail, I would like to link this mailing list > thread, because this is not a new issue and a patch is available: > http://www.mail-archive.com/misc at openbsd.org/msg115071.html > > For the following DFZ routes, I see wrong use of the fifth bit in the > Attribute Flags field: > Aggregator (7), length: 8, Flags [OT+8]: AS #68, origin > 192.65.95.253 > 0x0000: 0000 0044 c041 5ffd > Updated routes: > 128.165.0.0/16 > 141.111.0.0/16 > 192.65.95.0/24 > 192.12.184.0/24 > 204.121.0.0/16 > > According to RFC 4271 page 17, "the low-order four bits of the Attribute > Flags octet are unused. They MUST be zero when sent and MUST be ignored > when received." I read "ignored" to mean, don't tear down the BGP session > and print a cryptic error that the user probably will be unable to debug. > The OpenBGPd guys clearly agree and have supplied a patch, so affected > users should visit the above mailing list link, and install it. > > Here are my notes for this RFC page and a small diagram of the packet > header, because surprisingly, there isn't one in the RFC already > http://inconcepts.biz/~jsw/img/1121129aa-rfc4271pg17scan.jpg Sorry about > the poor quality of this, but it is past 3am here, and I know of several > operators (besides my downstream customers) who are experiencing this > problem right now. > > If I were someone who is broken by this right now, I would either patch my > OpenBGPd or ask your eBGP neighbors not to send you the above five routes > (filtering it on your own OpenBGPd router probably won't help.) > > Thanks, I hope this is helpful > From scott at sberkman.net Thu Nov 29 19:34:33 2012 From: scott at sberkman.net (Scott Berkman) Date: Thu, 29 Nov 2012 14:34:33 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D7117E5@MUNEXBE1.medline.com> References: <20663.35479.561328.722417@world.std.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D7117E5@MUNEXBE1.medline.com> Message-ID: <005301cdce68$8fce3930$af6aab90$@sberkman.net> Not sure if there is a legal precedent for this, but logically the difference is that there are no robots that I know of that can automatically receive and parse postal mail, then re-address and forward it. For a human to forward a letter takes a conscious manual action, even if they choose not to look inside. Having a Tor node for no specific purpose, having a hacked server/pc that is then compromised for some nefarious purpose, etc. are not necessarily purposeful actions that one could be held accountable for without other proof. I'd think the LEA would have to establish motive, like in any other crime, to make that jump. Perhaps in this case they believe they have, and that would end up in the courts, where you'd have to hope the Judge and or Jury sees that difference. Don't see this as very different either from when an agency confiscates a whole rack of shared servers because one user was suspected of some bad action, and we all know that does happen. -Scott -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Thursday, November 29, 2012 2:07 PM To: nanog at nanog.org Subject: RE: William was raided for running a Tor exit node. Please help if you can. How would this be legally different than receiving the illegal content in an envelope and anonymously forwarding the envelope via the post office? I am pretty sure you are still liable since you were the sender. I realize that there are special postal regulations but I think that agreeing to forward anything for anyone sight unseen is pretty risky and I think you will have a hard time pulling of the "service provider" defense if you are not selling services and are not licensed as a carrier. Steven Naslund -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Thursday, November 29, 2012 10:45 AM To: NANOG list Subject: Re: William was raided for running a Tor exit node. Please help if you can. On Nov 29, 2012, at 11:17 , Barry Shein wrote: > Back in the early days of the public internet we didn't require any > id to create an account, just that you found a way to pay us. We had > anonymous accts some of whom dropped by personally to pay their bill, > some said hello but I usually didn't know their names and that's how > they wanted it, I'd answer "hello ", whatever their login was > if I recognized them. Some mailed in something, a mail order, even > currency tho that was rare but it did happen, or had someone else drop > by to pay in cash (that is, no idea if they were local.) > > LEO occasionally served a warrant for information, usually child porn > biz (more than just accessing child porn, selling it) tho I don't > remember any anonymous accts being involved. "Mere conduit" defense. (Please do not anyone mention "common carrier status" or the like, ISPs are _not_ common carriers.) > I never expected to be held accountable for anyone's behavior unless I > was knowingly involved somehow (just the usual caveat.) LEO never > showed any particular interest in the fact that we were ok with > anonymous accounts. If I was made aware of illegal activities we'd > shut them off, didn't really happen much, maybe some credible > "hacking" complaint on occasion. How do you "shut off" a Tor "account"? > It's funny, it's all illusion like show business. It's not hard to set > up anonymous service, crap, just drop in at any wi-fi hotspot, many > just ask you to click that you accept their T&Cs and you're on. Would > they raid them, I was just using one at a major hospital this week > that was just like that, if someone used that for child porn etc? But > I guess stick your nose out and say you're specifically offering anon > accts and watch out I guess. Do you think if the police found out child pr0n was being served from a starbux they wouldn't confiscate the equipment from that store? -- TTFN, patrick From elw at stderr.org Thu Nov 29 19:38:51 2012 From: elw at stderr.org (elijah wright) Date: Thu, 29 Nov 2012 13:38:51 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121129192233.GQ9750@leitl.org> References: <20121129192233.GQ9750@leitl.org> Message-ID: We had a guy (aka potential customer) inquire the other day about hosting a Tor exit on our infrastructure the other day; he disappeared fairly quickly when he figured out that we weren't just going to give him an endless supply of unmetered 10G bandwidth. I was looking forward to billing him. :-) I'm not sure that armchair lawyering, here, actually helps anyone. Also, spel-chek, sequitur. best, --e On Thu, Nov 29, 2012 at 1:22 PM, Eugen Leitl wrote: > On Fri, Nov 30, 2012 at 01:14:08AM +1100, Emily Ozols wrote: > > Hi, > > > > I gotta ask and I'm sure someone would if I didn't, but how do we know > > this guy is legit? > > He's jumped up on a forum saying, "Hey, police raided me, help. gib > > mone plz" and failed to provide and reason as to how he's real and not > > just making it up. > > > > Maybe if there's a way to know this guy is legit, I'll help out if > > possible, but until then I'm just going to watch others with caution > > and I suggest others do as well. > > This matter is being investigated by the Tor developers. > It looks legitimate, so far. > > > On Fri, Nov 30, 2012 at 12:04 AM, Chris wrote: > > > I'm not William and a friend pasted a link on IRC to me. I'm going to > > > send him a few bucks because I know how it feels to get blindsided by > > > the police on one random day and your world is turned upside down. > > > > > > Source: > http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exit-accepting-donations-for-legal-expenses > > > > > > From the URL: > > > > > > Yes, it happened to me now as well - Yesterday i got raided for > > > someone sharing child pornography over one of my Tor exits. > > > I'm good so far, not in jail, but all my computers and hardware have > > > been confiscated. > > > (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) > > > > > > If convicted i could face up to 6 years in jail, of course i do not > > > want that and i also want to try to set a legal base for running Tor > > > exit nodes in Austria or even the EU. > > > > > > Sadly we have nothing like the EFF here that could help me in this > > > case by legal assistance, so i'm on my own and require a good lawyer. > > > Thus i'm accepting donations for my legal expenses which i expect to > > > be around 5000-10000 EUR. > > > > > > If you can i would appreciate if you could donate a bit (every amount > > > helps, even the smallest) either by PayPal (any currency is ok): > > > > https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZNBBD7EH4 > > > > > > Or by Bank Transfer (EUR only please): > > > > > > Holder: William Weber > > > Bank: EasyBank AG (Vienna, Austria) > > > Account: 20011351213 > > > Bank sort number: 14200 > > > IBAN: AT031420020011351213 > > > BIC: EASYATW1 > > > > > > I will try to pay them back when i'm out of this (or even before) but > > > i can obviously not guarantee this, please keep this in mind. > > > This money will only be used for legal expenses related to this case. > > > > > > If you have any questions or want to donate by another way > > > (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel free > > > to send me a mail (william at william.si) or a PM, or contact me in LET > > > IRC. > > > > > > Thanks! > > > William > > > > > > > > > > > > > > > -- > > > --C > > > > > > "The dumber people think you are, the more surprised they're going to > > > be when you kill them." - Sir William Clayton > > > > > > > > > > > -- > > ~Em > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > From bill at herrin.us Thu Nov 29 19:40:31 2012 From: bill at herrin.us (William Herrin) Date: Thu, 29 Nov 2012 14:40:31 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: On Thu, Nov 29, 2012 at 2:06 PM, Patrick W. Gilmore wrote: > On Nov 29, 2012, at 13:57 , William Herrin wrote: >> On Thu, Nov 29, 2012 at 11:45 AM, Patrick W. Gilmore wrote: >>> Do you think if the police found out child pr0n was >>> being served from a starbux they wouldn't >>> confiscate the equipment from that store? >> >> I think if they took the cash registers too the Starbucks lawyer would >> be in court an hour later with a motion to quash in one hand and an >> offer of full cooperation in the other. > > And if the sky were orange.... > Any other non-sequitors? :) All of Mr. Weber's equipment was seized. Last I checked the cash registers at Starbucks were networked computers too. Maybe your Starbucks is different. Mr. Weber lives in another jurisdiction, but in the U.S. the warrant is limited to material plausibly connected to the alleged crime. If the guy was shot with a 9mm and the warrant says "all firearms," it's unlawfully broad. The most it should be is "small calliber handguns" and not even that much if they know for sure it's a 9mm. If the police seize a shotgun and a couple of knives, they've overstepped. If the computer at IP:port:timestamp transmitted child porn, a warrant for "all computers" is also too broad. "Computers which use said IP address or which employ forensic countermeasures which prevent a ready determination whether they employed said IP address." And have a qualified technician on the search team, same as you would for any other material being searched. On the flip side, I think that if you're running a Tor node you'd better hope the police *want* your cooperation. If they don't your activity falls somewhere between criminal recklessness and criminal facilitation. Seriously, who do you think uses your Tor node? Whistle blowers exposing corruption and freedom loving libertarians? Fool. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Thu Nov 29 19:42:11 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 29 Nov 2012 14:42:11 -0500 (EST) Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: Message-ID: <12776402.36770.1354218131856.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Patrick W. Gilmore" > "Mere conduit" defense. (Please do not anyone mention "common carrier > status" or the like, ISPs are _not_ common carriers.) > Do you think if the police found out child pr0n was being served from > a starbux they wouldn't confiscate the equipment from that store? Well, pursuant to the "mere conduit" defense, I believe (IANAL) a defensible case could be made that the (people operating) Tor nodes are not "servers" as that term is generally understood in the industry, in the same way that web browser/caches are not "copies" as IP law understands *that* term. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Thu Nov 29 19:44:16 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 29 Nov 2012 14:44:16 -0500 (EST) Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: Message-ID: <685268.36772.1354218256890.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Patrick W. Gilmore" > > I think if they took the cash registers too the Starbucks lawyer would > > be in court an hour later with a motion to quash in one hand and an > > offer of full cooperation in the other. > > And if the sky were orange.... > > Any other non-sequitors? :) > P.S. I can come up with some examples where the cash registers would > be fair game, such as when the manager was charging the hosting > provider extra to sit in the corner and host the 'bad content'. But it > is still a non-sequitor w/r/t this thread. The hell it is: cops sieze things which are not only not related to a crime, but cannot *possibly be* relevant to that crime *all the effing time*, Patrick. You know this, I'm sure. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From george.herbert at gmail.com Thu Nov 29 19:50:57 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 29 Nov 2012 11:50:57 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B7B519.8050608@localnet.com> References: <50B7B519.8050608@localnet.com> Message-ID: On Thu, Nov 29, 2012 at 11:18 AM, Tom Beecher wrote: > Assuming it's true, it was bound to happen. Running anything , TOR or > otherwise, that allows strangers to do whatever they want is just folly. Such as, say, an Internet Service Provider business? ... -- -george william herbert george.herbert at gmail.com From tbeecher at localnet.com Thu Nov 29 19:58:25 2012 From: tbeecher at localnet.com (Tom Beecher) Date: Thu, 29 Nov 2012 14:58:25 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com> Message-ID: <50B7BE61.9050403@localnet.com> Not really comparable. Speaking from a US point of view, ISPs has strong legal protections isolating them from culpability for the actions of their customers. I know internationally things are different, but here in the US the ISP doesn't get dinged, except in certain cases where they are legally required to remove access to material and don't. End users have no such protections that I'm aware of that cover them similarly. On 11/29/2012 2:50 PM, George Herbert wrote: > On Thu, Nov 29, 2012 at 11:18 AM, Tom Beecher wrote: >> Assuming it's true, it was bound to happen. Running anything , TOR or >> otherwise, that allows strangers to do whatever they want is just folly. > Such as, say, an Internet Service Provider business? > > ... > From SNaslund at medline.com Thu Nov 29 20:00:50 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 29 Nov 2012 14:00:50 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com> I think service providers are afforded special protections because the law recognizes their utility and the inability of the service provider to be responsible for the actions of all of their customers. The major problem is that not every individual has the same protections. A lot of ISPs are actually also CLECs or LECs that are protected as licensed telecom carriers. ISPs also do not "allow strangers to do whatever they want" ISPs have responsibilities to act on DCMA notices and CALEA requests from law enforcement. These are things that Tor exit nodes are not capable of doing. If you were an ISP and could not respond to CALEA requests, you will find yourself out of business in a big hurry. Steven Naslund -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Thursday, November 29, 2012 1:51 PM To: Tom Beecher; NANOG Subject: Re: William was raided for running a Tor exit node. Please help if you can. On Thu, Nov 29, 2012 at 11:18 AM, Tom Beecher wrote: > Assuming it's true, it was bound to happen. Running anything , TOR or > otherwise, that allows strangers to do whatever they want is just folly. Such as, say, an Internet Service Provider business? ... -- -george william herbert george.herbert at gmail.com From george.herbert at gmail.com Thu Nov 29 20:06:28 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 29 Nov 2012 12:06:28 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B7BE61.9050403@localnet.com> References: <50B7B519.8050608@localnet.com> <50B7BE61.9050403@localnet.com> Message-ID: On Thu, Nov 29, 2012 at 11:58 AM, Tom Beecher wrote: > Not really comparable. > > Speaking from a US point of view, ISPs has strong legal protections > isolating them from culpability for the actions of their customers. I know > internationally things are different, but here in the US the ISP doesn't get > dinged, except in certain cases where they are legally required to remove > access to material and don't. > > End users have no such protections that I'm aware of that cover them > similarly. > > > On 11/29/2012 2:50 PM, George Herbert wrote: >> >> On Thu, Nov 29, 2012 at 11:18 AM, Tom Beecher >> wrote: >>> >>> Assuming it's true, it was bound to happen. Running anything , TOR or >>> otherwise, that allows strangers to do whatever they want is just folly. >> >> Such as, say, an Internet Service Provider business? There are plenty of ISPs with no or little customer contracts; anyone running open access wireless. Plenty of "open access" sites with free accounts. And any but the largest ISPs are "end users" of upstream bandwidth. The analogy of a small free access ISP and a Tor exit node is legally defensible. I know of five, six, seven that I can think of off the top of my head that are run by people I know, one of whom has started and/or been architect or operations lead for 5 or more commercial ISPs. Even more, ISP like protections are extended in the US to many "end user" sites such as blogging sites, Wikis, etc; where the site is "publishing" content but not creating it or exerting control over it, etc. This is US specific, and the case of a user in Austria is entirely unrelated to US law, but I don't know that this type of response would hold up in US court for these reasons. I am going to ping my internet law contacts in the US and see what they think, as IANAL. -- -george william herbert george.herbert at gmail.com From george.herbert at gmail.com Thu Nov 29 20:14:10 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 29 Nov 2012 12:14:10 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com> References: <50B7B519.8050608@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com> Message-ID: On Thu, Nov 29, 2012 at 12:00 PM, Naslund, Steve wrote: > ISPs also do not "allow strangers to do whatever they want" ISPs have > responsibilities to act on DCMA notices and CALEA requests from law > enforcement. These are things that Tor exit nodes are not capable of > doing. If you were an ISP and could not respond to CALEA requests, you > will find yourself out of business in a big hurry. Sure, Tor exit nodes are 'capable of doing' those things if a report is generated that someone's using it to source child porn or terrorist communications or DMCA violations. At the most extreme the owner can shut down a node; they might also put egress filters in place pursuant to notifications. Plenty of small ISPs in one sense or another don't comply with CALEA because they own systems not networks (open access sites, etc). CALEA goes to the network providers in those cases, as I understand it. The Tor owner also might chose to fight it and leave it completely open, but an ISP might chose to do that in response to certain notices as well. This presumes that law enforcement deems them the right place to go investigating an incident, and notifies them. But if they seem to be aware of what Tor is in the US and be generally reasonable in responding to issues with it, that I know of. -- -george william herbert george.herbert at gmail.com From tbeecher at localnet.com Thu Nov 29 20:26:57 2012 From: tbeecher at localnet.com (Tom Beecher) Date: Thu, 29 Nov 2012 15:26:57 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com> <50B7BE61.9050403@localnet.com> Message-ID: <50B7C511.6030805@localnet.com> Communications Decency Act, 47 U.S.C. ?230 is the US law that has been interpreted to provide immunity to ISP for the actions of their users. Zeran v. America Online, Inc., 4th Circuit, 1997 Jane Doe v. America Online, Inc., 5th Circuit, 1997 Blumenthal v. Drudge, DC District, 1998 Green v. AOL, 3rd Circuit, 2003 Gentry v. eBay, Inc, California Appeals, 2002 Delfino v. Agilent Technologies, California Appeals, 2006 The ISP ones are most relevant here, but look at these cases. The situation would be complicated if the ISP ran the TOR exit node themselves, and that would be a messy legal battle I'm sure. Either way, that doesn't change the fact that running a TOR exit on a home PC on a residential internet connection is silly. You might legally not be held responsible at the end of the day, but it just may cost you a lot in legal fees to get there. Personally, I have better things to spend money on. On 11/29/2012 3:06 PM, George Herbert wrote: > On Thu, Nov 29, 2012 at 11:58 AM, Tom Beecher wrote: >> Not really comparable. >> >> Speaking from a US point of view, ISPs has strong legal protections >> isolating them from culpability for the actions of their customers. I know >> internationally things are different, but here in the US the ISP doesn't get >> dinged, except in certain cases where they are legally required to remove >> access to material and don't. >> >> End users have no such protections that I'm aware of that cover them >> similarly. >> >> >> On 11/29/2012 2:50 PM, George Herbert wrote: >>> On Thu, Nov 29, 2012 at 11:18 AM, Tom Beecher >>> wrote: >>>> Assuming it's true, it was bound to happen. Running anything , TOR or >>>> otherwise, that allows strangers to do whatever they want is just folly. >>> Such as, say, an Internet Service Provider business? > There are plenty of ISPs with no or little customer contracts; anyone > running open access wireless. Plenty of "open access" sites with free > accounts. > > And any but the largest ISPs are "end users" of upstream bandwidth. > > The analogy of a small free access ISP and a Tor exit node is legally > defensible. I know of five, six, seven that I can think of off the > top of my head that are run by people I know, one of whom has started > and/or been architect or operations lead for 5 or more commercial > ISPs. > > Even more, ISP like protections are extended in the US to many "end > user" sites such as blogging sites, Wikis, etc; where the site is > "publishing" content but not creating it or exerting control over it, > etc. > > This is US specific, and the case of a user in Austria is entirely > unrelated to US law, but I don't know that this type of response would > hold up in US court for these reasons. I am going to ping my internet > law contacts in the US and see what they think, as IANAL. > > -- Thomas Beecher II Senior Network Administrator LocalNet Corp. CoreComm Internet Services 716-799-8881 tbeecher at localnet.com From SNaslund at medline.com Thu Nov 29 20:42:47 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 29 Nov 2012 14:42:47 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com><2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7118FD@MUNEXBE1.medline.com> The entire point of Tor is to be untraceable back to the source. Egress filters can prevent future abuse but do not provide for tracing back to the original source of offending conduct. They are not trying to stop the flow of the data in this case, they want the source in jail. If law enforcement comes to you and asks you to show them the source or destination on a case like the one in question, you cannot comply and if law enforcement asks you to trap this data in the future you will also have a problem complying because I think you cannot identify the original source. You ARE providing a network if you are running a Tor exit node just the same as someone who builds a MPLS VPN would be responsible for responding to law enforcement requests for data inside the secure network. A licensed LEC and CLEC has very specific requirements in terms of CALEA and DCMA. It is not something they optionally comply with. An ISP that does not respond to CALEA and DCMA can become liable for events that happen after their non-response. Their "safe harbor" protection ends the moment they do not act in good faith to comply with the law. Even a small ISP that does not own their own network can be subpoenaed to provide logs, sniffer traces, and file dumps from any system they own. I know this for a fact and have provided this data under court orders. CALEA applies just as well to servers and data as it does to the communication circuits themselves. If you have a server on the network, it has a communications circuit into it and you can be required to provide access to that circuit. You can also be required to tap email accounts or data directories as well. This data may not fall strictly under CALEA but a court order can compel you to provide any data you are in possession of. That is why law enforcement can grab a server or PC. ISPs and carriers are often given the benefit of the doubt and law enforcement accepts copies of data they want. If they view you as an adversary or have any inclination of hiding data, they will seize the machine. If they view a Tor exit node owner as an accessory, they are not going to be nicey nice about it. The main problem with Tor is that it purposefully attempts to make this data obscure which could be construed as obstruction. As far as US law enforcement attitudes on Tor, those can and will change as the government sees fit. It is all a matter of the "greater good" in their eyes and whether they think the fight is worthwhile. You better believe that as soon as it becomes a "national security threat" it is coming down. Steven Naslund -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Thursday, November 29, 2012 2:14 PM To: Naslund, Steve Cc: NANOG Subject: Re: William was raided for running a Tor exit node. Please help if you can. On Thu, Nov 29, 2012 at 12:00 PM, Naslund, Steve wrote: > ISPs also do not "allow strangers to do whatever they want" ISPs have > responsibilities to act on DCMA notices and CALEA requests from law > enforcement. These are things that Tor exit nodes are not capable of > doing. If you were an ISP and could not respond to CALEA requests, > you will find yourself out of business in a big hurry. Sure, Tor exit nodes are 'capable of doing' those things if a report is generated that someone's using it to source child porn or terrorist communications or DMCA violations. At the most extreme the owner can shut down a node; they might also put egress filters in place pursuant to notifications. Plenty of small ISPs in one sense or another don't comply with CALEA because they own systems not networks (open access sites, etc). CALEA goes to the network providers in those cases, as I understand it. The Tor owner also might chose to fight it and leave it completely open, but an ISP might chose to do that in response to certain notices as well. This presumes that law enforcement deems them the right place to go investigating an incident, and notifies them. But if they seem to be aware of what Tor is in the US and be generally reasonable in responding to issues with it, that I know of. -- -george william herbert george.herbert at gmail.com From marka at isc.org Thu Nov 29 20:46:54 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 30 Nov 2012 07:46:54 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Thu, 29 Nov 2012 09:01:30 CDT." References: <50AB49EA.3030101@cis.vutbr.cz> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfi x.org> Message-ID: <20121129204654.9F2F82C5E347@drugs.dv.isc.org> In message , Ray Soucy writes: > You should store IPv6 as a pair of 64-bit integers. While PHP lacks > the function set to do this on its own, it's not very difficult to do. I did it as a array of 8, 16 bit integers with a old version of dhclient. The had the advantage that you could just do "%x:%x:%x:%x:%x:%x:%x:%x" and get a valid IPv6 address which you could feed to other tools. option 6rd code 212 = { unsigned integer 8, unsigned integer 8, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, array of ip-address }; > Here are a set of functions I wrote a while back to do just that > (though I admit I should spend some time to try and make it more > elegant and I'm not sure it's completely up to date compared to my > local copy ... I would love some eyes on it to make some > improvements). > > http://soucy.org/project/inet6/ > > > > > I would point out that many developers don't even store IP addresses > correctly and just treat them as a string. In regards to storing as a > pair of 64-bit integers, I would caution against the temptation of > treating one field as the prefix and the other as the host segment. > While the 64-bit boundary is most common, it is certainly not > required, so please write your IPv6 support in a way that will allow > any valid prefix-length. > > > > > While PHP hasn't been my language of choice in the past, it seems to > be something that almost everyone knows, or can learn very quickly. > I've started using it as a command line scripting language quite a bit > as a result ... pretty much a cleaner Perl, the upshot is that you > don't have all the pre-written libraries that you'd find with Perl. > I've tried switching to Python for some things, but I got annoyed with > the specification being in a constant state of drastic syntax change. > > > > > But back to the topic at hand. I think the OP was expressing that > until developers have native IPv6 access at home, they just won't care > about IPv6 support, or won't test it as well as IPv4 support. That's > pretty much expected and I'm not even sure why it's being stated as > some revelation. As many have pointed out, there are tunnel brokers > available to developers to test IPv6 with, but at the end of the day, > most people don't want to use a slow tunnel for anything byond > testing, and if they don't have a lot of users asking for IPv6 they're > probably not going to give it much attention until they see a need for > it. It is a myth that tunnels are slow. They have to add some delay but depending upon the placement of the end point that may not even be measurable. I'm using one on another continent and for most of my traffic it has no measurable impact on the time. Some detinations are significantly worse. Tunneling with 6rd will generally not be measurable for any destination especially if you put the BR in the pop. > The majority of larger applications support IPv6 just fine because > there are enough users asking for IPv6 support. I suspect once you > see native IPv6 for residential users become more common you'll see > the developers who have been dragging their feet give in and add IPv6 > support. > > As mentioned with a shift to web applications though the browser, it's > been a lot less work. Just throw your application on a server with > IPv6 and it will generally work. You might need to modify a few > places that interact with IP addresses, but usually they're pretty > trivial (like logging) unless it's a network management oriented > application. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From george.herbert at gmail.com Thu Nov 29 20:53:23 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 29 Nov 2012 12:53:23 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D7118FD@MUNEXBE1.medline.com> References: <50B7B519.8050608@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D7118FD@MUNEXBE1.medline.com> Message-ID: On Thu, Nov 29, 2012 at 12:42 PM, Naslund, Steve wrote: > The entire point of Tor is to be untraceable back to the source. Egress > filters can prevent future abuse but do not provide for tracing back to > the original source of offending conduct. They are not trying to stop > the flow of the data in this case, they want the source in jail. If law > enforcement comes to you and asks you to show them the source or > destination on a case like the one in question, you cannot comply and if > law enforcement asks you to trap this data in the future you will also > have a problem complying because I think you cannot identify the > original source. If you run an open wireless access point and don't log MACs / MAC to IP DHCP assignments, you are in similar straights. If they come to you 31 days after the data flow and you retain logs for 30, you are in similar straights. If someone faked their wireless MAC and the data in your log is not definitive, everyone's stymied. If someone went into a Library and used an open access computer, there's often no log of who / when. The assertion being made here, that it's somehow illegal (or immoral, or scary) for there to be not-completely-traceable internet access in the US, is absurd. CALEA doesn't say what you're asserting. From the First Report and Order: "24. In this section, we find that facilities-based providers of any type of broadband Internet access service, including but not limited to wireline, cable modem, satellite, wireless, fixed wireless, and broadband access via powerline are subject to CALEA" ( http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-05-153A1.pdf ) If you're not a facilities-based provider, you aren't covered. -- -george william herbert george.herbert at gmail.com From SNaslund at medline.com Thu Nov 29 20:59:18 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 29 Nov 2012 14:59:18 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com> <50B7BE61.9050403@localnet.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D711928@MUNEXBE1.medline.com> 1. Running open access wireless does not make you legally an ISP and if your open wireless is used to commit a crime you could be criminally negligent if you did not take "reasonable care" in the eyes of the court. 2. If I provide access to four or five friends, I am not an ISP and in fact I am responsible if they use my connection to do something illegal since I am the customer of record. If you loan your car to an unlicensed driver and he kills someone, you are on the hook. 3. I guarantee you that if your blogging site, wiki or whatever is publishing content like child porn, you are going to jail. There is no "ISP like protections" for that. If you do not take action as soon as you know a crime is being committed, you are going to get nailed. The question in this case would be all about whether the Tor exit node is viewed as a device specifically enabling a criminal or something that was incidentally used to commit a crime. For example, if I give you a hammer and you break into someone's house with it, I am probably not criminally negligent. If I provided you with lock picking equipment and you are not a locksmith, I might be criminally negligent. This is not so clear cut a case that there would not be a fight about it. Steven Naslund -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Thursday, November 29, 2012 2:06 PM To: Tom Beecher Cc: NANOG Subject: Re: William was raided for running a Tor exit node. Please help if you can. On Thu, Nov 29, 2012 at 11:58 AM, Tom Beecher wrote: > Not really comparable. > > Speaking from a US point of view, ISPs has strong legal protections > isolating them from culpability for the actions of their customers. I > know internationally things are different, but here in the US the ISP > doesn't get dinged, except in certain cases where they are legally > required to remove access to material and don't. > > End users have no such protections that I'm aware of that cover them > similarly. > > > On 11/29/2012 2:50 PM, George Herbert wrote: >> >> On Thu, Nov 29, 2012 at 11:18 AM, Tom Beecher >> wrote: >>> >>> Assuming it's true, it was bound to happen. Running anything , TOR >>> or otherwise, that allows strangers to do whatever they want is just folly. >> >> Such as, say, an Internet Service Provider business? There are plenty of ISPs with no or little customer contracts; anyone running open access wireless. Plenty of "open access" sites with free accounts. And any but the largest ISPs are "end users" of upstream bandwidth. The analogy of a small free access ISP and a Tor exit node is legally defensible. I know of five, six, seven that I can think of off the top of my head that are run by people I know, one of whom has started and/or been architect or operations lead for 5 or more commercial ISPs. Even more, ISP like protections are extended in the US to many "end user" sites such as blogging sites, Wikis, etc; where the site is "publishing" content but not creating it or exerting control over it, etc. This is US specific, and the case of a user in Austria is entirely unrelated to US law, but I don't know that this type of response would hold up in US court for these reasons. I am going to ping my internet law contacts in the US and see what they think, as IANAL. -- -george william herbert george.herbert at gmail.com From owen at delong.com Thu Nov 29 21:13:28 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Nov 2012 13:13:28 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unf! ix.org> Message-ID: <8906A643-9898-4FEC-B3EF-94522990541C@delong.com> Why would I want to do that instead of store it as a single 128 bit integer or bit-field? Owen Sent from my iPad On Nov 29, 2012, at 6:01 AM, Ray Soucy wrote: > You should store IPv6 as a pair of 64-bit integers. While PHP lacks > the function set to do this on its own, it's not very difficult to do. > > Here are a set of functions I wrote a while back to do just that > (though I admit I should spend some time to try and make it more > elegant and I'm not sure it's completely up to date compared to my > local copy ... I would love some eyes on it to make some > improvements). > > http://soucy.org/project/inet6/ > > > > > I would point out that many developers don't even store IP addresses > correctly and just treat them as a string. In regards to storing as a > pair of 64-bit integers, I would caution against the temptation of > treating one field as the prefix and the other as the host segment. > While the 64-bit boundary is most common, it is certainly not > required, so please write your IPv6 support in a way that will allow > any valid prefix-length. > > > > > While PHP hasn't been my language of choice in the past, it seems to > be something that almost everyone knows, or can learn very quickly. > I've started using it as a command line scripting language quite a bit > as a result ... pretty much a cleaner Perl, the upshot is that you > don't have all the pre-written libraries that you'd find with Perl. > I've tried switching to Python for some things, but I got annoyed with > the specification being in a constant state of drastic syntax change. > > > > > But back to the topic at hand. I think the OP was expressing that > until developers have native IPv6 access at home, they just won't care > about IPv6 support, or won't test it as well as IPv4 support. That's > pretty much expected and I'm not even sure why it's being stated as > some revelation. As many have pointed out, there are tunnel brokers > available to developers to test IPv6 with, but at the end of the day, > most people don't want to use a slow tunnel for anything byond > testing, and if they don't have a lot of users asking for IPv6 they're > probably not going to give it much attention until they see a need for > it. > > The majority of larger applications support IPv6 just fine because > there are enough users asking for IPv6 support. I suspect once you > see native IPv6 for residential users become more common you'll see > the developers who have been dragging their feet give in and add IPv6 > support. > > As mentioned with a shift to web applications though the browser, it's > been a lot less work. Just throw your application on a server with > IPv6 and it will generally work. You might need to modify a few > places that interact with IP addresses, but usually they're pretty > trivial (like logging) unless it's a network management oriented > application. > > > > > On Thu, Nov 29, 2012 at 8:15 AM, Jeroen Massar wrote: >> On 2012-11-29 13:53 , . wrote: >>> On 29 November 2012 12:48, Dobbins, Roland wrote: >>>> >>>> On Nov 29, 2012, at 6:47 PM, Bj?rn Mork wrote: >>>> >>>>> What's the proper term for software which happens to access the network? >>>> >>>> Just about anything, these days. >>>> >>>> ;> >>>> >>>> 'Network-enabled' or 'network-capable' software, maybe? >>> >>> Connecting a app to a network is a fundamental change, so perhaps >>> change the app to become a "network app". A piece of software >>> connected to a network turns from a product into a service. >>> >>> "Programmers" is to a wide group of people. I am PHP programmer. How >>> will ipv6 impact me? nothing, probably. >> >> *ahem* >> >> As Owen already alluded to, some programs (PHP also) actually store IP >> addresses in databases. Thus if you where storing those as 32bit, you >> are out of luck. >> >> [..] >>> There are two groups of programmers, a) these that have programming >>> only as a job, and b) these that invest time beyond that. >> >> Group a for you? :) >> >> Greets, >> Jeroen > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net From george.herbert at gmail.com Thu Nov 29 21:17:46 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 29 Nov 2012 13:17:46 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D711928@MUNEXBE1.medline.com> References: <50B7B519.8050608@localnet.com> <50B7BE61.9050403@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711928@MUNEXBE1.medline.com> Message-ID: The entire question here is whether CALEA's covered entities definition and ISP "common carrier" (not exactly, but the commonly used term for CDA protections available, see earlier discussion) definitions overlap. The answer is no. It always has been no. Plenty of publishers and access providers do not fall under CALEA. The FCC and law enforcement are aware of that. The conflation of the two in this conversation has not been useful or educational. What the future might hold is an open question, but for the time being, CDA protections are available (at least theoretically, or arguably) for a lot of people for whom CALEA clearly is not applicable. CDA protections are available whether you log commenters' IP addresses on your blog, keep long lasting web acces logs, allow unrestricted wireless access point access without logging, or what. Responsibility under it does not kick in unless you're aware of or notified of an issue, with some exceptions. Plenty of sites do not keep logs long and some do not log. -george On Thu, Nov 29, 2012 at 12:59 PM, Naslund, Steve wrote: > 1. Running open access wireless does not make you legally an ISP and if > your open wireless is used to commit a crime you could be criminally > negligent if you did not take "reasonable care" in the eyes of the > court. > > 2. If I provide access to four or five friends, I am not an ISP and in > fact I am responsible if they use my connection to do something illegal > since I am the customer of record. If you loan your car to an > unlicensed driver and he kills someone, you are on the hook. > > 3. I guarantee you that if your blogging site, wiki or whatever is > publishing content like child porn, you are going to jail. There is no > "ISP like protections" for that. If you do not take action as soon as > you know a crime is being committed, you are going to get nailed. > > The question in this case would be all about whether the Tor exit node > is viewed as a device specifically enabling a criminal or something that > was incidentally used to commit a crime. For example, if I give you a > hammer and you break into someone's house with it, I am probably not > criminally negligent. If I provided you with lock picking equipment and > you are not a locksmith, I might be criminally negligent. This is not > so clear cut a case that there would not be a fight about it. > > Steven Naslund > > > > -----Original Message----- > From: George Herbert [mailto:george.herbert at gmail.com] > Sent: Thursday, November 29, 2012 2:06 PM > To: Tom Beecher > Cc: NANOG > Subject: Re: William was raided for running a Tor exit node. Please help > if you can. > > On Thu, Nov 29, 2012 at 11:58 AM, Tom Beecher > wrote: >> Not really comparable. >> >> Speaking from a US point of view, ISPs has strong legal protections >> isolating them from culpability for the actions of their customers. I >> know internationally things are different, but here in the US the ISP >> doesn't get dinged, except in certain cases where they are legally >> required to remove access to material and don't. >> >> End users have no such protections that I'm aware of that cover them >> similarly. >> >> >> On 11/29/2012 2:50 PM, George Herbert wrote: >>> >>> On Thu, Nov 29, 2012 at 11:18 AM, Tom Beecher >>> wrote: >>>> >>>> Assuming it's true, it was bound to happen. Running anything , TOR >>>> or otherwise, that allows strangers to do whatever they want is just > folly. >>> >>> Such as, say, an Internet Service Provider business? > > There are plenty of ISPs with no or little customer contracts; anyone > running open access wireless. Plenty of "open access" sites with free > accounts. > > And any but the largest ISPs are "end users" of upstream bandwidth. > > The analogy of a small free access ISP and a Tor exit node is legally > defensible. I know of five, six, seven that I can think of off the top > of my head that are run by people I know, one of whom has started and/or > been architect or operations lead for 5 or more commercial ISPs. > > Even more, ISP like protections are extended in the US to many "end > user" sites such as blogging sites, Wikis, etc; where the site is > "publishing" content but not creating it or exerting control over it, > etc. > > This is US specific, and the case of a user in Austria is entirely > unrelated to US law, but I don't know that this type of response would > hold up in US court for these reasons. I am going to ping my internet > law contacts in the US and see what they think, as IANAL. > > > -- > -george william herbert > george.herbert at gmail.com > -- -george william herbert george.herbert at gmail.com From paul4004 at gmail.com Thu Nov 29 21:21:14 2012 From: paul4004 at gmail.com (PC) Date: Thu, 29 Nov 2012 14:21:14 -0700 Subject: OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field In-Reply-To: <50B7B892.8060409@rancid.berkeley.edu> References: <50B7B892.8060409@rancid.berkeley.edu> Message-ID: If you hear anything more, I'd be interesting in knowing about it. I had a an upstream going up and down last night; reportedly their BGP process was core dumping due to a BGP attribute issue. I never found out what vendor it was though. Paul On Thu, Nov 29, 2012 at 12:33 PM, Michael Sinatra < michael at rancid.berkeley.edu> wrote: > Jeff and NANOG: > > We are currently dropping the bad attribute within our network (as293) > and are working with the customer to determine the origin of the > attribute (equipment, code rev, etc.). The bad attribute should not be > leaking beyond our AS at all. If you're filtering routes from AS68, you > should be able to resume accepting routes from that AS. > > michael > > On 11/29/12 12:44 AM, Jeff Wheeler wrote: > > I had two downstream BGP customers experience problem with an OpenBGPd > bug > > tonight. Before diving into detail, I would like to link this mailing > list > > thread, because this is not a new issue and a patch is available: > > http://www.mail-archive.com/misc at openbsd.org/msg115071.html > > > > For the following DFZ routes, I see wrong use of the fifth bit in the > > Attribute Flags field: > > Aggregator (7), length: 8, Flags [OT+8]: AS #68, origin > > 192.65.95.253 > > 0x0000: 0000 0044 c041 5ffd > > Updated routes: > > 128.165.0.0/16 > > 141.111.0.0/16 > > 192.65.95.0/24 > > 192.12.184.0/24 > > 204.121.0.0/16 > > > > According to RFC 4271 page 17, "the low-order four bits of the Attribute > > Flags octet are unused. They MUST be zero when sent and MUST be ignored > > when received." I read "ignored" to mean, don't tear down the BGP > session > > and print a cryptic error that the user probably will be unable to debug. > > The OpenBGPd guys clearly agree and have supplied a patch, so affected > > users should visit the above mailing list link, and install it. > > > > Here are my notes for this RFC page and a small diagram of the packet > > header, because surprisingly, there isn't one in the RFC already > > http://inconcepts.biz/~jsw/img/1121129aa-rfc4271pg17scan.jpg Sorry > about > > the poor quality of this, but it is past 3am here, and I know of several > > operators (besides my downstream customers) who are experiencing this > > problem right now. > > > > If I were someone who is broken by this right now, I would either patch > my > > OpenBGPd or ask your eBGP neighbors not to send you the above five routes > > (filtering it on your own OpenBGPd router probably won't help.) > > > > Thanks, I hope this is helpful > > > > > From ralph.brandt at pateam.com Thu Nov 29 21:52:06 2012 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Thu, 29 Nov 2012 16:52:06 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> Message-ID: <51C66083768C2949A7EB14910C78B01701BA478F@embgsr24.pateam.com> I have read a little of this BS thread. 1) I have been maintaining a network for 12 years. 2) I am and have been since Feb 1965 a programmer. Anyone who bashes either group has a problem. First, at one time programmers knew bits, bytes, opcodes, machine codes etc. I have written close to thirty languages and probably could write most of them now with a couple hours to browse a manual. I have done everything from punchdowns and crimping connectors to routing and ACL's. Sure there is a lot I do not know. But most of what academia has turned out in the last twenty years is people who know the left half of the byte but not the right. Today they don't even have an idea what happens. I am not sure some of them know that a computer runs on electricity. And it is nearly as bad in Networking as it is in Programming, Data Base, etc. We are building "experts" who have learned more and more about less and less till they know everything about nothing. You need six of them to plug in a router. Somewhere we need some of them to get out of their little silo, find out that there is a world out there and learn what the other guy does. When that happens the finger pointing that was just done here will not happen. Ralph Brandt From stu at spacehopper.org Thu Nov 29 22:00:22 2012 From: stu at spacehopper.org (Stuart Henderson) Date: Thu, 29 Nov 2012 22:00:22 +0000 (UTC) Subject: OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field References: Message-ID: On 2012-11-29, Jeff Wheeler wrote: > I had two downstream BGP customers experience problem with an OpenBGPd bug > tonight. Before diving into detail, I would like to link this mailing list > thread, because this is not a new issue and a patch is available: > http://www.mail-archive.com/misc at openbsd.org/msg115071.html Note that this was committed to OpenBGP on 12 August, so if you're running a *snapshot* from after that date, you won't be affected. It made it too late for OpenBSD 5.2 but has just been committed to the patch branch, so building from a newly-updated source checkout tagged OPENBSD_5_2 will also have this. Looks like this is in 5.2.20121014 in FreeBSD ports too. -sthen From jim at reptiles.org Thu Nov 29 22:00:39 2012 From: jim at reptiles.org (Jim Mercer) Date: Thu, 29 Nov 2012 17:00:39 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D71181A@MUNEXBE1.medline.com> References: <20663.35479.561328.722417@world.std.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D71181A@MUNEXBE1.medline.com> Message-ID: <20121129220039.GA90089@reptiles.org> On Thu, Nov 29, 2012 at 01:19:19PM -0600, Naslund, Steve wrote: > I think the best analogy I would use in defense is something like the > pre-paid cellular phones that are sold. That is about the only > anonymous communications service I can think of off the top of my head. > Problem is that most people are not licensed carriers and may not be > able to hide behind that protection. if your phone is stolen and used by a drug dealer, i'm pretty sure the cops would not be after you for anything the dealer did. if you stand on the corner with a sign saying "free cell phone airtime, just ask me", they might take a different view on things. now, whether you are guilty of anything or not, by standing there with a sign you are certainly opening yourself to legal inquiry, delay and hassle. i wouldn't be surprised if the cops didn't accept your "i'm just letting people use my phone, i've got nothing to do with their activities" defence, at least not without poking about for a bit, which might include looking at your cellphone, your home phone, your bank records, and anything else they think (and a judge agrees) might need viewing to clear you. -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From bonomi at mail.r-bonomi.com Thu Nov 29 22:06:14 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 29 Nov 2012 16:06:14 -0600 (CST) Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B7C511.6030805@localnet.com> Message-ID: <201211292206.qATM6EN0036004@mail.r-bonomi.com> > Date: Thu, 29 Nov 2012 15:26:57 -0500 > From: Tom Beecher > Subject: Re: William was raided for running a Tor exit node. Please help if > you can. > > Communications Decency Act, 47 U.S.C. 230 is the US law that has been > interpreted to provide immunity to ISP for the actions of their users. It is worth noting that 47 U.S.C. 230 provides _limited_ protections, only. Broad protection, but limited. It says that a provider shall not 'be treated as author' for material provided by someone else. This of little-to-no help with regard to kiddie porn, since distribution, and even 'mere' possession, are crimes -- independant of authorship. From tbeecher at localnet.com Thu Nov 29 22:31:52 2012 From: tbeecher at localnet.com (Tom Beecher) Date: Thu, 29 Nov 2012 17:31:52 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <201211292206.qATM6EN0036004@mail.r-bonomi.com> References: <201211292206.qATM6EN0036004@mail.r-bonomi.com> Message-ID: <50B7E258.2020809@localnet.com> 47 U.S.C. 230 doesn't do much for child porn, no. However, PROTECT does. PROTECT spells out reporting, but also contains safe harbor provisions such that an ISP who didn't know that child porn was being transmitted across their network cannot be prosecuted for not knowing, only for not taking the required reporting/preservation/destruction actions as required by law. And in practice, the process is: On 11/29/2012 5:06 PM, Robert Bonomi wrote: >> Date: Thu, 29 Nov 2012 15:26:57 -0500 >> From: Tom Beecher >> Subject: Re: William was raided for running a Tor exit node. Please help if >> you can. >> >> Communications Decency Act, 47 U.S.C. 230 is the US law that has been >> interpreted to provide immunity to ISP for the actions of their users. > It is worth noting that 47 U.S.C. 230 provides _limited_ protections, only. > Broad protection, but limited. It says that a provider shall not 'be > treated as author' for material provided by someone else. > > This of little-to-no help with regard to kiddie porn, since distribution, > and even 'mere' possession, are crimes -- independant of authorship. > > > > > From froomkin at law.miami.edu Thu Nov 29 23:07:48 2012 From: froomkin at law.miami.edu (Michael Froomkin - U.Miami School of Law) Date: Thu, 29 Nov 2012 18:07:48 -0500 (EST) Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D711928@MUNEXBE1.medline.com> References: <50B7B519.8050608@localnet.com> <50B7BE61.9050403@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711928@MUNEXBE1.medline.com> Message-ID: On Thu, 29 Nov 2012, Naslund, Steve wrote: > 1. Running open access wireless does not make you legally an ISP and if OK. > your open wireless is used to commit a crime you could be criminally > negligent if you did not take "reasonable care" in the eyes of the > court. > I believe this is incorrect under US law. Do you have any support, statutory or case law, for this claim? > 2. If I provide access to four or five friends, I am not an ISP and in > fact I am responsible if they use my connection to do something illegal > since I am the customer of record. If you loan your car to an > unlicensed driver and he kills someone, you are on the hook. > The key word above is "unlicensed". And the other key word -- not present -- is "knowingly". But the analogy breaks down because you don't need a license to use the Internet. Consequently, in most cases you will not know, and cannot reasonably be expected to know, about legal violations. If you let your buddy use your home wireless while he's staying with you for the weekend, and he commits, say, a fraud, or blackmails someone, you are not legally responsible for any of it unless you participated knowingly in some way. Of course, that you didn't know may be hard and expensive and unpleasant to try to prove, but that's a different question. > 3. I guarantee you that if your blogging site, wiki or whatever is > publishing content like child porn, you are going to jail. There is no Child porn is an unusual strict liability crime. If you publish or possess it, even unknowingly, you face real risks. As a practical matter most prosecutors do not bring cases against innocent victims (e.g. someone on AOL who gets an evil popup unexpectedly). In theory maybe they could, but I suspect they don't really want the test case. > "ISP like protections" for that. If you do not take action as soon as > you know a crime is being committed, you are going to get nailed. > > The question in this case would be all about whether the Tor exit node > is viewed as a device specifically enabling a criminal or something that I do not think that would be the analysis under US law at all. The first question is mens rea. We do not charge the car rental company with something if its car is used to rob a bank -- unless they knew in advance that was the plan. Cars enable criminals too. > was incidentally used to commit a crime. For example, if I give you a > hammer and you break into someone's house with it, I am probably not > criminally negligent. If I provided you with lock picking equipment and > you are not a locksmith, I might be criminally negligent. This is not The term "criminally negligent" really has no role here. Negligence is in most cases a civil not a criminal offense. There are specific crimes. There is aiding and abetting. There may be criminal negligence in unrelated cases where you have a duty to secure something or protect (or not harm) someone and fail to do so (e.g. you leave your car in a position to roll downhill and it hurts someone, or you are willfully blind to a danger to child for whom you should be caring, or you act with such inattention so as to kill someone). But in the USA ***you have no legal duty to secure your wireless***. None. You can leave it open, just as you can leave your window open and let people enjoy what you are playing on your stereo (modulo public nuisance law, and copyright rules against some types of unlicensed public performance). Thus there can be no negligence in leaving it open, at least absent specific knowledge that a person intends to do a specific thing. > so clear cut a case that there would not be a fight about it. > > Steven Naslund [...] -- A. Michael Froomkin, http://www.law.tm Blog: http://www.discourse.net Laurie Silvers & Mitchell Rubenstein Distinguished Professor of Law Editor, Jotwell: The Journal of Things We Like (Lots), jotwell.com U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | froomkin at law.tm -->It's warm here.<-- From mfidelman at meetinghouse.net Thu Nov 29 23:23:13 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 29 Nov 2012 18:23:13 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com> <50B7BE61.9050403@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711928@MUNEXBE1.medline.com> Message-ID: <50B7EE61.6080608@meetinghouse.net> Michael Froomkin - U.Miami School of Law wrote: > >> 2. If I provide access to four or five friends, I am not an ISP and in >> fact I am responsible if they use my connection to do something illegal >> since I am the customer of record. If you loan your car to an >> unlicensed driver and he kills someone, you are on the hook. >> > > The key word above is "unlicensed". And the other key word -- not > present -- is "knowingly". But the analogy breaks down because you > don't need a license to use the Internet. Consequently, in most cases > you will not know, and cannot reasonably be expected to know, about > legal violations. If you let your buddy use your home wireless while > he's staying with you for the weekend, and he commits, say, a fraud, > or blackmails someone, you are not legally responsible for any of it > unless you participated knowingly in some way. Of course, that you > didn't know may be hard and expensive and unpleasant to try to prove, > but that's a different question. Ummm... you might be liable under your service agreement with your ISP. Most of these have all kinds of restrictive clauses re. not letting others use your connection, copyright infringement, assumption of liability, yada, yada, yada. We all violate these, all the time, but there are times when that might catch up with someone. > > The term "criminally negligent" really has no role here. Negligence is > in most cases a civil not a criminal offense. There are specific > crimes. There is aiding and abetting. There may be criminal > negligence in unrelated cases where you have a duty to secure > something or protect (or not harm) someone and fail to do so (e.g. you > leave your car in a position to roll downhill and it hurts someone, or > you are willfully blind to a danger to child for whom you should be > caring, or you act with such inattention so as to kill someone). But > in the USA ***you have no legal duty to secure your wireless***. > None. You can leave it open, just as you can leave your window open > and let people enjoy what you are playing on your stereo (modulo > public nuisance law, and copyright rules against some types of > unlicensed public performance). Thus there can be no negligence in > leaving it open, at least absent specific knowledge that a person > intends to do a specific thing. > You may have a civil liability to secure your wireless under the terms-of-service agreement with your Internet provider. Well, maybe not to "secure your wireless" but to prevent unauthorized use of your connection to the service provider - which could be accomplished in other ways. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tvhawaii at shaka.com Thu Nov 29 23:28:38 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 29 Nov 2012 13:28:38 -1000 Subject: William was raided for running a Tor exit node. Please help if you can. References: <50B7B519.8050608@localnet.com> <50B7BE61.9050403@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711928@MUNEXBE1.medline.com> Message-ID: <2FE73F3BAD5E4BD795EAF61618137B2D@owner59e1f1502> Naslund, Steve wrote: > 1. Running open access wireless does not make you legally an ISP and if > your open wireless is used to commit a crime you could be criminally > negligent if you did not take "reasonable care" in the eyes of the > court. Related: https://www.eff.org/deeplinks/2012/07/judge-copyright-troll-cant-bully-internet-subscriber-bogus-legal-theory http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2035633 From SNaslund at medline.com Thu Nov 29 23:39:21 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 29 Nov 2012 17:39:21 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com><2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com><2A76E400AC84B845AAC35AA19F8E7A5D0D7118FD@MUNEXBE1.medline.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D711A9C@MUNEXBE1.medline.com> You are correct about most people not falling under CALEA. That also means that they do not have the "safe harbor" provisions provided to facilities based providers (however an open wireless hotspot MIGHT just make you a wireless facilities based provider). You are not under an obligation to provide data under CALEA but a court can order you collect that data going forward, allow LE to tap a device, or just seize the server to study it anytime they feel you may have evidence of a crime. A court can seize almost anything from anyone as long as a judge thinks it is a reasonable search and seizure. If you provide someone with any kind of tools or services (free or not) you are opening yourself up to a liability. If you are in physical possession of a server that contains kiddie porn you are likely to go to jail. I am not saying this Tor server has data like that onboard (but I suppose there could be caches, temp files, and such) but they are going to look until they understand it. You may very well be able to defend your right to a Tor server but it is certainly going to cost you a lot of money and I am sure it is going to be uncomfortable to explain why you want to have one to a judge when LE explains all the evil uses for one. When it comes to running an open access point, I think the legal issue would be negligence. Is it negligence for the 90 year old grandma to have an open AP (probably not, just didn't know better)? Is it negligence for me to have an open AP (probably, I am a network professional and know how to secure a network). As a long time service provider I can tell you that a lot of CALEA enforcement has to do with good faith more than the letter of the law. If your policy is to delete logs after 30 days and the cops show up on day 31, no big deal. If they show up at day 5 and you say you dump your logs at day 4, expect to get grilled. They can tell real quick if you are cooperating to the best of your ability. In the early Internet days, before the CALEA applied to ISPs I had to try to work with LE to comply with court orders and often we explained the technology and limitations of it to the FBI. We were even involved in expert testimony to explain how this "Internet Stuff" worked. Often we did not have the data they wanted but there were ways to get it for an ongoing investigation. Our policy was to not provide specific data without a court order but we would begin collecting it as soon as a LE agent told us they were going to try to obtain it. It was just a professional courtesy to them. I know there is a big counter-culture, no big brother, no regulation attitude toward a lot of Internet issues but I have seen some sick cases involving emailed threats (later carried out) and kids that made me give the law the benefit of the doubt in a lot of cases. There are lots of evil people out there and the Internet is a big tool for them. I have no statistics to back this up (and no one probably does) but with my many years of experience in engineering ARPANET, MILNET, and the Internet I would have to guess that most Tor servers are used for no good much more than they are protecting anyone's privacy. I am guessing that a ton of the Tor traffic is likely to be BitTorrent that is just as likely copyrighted material. That does not mean that Tor or BitTorrent is evil but as network professionals we all know (wink, wink) what that kind of stuff is really mainly used for. That probably does not affect your legal rights to have a Tor server but certainly affects my decision to donate to your defense if you get in a legal case. This is certainly an interesting discussion and I think there are not a lot of concrete answers since this is on the edge of technology law. I do think history shows us that while the government lags behind, they will eventually find a way to control this if it suits them and becomes a source of pain for them. Done with this subject, sorry for the long windedness Steven Naslund -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Thursday, November 29, 2012 2:53 PM To: Naslund, Steve Cc: NANOG Subject: Re: William was raided for running a Tor exit node. Please help if you can. On Thu, Nov 29, 2012 at 12:42 PM, Naslund, Steve wrote: > The entire point of Tor is to be untraceable back to the source. > Egress filters can prevent future abuse but do not provide for tracing > back to the original source of offending conduct. They are not trying > to stop the flow of the data in this case, they want the source in > jail. If law enforcement comes to you and asks you to show them the > source or destination on a case like the one in question, you cannot > comply and if law enforcement asks you to trap this data in the future > you will also have a problem complying because I think you cannot > identify the original source. If you run an open wireless access point and don't log MACs / MAC to IP DHCP assignments, you are in similar straights. If they come to you 31 days after the data flow and you retain logs for 30, you are in similar straights. If someone faked their wireless MAC and the data in your log is not definitive, everyone's stymied. If someone went into a Library and used an open access computer, there's often no log of who / when. The assertion being made here, that it's somehow illegal (or immoral, or scary) for there to be not-completely-traceable internet access in the US, is absurd. CALEA doesn't say what you're asserting. From the First Report and Order: "24. In this section, we find that facilities-based providers of any type of broadband Internet access service, including but not limited to wireline, cable modem, satellite, wireless, fixed wireless, and broadband access via powerline are subject to CALEA" ( http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-05-153A1.pdf ) If you're not a facilities-based provider, you aren't covered. -- -george william herbert george.herbert at gmail.com From froomkin at law.miami.edu Fri Nov 30 00:29:09 2012 From: froomkin at law.miami.edu (Michael Froomkin - U.Miami School of Law) Date: Thu, 29 Nov 2012 19:29:09 -0500 (EST) Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B7EE61.6080608@meetinghouse.net> References: <50B7B519.8050608@localnet.com> <50B7BE61.9050403@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711928@MUNEXBE1.medline.com> <50B7EE61.6080608@meetinghouse.net> Message-ID: Comments deep below. On Thu, 29 Nov 2012, Miles Fidelman wrote: > Michael Froomkin - U.Miami School of Law wrote: >> >> > 2. If I provide access to four or five friends, I am not an ISP and in >> > fact I am responsible if they use my connection to do something illegal >> > since I am the customer of record. If you loan your car to an >> > unlicensed driver and he kills someone, you are on the hook. >> > >> >> The key word above is "unlicensed". And the other key word -- not present >> -- is "knowingly". But the analogy breaks down because you don't need a >> license to use the Internet. Consequently, in most cases you will not >> know, and cannot reasonably be expected to know, about legal violations. >> If you let your buddy use your home wireless while he's staying with you >> for the weekend, and he commits, say, a fraud, or blackmails someone, you >> are not legally responsible for any of it unless you participated >> knowingly in some way. Of course, that you didn't know may be hard and >> expensive and unpleasant to try to prove, but that's a different question. > > Ummm... you might be liable under your service agreement with your ISP. Most > of these have all kinds of restrictive clauses re. not letting others use > your connection, copyright infringement, assumption of liability, yada, yada, > yada. We all violate these, all the time, but there are times when that > might catch up with someone. OK, you might have *contract* liability to the ISP, but not to third parities in the main. Contract damages < tort damages < criminal penalties, the latter being what we were talking about). The only attempt I know of to make violation of those contract terms the predicate for criminal liability failed. Google "Lori Drew". >> >> The term "criminally negligent" really has no role here. Negligence is in >> most cases a civil not a criminal offense. There are specific crimes. >> There is aiding and abetting. There may be criminal negligence in >> unrelated cases where you have a duty to secure something or protect (or >> not harm) someone and fail to do so (e.g. you leave your car in a position >> to roll downhill and it hurts someone, or you are willfully blind to a >> danger to child for whom you should be caring, or you act with such >> inattention so as to kill someone). But in the USA ***you have no legal >> duty to secure your wireless***. None. You can leave it open, just as >> you can leave your window open and let people enjoy what you are playing >> on your stereo (modulo public nuisance law, and copyright rules against >> some types of unlicensed public performance). Thus there can be no >> negligence in leaving it open, at least absent specific knowledge that a >> person intends to do a specific thing. >> > > You may have a civil liability to secure your wireless under the > terms-of-service agreement with your Internet provider. Well, maybe not to > "secure your wireless" but to prevent unauthorized use of your connection to > the service provider - which could be accomplished in other ways. Normally that would just be a capacity or useage based billing issue in practice. But sure, contract terms vary widely. Note, though, the distinction between "having contracted to pay extra in some circumstances" (one type of 'civil liability') and risking being found in violation of the contract (another type, but usually one that results in termination of the service rather than an obligation to pay). > > Miles Fidelman -- A. Michael Froomkin, http://www.law.tm Blog: http://www.discourse.net Laurie Silvers & Mitchell Rubenstein Distinguished Professor of Law Editor, Jotwell: The Journal of Things We Like (Lots), jotwell.com U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | froomkin at law.tm -->It's warm here.<-- From froomkin at law.miami.edu Fri Nov 30 00:29:46 2012 From: froomkin at law.miami.edu (Michael Froomkin - U.Miami School of Law) Date: Thu, 29 Nov 2012 19:29:46 -0500 (EST) Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D711A9C@MUNEXBE1.medline.com> References: <50B7B519.8050608@localnet.com><2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com><2A76E400AC84B845AAC35AA19F8E7A5D0D7118FD@MUNEXBE1.medline.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711A9C@MUNEXBE1.medline.com> Message-ID: On Thu, 29 Nov 2012, Naslund, Steve wrote: [...] > > When it comes to running an open access point, I think the legal issue > would be negligence. Is it negligence for the 90 year old grandma to > have an open AP (probably not, just didn't know better)? Is it > negligence for me to have an open AP (probably, I am a network > professional and know how to secure a network). > In order for there to be a civil claim of negligence there must be, inter alia, a breach of duty. What duty has been breached in your scenario? None. [...] > > This is certainly an interesting discussion and I think there are not a > lot of concrete answers since this is on the edge of technology law. I Actually some of us have been teaching and writing about this stuff since the mid 1990s. These issues are far from new; we went through them in the early anonymous remailer days. -- A. Michael Froomkin, http://www.law.tm Blog: http://www.discourse.net Laurie Silvers & Mitchell Rubenstein Distinguished Professor of Law Editor, Jotwell: The Journal of Things We Like (Lots), jotwell.com U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | froomkin at law.tm -->It's warm here.<-- From eng.jstolli at yahoo.com Thu Nov 29 22:22:13 2012 From: eng.jstolli at yahoo.com (James Stoll) Date: Thu, 29 Nov 2012 14:22:13 -0800 (PST) Subject: Windows 2008/2012 arp timeout process Message-ID: <1354227733.59886.YahooMailNeo@web140005.mail.bf1.yahoo.com> Greetings Nanog, I apologize in advance if this should be directed towards a server/systems discussion list, but I've noticed some (what I think are) issues with the way windows 2008/2012 handles arp. I started noticing some high arp processes on some of our 6500s running sup720s, and after performing some captures of packets being punted to the cpu I found that there were quite a few repeat sources. After digging into the sources, it looks like windows 2008/2012 systems are sending arp refresh requests quite frequently. According to this article ( http://support.microsoft.com/kb/949589 ), if the neighbor entry is in use for the IP it should not go stale. Specifically: "If the entry is in the "Reachable" state, Windows Vista TCP/IP hosts do not send ARP requests to the network. Therefore, Windows Vista TCP/IP hosts use the information in the cache. If an entry is not used, and it stays in the "Reachable" state for longer than its "Reachable Time" value, the entry changes to the "Stale" state. If an entry is in the "Stale" state, the Windows Vista TCP/IP host must send an ARP request to reach that destination." I know that states Windows Vista, but the "applies to" section lists the other OSes. I've replicated this in my lab (server pinging its own gateway while capturing traffic), and I am seeing the same issue: 222???????? 10:05:18.462720??????????????? Dell_a6:dc:52???? All-HSRP-routers_0a?????? ARP??????? Who has 10.36.0.1?? Tell 10.36.0.31 223???????? 10:05:18.464759??????????????? All-HSRP-routers_0a?????? Dell_a6:dc:52???? ARP??????? 10.36.0.1 is at 00:00:0c:07:ac:0a 1886?????? 10:06:31.962218??????????????? Dell_a6:dc:52???? All-HSRP-routers_0a?????? ARP??????? Who has 10.36.0.1?? Tell 10.36.0.31 1887?????? 10:06:31.963004??????????????? All-HSRP-routers_0a?????? Dell_a6:dc:52???? ARP??????? 10.36.0.1 is at 00:00:0c:07:ac:0a 3348?????? 10:07:23.461682??????????????? Dell_a6:dc:52???? All-HSRP-routers_0a?????? ARP??????? Who has 10.36.0.1?? Tell 10.36.0.31 3349?????? 10:07:23.471003??????????????? All-HSRP-routers_0a?????? Dell_a6:dc:52???? ARP??????? 10.36.0.1 is at 00:00:0c:07:ac:0a I've tried this on various devices, and the only place I don't see this behavior is on wireless interfaces. I'm more of a linux guy, and performing the same tests there I see the behavior stated in this article (which is what I would expect) - http://linux-ip.net/html/ether-arp.html . Specifically: "Entries in the ARP cache are periodically and automatically verified unless continually used." Has anyone run into this issue before ? Have a fix ? Point me to any documentation or other distros that I should ask ? TIA, James From will at harg.net Fri Nov 30 01:39:33 2012 From: will at harg.net (Will Hargrave) Date: Fri, 30 Nov 2012 01:39:33 +0000 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D7118FD@MUNEXBE1.medline.com> Message-ID: <254DF54D-5A5C-4DB4-9C23-642A1F7DB27A@harg.net> On 29 Nov 2012, at 20:53, George Herbert wrote: > The assertion being made here, that it's somehow illegal (or immoral, > or scary) for there to be not-completely-traceable internet access in > the US, is absurd. The real issue here is *not* the legality of the act of providing a Tor exit node, or an open access point, or anything else. In sensible countries that is perfectly legal. The problem here is the reality of undergoing a criminal investigation. Think carefully about the impact of having everything in your life which runs an operating system taken away. Phones. Tablet. Laptop. Servers. All portable drives, data. If you rely on that hardware for your income (and who doesn't?) you're going to have to buy all of that again. And restore your data, if you are able. -- Will From kyle.creyts at gmail.com Fri Nov 30 01:40:25 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Thu, 29 Nov 2012 17:40:25 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121129220039.GA90089@reptiles.org> References: <20663.35479.561328.722417@world.std.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D71181A@MUNEXBE1.medline.com> <20121129220039.GA90089@reptiles.org> Message-ID: On Thu, Nov 29, 2012 at 2:00 PM, Jim Mercer wrote: > On Thu, Nov 29, 2012 at 01:19:19PM -0600, Naslund, Steve wrote: >> I think the best analogy I would use in defense is something like the >> pre-paid cellular phones that are sold. That is about the only >> anonymous communications service I can think of off the top of my head. >> Problem is that most people are not licensed carriers and may not be >> able to hide behind that protection. > > if your phone is stolen and used by a drug dealer, i'm pretty sure the cops > would not be after you for anything the dealer did. > > if you stand on the corner with a sign saying "free cell phone airtime, > just ask me", they might take a different view on things. > > now, whether you are guilty of anything or not, by standing there with a sign > you are certainly opening yourself to legal inquiry, delay and hassle. > > i wouldn't be surprised if the cops didn't accept your "i'm just letting > people use my phone, i've got nothing to do with their activities" defence, > at least not without poking about for a bit, which might include looking > at your cellphone, your home phone, your bank records, and anything else > they think (and a judge agrees) might need viewing to clear you. A few questions this thread raises for me: you are a very trusting person, and frequently let people borrow your things. A friend frequently borrows your phone, which he explains is because he: a) frequently lets his phone die, or has run close to using too many minutes. You frequently allow him (and other people) to borrow your phone. At some point, it becomes clear that his life has taken a turn for the worse, and he has become involved in activities of which you do not approve. You stop allowing him to use your phone. During a criminal investigation of your friend's activities, it later becomes clear that for some time he was using it for illegal activities. At what point did allowing him to use your phone become illegal, and how should a responsible citizen rationally realize or identify this point? How can one be reasonably sure that one knows another person well enough to allow them to use one's equipment/resources? When do you become responsible for the activity of someone else on your equipment? Clearly "always" is not correct; similarly, "never" is also not correct. b) (most analogous to the actual situation) has a [legitimate?] reason for wanting to avoid the entity he calls having, being able to predict, see, or otherwise link some information he wishes to give them with some information he does not wish to give them (for example, his phone number [1]) Upon this pretense, which seems fairly reasonable, you allow him access to your phone. In order to enable this pursuit (so that this phone number cannot be attached to a pattern of activity), you also allow others to use your phone for similar reasons. You consider such activity correlation/tracking and data mining to be a violation of privacy (explicitly with regard to data-mining and activity tracking performed in pursuit of selling this data for profit). Now arguably, in the second case, you are operating this "service" with an explicitly altruistic intent. IF you are not informed about the mechanics of this process, and you are unaware of the issues this creates for law enforcement entities in identifying criminals, what constitutes wrongdoing? If you are not aware of criminal uses of your service which is entirely free and only intended for avoiding data-miners, are you still accountable for the activities of those using it? Why? At what point do you accept or acquire this responsibility? How is this different from operating a party line shared by an apartment building or phone bridge with external calling ability? I am curious about the impact of the nuances of each of these situations. [1] he is paranoid, and doesn't like the pizza place associating his address with his phone number, or perhaps he is calling someone who collects marketing data and attempts to data-mine his activity, or some other more legitimate, applicable and realistic take on appropriate cases for desiring anonymity in such a transaction > > -- > Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 > "He who dies with the most toys is nonetheless dead" > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From owen at delong.com Fri Nov 30 03:22:48 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Nov 2012 19:22:48 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B7BE61.9050403@localnet.com> References: <50B7B519.8050608@localnet.com> <50B7BE61.9050403@localnet.com> Message-ID: <3003A32A-1A8B-4775-8886-2D23B9395B10@delong.com> Yes, but if you are operating a TOR node, it's not entirely clear to me that you are not actually an ISP (whether you realize that or not). You are, after all, providing a form of internet access to non-paying customers. Owen On Nov 29, 2012, at 11:58 , Tom Beecher wrote: > Not really comparable. > > Speaking from a US point of view, ISPs has strong legal protections isolating them from culpability for the actions of their customers. I know internationally things are different, but here in the US the ISP doesn't get dinged, except in certain cases where they are legally required to remove access to material and don't. > > End users have no such protections that I'm aware of that cover them similarly. > > On 11/29/2012 2:50 PM, George Herbert wrote: >> On Thu, Nov 29, 2012 at 11:18 AM, Tom Beecher wrote: >>> Assuming it's true, it was bound to happen. Running anything , TOR or >>> otherwise, that allows strangers to do whatever they want is just folly. >> Such as, say, an Internet Service Provider business? >> >> ... >> > From rs at seastrom.com Fri Nov 30 05:52:11 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 30 Nov 2012 00:52:11 -0500 Subject: carping about CARP Message-ID: <86pq2vbptg.fsf@seastrom.com> I can't seem to recall anyone griping about this here on our august little list but google finds that I'm by no means the first to have been burned by an unholy interaction between VRRP and CARP. Let's skip the protocol discussions (same protocol number and uses multicast) [*] and go straight to the behavioral observations. I turned on VRRP this evening on a pair of routers. All of a sudden a CARP instance between a pair of pfSense boxes in the rack (which I didn't even know was there) invited itself to the party and started flailing all over the place and causing oscillating packet loss for anything that was going off-segment. Note that the Ciscos didn't exhibit any untoward behavior, and there were "passwords" on the VRRP sessions too. Meanwhile, the pfSense box spazzed out and filled its dmesg logs with stuff like: arp: 192.0.2.1 moved from 00:00:0c:xx:xx:01 to 00:00:5e:xx:xx:01 on em1 arp: 192.0.2.1 moved from 00:00:5e:xx:xx:01 to 00:00:0c:xx:xx:01 on em1 (no other hosts on the segment were logging such activity) Looks like CARP is a bit loose about believing stuff coming in over the wire. Seems a bit out of character for OpenBSD, but maybe these days it's considered all good so long as such a malfunction only causes an outage, not a core dump. Anyway, word to the wise, CARP and VRRP is a bit of a dangerous mixture. -r [*] The OpenBSD side of the story can be read at http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol#No_official_Internet_protocol_number Seems that there is a lesson to be learned here: "o hai, we wrote this software but can not be bothered to follow your process or formally write up the protocol, plz to be giving us a protocol number" ain't gonna fly. From morrowc.lists at gmail.com Fri Nov 30 06:56:01 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 30 Nov 2012 01:56:01 -0500 Subject: carping about CARP In-Reply-To: <86pq2vbptg.fsf@seastrom.com> References: <86pq2vbptg.fsf@seastrom.com> Message-ID: On Fri, Nov 30, 2012 at 12:52 AM, Robert E. Seastrom wrote: > Note that the Ciscos didn't exhibit any untoward behavior, and there > were "passwords" on the VRRP sessions too. case of the same situation all[1] 'software md5 tcp' implementations have? sign but never verify... -chris [1]: solaris's md5 and I believe the linux one do this :( From joakim at aronius.se Fri Nov 30 07:18:04 2012 From: joakim at aronius.se (Joakim Aronius) Date: Fri, 30 Nov 2012 08:18:04 +0100 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> Message-ID: <20121130071804.GA28545@nike.aronius.se> * Patrick W. Gilmore (patrick at ianai.net) wrote: > On Nov 29, 2012, at 12:58 , Barry Shein wrote: > > It would seem like they'd have to confiscate the equipment at every > > Starbucks in their jurisdiction, which could be every one in the US > > for example. > > They didn't confiscate every Tor exit node in the US once they found something nefarious emanating from one. > Lets assume that some child pr0n dealer used this Tor exit node, is it not reasonable if the police wants to see if there are logs that make it possible to catch the sleazebag? Should LE ignore crime if it originates from a network which operates a Tor exit node? I am all for being anonymous on the net but I seriously believe that we still need to enforce the law when it comes to serious felonies like child pr0n, organized crime etc, we can't give them a free pass just by using Tor. I dont think it should be illegal to operate a Tor exit node but what just happened could be a consequence of doing it. Of course they might not know abot Tor and believes that it is Mr Williams that is the bad guy. /J From eugen at leitl.org Fri Nov 30 07:25:05 2012 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 30 Nov 2012 08:25:05 +0100 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. Message-ID: <20121130072505.GD9750@leitl.org> ----- Forwarded message from Asad Haider ----- From: Asad Haider Date: Thu, 29 Nov 2012 19:37:24 +0000 To: tor-talk at lists.torproject.org Subject: Re: [tor-talk] William was raided for running a Tor exit node. Please help if you can. Reply-To: tor-talk at lists.torproject.org William will be posting a statement soon which will explain everything that's happened and give a detailed account of events, along with evidence including pictures showing the aftermath of the raid in his apartment, as well as copies of the warrant and inventory of seized items. He runs a large ISP in Austria and is a well respected member of the community, a lot of us have already sent in donations. His blog is https://rdns.im/ and I'm guessing the statement will be posted on there, I'll send everyone a link once it's finished being written. On 29 November 2012 19:22, Eugen Leitl wrote: > ----- Forwarded message from Emily Ozols ----- > > From: Emily Ozols > Date: Fri, 30 Nov 2012 01:14:08 +1100 > To: nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. Please help if > you can. > > Hi, > > I gotta ask and I'm sure someone would if I didn't, but how do we know > this guy is legit? > He's jumped up on a forum saying, "Hey, police raided me, help. gib > mone plz" and failed to provide and reason as to how he's real and not > just making it up. > > Maybe if there's a way to know this guy is legit, I'll help out if > possible, but until then I'm just going to watch others with caution > and I suggest others do as well. > > On Fri, Nov 30, 2012 at 12:04 AM, Chris wrote: > > I'm not William and a friend pasted a link on IRC to me. I'm going to > > send him a few bucks because I know how it feels to get blindsided by > > the police on one random day and your world is turned upside down. > > > > Source: > http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exit-accepting-donations-for-legal-expenses > > > > From the URL: > > > > Yes, it happened to me now as well - Yesterday i got raided for > > someone sharing child pornography over one of my Tor exits. > > I'm good so far, not in jail, but all my computers and hardware have > > been confiscated. > > (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) > > > > If convicted i could face up to 6 years in jail, of course i do not > > want that and i also want to try to set a legal base for running Tor > > exit nodes in Austria or even the EU. > > > > Sadly we have nothing like the EFF here that could help me in this > > case by legal assistance, so i'm on my own and require a good lawyer. > > Thus i'm accepting donations for my legal expenses which i expect to > > be around 5000-10000 EUR. > > > > If you can i would appreciate if you could donate a bit (every amount > > helps, even the smallest) either by PayPal (any currency is ok): > > > https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZNBBD7EH4 > > > > Or by Bank Transfer (EUR only please): > > > > Holder: William Weber > > Bank: EasyBank AG (Vienna, Austria) > > Account: 20011351213 > > Bank sort number: 14200 > > IBAN: AT031420020011351213 > > BIC: EASYATW1 > > > > I will try to pay them back when i'm out of this (or even before) but > > i can obviously not guarantee this, please keep this in mind. > > This money will only be used for legal expenses related to this case. > > > > If you have any questions or want to donate by another way > > (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel free > > to send me a mail (william at william.si) or a PM, or contact me in LET > > IRC. > > > > Thanks! > > William > > > > > > > > > > -- > > --C > > > > "The dumber people think you are, the more surprised they're going to > > be when you kill them." - Sir William Clayton > > > > > > -- > ~Em > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > _______________________________________________ > tor-talk mailing list > tor-talk at lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > _______________________________________________ tor-talk mailing list tor-talk at lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From tvhawaii at shaka.com Fri Nov 30 07:44:38 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 29 Nov 2012 21:44:38 -1000 Subject: William was raided for running a Tor exit node. Please help if you can. References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> Message-ID: <82FAEA5693C74B239995BE9E3EB9A89C@owner59e1f1502> Joakim Aronius wrote: > Lets assume that some child pr0n dealer used this Tor exit node, is it not reasonable if the police wants to see if > there are > logs that make it possible to catch the sleazebag? Should LE ignore crime if it originates from a network which operates > a Tor > exit node? > > I am all for being anonymous on the net but I seriously believe that we still need to enforce the law when it comes to > serious > felonies like child pr0n, organized crime etc, we can't give them a free pass just by using Tor. I dont think it should > be > illegal to operate a Tor exit node but what just happened could be a consequence of doing it. > > Of course they might not know abot Tor and believes that it is Mr Williams that is the bad guy. > > /J Wouldn't Austrian LEA need possession/knowledge of this pr0n site in order to determine the exit node that was using it? From davidianwalker at gmail.com Fri Nov 30 08:59:50 2012 From: davidianwalker at gmail.com (David Walker) Date: Fri, 30 Nov 2012 19:29:50 +1030 Subject: carping about CARP In-Reply-To: <86pq2vbptg.fsf@seastrom.com> References: <86pq2vbptg.fsf@seastrom.com> Message-ID: On 30/11/2012, Robert E. Seastrom wrote: > [*] The OpenBSD side of the story can be read at > http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol#No_official_Internet_protocol_number > > Seems that there is a lesson to be learned here: > > "o hai, we wrote this software but can not be bothered to follow your > process or formally write up the protocol, plz to be giving us a > protocol number" ain't gonna fly. > > > This tells me pretty much everything I need to know about this: https://datatracker.ietf.org/ipr/19/ Theo's comments in context here: http://marc.info/?l=openbsd-misc&m=133832434412686&w=2 The article in question: http://queue.acm.org/detail.cfm?id=2090149 I recommend reading the comments. >From where I stand, the OpenBSD project has been consistent on insulating itself against future legal issues, no matter how remote, with the idea that your security should not be restrained by anyone other than you. I believe that idea has legs regardless of practical considerations and stands on it's own. Besides, I won't discount OpenBSD out of hand for forging ahead, withstanding practical issues, considering the runs they've got on the board and the many facepalm fails we see in the diametrically opposed corporate world. It might be a very good thing they've bothered to take the time on this. Best wishes. From randy at psg.com Fri Nov 30 09:02:41 2012 From: randy at psg.com (Randy Bush) Date: Fri, 30 Nov 2012 18:02:41 +0900 Subject: carping about CARP In-Reply-To: References: <86pq2vbptg.fsf@seastrom.com> Message-ID: > case of the same situation all[1] 'software md5 tcp' implementations > have? sign but never verify... and freebsd :( From pelzi at pelzi.net Fri Nov 30 09:13:14 2012 From: pelzi at pelzi.net (Jussi Peltola) Date: Fri, 30 Nov 2012 11:13:14 +0200 Subject: carping about CARP In-Reply-To: <86pq2vbptg.fsf@seastrom.com> References: <86pq2vbptg.fsf@seastrom.com> Message-ID: <20121130091314.GD23446@pokute.pelzi.net> The amount of detail in the original posting is rather disappointing, with absolutely no hope of anyone being able to reproduce the problem with the data given. Did the vhid and vrrp group overlap? Were there duplicate IP addresses? From eugen at leitl.org Fri Nov 30 09:37:09 2012 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 30 Nov 2012 10:37:09 +0100 Subject: [tor-relays] Bandwidth and server leads [was: Tor raid] Message-ID: <20121130093709.GV9750@leitl.org> ----- Forwarded message from grarpamp ----- From: grarpamp Date: Thu, 29 Nov 2012 17:36:33 -0500 To: tor-relays at lists.torproject.org Cc: elw at stderr.org Subject: [tor-relays] Bandwidth and server leads [was: Tor raid] Reply-To: tor-relays at lists.torproject.org > From: elijah wright > Date: Thu, 29 Nov 2012 13:38:51 -0600 > Cc: nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. > We had a guy (aka potential customer) inquire the other day about hosting a > Tor exit on our infrastructure the other day; he disappeared fairly > quickly when he figured out that we weren't just going to give him an > endless supply of unmetered 10G bandwidth. I was looking forward to > billing him. :-) Contemporary mailing list lols aside, I believe you'll find that most operators in this space are quite serious and professional. If you're a potential friend of Tor, anonymity networks and the general thought space around it... and your price [or that of someone you know, nanog or otherwise, who might be such a friend] was highly competitive, or even special... I'd be fairly confident that consultation with those on this list would lead to a sale of said (or related) billable services. Feel free to forward and/or put any interested parties in touch with this list or torproject.org. _______________________________________________ tor-relays mailing list tor-relays at lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From rs at seastrom.com Fri Nov 30 12:44:26 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 30 Nov 2012 07:44:26 -0500 Subject: carping about CARP In-Reply-To: (David Walker's message of "Fri, 30 Nov 2012 19:29:50 +1030") References: <86pq2vbptg.fsf@seastrom.com> Message-ID: <86ip8n6z11.fsf@seastrom.com> David Walker writes: > [ patent fight recap ] Thanks for posting those. I recall the discussions surrounding the HSRP patents well, but it's been a while and I have proportionally more gray hair (and less overall) now. My problem is not with Theo nor with the IETF. My problem is with a crappy and credulous implementation. When an outage is caused by redundancy software that comes from an organization that prides itself on well-written code, the irony meter goes off the scale. > From where I stand, the OpenBSD project has been consistent on > insulating itself against future legal issues, no matter how remote, > with the idea that your security should not be restrained by anyone > other than you. What is "security" though and what it its aim? To my way of thinking, what happened to me last night wherein a box misbehaved and caused indigestion on an entire broadcast domain was a non-trivial security and availability incident. On the scale of badness, it's somewhat worse than a "magic packet causes this box to reboot" flaw, but not as bad as a "box gets owned, sensitive data gets divulged" incident. In my world, at least, security and availability are intimately intertwined. Were they not, one could easily "win" the security "game" by the simple expedient of turning the host off. Mission accomplished! > I believe that idea has legs regardless of practical considerations > and stands on it's own. > > Besides, I won't discount OpenBSD out of hand for forging ahead, > withstanding practical issues, considering the runs they've got on the > board and the many facepalm fails we see in the diametrically opposed > corporate world. > > It might be a very good thing they've bothered to take the time on this. The problem here is "insufficient paranoia about packets that come flying in over the transom, based on naive contemporaneous belief that a particular protocol number was not in use". I mean, gosh, who would ever send packets on an unused protocol number? And who other than us would get frustrated with the process and decide to forge ahead on their own. Most of us here are familiar with Postel's oft-quoted RFC793 robustness principle ("be conservative in what you do, be liberal in what you accept from others"). Yet, when one is engaging in an off-label use of any protocol, identifier, etc. it is incumbent on the protocol designer to mark their traffic in a particular way so that it is easy to identify, both for themselves and for others. Sure, one could argue that this is merely abstracting away the semantics of the protocol number field (hopefully to a field with more data space) but the whole point is to not accidentally interoperate with something with which you are not prepared to interoperate. Stated another way, nothing is keeping me from using udp/139 for something else so long as my packets aren't misinterpreted by SMB servers out there as being SMB, and so long as I don't accidentally eat someone else's SMB and do something stupid. Would you eat food that someone left on your doorstep with no note and no hint as to who it came from? Obviously from your mom, right? I mean who else would leave food on your doorstep? How about Halloween candy with open wrappers? The comparisons in the messages you cited to a four year old may not be that far off. -r From nick at foobar.org Fri Nov 30 12:44:27 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 30 Nov 2012 12:44:27 +0000 Subject: carping about CARP In-Reply-To: <86pq2vbptg.fsf@seastrom.com> References: <86pq2vbptg.fsf@seastrom.com> Message-ID: <50B8AA2B.8000903@foobar.org> On 30/11/2012 05:52, Robert E. Seastrom wrote: > [*] The OpenBSD side of the story can be read at > http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol#No_official_Internet_protocol_number > > Seems that there is a lesson to be learned here: > > "o hai, we wrote this software but can not be bothered to follow your > process or formally write up the protocol, plz to be giving us a > protocol number" ain't gonna fly. Which is fair enough from the ietf's point of view. Having said that, 1. patent US5473599 is pretty general and I can't see why it wouldn't apply to any host running CARP for router NHRP - although it's not clear that it would apply to e.g. host service high availability addressing. IOW, it's not at all clear that this is a legally unencumbered protocol, despite the bleatings from the openbsd camp. 2. the original patent is due to expire in about 18 months (april 2014) and i can't immediately see any cip applications which might extend it. This will render the debate substantially redundant. Regarding the ruckus between the openbsd camp and the ietf, the ietf's position is here: http://www.ietf.org/mail-archive/web/vrrp/current/msg00350.html It looks like there wasn't any serious attempt on the part of the openbsd people to engage with the ietf. There were no drafts, barely any mailing list postings to either the vrrp (now concluded) or routing discussion WGs, and apparently only a single presentation at a single ietf meeting. Maybe I've missed something though - I haven't checked the openbsd mailing lists because apparently their archives aren't publicly accessible. It's not at all clear why the openbsd people expected that a "petition" to IANA would result in them being assigned an official protocol number for CARP. There are only 254 of these available so it's not unreasonable to decline to register them unless there is a strong written case to do so. There's a policy in place for this (rfc5237), and it's in place for a good reason. As for the openbsd position on the choice of protocol number: "Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112" My goodness, what a co-incidence that they happened to choose the same protocol number as VRRP. http://www.ietf.org/mail-archive/web/ietf/current/msg48988.html Good thing this wasn't ever going to cause people trouble. Nick From joakim at aronius.se Fri Nov 30 12:51:15 2012 From: joakim at aronius.se (Joakim Aronius) Date: Fri, 30 Nov 2012 13:51:15 +0100 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <254DF54D-5A5C-4DB4-9C23-642A1F7DB27A@harg.net> References: <50B7B519.8050608@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D7118FD@MUNEXBE1.medline.com> <254DF54D-5A5C-4DB4-9C23-642A1F7DB27A@harg.net> Message-ID: <20121130125115.GA30947@nike.aronius.se> * Will Hargrave (will at harg.net) wrote: > > On 29 Nov 2012, at 20:53, George Herbert wrote: > > > The assertion being made here, that it's somehow illegal (or immoral, > > or scary) for there to be not-completely-traceable internet access in > > the US, is absurd. > > The real issue here is *not* the legality of the act of providing a Tor exit node, or an open access point, or anything else. In sensible countries that is perfectly legal. The problem here is the reality of undergoing a criminal investigation. It could also be the case that they think the person running the Tor exit node is the actual perpetrator, i.e. its needed to seize all HW to get the kiddie pr0n. Is it even possible for a network sniffer to distinguish between Tor exit traffic and his own traffic? Hopefully he will get it all back but it will most liklely cost both time and money to explain Tor to the Austrian judical system. > > Think carefully about the impact of having everything in your life which runs an operating system taken away. Phones. Tablet. Laptop. Servers. All portable drives, data. If you rely on that hardware for your income (and who doesn't?) you're going to have to buy all of that again. And restore your data, if you are able. Fully agree. /J From rsk at gsp.org Fri Nov 30 12:58:53 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 30 Nov 2012 07:58:53 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: <20121130125853.GB7333@gsp.org> On Thu, Nov 29, 2012 at 08:04:02AM -0500, Chris quoted (William): > Yes, it happened to me now as well - Yesterday i got raided for > someone sharing child pornography over one of my Tor exits. Question: what evidence has been published -- that is, placed somewhere that we can all see it -- that substantiates the claim that child porn traversed the node in question? Followup question 1: if no such evidence has been produced, then why should we believe that it exists? Extraordinary claims require extraordinary proof. Followup question 2: if the goal is to identify and apprehend the perpetrators of child porn (and that's a good goal) then why would the police raid this operation? Would it not make far more sense to take advantage of the operator's knowledge and experience and quietly ask for his/her cooperation *while leaving the node running*? Followup question 3: what evidence in front of us allows us to clearly discern that this is what it purports to be and not simply an attempt to shut down a Tor node (and intimidate the operators of others) by using a plausible excuse based on a universal hot-button issue? ---rsk From jeroen at unfix.org Fri Nov 30 13:04:07 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 30 Nov 2012 14:04:07 +0100 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121130125115.GA30947@nike.aronius.se> References: <50B7B519.8050608@localnet.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D7118FD@MUNEXBE1.medline.com> <254DF54D-5A5C-4DB4-9C23-642A1F7DB27A@harg.net> <20121130125115.GA30947@nike.aronius.se> Message-ID: <50B8AEC7.1090401@unfix.org> On 2012-11-30 13:51 , Joakim Aronius wrote: > * Will Hargrave (will at harg.net) wrote: >> >> On 29 Nov 2012, at 20:53, George Herbert >> wrote: >> >>> The assertion being made here, that it's somehow illegal (or >>> immoral, or scary) for there to be not-completely-traceable >>> internet access in the US, is absurd. >> >> The real issue here is *not* the legality of the act of providing a >> Tor exit node, or an open access point, or anything else. In >> sensible countries that is perfectly legal. The problem here is the >> reality of undergoing a criminal investigation. > > It could also be the case that they think the person running the Tor > exit node is the actual perpetrator, i.e. its needed to seize all HW > to get the kiddie pr0n. Is it even possible for a network sniffer to > distinguish between Tor exit traffic and his own traffic? Not easily, this as TCP connections originate from the box itself. > Hopefully he will get it all back but it will most liklely cost both > time and money to explain Tor to the Austrian judical system. According to http://raided4tor.cryto.net/ he at least got a full list of what was confiscated including the various weapons in his possession, that in combo with the owning of a safe deposit box (which was not searched) with amongst others cash is an interesting part in personal security IMHO though ;) >> Think carefully about the impact of having everything in your life >> which runs an operating system taken away. Phones. Tablet. Laptop. >> Servers. All portable drives, data. If you rely on that hardware >> for your income (and who doesn't?) you're going to have to buy all >> of that again. And restore your data, if you are able. Actually they did not take anything away that was really related to the what was detected. The IP that the connection to the (apparently monitored or owned by the $investigators) CP website came from was a rented server in Poland. He apparently was notified that that exit node was being used for abuse and thus 'closed it because of the hacking through it' (which really is not helping when you still run others and looks a lot like you have something to hide to me...) All the other servers he apparently runs in the US and Hong Kong etc are still up and running too. Thus the computer things confiscated where effectively unrelated to the IP that triggered them to look at it. On 2012-11-30 13:58 , Rich Kulawiec wrote:> On Thu, Nov 29, 2012 at 08:04:02AM -0500, Chris quoted (William): >> Yes, it happened to me now as well - Yesterday i got raided for >> someone sharing child pornography over one of my Tor exits. > > Question: what evidence has been published -- that is, placed somewhere > that we can all see it -- that substantiates the claim that child porn > traversed the node in question? The moment you can see that it is real CP you have seen CP. Do not ask for that. There are special people who have legally signed documents and agreements that investigate this. > Followup question 1: if no such evidence has been produced, then > why should we believe that it exists? Extraordinary claims require > extraordinary proof. What likely is the case, from what I understand, is that the server hosting the CP was being either monitored or operated by $investigators. > Followup question 2: if the goal is to identify and apprehend the > perpetrators of child porn (and that's a good goal) then why would > the police raid this operation? Because they maybe think he originated it, see also the note above of closing the Tor exit that (allegedly) sourced the request(s). > Would it not make far more sense to > take advantage of the operator's knowledge and experience and quietly > ask for his/her cooperation *while leaving the node running*? He already closed the node, apparently due to hacking happening through it. But that would not help anyway, as it is Tor, thus unless you are really really good there is nothing to see there as you'll never find out who originated the connection through Tor. > Followup question 3: what evidence in front of us allows us to clearly > discern that this is what it purports to be and not simply an attempt > to shut down a Tor node (and intimidate the operators of others) > by using a plausible excuse based on a universal hot-button issue? The owner (the William person this is about) shut it down himself. See the blog mentioned above for more details from his side. Greets, Jeroen From hb-nanog at bsws.de Fri Nov 30 13:08:27 2012 From: hb-nanog at bsws.de (Henning Brauer) Date: Fri, 30 Nov 2012 14:08:27 +0100 Subject: carping about CARP In-Reply-To: <86ip8n6z11.fsf@seastrom.com> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> Message-ID: <20121130130827.GB16865@quigon.bsws.de> * Robert E. Seastrom [2012-11-30 13:46]: > My problem is not with Theo nor with the IETF. My problem is with a > crappy and credulous implementation. When an outage is caused by > redundancy software that comes from an organization that prides itself > on well-written code, the irony meter goes off the scale. vrrp and carp share the vhid space. you have to use unique vhids per network segment, that's about it. the openbsd box was nice enough to tell you about the mac address conflict, the other's didn't. if you looked at the carp boxes you had seen that carp had continued to work just fine. the mac address (which is basically "fixed prefix + vhid) conflict is your "outage". there's nothing we could do about that. and re IANA, they made it clear they would not give us a proto number no matter what; we didn't have a choice but to ignore that industry-money-driven committee. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From stu at spacehopper.org Fri Nov 30 13:37:46 2012 From: stu at spacehopper.org (Stuart Henderson) Date: Fri, 30 Nov 2012 13:37:46 +0000 (UTC) Subject: carping about CARP References: <86pq2vbptg.fsf@seastrom.com> Message-ID: On 2012-11-30, Robert E. Seastrom wrote: > > I can't seem to recall anyone griping about this here on our august > little list but google finds that I'm by no means the first to have > been burned by an unholy interaction between VRRP and CARP. > > Let's skip the protocol discussions (same protocol number and uses > multicast) [*] and go straight to the behavioral observations. > > I turned on VRRP this evening on a pair of routers. All of a sudden a > CARP instance between a pair of pfSense boxes in the rack (which I > didn't even know was there) invited itself to the party and started > flailing all over the place and causing oscillating packet loss for > anything that was going off-segment. > > Note that the Ciscos didn't exhibit any untoward behavior, and there > were "passwords" on the VRRP sessions too. Meanwhile, the pfSense box > spazzed out and filled its dmesg logs with stuff like: > > arp: 192.0.2.1 moved from 00:00:0c:xx:xx:01 to 00:00:5e:xx:xx:01 on em1 > arp: 192.0.2.1 moved from 00:00:5e:xx:xx:01 to 00:00:0c:xx:xx:01 on em1 > > (no other hosts on the segment were logging such activity) All this shows is that the IP address is flip-flopping between a Cisco MAC address and a CARP/VRRP unicast MAC address. I would double check the vrrp config and make sure that the vrrp IP address is *only* configured on vrrp, not ethernet interfaces. > Looks like CARP is a bit loose about believing stuff coming in over > the wire. Seems a bit out of character for OpenBSD, but maybe these > days it's considered all good so long as such a malfunction only > causes an outage, not a core dump. I don't see anything here indicating that it's to do with CARP believing things sent over the wire, I suspect the problem would still occur if CARP were disabled on the pfSense box. (Do people really run CARP in the wild without authentication anyway?) From stu at spacehopper.org Fri Nov 30 13:38:20 2012 From: stu at spacehopper.org (Stuart Henderson) Date: Fri, 30 Nov 2012 13:38:20 +0000 (UTC) Subject: carping about CARP References: <86pq2vbptg.fsf@seastrom.com> Message-ID: On 2012-11-30, Randy Bush wrote: >> case of the same situation all[1] 'software md5 tcp' implementations >> have? sign but never verify... > > and freebsd :( > > openbsd verifies these, btw. From rs at seastrom.com Fri Nov 30 14:35:10 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 30 Nov 2012 09:35:10 -0500 Subject: carping about CARP In-Reply-To: <20121130130827.GB16865@quigon.bsws.de> (Henning Brauer's message of "Fri, 30 Nov 2012 14:08:27 +0100") References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> <20121130130827.GB16865@quigon.bsws.de> Message-ID: <86ip8ngnvl.fsf@seastrom.com> Henning Brauer writes: > * Robert E. Seastrom [2012-11-30 13:46]: >> My problem is not with Theo nor with the IETF. My problem is with a >> crappy and credulous implementation. When an outage is caused by >> redundancy software that comes from an organization that prides itself >> on well-written code, the irony meter goes off the scale. > > vrrp and carp share the vhid space. you have to use unique vhids per > network segment, that's about it. > > the openbsd box was nice enough to tell you about the mac address > conflict, the other's didn't. pfSense is FreeBSD, but who's counting? The problem is magnified when ill-behaved software ends up in appliances. Good thing we were able to get a shell on the box. > if you looked at the carp boxes you had seen that carp had continued > to work just fine. the mac address (which is basically "fixed prefix + > vhid) conflict is your "outage". there's nothing we could do about > that. > > and re IANA, they made it clear they would not give us a proto number > no matter what; we didn't have a choice but to ignore that > industry-money-driven committee. Between choosing an Ethernet OUI which was assigned to IANA by IEEE (another "industry-money-driven committee") and choosing protocol 112 (odds of coincidence 1 in what, 120 or so at the time?), "ignore" is not the word I would have chosen here. -r From marcelplug at gmail.com Fri Nov 30 14:35:55 2012 From: marcelplug at gmail.com (Marcel Plug) Date: Fri, 30 Nov 2012 09:35:55 -0500 Subject: Windows 2008/2012 arp timeout process In-Reply-To: <1354227733.59886.YahooMailNeo@web140005.mail.bf1.yahoo.com> References: <1354227733.59886.YahooMailNeo@web140005.mail.bf1.yahoo.com> Message-ID: Hi James, Is your windows client seeing traffic from the 6500 with the real (Burned in) MAC address of your 6500? If so it may be re-arping to find out which of the MAC addresses is the 'right' one to use, the real MAC or the HSRP MAC. My memory is fuzzy, but I think I've seen issues like that before. Sorry its been a while so I can't remember anything more specific. -Marcel On Thu, Nov 29, 2012 at 5:22 PM, James Stoll wrote: > Greetings Nanog, > > I apologize in advance if this should be directed towards a server/systems > discussion list, but I've noticed some (what I think are) issues with the > way windows 2008/2012 handles arp. I started noticing some high arp > processes on some of our 6500s running sup720s, and after performing some > captures of packets being punted to the cpu I found that there were quite a > few repeat sources. After digging into the sources, it looks like windows > 2008/2012 systems are sending arp refresh requests quite frequently. > > According to this article ( http://support.microsoft.com/kb/949589 ), if > the neighbor entry is in use for the IP it should not go stale. > Specifically: > > "If the entry is in the "Reachable" state, Windows Vista TCP/IP hosts do > not send ARP requests to the network. Therefore, Windows Vista TCP/IP hosts > use the information in the cache. If an entry is not used, and it stays in > the "Reachable" state for longer than its "Reachable Time" value, the entry > changes to the "Stale" state. If an entry is in the "Stale" state, the > Windows Vista TCP/IP host must send an ARP request to reach that > destination." > > I know that states Windows Vista, but the "applies to" section lists the > other OSes. > > I've replicated this in my lab (server pinging its own gateway while > capturing traffic), and I am seeing the same issue: > > 222 10:05:18.462720 Dell_a6:dc:52 > All-HSRP-routers_0a ARP Who has 10.36.0.1? Tell 10.36.0.31 > 223 10:05:18.464759 All-HSRP-routers_0a > Dell_a6:dc:52 ARP 10.36.0.1 is at 00:00:0c:07:ac:0a > 1886 10:06:31.962218 Dell_a6:dc:52 > All-HSRP-routers_0a ARP Who has 10.36.0.1? Tell 10.36.0.31 > 1887 10:06:31.963004 All-HSRP-routers_0a > Dell_a6:dc:52 ARP 10.36.0.1 is at 00:00:0c:07:ac:0a > 3348 10:07:23.461682 Dell_a6:dc:52 > All-HSRP-routers_0a ARP Who has 10.36.0.1? Tell 10.36.0.31 > 3349 10:07:23.471003 All-HSRP-routers_0a > Dell_a6:dc:52 ARP 10.36.0.1 is at 00:00:0c:07:ac:0a > > I've tried this on various devices, and the only place I don't see this > behavior is on wireless interfaces. > > I'm more of a linux guy, and performing the same tests there I see the > behavior stated in this article (which is what I would expect) - > http://linux-ip.net/html/ether-arp.html . Specifically: > > "Entries in the ARP cache are periodically and automatically verified > unless continually used." > > Has anyone run into this issue before ? Have a fix ? Point me to any > documentation or other distros that I should ask ? > > TIA, > James > From rs at seastrom.com Fri Nov 30 14:45:23 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 30 Nov 2012 09:45:23 -0500 Subject: carping about CARP In-Reply-To: <20121130091314.GD23446@pokute.pelzi.net> (Jussi Peltola's message of "Fri, 30 Nov 2012 11:13:14 +0200") References: <86pq2vbptg.fsf@seastrom.com> <20121130091314.GD23446@pokute.pelzi.net> Message-ID: <86ehjbgnek.fsf@seastrom.com> Jussi Peltola writes: > The amount of detail in the original posting is rather disappointing, > with absolutely no hope of anyone being able to reproduce the problem > with the data given. It was not intended as a bug report, instead merely an expression of disappointment and an advsory to fellow travelers to watch their backs. Sometimes a report of muggings in a locale is useful, even without a detailed description of the attacker. > Did the vhid and vrrp group overlap? Were there duplicate IP addresses? Yes, "vrrp 1" turned out to be a bad plan here. Turned off vrrp on the router and went with HSRP. There is enough documentation on HSRP vs VRRP around (heck, even Wikipedia) to surmise that something that interacted poorly with VRRP would likely not do the same to HSRP. Docs on CARP are thin on the ground. Never even an I-D. Didn't have time to read the source code when the network was acting up. -r From rps at maine.edu Fri Nov 30 14:45:25 2012 From: rps at maine.edu (Ray Soucy) Date: Fri, 30 Nov 2012 09:45:25 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> Message-ID: I'll see your disagree and raise you another ;-) I would say you almost never want to store addresses as character data unless the only thing you're using them for is logging (even then it's questionable). I run into people who do this all the time and it's a nightmare. It's easy to store a v6 address as a string, but when you want to select a range of IPv6 addresses from a database, not having them represented as integers means you can't do efficient numerical comparisons in your SQL statements, it also makes indexing your table slower; to put it simply, it doesn't scale well. So as a general rule, if you need to do any comparison or calculation on a v6 address, please don't store it as a string. >From an efficiency standpoint, you want to store it in chunks of the largest integer your DBMS supports. If a DBMS supports 128-bit integers and has optimized operations for them, then go for it. Most only support 64-, or even 32-bit. I say 64-bit because that's what the majority of current systems actually support and I don't see anyone coming out with a 128-bit architecture ;( For convenience I would very much love to see MySQL include inet6_aton and inet6_ntoa, along with a 128-bit data structure that would be implemented as either a pair of 64-bit or 4x 32-bit values depending on the architecture. But from a performance standpoint, I really don't want my DBMS doing that calculation; I want the application server doing it (because it's much easier to scale and distribute the application side than the storage side). Note that I'm talking about more from a database storage perspective than an internal application perspective. By all means, you should use the standard data structure for v6. As mentioned below a lot of the internal structures use 8-bit unsigned integers (or char); but that's mainly a hold-over from when we had the reality of 8-bit and 16-bit platforms (for compatibility). With unions, these structs are treated as a collection of 8, 16, 32, 64 or a single 128-bit variable which makes it something the developer doesn't need to worry about once the libraries are written. On Thu, Nov 29, 2012 at 9:55 AM, William Herrin wrote: > On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy wrote: > > You should store IPv6 as a pair of 64-bit integers. While PHP lacks > > the function set to do this on its own, it's not very difficult to do. > > Hi Ray, > > I have to disagree. In your SQL database you should store addresses as > a fixed length character string containing a zero-padded hexadecimal > representation of the IPv4 or IPv6 address with A through F forced to > the consistent case of your choice. Expand :: and optionally strip the > colons entirely. If you want to store a block of addresses, store it > as two character strings: start and end of the range. > > Bytes are cheap and query simplicity is important. Multi-element > indexes are messy and the code to manage an array of integers is > messier than managing a character string in most programming > languages. memcmp() that integer array for less or greater than? Not > on a little endian machine! > > > > Here are a set of functions I wrote a while back to do just that > > (though I admit I should spend some time to try and make it more > > elegant and I'm not sure it's completely up to date compared to my > > local copy ... I would love some eyes on it to make some > > improvements). > > > > http://soucy.org/project/inet6/ > > If we're plugging our code, give my public domain libeasyv6 a try. It > eases entry into dual stack programming for anyone used to doing > gethostbyname followed by a blocking connect(). Just do a > connectbyname() with the hostname or textual IP address, the port, a > timeout and null options. The library takes care of finding a working > IPv4 or IPv6 address for the host and connecting to it in a timely > manner. > > http://bill.herrin.us/freebies/ > > Currently Linux only but if you're willing to lose timeout control on > the DNS lookup you can replace getaddrinfo_a() with standard > getaddrinfo() and the code should run anywhere. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From rs at seastrom.com Fri Nov 30 14:47:28 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 30 Nov 2012 09:47:28 -0500 Subject: carping about CARP In-Reply-To: (Stuart Henderson's message of "Fri, 30 Nov 2012 13:37:46 +0000 (UTC)") References: <86pq2vbptg.fsf@seastrom.com> Message-ID: <86a9tzgnb3.fsf@seastrom.com> Stuart Henderson writes: > I don't see anything here indicating that it's to do with CARP > believing things sent over the wire, I suspect the problem would still > occur if CARP were disabled on the pfSense box. (Do people really > run CARP in the wild without authentication anyway?) 1) it did not. 2) standard, out of the box pfSense distribution. Haven't run that codebase lately myself, and not sufficiently interested this morning to dig through the code. Just watch your back, that's all. :) -r From davidianwalker at gmail.com Fri Nov 30 15:35:14 2012 From: davidianwalker at gmail.com (David Walker) Date: Sat, 1 Dec 2012 02:05:14 +1030 Subject: carping about CARP In-Reply-To: <86ip8n6z11.fsf@seastrom.com> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> Message-ID: Comments inline ... as best I can. On 30/11/2012, Robert E. Seastrom wrote: > > David Walker writes: > >> [ patent fight recap ] > > Thanks for posting those. I recall the discussions surrounding the > HSRP patents well, but it's been a while and I have proportionally > more gray hair (and less overall) now. > > My problem is not with Theo nor with the IETF. My problem is with a > crappy and credulous implementation. When an outage is caused by > redundancy software that comes from an organization that prides itself > on well-written code, the irony meter goes off the scale. You should hammer on OpenBSD. However, as yet this is an unknown. http://openbsd.org/report.html As far irony goes, there is some here but I'm not sure what you've got is countable yet. > >> From where I stand, the OpenBSD project has been consistent on >> insulating itself against future legal issues, no matter how remote, >> with the idea that your security should not be restrained by anyone >> other than you. > > What is "security" though and what it its aim? To my way of thinking, > what happened to me last night wherein a box misbehaved and caused > indigestion on an entire broadcast domain was a non-trivial security > and availability incident. Of course. > > On the scale of badness, it's somewhat worse than a "magic packet > causes this box to reboot" flaw, but not as bad as a "box gets owned, > sensitive data gets divulged" incident. In my world, at least, > security and availability are intimately intertwined. Were they not, > one could easily "win" the security "game" by the simple expedient of > turning the host off. Mission accomplished! The phrase you're looking for is denial of service, a known security phenomena. > >> I believe that idea has legs regardless of practical considerations >> and stands on it's own. >> >> Besides, I won't discount OpenBSD out of hand for forging ahead, >> withstanding practical issues, considering the runs they've got on the >> board and the many facepalm fails we see in the diametrically opposed >> corporate world. >> >> It might be a very good thing they've bothered to take the time on this. > > The problem here is "insufficient paranoia about packets that come > flying in over the transom, based on naive contemporaneous belief that > a particular protocol number was not in use". I mean, gosh, who would > ever send packets on an unused protocol number? And who other than us > would get frustrated with the process and decide to forge ahead on > their own. As far as not using the same protocol number, that's neither here nor there. Something I've noticed looking at information security is the taxonomy of Confidentiality, Integrity, Availability - which addresses your previous points. Something else I've noticed is the notion of security through obscurity and how it cedes the initative to the attacker. Experience tells me this is not lost on the OpenBSD folks. Translation, it's commonly understood that secure protocols shouldn't rely on trusting others to obey the rules ... and whether or not it's OpenBSD or Johnny Black Hat that's on 122 or whatever, if that causes issues then it's either down to the protocol or the administrator. I have no doubt OpenBSD understood all this. If I take Theo's word for it, he employed a mechanism available in the rfc (i.e. VRRP) to allow traffic to be differentiated. Regardless, if a competing implementation can cause a DoS or any other issue that's either a design failure that should be addressed in a subsequent rfc or if it's a design limitation, then it's a failure to concommittantly secure the network. Blaming OpenBSD for protocol number won't fly. If I'm to take Stuart's cue then somebody hasn't read the documentation. Simple. > > Most of us here are familiar with Postel's oft-quoted RFC793 > robustness principle ("be conservative in what you do, be liberal in > what you accept from others"). Yet, when one is engaging in an > off-label use of any protocol, identifier, etc. it is incumbent on the > protocol designer to mark their traffic in a particular way so that it > is easy to identify, both for themselves and for others. Sure, one > could argue that this is merely abstracting away the semantics of the > protocol number field (hopefully to a field with more data space) but > the whole point is to not accidentally interoperate with something > with which you are not prepared to interoperate. At a casual reading, looking at the security considerations of for example ... http://tools.ietf.org/rfc/rfc3768.txt ... suggests to me that there are exploitable vectors inherent to this protocol. I'll say it again, I'm no subject matter expert. I'd be happy for you point me in the right direction, otherwise you're going to have to wait for me to get up to speed. Otherwise see previous, if there are no mechanisms to secure VRRP or CARP then either the network or the machine needs to be secure or the protocol shouldn't be in service or relied upon. > > Stated another way, nothing is keeping me from using udp/139 for > something else so long as my packets aren't misinterpreted by SMB > servers out there as being SMB, and so long as I don't accidentally > eat someone else's SMB and do something stupid. No matter what protocol we look at, ultimately that comes down to protocol design. After that is network design. If a protocol is open to attack by unauthenticated users then it's up to me to secure the network against unauthenticated users. Expecting only legitimate traffic no matter what the door or window we're looking at is not the right way to do it. The bad guys certainly don't care either way whether you want malformed packets or not or complimentary looking implementations or not. > > Would you eat food that someone left on your doorstep with no note and > no hint as to who it came from? Obviously from your mom, right? I > mean who else would leave food on your doorstep? How about Halloween > candy with open wrappers? The comparisons in the messages you cited > to a four year old may not be that far off. > > -r > > From sclark at netwolves.com Fri Nov 30 15:38:58 2012 From: sclark at netwolves.com (Steve Clark) Date: Fri, 30 Nov 2012 10:38:58 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> Message-ID: <1354289940815-019-01077594.sclark.netwolves.com@sclark66.netwolves.com> On 11/30/2012 09:45 AM, Ray Soucy wrote: > I'll see your disagree and raise you another ;-) > > I would say you almost never want to store addresses as character data > unless the only thing you're using them for is logging (even then it's > questionable). I run into people who do this all the time and it's a > nightmare. > > It's easy to store a v6 address as a string, but when you want to select a > range of IPv6 addresses from a database, not having them represented as > integers means you can't do efficient numerical comparisons in your SQL > statements, it also makes indexing your table slower; to put it simply, it > doesn't scale well. > > So as a general rule, if you need to do any comparison or calculation on a > v6 address, please don't store it as a string. > > >From an efficiency standpoint, you want to store it in chunks of the > largest integer your DBMS supports. If a DBMS supports 128-bit integers > and has optimized operations for them, then go for it. Most only support > 64-, or even 32-bit. I say 64-bit because that's what the majority of > current systems actually support and I don't see anyone coming out with a > 128-bit architecture ;( > > For convenience I would very much love to see MySQL include inet6_aton and > inet6_ntoa, along with a 128-bit data structure that would > be implemented as either a pair of 64-bit or 4x 32-bit values depending on > the architecture. But from a performance standpoint, I really don't want > my DBMS doing that calculation; I want the application server doing it > (because it's much easier to scale and distribute the application side than > the storage side). Postgresql has an inet data type that handles both ipv4 and ipv6 addresses with a slew of functions to manipulate the data type. http://www.postgresql.org/docs/8.4/static/functions-net.html > Note that I'm talking about more from a database storage perspective than > an internal application perspective. > > By all means, you should use the standard data structure for v6. As > mentioned below a lot of the internal structures use 8-bit unsigned > integers (or char); but that's mainly a hold-over from when we had the > reality of 8-bit and 16-bit platforms (for compatibility). With unions, > these structs are treated as a collection of 8, 16, 32, 64 or a single > 128-bit variable which makes it something the developer doesn't need to > worry about once the libraries are written. > > > > > On Thu, Nov 29, 2012 at 9:55 AM, William Herrin wrote: > >> On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy wrote: >>> You should store IPv6 as a pair of 64-bit integers. While PHP lacks >>> the function set to do this on its own, it's not very difficult to do. >> Hi Ray, >> >> I have to disagree. In your SQL database you should store addresses as >> a fixed length character string containing a zero-padded hexadecimal >> representation of the IPv4 or IPv6 address with A through F forced to >> the consistent case of your choice. Expand :: and optionally strip the >> colons entirely. If you want to store a block of addresses, store it >> as two character strings: start and end of the range. >> >> Bytes are cheap and query simplicity is important. Multi-element >> indexes are messy and the code to manage an array of integers is >> messier than managing a character string in most programming >> languages. memcmp() that integer array for less or greater than? Not >> on a little endian machine! >> >> >>> Here are a set of functions I wrote a while back to do just that >>> (though I admit I should spend some time to try and make it more >>> elegant and I'm not sure it's completely up to date compared to my >>> local copy ... I would love some eyes on it to make some >>> improvements). >>> >>> http://soucy.org/project/inet6/ >> If we're plugging our code, give my public domain libeasyv6 a try. It >> eases entry into dual stack programming for anyone used to doing >> gethostbyname followed by a blocking connect(). Just do a >> connectbyname() with the hostname or textual IP address, the port, a >> timeout and null options. The library takes care of finding a working >> IPv4 or IPv6 address for the host and connecting to it in a timely >> manner. >> >> http://bill.herrin.us/freebies/ >> >> Currently Linux only but if you're willing to lose timeout control on >> the DNS lookup you can replace getaddrinfo_a() with standard >> getaddrinfo() and the code should run anywhere. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> > > -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From bgw990 at gmail.com Fri Nov 30 11:27:10 2012 From: bgw990 at gmail.com (b.g. white) Date: Fri, 30 Nov 2012 05:27:10 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. Message-ID: >I think if they took the cash registers too the >Starbucks lawyer would be in court an hour later >with a motion to quash in one hand and an offer of >full cooperation in the other. >Regards, Bill Herrin The standard, in the U.S., is "any electronic device capable of storing data". From eng.jstolli at yahoo.com Fri Nov 30 16:05:32 2012 From: eng.jstolli at yahoo.com (James Stoll) Date: Fri, 30 Nov 2012 08:05:32 -0800 (PST) Subject: Windows 2008/2012 arp timeout process In-Reply-To: References: <1354227733.59886.YahooMailNeo@web140005.mail.bf1.yahoo.com> Message-ID: <1354291532.92622.YahooMailNeo@web140001.mail.bf1.yahoo.com> No, but to isolate any possible layer2 traffic that could affect the issue, one of my colleagues performed host to guest testing in a VM and we are seeing the same issue. 14:28:30.420589 00:1c:42:d7:92:84 > 00:1c:42:00:00:08, ethertype ARP (0x0806), length 42: Request who-has 10.211.55.2 (00:1c:42:00:00:08) tell 10.211.55.3, length 28 14:28:30.420684 00:1c:42:00:00:08 > 00:1c:42:d7:92:84, ethertype ARP (0x0806), length 60: Reply 10.211.55.2 is-at 00:1c:42:00:00:08, length 46 14:29:03.421388 00:1c:42:d7:92:84 > 00:1c:42:00:00:08, ethertype ARP (0x0806), length 42: Request who-has 10.211.55.2 (00:1c:42:00:00:08) tell 10.211.55.3, length 28 14:29:03.421505 00:1c:42:00:00:08 > 00:1c:42:d7:92:84, ethertype ARP (0x0806), length 60: Reply 10.211.55.2 is-at 00:1c:42:00:00:08, length 46 14:29:36.423363 00:1c:42:d7:92:84 > 00:1c:42:00:00:08, ethertype ARP (0x0806), length 42: Request who-has 10.211.55.2 (00:1c:42:00:00:08) tell 10.211.55.3, length 28 14:29:36.423463 00:1c:42:00:00:08 > 00:1c:42:d7:92:84, ethertype ARP (0x0806), length 60: Reply 10.211.55.2 is-at 00:1c:42:00:00:08, length 46 14:30:09.424479 00:1c:42:d7:92:84 > 00:1c:42:00:00:08, ethertype ARP (0x0806), length 42: Request who-has 10.211.55.2 (00:1c:42:00:00:08) tell 10.211.55.3, length 28 The "real" traffic was just pings between the host/vm, and a raw capture was performed and the only mac addresses in use were the ones listed above. ________________________________ From: Marcel Plug To: James Stoll Cc: "nanog at nanog.org" Sent: Friday, November 30, 2012 8:35 AM Subject: Re: Windows 2008/2012 arp timeout process Hi James, Is your windows client seeing traffic from the 6500 with the real (Burned in) MAC address of your 6500? ?If so it may be re-arping to find out which of the MAC addresses is the 'right' one to use, the real MAC or the ?HSRP MAC. My memory is fuzzy, but I think I've seen issues like that before. ?Sorry its been a while so I can't remember anything more specific. -Marcel On Thu, Nov 29, 2012 at 5:22 PM, James Stoll wrote: Greetings Nanog, > >I apologize in advance if this should be directed towards a server/systems discussion list, but I've noticed some (what I think are) issues with the way windows 2008/2012 handles arp. I started noticing some high arp processes on some of our 6500s running sup720s, and after performing some captures of packets being punted to the cpu I found that there were quite a few repeat sources. After digging into the sources, it looks like windows 2008/2012 systems are sending arp refresh requests quite frequently. > >According to this article ( http://support.microsoft.com/kb/949589 ), if the neighbor entry is in use for the IP it should not go stale. Specifically: > >"If the entry is in the "Reachable" state, Windows Vista TCP/IP hosts do not send ARP requests to the network. Therefore, Windows Vista TCP/IP hosts use the information in the cache. If an entry is not used, and it stays in the "Reachable" state for longer than its "Reachable Time" value, the entry changes to the "Stale" state. If an entry is in the "Stale" state, the Windows Vista TCP/IP host must send an ARP request to reach that destination." > >I know that states Windows Vista, but the "applies to" section lists the other OSes. > >I've replicated this in my lab (server pinging its own gateway while capturing traffic), and I am seeing the same issue: > >222???????? 10:05:18.462720??????????????? Dell_a6:dc:52???? All-HSRP-routers_0a?????? ARP??????? Who has 10.36.0.1?? Tell 10.36.0.31 >223???????? 10:05:18.464759??????????????? All-HSRP-routers_0a?????? Dell_a6:dc:52???? ARP??????? 10.36.0.1 is at 00:00:0c:07:ac:0a >1886?????? 10:06:31.962218??????????????? Dell_a6:dc:52???? All-HSRP-routers_0a?????? ARP??????? Who has 10.36.0.1?? Tell 10.36.0.31 >1887?????? 10:06:31.963004??????????????? All-HSRP-routers_0a?????? Dell_a6:dc:52???? ARP??????? 10.36.0.1 is at 00:00:0c:07:ac:0a >3348?????? 10:07:23.461682??????????????? Dell_a6:dc:52???? All-HSRP-routers_0a?????? ARP??????? Who has 10.36.0.1?? Tell 10.36.0.31 >3349?????? 10:07:23.471003??????????????? All-HSRP-routers_0a?????? Dell_a6:dc:52???? ARP??????? 10.36.0.1 is at 00:00:0c:07:ac:0a > >I've tried this on various devices, and the only place I don't see this behavior is on wireless interfaces. > >I'm more of a linux guy, and performing the same tests there I see the behavior stated in this article (which is what I would expect) - http://linux-ip.net/html/ether-arp.html . Specifically: > >"Entries in the ARP cache are periodically and automatically verified unless continually used." > >Has anyone run into this issue before ? Have a fix ? Point me to any documentation or other distros that I should ask ? > >TIA, >James > From bzs at world.std.com Fri Nov 30 16:40:50 2012 From: bzs at world.std.com (Barry Shein) Date: Fri, 30 Nov 2012 11:40:50 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com> Message-ID: <20664.57746.539216.513326@world.std.com> On November 29, 2012 at 11:50 george.herbert at gmail.com (George Herbert) wrote: > On Thu, Nov 29, 2012 at 11:18 AM, Tom Beecher wrote: > > Assuming it's true, it was bound to happen. Running anything , TOR or > > otherwise, that allows strangers to do whatever they want is just folly. > > Such as, say, an Internet Service Provider business? Or a wi-fi hotspot that only requires clicking Accept, no id involved? -- -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 drc at virtualized.org Fri Nov 30 16:48:48 2012 From: drc at virtualized.org (David Conrad) Date: Fri, 30 Nov 2012 08:48:48 -0800 Subject: carping about CARP In-Reply-To: <20121130130827.GB16865@quigon.bsws.de> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> <20121130130827.GB16865@quigon.bsws.de> Message-ID: <4F61C7CB-6AAD-4E43-A764-4A4C7E438A37@virtualized.org> On Nov 30, 2012, at 5:08 AM, Henning Brauer wrote: > and re IANA, they made it clear they would not give us a proto number As they should have. IANA abides by the rules laid down for it by the IETF/IESG/IAB. The openbsd folks couldn't be bothered to even write up a draft and chose to squat on a protocol number. > no matter what; BS. If the openbsd folks followed the rules, they'd have gotten the number(s) they requested (assuming they were justified). There is no grand persecution here. There is management of a limited resource. > we didn't have a choice but to ignore that industry-money-driven committee. Which 'industry-money-driven committee' would that be? Regards, -drc From sotnickd-nanog at ddv.com Fri Nov 30 17:14:11 2012 From: sotnickd-nanog at ddv.com (Dave Sotnick) Date: Fri, 30 Nov 2012 09:14:11 -0800 Subject: Recovering from spam resulting from compromised account In-Reply-To: References: Message-ID: Hello again, I sincerely appreciate all the suggestions over the past week or so. We are mostly out of the woods. Yahoo is still blocking one of our MXs (12.25.180.94), despite repeated attempts to clear that IP. It appears as though no matter who we contact at Yahoo, they are all sending the same canned response: "While we cannot provide you with specific information, we encourage you to > review some of our recommended best practices for sending to Yahoo! Mail. > For assistance with delivery issues to Yahoo! Mail, please visit the Yahoo! > Postmaster help site. Your patience during this process is greatly > appreciated. Thank you again for contacting Yahoo! Mail." ***If anyone knows of a human at Yahoo who might actually be able to assist, that would be much appreciated.*** We got our way out of this mess by writing to the major Postmasters, explaining the situation and then being patient while things cleared up. Gmail was the most responsive (surprise surprise), and once our mail queue was cleared of all queued SPAM and we _actually_ stopped sending messages, they automatically cleared our name without requiring any human intervention. Oh, and to add insult to injury, an IP address change at AT&T was preventing them from slaving our reverse DNS, which expired and caused a whole mess of further problems to our email. :-( Time to add some _external_ DNS health checks to our monitoring systems. Thanks again, Dave On Wed, Nov 21, 2012 at 5:53 PM, Dave Sotnick wrote: > Hello, oh knowledgeable NANOG. > > I am the technical lead for network for Pixar. (Note: I am not the > mail admin, he's on vacation.) Yesterday we had an account compromise > that resulted in ~2.5M messages being sent through our two MTAs. > > I have acknowledged/closed the two SpamCop incidents, and mail is > starting to flow, slowly, however we are still receiving bounces (some > hard!) and I am looking for assistance in getting Pixar's IPs cleared > from the blacklists. > > I was pointed to: > > http://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a12.25.180.66 > http://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a12.25.180.94 > > Which shows we're still listed on Backscatterer and SPAM Cannibal. > > Also had reports that we're still seeing bounces to Gmail, Comcast and > Yahoo accounts. > > What can we do to speed things along? We have a ticket open with Gmail > folks since we have a studio who uses Gmail for Corporate mail. Any > Comcast or Gmail SMTP contacts on NANOG that can help? Would love to > get all out stuck mail out of these folks' MTAs. > > Or do we need to just remove ourselves from the last two blacklists at > mxtoolbox? > > Thanks, > David Sotnick > -- > Pixar > Emeryville, CA From bzs at world.std.com Fri Nov 30 17:48:16 2012 From: bzs at world.std.com (Barry Shein) Date: Fri, 30 Nov 2012 12:48:16 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121130071804.GA28545@nike.aronius.se> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> Message-ID: <20664.61792.77457.146095@world.std.com> On November 30, 2012 at 08:18 joakim at aronius.se (Joakim Aronius) wrote: > > I am all for being anonymous on the net but I seriously believe that we still need to enforce the law when it comes to serious felonies like child pr0n, organized crime etc, we can't give them a free pass just by using Tor. I dont think it should be illegal to operate a Tor exit node but what just happened could be a consequence of doing it. Yeah, next they'll let just anyone walk down the sidewalk without identifying themselves. And those are public sidewalks paid for by tax dollars! Or drop a few coins in a public telephone (I know, a little dated, but they exist) w/o id and commit some crime! I think some here need to reflect on what they're saying. Sure, it'd be better to stop bad guys, but this has always been the problem in a free society, you can't just put draconian rules on everyone else because otherwise some bad guy might not be immediately and easily identified. This was the sort of reasoning they used in the Soviet Union to make it very difficult to get access to a photocopy machine (ask someone who lived there, it was practically like buying a firearm in the US.) We're all (well most of us) glad that law enforcement does its job, but even the US Constitution (3rd amendment) bothered to state: No Soldier shall, in time of peace be quartered in any house, without the consent of the Owner, nor in time of war, but in a manner to be prescribed by law. It's only an analogy but I think it's clear, if we're protected from being forced to provide food & shelter directly to soldiers presumably defending our lives and country the principle as it pertains to being required to do whatever law enforcement dreams up to catch bad guys is pretty clear. As a principle -- Note: I am NOT making a legal point! Ok, grab onto that "manner prescribed by law", but remember that it said "in time of war". None of what we're discussing is relevant to any war (except as politicians toss around the war on this or that.) > Of course they might not know abot Tor and believes that it is Mr Williams that is the bad guy. > > /J Sure, but I assume he told them that :-) -- -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 mfidelman at meetinghouse.net Fri Nov 30 18:25:42 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 30 Nov 2012 13:25:42 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20664.61792.77457.146095@world.std.com> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> <20664.61792.77457.146095@world.std.com> Message-ID: <50B8FA26.6070104@meetinghouse.net> Barry Shein wrote: > On November 30, 2012 at 08:18 joakim at aronius.se (Joakim Aronius) wrote: > > > > I am all for being anonymous on the net but I seriously believe that we still need to enforce the law when it comes to serious felonies like child pr0n, organized crime etc, we can't give them a free pass just by using Tor. I dont think it should be illegal to operate a Tor exit node but what just happened could be a consequence of doing it. > > Yeah, next they'll let just anyone walk down the sidewalk without > identifying themselves. And those are public sidewalks paid for by tax > dollars! > > Or drop a few coins in a public telephone (I know, a little dated, but > they exist) w/o id and commit some crime! > > I think some here need to reflect on what they're saying. > > Sure, it'd be better to stop bad guys, but this has always been the > problem in a free society, you can't just put draconian rules on > everyone else because otherwise some bad guy might not be immediately > and easily identified. > Well put Barry. Or, as Ben Franklin put it: "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Miles Fidelman* * -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bill at herrin.us Fri Nov 30 18:29:26 2012 From: bill at herrin.us (William Herrin) Date: Fri, 30 Nov 2012 13:29:26 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20664.61792.77457.146095@world.std.com> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> <20664.61792.77457.146095@world.std.com> Message-ID: On Fri, Nov 30, 2012 at 12:48 PM, Barry Shein wrote: > Yeah, next they'll let just anyone walk down the sidewalk without > identifying themselves. And those are public sidewalks paid for by tax > dollars! If you hang out with criminals, sooner or later you'll encounter a situation where there is a reasonable suspicion that you committed a crime. Not because you hung out with criminals but because something criminal happened while you were hanging out with the criminals and with only a partial set of facts it appears likely that you did it. It takes extraordinary diligence to hang out with criminals yet remain personally above reproach. It's a tightrope many news reporters have to walk. I have yet to see such diligence practiced in the operation of a Tor node. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dougb at dougbarton.us Fri Nov 30 18:34:46 2012 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 30 Nov 2012 12:34:46 -0600 Subject: carping about CARP In-Reply-To: <4F61C7CB-6AAD-4E43-A764-4A4C7E438A37@virtualized.org> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> <20121130130827.GB16865@quigon.bsws.de> <4F61C7CB-6AAD-4E43-A764-4A4C7E438A37@virtualized.org> Message-ID: <50B8FC46.4000705@dougbarton.us> This issue came up originally during my tenure at IANA, and FWIW I concur with David. I have a vague memory of engaging directly with some folks from OpenBSD and letting them know that I was sympathetic with their situation, but IANA has strict rules to follow, and unless they followed procedure my hands were tied. Re the "industry-money-driven committee" bit, at the time (and in fact, up until recently) I was a FreeBSD committer myself, so if anything I was *more* inclined to be sympathetic to those from the OS community who submitted applications. I can also assure you that we did assign code points to a non-trivial number of open source applicants _who followed the documented procedures_. Doug On 11/30/2012 10:48 AM, David Conrad wrote: > On Nov 30, 2012, at 5:08 AM, Henning Brauer wrote: >> and re IANA, they made it clear they would not give us a proto number > > As they should have. IANA abides by the rules laid down for it by the IETF/IESG/IAB. The openbsd folks couldn't be bothered to even write up a draft and chose to squat on a protocol number. > >> no matter what; > > BS. If the openbsd folks followed the rules, they'd have gotten the number(s) they requested (assuming they were justified). There is no grand persecution here. There is management of a limited resource. > >> we didn't have a choice but to ignore that industry-money-driven committee. > > Which 'industry-money-driven committee' would that be? > > Regards, > -drc From cscora at apnic.net Fri Nov 30 18:55:37 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Dec 2012 04:55:37 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201211301855.qAUItbME001943@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 01 Dec, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 434185 Prefixes after maximum aggregation: 180393 Deaggregation factor: 2.41 Unique aggregates announced to Internet: 212775 Total ASes present in the Internet Routing Table: 42729 Prefixes per ASN: 10.16 Origin-only ASes present in the Internet Routing Table: 33874 Origin ASes announcing only one prefix: 15815 Transit ASes present in the Internet Routing Table: 5690 Transit-only ASes present in the Internet Routing Table: 135 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 41 Max AS path prepend of ASN ( 22394) 35 Prefixes from unregistered ASNs in the Routing Table: 1103 Unregistered ASNs in the Routing Table: 406 Number of 32-bit ASNs allocated by the RIRs: 3544 Number of 32-bit ASNs visible in the Routing Table: 3165 Prefixes from 32-bit ASNs in the Routing Table: 8591 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 146 Number of addresses announced to Internet: 2614823628 Equivalent to 155 /8s, 219 /16s and 10 /24s Percentage of available address space announced: 70.6 Percentage of allocated address space announced: 70.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.9 Total number of prefixes smaller than registry allocations: 153016 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 104809 Total APNIC prefixes after maximum aggregation: 32640 APNIC Deaggregation factor: 3.21 Prefixes being announced from the APNIC address blocks: 105681 Unique aggregates announced from the APNIC address blocks: 43268 APNIC Region origin ASes present in the Internet Routing Table: 4800 APNIC Prefixes per ASN: 22.02 APNIC Region origin ASes announcing only one prefix: 1244 APNIC Region transit ASes present in the Internet Routing Table: 786 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 375 Number of APNIC addresses announced to Internet: 715311872 Equivalent to 42 /8s, 162 /16s and 203 /24s Percentage of available APNIC address space announced: 83.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, 131072-133119 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: 155613 Total ARIN prefixes after maximum aggregation: 78549 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 156347 Unique aggregates announced from the ARIN address blocks: 69911 ARIN Region origin ASes present in the Internet Routing Table: 15313 ARIN Prefixes per ASN: 10.21 ARIN Region origin ASes announcing only one prefix: 5771 ARIN Region transit ASes present in the Internet Routing Table: 1598 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 41 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1087539840 Equivalent to 64 /8s, 210 /16s and 138 /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, 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: 110794 Total RIPE prefixes after maximum aggregation: 57939 RIPE Deaggregation factor: 1.91 Prefixes being announced from the RIPE address blocks: 113671 Unique aggregates announced from the RIPE address blocks: 73036 RIPE Region origin ASes present in the Internet Routing Table: 16973 RIPE Prefixes per ASN: 6.70 RIPE Region origin ASes announcing only one prefix: 8130 RIPE Region transit ASes present in the Internet Routing Table: 2750 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 31 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2051 Number of RIPE addresses announced to Internet: 648513060 Equivalent to 38 /8s, 167 /16s and 134 /24s Percentage of available RIPE address space announced: 94.3 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, 196608-199679 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: 44625 Total LACNIC prefixes after maximum aggregation: 8910 LACNIC Deaggregation factor: 5.01 Prefixes being announced from the LACNIC address blocks: 48145 Unique aggregates announced from the LACNIC address blocks: 22869 LACNIC Region origin ASes present in the Internet Routing Table: 1732 LACNIC Prefixes per ASN: 27.80 LACNIC Region origin ASes announcing only one prefix: 496 LACNIC Region transit ASes present in the Internet Routing Table: 330 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 715 Number of LACNIC addresses announced to Internet: 120089384 Equivalent to 7 /8s, 40 /16s and 107 /24s Percentage of available LACNIC address space announced: 71.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 9637 Total AfriNIC prefixes after maximum aggregation: 2298 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 10195 Unique aggregates announced from the AfriNIC address blocks: 3564 AfriNIC Region origin ASes present in the Internet Routing Table: 578 AfriNIC Prefixes per ASN: 17.64 AfriNIC Region origin ASes announcing only one prefix: 174 AfriNIC Region transit ASes present in the Internet Routing Table: 131 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 43071488 Equivalent to 2 /8s, 145 /16s and 56 /24s Percentage of available AfriNIC address space announced: 42.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 4766 2942 11557 900 Korea Telecom (KIX) 17974 2431 826 46 PT TELEKOMUNIKASI INDONESIA 7545 1811 301 90 TPG Internet Pty Ltd 4755 1625 374 159 TATA Communications formerly 9829 1412 1155 42 BSNL National Internet Backbo 9583 1182 88 499 Sify Limited 7552 1142 1062 11 Vietel Corporation 4808 1126 2056 317 CNCGROUP IP network: China169 24560 1040 385 165 Bharti Airtel Ltd., Telemedia 9498 1032 310 74 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3196 994 218 Windstream Communications Inc 6389 3145 3719 148 bellsouth.net, inc. 18566 2083 382 180 Covad Communications 22773 1938 2932 131 Cox Communications, Inc. 1785 1935 678 124 PaeTec Communications, Inc. 20115 1684 1607 625 Charter Communications 4323 1589 1153 394 Time Warner Telecom 30036 1360 280 750 Mediacom Communications Corp 7018 1279 10275 848 AT&T WorldNet Services 7011 1223 334 693 Citizens Utilities 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 1715 544 16 Corbina telecom 12479 856 777 64 Uni2 Autonomous System 34984 849 210 215 BILISIM TELEKOM 2118 784 97 15 EUnet/RELCOM Autonomous Syste 13188 742 94 132 Educational Network 31148 738 38 13 FreeNet ISP 6830 717 2313 436 UPC Distribution Services 20940 705 227 545 Akamai Technologies European 8551 603 367 39 Bezeq International 58113 603 68 366 LIR DATACENTER TELECOM SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2261 386 206 TVCABLE BOGOTA 28573 2160 1285 66 NET Servicos de Comunicao S.A 7303 1668 1138 201 Telecom Argentina Stet-France 8151 1601 3022 356 UniNet S.A. de C.V. 6503 1538 435 67 AVANTEL, S.A. 27947 754 77 92 Telconet S.A 3816 659 309 70 Empresa Nacional de Telecomun 11172 603 85 68 Servicios Alestra S.A de C.V 18881 595 716 18 Global Village Telecom 7738 579 1178 33 Telecomunicacoes da Bahia 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 24863 873 274 36 LINKdotNET AS number 36998 772 48 3 MOBITEL 8452 536 958 13 TEDATA 6713 519 666 20 Itissalat Al-MAGHRIB 24835 289 80 8 RAYA Telecom - Egypt 3741 268 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 179 697 88 MTN Network Solutions 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 7029 3196 994 218 Windstream Communications Inc 6389 3145 3719 148 bellsouth.net, inc. 4766 2942 11557 900 Korea Telecom (KIX) 17974 2431 826 46 PT TELEKOMUNIKASI INDONESIA 10620 2261 386 206 TVCABLE BOGOTA 28573 2160 1285 66 NET Servicos de Comunicao S.A 18566 2083 382 180 Covad Communications 22773 1938 2932 131 Cox Communications, Inc. 1785 1935 678 124 PaeTec Communications, Inc. 7545 1811 301 90 TPG Internet Pty Ltd 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 3145 2997 bellsouth.net, inc. 17974 2431 2385 PT TELEKOMUNIKASI INDONESIA 28573 2160 2094 NET Servicos de Comunicao S.A 10620 2261 2055 TVCABLE BOGOTA 4766 2942 2042 Korea Telecom (KIX) 18566 2083 1903 Covad Communications 1785 1935 1811 PaeTec Communications, Inc. 22773 1938 1807 Cox Communications, Inc. 7545 1811 1721 TPG Internet Pty Ltd 8402 1715 1699 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59530 UNALLOCATED 5.8.182.0/24 31261 GARS Telecom 61408 UNALLOCATED 5.56.0.0/21 174 Cogent Communication 61395 UNALLOCATED 5.83.56.0/22 3292 TDC Tele Danmark 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.112.114.0/24 23884 Proimage Engineering and Comm 41.222.80.0/21 37110 Moztel LDA 41.223.108.0/22 36966 >>UNKNOWN<< 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.66.32.0/20 18864 >>UNKNOWN<< 64.187.208.0/24 174 Cogent Communications 64.187.209.0/24 23005 Power Pulse 65.111.1.0/24 32258 SDN Global 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:18 /9:13 /10:29 /11:88 /12:243 /13:478 /14:858 /15:1555 /16:12467 /17:6553 /18:10881 /19:21495 /20:30777 /21:32846 /22:43646 /23:40544 /24:227407 /25:1363 /26:1734 /27:885 /28:184 /29:79 /30:17 /31:0 /32:25 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2620 3196 Windstream Communications Inc 18566 2033 2083 Covad Communications 6389 1781 3145 bellsouth.net, inc. 8402 1424 1715 Corbina telecom 22773 1273 1938 Cox Communications, Inc. 30036 1273 1360 Mediacom Communications Corp 11492 1146 1181 Cable One 6503 1054 1538 AVANTEL, S.A. 1785 1021 1935 PaeTec Communications, Inc. 7011 958 1223 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:646 2:753 3:1 4:13 5:660 6:3 8:488 12:1953 13:3 14:701 15:10 16:3 17:6 20:27 23:217 24:1779 27:1416 31:1297 32:54 33:2 34:2 36:7 37:1057 38:845 39:2 40:140 41:2624 42:179 44:3 46:1699 47:3 49:507 50:619 52:12 54:27 55:7 57:28 58:1067 59:550 60:234 61:1287 62:1026 63:2022 64:4332 65:2200 66:4499 67:2100 68:1165 69:3238 70:926 71:557 72:1893 74:2622 75:479 76:299 77:986 78:1020 79:506 80:1227 81:982 82:632 83:540 84:529 85:1159 86:477 87:960 88:354 89:1744 90:305 91:5352 92:590 93:1574 94:2014 95:1202 96:408 97:323 98:972 99:40 100:31 101:285 103:1868 105:516 106:119 107:202 108:487 109:1669 110:814 111:972 112:459 113:737 114:643 115:898 116:888 117:777 118:962 119:1253 120:376 121:678 122:1738 123:1179 124:1326 125:1290 128:572 129:201 130:294 131:666 132:317 133:143 134:254 135:62 136:215 137:238 138:340 139:168 140:492 141:294 142:499 143:363 144:492 145:83 146:523 147:287 148:735 149:330 150:155 151:221 152:398 153:183 154:22 155:440 156:226 157:375 158:279 159:673 160:335 161:414 162:370 163:192 164:581 165:449 166:479 167:561 168:980 169:130 170:977 171:151 172:6 173:1699 174:640 175:441 176:889 177:1451 178:1681 180:1351 181:178 182:1116 183:303 184:621 185:104 186:2065 187:1437 188:1790 189:1603 190:5975 192:6064 193:5428 194:4395 195:3659 196:1238 197:272 198:3951 199:5098 200:6018 201:1971 202:8803 203:8741 204:4439 205:2554 206:2759 207:2802 208:4067 209:3651 210:2900 211:1527 212:2149 213:1870 214:886 215:74 216:5180 217:1605 218:588 219:311 220:1258 221:533 222:336 223:419 End of report From bill at herrin.us Fri Nov 30 19:09:59 2012 From: bill at herrin.us (William Herrin) Date: Fri, 30 Nov 2012 14:09:59 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> Message-ID: On Fri, Nov 30, 2012 at 9:45 AM, Ray Soucy wrote: > I'll see your disagree and raise you another ;-) > > I would say you almost never want to store addresses as character data > unless the only thing you're using them for is logging (even then it's > questionable). I run into people who do this all the time and it's a > nightmare. > > It's easy to store a v6 address as a string, but when you want to select a > range of IPv6 addresses from a database, not having them represented as > integers means you can't do efficient numerical comparisons in your SQL > statements, it also makes indexing your table slower; to put it simply, it > doesn't scale well. Hi Ray, If you've stored them in the string format I suggested, the string comparison *is* an efficient numerical comparison. On a CISC processor it may even be implemented with a single instruction byte string comparison. Go test. You may be surprised at the results. The one useful function you can't do directly from a string format is apply an AND mask (netmask). More often than not this is irrelevant: you don't want to load the data and then apply the mask, you want the mask to constrain the data which you load from the database. You'd need the database software to understand the address type and index it with a radix tree, something it can do with neither a string format nor your split 64-bit format. In either case you substitute query by range for query by netmask. WHERE IP>='A' AND IP<='B' WHERE (IPHigh>AHigh AND IPHigh=ALow) OR (IPHigh!=AHigh AND IPHigh=BHigh AND IPLow<=BLow) OR (IPHigh=AHigh AND IPHigh=BHigh AND IPLow>=ALow AND IPLow<=BLow) Which version looks more efficient to you? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Fri Nov 30 19:35:23 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Nov 2012 11:35:23 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121130125853.GB7333@gsp.org> References: <20121130125853.GB7333@gsp.org> Message-ID: <2FC0561A-EC60-46A9-A4ED-EEEF48BBC7BC@delong.com> On Nov 30, 2012, at 4:58 AM, Rich Kulawiec wrote: > On Thu, Nov 29, 2012 at 08:04:02AM -0500, Chris quoted (William): >> Yes, it happened to me now as well - Yesterday i got raided for >> someone sharing child pornography over one of my Tor exits. > > Question: what evidence has been published -- that is, placed somewhere > that we can all see it -- that substantiates the claim that child porn > traversed the node in question? > > Followup question 1: if no such evidence has been produced, then > why should we believe that it exists? Extraordinary claims require > extraordinary proof. > I don't find the claim all that extraordinary. I think it was only a matter of time before the kiddie-pr0n distributors figured out TOR as a perfect way to distribute anonymously. > Followup question 2: if the goal is to identify and apprehend the > perpetrators of child porn (and that's a good goal) then why would > the police raid this operation? Would it not make far more sense to > take advantage of the operator's knowledge and experience and quietly > ask for his/her cooperation *while leaving the node running*? Sure, but law enforcement isn't exactly renowned for doing the smart things in such situations. Especially during their rather extensive learning curve. > Followup question 3: what evidence in front of us allows us to clearly > discern that this is what it purports to be and not simply an attempt > to shut down a Tor node (and intimidate the operators of others) > by using a plausible excuse based on a universal hot-button issue? > None whatsoever. It's an entirely plausible alternate explanation. At this point, we can't rule either of them out. However, the basic theory "Never attribute to malice what can be adequately explained by incompetence." says that the kiddie-pr0n story is more likely. Owen From owen at delong.com Fri Nov 30 20:04:19 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Nov 2012 12:04:19 -0800 Subject: carping about CARP In-Reply-To: <86ip8n6z11.fsf@seastrom.com> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> Message-ID: <04A3A2DE-708C-4F52-B4C3-86BE2A628278@delong.com> >> I believe that idea has legs regardless of practical considerations >> and stands on it's own. >> >> Besides, I won't discount OpenBSD out of hand for forging ahead, >> withstanding practical issues, considering the runs they've got on the >> board and the many facepalm fails we see in the diametrically opposed >> corporate world. >> >> It might be a very good thing they've bothered to take the time on this. > > The problem here is "insufficient paranoia about packets that come > flying in over the transom, based on naive contemporaneous belief that > a particular protocol number was not in use". I mean, gosh, who would > ever send packets on an unused protocol number? And who other than us > would get frustrated with the process and decide to forge ahead on > their own. > Perhaps we should ask IETF/IANA to allocate a group of protocol numbers to "the wild west". A protocol-number equivalent of RFC-1918 or private ASNs. You can use these for whatever you want, but so can anyone else and if you do, you do so at your own risk. This won't entirely solve the problem, but at least it would provide some level of shield for protocol numbers that are registered to particular purposes through the IETF/IANA process. Owen From owen at delong.com Fri Nov 30 20:46:45 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Nov 2012 12:46:45 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unf! ix.org> Message-ID: <1ACE1BF5-811C-4F49-9BCC-5CC5ABDC5530@delong.com> On Nov 30, 2012, at 11:09 AM, William Herrin wrote: > On Fri, Nov 30, 2012 at 9:45 AM, Ray Soucy wrote: >> I'll see your disagree and raise you another ;-) >> >> I would say you almost never want to store addresses as character data >> unless the only thing you're using them for is logging (even then it's >> questionable). I run into people who do this all the time and it's a >> nightmare. >> >> It's easy to store a v6 address as a string, but when you want to select a >> range of IPv6 addresses from a database, not having them represented as >> integers means you can't do efficient numerical comparisons in your SQL >> statements, it also makes indexing your table slower; to put it simply, it >> doesn't scale well. > > Hi Ray, > > If you've stored them in the string format I suggested, the string > comparison *is* an efficient numerical comparison. On a CISC processor > it may even be implemented with a single instruction byte string > comparison. Go test. You may be surprised at the results. > > The one useful function you can't do directly from a string format is > apply an AND mask (netmask). More often than not this is irrelevant: > you don't want to load the data and then apply the mask, you want the > mask to constrain the data which you load from the database. You'd > need the database software to understand the address type and index it > with a radix tree, something it can do with neither a string format > nor your split 64-bit format. > Since non-contiguous masking is rare, this can, actually be pretty efficient for contiguous masking because you have a ? chance that the mask aligns with a character (the more I think about this, the more I think storing the address as a 32-character string without colons makes the most sense). If it's not aligned on a nibble boundary, then you can either do ranged comparisons as suggested below, or, you can do a two-step process like this: Let's say we want to look for addresses within 2001:db8::/29. This would mean we need to match all strings starting with 2001:0db8 through 2001:0dbf. We could easily grab everything that begins with '20010db%' and then select the masked values matching from the 8th column where (atoi(concat("0x",substr(addr,8,1))) & 0x8). Forgive me if I don't get the SQL syntax exactly right or have a wrong function name? I do more C than SQL. Both of these comparisons could be performed in a single select like: SELECT * FROM WHERE ip6addr is like '20010db%' and \ (atoi(concat('0x', substr(ip6addr,8,1))) & 0x8) This should be relatively efficient because the more expensive second test will only be performed on records that first pass the relatively cheap match of the first 7 characters. Owen > From cjeker at diehard.n-r-g.com Fri Nov 30 21:01:54 2012 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Fri, 30 Nov 2012 22:01:54 +0100 Subject: carping about CARP In-Reply-To: <4F61C7CB-6AAD-4E43-A764-4A4C7E438A37@virtualized.org> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> <20121130130827.GB16865@quigon.bsws.de> <4F61C7CB-6AAD-4E43-A764-4A4C7E438A37@virtualized.org> Message-ID: <20121130210154.GJ11066@diehard.n-r-g.com> On Fri, Nov 30, 2012 at 08:48:48AM -0800, David Conrad wrote: > On Nov 30, 2012, at 5:08 AM, Henning Brauer wrote: > > and re IANA, they made it clear they would not give us a proto number > > As they should have. IANA abides by the rules laid down for it by the > IETF/IESG/IAB. The openbsd folks couldn't be bothered to even write up a > draft and chose to squat on a protocol number. > > > no matter what; > > BS. If the openbsd folks followed the rules, they'd have gotten the > number(s) they requested (assuming they were justified). There is no > grand persecution here. There is management of a limited resource. > IETF already decided that VRRP was the way to go. So an alternative implementation would not have been accepted. The result would be a draft that would never be adopted and so it is back to start. Still carp packets can coexist with vrrp packets. They use a different version numbers. Also you need to use a different vhid but the same thing is true if you have 2 groups of vrrp on the same lan. If you configure something like VRRP you should run a quick tcpdump first and check if there are not unexpected packets showing up. This is especially important for any protocol that does a link local multicast or broadcast. This is basic network admin best practice (at least I expect that from a network engineer). > > we didn't have a choice but to ignore that industry-money-driven committee. > > Which 'industry-money-driven committee' would that be? Did you ever read any of the IETF mailing lists and looked at the email addresses of those people pushing the hardest? At least in the ones I'm subscribed to the bias is obvious. -- :wq Claudio From SNaslund at medline.com Fri Nov 30 21:01:53 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 15:01:53 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121130125853.GB7333@gsp.org> References: <20121130125853.GB7333@gsp.org> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> >-----Original Message----- >From: Rich Kulawiec [mailto:rsk at gsp.org] >Sent: Friday, November 30, 2012 6:59 AM >To: nanog at nanog.org >Subject: Re: William was raided for running a Tor exit node. Please help if you can. > On Thu, Nov 29, 2012 at 08:04:02AM -0500, Chris quoted (William): > Yes, it happened to me now as well - Yesterday i got raided for > someone sharing child pornography over one of my Tor exits. > Question: what evidence has been published -- that is, placed somewhere that we can all see it -- that substantiates the claim that child porn > traversed the node in question? The cops don't have to present evidence until there is a court case. Since this guy was not arrested, they have apparently not decided to charge him yet. The apparently had some evidence to get the seizure order. They have to convince a judge, not the public. > Followup question 1: if no such evidence has been produced, then why should we believe that it exists? Extraordinary claims require extraordinary > proof. Again, no evidence needed until a prosecution happens. Just enough for the cops to convince a judge to allow the evidence seizure. >Followup question 2: if the goal is to identify and apprehend the perpetrators of child porn (and that's a good goal) then why would the police raid >this operation? Would it not make far more sense to take advantage of the operator's knowledge and experience and quietly ask for his/her cooperation >*while leaving the node running*? Maybe the cops think he is a perpetrator. It is not unthinkable that he set up a network to hide his own activities. Note that they seized his HOME storage devices, not the Tor server. >Followup question 3: what evidence in front of us allows us to clearly discern that this is what it purports to be and not simply an attempt to shut >down a Tor node (and intimidate the operators of others) by using a plausible excuse based on a universal hot-button issue? Since the individual indicates that the Tor node was already down and the police did not seize it, what makes you think that it was the target at all. The individual only indicated that the police asked about the IP address used by the Tor server during his questioning so it is possible they did not know it was a Tor node and maybe thought it was at his apartment. I have yet to see anything indicating that he is not allowed to bring his Tor node back online. I am not assuming this is only about the Tor node just because the cops asked him about it. I am a little concerned that this guy keeps a safe deposit box with a burner phone and cash around. Is he a CIA agent? :) Why would I donate to his legal defense when he has not been charged yet? A little premature, no? >---rsk Steven Naslund From SNaslund at medline.com Fri Nov 30 21:30:37 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 15:30:37 -0600 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121130072505.GD9750@leitl.org> References: <20121130072505.GD9750@leitl.org> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> WAIT A SECOND HERE!?!? I just read below that this guy runs a large ISP in Austria. I thought his Tor node was hosted with an external provider. If he runs the ISP, why would he not host his own server in house? I suppose there are reasons but I can't think of one, especially if you feel so strongly about this being your right. He talks about moving it to another ISP in the article interviewing him. How about moving it to the large ISP you run? If he runs a large ISP he must not be very good at it if he needs our donations to help him defend himself from a crime he has not been charged with yet. Most of the guys I know that run large ISPs have legal guys available to them. They could also come up with 10000EUR if necessary. What is he going to do with this money if no charges are filed and they give his gear back? If he believes that he is innocent of any crime then he should be confident they won't find anything to charge him with, right? > > If convicted i could face up to 6 years in jail, of course i do not > > want that and i also want to try to set a legal base for running Tor > > exit nodes in Austria or even the EU. > > Six years in jail for what? They didn't arrest you yet. How do you know what the charges are? The cops must not be too worried about the Tor node if they did not seize it. They seem a lot more interested in his personal storage devices. He seems to have a lot of data at home, not illegal (possibly) but I am wondering what it all might be. The cops have a lot of looking around ahead of them. Seems awful worried for a guy who claims to be innocent. I am wondering why he seems so sure he will be charged that he is building a legal defense fund before being arrested. > > Sadly we have nothing like the EFF here that could help me in this > > case by legal assistance, so i'm on my own and require a good lawyer. > > Thus i'm accepting donations for my legal expenses which i expect to > > be around 5000-10000 EUR. So you know how much it costs to defend a case with unknown charges and without knowing if you will be arrested yet?!?!?! This whole thing sounds flakier with every new detail. Steven Naslund -----Original Message----- From: Eugen Leitl [mailto:eugen at leitl.org] Sent: Friday, November 30, 2012 1:25 AM To: NANOG list Subject: Re: [tor-talk] William was raided for running a Tor exit node. Please help if you can. ----- Forwarded message from Asad Haider ----- From: Asad Haider Date: Thu, 29 Nov 2012 19:37:24 +0000 To: tor-talk at lists.torproject.org Subject: Re: [tor-talk] William was raided for running a Tor exit node. Please help if you can. Reply-To: tor-talk at lists.torproject.org William will be posting a statement soon which will explain everything that's happened and give a detailed account of events, along with evidence including pictures showing the aftermath of the raid in his apartment, as well as copies of the warrant and inventory of seized items. He runs a large ISP in Austria and is a well respected member of the community, a lot of us have already sent in donations. His blog is https://rdns.im/ and I'm guessing the statement will be posted on there, I'll send everyone a link once it's finished being written. On 29 November 2012 19:22, Eugen Leitl wrote: > ----- Forwarded message from Emily Ozols ----- > > From: Emily Ozols > Date: Fri, 30 Nov 2012 01:14:08 +1100 > To: nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. Please help if > you can. > > Hi, > > I gotta ask and I'm sure someone would if I didn't, but how do we know > this guy is legit? > He's jumped up on a forum saying, "Hey, police raided me, help. gib > mone plz" and failed to provide and reason as to how he's real and not > just making it up. > > Maybe if there's a way to know this guy is legit, I'll help out if > possible, but until then I'm just going to watch others with caution > and I suggest others do as well. > > On Fri, Nov 30, 2012 at 12:04 AM, Chris wrote: > > I'm not William and a friend pasted a link on IRC to me. I'm going > > to send him a few bucks because I know how it feels to get > > blindsided by the police on one random day and your world is turned upside down. > > > > Source: > http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exi > t-accepting-donations-for-legal-expenses > > > > From the URL: > > > > Yes, it happened to me now as well - Yesterday i got raided for > > someone sharing child pornography over one of my Tor exits. > > I'm good so far, not in jail, but all my computers and hardware have > > been confiscated. > > (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) > > > > If convicted i could face up to 6 years in jail, of course i do not > > want that and i also want to try to set a legal base for running Tor > > exit nodes in Austria or even the EU. > > > > Sadly we have nothing like the EFF here that could help me in this > > case by legal assistance, so i'm on my own and require a good lawyer. > > Thus i'm accepting donations for my legal expenses which i expect to > > be around 5000-10000 EUR. > > > > If you can i would appreciate if you could donate a bit (every > > amount helps, even the smallest) either by PayPal (any currency is ok): > > > https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZ > NBBD7EH4 > > > > Or by Bank Transfer (EUR only please): > > > > Holder: William Weber > > Bank: EasyBank AG (Vienna, Austria) > > Account: 20011351213 > > Bank sort number: 14200 > > IBAN: AT031420020011351213 > > BIC: EASYATW1 > > > > I will try to pay them back when i'm out of this (or even before) > > but i can obviously not guarantee this, please keep this in mind. > > This money will only be used for legal expenses related to this case. > > > > If you have any questions or want to donate by another way > > (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel > > free to send me a mail (william at william.si) or a PM, or contact me > > in LET IRC. > > > > Thanks! > > William > > > > > > > > > > -- > > --C > > > > "The dumber people think you are, the more surprised they're going > > to be when you kill them." - Sir William Clayton > > > > > > -- > ~Em > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > _______________________________________________ > tor-talk mailing list > tor-talk at lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > _______________________________________________ tor-talk mailing list tor-talk at lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From mysidia at gmail.com Fri Nov 30 21:46:57 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 30 Nov 2012 15:46:57 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: On 11/29/12, William Herrin wrote: > If the computer at IP:port:timestamp transmitted child porn, a warrant > for "all computers" is also too broad. "Computers which use said IP As you know, there may always be some uncertainty about which computer was using a certain IP address at a certain time -- the computer assigned that address might have been off, with a deviant individual spoofing MAC address and IP address of a certain computer, using different equipment still attached to the same physical LAN. Their warrant authors will probably not say "all computers"; they will more likely say something like all digital storage media, and equipment required for access. Which includes all hard drives, SSDs, CF cards, diskettes, CDRs, and all the computing equipment they are installed in (keyboard, monitor, mouse, etc) normally used to access the media. > address or which employ forensic countermeasures which prevent a ready > determination whether they employed said IP address." And have a DHCP? > qualified technician on the search team, same as you would for any > other material being searched. If they had a qualified technician, they probably wouldn't be raiding a TOR exit node in the first place; they would have investigated the matter more thoroughly, and saved precious time. -- -JH From alter3d at alter3d.ca Fri Nov 30 21:53:16 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 30 Nov 2012 16:53:16 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> Message-ID: <50B92ACC.70104@alter3d.ca> On 11/30/2012 04:01 PM, Naslund, Steve wrote: > I am a little concerned that this guy keeps a safe deposit box with a burner > phone and cash around. Is he a CIA agent? :) Anyone who DOESN'T have such things stashed away somewhere is, IMHO, incredibly naive and taking on quite a large amount of risk. The likelihood (and hope) is that you'll never need it. But on the off chance that you get f***ed by the legal system because of some power hungry, mouth-breather cop who can't/won't understand that you've done nothing wrong -- or worse, that you're easily provably within the law, but he "believes" that you're not and drags you through the process anyways -- you'll be very happy that you stashed away that old unlocked cell phone, old laptop, change of clothes and cash. I'm a (legal) firearms owner... up here in Canada, where some previous governments enacted extreme anti-gun legislation, that pretty much means that if I so much as sneeze in a way that a cop doesn't like, I can have my life ruined pretty damned fast (not quite, but really close). I wouldn't bet against me having an excrement-hitting-the-oscillator stash like this guy does. ;) (Note: I don't mean to imply that all cops are power hungry mouth-breathers intent on destroying the lives of citizens. Most cops are fundamentally good people and do a great job. But like every other profession, there ARE bad cops out there, and it's within the realm of possibility that you'll deal with one of them one day.) > Why would I donate to his legal defense when he has not been charged > yet? A little premature, no? > If you think that legal costs in a criminal case only start when you've been formally charged, you're grossly misinformed. At what point you personally decide to donate is one thing, but implying that someone doesn't need a defense fund prior to charges being laid is a bit naive about how the process works. - Pete From SNaslund at medline.com Fri Nov 30 21:55:39 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 15:55:39 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <50B7B519.8050608@localnet.com><2A76E400AC84B845AAC35AA19F8E7A5D0D711892@MUNEXBE1.medline.com><2A76E400AC84B845AAC35AA19F8E7A5D0D7118FD@MUNEXBE1.medline.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D711A9C@MUNEXBE1.medline.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7121B4@MUNEXBE1.medline.com> As a network professional do I not have a duty to protect my companies network from unauthorized access within my ability to do so? I think I do. If you lost all of your credit card and identity data because I left an open wifi hotspot on my network would you have a liability case? I sure think so. If I go into your building and plug in an open wifi hotspot that allows a hacker to gain access to your stuff, is that illegal? I think it is. In this case we are not talking about a civil claim of negligence at all. It is not even a civil case. Let's look at it more as the credibility of deniability. Grandma can claim in court that she had no idea that the neighborhood was using her wifi and be believable. I can't make that claim because it is easy to prove that I know better. Whether the act itself is legal is another matter, but the ability to deny knowledge of the act is the question. So, the way this translates is "Sir, did you know that a large percentage of Tor use is for illegal activities?" How does this guy answer no when he supposedly runs a large ISP? As far as the anonymous remailer, at that time sending anonymous email or spam was not yet illegal. Many ISPs began cracking down on open mail relays well before the CAN SPAM stuff came about because it was good business and most of the industry agreed that open mail relay was bad. What I find really interesting is that the ISP (in general, there are a few rogues) will immediately shut down access to an open mail relay being hosted by their customer because it enables SPAM, but would allow a Tor relay that allows lots of illegal activity. I can tell you exactly why this happens. Most network professionals hate spam, its inconvenience, its clogging of the systems we maintain, and we declared war on the spammers. Tor however enables a whole lot of "gray area" activities like media piracy, warez, and lots of other stuff that some of us are less concerned about (and some of us actually use). If the ISPs and engineers get concerned about any of this stuff, we are capable of killing it off easier than the law enforcement channels. We never eliminated SPAM but it was made a lot tougher. Unfortunately, the history of the public Internet shows that one of the technology drivers of higher and better connections are for things like media sharing and distribution which includes some not so savory or legal sharing and distribution and some not so nice media. Steven Naslund -----Original Message----- From: Michael Froomkin - U.Miami School of Law [mailto:froomkin at law.miami.edu] Sent: Thursday, November 29, 2012 6:30 PM To: Naslund, Steve Cc: NANOG Subject: RE: William was raided for running a Tor exit node. Please help if you can. On Thu, 29 Nov 2012, Naslund, Steve wrote: [...] > > When it comes to running an open access point, I think the legal issue > would be negligence. Is it negligence for the 90 year old grandma to > have an open AP (probably not, just didn't know better)? Is it > negligence for me to have an open AP (probably, I am a network > professional and know how to secure a network). > In order for there to be a civil claim of negligence there must be, inter alia, a breach of duty. What duty has been breached in your scenario? None. [...] > > This is certainly an interesting discussion and I think there are not > a lot of concrete answers since this is on the edge of technology law. > I Actually some of us have been teaching and writing about this stuff since the mid 1990s. These issues are far from new; we went through them in the early anonymous remailer days. -- A. Michael Froomkin, http://www.law.tm Blog: http://www.discourse.net Laurie Silvers & Mitchell Rubenstein Distinguished Professor of Law Editor, Jotwell: The Journal of Things We Like (Lots), jotwell.com U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | froomkin at law.tm -->It's warm here.<-- From cidr-report at potaroo.net Fri Nov 30 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Nov 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201211302200.qAUM00CN090198@wattle.apnic.net> This report has been generated at Fri Nov 30 21:13:10 2012 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 23-11-12 435758 251760 24-11-12 435405 251764 25-11-12 435562 251850 26-11-12 435722 251810 27-11-12 435517 251735 28-11-12 435718 251249 29-11-12 435488 251596 30-11-12 435823 252285 AS Summary 42843 Number of ASes in routing system 17809 Number of ASes announcing only one prefix 3196 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 114767072 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 30Nov12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 436867 252206 184661 42.3% All ASes AS6389 3145 152 2993 95.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2169 67 2102 96.9% NET Servicos de Comunicao S.A. AS4766 2942 918 2024 68.8% KIXS-AS-KR Korea Telecom AS17974 2431 540 1891 77.8% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3196 1450 1746 54.6% WINDSTREAM - Windstream Communications Inc AS18566 2083 423 1660 79.7% COVAD - Covad Communications Co. AS22773 1938 318 1620 83.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2261 653 1608 71.1% Telmex Colombia S.A. AS7303 1666 395 1271 76.3% Telecom Argentina S.A. AS4323 1595 400 1195 74.9% TWTC - tw telecom holdings, inc. AS4755 1625 539 1086 66.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1142 188 954 83.5% VIETEL-AS-AP Vietel Corporation AS8151 1610 703 907 56.3% Uninet S.A. de C.V. AS7545 1815 943 872 48.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 1017 173 844 83.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS1785 1934 1158 776 40.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1126 350 776 68.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 861 118 743 86.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS2118 784 85 699 89.2% RELCOM-AS OOO "NPO Relcom" AS855 707 52 655 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1116 499 617 55.3% LEVEL3 Level 3 Communications AS17676 704 88 616 87.5% GIGAINFRA Softbank BB Corp. AS22561 1040 430 610 58.7% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 1049 442 607 57.9% GBLX Global Crossing Ltd. AS24560 1040 440 600 57.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS19262 1004 405 599 59.7% VZGNI-TRANSIT - Verizon Online LLC AS36998 772 178 594 76.9% SDN-MOBITEL AS22047 579 22 557 96.2% VTR BANDA ANCHA S.A. AS4780 839 292 547 65.2% SEEDNET Digital United Inc. AS18881 596 49 547 91.8% Global Village Telecom Total 44786 12470 32316 72.2% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.213.138.0/24 AS33991 SKALA-AS Company Skala, Ltd 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.11.224.0/22 AS19829 WAVE-MAX Wave-Max S.r.L. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 Nov 30 22:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Nov 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201211302200.qAUM01N1090215@wattle.apnic.net> BGP Update Report Interval: 22-Nov-12 -to- 29-Nov-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS37113 100140 5.0% 2328.8 -- tangerine-ug-as 2 - AS37044 46614 2.3% 2330.7 -- Tangerine-AS 3 - AS8402 43314 2.2% 23.0 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS36915 39112 1.9% 1504.3 -- AFOL-KE-AS 5 - AS3909 38402 1.9% 9600.5 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - AS9829 33612 1.7% 41.5 -- BSNL-NIB National Internet Backbone 7 - AS35228 30715 1.5% 117.7 -- BEUNLIMITED Avatar Broadband Limited 8 - AS24757 25237 1.3% 467.4 -- EthioNet-AS 9 - AS29039 22891 1.1% 2543.4 -- AFRICAONLINE-UG Africa Online Uganda 10 - AS22561 22032 1.1% 1049.1 -- DIGITAL-TELEPORT - Digital Teleport Inc. 11 - AS10620 20644 1.0% 11.3 -- Telmex Colombia S.A. 12 - AS29049 14202 0.7% 43.0 -- DELTA-TELECOM-AS Delta Telecom LTD. 13 - AS29032 13570 0.7% 424.1 -- DATANET-UG DATANET LLC 14 - AS7922 13144 0.7% 1460.4 -- COMCAST-7922 - Comcast Cable Communications, Inc. 15 - AS21491 13083 0.7% 1189.4 -- UGANDA-TELECOM Uganda Telecom 16 - AS37048 12852 0.6% 918.0 -- Foris-Uganda 17 - AS2708 12204 0.6% 89.1 -- Universidad de Guanajuato 18 - AS9808 11887 0.6% 14.2 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 19 - AS13118 11121 0.6% 556.0 -- ASN-YARTELECOM OJSC Rostelecom 20 - AS43695 10630 0.5% 10630.0 -- LISNER_AS UNIQ LISNER Sp. z o.o. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS43695 10630 0.5% 10630.0 -- LISNER_AS UNIQ LISNER Sp. z o.o. 2 - AS3909 38402 1.9% 9600.5 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - AS24057 6660 0.3% 6660.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 4 - AS6629 8545 0.4% 4272.5 -- NOAA-AS - NOAA 5 - AS19406 4173 0.2% 4173.0 -- TWRS-MA - Towerstream I, Inc. 6 - AS2033 3822 0.2% 3822.0 -- PANIX - Panix Network Information Center 7 - AS29039 22891 1.1% 2543.4 -- AFRICAONLINE-UG Africa Online Uganda 8 - AS37115 2333 0.1% 2333.0 -- TMP-UG 9 - AS37044 46614 2.3% 2330.7 -- Tangerine-AS 10 - AS37113 100140 5.0% 2328.8 -- tangerine-ug-as 11 - AS14680 6902 0.3% 2300.7 -- REALE-6 - Auction.com 12 - AS37273 5777 0.3% 1925.7 -- BCS 13 - AS37156 9253 0.5% 1850.6 -- XTRANET 14 - AS57918 1740 0.1% 1740.0 -- ACOD-AS ACOD CJSC 15 - AS6197 1642 0.1% 1642.0 -- BATI-ATL - BellSouth Network Solutions, Inc 16 - AS36915 39112 1.9% 1504.3 -- AFOL-KE-AS 17 - AS7922 13144 0.7% 1460.4 -- COMCAST-7922 - Comcast Cable Communications, Inc. 18 - AS9950 2508 0.1% 1254.0 -- PUBNETPLUS2-AS-KR DACOM 19 - AS51122 1210 0.1% 1210.0 -- SIT-CORP-AS Sitronics, AO 20 - AS36529 2416 0.1% 1208.0 -- AXXA-RACKCO - Rackco.com TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.18.0/24 12818 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.255.0/24 12790 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.254.0/24 12790 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 184.159.130.0/23 10892 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 5 - 184.157.224.0/19 10824 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 6 - 93.181.254.0/23 10640 0.5% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 7 - 91.198.110.0/24 10630 0.5% AS43695 -- LISNER_AS UNIQ LISNER Sp. z o.o. 8 - 202.14.255.0/24 6660 0.3% AS24057 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 9 - 23.67.247.0/24 6541 0.3% AS7922 -- COMCAST-7922 - Comcast Cable Communications, Inc. 10 - 184.51.102.0/24 6537 0.3% AS7922 -- COMCAST-7922 - Comcast Cable Communications, Inc. 11 - 12.139.133.0/24 5626 0.3% AS14680 -- REALE-6 - Auction.com 12 - 203.28.157.0/24 5167 0.2% AS4802 -- ASN-IINET iiNet Limited 13 - 139.139.19.0/24 4939 0.2% AS1562 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 14 - 194.63.9.0/24 4636 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 15 - 192.58.232.0/24 4515 0.2% AS6629 -- NOAA-AS - NOAA 16 - 123.252.208.0/24 4446 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 17 - 49.248.72.0/21 4226 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 18 - 69.38.178.0/24 4173 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 19 - 192.58.2.0/24 4030 0.2% AS6629 -- NOAA-AS - NOAA 20 - 209.48.168.0/24 3822 0.2% AS2033 -- PANIX - Panix Network Information Center 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 SNaslund at medline.com Fri Nov 30 22:02:08 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 16:02:08 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B92ACC.70104@alter3d.ca> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> OK, there must be a lot more paranoid people out there than I thought there were. I personally don't have a "runaway kit" stashed away. I will get right on that. So when that "mouth breather cop" won't believe you are innocent, your answer is to grab your stuff and go on the lamb for awhile? I am sure he will let you out to go to the bank, get your stuff, and leave town. I think you have seen way to many movies. So if the cops show up at his door tomorrow and say "Here's all your stuff back, there was no evidence of a crime.", you are OK with this guys keeping the "defense fund"? Steve -----Original Message----- From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] Sent: Friday, November 30, 2012 3:53 PM To: nanog at nanog.org Subject: Re: William was raided for running a Tor exit node. Please help if you can. On 11/30/2012 04:01 PM, Naslund, Steve wrote: > I am a little concerned that this guy keeps a safe deposit box with > a burner phone and cash around. Is he a CIA agent? :) Anyone who DOESN'T have such things stashed away somewhere is, IMHO, incredibly naive and taking on quite a large amount of risk. The likelihood (and hope) is that you'll never need it. But on the off chance that you get f***ed by the legal system because of some power hungry, mouth-breather cop who can't/won't understand that you've done nothing wrong -- or worse, that you're easily provably within the law, but he "believes" that you're not and drags you through the process anyways -- you'll be very happy that you stashed away that old unlocked cell phone, old laptop, change of clothes and cash. I'm a (legal) firearms owner... up here in Canada, where some previous governments enacted extreme anti-gun legislation, that pretty much means that if I so much as sneeze in a way that a cop doesn't like, I can have my life ruined pretty damned fast (not quite, but really close). I wouldn't bet against me having an excrement-hitting-the-oscillator stash like this guy does. ;) (Note: I don't mean to imply that all cops are power hungry mouth-breathers intent on destroying the lives of citizens. Most cops are fundamentally good people and do a great job. But like every other profession, there ARE bad cops out there, and it's within the realm of possibility that you'll deal with one of them one day.) > Why would I donate to his legal defense when he has not been charged > yet? A little premature, no? > If you think that legal costs in a criminal case only start when you've been formally charged, you're grossly misinformed. At what point you personally decide to donate is one thing, but implying that someone doesn't need a defense fund prior to charges being laid is a bit naive about how the process works. - Pete From raysonlogin at gmail.com Fri Nov 30 22:02:46 2012 From: raysonlogin at gmail.com (Rayson Ho) Date: Fri, 30 Nov 2012 17:02:46 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: On Fri, Nov 30, 2012 at 4:46 PM, Jimmy Hess wrote: > If they had a qualified technician, they probably wouldn't be raiding > a TOR exit node in the first place; they would have investigated the > matter more thoroughly, and saved precious time. And what if the TOR exit node was in the cloud? Are they going to confiscate millions of servers just because a few of them were hosting child pornography?? (I am a believer of Cloud Computing, and in fact earlier this month we had a 10,000-node Grid Engine HPC cluster running in Amazon EC2: http://blogs.scalablelogic.com/2012/11/running-10000-node-grid-engine-cluster.html ) I believe most Cloud providers (Google, Amazon, IBM, etc) have some sort of disclaimer clause... but then one can get a VPN account easily too (there are many free ones as well)! So how could VPN, local coffee shops, and cloud providers protect themselves from this kind of non-sense?? Rayson ================================================== Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ > > -- > -JH > From tetherow at shwisp.net Fri Nov 30 22:04:32 2012 From: tetherow at shwisp.net (Sam Tetherow) Date: Fri, 30 Nov 2012 16:04:32 -0600 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> References: <20121130072505.GD9750@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> Message-ID: <50B92D70.7060403@shwisp.net> On 11/30/2012 03:30 PM, Naslund, Steve wrote: > WAIT A SECOND HERE!?!? > > I just read below that this guy runs a large ISP in Austria. I thought > his Tor node was hosted with an external provider. If he runs the ISP, > why would he not host his own server in house? I suppose there are > reasons but I can't think of one, especially if you feel so strongly > about this being your right. > > He talks about moving it to another ISP in the article interviewing him. > How about moving it to the large ISP you run? > > If he runs a large ISP he must not be very good at it if he needs our > donations to help him defend himself from a crime he has not been > charged with yet. Most of the guys I know that run large ISPs have > legal guys available to them. They could also come up with 10000EUR if > necessary. > > What is he going to do with this money if no charges are filed and they > give his gear back? If he believes that he is innocent of any crime > then he should be confident they won't find anything to charge him with, > right? > >>> If convicted i could face up to 6 years in jail, of course i do not >>> want that and i also want to try to set a legal base for running Tor >>> exit nodes in Austria or even the EU. >>> > Six years in jail for what? They didn't arrest you yet. How do you > know what the charges are? The cops must not be too worried about the > Tor node if they did not seize it. They seem a lot more interested in > his personal storage devices. He seems to have a lot of data at home, > not illegal (possibly) but I am wondering what it all might be. The > cops have a lot of looking around ahead of them. Seems awful worried > for a guy who claims to be innocent. I am wondering why he seems so > sure he will be charged that he is building a legal defense fund before > being arrested. > > >>> Sadly we have nothing like the EFF here that could help me in this >>> case by legal assistance, so i'm on my own and require a good > lawyer. >>> Thus i'm accepting donations for my legal expenses which i expect to >>> be around 5000-10000 EUR. > So you know how much it costs to defend a case with unknown charges and > without knowing if you will be arrested yet?!?!?! > > This whole thing sounds flakier with every new detail. > > Steven Naslund > > -----Original Message----- > From: Eugen Leitl [mailto:eugen at leitl.org] > Sent: Friday, November 30, 2012 1:25 AM > To: NANOG list > Subject: Re: [tor-talk] William was raided for running a Tor exit node. > Please help if you can. > > ----- Forwarded message from Asad Haider ----- > > From: Asad Haider > Date: Thu, 29 Nov 2012 19:37:24 +0000 > To: tor-talk at lists.torproject.org > Subject: Re: [tor-talk] William was raided for running a Tor exit node. > Please help if you can. > Reply-To: tor-talk at lists.torproject.org > > William will be posting a statement soon which will explain everything > that's happened and give a detailed account of events, along with > evidence including pictures showing the aftermath of the raid in his > apartment, as well as copies of the warrant and inventory of seized > items. > > He runs a large ISP in Austria and is a well respected member of the > community, a lot of us have already sent in donations. > > His blog is https://rdns.im/ and I'm guessing the statement will be > posted on there, I'll send everyone a link once it's finished being > written. > > On 29 November 2012 19:22, Eugen Leitl wrote: > >> ----- Forwarded message from Emily Ozols ----- >> >> From: Emily Ozols >> Date: Fri, 30 Nov 2012 01:14:08 +1100 >> To: nanog at nanog.org >> Subject: Re: William was raided for running a Tor exit node. Please > help if >> you can. >> >> Hi, >> >> I gotta ask and I'm sure someone would if I didn't, but how do we know >> this guy is legit? >> He's jumped up on a forum saying, "Hey, police raided me, help. gib >> mone plz" and failed to provide and reason as to how he's real and not >> just making it up. >> >> Maybe if there's a way to know this guy is legit, I'll help out if >> possible, but until then I'm just going to watch others with caution >> and I suggest others do as well. >> >> On Fri, Nov 30, 2012 at 12:04 AM, Chris wrote: >>> I'm not William and a friend pasted a link on IRC to me. I'm going >>> to send him a few bucks because I know how it feels to get >>> blindsided by the police on one random day and your world is turned > upside down. >>> Source: >> http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exi >> t-accepting-donations-for-legal-expenses >>> From the URL: >>> >>> Yes, it happened to me now as well - Yesterday i got raided for >>> someone sharing child pornography over one of my Tor exits. >>> I'm good so far, not in jail, but all my computers and hardware have >>> been confiscated. >>> (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) >>> >>> If convicted i could face up to 6 years in jail, of course i do not >>> want that and i also want to try to set a legal base for running Tor >>> exit nodes in Austria or even the EU. >>> >>> Sadly we have nothing like the EFF here that could help me in this >>> case by legal assistance, so i'm on my own and require a good > lawyer. >>> Thus i'm accepting donations for my legal expenses which i expect to >>> be around 5000-10000 EUR. >>> >>> If you can i would appreciate if you could donate a bit (every >>> amount helps, even the smallest) either by PayPal (any currency is > ok): >> https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZ >> NBBD7EH4 >>> Or by Bank Transfer (EUR only please): >>> >>> Holder: William Weber >>> Bank: EasyBank AG (Vienna, Austria) >>> Account: 20011351213 >>> Bank sort number: 14200 >>> IBAN: AT031420020011351213 >>> BIC: EASYATW1 >>> >>> I will try to pay them back when i'm out of this (or even before) >>> but i can obviously not guarantee this, please keep this in mind. >>> This money will only be used for legal expenses related to this > case. >>> If you have any questions or want to donate by another way >>> (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel >>> free to send me a mail (william at william.si) or a PM, or contact me >>> in LET IRC. >>> >>> Thanks! >>> William >>> >>> >>> >>> >>> -- >>> --C >>> >>> "The dumber people think you are, the more surprised they're going >>> to be when you kill them." - Sir William Clayton >>> >> >> >> -- >> ~Em >> >> ----- End forwarded message ----- >> -- >> Eugen* Leitl leitl http://leitl.org >> ______________________________________________________________ >> ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org >> 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE >> _______________________________________________ >> tor-talk mailing list >> tor-talk at lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> > _______________________________________________ > tor-talk mailing list > tor-talk at lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > From SNaslund at medline.com Fri Nov 30 22:09:21 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 16:09:21 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7121E6@MUNEXBE1.medline.com> >From: Jimmy Hess [mailto:mysidia at gmail.com] >Sent: Friday, November 30, 2012 3:47 PM >To: William Herrin >Cc: NANOG list >Subject: Re: William was raided for running a Tor exit node. Please help if you can. >On 11/29/12, William Herrin wrote: >> If the computer at IP:port:timestamp transmitted child porn, a warrant >> for "all computers" is also too broad. "Computers which use said IP >As you know, there may always be some uncertainty about which computer was using a certain IP address at a certain time -- the computer >assigned that address might have been off, with a deviant >individual spoofing MAC address and IP address of a certain computer, using different equipment still attached to the same physical LAN. >Their warrant authors will probably not say "all computers"; they will more likely say something like all digital storage media, and equipment >required for access. Funny thing is they hit his residence, not the location where the Tor server was located. Most likely they tracked the Tor server's IP to an account at the ISP that hosted it, that pointed at his residence. Strange that they did not seize the server itself according to the interview of the guy involved. >Which includes all hard drives, SSDs, CF cards, diskettes, CDRs, and all the computing equipment they are installed in (keyboard, monitor, mouse, >etc) normally used to access the media. Probably said all computing equipment and media on the premise. That is extremely common language for these warrants. I have never, ever, heard of a seizure that only involved a single IP address. The cops know that media moves around. >> address or which employ forensic countermeasures which prevent a ready >> determination whether they employed said IP address." And have a >DHCP? >> qualified technician on the search team, same as you would for any >> other material being searched. >If they had a qualified technician, they probably wouldn't be raiding >a TOR exit node in the first place; they would have investigated the >matter more thoroughly, and saved precious time. > Remember, they did not raid the Tor exit node. They raided the home of the guy running the Tor exit node. Way different. >-- >-JH Steven Naslund From EWieling at nyigc.com Fri Nov 30 22:11:47 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Fri, 30 Nov 2012 17:11:47 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B92ACC.70104@alter3d.ca> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> Message-ID: <616B4ECE1290D441AD56124FEBB03D080B72FB5CAA@mailserver2007.nyigc.globe> >-----Original Message----- >From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] >Sent: Friday, November 30, 2012 4:53 PM >To: nanog at nanog.org >Subject: Re: William was raided for running a Tor exit node. Please help if you can. > > (Note: I don't mean to imply that all cops are power hungry >mouth-breathers intent on destroying the lives of citizens. Most cops >are fundamentally good people and do a great job. But like every other profession, there ARE bad cops out there, and it's within the realm of possibility that you'll deal with one of them one day.) Power corrupts and cops have power. What scares me is that there is no way *I* can tell the difference between a cop who accepts free coffee from the local caf? and a cop who will lie to get what they want. From wbailey at satelliteintelligencegroup.com Fri Nov 30 22:12:13 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 30 Nov 2012 22:12:13 +0000 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> Message-ID: <8200F04ED2C5EF40B246388AD4B822A512D5C5F7@BL2PRD0512MB662.namprd05.prod.outlook.com> When is the last time you were arrested, or even in a legal situation which required your attention as a defendant? It seems pretty straight forward, but I can assure you this guy is getting very little sleep and his heart is beating out of his chest. Granted this entire situation is taking place in a legal venue which I have no understanding of (The EU obviously does things differently). I think it was pretty risky to consider running a Tor node, much less being involved in running multiple nodes. This entire situation is beginning to read like a Kim DotCom (or Schmitz for those of us who worked for him at some point) novel, where an outside force directed a local LEA to perform some kind of raid to get someone's attention. This was obviously not a helicopter raid with SWAT, ala RapidShare, but I hope you get the point. This guy is sweating bullets because he has no idea what is going to happen next (in my humble opinion), so his rational thought process and/or even discussing when he will return the funds donated is a pre-mature at best. Just my .02. On 11/30/12 1:30 PM, "Naslund, Steve" wrote: >WAIT A SECOND HERE!?!? > >I just read below that this guy runs a large ISP in Austria. I thought >his Tor node was hosted with an external provider. If he runs the ISP, >why would he not host his own server in house? I suppose there are >reasons but I can't think of one, especially if you feel so strongly >about this being your right. > >He talks about moving it to another ISP in the article interviewing him. >How about moving it to the large ISP you run? > >If he runs a large ISP he must not be very good at it if he needs our >donations to help him defend himself from a crime he has not been >charged with yet. Most of the guys I know that run large ISPs have >legal guys available to them. They could also come up with 10000EUR if >necessary. > >What is he going to do with this money if no charges are filed and they >give his gear back? If he believes that he is innocent of any crime >then he should be confident they won't find anything to charge him with, >right? > >> > If convicted i could face up to 6 years in jail, of course i do not >> > want that and i also want to try to set a legal base for running Tor > >> > exit nodes in Austria or even the EU. >> > > >Six years in jail for what? They didn't arrest you yet. How do you >know what the charges are? The cops must not be too worried about the >Tor node if they did not seize it. They seem a lot more interested in >his personal storage devices. He seems to have a lot of data at home, >not illegal (possibly) but I am wondering what it all might be. The >cops have a lot of looking around ahead of them. Seems awful worried >for a guy who claims to be innocent. I am wondering why he seems so >sure he will be charged that he is building a legal defense fund before >being arrested. > > >> > Sadly we have nothing like the EFF here that could help me in this >> > case by legal assistance, so i'm on my own and require a good >lawyer. >> > Thus i'm accepting donations for my legal expenses which i expect to > >> > be around 5000-10000 EUR. > >So you know how much it costs to defend a case with unknown charges and >without knowing if you will be arrested yet?!?!?! > >This whole thing sounds flakier with every new detail. > >Steven Naslund > >-----Original Message----- >From: Eugen Leitl [mailto:eugen at leitl.org] >Sent: Friday, November 30, 2012 1:25 AM >To: NANOG list >Subject: Re: [tor-talk] William was raided for running a Tor exit node. >Please help if you can. > >----- Forwarded message from Asad Haider ----- > >From: Asad Haider >Date: Thu, 29 Nov 2012 19:37:24 +0000 >To: tor-talk at lists.torproject.org >Subject: Re: [tor-talk] William was raided for running a Tor exit node. > Please help if you can. >Reply-To: tor-talk at lists.torproject.org > >William will be posting a statement soon which will explain everything >that's happened and give a detailed account of events, along with >evidence including pictures showing the aftermath of the raid in his >apartment, as well as copies of the warrant and inventory of seized >items. > >He runs a large ISP in Austria and is a well respected member of the >community, a lot of us have already sent in donations. > >His blog is https://rdns.im/ and I'm guessing the statement will be >posted on there, I'll send everyone a link once it's finished being >written. > >On 29 November 2012 19:22, Eugen Leitl wrote: > >> ----- Forwarded message from Emily Ozols ----- >> >> From: Emily Ozols >> Date: Fri, 30 Nov 2012 01:14:08 +1100 >> To: nanog at nanog.org >> Subject: Re: William was raided for running a Tor exit node. Please >help if >> you can. >> >> Hi, >> >> I gotta ask and I'm sure someone would if I didn't, but how do we know > >> this guy is legit? >> He's jumped up on a forum saying, "Hey, police raided me, help. gib >> mone plz" and failed to provide and reason as to how he's real and not > >> just making it up. >> >> Maybe if there's a way to know this guy is legit, I'll help out if >> possible, but until then I'm just going to watch others with caution >> and I suggest others do as well. >> >> On Fri, Nov 30, 2012 at 12:04 AM, Chris wrote: >> > I'm not William and a friend pasted a link on IRC to me. I'm going >> > to send him a few bucks because I know how it feels to get >> > blindsided by the police on one random day and your world is turned >upside down. >> > >> > Source: >> http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exi >> t-accepting-donations-for-legal-expenses >> > >> > From the URL: >> > >> > Yes, it happened to me now as well - Yesterday i got raided for >> > someone sharing child pornography over one of my Tor exits. >> > I'm good so far, not in jail, but all my computers and hardware have > >> > been confiscated. >> > (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) >> > >> > If convicted i could face up to 6 years in jail, of course i do not >> > want that and i also want to try to set a legal base for running Tor > >> > exit nodes in Austria or even the EU. >> > >> > Sadly we have nothing like the EFF here that could help me in this >> > case by legal assistance, so i'm on my own and require a good >lawyer. >> > Thus i'm accepting donations for my legal expenses which i expect to > >> > be around 5000-10000 EUR. >> > >> > If you can i would appreciate if you could donate a bit (every >> > amount helps, even the smallest) either by PayPal (any currency is >ok): >> > >> https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4LZ >> NBBD7EH4 >> > >> > Or by Bank Transfer (EUR only please): >> > >> > Holder: William Weber >> > Bank: EasyBank AG (Vienna, Austria) >> > Account: 20011351213 >> > Bank sort number: 14200 >> > IBAN: AT031420020011351213 >> > BIC: EASYATW1 >> > >> > I will try to pay them back when i'm out of this (or even before) >> > but i can obviously not guarantee this, please keep this in mind. >> > This money will only be used for legal expenses related to this >case. >> > >> > If you have any questions or want to donate by another way >> > (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel >> > free to send me a mail (william at william.si) or a PM, or contact me >> > in LET IRC. >> > >> > Thanks! >> > William >> > >> > >> > >> > >> > -- >> > --C >> > >> > "The dumber people think you are, the more surprised they're going >> > to be when you kill them." - Sir William Clayton >> > >> >> >> >> -- >> ~Em >> >> ----- End forwarded message ----- >> -- >> Eugen* Leitl leitl http://leitl.org >> ______________________________________________________________ >> ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org >> 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE >> _______________________________________________ >> tor-talk mailing list >> tor-talk at lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> >_______________________________________________ >tor-talk mailing list >tor-talk at lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > >----- End forwarded message ----- >-- >Eugen* Leitl leitl http://leitl.org >______________________________________________________________ >ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org >8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > > From SNaslund at medline.com Fri Nov 30 22:15:54 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 16:15:54 -0600 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <8200F04ED2C5EF40B246388AD4B822A512D5C5F7@BL2PRD0512MB662.namprd05.prod.outlook.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> <8200F04ED2C5EF40B246388AD4B822A512D5C5F7@BL2PRD0512MB662.namprd05.prod.outlook.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D712204@MUNEXBE1.medline.com> Well, in that case.... I am really worried that the cops might charge me with a crime. They took my computers and are looking at them. I did not do anything wrong but just in case they decide to charge me with a crime, please send me some money. Thanks, Steven Naslund -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Friday, November 30, 2012 4:12 PM To: Naslund, Steve; NANOG list Subject: Re: [tor-talk] William was raided for running a Tor exit node. Please help if you can. When is the last time you were arrested, or even in a legal situation which required your attention as a defendant? It seems pretty straight forward, but I can assure you this guy is getting very little sleep and his heart is beating out of his chest. Granted this entire situation is taking place in a legal venue which I have no understanding of (The EU obviously does things differently). I think it was pretty risky to consider running a Tor node, much less being involved in running multiple nodes. This entire situation is beginning to read like a Kim DotCom (or Schmitz for those of us who worked for him at some point) novel, where an outside force directed a local LEA to perform some kind of raid to get someone's attention. This was obviously not a helicopter raid with SWAT, ala RapidShare, but I hope you get the point. This guy is sweating bullets because he has no idea what is going to happen next (in my humble opinion), so his rational thought process and/or even discussing when he will return the funds donated is a pre-mature at best. Just my .02. On 11/30/12 1:30 PM, "Naslund, Steve" wrote: >WAIT A SECOND HERE!?!? > >I just read below that this guy runs a large ISP in Austria. I thought >his Tor node was hosted with an external provider. If he runs the ISP, >why would he not host his own server in house? I suppose there are >reasons but I can't think of one, especially if you feel so strongly >about this being your right. > >He talks about moving it to another ISP in the article interviewing him. >How about moving it to the large ISP you run? > >If he runs a large ISP he must not be very good at it if he needs our >donations to help him defend himself from a crime he has not been >charged with yet. Most of the guys I know that run large ISPs have >legal guys available to them. They could also come up with 10000EUR if >necessary. > >What is he going to do with this money if no charges are filed and they >give his gear back? If he believes that he is innocent of any crime >then he should be confident they won't find anything to charge him >with, right? > >> > If convicted i could face up to 6 years in jail, of course i do not >> > want that and i also want to try to set a legal base for running >> > Tor > >> > exit nodes in Austria or even the EU. >> > > >Six years in jail for what? They didn't arrest you yet. How do you >know what the charges are? The cops must not be too worried about the >Tor node if they did not seize it. They seem a lot more interested in >his personal storage devices. He seems to have a lot of data at home, >not illegal (possibly) but I am wondering what it all might be. The >cops have a lot of looking around ahead of them. Seems awful worried >for a guy who claims to be innocent. I am wondering why he seems so >sure he will be charged that he is building a legal defense fund before >being arrested. > > >> > Sadly we have nothing like the EFF here that could help me in this >> > case by legal assistance, so i'm on my own and require a good >lawyer. >> > Thus i'm accepting donations for my legal expenses which i expect >> > to > >> > be around 5000-10000 EUR. > >So you know how much it costs to defend a case with unknown charges and >without knowing if you will be arrested yet?!?!?! > >This whole thing sounds flakier with every new detail. > >Steven Naslund > >-----Original Message----- >From: Eugen Leitl [mailto:eugen at leitl.org] >Sent: Friday, November 30, 2012 1:25 AM >To: NANOG list >Subject: Re: [tor-talk] William was raided for running a Tor exit node. >Please help if you can. > >----- Forwarded message from Asad Haider ----- > >From: Asad Haider >Date: Thu, 29 Nov 2012 19:37:24 +0000 >To: tor-talk at lists.torproject.org >Subject: Re: [tor-talk] William was raided for running a Tor exit node. > Please help if you can. >Reply-To: tor-talk at lists.torproject.org > >William will be posting a statement soon which will explain everything >that's happened and give a detailed account of events, along with >evidence including pictures showing the aftermath of the raid in his >apartment, as well as copies of the warrant and inventory of seized >items. > >He runs a large ISP in Austria and is a well respected member of the >community, a lot of us have already sent in donations. > >His blog is https://rdns.im/ and I'm guessing the statement will be >posted on there, I'll send everyone a link once it's finished being >written. > >On 29 November 2012 19:22, Eugen Leitl wrote: > >> ----- Forwarded message from Emily Ozols >> ----- >> >> From: Emily Ozols >> Date: Fri, 30 Nov 2012 01:14:08 +1100 >> To: nanog at nanog.org >> Subject: Re: William was raided for running a Tor exit node. Please >help if >> you can. >> >> Hi, >> >> I gotta ask and I'm sure someone would if I didn't, but how do we >> know > >> this guy is legit? >> He's jumped up on a forum saying, "Hey, police raided me, help. gib >> mone plz" and failed to provide and reason as to how he's real and >> not > >> just making it up. >> >> Maybe if there's a way to know this guy is legit, I'll help out if >> possible, but until then I'm just going to watch others with caution >> and I suggest others do as well. >> >> On Fri, Nov 30, 2012 at 12:04 AM, Chris wrote: >> > I'm not William and a friend pasted a link on IRC to me. I'm going >> > to send him a few bucks because I know how it feels to get >> > blindsided by the police on one random day and your world is turned >upside down. >> > >> > Source: >> http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-ex >> i t-accepting-donations-for-legal-expenses >> > >> > From the URL: >> > >> > Yes, it happened to me now as well - Yesterday i got raided for >> > someone sharing child pornography over one of my Tor exits. >> > I'm good so far, not in jail, but all my computers and hardware >> > have > >> > been confiscated. >> > (20 computers, 100TB+ storage, My Tablets/Consoles/Phones) >> > >> > If convicted i could face up to 6 years in jail, of course i do not >> > want that and i also want to try to set a legal base for running >> > Tor > >> > exit nodes in Austria or even the EU. >> > >> > Sadly we have nothing like the EFF here that could help me in this >> > case by legal assistance, so i'm on my own and require a good >lawyer. >> > Thus i'm accepting donations for my legal expenses which i expect >> > to > >> > be around 5000-10000 EUR. >> > >> > If you can i would appreciate if you could donate a bit (every >> > amount helps, even the smallest) either by PayPal (any currency is >ok): >> > >> https://paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2Q4L >> Z >> NBBD7EH4 >> > >> > Or by Bank Transfer (EUR only please): >> > >> > Holder: William Weber >> > Bank: EasyBank AG (Vienna, Austria) >> > Account: 20011351213 >> > Bank sort number: 14200 >> > IBAN: AT031420020011351213 >> > BIC: EASYATW1 >> > >> > I will try to pay them back when i'm out of this (or even before) >> > but i can obviously not guarantee this, please keep this in mind. >> > This money will only be used for legal expenses related to this >case. >> > >> > If you have any questions or want to donate by another way >> > (MoneyBookers, Webmoney, Bitcoin, Liberty Reserve, Neteller) feel >> > free to send me a mail (william at william.si) or a PM, or contact me >> > in LET IRC. >> > >> > Thanks! >> > William >> > >> > >> > >> > >> > -- >> > --C >> > >> > "The dumber people think you are, the more surprised they're going >> > to be when you kill them." - Sir William Clayton >> > >> >> >> >> -- >> ~Em >> >> ----- End forwarded message ----- >> -- >> Eugen* Leitl leitl http://leitl.org >> ______________________________________________________________ >> ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org >> 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE >> _______________________________________________ >> tor-talk mailing list >> tor-talk at lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> >_______________________________________________ >tor-talk mailing list >tor-talk at lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > >----- End forwarded message ----- >-- >Eugen* Leitl leitl http://leitl.org >______________________________________________________________ >ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org >8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > > From nanog at afxr.net Fri Nov 30 22:18:11 2012 From: nanog at afxr.net (Randy) Date: Fri, 30 Nov 2012 16:18:11 -0600 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <1354289940815-019-01077594.sclark.netwolves.com@sclark66.netwolves.com> References: <50AB49EA.3030101@cis.vutbr.cz> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> <1354289940815-019-01077594.sclark.netwolves.com@sclark66.netwolves.com> Message-ID: <50B930A3.7030005@afxr.net> - Well I want to add my 10 cents, I am a c++ programmer, and have been waiting for my isp to offer native ipv6 for ever. I got fed up with waiting and setup a ipv6 over ipv4 tunnel. So once I got that done, I spent only an hour updating my socket classes to support ipv6. I hadent done so before because I never had ipv6 access, * I don't release code without testing it first *. It wasn't difficult to update to ipv6, only some reading was needed, don't know what the fuss is =D From alter3d at alter3d.ca Fri Nov 30 22:20:40 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 30 Nov 2012 17:20:40 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> Message-ID: <50B93138.3020003@alter3d.ca> I didn't say anything about trying to run away. That probably won't accomplish a whole lot in the long run. But when all of your bank accounts and credit cards are frozen, and your house is a crime scene, at least you have the means to rent a hotel room, contact family/lawyers, etc. And no, I'm not OK with people keeping any money that was donated for a specific purpose in excess of what was actually used. You'd hope that he'd be a good guy about it and give back the portion that wasn't used, or clearly state that any excess will go to charity or something. However, there's no such guarantee (short of doing it through a trust fund with his lawyer), and just like any philanthropic venture, it's up to each donor choose when/if they'll help out. It's just like Kickstarter -- you hope to get something good out of it, but if it bombs, well... you pay your money and you take your chances. - Pete On 11/30/2012 05:02 PM, Naslund, Steve wrote: > OK, there must be a lot more paranoid people out there than I thought > there were. I personally don't have a "runaway kit" stashed away. I > will get right on that. So when that "mouth breather cop" won't believe > you are innocent, your answer is to grab your stuff and go on the lamb > for awhile? I am sure he will let you out to go to the bank, get your > stuff, and leave town. I think you have seen way to many movies. > > So if the cops show up at his door tomorrow and say "Here's all your > stuff back, there was no evidence of a crime.", you are OK with this > guys keeping the "defense fund"? > > Steve > > -----Original Message----- > From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] > Sent: Friday, November 30, 2012 3:53 PM > To: nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. Please help > if you can. > > > On 11/30/2012 04:01 PM, Naslund, Steve wrote: >> I am a little concerned that this guy keeps a safe deposit box with >> a burner phone and cash around. Is he a CIA agent? :) > Anyone who DOESN'T have such things stashed away somewhere is, IMHO, > incredibly naive and taking on quite a large amount of risk. > > The likelihood (and hope) is that you'll never need it. But on the off > chance that you get f***ed by the legal system because of some power > hungry, mouth-breather cop who can't/won't understand that you've done > nothing wrong -- or worse, that you're easily provably within the law, > but he "believes" that you're not and drags you through the process > anyways -- you'll be very happy that you stashed away that old unlocked > cell phone, old laptop, change of clothes and cash. > > I'm a (legal) firearms owner... up here in Canada, where some previous > governments enacted extreme anti-gun legislation, that pretty much means > that if I so much as sneeze in a way that a cop doesn't like, I can have > my life ruined pretty damned fast (not quite, but really close). I > wouldn't bet against me having an excrement-hitting-the-oscillator stash > like this guy does. ;) > > (Note: I don't mean to imply that all cops are power hungry > mouth-breathers intent on destroying the lives of citizens. Most cops > are fundamentally good people and do a great job. But like every other > profession, there ARE bad cops out there, and it's within the realm of > possibility that you'll deal with one of them one day.) > >> Why would I donate to his legal defense when he has not been charged >> yet? A little premature, no? >> > If you think that legal costs in a criminal case only start when you've > been formally charged, you're grossly misinformed. At what point you > personally decide to donate is one thing, but implying that someone > doesn't need a defense fund prior to charges being laid is a bit naive > about how the process works. > > - Pete > > > From bill at herrin.us Fri Nov 30 22:20:33 2012 From: bill at herrin.us (William Herrin) Date: Fri, 30 Nov 2012 17:20:33 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: On Fri, Nov 30, 2012 at 4:46 PM, Jimmy Hess wrote: > On 11/29/12, William Herrin wrote: >> If the computer at IP:port:timestamp transmitted child porn, a warrant >> for "all computers" is also too broad. "Computers which use said IP > > As you know, there may always be some uncertainty about which computer > was using a certain IP address at a certain time -- the computer > assigned that address might have been off, with a deviant Or more likely behind a NAT device where the address which presents is the NAT device. But the police won't know that until they search. Until they search they have no factual basis for the presumptions either that more than one computer was associated with the activity or that it isn't possible to readily identify which computer was involved. That Tor node was probably on a static IP address and was probably on the same static IP address at the time of the alleged activity. "Reasonable suspicion" doesn't mean Bob thinks you did it, it means that there's a trail of facts which lead *directly* to the evidence you seek permission to seize. The trail to child porn doesn't include the right to seize the stack of John Denver music and while it might include the right to search the shelf of DVDs it doesn't include the right to seize the ones produced by Disney. The right to search your computer and the right to seize it are not at all the same thing. Practically speaking, right now the police are going to seize all your computers. But keep watching. Some time in the next decade or two warrants will start to get quashed for failing to specify (by parameters) *which* computer they were looking for. As computers become more central to our lives it will probably come out that they have the right to duplicate your hard drives and other read/write media but don't have a right to take the originals unless they observe warrant-covered material *on* the computer while searching. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From SNaslund at medline.com Fri Nov 30 22:31:39 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 16:31:39 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <616B4ECE1290D441AD56124FEBB03D080B72FB5CAA@mailserver2007.nyigc.globe> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <616B4ECE1290D441AD56124FEBB03D080B72FB5CAA@mailserver2007.nyigc.globe> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D712224@MUNEXBE1.medline.com> Guess who has power over the networks and Internet. We do and power corrupts us too. There are some bad guy ISPs and engineers out there too. Just because you are running a Tor server to allow for "privacy protection" does not mean you were never doing anything illegal through it. I know this is not true in all cases but a lot of times the guy who screams the most about privacy has something to hide. Do you like getting phone calls with blocked callerID? Do you like getting anonymous SPAM? Do you mind having anonymously sourced pics of your kids going out over the internet? One guys privacy is sometimes an invasion of mine. If this guy is so distraught over this case maybe he should have ensured that he had the resources to defend himself before he put up the multiple exit nodes. There are test cases all the time, but if you want to be the test case you should be prepared. How many of us have killed an open mail relay (did you have a warrant before you interrupted that good Samaritan providing that free mail server to the poor downtrodden email-less masses...you are not even a cop and did not have a judge review your actions..how dare you...)? Steven Naslund -----Original Message----- From: Eric Wieling [mailto:EWieling at nyigc.com] Sent: Friday, November 30, 2012 4:12 PM To: nanog at nanog.org Subject: RE: William was raided for running a Tor exit node. Please help if you can. >-----Original Message----- >From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] >Sent: Friday, November 30, 2012 4:53 PM >To: nanog at nanog.org >Subject: Re: William was raided for running a Tor exit node. Please help if you can. > > (Note: I don't mean to imply that all cops are power hungry >mouth-breathers intent on destroying the lives of citizens. Most cops >are fundamentally good people and do a great job. But like every other profession, there ARE bad cops out there, and it's within the realm of possibility that you'll deal with one of them one day.) Power corrupts and cops have power. What scares me is that there is no way *I* can tell the difference between a cop who accepts free coffee from the local caf? and a cop who will lie to get what they want. From bill at herrin.us Fri Nov 30 22:35:57 2012 From: bill at herrin.us (William Herrin) Date: Fri, 30 Nov 2012 17:35:57 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50B930A3.7030005@afxr.net> References: <50AB49EA.3030101@cis.vutbr.cz> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> <1354289940815-019-01077594.sclark.netwolves.com@sclark66.netwolves.com> <50B930A3.7030005@afxr.net> Message-ID: On Fri, Nov 30, 2012 at 5:18 PM, Randy wrote: > - > Well I want to add my 10 cents, > I am a c++ programmer, and have been waiting for my isp to offer native ipv6 > for ever. I got fed up with waiting and setup a ipv6 over ipv4 tunnel. So > once I got that done, I spent only an hour updating my socket classes to > support ipv6. I hadent done so before because I never had ipv6 access, * I > don't release code without testing it first *. > > It wasn't difficult to update to ipv6, only some reading was needed, don't > know what the fuss is =D Go test it against a dual stack remote host with the Tunnel's addresses still configured on your hosts but packet filtering set to silently drop packets on the IPv6 tunnel. Then work through the implications of what you observe. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From SNaslund at medline.com Fri Nov 30 22:37:16 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 16:37:16 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B93138.3020003@alter3d.ca> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50B93138.3020003@alter3d.ca> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D71223B@MUNEXBE1.medline.com> OK, I get it. I think my BS detector is set to high today. I am just really suspicious that this guy that runs an large ISP can't at least wait until there are charges before all the uproar. I think if the cops came and seized my home PCs right now I would probably give them the time to look at them, realize there is nothing there, and give them back to me before freaking out completely. I would be wondering what was going on but probably not raising a defense fund. Steve -----Original Message----- From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] Sent: Friday, November 30, 2012 4:21 PM To: nanog at nanog.org Subject: Re: William was raided for running a Tor exit node. Please help if you can. I didn't say anything about trying to run away. That probably won't accomplish a whole lot in the long run. But when all of your bank accounts and credit cards are frozen, and your house is a crime scene, at least you have the means to rent a hotel room, contact family/lawyers, etc. And no, I'm not OK with people keeping any money that was donated for a specific purpose in excess of what was actually used. You'd hope that he'd be a good guy about it and give back the portion that wasn't used, or clearly state that any excess will go to charity or something. However, there's no such guarantee (short of doing it through a trust fund with his lawyer), and just like any philanthropic venture, it's up to each donor choose when/if they'll help out. It's just like Kickstarter -- you hope to get something good out of it, but if it bombs, well... you pay your money and you take your chances. - Pete On 11/30/2012 05:02 PM, Naslund, Steve wrote: > OK, there must be a lot more paranoid people out there than I thought > there were. I personally don't have a "runaway kit" stashed away. I > will get right on that. So when that "mouth breather cop" won't > believe you are innocent, your answer is to grab your stuff and go on > the lamb for awhile? I am sure he will let you out to go to the bank, > get your stuff, and leave town. I think you have seen way to many movies. > > So if the cops show up at his door tomorrow and say "Here's all your > stuff back, there was no evidence of a crime.", you are OK with this > guys keeping the "defense fund"? > > Steve > > -----Original Message----- > From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] > Sent: Friday, November 30, 2012 3:53 PM > To: nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. Please > help if you can. > > > On 11/30/2012 04:01 PM, Naslund, Steve wrote: >> I am a little concerned that this guy keeps a safe deposit box >> with a burner phone and cash around. Is he a CIA agent? :) > Anyone who DOESN'T have such things stashed away somewhere is, IMHO, > incredibly naive and taking on quite a large amount of risk. > > The likelihood (and hope) is that you'll never need it. But on the > off chance that you get f***ed by the legal system because of some > power hungry, mouth-breather cop who can't/won't understand that > you've done nothing wrong -- or worse, that you're easily provably > within the law, but he "believes" that you're not and drags you > through the process anyways -- you'll be very happy that you stashed > away that old unlocked cell phone, old laptop, change of clothes and cash. > > I'm a (legal) firearms owner... up here in Canada, where some previous > governments enacted extreme anti-gun legislation, that pretty much > means that if I so much as sneeze in a way that a cop doesn't like, I > can have my life ruined pretty damned fast (not quite, but really > close). I wouldn't bet against me having an > excrement-hitting-the-oscillator stash like this guy does. ;) > > (Note: I don't mean to imply that all cops are power hungry > mouth-breathers intent on destroying the lives of citizens. Most cops > are fundamentally good people and do a great job. But like every > other profession, there ARE bad cops out there, and it's within the > realm of possibility that you'll deal with one of them one day.) > >> Why would I donate to his legal defense when he has not been charged >> yet? A little premature, no? >> > If you think that legal costs in a criminal case only start when you've > been formally charged, you're grossly misinformed. At what point you > personally decide to donate is one thing, but implying that someone > doesn't need a defense fund prior to charges being laid is a bit naive > about how the process works. > > - Pete > > > From SNaslund at medline.com Fri Nov 30 22:44:50 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 16:44:50 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D712251@MUNEXBE1.medline.com> I might be reading this the wrong way but it looked to me like the cops raided his home and the Tor server is hosted off site with an ISP. That is what is bugging me so much. The cops raided his house, not the location of the server. If they had tracked the server by its IP it would have led to the hoster, not his home. They could have gotten his address as the account holder but the ISP would have known that the Tor server was at their site not his home. The IP would not track to his residence. Something is not the full story here or I am misreading his interview. I have seen some of the warrants due to child porn cases. They tend to be very sweeping and usually specify recordable media and data processing equipment. That is admittedly broad but the cops usually do not have forensic computer guys on site so they try to grab it all. It is not right but that is how it currently works. Anything else requires the expertise on site to search the equipment where it is. Most cops don't know a PC from a router, from a switch. It all goes. Steven Naslund -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Friday, November 30, 2012 4:21 PM To: Jimmy Hess Cc: NANOG list Subject: Re: William was raided for running a Tor exit node. Please help if you can. On Fri, Nov 30, 2012 at 4:46 PM, Jimmy Hess wrote: > On 11/29/12, William Herrin wrote: >> If the computer at IP:port:timestamp transmitted child porn, a >> warrant for "all computers" is also too broad. "Computers which use >> said IP > > As you know, there may always be some uncertainty about which computer > was using a certain IP address at a certain time -- the computer > assigned that address might have been off, with a deviant Or more likely behind a NAT device where the address which presents is the NAT device. But the police won't know that until they search. Until they search they have no factual basis for the presumptions either that more than one computer was associated with the activity or that it isn't possible to readily identify which computer was involved. That Tor node was probably on a static IP address and was probably on the same static IP address at the time of the alleged activity. "Reasonable suspicion" doesn't mean Bob thinks you did it, it means that there's a trail of facts which lead *directly* to the evidence you seek permission to seize. The trail to child porn doesn't include the right to seize the stack of John Denver music and while it might include the right to search the shelf of DVDs it doesn't include the right to seize the ones produced by Disney. The right to search your computer and the right to seize it are not at all the same thing. Practically speaking, right now the police are going to seize all your computers. But keep watching. Some time in the next decade or two warrants will start to get quashed for failing to specify (by parameters) *which* computer they were looking for. As computers become more central to our lives it will probably come out that they have the right to duplicate your hard drives and other read/write media but don't have a right to take the originals unless they observe warrant-covered material *on* the computer while searching. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jgreco at ns.sol.net Fri Nov 30 22:49:01 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 30 Nov 2012 16:49:01 -0600 (CST) Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D71223B@MUNEXBE1.medline.com> Message-ID: <201211302249.qAUMn1iI033496@aurora.sol.net> > OK, I get it. I think my BS detector is set to high today. I am just > really suspicious that this guy that runs an large ISP can't at least > wait until there are charges before all the uproar. I think if the cops > came and seized my home PCs right now I would probably give them the > time to look at them, realize there is nothing there, and give them back > to me before freaking out completely. I would be wondering what was > going on but probably not raising a defense fund. You do realize that it is completely common for "looking" at them to take months. This is a big thing to people in this community, because the police will happily come and confiscate the tools you need to do your job, and not return them for months, years, or sometimes even ever, even in cases where it seems fairly straightforward to identify that the person has done nothing wrong. The police, and many of the policies surrounding this issue, often assume that the party is guilty, and also assume that seizure isn't a significant professional issue. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jason at thebaughers.com Fri Nov 30 22:54:14 2012 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 30 Nov 2012 16:54:14 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D71223B@MUNEXBE1.medline.com> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50B93138.3020003@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D71223B@MUNEXBE1.medline.com> Message-ID: I can't help but wonder who would send money to same random person based on a story that may or may not be true. Were these people sucked in by Nigeria scams as well? Not only that, but the list of people who proclaimed their innocence only to be proven guilty is very long. I can't vouch for countries outside of the USA, but here at least we don't get subpoenas on a whim. They are usually part of a very long drawn-out investigation, and they usually are for a very good reason. Jason On Fri, Nov 30, 2012 at 4:37 PM, Naslund, Steve wrote: > OK, I get it. I think my BS detector is set to high today. I am just > really suspicious that this guy that runs an large ISP can't at least > wait until there are charges before all the uproar. I think if the cops > came and seized my home PCs right now I would probably give them the > time to look at them, realize there is nothing there, and give them back > to me before freaking out completely. I would be wondering what was > going on but probably not raising a defense fund. > > Steve > > -----Original Message----- > From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] > Sent: Friday, November 30, 2012 4:21 PM > To: nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. Please help > if you can. > > I didn't say anything about trying to run away. That probably won't > accomplish a whole lot in the long run. But when all of your bank > accounts and credit cards are frozen, and your house is a crime scene, > at least you have the means to rent a hotel room, contact > family/lawyers, etc. > > And no, I'm not OK with people keeping any money that was donated for a > specific purpose in excess of what was actually used. You'd hope that > he'd be a good guy about it and give back the portion that wasn't used, > or clearly state that any excess will go to charity or something. > However, there's no such guarantee (short of doing it through a trust > fund with his lawyer), and just like any philanthropic venture, it's up > to each donor choose when/if they'll help out. It's just like > Kickstarter -- you hope to get something good out of it, but if it > bombs, well... you pay your money and you take your chances. > > - Pete > > > > On 11/30/2012 05:02 PM, Naslund, Steve wrote: > > OK, there must be a lot more paranoid people out there than I thought > > there were. I personally don't have a "runaway kit" stashed away. I > > will get right on that. So when that "mouth breather cop" won't > > believe you are innocent, your answer is to grab your stuff and go on > > the lamb for awhile? I am sure he will let you out to go to the bank, > > > get your stuff, and leave town. I think you have seen way to many > movies. > > > > So if the cops show up at his door tomorrow and say "Here's all your > > stuff back, there was no evidence of a crime.", you are OK with this > > guys keeping the "defense fund"? > > > > Steve > > > > -----Original Message----- > > From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] > > Sent: Friday, November 30, 2012 3:53 PM > > To: nanog at nanog.org > > Subject: Re: William was raided for running a Tor exit node. Please > > help if you can. > > > > > > On 11/30/2012 04:01 PM, Naslund, Steve wrote: > >> I am a little concerned that this guy keeps a safe deposit box > >> with a burner phone and cash around. Is he a CIA agent? :) > > Anyone who DOESN'T have such things stashed away somewhere is, IMHO, > > incredibly naive and taking on quite a large amount of risk. > > > > The likelihood (and hope) is that you'll never need it. But on the > > off chance that you get f***ed by the legal system because of some > > power hungry, mouth-breather cop who can't/won't understand that > > you've done nothing wrong -- or worse, that you're easily provably > > within the law, but he "believes" that you're not and drags you > > through the process anyways -- you'll be very happy that you stashed > > away that old unlocked cell phone, old laptop, change of clothes and > cash. > > > > I'm a (legal) firearms owner... up here in Canada, where some previous > > > governments enacted extreme anti-gun legislation, that pretty much > > means that if I so much as sneeze in a way that a cop doesn't like, I > > can have my life ruined pretty damned fast (not quite, but really > > close). I wouldn't bet against me having an > > excrement-hitting-the-oscillator stash like this guy does. ;) > > > > (Note: I don't mean to imply that all cops are power hungry > > mouth-breathers intent on destroying the lives of citizens. Most > cops > > are fundamentally good people and do a great job. But like every > > other profession, there ARE bad cops out there, and it's within the > > realm of possibility that you'll deal with one of them one day.) > > > >> Why would I donate to his legal defense when he has not been charged > >> yet? A little premature, no? > >> > > If you think that legal costs in a criminal case only start when > you've > > been formally charged, you're grossly misinformed. At what point you > > personally decide to donate is one thing, but implying that someone > > doesn't need a defense fund prior to charges being laid is a bit naive > > > about how the process works. > > > > - Pete > > > > > > > > > > From rdobbins at arbor.net Fri Nov 30 23:00:42 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 30 Nov 2012 23:00:42 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> Message-ID: <7EAA26F2-7EED-41DB-BC98-0AA53E05D930@arbor.net> On Nov 29, 2012, at 12:27 PM, Owen DeLong wrote: > 60% of the world's population still isn't on the internet and I expect a significant fraction of that will be coming on in the next 2-4 years. I live and work in a part of the world which contains a sizable subset of that 60% - i.e., Asia. I see just about zero IPv6 awareness, much less deployment, except peripherally in Japan and, to an even lesser degree, the RoK. I see so many other challenges facing so many IPv4 networks in this region that it's inconceivable that they would be deploying IPv6 within the next 2-4 years, or even the foreseeable future. Also, it appears to me that a large proportion of the population in this region who have both a sufficient amount of disposable income (it doesn't require much here, especially via mobile wireless, but it's still more than a lot of people have) and a corresponding degree of interest to obtain and benefit from Internet access, and who are in fact likely to ever get Internet access, already have it. So, I'm not so sure that there are still these vast numbers of underserved yet eager potential Internet users out there, as is commonly mooted. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jeroen at unfix.org Fri Nov 30 23:09:27 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 01 Dec 2012 00:09:27 +0100 Subject: Remaining IPv6 hurdles (Was: Programmers...) In-Reply-To: <7EAA26F2-7EED-41DB-BC98-0AA53E05D930@arbor.net> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> <7EAA26F2-7EED-41DB-BC98-0AA53E05D930@arbor.net> Message-ID: <50B93CA7.3020006@unfix.org> On 2012-12-01 00:00, Dobbins, Roland wrote: > > On Nov 29, 2012, at 12:27 PM, Owen DeLong wrote: > >> 60% of the world's population still isn't on the internet and I >> expect a significant fraction of that will be coming on in the next >> 2-4 years. > > I live and work in a part of the world which contains a sizable > subset of that 60% - i.e., Asia. > > I see just about zero IPv6 awareness, much less deployment, except > peripherally in Japan and, to an even lesser degree, the RoK. Japan and South Korea are doing quite well indeed and China has CERNET of course which is doing mostly IPv6. There are some ISPs in various other Asian countries doing IPv6, but I guess indeed that they don't push that much traffic, but counting that is hard to tell anyway. > I see so many other challenges facing so many IPv4 networks in this > region that it's inconceivable that they would be deploying IPv6 > within the next 2-4 years, or even the foreseeable future. Can you divulge some of these hurdles? Would be interesting to know what they are running into. Greets, Jeroen From SNaslund at medline.com Fri Nov 30 23:10:09 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 17:10:09 -0600 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <201211302249.qAUMn1iI033496@aurora.sol.net> References: <2A76E400AC84B845AAC35AA19F8E7A5D0D71223B@MUNEXBE1.medline.com> <201211302249.qAUMn1iI033496@aurora.sol.net> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7122B2@MUNEXBE1.medline.com> I understand that they could look at them for many months. In the meantime, my life will go on. I don't believe there is a whole lot you can do about it. If they take too long, I will consider asking a lawyer to look into getting my stuff back but it would have to be expensive stuff to make the lawyer worthwhile. I am guessing I would buy a new PC (they did not seize this guys bank account or credit cards), I probably don't need 100 Terabytes of storage so my costs are not so bad. My message to the cops and my lawyer would be charge me or lets clear this up. There are laws to protect you from the government from taking your stuff in an unfair manner if you want to go that route. If there is a misunderstanding I will talk to the cops all they want. If I feel I need representation, I will get some. If I am really innocent, I doubt they could ask me too much that would upset me. My guess is they would rather move on in their case instead of spinning their wheels with me. I have thought it was rough on people to have all their stuff seized and I suppose you could try and collect some damages if you bought new gear while your stuff was being held (if for no reason) but I think that very often the cops seize the right stuff. I would really like a poll since we have a lot of network professionals on here, exactly how many of us have had something seized by the cops with NO CAUSE. Anybody, I would like to hear from a real life case. Sorry people...most cops want to put the right people in jail and are not trying to violate your rights. There are bad eggs but that is why we have judges. When I hear someone I don't know say they are innocent and the cops say they are guilty, I tend to believe the cop. Everyone in jail says he is innocent too. BTW - in this case, the cops have not even said this guy is guilty of anything yet. Steven Naslund -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Friday, November 30, 2012 4:49 PM To: Naslund, Steve Cc: nanog at nanog.org Subject: Re: William was raided for running a Tor exit node. Please help if > OK, I get it. I think my BS detector is set to high today. I am just > really suspicious that this guy that runs an large ISP can't at least > wait until there are charges before all the uproar. I think if the > cops came and seized my home PCs right now I would probably give them > the time to look at them, realize there is nothing there, and give > them back to me before freaking out completely. I would be wondering > what was going on but probably not raising a defense fund. You do realize that it is completely common for "looking" at them to take months. This is a big thing to people in this community, because the police will happily come and confiscate the tools you need to do your job, and not return them for months, years, or sometimes even ever, even in cases where it seems fairly straightforward to identify that the person has done nothing wrong. The police, and many of the policies surrounding this issue, often assume that the party is guilty, and also assume that seizure isn't a significant professional issue. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From marka at isc.org Fri Nov 30 23:12:00 2012 From: marka at isc.org (Mark Andrews) Date: Sat, 01 Dec 2012 10:12:00 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Fri, 30 Nov 2012 17:35:57 CDT." References: <50AB49EA.3030101@cis.vutbr.cz> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> <1354289940815-019-01077594.sclark.netwolves.com@sclark66.netwolves.com> <50B930A3.7030005@afxr.n et> Message-ID: <20121130231200.F15172C70366@drugs.dv.isc.org> In message , William Herrin writes: > On Fri, Nov 30, 2012 at 5:18 PM, Randy wrote: > > - > > Well I want to add my 10 cents, > > I am a c++ programmer, and have been waiting for my isp to offer native ipv6 > > for ever. I got fed up with waiting and setup a ipv6 over ipv4 tunnel. So > > once I got that done, I spent only an hour updating my socket classes to > > support ipv6. I hadent done so before because I never had ipv6 access, * I > > don't release code without testing it first *. > > > > It wasn't difficult to update to ipv6, only some reading was needed, don't > > know what the fuss is =D > > Go test it against a dual stack remote host with the Tunnel's > addresses still configured on your hosts but packet filtering set to > silently drop packets on the IPv6 tunnel. Then work through the > implications of what you observe. Go test your IPv4 code against a half broken multi-homed server. There is no difference. You either have good mutli-homed support or not in your code. With dual stack everything is multi-homed so no more ignoring the issue. > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From asullivan at dyn.com Fri Nov 30 23:19:21 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 30 Nov 2012 18:19:21 -0500 Subject: carping about CARP In-Reply-To: References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> Message-ID: <20121130231921.GN8043@dyn.com> On Sat, Dec 01, 2012 at 02:05:14AM +1030, David Walker wrote: > As far as not using the same protocol number, that's neither here nor there. Horse pucky. On the Internet, the secure and reliable players co-ordinate their protocol actions through the IANA, using the published IANA rules for how you get a protocol identifier. This case is a straightforward example of a bunch of people angry at things not going their way, and treading all over a well-defined, open process becuse they didn't like the actions of some of the participants. I don't like those actions either, but if proponents cannot bother to publish an Internet-Draft describing CARP, it's pretty hard to take CARP seriously as anything like a "protocol". It's just rude behaviour on someone else's well-defined port. A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From asullivan at dyn.com Fri Nov 30 23:23:52 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 30 Nov 2012 18:23:52 -0500 Subject: carping about CARP In-Reply-To: <20121130210154.GJ11066@diehard.n-r-g.com> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> <20121130130827.GB16865@quigon.bsws.de> <4F61C7CB-6AAD-4E43-A764-4A4C7E438A37@virtualized.org> <20121130210154.GJ11066@diehard.n-r-g.com> Message-ID: <20121130232352.GO8043@crankycanuck.ca> On Fri, Nov 30, 2012 at 10:01:54PM +0100, Claudio Jeker wrote: > implementation would not have been accepted. The result would be a draft > that would never be adopted and so it is back to start. "Adopted" by whom? The procedure, even at the time, did not require in any way IETF consensus. Getting a number requires that you tell others what is going on, not that you justify the going on itself. > Did you ever read any of the IETF mailing lists and looked at the email > addresses of those people pushing the hardest? At least in the ones I'm > subscribed to the bias is obvious. I think that _ad hominem_ arguments are fallacious, and should be dismissed as such. A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From SNaslund at medline.com Fri Nov 30 23:28:01 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 17:28:01 -0600 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <7EAA26F2-7EED-41DB-BC98-0AA53E05D930@arbor.net> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> <7EAA26F2-7EED-41DB-BC98-0AA53E05D930@arbor.net> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D797551@MUNEXBE1.medline.com> I would guess that a lot of the access growth going forward is going to be a lot of what I would term "incidental access". More and more devices and technology requires or supports Internet access. So while a lot of people may not ask for internet service that don't already have it, it will be more of an enabling technology that allows them to do other stuff that they are interested in. My aunt could care less about "the Internet" but she sure loves being able to turn on the heat at her vacation home and monitor stuff there. For example, Joe Schmo may not care about web browsing but wants remote video surveillance, power saving technologies from his power company, smart appliances, and a car that calls in for service by itself. In education, consider that in the third world schools are finding it much more cost effective to build a computer lab than to provide up to date text books and libraries. In that case, the economics are in favor of technology adoption. A lot of these will require Internet access and more importantly this guy is going to get more and more device such that there will be an explosion in address needs. Since he is mobile with all this cool stuff, NATing it all is going to get ugly fast. IPv6 might really be a good idea to new build outs since some of the most difficult issues are with transition strategies and devices consumers will have to configure. I think my life would be much easier if I were to deploy IPv6 from day 1. Cell phones that can be auto configured or embedded devices that the consumer does not have to deal with are the best places to put IPv6. This is a lot like fiber deployment. I put a lot of fiber into countries that did not have good wire line infrastructure. It was cheaper, easier to maintain, and was not as marketable on the black market as copper is. Some of the last countries to get technology have the best infrastructure now because they started with the last generation of stuff. It is a lot harder to justify replacement of old tech than a Greenfield installation. Steven Naslund -----Original Message----- From: Dobbins, Roland [mailto:rdobbins at arbor.net] Sent: Friday, November 30, 2012 5:01 PM To: NANOG list Subject: Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... On Nov 29, 2012, at 12:27 PM, Owen DeLong wrote: > 60% of the world's population still isn't on the internet and I expect a significant fraction of that will be coming on in the next 2-4 years. I live and work in a part of the world which contains a sizable subset of that 60% - i.e., Asia. I see just about zero IPv6 awareness, much less deployment, except peripherally in Japan and, to an even lesser degree, the RoK. I see so many other challenges facing so many IPv4 networks in this region that it's inconceivable that they would be deploying IPv6 within the next 2-4 years, or even the foreseeable future. Also, it appears to me that a large proportion of the population in this region who have both a sufficient amount of disposable income (it doesn't require much here, especially via mobile wireless, but it's still more than a lot of people have) and a corresponding degree of interest to obtain and benefit from Internet access, and who are in fact likely to ever get Internet access, already have it. So, I'm not so sure that there are still these vast numbers of underserved yet eager potential Internet users out there, as is commonly mooted. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From tvhawaii at shaka.com Fri Nov 30 23:37:19 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 30 Nov 2012 13:37:19 -1000 Subject: William was raided for running a Tor exit node. Please help if you can. References: <20663.35479.561328.722417@world.std.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D712251@MUNEXBE1.medline.com> Message-ID: Naslund, Steve wrote: > I might be reading this the wrong way but it looked to me like the cops > raided his home and the Tor server is hosted off site with an ISP. That > is what is bugging me so much. The cops raided his house, not the > location of the server. If they had tracked the server by its IP it > would have led to the hoster, not his home. They could have gotten his > address as the account holder but the ISP would have known that the Tor > server was at their site not his home. The IP would not track to his > residence. Something is not the full story here or I am misreading his > interview. How about: Police have seen CP and have logs from "Additionally, I was accused of sharing (and possibly producing) child pornography on a clearnet forum via an image hosting site that was probably tapped." Police look at IP addresses that have accessed the images for those that are within their jurisdiction. Police find an address within a block that is registered to Wiliam. Police raid William and receive an education on TOR exit nodes on servers in Poland. Maybe? Why wouldn't the IP address have led to William? --Michael From nick at foobar.org Fri Nov 30 23:39:48 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 30 Nov 2012 23:39:48 +0000 Subject: carping about CARP In-Reply-To: <20121130210154.GJ11066@diehard.n-r-g.com> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> <20121130130827.GB16865@quigon.bsws.de> <4F61C7CB-6AAD-4E43-A764-4A4C7E438A37@virtualized.org> <20121130210154.GJ11066@diehard.n-r-g.com> Message-ID: <50B943C4.8050001@foobar.org> On 30/11/2012 21:01, Claudio Jeker wrote: > Still carp packets can coexist with vrrp packets. They use a different > version numbers. And the same mac address pool, which means that if you use the same vhid as vrrp group number, you will trash both your carp and vrrp virtual IPs. Carp was coded explicitly knowing that this would happen, because it squats the VRRP mac address ranges as well as protocol 112. This isn't documented anywhere on the openbsd web site. Not in the man pages, not in the FAQs and not in the pf documentation. It would be real nice to think that this was an oversight. Basic developer best practice involves not deliberately creating loss-of-service style pitfalls for users to fall into, and the least I expect from a developer is that if they're going to do write a "different" protocol which poops all over a similar protocol and takes down peoples' networks during deployment because it's squatting someone else's registered space, the least they could do is document the problem clearly. Regardless of any faux innocent pieties expressed by the openbsd people, this protocol behaviour is astoundingly obnoxious. Nick Also you need to use a different vhid but the same thing > is true if you have 2 groups of vrrp on the same lan. If you configure > something like VRRP you should run a quick tcpdump first and check > if there are not unexpected packets showing up. This is especially > important for any protocol that does a link local multicast or broadcast. > This is basic network admin best practice (at least I expect that from a > network engineer). > >>> we didn't have a choice but to ignore that industry-money-driven committee. >> >> Which 'industry-money-driven committee' would that be? > > Did you ever read any of the IETF mailing lists and looked at the email > addresses of those people pushing the hardest? At least in the ones I'm > subscribed to the bias is obvious. > From SNaslund at medline.com Fri Nov 30 23:49:44 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 30 Nov 2012 17:49:44 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D712251@MUNEXBE1.medline.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D797568@MUNEXBE1.medline.com> If he is claiming that the traffic to the forum came through the Tor node, that IP would lead them to the hosting company of the Tor node. Not his residence. If they had an IP that led to his home, that would have to mean that the traffic did not come from his Tor node at the ISP. I suppose you could get your own block of addresses and get the ISP to advertise them for you to host your server but I don't think you would. If they got his address from the hosting company, I suppose that might lead them to his house but it also would have told them that the Tor node was not AT his house. Why go there? I think they have something else. There are lots of terabytes for them to look at. Who wants to bet what is there? Steven Naslund -----Original Message----- From: Michael Painter [mailto:tvhawaii at flex.com] On Behalf Of Michael Painter Sent: Friday, November 30, 2012 5:37 PM To: Naslund, Steve; NANOG list Subject: Re: William was raided for running a Tor exit node. Please help if you can. Naslund, Steve wrote: > I might be reading this the wrong way but it looked to me like the > cops raided his home and the Tor server is hosted off site with an > ISP. That is what is bugging me so much. The cops raided his house, > not the location of the server. If they had tracked the server by its > IP it would have led to the hoster, not his home. They could have > gotten his address as the account holder but the ISP would have known > that the Tor server was at their site not his home. The IP would not > track to his residence. Something is not the full story here or I am > misreading his interview. How about: Police have seen CP and have logs from "Additionally, I was accused of sharing (and possibly producing) child pornography on a clearnet forum via an image hosting site that was probably tapped." Police look at IP addresses that have accessed the images for those that are within their jurisdiction. Police find an address within a block that is registered to Wiliam. Police raid William and receive an education on TOR exit nodes on servers in Poland. Maybe? Why wouldn't the IP address have led to William? --Michael From rdobbins at arbor.net Fri Nov 30 23:49:40 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 30 Nov 2012 23:49:40 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D797551@MUNEXBE1.medline.com> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> <7EAA26F2-7EED-41DB-BC98-0AA53E05D930@arbor.net> <2A76E400AC84B845AAC35AA19F8E7A5D0D797551@MUNEXBE1.medline.com> Message-ID: On Dec 1, 2012, at 6:28 AM, Naslund, Steve wrote: > A lot of these will require Internet access and more importantly thiscguy is going to get more and more device such that there will be an > explosion in address needs. I agree that spimes and M2M in general certainly have the potential for explosive growth, if they're ever adopted for various large-scale applications. Right now, at least, this is largely theoretical (again, waiting for the 'killer app'). ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton