Re: Automatic IPv6 due to broadcast

[Anurag Bhatia]

Thanks for useful reply everyone!


As I mentioned - I applied quick temporary fix by stop broadcast from
router and clearing of routing table on servers. Will apply disabling of
autoconfig now.

On Tue, Apr 17, 2012 at 5:25 PM, Mick O'Rourke wrote:

> RA guard is useful if your tcam capacity and or switching platform allows -
> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-01
>
> An older yet still a good read from Cisco on some IPv6 first hop security:
>
> http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security.html#wp1054246
>
> Mick
>



-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com

Re: Most energy efficient (home) setup

[Jeroen van Aart]

Jimmy Hess wrote:

Consider that the probability 16GB of SDRAM experiences at least one
single bit error at sea level,
in a given 6 hour period exceeds  66%  = 1 - (1 - 1.3e-12 * 6)^(16 *
2^30 * 8).In any given 24 hour period, the probability of at least
one single bit error  exceeds 98%.Assuming the memory is good and
functioning correctly;



application in the effected space,  and  moderately important data is
being damaged
well,   that's just plain uncool


Having limited knowledge of which consumer devices support ECC memory 
and which don't I was pleasantly surprised to find out the always on IBM 
thinkpad I ran for years refused to work with non-ECC memory.


Greetings,
Jeroen

--
Earthquake Magnitude: 6.2
Date: Tuesday, April 17, 2012 19:03:55 UTC
Location: east of the South Sandwich Islands
Latitude: -59.0988; Longitude: -16.6928
Depth: 1.00 km

letter opposing cybersecurity legislation: looking for signers

[Dan Auerbach]

Dear NANOGers,

EFF is looking for sign-ons to a letter expressing concern about some of the 
proposed "cybersecurity" legislation currently being debated in the US 
Congress. This legislation has a number of alarming provisions, including 
incentives for recording massive amounts of network traffic and sharing it with 
federal agencies; nullification of existing wiretapping and privacy laws; in 
some cases, new kinds of bureaucracy for backbone and other ISPs who are 
designated as "critical infrastructure", and provisions that establish 
intellectual property enforcement as a "cybersecurity" objective.

We realize this is potentially a complicated topic in the NANOG community, and 
we'd prefer not to start a giant OT flamewar, so: if you agree with our 
concerns and would like to sign on to our letter, let us know by private email 
by Thursday morning 9am Pacific US time. If you think we have the wrong 
perspective, you can let us know off-list, or write your own letters, or work 
with your various policy departments on this.

Because there are many "cybersecurity" bills currently being debated in the US 
House and Senate, the letter is generally framed in opposition to bad aspects 
of the bills, though it calls out two current proposals that are particularly 
bad and close to passing: CISPA (H.R. 3523) in the House, and "Secure IT Act" 
(S. 2151) in the Senate. The letter also is intended to be simple and focused 
on the civil liberties issues that stem from the broadness of the bills. It 
does not talk about technical problems with deploying IDS/IPS in the private 
sector (for a discussion of this, see, e.g. 
http://harvardnsj.org/wp-content/uploads/2012/01/Vol.-3_Bellovin_Bradner_Diffie_Landau_Rexford1.pdf)
 or other legitimate technical concerns about effectiveness. We certainly 
encourage people to raise these concerns separately. The text of the letter is 
below in triple quotes:

"""

Dear Lawmakers,


We are writing you today as professionals, academics, and experts who
have researched, analyzed, and defended against security threats to the
Internet and its infrastructure. We have devoted our careers to building
security technologies, and to protecting networks, computers, and
critical infrastructure against attacks of many stripes.

We take security very seriously, but we fervently believe that strong
computer and network security does not require Internet users to
sacrifice their privacy and civil liberties. The opposite, in fact, is true.

The bills currently under consideration, including Rep. Rogers' /Cyber
Intelligence Sharing and Protection Act of 2011 /(H.R. 3523) and Sen.
McCain's/SECURE IT Act /(S. 2151)/, /are drafted to allow entities who
participate in relaying or receiving Internet traffic to freely monitor
and redistribute those network communications. The bills nullify current
legal protections against wiretapping and similar civil liberties
violations for that kind of broad data sharing. By encouraging the
transfer of users' private communications to US Federal agencies, and
lacking any form of public accountability or transparency, these
"cybersecurity" bills falsely trade our civil liberties for the promise
of improved network security. As experts in the field, we reject this
false trade-off and urge you to oppose any cybersecurity initiative that
does not explicitly include appropriate methods to ensure the protection
of users' civil liberties.

In summary, we urge you to reject legislation that:

  *

Uses vague language to describe network security attacks, threat
indicators, and countermeasures, allowing for the possibility that
innocuous online activities could be construed as "cybersecurity"
threats.

  *

Exempts "cybersecurity" activities from existing laws that protect
individuals' privacy and devices, such as the Wiretap Act, the
Stored Communications Act, and the Computer Fraud and Abuse Act.

  *

Gives sweeping immunity from liability to companies even if they
violate individuals' privacy without good reason.

  *

Allows data originally collected through "cybersecurity" programs to
be used to prosecute unrelated crimes.

  *

Includes provisions suggesting a back door for intellectual property
enforcement. Computer security is too important an issue to let it
be hijacked for the sectional interests of unrelated industries.

We appreciate your interest in making our networks more secure, but
passing legislation that suffers from the problems above would be a
grave mistake for privacy and civil liberties, and will not be a step
forward in making us safer.

Sincerely,



"""

For a more detailed discussion of some of the civil liberties implications and 
other analyses, please see the following articles:

https://www.eff.org/deeplinks/2012/03/dangerously-vague-cybersecurity-legislation

https://www.eff.org/deeplinks/2012/03/rogers-cybersecurity-bill-broad-enough-use-against-wikileaks-and-pirate-bay

http

Re: [c-nsp] Possible T1 clocking problem.

[Carlos Alcantar]

You might want to put a t1 test set on the line and check and see if the
clock frequency is moving.

Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314 / car...@race.com / http://www.race.com





-Original Message-
From: Andrew Koch 
Date: Tue, 17 Apr 2012 14:16:27 -0500
To: , "nanog@nanog.org" 
Subject: Re: [c-nsp] Possible T1 clocking problem.

On 4/17/12 13:46 AM, Joseph Mays wrote:

> The interface on the remote end (t1 WIC port in a 2600 shows a lot more
>errors, including a lot of frame errors, for the same time period.
[snip]

Are these T1 frame errors, or a higher level?  If you believe this to
be a T1 concern, you should be checking at the T1 level - "show
controller T1 1/0:24" for the AS5400 and "show service-module serial
x/y performance-statistics" for the WIC on the 2600.  Both of these
commands will display the T1 statistics in 15min intervals.

If you see errors there, most HDSL4 smart-jacks have a serial port for
pulling stats and levels, if they are your smart-jacks to be checking.

HTH,
Andy

Re: [c-nsp] Possible T1 clocking problem.

[Andrew Koch]

On 4/17/12 13:46 AM, Joseph Mays wrote:

> The interface on the remote end (t1 WIC port in a 2600 shows a lot more 
> errors, including a lot of frame errors, for the same time period.
[snip]

Are these T1 frame errors, or a higher level?  If you believe this to
be a T1 concern, you should be checking at the T1 level - "show
controller T1 1/0:24" for the AS5400 and "show service-module serial
x/y performance-statistics" for the WIC on the 2600.  Both of these
commands will display the T1 statistics in 15min intervals.

If you see errors there, most HDSL4 smart-jacks have a serial port for
pulling stats and levels, if they are your smart-jacks to be checking.

HTH,
Andy

Re: OpenFlow @ GOOG

[Marshall Eubanks]

I wonder if this will be contributed to the DC (DataCenter) work
currently gearing up in the IETF.

Regards
Marshall

On Tue, Apr 17, 2012 at 12:37 PM, Eugen Leitl  wrote:
>
> http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/all/1
>
> Going With The Flow: Google’s Secret Switch To The Next Wave Of Networking
>
> By Steven Levy April 17, 2012 | 11:45 am |
>
> Categories: Data Centers, Networking
>
> In early 1999, an associate computer science professor at UC Santa Barbara
> climbed the steps to the second floor headquarters of a small startup in Palo
> Alto, and wound up surprising himself by accepting a job offer. Even so, Urs
> Hölzle hedged his bet by not resigning from his university post, but taking a
> year-long leave.
>
> He would never return. Hölzle became a fixture in the company — called
> Google. As its czar of infrastructure, Hölzle oversaw the growth of its
> network operations from a few cages in a San Jose co-location center to a
> massive internet power; a 2010 study by Arbor Networks concluded that if
> Google was an ISP it would be the second largest in the world (the largest is
> Tier 3, which services over 2,700 major corporations in 450 markets over
> 100,000 fiber miles.) ‘You have all those multiple devices on a network but
> you’re not really interested in the devices — you’re interested in the
> fabric, and the functions the network performs for you,’ Hölzle says.
>
> Google treats its infrastructure like a state secret, so Hölzle rarely speaks
> about it in public. Today is one of those rare days: at the Open Networking
> Summit in Santa Clara, California, Hölzle is announcing that Google
> essentially has remade a major part of its massive internal network,
> providing the company a bonanza in savings and efficiency. Google has done
> this by brashly adopting a new and radical open-source technology called
> OpenFlow.
>
> Hölzle says that the idea behind this advance is the most significant change
> in networking in the entire lifetime of Google.
>
> In the course of his presentation Hölzle will also confirm for the first time
> that Google — already famous for making its own servers — has been designing
> and manufacturing much of its own networking equipment as well.
>
> “It’s not hard to build networking hardware,” says Hölzle, in an advance
> briefing provided exclusively to Wired. “What’s hard is to build the software
> itself as well.”
>
> In this case, Google has used its software expertise to overturn the current
> networking paradigm.
>
> If any company has potential to change the networking game, it is Google. The
> company has essentially two huge networks: the one that connects users to
> Google services (Search, Gmail, YouTube, etc.) and another that connects
> Google data centers to each other. It makes sense to bifurcate the
> information that way because the data flow in each case has different
> characteristics and demand. The user network has a smooth flow, generally
> adopting a diurnal pattern as users in a geographic region work and sleep.
> The performance of the user network also has higher standards, as users will
> get impatient (or leave!) if services are slow. In the user-facing network
> you also need every packet to arrive intact — customers would be pretty
> unhappy if a key sentence in a document or e-mail was dropped.
>
> The internal backbone, in contrast, has wild swings in demand — it is
> “bursty” rather than steady. Google is in control of scheduling internal
> traffic, but it faces difficulties in traffic engineering. Often Google has
> to move many petabytes of data (indexes of the entire web, millions of backup
> copies of user Gmail) from one place to another. When Google updates or
> creates a new service, it wants it available worldwide in a timely fashion —
> and it wants to be able to predict accurately how quickly the process will
> take.
>
> “There’s a lot of data center to data center traffic that has different
> business priorities,” says Stephen Stuart, a Google distinguished engineer
> who specializes in infrastructure. “Figuring out the right thing to move out
> of the way so that more important traffic could go through was a challenge.”
>
> But Google found an answer in OpenFlow, an open source system jointly devised
> by scientists at Stanford and the University of California at Berkeley.
> Adopting an approach known as Software Defined Networking (SDN), OpenFlow
> gives network operators a dramatically increased level of control by
> separating the two functions of networking equipment: packet switching and
> management. OpenFlow moves the control functions to servers, allowing for
> more complexity, efficiency and flexibility.
>
> “We were already going down that path, working on an inferior way of doing
> software-defined networking,” says Hölzle. “But once we looked at OpenFlow,
> it was clear that this was the way to go. Why invent your own if you don’t
> have to?”
>
> Google became one of several 

OpenFlow @ GOOG

[Eugen Leitl]

http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/all/1

Going With The Flow: Google’s Secret Switch To The Next Wave Of Networking

By Steven Levy April 17, 2012 | 11:45 am | 

Categories: Data Centers, Networking

In early 1999, an associate computer science professor at UC Santa Barbara
climbed the steps to the second floor headquarters of a small startup in Palo
Alto, and wound up surprising himself by accepting a job offer. Even so, Urs
Hölzle hedged his bet by not resigning from his university post, but taking a
year-long leave.

He would never return. Hölzle became a fixture in the company — called
Google. As its czar of infrastructure, Hölzle oversaw the growth of its
network operations from a few cages in a San Jose co-location center to a
massive internet power; a 2010 study by Arbor Networks concluded that if
Google was an ISP it would be the second largest in the world (the largest is
Tier 3, which services over 2,700 major corporations in 450 markets over
100,000 fiber miles.) ‘You have all those multiple devices on a network but
you’re not really interested in the devices — you’re interested in the
fabric, and the functions the network performs for you,’ Hölzle says.

Google treats its infrastructure like a state secret, so Hölzle rarely speaks
about it in public. Today is one of those rare days: at the Open Networking
Summit in Santa Clara, California, Hölzle is announcing that Google
essentially has remade a major part of its massive internal network,
providing the company a bonanza in savings and efficiency. Google has done
this by brashly adopting a new and radical open-source technology called
OpenFlow.

Hölzle says that the idea behind this advance is the most significant change
in networking in the entire lifetime of Google.

In the course of his presentation Hölzle will also confirm for the first time
that Google — already famous for making its own servers — has been designing
and manufacturing much of its own networking equipment as well.

“It’s not hard to build networking hardware,” says Hölzle, in an advance
briefing provided exclusively to Wired. “What’s hard is to build the software
itself as well.”

In this case, Google has used its software expertise to overturn the current
networking paradigm.

If any company has potential to change the networking game, it is Google. The
company has essentially two huge networks: the one that connects users to
Google services (Search, Gmail, YouTube, etc.) and another that connects
Google data centers to each other. It makes sense to bifurcate the
information that way because the data flow in each case has different
characteristics and demand. The user network has a smooth flow, generally
adopting a diurnal pattern as users in a geographic region work and sleep.
The performance of the user network also has higher standards, as users will
get impatient (or leave!) if services are slow. In the user-facing network
you also need every packet to arrive intact — customers would be pretty
unhappy if a key sentence in a document or e-mail was dropped.

The internal backbone, in contrast, has wild swings in demand — it is
“bursty” rather than steady. Google is in control of scheduling internal
traffic, but it faces difficulties in traffic engineering. Often Google has
to move many petabytes of data (indexes of the entire web, millions of backup
copies of user Gmail) from one place to another. When Google updates or
creates a new service, it wants it available worldwide in a timely fashion —
and it wants to be able to predict accurately how quickly the process will
take.

“There’s a lot of data center to data center traffic that has different
business priorities,” says Stephen Stuart, a Google distinguished engineer
who specializes in infrastructure. “Figuring out the right thing to move out
of the way so that more important traffic could go through was a challenge.”

But Google found an answer in OpenFlow, an open source system jointly devised
by scientists at Stanford and the University of California at Berkeley.
Adopting an approach known as Software Defined Networking (SDN), OpenFlow
gives network operators a dramatically increased level of control by
separating the two functions of networking equipment: packet switching and
management. OpenFlow moves the control functions to servers, allowing for
more complexity, efficiency and flexibility.

“We were already going down that path, working on an inferior way of doing
software-defined networking,” says Hölzle. “But once we looked at OpenFlow,
it was clear that this was the way to go. Why invent your own if you don’t
have to?”

Google became one of several organizations to sign on to the Open Networking
Foundation, which is devoted to promoting OpenFlow. (Other members include
Yahoo, Microsoft, Facebook, Verizon and Deutsche Telekom, and an innovative
startup called Nicira.) But none of the partners so far have announced any
implementation as extensive as Google’s.

Why is O

Re: trouble with Paradyne Bitstorm 2600 DSLAM

[A.T.]

Thanks. I have already tried interrupting boot process. Booting up with
parameter 0x00020 (disable login security) don't seem affect outcome,
both serial and management ethernet still asks login.


On Tue, 2012-04-17 at 09:09 -0500, Chris Boyd wrote:
> Try pressing enter several times after powering the system up.
> 
> --Chris
> 
> On Apr 17, 2012, at 8:19 AM, A.T. wrote:
> 
> > Hello, all!
> > 
> > 
> > I have Paradyne Bitstorm 2600 DSLAM, but no password. Is it possible to
> > reset this device to factory configuration? Manuals don't say much, only
> > specified way to restore factory settings assume logged in
> > administrator.
> > 
> > Thanks!
> > 
> > 
> > 
> > 
> > 
> > 
> > !DSPAM:1001,4f8d6e61937107248971901!
> 

trouble with Paradyne Bitstorm 2600 DSLAM

[A.T.]

Hello, all!


I have Paradyne Bitstorm 2600 DSLAM, but no password. Is it possible to
reset this device to factory configuration? Manuals don't say much, only
specified way to restore factory settings assume logged in
administrator.

Thanks!

Re: Automatic IPv6 due to broadcast

[Mick O'Rourke]

RA guard is useful if your tcam capacity and or switching platform allows -
http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-01

An older yet still a good read from Cisco on some IPv6 first hop security:
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security.html#wp1054246

Mick

Re: Automatic IPv6 due to broadcast

[Jared Mauch]

tcpdump -e will show source and dest mac address.

On Apr 17, 2012, at 6:54 AM, Ray Soucy  wrote:

> tcpdump -ni eth0 'ip6 dst ff02::1'
> 
> 06:48:48.044409 IP6 fe80::2d0:1ff:fedf:8400 > ff02::1: ICMP6, router
> advertisement, length 64

Re: Automatic IPv6 due to broadcast

[Ray Soucy]

You have a rogue IPv6 router on your network.  It's not a host problem.
 It's along the lines of having a rogue DHCP server on your network but
faster propagation.

It needs to be tracked down and disabled.

You can use tcpdump (as root) to capture IPv6 RA and see who's doing it,
and what's being advertised:

tcpdump -ni eth0 'ip6 dst ff02::1'

06:48:48.044409 IP6 fe80::2d0:1ff:fedf:8400 > ff02::1: ICMP6, router
advertisement, length 64

Then look at your IPv6 neighbor table for the MAC of that host:

ip -6 neigh show

fe80::2d0:1ff:fedf:8400 dev eth0 lladdr 00:d0:01:df:84:00 router REACHABLE

Once you have the MAC, track it down and disable it.

On a Cisco device "show mac address-table" (or "show mac-address-table" on
older hardware).




-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: Automatic IPv6 due to broadcast

[Seth Mos]

Op 17-4-2012 10:33, Carlos Martinez-Cagnazzo schreef:

IMO it's much easier to disable one rogue than to disable IPv6 on the
whole network. That is if you can find it, but with some proper
tcpdumping and/or CLI commands (depending on the switches that you have)
it should be relatively easy.


Even better, the IPv6 gateway you got assigned is based on the MAC 
address. That means you can also find what brand of device is advertising.


http://standards.ieee.org/develop/regauth/oui/public.html

You can most likely find which IPv4 address the MAC corresponds too as 
well. Was that so hard?



Not to mention that, as pointed by others, this provides a wonderful
opportunity to look into this new (*grin*) protocol.


Indeed!



Cheers!

~Carlos


Cheers,

Seth

Re: Automatic IPv6 due to broadcast

[Carlos Martinez-Cagnazzo]

I don't understand why a problem with a tunnel 'leaves a bad taste with
IPv6'. Since when a badly configured DNS zone left people with a 'bad
taste for DNS', or a badly configured switch left people with 'a bad
taste for spanning tree' or 'a bad taste for vlan trunking' ?

It seems to me that what are perceived as operational mistakes and/or
plain lack of knowledge for some technologies is perceived as a fault of
the protocol itself in the case of IPv6.

People need to get their acts together.

~Carlos

On 4/16/12 11:38 PM, Brandon Penglase wrote:
> I know you mentioned RedHat, but not if it was the router or other
> servers. Were you playing with Microsoft's Direct Access and turn on
> the dns entry (isatap.domain.com) internally?
> At my current place of employment, we had a security student (at the
> direction of our security analyst) turn up a DA test server. When they
> enabled the DNS entry, just about every Windows 7 and 2008 server setup
> a v6 tunnel back to this little tiny VM. This also included the DNS
> entries in AD, so all of the sudden, servers have v6 addresses. 
> Needless to say, everything was horribly slow, and some things even
> flat out broke. Sadly this event left a really sour taste for IPv6 with
> Networking department (whom I was occasionally bugging about v6).
>
> If you weren't testing this, did you possibly setup something similar
> where it would automatically generate a tunnel?
>
>   Brandon Penglase
>
>  On Mon, 16 Apr 2012 23:39:46 +0530
> Anurag Bhatia  wrote:
>
>> Hello everyone
>>
>>
>>
>> Just got a awfully crazy issue. I heard from our support team about
>> failure of whois during domain registration. Initially I thought of
>> port 43 TCP block or something but found it was all ok. Later when
>> ran whois manually on server via terminal it failed. Found problem
>> that server was connecting to whois server - whois.verisign-grs.com.
>> I was stunned! Server got IPv6 and not just that one - almost all.
>> This was scary - partial IPv6 setup and it was breaking things.
>>
>> In routing tables, routes were all going to a router which I recently
>> setup for testing. That router and other servers are under same
>> switch but by no means I ever configured that router as default
>> gateway for IPv6. I found option of "broadcast" was enabled on router
>> for local fe80... address and I guess router broadcasted IPv6 and
>> somehow (??) all servers found that they have a IPv6 router on LAN
>> and started using it - automated DHCP IPv6?
>>
>> I wonder if anyone else also had similar issues? Also, if my guesses
>> are correct then how can we disable Red Hat distro oriented servers
>> from taking such automated configuration - simple DHCP in IPv6
>> disable?
>>
>>
>>
>>
>> Thanks
>>
>> -- 
>>
>> Anurag Bhatia
>> anuragbhatia.com
>> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
>> network!
>>
>> Twitter: @anurag_bhatia 
>> Linkedin: http://linkedin.anuragbhatia.com
>>

Re: Automatic IPv6 due to broadcast

[Carlos Martinez-Cagnazzo]

IMO it's much easier to disable one rogue than to disable IPv6 on the
whole network. That is if you can find it, but with some proper
tcpdumping and/or CLI commands (depending on the switches that you have)
it should be relatively easy.

Not to mention that, as pointed by others, this provides a wonderful
opportunity to look into this new (*grin*) protocol.

Cheers!

~Carlos

On 4/16/12 9:32 PM, Arturo Servin wrote:
> Anurag,
>
>   You have a rogue RA in your network. Now is just an annoying DoS, but 
> it can easily be turned in a real security concern.
>
>   I suggest to either deploy properly IPv6 or disable it. I am more on 
> the former, but it is your choice.
>
> Regards
> -as
>
> On 16 Apr 2012, at 15:09, Anurag Bhatia wrote:
>
>> Hello everyone
>>
>>
>>
>> Just got a awfully crazy issue. I heard from our support team about failure
>> of whois during domain registration. Initially I thought of port 43 TCP
>> block or something but found it was all ok. Later when ran whois manually
>> on server via terminal it failed. Found problem that server was connecting
>> to whois server - whois.verisign-grs.com. I was stunned! Server got IPv6
>> and not just that one - almost all. This was scary - partial IPv6 setup and
>> it was breaking things.
>>
>> In routing tables, routes were all going to a router which I recently setup
>> for testing. That router and other servers are under same switch but by no
>> means I ever configured that router as default gateway for IPv6. I found
>> option of "broadcast" was enabled on router for local fe80... address and I
>> guess router broadcasted IPv6 and somehow (??) all servers found that they
>> have a IPv6 router on LAN and started using it - automated DHCP IPv6?
>>
>> I wonder if anyone else also had similar issues? Also, if my guesses are
>> correct then how can we disable Red Hat distro oriented servers from taking
>> such automated configuration - simple DHCP in IPv6 disable?
>>
>>
>>
>>
>> Thanks
>>
>> -- 
>>
>> Anurag Bhatia
>> anuragbhatia.com
>> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
>> network!
>>
>> Twitter: @anurag_bhatia 
>> Linkedin: http://linkedin.anuragbhatia.com
>