- Test - lists.nanog.org

Re: IPv6 Deployment for the LAN
by Ray Soucy 23 Oct '09

23 Oct '09

It's certainly encouraging to see how there is such consensus among NANOG on IPv6 deployment. :-) Recent exchanges seem to be getting a little personal, so we might want to take a step back and breath. I don't think adding default gateway support to DHCPv6 will have much of an impact, but I'm OK with people trying to get it implemented. Another tool in the box. I just wouldn't hold your breath waiting for it. I think the better approach is to take a firm stand on security and make RA gaurd and DHCPv6 snooping expected for network devices. These problems will still exist if default gateway options for DHCPv6 get implemented. As for RA taking down a network quickly, well, it can be restored quickly too. The fact that RA is actually responsive can be a benefit in some situations. Hopefully if anything has come out of this thread its that both stateless and stateful configuration have a place in IPv6, and that there is still work to be done before IPv6 is really ready for the enterprise LAN. Others may have their specific requests from vendors, but here are mine: 1. Include DHCPv6 client functionality as part of any IPv6 implementation. 2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure. A lot of the frustration seems to come from Windows ICS acting as an IPv6 router. I think everyone here has been after Microsoft to either remove ICS or make it more difficult to enable at one point or another. While a rogue RA can come from anywhere, Windows is usually the guilty party. I would argue that since NAT is not a component of IPv6, no host should be implementing ICS-like functionality for IPv6. It's unlikely that there would be a situation on an IPv6 network that a host needed to share it's IPv6 address to get others online. Just my thoughts. Maybe someone from Microsoft who can do something about it lurks on this list. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/

3 3

Need a clueful Telia AS1299 engineer
by Jeffrey Lyon 22 Oct '09

22 Oct '09

Could a clueful AS1299 engineer please drop me a line? Dealing with the Level 0 technicians that are offered to IC clients is completely useless in diagnosing a rather serious issue. -- Jeffrey Lyon, Leadership Team jeffrey.lyon(a)blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty."

2 1

IPv6 internet broken, cogent/telia/hurricane not peering
by Igor Ybema 22 Oct '09

22 Oct '09

Hi, I recently noticed that there seems a peering issue on the ipv6 internet. As we all know hurricane is currently the largest ipv6 carrier. Other large carriers are now implementing ipv6 on their networks, like Cogent and Telia. However, due to some politics it seems that they are not peering with each other resulting in a broken ipv6 internet currently. I noticed this by using the looking glasses from telia and hurricane. This is only a real problem if you use hurricane as the only transit. However, hurricane also announces 6to4 relays. When you happen to use the hurricane relay server (due to the shortest path), cogent and telia (and maybe more) are not reachable. I already asked hurricane about their point of view. They simply just ignore it because they 'are the biggest one'. I'm currious about you point of view. regards, Igor Ybema Senior network Administrator Oxilion

28 64

Fwd: [IP] [warning: layer 8/9] "Strange bedfellows, " aka a joint statement from Verizon Wireless and Google
by tvest＠eyeconomics.com 22 Oct '09

22 Oct '09

Interesting, curious... but meaningful? To my mind Google's language seems to be focused on wireline issues, which I guess are probably quite a bit easier for Verizon Wireless to accommodate. Conversely, VW's emphasis on continuing self-regulation of wireless access would seem to be of secondary importance, at best, to Google. Does this mean that a future of combat over "my (TCP) ports" is somewhat less likely? Does this mean that Google won't be offering me FTTH within the next 2-3 years? Inquiring minds take note! TV Begin forwarded message: > From: David Farber <dave(a)farber.net> > Date: October 22, 2009 7:27:48 AM EDT > To: "ip" <ip(a)v2.listbox.com> > Subject: [IP] Finding Common Ground on an Open Internet - a joint > statement from Lowell McAdam, CEO Verizon Wireless and Eric Schmidt, > CEO Google. > Reply-To: dave(a)farber.net > > A Technology and Telecommunications Policy Blog > Thursday, October 22, 2009 > > Finding Common Ground on an Open Internet > > The following is a joint statement from Lowell McAdam, CEO Verizon > Wireless and Eric Schmidt, CEO Google. > > > Verizon and Google might seem unlikely bedfellows in the current > debate > around network neutrality, or an open Internet. And while it's true we > do disagree quite strongly about certain aspects of government > policy in > this area--such as whether mobile networks should even be part of the > discussion--there are many issues on which we agree. For starters we > both think it's essential that the Internet remains an unrestricted > and > open platform--where people can access any content (so long as it's > legal), as well as the services and applications of their choice. > > > > There are two key factors driving innovation on the web today. First > is > the programming language of the Internet, which was designed over > forty > years ago by engineers who wanted the freedom to communicate from any > computer, anywhere in the world. It enables Macs to talk to PCs, > Blackberry Storms to iPhones, the newest computers to the oldest > hardware on the planet across any kind of network--cable, DSL, fiber, > mobile, WiFi or even dial up. > > > > Second, private investment is dramatically increasing broadband > capacity > and the intelligence of networks, creating the infrastructure to > support > ever more sophisticated applications. > > > > As a result, however or wherever you access the Internet the people > you > want to connect with can receive your message. There is no central > authority that can step in and prevent you from talking to someone > else, > or that imposes rules prescribing what services should be available. > > > > Transformative is an over-used word, especially in the tech sector. > But > the Internet has genuinely changed the world. Consumers of all stripes > can decide which services they want to use and the companies they > trust > to provide them. In addition, if you're an entrepreneur with a big > idea, > you can launch your service online and instantly connect to an > audience > of billions. You don't need advance permission to use the network. At > the same time, network providers are free to develop new applications, > either on their own or in collaboration with others. > > > > This kind of "innovation without permission" has changed the way we do > business forever, fueling unprecedented collaboration, creativity and > opportunity. And because America has been at the forefront of most of > these changes, we have disproportionately benefited in terms of > economic > growth and job creation. > > > > So, in conjunction with the Federal Communications Commission's > national > plan to bring broadband to all Americans, we understand its decision > to > start a debate about how best to protect and promote the openness of > the > Internet. FCC Chairman Julius Genachowski has promised a thoughtful, > transparent decision-making process, and we look forward to taking > part > in the analysis and discussion that is to follow. We believe this kind > of process can work, because as the two of us have debated these > issues > we have found a number of basic concepts to agree on. > > > > First, it's obvious that users should continue to have the final say > about their web experience, from the networks and software they use, > to > the hardware they plug in to the Internet and the services they access > online. The Internet revolution has been people powered from the very > beginning, and should remain so. The minute that anyone, whether from > government or the private sector, starts to control how people use the > Internet, it is the beginning of the end of the Net as we know it. > > > > Second, advanced and open networks are essential to the future > development of the Web. Policies that continue to provide incentives > for > investment and innovation are a vital part of the debate we are now > beginning. > > > > Third, the FCC's existing wireline broadband principles make clear > that > users are in charge of all aspects of their Internet experience--from > access to apps and content. So we think it makes sense for the > Commission to establish that these existing principles are > enforceable, > and implement them on a case-by-case basis. > > > > Fourth, we're in wild agreement that in this rapidly changing Internet > ecosystem, flexibility in government policy is key. Policymakers > sometimes fall prey to the temptation to write overly detailed rules, > attempting to predict every possible scenario and address every > possible > concern. This can have unintended consequences. > > > > Fifth, broadband network providers should have the flexibility to > manage > their networks to deal with issues like traffic congestion, spam, > "malware" and denial of service attacks, as well as other threats that > may emerge in the future--so long as they do it reasonably, consistent > with their customers' preferences, and don't unreasonably discriminate > in ways that either harm users or are anti-competitive. They should > also > be free to offer managed network services, such as IP television. > > > > Finally, transparency is a must. Chairman Genachowski has proposed > adding this principle to the FCC's guidelines, and we both support > this > step. All providers of broadband access, services and applications > should provide their customers with clear information about their > offerings. > > > > Doubtless, there will be disagreements along the way. While Verizon > supports openness across its networks, it believes that there is no > evidence of a problem today -- especially for wireless -- and no basis > for new rules and that regulation in the US could have a detrimental > effect globally. While Google supports light touch regulation, it > believes that safeguards are needed to combat the incentives for > carriers to pick winners and losers online. > > > > Both of our businesses rely on each other. So we believe it's > appropriate to discuss how we ensure that consumers can get the > information, products, and services they want online, encourage > investment in advanced networks and ensure the openness of the web > around the world. We're ready to engage in this important policy > discussion.

1 0

Re: Consistent asymetric latency on monitoring?
by Rick Ernst 22 Oct '09

22 Oct '09

Resent, since I responded from the wrong address: --- The basic operation of IP SLA is as surmised; payload with timestamps and other telemetry data is sent to a 'responder' which manipulates the payload, including adding its own timestamps, and returns the altered payload. I had to do a mental walk-through, but I think I see how drift can cause this. I'm going to generate some artificial data, graph it, and see if it matches the general waveshape I'm seeing. I purposefully have the traffic generators ntp syncing against the responders. I thought that would keep the clocks more closely in sync. I don't necessarily care if the time is 'right', just that it's the same. What kind of difference should I expect if I sync both generators and responders against the same source, or not sync the responder? I'm thinking that having one source with constant drift may be better than both devices trying to walk/correct the time. Thanks for the input! On Wed, Oct 21, 2009 at 8:01 PM, Rick Ernst <ernst(a)shreddedmail.com> wrote: > Resent, since I responded from the wrong address: > --- > The basic operation of IP SLA is as surmised; payload with timestamps > and other telemetry data is sent to a 'responder' which manipulates > the payload, including adding its own timestamps, and returns the > altered payload. > > I had to do a mental walk-through, but I think I see how drift can > cause this. I'm going to generate some artificial data, graph it, and > see if it matches the general waveshape I'm seeing. > > I purposefully have the traffic generators ntp syncing against the > responders. I thought that would keep the clocks more closely in sync. > I don't necessarily care if the time is 'right', just that it's the > same. What kind of difference should I expect if I sync both > generators and responders against the same source, or not sync the > responder? I'm thinking that having one source with constant drift may > be better than both devices trying to walk/correct the time. > > Thanks for the input! > > > On Wed, Oct 21, 2009 at 7:55 PM, Rick Ernst <ernst(a)shreddedmail.com>wrote: > >> The basic operation of IP SLA is as surmised; payload with timestamps >> and other telemetry data is sent to a 'responder' which manipulates >> the payload, including adding its own timestamps, and returns the >> altered payload. >> >> I had to do a mental walk-through, but I think I see how drift can >> cause this. I'm going to generate some artificial data, graph it, and >> see if it matches the general waveshape I'm seeing. >> >> I purposefully have the traffic generators ntp syncing against the >> responders. I thought that would keep the clocks more closely in sync. >> I don't necessarily care if the time is 'right', just that it's the >> same. What kind of difference should I expect if I sync both >> generators and responders against the same source, or not sync the >> responder? I'm thinking that having one source with constant drift may >> be better than both devices trying to walk/correct the time. >> >> Thanks for the input! >> >> >> On Wednesday, October 21, 2009, Nathan Ward <nanog(a)daork.net> wrote: >> > On 22/10/2009, at 2:31 PM, Perry Lorier wrote: >> > >> > >> > I assume this product works by having a packet with a timestamp sent >> from the source to the destination where it is timestamped again and either >> sent back, or another packet is sent in the other direction. The difference >> between the two timestamps gives you the latency in that direction. >> > >> > >> > I believe a packet is sent, and the target router responds with a >> timestamp. >> > >> > But yeah, timestamps are being compared. >> > >> > I'm with Perry though - sounds like your clocks are drifting. >> > >> > -- >> > Nathan Ward >> > >> > >> > >

3 3

Consistent asymetric latency on monitoring?
by Rick Ernst 22 Oct '09

22 Oct '09

Although the implementation is Cisco-specific, this feels more appropriate for NANOG. We've started rolling out a state-wide monitoring system based on Cisco's "IP SLA" feature set. Out of 5 sites deployed so far (different locations, different providers), we are consistently seeing one-way latency mirror the opposite direction. As source-destination latency goes up, destination-source latency goes down and vice versa. Myself and the monitoring team have ripped apart the OIDs, IP SLA configuration, and monitoring system. We've also built an ad-hoc system to compare the results. It's still consistent behavior. It's not a true mirror; there is definitely variation between the data collection, but at the 10,000 foot level, there is an obvious and consistent mirror to the data. The network topology is independant service providers all providing backhaul to a local ethernet exchange. Has anybody seen this type of behavior? We are solidly convinced that we are using the proper OIDs and making the proper transformations of the data. The two remaining causes appear to be either "natural behavior of the links" and/or "artifact in the IP SLA mechanism". Any ideas? Thanks!

4 3

Re: NetFlow analyzer software
by Michael J McCafferty 22 Oct '09

22 Oct '09

ManageEngine's product is the one that kills browsers because you can tell it to list the top X ASNs. ------Original Message------ From: Brian R. Watters To: nanog(a)nanog.org Cc: nanog(a)nanog.org ReplyTo: Brian R. Watters Subject: RE: NetFlow analyzer software Sent: Oct 19, 2009 10:45 AM We have used this product with great success and its reasonable in pricing and well supported. http://www.manageengine.com/products/netflow/index.html BRW -----Original Message----- From: mark jackson [mailto:markcciejackson@gmail.com] Sent: Monday, October 19, 2009 10:47 AM To: mike(a)m5computersecurity.com Cc: nanog(a)nanog.org Subject: Re: NetFlow analyzer software What's up gold Mrtpg Scrtinizer Nagios Riverbed Cascade Solarwinds Sent from my iPhone Please excuse spelling errors On Oct 19, 2009, at 10:43 AM, "Michael J McCafferty" <mike(a)m5computersecurity.com > wrote: > All, > I am looking for decent netflow analyzer and reporting software > with good support for AS data. > ManagEngine's product crashes or locks up my browser when I try to > list/sort the AS info because it's too large of a list and there is > no way to tell it to show just the top x results. > Plixer's Scrutenizer, while it seems like it's a pretty decent > product, is no longer supporting Linux... We are a Linux shop > (servers, desktops, laptops). > What else is there that I might want to look at? > > Thanks! > Mike > M5Hosting.com > Sent from my Verizon Wireless BlackBerry > Sent from my Verizon Wireless BlackBerry

4 3

Re: ISP customer assignments
by Robert.E.VanOrmer＠frb.gov 22 Oct '09

22 Oct '09

The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each. Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste. Food for thought... >Message: 3 >Date: Mon, 5 Oct 2009 17:47:12 -0400 >From: Dorn Hetzel <dhetzel(a)gmail.com> >Subject: Re: ISP customer assignments >To: bmanning(a)vacation.karoshi.com >Cc: NANOG list <nanog(a)nanog.org> >Message-ID: > <7db2dcf90910051447r5bd7e42fja0b750dceb8d764(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a >little less than 6x10^24Kg. > > 2^128 is around 3.4x10^38. >So in a flat address space we have about one IPV6 address for every 20,000Kg >in the galaxy or for every 20 picograms in the earth... > >One would hope it would last for a while :) > >On Mon, Oct 5, 2009 at 5:32 PM, <bmanning(a)vacation.karoshi.com> wrote: > >> >> considered top posting to irritate a few folks, decided not to. >> >> >> On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: >> > On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: >> > >> > >Whenever you declare something to be "inexhasutable" all you do is >> > >increase demand. Eventually you reach a point where you realize that >> > >there is, in fact, a limit to the inexhaustable resource. >> > >> > This is where I think there is a major disconnect on IPv6. The size >> > of the pool is just so large that people just can't wrap their heads >> > around it. >> > >> > 2^128 is enough space for every man, woman and child on the planet to >> > have around 4 billion /64s to themselves. Even if we assume everyone >> > might possibly need say 10 /64s per person that still means we are >> > covered until the population hits around 2,600,000,000,000,000,000. >> > >> > Chris >> > >> >> here, you expose a hidebound bias to 20th century networking. >> please remember that - with few exceptions - people network >> at a very different level than machines. people don't need >> IP addresses - computing nodes that want to communicate do. >> >> Just for grins, put a unique IPv6 address in every active RFID >> tag. ... and remember that there are RFID printers that can >> put 18 tags on a single A4 sheet. Numbers will become disposible, >> like starbucks coffee cups and MCD's bigmac containers. >> >> --bill >> >>

56 117

equinix is acquiring switch & data
by Cord MacLeod 21 Oct '09

21 Oct '09

http://www.equinix.com/news/press/na/2009/news-5109/ Thought this was relevant.

3 2

Re: IPv6 Deployment for the LAN
by Karl Auer 21 Oct '09

21 Oct '09

On Sat, 2009-10-17 at 20:55 -0400, Ray Soucy wrote: > making use of SLAAC. The concern here is that older hosts with less > than OK implementations will still enable IPv6 without regard for the > stability and security concerns associated with IPv6. Some hosts - very dumb ones or very old ones, probably embedded stacks - may do SLAAC even with a prefix other than 64 bits! Once a stack is broken,, anything is possible, so I'm not sure you win much here. Zig to avoid one dud, you'll have to zag to avoid thenext, and before you know it your life is nothing but dodging. Take the high ground instead. Better to find and cure/replace/isolate broken hosts than break your entire network just to accommodate them. If you start doing the "wrong thing" to accommodate broken hosts, you will never find peace. Zig to avoid one dud; you'll have to zag to avoid the next and before you know it your life is nothing but dodging. Take the high ground instead. Do the advertisements "right", advise sysadmins that hosts should not do SLAAC, and (if you are really concerned about broken hosts) collect MAC address information from your switches and do an automated test of reachability on all SLAAC addresses. You can generate the addresses yourself easily enough from the prefix and the MAC. None should be reachable, and any that are - well, you now know where they are and can take appropriate action. And then block all SLAAC addresses at your routers or firewalls, that'll larn 'em :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer(a)biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

4 4