- Test - lists.nanog.org

RE: Interesting google redirects.
by Skywing 10 Mar '11

10 Mar '11

(Apologies for the top-post.) I've been experiencing the same. Seems like their geolocation data is busted (since last morning at least), if I had to take a guess. - S -----Original Message----- From: Wil Schultz <wschultz(a)bsdboy.com> Sent: Thursday, March 03, 2011 7:25 To: NANOG Operators Group <nanog(a)nanog.org> Subject: Interesting google redirects. Has anyone else had complaints that www.google.com is occasionally redirecting (http 302) to www.google.com.hk this morning? -wil

12 11

Geolocation Info Correction Needed at Apple, Yahoo, MSN
by Schiller, Heather A 10 Mar '11

10 Mar '11

If anyone is listening, would you be so kind as to update geolocation info for the following-- they are in Mexico, not Argentina. inetnum: 186.64.16.176/29 status: reallocated owner: Infor Global Solutions Mexico SA de CV ownerid: MX-IGSM-LACNIC responsible: Hector Garcia Bernal address: Montes Urales 505 Lomas de Chapultepec, , address: - mexico city - country: MX I couldn't find information on how to get geolocation errors corrected for Apple, Yahoo or MSN on their websites. It would be nice if folks would also update http://nanog.cluepon.net/index.php/GeoIP which details the process for several large sites. Thanks, --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241 security(a)verizonbusiness.com

4 4

dhcp6 solicit
by Jeroen van Aart 10 Mar '11

10 Mar '11

I was doing some packet scanning on one of my IPv6 enabled servers and I found traffic such as the following frequently (IPs slightly edited): 02:23:02.410360 IP6 fe80::ff78.546 > ff02::2.547: dhcp6 solicit Not having done too much ipv6 packet scanning yet I am curious to know if this is a mis-configured dhcp6 server somewhere? Is this a rather common thing to see in IPv6 traffic? The addresses are not mine, neither do I run a dhcpv6 daemon (no need for it). Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html

2 1

ipv6 question
by ann kok 10 Mar '11

10 Mar '11

Hi I read ipv6forum.pdf about ipv6 It said MTU must be at least 1280 bytes (1500+) Does it mean to set the mtu over 1500 I set my linux box eth0 as 2001:db8:cafe:1111::12/64 but I can't ping it inet6 2001:db8:cafe:1111::12/64 scope global tentative ls it this problem? Thank you # ping6 2001:db8:cafe:1111::12 PING 2001:db8:cafe:1111::12(2001:db8:cafe:1111::12) 56 data bytes >From ::1 icmp_seq=1 Destination unreachable: Address unreachable >From ::1 icmp_seq=2 Destination unreachable: Address unreachable

4 3

Anyone has a contact with IP clue at VerizonBusiness?
by Alex Yuriev 09 Mar '11

09 Mar '11

I know it may be a stretch but is there a remote possibility that someone knows anyone inside Verizon Business who has an ounce of clue about IPv4 address allocation and routing? It seems the panic over IPv4 scarcity is resulting in the most peculiar ideas bubbling up in the IP provisioning side which must be stomped out of existence before such ideas create signigicant connectivity issues. Thanks, Alex

3 2

L3DSR server side bits open sourced
by Jan Schaumann 09 Mar '11

09 Mar '11

Hello, Some of you may remember my talk at Nanog51 about L3DSR (http://nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog…) I had promised that we'd try to get the server side bits released soon. While it took longer than anticipated, I'm glad to be able to announce that as of about ten minutes ago, they have finally escaped^Wbeen released into the wild: https://github.com/yahoo/l3dsr It's possible that we will try to put together a more formal announcement of this, but since I had promised the release at Nanog, I figured it'd be fair to let you guys know first. :-) Vanity plug: https://twitter.com/#!/jschauma/status/45181937089908736 Happy L3DSR'ing! -Jan

5 7

How many IPv6 BGP routes are you planning for in DFZ?
by Jeff Wheeler 09 Mar '11

09 Mar '11

On Wed, Mar 9, 2011 at 2:19 AM, George Bonser <gbonser(a)seven.com> wrote: > The ipv4-ipv6-2 CAM profile in 5.1 gives 768K v4 routes and 64k v6 > routes which should be good for quite a while. That is provided you How many IPv6 BGP routes are folks typically planning for in the DFZ before a hardware upgrade is required? Here are some relevant figures (note that my script makes some minor errors but this is good enough for discussion purposes): IPv6: Unique Origin ASes seen: 3287 Examined 4705 active routes IPv4: Unique Origin ASes seen: 36707 Examined 352688 active routes Making some assumptions, let's say every active ASN in DFZ will announce a mean of 1.4 IPv6 routes (the number seen today.) If IPv6 grows from under 10% of ASNs today to 100% of ASNs in a year or two, we will see about 53k IPv6 routes in DFZ. Keep in mind that many, if not most, ASNs originating IPv6 routes today have substantially no production services on IPv6, and they may deaggregate more in the future, etc. Some folks seem to believe that not every ASN will announce routes to the DFZ. I don't think that is a safe assumption upon which to base purchasing decisions for routers which should have a life-cycle of several years. Whether or not networks *should* announce more than one route, or any routes at all, seems debatable; but when making router purchasing decisions, I don't want to tell my clients two years from now that they have to spend capital dollars on routers just to gain IPv6 FIB. I also don't want to tell them they have to filter some routes, and make any BGP customers unhappy, and live with other downfalls of that unfortunate compromise. I am certainly not deploying any boxes that will only do 64k IPv6 FIB in default-free part of my clients' networks. It certainly will work now, and will almost certainly be safe in one year. In two years, it seems a little questionable. Beyond that time-frame, it is much easier to justify new routers, as ports become cheaper and faster; but I still do not want my clients to be forced to buy new routers simply because of overly-optimistic assumptions about IPv6 DFZ size. Really, I would like vendors to make IPv4 and IPv6 FIB come from the same pool (with obviously different allocation sizes) or allow me to configure the partitioning as I see fit. This has been the case for quite a few platforms for many years. I am not comfortable guessing at whether I will first need to exceed 500K IPv4 routes (maybe we won't even see that number) or 64K IPv6 routes (this seems a virtual certainty, but when it happens is hard to say.) Once you add L3VPN into your list of concerns, your future FIB needs become even more difficult to predict. -- Jeff S Wheeler <jsw(a)inconcepts.biz> Sr Network Operator / Innovative Network Concepts

2 1

Re: IPv4 address shortage? Really?
by Vadim Antonov 09 Mar '11

09 Mar '11

Christopher Morrow <morrowc.lists(a)gmail.com> wrote: > Gbqq Haqrejbbq jbhyq ybir lbhe fbyhgvba! Cebcf! I'm sure he would:) Though I can't claim a credit for the idea... it's way too old, so old, in fact, that many people have forgotten all about it. Mark Andrews <marka(a)isc.org> wrote: > This has been thought of before, discussed and rejected. Of course, it was Discussed and Rejected. I fall to my knees and beg the forgiveness from those On High who bless us with Their Infinite Wisdom and Foresight. How could I presume to challenge Their Divine Providence? Mea culpa, mea maxima culpa. ...well, kind of. What you don't mention is that it was thought to be ugly and rejected solely on the aesthetic grounds. Which is somewhat different from being rejected because it cannot work. Now, I'd be first to admit that using LSRR as a substitute for straightforward address extension is ugly. But so is iBGP, CIDR/route aggregation, running interior routing over CLNS, and (God forbid, for it is ugly as hell) NAT. Think of it, dual stack is even uglier. At least, with LSRR-based approach you can still talk to legacy hosts without building completely new and indefinitely maintaining a parallel legacy routing infrastructure. Scott W Brim <scott.brim(a)gmail.com> wrote: > There are a number of reasons why you want IP addresses to be > globally unique, even if they are not globally routed. And do you have it now? The last time I checked, NAT was all over the place. Ergo - global address uniqueness (if defined as having unique interface address labels) is not necessary for practical data networking. In fact, looking at two or more steps in the source route taken together as a single address gives you exactly what you want - the global uniqueness, as long as you take care to alternate disjoint address spaces along the path and designate one of these spaces (the existing publicly routeable space) as the root from which addressing starts. Bill Manning <bmanning(a)vacation.karoshi.com> wrote: > just a bit of renumbering... Ah, that's nice, but I don't propose expanding use of NAT. Or renumbering on massive scale. In fact I want to remind that NAT was never a necessity. It's a temporary fix which gave IPv4 a lot of extra mileage and became popular precisely because it didn't break networking too much while allowing folks to keep using the existing stuff. The real problem with NAT is called "P2P" (and I think it will become important enough to become the death of NAT). Jima <nanog(a)jima.tk> wrote: > This seems like either truly bizarre trolling, I guess you haven't been around NANOG (and networking) too long, or you'd be careful to call me a troll:) What I want is to remind people that with a little bit of lateral thinking we can get a lot more mileage out of the good old IPv4. Its death was predicted many times already. (Let me remember... there was that congestion collapse, then it was the routing table overwhelming the IGPs, and then there was that shortage of class Bs and routing tables outgrowing RAM in ciscos, and then there was a heated battle over IP address ownership, and there was the Big Deal about n^2 growth of iBGP mesh). I don't remember what was the deal with Bob Metcalfe and his (presumably eaten) hat. Something about Moore's Law? > or the misguided idea of someone who's way too invested in IPv4 and > hasn't made any necessary plans or steps to implement IPv6. "Too invested in IPv4"? Like, the Internet and everybody on it? You know, I left the networking soapbox years ago, and I couldn't care less about the religious wars regarding the best ways to shoot themselves in the foot. The reason why I moved to different pastures was sheer boredom. The last interesting development in the networking technology was when some guy figured out that you can shuffle IP packets around faster than you can convert a lambda from photons to electrons - and thus has shown that there's no technological limitation to the bandwidth of Internet backbones. > you'd have to overhaul software on many, many computers, routers, > and other devices. (Wait, why does this sound familiar?) You probably missed the whole point - which is that unlike dual-stack solution using LSRR leverages existing, installed, and paid for, infrastructure. > too bad we don't have a plan that could be put into action sooner The cynical old codgers like yours truly have predicted that the whole IPv6 saga would come precisely to that - when it was beginning. The reason for that is called the Second System Effect of which IPv6 is a classical example. A truly workable and clean solution back then would be to simply add more bits to IPv4 addresses (that's what options are for). Alas, a lot of people thought that it would be very neat to replace the whole piston engine with a turbine powerplant instead of limiting themselves to changing spark plugs and continuing on the way to the real job (namely, making moving bits from place A to place B as cheap and fast as possible). Now, we don't have a problem of running out of IPv4 addresses - NAT takes care of that, and will continue to do so for many years more. We do have a problem of having no way[*] to initiate connections to boxes hidden behind NATs. Which is bad for P2P applications. To solve this problem three things need to be done: 1) to create network infrastructure which can haul packets with extended addresses (be it IPv4 or IPv6) and extend network stacks in the OSes to support this transport; 2) to create a way to map domain names to those addresses; 3) to get applications to work with the extended addresses. You also need a clean migration path from legacy to the new architecture (which IPv6 lacks), just to stay in the realm of practical. 1 and 3 are seriously expensive. 2 is relatively easy as DNS has provisions for expansion which were actually used (instead of reinventing the wheel, thankfully). The issue #1 can be sidestepped by use of LSRR as I suggested. #2 and #3 are, to a considerable extent, already solved by the people implementing IPv6. Now, listen carefully: you don't have to use IPv6 packets to use IPv6 addresses. In fact, all we need to get benefits of extended addressing w/o going to the trouble of implementing native or tunneled IPv6 networks is a simple shim (either within kernels or within language libraries) which takes IPv6 address/socket and translates it into IPv4 socket with appropriate LSRR option information attached. (A small subset of IPv6 addresses could be set aside for the purpose... one /32 or such; just so you can still have IPv6 in all its glory if you wish). The entire amount of development for a Unix-like OS is about 500 lines of code (that's my educated guess based on the gut feeling developed while I was hacking various Unix kernels for living since v6). My question to the community - is it interesting enough? I.e. should I spend my time on writing I-D on IPv4 Extended Addressing, or will I be dismissed as a troll for my trouble? --vadim [*] chownat exceeds even my tolerance for ugliness, though the expoit itself is an elegant use of the quasi-paradox from probability theory.

4 8

OT: What vexes VoIP users?
by Eric Brunner-Williams 09 Mar '11

09 Mar '11

OT, but NANOG is almost always good for quick clue ... For those who have residential VoIP, what provider {features | bugs} are most vexing? For those who provision residential VoIP, what subscriber {expectations | behaviors} are most vexing? Thanks in advance, Eric

27 82

Re: [afnog] Suspicious request for IP address space
by Randy Bush 08 Mar '11

08 Mar '11

> Even more suspicious is the fact that there is no organisational > information attached to the request and the sender used a gmail > address. They supplied an Indian telephone number. it is about this point where i realize that i am overloaded with real work, hit delete, and get back to that work. randy

4 5