- NANOG - lists.nanog.org

Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
by Johnny Eriksson 28 Nov '12

28 Nov '12

Owen DeLong <owen(a)delong.com> 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

1 0

Looking for an Optimum Online engineer
by Blake Pfankuch 27 Nov '12

27 Nov '12

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

1 0

Folks - changes to USTiming.ORG NIST Time Servers access names...
by tglassey 27 Nov '12

27 Nov '12

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.

1 0

Spanner: synchronizing the largest global database with GPSDO stratum 1 in every datacenter
by Eugen Leitl 27 Nov '12

27 Nov '12

(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

1 0

CfP: Survey on network attack detection and mitigation
by Sebastian Abt 27 Nov '12

27 Nov '12

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

1 0

Re: [serval-project-dev] Re: Adding GPS location to IPv6 header
by Eugen Leitl 27 Nov '12

27 Nov '12

----- Forwarded message from Jeremy Lakeman <jeremy(a)servalproject.org> ----- From: Jeremy Lakeman <jeremy(a)servalproject.org> Date: Tue, 27 Nov 2012 11:10:26 +1030 To: serval-project-developers(a)googlegroups.com Subject: Re: [serval-project-dev] Re: Adding GPS location to IPv6 header Reply-To: serval-project-developers(a)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 <eugen(a)leitl.org> wrote: > ----- Forwarded message from George Herbert <george.herbert(a)gmail.com> ----- > > From: George Herbert <george.herbert(a)gmail.com> > Date: Mon, 26 Nov 2012 14:51:57 -0800 > To: William Herrin <bill(a)herrin.us> > Cc: Eugen Leitl <eugen(a)leitl.org>, nanog(a)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 <bill(a)herrin.us> wrote: >> On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl <eugen(a)leitl.org> 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(a)dirtside.com bill(a)herrin.us >> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> >> Falls Church, VA 22042-3004 >> > > > > -- > -george william herbert > george.herbert(a)gmail.com > > ----- End forwarded message ----- > -- > Eugen* Leitl <a href="http://leitl.org">leitl</a> 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(a)googlegroups.com. > To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)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(a)googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> 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

1 0

AT&T postmaster/mail admin
by A Howard 27 Nov '12

27 Nov '12

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

1 0

RE: Adding GPS location to IPv6 header
by Ammar Salih 27 Nov '12

27 Nov '12

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@auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog(a)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

13 20

Cloudmark
by John Zettlemoyer 26 Nov '12

26 Nov '12

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

1 0

Fwd: (via Dave Farber's IP list): Mark Crispin
by Rich Kulawiec 26 Nov '12

26 Nov '12

Careful with followups, please, am sending this to multiple lists. ---rsk ----- Forwarded message ----- > ? From: Barry Leiba <barryleiba at computer.org> > ? 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 <imap5 at ietf.org> 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 -----

1 0