Re: The state of TACACS+
On Dec 30, 2013 9:01 AM, "Saku Ytti" wrote: > > On (2013-12-30 08:49 -0500), Christopher Morrow wrote: > > > Nor accounting... > > I think this is probably sufficient justification for TACACS+. I'm not sure if > command authorization is sufficient, as you can deliver group via radius which > maps to authorized commands. > But if you must support accounting, per-command authorization comes as free > gift more or less. > Yes. Per-command auth and accounting is needed. So what we need is tacacs over TLS (sctp / ipv6) I agree tacacs is long in the tooth and needs to be revisited and invested in. Please take my money (serious) CB > -- > ++ytti >
Re: ddos attacks
On Dec 19, 2013 4:25 PM, "Dobbins, Roland" wrote: > > > On Dec 19, 2013, at 6:12 AM, cb.list6 wrote: > > > I am strongly considering having my upstreams to simply rate limit ipv4 UDP. > > QoS is a very poor mechanism for remediating DDoS attacks. It ensures that programmatically-generated attack traffic will 'squeeze out' legitimate traffic. > I agree. But ... i am pretty sure i am going to do it. Trade offs. > > During an attack, 100% of the attack traffic is ipv4 udp (dns, chargen, whatever). > > Have you checked to see whether you and/or your customers have open DNS recursors, misconfigured CPE devices, etc. which can be used as reflectors/amplifiers on your respective networks? > > Have you implemented NetFlow and S/RTBH? Considered building a mitigation center? > > <http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html> > > Do you work with your peers/upstreams/downstreams to mitigate DDoS attacks when they ingress your network? > Not answering any of that. But thanks for asking. > There are lots of things one can do to increase one's ability to detect, classify, traceback, and mitigate DDoS attacks, yet which aren't CAPEX-intensive. > I think ipv4 udp is just going to become operationally deprecated. Too much pollution. It is really an epic amount of trash / value ratio in ipv4 udp. I recommend folks enable their auth dns servers for ipv6 ... and dont run open resolvers CB > --- > Roland Dobbins // <http://www.arbornetworks.com> > > Luck is the residue of opportunity and design. > >-- John Milton > >
Re: ddos attacks
On Thu, Dec 19, 2013 at 8:18 AM, Edward Lewis wrote: > On Dec 18, 2013, at 18:12, cb.list6 wrote: > > > I am strongly considering having my upstreams to simply rate limit ipv4 > > UDP. It is the simplest solution that is proactive. > > > Recently it's been said that when a protocol is "query/response" (like > DNS), willingly suppressing responses might be as harmful as passing all > the traffic. > > This comes from a presentation at October's DNS-OARC workshop: > > https://indico.dns-oarc.net//getFile.py/access?contribId=4&resId=0&materialId=slides&confId=1 > > This is a "what is possible in theory" presentation, said to help you set > your expectation whether this is a true threat or not. > > The underlying message is that while a querier is waiting for a response, > there is a window of vulnerability in which a forged response might be > accepted. If the responder elects not to respond, they increase the (time) > duration of that window. > > While "smart" rate limiting exhibits benefits I suspect "simple" rate > limiting might have some undesirable consequences. > > I completely agree. This why i have not yet implemented IPv4 UDP rate-limiting yet, but it seems inevitable for 2014 if these attacks go on. The profile i have in mind is when UDP exceeds 5x the baseline, then tail-drop. Keep in mind, when UDP exceeds 5x the baseline, the chances are are 99% that the UDP is consuming the entire ISP pipe and everything is rate-limited due to the pipe being saturated. So, this is not a simple either / or. This is degrade UDP proactively or suffer all traffic degrading because there is a huge DDoS coming in (which is the current situation). > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStarYou can leave a voice message at > +1-571-434-5468 > > Why is it that people who fear government monitoring of social media are > surprised to learn that I avoid contributing to social media? > >
Time to stopy saying there is no IPv6 traffice: was Re: ddos attacks
On Wed, Dec 18, 2013 at 5:03 PM, Jon Lewis wrote: > On Wed, 18 Dec 2013 valdis.kletni...@vt.edu wrote: > > On Wed, 18 Dec 2013 15:12:28 -0800, "cb.list6" said: >> >> I am strongly considering having my upstreams to simply rate limit ipv4 >>> UDP. It is the simplest solution that is proactive. >>> >> >> What are the prospects for ipv6 UDP not suffering the same fate? >> > > Roughly 0%, but there's so little v6 traffic compared to v4, you probably > don't have to worry about v6 attack traffic yet...particularly if you're > not dual stack yet. :) > > I understand that your answer about nil IPv6 traffic may be appropriate for your network, but for many of us IPv6 is currently a non-trivial amount of traffic that is growing quickly. And, in some cases, IPv6 is the dominate amount of traffic. Here are some quick stats of a few select familiar names from http://www.worldipv6launch.org/measurements/ Google Fiber 70% Virginia Tech 61% Verizon Wireless 40% Comcast 20% AT&T Wireline 15% T-Mobile US 6% > -- > Jon Lewis, MCP :) | I route > | therefore you are > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ >
Re: ddos attacks
On Aug 2, 2013 10:31 AM, wrote: > > I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them? > > Scott > > I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive. The facts are that during steady state less than 5% of my aggregate traffic is ipv4 udp. During an attack, 100% of the attack traffic is ipv4 udp (dns, chargen, whatever). The attacks last for about 10 minutes, so manual intervention is not possible. Automated intervention has its own warts. Conclusion: ipv4 udp is a toxic dump. It is a shame that DNS (can be tcp), webrtc (should be sctp), and Google's QUIC are going to suffer the rate limited fate. My advice to them is to get aways from ipv4 udp, the problem is getting worse not better. CB
Re: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding?
On Dec 11, 2013 5:45 PM, "Larry Sheldon" wrote: > > On 12/11/2013 9:21 AM, Tim Franklin wrote: >>> >>> Just because something is public doesn¹t mean you have to accept >>> ALL traffic, it just means you have to anticipate any potential >>> problems based on Larry knowing your address rather than imagining >>> him standing at the front gate of your gated community. ;) (let¹s >>> torture that analogy!) >> >> >> There's still a gated community? I thought that particular piece of >> routing joy was long gone... >> >> Sorry, I'll get my coat. Tim. > > > I'm not sure that was an analogy--it was exploring the exact meanings of two words. > > In any case, I submit that an address behind a gate is not a "public address". > > But my point is, my address is in fact public, not behind any gates--displayed once on the post that supports the mail box, again inside the mailbox door for the mail person, and on a sign on the house next to the door. > > Which public display grants to no one any right of access to the interior of my house (indeed to no part of the property save the path from the street to the front door). > > Similarly, my IP address could be publicly visible but that does not grant any right of access to the equipment it attaches to. > > (I might leave my front door wide open--that STILL does not grant any RIGHT of access. It does depend on archaic notions of honest and regard for rights to keep people out.) > > > I'm done. > It's maybe better to think of an ip address as a phone number. Most people get a better experience if they can make and receive calls. Your line of thinking is that you would only like to make outbound phone calls. That's cool, for you. The rest of us will be playing xbox online, which explicitly recommends unsolicited inbound connections, meaning your result will be better if you do not statefully firewall and allow xbox to form arbitrary meshes of ipsec http://tools.ietf.org/agenda/88/slides/slides-88-v6ops-0.pdf CB > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) >
Re: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding?
On Dec 10, 2013 2:32 PM, "Geraint Jones" wrote: > > On 11/12/13 10:13 am, "Alex White-Robinson" wrote: > > > >Wotcha, > > > >>Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) > >>since you have to treat each boxes as if it was public. > > > >I see this kind of statement surprisingly often. Having a public address > >doesn't make a device public. > > Yes it does, it makes end to end connectivity work again. NAT broke that > (and its one of the best things about v6). People have been relying on the > fact that you need rules to get through a NAT to reach a box - thereby > having NAT work as an inbound firewall. NAT != Security. > > But yes having a public address means your box is public, you have to do > something to STOP traffic getting to it. With NAT you have to do something > to ENABLE traffic to get to it. > Correct. IPv6 correctly supports the end to end model. Firewalls can be scalably implemented on host, not middle boxes. The firewall mindset is locked in from the win2k days, NAT reinforced that, and it is worth re-evaluated removing firewalls with ipv6 Question: are nanog meeting networks stateful firewalled? Follow up question -- if there is no firewall, do folks experience a higher degree of malware infection after the meeting ? CB > >I don't really see a drive to have devices exposed to the internet without > >a stateful device in front of them in IPv6 world. People shouldn't allow > >unsolicited connections to hit your internal workstation on any address > >scheme. > > > >Cheers, > >Alex. > > > > > >Date: Tue, 10 Dec 2013 05:56:41 +1300 > >From: Pieter De Wit > >To: nz...@list.waikato.ac.nz > >Subject: Re: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? > >Message-ID: <52a5f649.7070...@insync.za.net> > >Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > > >Hi, > > > >I normally use a combination of "1" and "2". I prefer 1 for weird and > >"not nat friendly" protocols, like SIP or some other application. The > >general rule of thumb is to use number 2 in other cases. In both setups, > >remember to deploy local firewalls as well. This will help for the case > >when a box on the subnet is hacked. > > > >My other twist is to deploy "1" without the private NIC, along with > >local firewalls (and as you said, dedicated FW). > > > >Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) > >since you have to treat each boxes as if it was public. > > > >Cheers, > > > >Pieter > > >
Re: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO)
On Dec 6, 2013 5:16 PM, "Michael Thomas" wrote: > > On 12/06/2013 05:54 AM, Mark Radabaugh wrote: >> >> >> I realize most of the NANOG operators are not running end user networks anymore. Real consumption data: >> >> Monthly_GBCountPercent >> <100GB 3658 90% >> 100-149 368 10% >> 150-199 173 4.7% >> 200-249 97 2.6% >> 250-299 50 1.4% >> 300-399 27 0.7% >> 400-499 9 0.25% >> 500-599 4 0.1% >> 600-699 4 0.1% >> 700-799 3 0.1% >> >800 1 0.03% >> >> Overall average: 36GB/mo >> >> >> The user at 836MB per month is on a 3.5Mbps plan paying $49.95/mo. Do we do anything about it? No - because our current AUP and policies say he can do that. >> > > Thanks for the stats, real life is always refreshing :) > > It seems to me -- all things being equal -- that the real question is whether Mr. Hog is impacting your > other users. If he's not, then what difference does it make if he consumes the bits, or if the bits over > the air are not consumed at all? Is it because of transit costs? That seems unlikely because Mr. Hog's > 800gb is dwarfed by your 3658*36gb (almost three orders of magnitude). > > If he is impacting other users, doesn't this devolve into a shaping problem which is there regardless > of whether it's him or 4 people at 200GB? > > Mike > In a cell network, mr. Hog is most definately negatively impacting users on the same radio sector and backhaul, both of which are dimensioned and operated (like the internet as a whole) on statistical multiplexing. If mr hog is blasting 50mbs on a 100meg link 24/7, nobody will perceive 100mbs since 50mbs is always consumed by mr hog. Statistical multiplexing works great 99% of the time, and i personally would rather not engineer the whole system to fight the 1% extreme users CB
Re: Question related to Cellular Data and restrictions..
On Dec 4, 2013 11:31 PM, "Warren Bailey" < wbai...@satelliteintelligencegroup.com> wrote: > > Blanket reply.. :) > > So at what point does unlimited mean unlimited? Roaming agreements have always been two sided. In my case.. I roam on to AT&T's network, the same as AT&T folk roam into tmo when they do not have coverage. At the end of the month the two are reconciled and someone gets paid. If you are selling a service that is making generalized assurances in connectivity (nationwide 4g let netwokr) , you should make a best effort to honor that. It wasn't even a fair amount of bandwidth.. I could deal with a 2gb a month cap or something.. But I am now able to use my unlimited data in 100 countries without incurring additional charges.. Are we going to start saying that international roaming costs are lower than domestic on a regularly used network? > > I literally feel like I'm taking crazy pills here. Tmo and Att are far from small fish.. And a 50mb per month cap is absolute bullshit. Figure it into your business line.. Or do the honest thing and don't offer the service. How you guys are justifying this is BEYOND me. You can buy a ds1 for several hundred dollars per month.. And unlimited customers get 50 megs a month for data.. You can't even check email over the month on that. I'm not an abusive user.. I don't download or use my cellular data connection for hacked hotspot use.. Not to mention the hotspot I do have with them has 10gb a month nationwide.. So I can use my puck for 10gb..but my phone (on the SAME TOWER) is different? > > That is like saying sms costs network providers money.. (don't bring up ran gear or smsc costs.. It's not related) > If you have a beef with tmo, here is the complaint department https://mobile.twitter.com/JohnLegere or you can email him at john.leg...@t-mobile.com You can probably just forward this thread Given that tmo now has free (rate limited) intl data roaming, it is a bummer to see domestic roaming is now less well served. I think in belt tightening years limiting domestic roaming saved substantial cost ... since it can be expensive having some users living on roamed networks CB > > Sent from my Mobile Device. > > > Original message > From: Joshua Goldbard > Date: 12/04/2013 4:10 PM (GMT-09:00) > To: Henry Yen > Cc: nanog@nanog.org > Subject: Re: Question related to Cellular Data and restrictions.. > > > Ting is an MVNO (just like my company 2600hz) and while it would violate the terms of my NDA to confirm the 10x number I can say that we found it to be prohibitively expensive. > > One should be aware that, just like in the IP transit world, the small players have different rules than the big kids. It might be prohibitively expensive for us, but it's a different order of magnitude for a carrier like Sprint proper. > > Hope that helps. > > Cheers, > Joshua > > P.S. shameless plug: we provide white-label cellular service to operators including full provisioning and call control plus it can be tied back into corporate phone systems (and it's open source!!). > > Sent from my iPhone > > On Dec 4, 2013, at 2:59 PM, "Henry Yen" wrote: > > > On Wed, Dec 04, 2013 at 22:18:12PM +, Joshua Goldbard wrote: > >> ... When you send your data > >> over a partners network it raises your wireless company's cost of > >> delivering service, in some cases so much so that you become > >> unprofitable. > > > > Some folks over at Ting(.com) suggest that the cost for data roaming is as > > high as ten times that for voice/SMS roaming, which is why they don't charge > > extra for the latter, and do not at all provide the former. > > > > -- > > Henry YenAegis Information Systems, Inc. > > Senior Systems Programmer Hicksville, New York > > (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) > > > > >
Re: MTR for Android?
On Sep 5, 2013 3:34 PM, "Jay Ashworth" wrote: > > Does anybody know if the program has been ported, or re-created there? > > I have searched the market, but not found anything... at least nothing whose description includes the letters mtr. > - jra Mtr is here http://dan.drown.org/android/pkg/ CB > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Google's QUIC
On Fri, Jun 28, 2013 at 8:00 PM, Leo Bicknell wrote: > > On Jun 28, 2013, at 5:24 PM, Octavio Alvarez > wrote: > >> That's the point exactly. Google has more power and popularity to >> influence adoption of a protocol, just like with SPDY and QUIC. > > This is the main reason why I'm very supportive of this effort. I'm a bit > skeptical of what I have read so far, but I know that it's nearly impossible > to tell how these things really work from theory and simulations. Live, real > world testing is required competing with all sorts of other flows. > > Google with their hands in both things like www.google.com and Chrome is in > an interesting position to implement server and client side of these > implementations, and turn them on and off at will. They can do the real > world tests, tweak, report on them, and advance the state of the art. > > So for now I'll reserve judgement on this particular protocol, while > encouraging Google to do more of this sort of real world testing at the > protocol level. > +1, Google is smart for doing this. It is important to push the boundaries on performance. QUIC is UDP, and UDP is the right step for now. And, hopefully this stuff gets rolled up into ILNP stack features. Yes ILNP needs stack changes, think big. Not all things can NOT be a simple incremental tweaks. ILNP will be a revolution. QUIC is simply a revolt on performance issues with TCP in today's low-loss, high latency (mobile), and middle box encumbered networks. CB > Now, how about an SCTP test? :) > > -- >Leo Bicknell - bickn...@ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > >
Re: huawei
On Sat, Jun 15, 2013 at 8:35 AM, Randy Bush wrote: > i wonder if and how many governments are worried about when the nsa > tells cisco to send the kill switch signal to their routers. > > randy > What kill switch ? http://www.cisco.com/en/US/products/csa/cisco-sa-20090325-udp.html http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120530-iosxr
Re: Bogons filtering
On Jun 10, 2013 7:50 PM, "Jayram A. Deshpande" wrote: > > Hello, > > > With IPv4 being almost exhausted[1] , I am curious to know how many net admins have the Bogon filtering ACLs still hanging around ? > No bogon filters here. Retiring bogon filters is great, one less process to maintain. > Google even gave me this expired Internet Draft [2] that seems to have been intended as a BCP. > > > Regards, > -Jay. > > > [1] https://www.arin.net/resources/request/ipv4_countdown.html > [2] https://tools.ietf.org/id/draft-vegoda-no-more-unallocated-slash8s-01.txt > > -- > "Subvert the paradigm." - C.K. Prahlad > >
Re: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday)
On Sat, Jun 8, 2013 at 10:28 AM, Warren Bailey wrote: > Japan has been doing this exact thing for close to 10 years.. Why is it hard Japan has been doing what exactly? Can you cite it? I am pretty sure by "exact thing" you do not mean EMBMS. > to do? Buffer the video 30 seconds or use a codec that doesn't blow? I use > my phone via "4G"and stream media constantly. If you take a look at Charlie Yes, and by "streaming", you mean downloading discrete video chunks with http. That is the state of the industry today video over unicast TCP / HTTP. It is not EMBMS A very large percentage of mobile data traffic today is video via HTTP http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-520862.html I do not know of any EMBMS deployments. CB > Ergen's behavior lately, there won't need to be a lte tv.. Lightsquared is > about to be murdered for breaking the Gps and dish will take over as largest > provider in the US. Now taking bets. > > > Sent from my Mobile Device. > > > > Original message > From: "cb.list6" > Date: 06/08/2013 9:52 AM (GMT-08:00) > To: Brandon Butterworth > Cc: nanog@nanog.org > Subject: Re: Webcasting as a replacement for traditional broadcasting (was > Re: Wackie 'ol Friday) > > > On Sat, Jun 8, 2013 at 3:08 AM, Brandon Butterworth > wrote: >>> I was at an incentive auction discussion earlier in the week where it >>> was suggested that the broadcasters see a rosy future with ATSC >>> beaming to mobile, but there is still work to be done. >> >> They might wish, after many years there has been little take up of the >> various systems created to do this (we've spent quite some time working >> on the standards). Nobody wanted to pay for it to be in handsets, other >> features were seen as more important uses of the space/power. >> >> The next try is LTE Broadcast >> http://en.wikipedia.org/wiki/EMBMS >> > > Without going into painful detail on the policy, technology or > economics, i really don't see EMBMS being widely deployed and > successful > > Not to say some folks won't try to make pigs fly. Vendors make a lot > of money at the "pigs flying" BU. > > I do imagine the invisible hand of tariffs guiding users to better use > broadcast TV and Radio for live events. > > CB > >> brandon >> >
Re: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday)
On Sat, Jun 8, 2013 at 3:08 AM, Brandon Butterworth wrote: >> I was at an incentive auction discussion earlier in the week where it >> was suggested that the broadcasters see a rosy future with ATSC >> beaming to mobile, but there is still work to be done. > > They might wish, after many years there has been little take up of the > various systems created to do this (we've spent quite some time working > on the standards). Nobody wanted to pay for it to be in handsets, other > features were seen as more important uses of the space/power. > > The next try is LTE Broadcast > http://en.wikipedia.org/wiki/EMBMS > Without going into painful detail on the policy, technology or economics, i really don't see EMBMS being widely deployed and successful Not to say some folks won't try to make pigs fly. Vendors make a lot of money at the "pigs flying" BU. I do imagine the invisible hand of tariffs guiding users to better use broadcast TV and Radio for live events. CB > brandon >
Re: "It's the end of the world as we know it" -- REM
On Apr 25, 2013 10:29 PM, "joel jaeggli" wrote: > > On 4/25/13 10:16 PM, Matt Palmer wrote: >> >> On Thu, Apr 25, 2013 at 07:49:03PM -0700, Michael Thomas wrote: >>> >>> On 04/25/2013 07:27 PM, Owen DeLong wrote: AWS stands out as a complete laggard in this area. >>> >>> Heh... that's why I put all kinds of question marks and hedges :) >>> That's disappointing about aws. On the other hand, if aws lights >>> up v6, a huge amount of content will be v6 capable in one swell-foop. >> >> Even if the only thing that supported IPv6 was ELB, and everything else was >> still IPv4 internally, that'd put a lot of traffic on IPv6 very quickly, and >> ELB is something *entirely* controlled by AWS (you CNAME to an ELB FQDN, AWS >> takes care of resolution and proxies a TCP connection to your instance). > > elb ipv6 support has been in place for some time (may 2011 for us east and ireland) > > "IPv6 support is currently available in the following Amazon EC2 regions: US East (Northern Virginia), US West (Northern California), US West (Oregon), EU (Ireland), Asia Pacific (Tokyo), and Asia Pacific (Singapore).? Yeah, I thought AWS ELB supported ipv6 too. But if your ELB is tied to a VPC, that is NOT supported. I learned that one the hard way, and now that is one less site that would be ipv6 but is not. CB. >> >> >> - Matt >> > >
Re: Google incorrect IPv6 GeoIP
Heather, I see the same thing from my arpnetworks vps [cbyrne@chair6 ~]$ traceroute6 www.google.com traceroute6 to www.google.com (2404:6800:4003:801::1010) from 2607:f2f8:a8e0::2, 64 hops max, 12 byte packets 1 2607:f2f8:a8e0::1 1.657 ms 0.976 ms 0.750 ms 2 2001:504:13::1a 1.728 ms 10.591 ms 0.756 ms 3 2001:4860:1:1:0:1b1b:0:19 0.873 ms 0.907 ms 0.833 ms 4 2001:4860::1:0:29b3 1.195 ms 138.964 ms 2001:4860::1:0:991 1.633 ms 5 2001:4860::8:0:2996 1.645 ms 2001:4860::8:0:2995 1.929 ms 1.484 ms 6 2001:4860::1:0:47 99.059 ms 99.272 ms 2001:4860::1:0:75 99.079 ms 7 2001:4860::1:0:298 99.372 ms 111.549 ms 99.972 ms 8 2001:4860::1:0:26ff 103.146 ms 103.317 ms 103.029 ms 9 2001:4860::1:0:337f 166.821 ms 203.479 ms 166.468 ms 10 2001:4860:0:1::18f 167.021 ms 167.378 ms 166.896 ms 11 2404:6800:8000:4::e 167.039 ms 167.099 ms 167.254 ms [cbyrne@chair6 ~]$ dig www.google.com ; <<>> DiG 9.6.-ESV-R3 <<>> www.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50127 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;www.google.com.IN ;; ANSWER SECTION: www.google.com. 15 IN 2404:6800:4003:801::1010 ;; AUTHORITY SECTION: google.com. 271198 IN NS ns1.google.com. google.com. 271198 IN NS ns3.google.com. google.com. 271198 IN NS ns2.google.com. google.com. 271198 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 61968 IN A 216.239.32.10 ns3.google.com. 61968 IN A 216.239.36.10 ns4.google.com. 61968 IN A 216.239.38.10 ns2.google.com. 61968 IN A 216.239.34.10 ;; Query time: 1 msec ;; SERVER: 208.79.88.7#53(208.79.88.7) ;; WHEN: Fri Apr 12 08:04:59 2013 ;; MSG SIZE rcvd: 196 [cbyrne@chair6 ~]$ On Fri, Apr 12, 2013 at 7:53 AM, Heather Schiller wrote: > Forwarded to folks I think should be able to help.. > > --Heather > > > On Thu, Apr 11, 2013 at 7:13 PM, Yang Yu wrote: > >> For some reason Google redirects requests from Dreamhost's IPv6 block >> 2607:f298::/32 to google.com.hk >> >> $ wget http://www.google.com >> --2013-04-11 16:06:45-- http://www.google.com/ >> Resolving www.google.com... 2607:f8b0:400c:c01::93, 173.194.75.99, >> 173.194.75.147, ... >> Connecting to www.google.com|2607:f8b0:400c:c01::93|:80... connected. >> HTTP request sent, awaiting response... 302 Found >> Location: >> http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww >> [following] >> --2013-04-11 16:06:46-- >> >> http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww >> Resolving www.google.com.hk... 2607:f8b0:400c:c01::6a, 173.194.75.105, >> 173.194.75.99, ... >> Connecting to www.google.com.hk|2607:f8b0:400c:c01::6a|:80... connected. >> HTTP request sent, awaiting response... 302 Found >> Location: http://www.google.com.hk/ [following] >> --2013-04-11 16:06:46-- http://www.google.com.hk/ >> Reusing existing connection to www.google.com.hk:80. >> HTTP request sent, awaiting response... 200 OK >> Length: unspecified [text/html] >> Saving to: “index.html” >> >> >> The report IP problem form >> (https://support.google.com/websearch/contact/ip?rd=1) does not think >> IPv6 addresses are valid. >> >> Can someone help with this issue? >> >> Thanks. >> >> Yang >> >>
Re: Class E addresses in the wild
On Thu, Mar 21, 2013 at 12:06 PM, George Herbert wrote: > It is (or was) fairly commonly in use among internal nets which > overflowed RFC 1918 or have to internetwork with other heavy users of > RFC 1918 space. I know of at least two service providers and one cell > network who were using it for that 3 years ago. > I am pretty sure Class E is completely defunct and not used anywhere since Cisco and Juniper routers do not forward the packets (circa 2008 testing) and no known host accept it as a valid address, AFAIK. CB > Someone leaking internal routes for such? Or attempt to hijack the space? > > Only the Shadow knows... > > > On Thu, Mar 21, 2013 at 11:17 AM, Donald Eastlake wrote: >> No authorized IETF use that I know of. See >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml >> >> Thanks, >> Donald >> = >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e...@gmail.com >> >> >> On Thu, Mar 21, 2013 at 2:09 PM, Buz Dale wrote: >>> Is anyone else seeing a lot of Class E address space (240.0.0.0/4) at their >>> borders? Has this space been reinstated in some as yet unknown to me RFC? >>> Thanks, >>> Buz >>> >>> -- >>> Buz Dale >>> buzd...@gmail.com >>> GMT -5 >>> -- >>> >>> >>> >>> -- >>> Buz Dale >>> buzd...@gmail.com >>> GMT -5 >>> -- >> > > > > -- > -george william herbert > george.herb...@gmail.com >
ILNP FTW ... Was Re: [c-nsp] DNS amplification
On Mar 19, 2013 8:26 PM, "David Conrad" wrote: > > Leo, > > On Mar 19, 2013, at 11:57 AM, Leo Bicknell wrote: > > In a message written on Tue, Mar 19, 2013 at 11:33:33AM -0700, David Conrad wrote: > >> LISP doesn't replace BGP. It merely adds a layer of indirection so you don't have to propagate identity information along with routing topology, allowing much greater aggregation. > > The problem with LISP is that when the complexity of the entire > > system is taken into account it is not signficantly more efficient > > than the current system. > > When was the last time you (as a network operator) cared about the efficiency of the entire system? > > LISP (and similar) system are inherently more complex because they're adding a new element to the network -- TANSTAAFL. The point is that the complexity is added at the edge where it is easy/cheap (per node or site). Yes, entire system complexity goes up. However from the perspective of the core where life is fast/expensive, complexity goes down since identity is separated from location. > As I see it, that is the fundamental problem with LISP. It wants edge investment to solve a core problem. I don't carry full routes in my core, but LISP wants me to do something to solve a problem I don't have. And, that something looks a lot like an ATM SVC (dynamic tunnels ?) That said, IMHO, ILNP is a lot more interesting in the locator / id split space As well as general evolution of internet architecture. LISP just has had better marketing and simpler code. Ya know, this problem would also largely be solved if everyone just switched to ipv6 and stopped using those disjointed tiny v4 blocks. Oh, but that would break Skype. Nevermind. CB > > A LISP network is a similar model, with LISP nodes caching rather than linecards. > > You're comparing the equivalent of a DNS lookup with a FIB lookup. Yes, there is a performance hit when you do the mapping of identity to location (TANSTAAFL), however this is at the edge in the millisecond DRAM-stored connection initiation world, not in the core in the nanosecond SRAM-stored packet forwarding world. > > Regards, > -drc > >
