Re: Big day for IPv6 - 1% native penetration
On 27 Nov 2012, at 14:50, Randy Bush ra...@psg.com wrote: sorry if the facts did not support your conclusion. they do support mine. Pointers to these facts would be greatly appreciated, especially as no one else seems to know where to find them. to repeat, a very large broadband provider has said semi-publicly, and another has corroborated, when they enable ipv6 to an average consumer, 40% of the traffic immediately switches to ipv6. the cause is netflix and youtube, with a bit of help from fb and non-youtube gobble. content is queen. http://6lab.cisco.com/stats/ suggests the figure is even higher, over 50% in some cases. Tim
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On 27 Nov 2012, at 23:44, Owen DeLong o...@delong.com wrote: Given the number of network engineers compared to the number of tunnel broker subscribers just at Hurricane Electric, I don't think that argument holds water. We have actually made using a tunnel broker very easy and provide pretty complete configuration examples for many many platforms. The examples are customized to contain the configuration elements for your particular tunnel so in most cases they are basically copy-and-paste configurations. Indeed. Our students find it pretty straightforward, and they're (relatively) novice developers. I would think that a developer of corporate network-based applications that is worth his salt would be one of the people pushing the IT/Neteng group to give him the tools to do his job. If he waits until they are implementing IPv6 on corporate desktops, he guarantees himself a really bad game of catch-up once that time arrives. I would hope so too. That said if applications are written well, much of the problems can be abstracted. There's been guidance out there for several years, e.g. RFC4038 and many similar white papers etc etc. Tim
Re: Big day for IPv6 - 1% native penetration
On 20 Nov 2012, at 16:42, Mike Jones m...@mikejones.in wrote: If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement. Which ties in with the 50% or so figure you can see at http://6lab.cisco.com/stats/. tim
Re: DHCPv6 and MAC addresses
What about http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03 ? -- Tim On 14 Nov 2012, at 17:46, Ray Soucy r...@maine.edu wrote: Saw yet another attempt at a solution pop up to try and deal with the lack of a MAC address in DHCPv6 messages. I've been giving this some thought about how this should be best accomplished without requiring that host implementations of DHCPv6 be modified. Taking advantage of the relay-agent seems to be the most elegant solution: 1) Any DHCPv6 server on a local segment will already have access to the MAC address; but having a DHCPv6 server on each segment is not ideal. 2) Requests that are relayed flow through a relay-agent, which is on a device that also has access to the MAC address of the client system. Option A: RFC 6422 provides for Realy-Supplied DHCP Options, currently with one option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). You can see the list here: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml I think the quickest solution would be: 1) Adding an RSOO for the client MAC address 2) Get vendors on board to draft and adopt a standard for it on routers, 3) Modify DHCPv6 servers to have support for MAC identification based on the MAC of the local request OR the MAC of the relayed request when the option is present. Option B: The current RELAY-FORW message already includes the link-local address of the client. Perhaps there should be a modification to the privacy extensions RFC to forbid the use of privacy addressing on the link-local scope; at this point we could modify DHCPv6 servers to be able to determine the MAC address for relayed requests based on their link-local address. Unfortunately, the cat is out of the bag on this one, so it would take time to get host implementations modified. I might be overlooking something critical... thoughts? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: Google opens Web Window on their Data Centers
On 18 Oct 2012, at 15:28, Tony Patti t...@swalter.com wrote: http://www.google.com/about/datacenters/gallery/#/ Where the Internet lives - Take a look inside Google's high-tech data centers One of those photos looks like it came directly from the Hive in Resident Evil. Now we know... Tim
Re: FOLO: POLL: 802.1x deployment
On 25 Sep 2012, at 14:50, Jay Ashworth j...@baylink.com wrote: I propose to mention educational institutions by name, There's an awful lot of those using 802.1x. It'll be some list :) Tim
Re: The Department of Work and Pensions, UK has an entire /8
On 18 Sep 2012, at 15:32, Nick Hilliard n...@foobar.org wrote: On 18/09/2012 15:07, Eugen Leitl wrote: Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 Addresses unused? sez who? Oh, it said it on the internet so it must be true. Other than that, I'm totally failing to see what's newsworthy about who or what happens to hold a legacy /8. Could someone explain? Pssst! Want a nice unused /4? Yours cheap! Tim
Re: Return two locations or low TTL [was: DNS caches that support partitioning ?]
On 20 Aug 2012, at 16:39, Tony Finch d...@dotat.at wrote: Shumon Huque shu...@upenn.edu wrote: On 8/20/12 10:11 AM, Tony Finch wrote: The problem is RFC 3484 address selection; getaddrinfo is just the usual place this is implemented. I had believed that there was work in progress to fix this problem with the specs but it seems to have stalled. http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-05 It's in the RFC editor queue actually: http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484bis/?include_text=1 http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484bis/history/ Excellent :-) Tony. I'll ask the IETF admins to link -revise to the bis draft so this continuation is clearer in the tools pages. Tim
Re: shared address space... a reality!
On 15 Mar 2012, at 21:03, valdis.kletni...@vt.edu wrote: On Thu, 15 Mar 2012 13:35:13 PDT, George Herbert said: What, senior network people testing out new test/transitional space at home before they test it at work is bad? Either that, or Randy was being snarky about how long the promise to *only* use the address space for numbering CGN interfaces and not as additional RFC1918 space was going to last in reality So where is that new /10 leaking to already? ;). Tim
Re: Shim6, was: Re: filtering /48 is going to be necessary
On 12 Mar 2012, at 19:30, Owen DeLong wrote: I know my view is unpopular, but, I really would rather see PI made inexpensive and readily available than see NAT brought into the IPv6 mainstream. However, in my experience, very few residential customers make use of that 3G backup port. So what assumptions do you think future IPv6-enabled homenets might make about the prefixes they receive or can use? Isn't having a PI per residential homenet rather unlikely? It would be desirable to avoid NPTv6 in the homenet scenario. Tim
Re: using ULA for 'hidden' v6 devices?
So the issue of ULAs has come up in the IETF homenet WG. The homenet WG is considering routing, prefix delegation, security, naming and service discovery. ULA support is written into RFC6204 (basic IPv6 requirements for CPE routers) so home CPEs should have the capability, and should be able to generate random ULA prefixes. The potential advantage of ULAs is that you have a stable internal addressing scheme within the homenet, while your ISP-assigned prefix may change over time. You run ULAs alongside your PA prefix. ULAs are not used for host-based NAT. The implication is that all homenet devices carry a ULA, though whether some do not also have a global PA address is open for debate. There's a suggestion that ULAs could be used to assist security to some extent, allowing ULA to ULA communications as they are known to be within the homenet. The naming and service discovery elements should remove the need to ever manually enter a ULA prefix; thus the temptation to use 0 instead of random bits for the ULA prefix should be reduced (even if the CPE allows it). Prefix delegation of ULAs within a homenet would be done the same way as for the global PA prefix. There is a proposal (not from within the homenet WG) to use ULAs with NPT66 (RFC6296). That obviously has some architectural implications. Tim
Re: using ULA for 'hidden' v6 devices?
On 26 Jan 2012, at 11:10, George Bonser wrote: The potential advantage of ULAs is that you have a stable internal addressing scheme within the homenet, while your ISP-assigned prefix may change over time. You run ULAs alongside your PA prefix. ULAs are not used for host-based NAT. The implication is that all homenet devices carry a ULA, though whether some do not also have a global PA address is open for debate. Yeah, there's some advantage to that. Have a corp.foo.com domain that is the native domain for the internal machines while the foo.com domain that is visible to the outside world has outside accessible addressing. Perhaps host.local or host.home internally and host.foo.com externally, though the latter could/should work internally as well. There's a suggestion that ULAs could be used to assist security to some extent, allowing ULA to ULA communications as they are known to be within the homenet. Not sure how that assists security unless you simply want to limit site-site communications to your ULA ranges only, then sure. In practice, sites often back each other up and you can have external traffic for site A using site B for its internet access, but that's not a big deal, just need to keep your internal and external traffic separated which any good admin will do as a matter of course, anyway. It was a suggestion a previous homenet session, but the security aspect of homenet is lagging rather behind the current focus of routing and prefix delegation. The usefulness of the suggestion does depend on ULA filtering at borders, and defining the borders. I'm interested in views as one of the editors of the homenet architecture text. Tim
Re: using ULA for 'hidden' v6 devices?
Thanks for the comments Ray, a couple of comments in-line. On 26 Jan 2012, at 12:43, Ray Soucy wrote: Local traffic shouldn't need to touch the CPE regardless of ULA or GUA. Also note that we already have the link local scope for traffic between hosts on the same link (which is all hosts in a typical home network); ULA only becomes useful if routing is involved which is not the typical deployment for the home. The assumption in homenet is that it will become so. ULA is useful, on the other hand, if NPT is used. NPT is not NAT, and doesn't have any of the nastiness of NAT. Well, you still have address rewriting, but prefix-based. I think a lot of the question has to do with what the role of CPE will be going forward. As long as we're talking dual-stack, having operational consistency between IPv4 and IPv6 makes sense. If it's an IPv6-only environment, then things become a lot more flexible (do we even need CPE to include a firewall, or do we say host-based firewalls are sufficient, for example). The initial assumption in homenet is a stateful firewall with hosts inside the homenet using PCP or something similar. Tim
Re: using ULA for 'hidden' v6 devices?
On 26 Jan 2012, at 16:53, Owen DeLong wrote: On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote: Does this mean we're also looking at residential allocations larger than a /64 as the norm? We certainly should be. I still think that /48s for residential is the right answer. My /48 is working quite nicely in my house. There seems to be a lot of discussion happening around a /60 or /56. I wouldn't assume a /48 for residential networks, or a static prefix. So a CPE device with a stateful firewall that accepts a prefix via DHCPv6-PD and makes use of SLAAC for internal network(s) is the foundation, correct? I would expect it to be a combination of SLAAC, DHCPv6, and/or DHCPv6-PD. Which combination may be vendor dependent, but, hopefully the norm will include support for downstream routers and possibly chosen address style configuration (allowing the user to pick an address for their host and configure it at the CPE) which would require DHCP support. Yes, the assumption is multi-subnet in the homenet, with a method for (efficient) prefix delegation internally. Then use random a ULA allocation that exists to route internally (sounds a lot like a site-local scope; which I never understood the reason we abandoned). I can actually see this as a reasonable use of ULA, but, I agree site-local scope would have been a better choice. The maybe you can maybe you cant route it nature of ULA is, IMHO it's only advantage over site-local and at the same time the greatest likelihood that it will be misused in a variety of harmful ways, not the least of which is to bring the brain-damage of NAT forward into the IPv6 enterprise. Site-locals didn't include the random prefix element, thus increasing the chance of collision should two site-local sites communicate. See RFC3879 for the issues. I'm just not seeing the value in adding ULA as a requirement unless bundled with NPT for a multi-homed environment, especially if a stateful firewall is already included. If anything, it might slow down adoption due to increased complexity. I don't believe it adds visible complexity. I think it should be relatively transparent to the end-user. Basically, you have one prefix for communications within the house (ULA) and another prefix for communications outside. The prefix for external sessions may not be stable (may change periodically for operational or German reasons), but, the internal prefix remains stable and you can depend on it for configuring access to (e.g. printers, etc.). Sure, service discovery (mDNS, et. al) should obviate the need for most such configuration, but, there will likely always be something that doesn't quite get SD right somehow. Also, the ULA addresses don't mysteriously stop working when your connection to your ISP goes down, so, at least your LAN stuff doesn't die from ISP death. Consider also long-lived connections for example. I don't think there's a conclusion as yet in homenet about ULAs, nor will a conclusion prevent people doing as they please if they really want to. Tim
Re: IPv6 end user addressing
On 10 Aug 2011, at 16:11, Scott Helms wrote: Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. Well, there is some new effort on this in the homenet WG in IETF. For snooping IPv6 multicast it's MLD snooping rather than IGMP. We use it in our enterprise since we have multiple multicast video channels in use. Tim On 8/10/2011 9:02 AM, Owen DeLong wrote: Bridging eliminates the multicast isolation that you get from routing. This is not a case for bridging, it's a case for making it possible to do real routing in the home and we now have the space and the technology to actually do it in a meaningful and sufficiently automatic way as to be applicable to Joe 6-Mac. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: Mac OS X Lion has DHCPv6
On 25 Jul 2011, at 15:50, Ray Soucy wrote: Just wanted to drop a note as a was pretty harsh on Apple when rumors of them not including DHCPv6 client support were floating about. In the past few days I've also seen people post that OS X doesn't have DHCPv6, because they were looking for DHCPv6 in the UI. Thankfully these reports are false. Just tried it myself on a newly upgraded Mac. Quick testing shows that when Automatic is used for the IPv6 setting, OS X will correctly look at the A, M, and O flags of an IPv6 RA and make use of DHCPv6 when instructed to. Thank you to everyone at Apple who made this happen. Especially James Woodyatt, who I gave a piratically hard time to wearing my end-user hat ;-) +1 Running successfully on Lion with DHCPv6-supplied resolvers at the IETF meeting this week. Tim _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On 10 Jul 2011, at 21:22, Owen DeLong wrote: On Jul 10, 2011, at 12:23 PM, William Herrin wrote: Consider, for example, RFC 3484. That's the one that determines how an IPv6 capable host selects which of a group of candidate IPv4 and IPv6 addresses for a particular host name gets priority. How is a server's address priority NOT an issue that should be managed at an operations level by individual server administrators? Yet the working group which produced it came up with a static prioritization that is the root cause of a significant portion of the IPv6 deployment headaches we face. 3484 specifies a static default. By definition, defaults in absence of operator configuration kind of have to be static. Having a reasonable and expected set of defaults documented in an RFC provides a known quantity for what operators can/should expect from hosts they have not configured. I see nothing wrong with RFC 3484 other than I would agree that the choices made were suboptimal. Mostly that was based on optimism and a lack of experience available at the time of writing. There is another RFC and there are APIs and most operating systems have configuration mechanisms where an operator CAN set that to something other than the 3484 defaults. There is a DHCPv6 option to configure host policy described in http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-01, which is hopefully approaching a WGLC at IETF81. RFC3484 was originally published in 2003, which is a long time ago. And of course it turned out that, with wider operational experience and feedback from the operator community, there were some issues uncovered and some omissions. Perhaps some of those might have been foreseen, but I highly doubt all of them would have. Many of the issues were captured in RFC5220, which led to the work on RFC3484-bis, which is also close to publication. Now, perhaps the DHCPv6 option and the 3484-bis drafts could be posted to the NANOG list at an appropriate time, for example when the docs hit WGLC. But there are a lot of WGLCs out there and the question is then whether the NANOG list, or some special NANOG list for IETF WGLCs, would want all those notifications. As a co-author of the DHCPv6 and 3484-bis drafts, I am quite happy to post about these to NANOG as they approach last call. There are three open issues on 3484-bis that some feedback would be welcomed on. There should be an operations callout as well -- a section where proposed operations defaults (as well as statics for which a solid case can be made for an operations tunable) are extracted from the thick of it and offered for operator scrutiny prior to publication of the RFC. I think this would be a good idea, actually. It would probably be more effective to propose it to IETF than to NANOG, however. Whether it's a separate section in the draft, or a recommendation to post to operators communities (which is more than just NANOG of course), the question as mentioned above is how that's done in a way to get the attention of appropriate operators without drowning them in notifications. Tim
Re: future revenue at risk vs near term cost ratio
On 20 Jun 2011, at 08:00, Doug Barton wrote: On 06/19/2011 23:38, Mike Leber wrote: On 6/19/11 10:47 PM, Paul Vixie wrote: Date: Sun, 19 Jun 2011 22:32:59 -0700 From: Doug Bartondo...@dougbarton.us ... the highly risk-averse folks who won't unconditionally enable IPv6 on their web sites because it will cause problems for 1/2000 of their customers. let me just say that if i was making millions of dollars a day and i had the choice of reducing that by 1/2000th or not i would not choose to reduce it. as much as i love the free interchange of ideas i will point out that commerce is what's paid the internet's bills all these years. Fortunately, 1/2000th was just the now proven false boogey man that people substituted as a placeholder for the unknown. Actually the people using that number had hard facts to back it up, but that was all debated at length already, and I don't see any point going over it again. Except that if there's new evidence showing the figure is lower, let's see it :) The measurements we have made show 0.07% over the past month or so, the figure being users who can access a site with an A record, but not one with an A and record. There are still corner case issues out there, but I suspect that that small percentage may well be down to users who don't update their OS or software. It would be very interesting to know the real causes. I would hope things like 3484-bis and happy eyeballs will help reduce these further. Tim
Re: The stupidity of trying to fix DHCPv6
On 10 Jun 2011, at 11:20, Iljitsch van Beijnum wrote: On 10 jun 2011, at 12:10, sth...@nethelp.no wrote: So where do I point out the stupidity of trying to fix this non-brokenness? Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. It is a mistake to want this, because having the router tell you who the router is gives you fait sharing so less breakage. It's also unnecessary because you still need cooperation from your switches to be safe from rogue DHCPv6 servers even if you go visit all your hosts and turn off stateless autoconfig in an effort to thwart rogue RAs. But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes. Well, remember that, from Google's estimate, only 0.3% of the access networks are IPv6 capable, so there's still 99.7% to deploy. But yes, any changes to add features a la draft-droms-dhc-dhcpv6-default-router-00 would take time, and support in the IETF seems minimal. We're planning to use DHCPv6 and RA (with no prefixes, only for the link local next hop). This is more complex than using DHCPv6 alone, without RA, would be. It is. It's also more robust. And doing this is less complex than trying to change DHCPv6 so you get to use a less complex system in the future after a complex transition. The focus right now should be on getting the existing RA+DHCPv6 to work as intended, and to validate the model within the 0.3% base. I don't buy that a transition from RA+DHCP to DHCP-only is particularly complex though. Turn off the RAs and let DHCP do it's (extra) things. However, you'd then need to know that every device you want to network supports that new DHCP-only operation, and that will be some time off, if it happens at all. Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6. Tim
Re: The stupidity of trying to fix DHCPv6
On 10 Jun 2011, at 15:08, Iljitsch van Beijnum wrote: (And it's insane that Windows still exhibits this completely broken behavior.) We could derail into some broken MacOS X behaviour if you like ;) Tim
Re: The stupidity of trying to fix DHCPv6
On 10 Jun 2011, at 15:24, Iljitsch van Beijnum wrote: On 10 jun 2011, at 16:12, Tim Chown wrote: (And it's insane that Windows still exhibits this completely broken behavior.) We could derail into some broken MacOS X behaviour if you like ;) Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN. Indeed. Well, hopefully MS is listening to the 6to4-advisory draft. Tim
Re: World IPv6 Only Day.
On 9 Jun 2011, at 05:36, Karl Auer wrote: On Wed, 2011-06-08 at 17:37 -1000, Paul Graydon wrote: Dumb question.. what does the switch (L2) have to do with IPv6 (L3), or is it one of those 'somewhere in between the two' things? Well, a modern switch should work fine, even if not directly IPv6 aware, but it won't understand multicast and will generally flood multicast frames to all interfaces. So definitely stipulate IPv6 capability, even for switches And it won't have DHCPv6 snooping, or tools to mitigate rogue RAs. Tim
Re: IPv6 day fun is beginning!
On 8 Jun 2011, at 04:46, Jared Mauch wrote: We have seen a traffic increase but nothing like what I was expecting, nay hoping to see. (i.e.: gigs and gigs of traffic - it does look like ~2x to me in an unscientific eye-look at a chart). Some of it may be down to client behaviour. Despite Facebook being a 30 second TTL, I had to flush my MacOS X DNS cache before I'd get the new record. Tim
Re: Facebook's IPv6 Addresses - LOL
On 8 Jun 2011, at 02:05, David Swafford wrote: This is amusing: In case the formatting get's lost, their initial address includes face:booc and one of the hops along the way is dead:beef. :-) Cisco's is better... $ ping6 www.cisco.com PING6(56=40+8+8 bytes) 2001:630:d0:f103::c0:ffee -- 2001:420:80:1:c:15c0:d06:f00d 16 bytes from 2001:420:80:1:c:15c0:d06:f00d, icmp_seq=0 hlim=238 time=141.937 ms Tim
Re: v6 proof of life
On 7 Jun 2011, at 04:47, Wes Hardaker wrote: On Mon, 06 Jun 2011 23:56:32 +, Paul Vixie vi...@isc.org said: PV it's been a while since i looked at the query stream still hitting PV importantly and happily, there's a great deal of IPv6 happening PV here. Which is reaffirming what many have said for a while: it'll be the server-to-server traffic that will first peak. It's just going to take the client-server relationships years to catch up. Every time I look at my maillogs I've found there is quite a bit of v6 happening. But the web logs show almost nothing. Other way around here... pushing 2% external web traffic by IPv6, but only about 0.2% of mail traffic, and that would be lower if some of our users weren't on various IETF mail lists. Tim
Re: ipv6 day DDoS threat?
On 7 Jun 2011, at 20:04, Leo Bicknell wrote: I thought the goal was to get everyone to try out IPv6. Doesn't that include the miscreants? :) Well, if I was evil I'd be looking for IPv6 back doors tomorrow... Tim
Re: Microsoft's participation in World IPv6 day
On 6 Jun 2011, at 15:30, Jason Fesler wrote: I would have expected the green+azure areas in those graphs to have increased in the past half year but counter-intutitively, it appears that IPv4 only usage is increasing. You're assuming there's significant rollout of IPv6. Everything I've seen so far says that *starts* nowish, and more laterish this year, in any impacting way. Really, we're just just before the start of getting end user adoption to start rising. For our web presence, which has been dual-stack since 2004, we saw external IPv6 traffic rise 0.1% per year to 2010, when it 'leapt' to 1.0% and in 2011 so far the highest we've seen over any month is 1.8%, so it doubled in 2010 and is set to more than double in 2011. OK, so 2% is still small, but from tiny acorns... SMTP is still well under 1% though. Tim
Re: Microsoft's participation in World IPv6 day
On 3 Jun 2011, at 10:13, Owen DeLong wrote: As I said before, provide pointers to resources where users can follow up on actually resolving the issues. Their ISP, their IT department, web pages with additional information on how to diagnose the problem, etc. I would guess a typical user will call their local helpdesk or ISP first if they have problems. They won't have a clue that Google or Facebook are down or slow due to IPv6 connectivity issues. In which case MS providing a syskb entry for those support people to point the user at seems pretty reasonable. One major MS site has gone dual-stack this morning btw :) Tim
Re: Microsoft's participation in World IPv6 day
On 3 Jun 2011, at 01:08, andrew.wallace wrote: World anything day is a sure-shot bet win at an anti-climax, and an industry failure and waste of investment and publicity campaign. The day passing without any significant userland issues would make it a success. It's a good opportunity to ensure you have the right measurement tools in place so you can learn something from the day. For sites that have dual-stack deployed, a one-day peek into the future where perhaps 15% or more of external traffic will be IPv6 is pretty useful, given it's currently 1% or less. Tim
Re: Yahoo and IPv6
On 31 May 2011, at 22:31, Voll, Toivo wrote: Netalyzr (http://n3.netalyzr.icsi.berkeley.edu/analysis) finds no issues with my IPv6 status, but alerts me to the fact (since confirmed by switching to IE) that Google Chrome defaults to IPv4 rather than IPv6, and consequently a lot of the testing tools claim that my IPv6 is broken. I'm a little confused there - the current Chrome prefers IPv6, and also now includes code to allow fast failover to IPv4 in the event IPv6 connectivity is down/slow (300ms headstart). I had some issues with Netalyzer detecting my dual-stack status, which the chaps there are helping with. Tim
Re: OPERATIONAL: Royal Wedding expected to break traffic records
On 29 Apr 2011, at 03:26, Rob V wrote: Not just that ... Youtube is apparently expecting 400 million (?!) viewers! http://news.yahoo.com/s/zd/20110428/tc_zd/263745 The doomsayers are out with freshly painted signs ... the Internet will break tomorrow morning! :-) Must say the quality of the Youtube coverage has been very good, in all senses. Interesting early on the youtube feed lagged 20+ seconds behind the 'live' BBC TV, then during the ceremony was almost simulataneous. Tim
Re: World of Warcraft may begin using IPv6 on Tuesday
On 27 Apr 2011, at 00:21, Bernhard Schmidt wrote: Kevin Day toa...@dragondata.com wrote: ... To get ahead of the issue, we've put an IPv6 option into the World of Warcraft interface with patch 4.1. So as IPv6 starts to become more widely available the game will already be prepared to handle the switch over. For most players, the IPv6 checkbox will remain grayed out until IPv6 becomes available in your area. Once available, enabling this feature will require WoW.exe to detect a valid IPv6 connection to the internet on the computer you are playing from. At some point in the future, WoW realm servers will be able to use IPv6 in addition to the current IPv4. If IPv6 is enabled, the game will attempt to establish an IPv6 connection first. If unable to find an IPv6 connection, or if the IPv6 option is disabled/grayed out, the game will make an IPv4 connection instead. This should not cause any connection or performance issues. --- At some point in the future does not sound like we will see much IPv6 traffic immediately, but who knows. Is anyone seeing some traffic that might point to IPv6 adoption on the servers? I arranged a test this morning. With a laptop running 4.1 on a dual-stack network the IPv6 option is greyed out under Network Options. I'm assuming your suggestion that the Blizzard servers are not yet enabled is probably correct, but that the clients now have capability. Would be interesting to know what they consider a 'valid IPv6 connection'. Tim
Re: SIXXS contact
On 27 Apr 2011, at 08:19, Mikael Abrahamsson wrote: On Tue, 26 Apr 2011, Andrew Kirch wrote: I'm not complaining, but I would point out that if these free brokers are the public face of IPv6 for many hobbyists (and much of the various software run on/over the internet is written by volunteers, and/or given away for free), we aren't going to get there. The big deafening silence from SIXXS is really unfortunate in that it does actively affect my opinion of IPv6, my willingness to spend time implementing it, pestering my upstream about it, or having my business give a damn about it. Yes I know they're volunteers, but how much does that matter? So you would prefer that they shut down their service rather than provide current level of support? I've had very prompt and good replies from SixXS when I've contacted them. Equally students I know who use HE brokers are very happy with their service, e.g. HE have added features in response to feedback. Tim
Re: World of Warcraft may begin using IPv6 on Tuesday
On 23 Apr 2011, at 23:29, Tom Hill wrote: On Sat, 2011-04-23 at 13:09 -0500, Kevin Day wrote: For those that don't know, World of Warcraft is currently the largest online role playing game, with somewhere over 12 million subscribers. Version 4.1 of the game is expected to be released this Tuesday, which will be automatically pushed to all clients. The current Beta version of 4.1 has full IPv6 support. In the beta, it's automatically enabled if you have native IPv6 (non-6to4, non-Teredo). While Blizzard has been pretty silent about this, barring a last minute revert or delay of this patch, there are suddenly going to be a bunch more users that can potentially use IPv6. And these users are the type who are going to be especially sensitive to latency, jitter and packet loss, since this is a real-time game platform. For those of you with Help Desks who have to support users like this, the associated setting in the game's Options menu is apparently called Enable IPv6 when available. It's apparently grayed out if you do not have IPv6 at all, unchecked by default if you are on 6to4 or Teredo, and checked by default if you are on native v6. The tooltip says: Enables the use of IPv6, the technology behind the next-generation Internet. Requires IPv6 connectivity to the internet. Checking this box without IPv6 connectivity may prevent you from playing WoW. Anyone from Activision/Blizzard who would like to chime in with more details? :) I can't say that I'm from Blizzard, but I'm *seriously* impressed by them for making this happen. Kudos to Blizzard! Confirmed in patch notes: http://us.battle.net/wow/en/game/patch-notes/ptr-patch-notes Tim
Re: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? )
On 12 Apr 2011, at 07:33, Michael DeMan wrote: Call me and old 'hard case' - but I prefer that when I get information via email, that if possible, the relevant information show up immediately. Call me lazy I guess - but I would expect that most folks on this list have also understood good user interface design, and that the least amount of work that needs to be done for the receiver to be able to get their information is frequently the best solution. Well indeed, top-posting is just so much more efficient given the volumes of email most of us probably see each day. Back when receiving an email was an event, and your xbiff flag popping up was a cause for excitement, taking time to scroll/page down to the new bottom-posted content in the reply was part of the enjoyment of the whole 'You have new mail' process. But I'm afraid times have changed; bottom-posted email is now an annoyance to most just as a slow-loading web page would be. Tim
Re: Barracuda Networks is at it again: Any Suggestions as to an Alternative?
On 9 Apr 2011, at 04:56, Dobbins, Roland wrote: On Apr 9, 2011, at 10:51 AM, John Palmer (NANOG Acct) wrote: My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used http://www.ironport.com/ I don't know quite how high a performance you need. If it's just email spam/viruses you are concerned with, you can run MailScanner for free, see http://www.mailscanner.info.It's been around for 10 years now and used by a lot of big organisations, many of which are listed on the web site.Written by a colleague here at University of Southampton, hence the plug. If you install and run it yourself, there's a good community mail list for support and tips. If you want a commercial version then Fort Systems (http://www.fsl.com) can do that, and they also have a companion product BarricadeMX that's a pretty decent pre-filter system. Tim
Top webhosters offering v6 too?
Which of the big boys are doing it? Tim
Re: Significant Announcement (re: IPv4) 3 February - Watch it Live!
On 3 Feb 2011, at 14:49, Igor Ybema wrote: I think they were under a TCP-SYN attack :) The video was super choppy from here and I have bandwidth to burn at this time of the day. A little disappointing, but I'm sure (fingers crossed) someone will have a clean recording of it that they will make available. I saw that also. Switched to windows media stream which was working fine. However,.. stream was not available on a IPv6 only host. Epic fail! :) Seemed the nro web site was v6 but the embedded video from flash.merit.edu was IPv4-only? Tim
Re: NIST IPv6 document
On 7 Jan 2011, at 15:12, Justin M. Streiner wrote: On Thu, 6 Jan 2011, Jeff Wheeler wrote: On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong o...@delong.com wrote: 1. Block packets destined for your point-to-point links at your borders. There's no legitimate reason someone should be Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those networks want NDP to be the reason they choose to make this change. Correct me if I'm wrong, but wouldn't blocking all traffic destined for your infrastructure at the borders also play havoc with PTMUD? Limiting the traffic allowed to just the necessary types would seem like a reasonable alternative. Recommendations for PTMUD-friendly filtering are described in RFC 4890. Tim
Re: NIST IPv6 document
On 6 Jan 2011, at 17:17, Jack Bates wrote: A randomly setup ssh server without DNS will find itself brute force attacked. Darknets are setup specifically for detection of scans. One side effect of v6, is determining how best to deploy darknets, as we can't just take one or two blocks to do it anymore. We'll need to interweave the darknets with the production blocks. I wish it was possible via DHCPv6-PD to assign a block minus a sub-block (hey, don't use this /64 in the /48 I gave you). It could be that darknets will have to go and flow analysis is all we'll be left with. As RFC6018 suggests, this could be done dynamically on any given active subnet. Tim
Re: NIST IPv6 document
On 6 Jan 2011, at 18:20, Owen DeLong wrote: On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote: On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made port-scanning easy, attractive, productive, and commonplace. I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. You are mistaken... Host scanning followed by port sweeps is a very common threat and still widely practiced in IPv4. In our IPv6 enterprise we have not seen any 'traditional' port scans (across IP space), rather we see port sweeps on IPv6 addresses that we expose publicly (DNS servers, web servers, MX servers etc). This is discussed a bit in RFC5157. We have yet to see any of the ND problems discussed in this thread, mainly I believe because our perimeter firewall blacks any such sweeps before they hit the edge router serving the 'attacked' subnet. The main operational problem we see is denial of service caused by unintentional IPv6 RAs from hosts. I think this is an interesting thread though and we'll run some tests internally to see how the issue might (or might not) affect our network. Tim
Re: IPv6 - real vs theoretical problems
On 7 Jan 2011, at 06:11, Owen DeLong wrote: That's a draft, and, it doesn't really eliminate the idea that /48s are generally a good thing so much as it recognizes that there might be SOME circumstances in which they are either not necessary or insufficient. As a draft, it hasn't been through the full process and shouldn't be considered to have the same weight as an RFC. While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may never do so. The IETF data tracker shows draft-ietf-v6ops-3177bis-end-sites is under IESG review, with comments currently being made, see https://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/ which also notes the draft has strong support so is likely to be published soon. The document is only guidance regardless. Tim
Re: NIST IPv6 document
On 6 Jan 2011, at 15:10, Lamar Owen wrote: Ok, perhaps I'm dense, but why is the router going to try to find a host that it already doesn't know based on an unsolicited outside packet? Why is the router trusting the outside's idea of what addresses are active, and why isn't the router dropping packets on the floor destined to hosts on one of its interfaces' local subnets that it doesn't already know about? If the packet is a response to a request from the host, then the router should have seen the outgoing packet (or, in the case of HSRP-teamed routers, all the routers in the standby group should be keeping track of all hosts, etc) and it should already be in the neighbor table. There's some interesting discussion around this point in RFC6018, which discusses the use of greynet monitoring in sparsely populated IPv6 subnets. This approach may be one method to help detect and or mitigate such attacks. Tim
Re: Low end, cool CPE.
On 12 Nov 2010, at 12:55, Bjørn Mork wrote: This is far too diffuse. You'll get a yes, we've got IPv6. You should at least add - IPv6 packet filtering and policy management (at least simple access lists) snip The point is: We've been asking for IPv6 for too long. That's just one bit in a packet header. We need to start asking for the features we expect, which is a lot more than that bit. For IPv6 CPE requirements, you might want to look at http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-07 and comment on the IETF v6ops list. Tim
Re: Email over v6
On 8 Jul 2010, at 03:00, Antonio Querubin wrote: On Wed, 7 Jul 2010, Zaid Ali wrote: Are there any folks here who would be inclined to do SMTP over IPv6? I have a test v6 network with is ready to do email but getting some real world data to verify headers would be more helpful. Please send me an email offlist if you are interested. The NANOG list mail server is IPv6-enabled. Your above message came into our mail server over IPv6. So by just using this list you'll be testing your mailserver over IPv6. So for example here's Antonio's reply header going to the list over v6 transport then out to our site also by v6: Received: from s0.nanog.org (s0.nanog.org [2001:48a8:6880:95::20]) by crow.ecs.soton.ac.uk (crow.ecs.soton.ac.uk [2001:630:d0:f110::25b]) envelope-from nanog-bounces+tjc=ecs.soton.ac...@nanog.org with ESMTP id m673381995435214jA ret-id none; Thu, 08 Jul 2010 03:03:19 +0100 Received: from localhost ([::1] helo=s0.nanog.org) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from nanog-boun...@nanog.org) id 1OWgRQ-000HxK-8m; Thu, 08 Jul 2010 02:02:20 + Received: from outgoing03.lava.net ([2001:1888:0:1:202:b3ff:fe1d:6b98]) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from t...@lava.net) id 1OWgPi-000G1S-Si for nanog@nanog.org; Thu, 08 Jul 2010 02:00:35 +
Re: IP4 Space
On Fri, Mar 12, 2010 at 11:42:50AM +1100, Mark Andrews wrote: Does it make sense/work to do this for internal operations even if our outside connections are IPv4 only (forget about tunneling). Even more mundane questions like how to deal with IPv4 only networked printers when everything else is IPv6? As for IPv4 only printers you can continue to run dual stack internally forever if you want. Otherwise put them on their own vlan and connect to them over NAT64 or run a proxy service. Our approach to v6 deployment has always been about enabling capability where it is available. The trick is then to have the right tools to manage and monitor it. The interesting thing about printers is that even quite low end network printers (like the HP Laserjet I have) have had IPv6 for quite a while. You can even configure DHCPv6 on the one I'm using. Just look for capabilities/features as you refresh equipment and it makes things that little easier. Tim
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On Tue, Feb 16, 2010 at 08:14:13AM +0100, Mikael Abrahamsson wrote: On Tue, 16 Feb 2010, Nathan Ward wrote: Perhaps they have Teredo and 6to4, and could not reach you via 6to4 so instead used Teredo, or, any number of scenarios. I think their only IPv6 connectivity was Teredo (for instance, they're behind NAT), and thus they used it to get the IPv6 only content. So for our case here at Southampton our web presence www.ecs.soton.ac.uk is advertised via both A and records. What we see is less than 1% of our IPv6 traffic coming from the Teredo prefix. 6to4 is at most 1%. I think the reason we see less 6to4 than some might expect is that a lot of our IPv6 accesses may be from other academic networks where IPv6 is available 'properly'. I had our web guys send me a log of recent Teredo accesses to our servers and the user agents were varied.As Tore suggested, Opera 9.8 was on the list (since fixed), but also some Mozilla-based entries from both Linux and Windows platforms. Total entries: 761 Opera 9.8: 354 Firefox 3.5.7 (Windows): 61 Firefox 3.5.7 (Linux): 96 Iceweasel 3.5.6 (Linux): 8 Mozilla 4.0 (Windows): 242 Not a huge sample, but it shows Windows UAs hitting us from the Teredo prefix. -- Tim
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On Fri, Feb 12, 2010 at 08:16:56AM +1100, Mark Andrews wrote: If you can't get native IPv6 then use a tunneled service like Hurricane Electric's (HE.NET). It is qualitatively better than 6to4 as it doesn't require random nodes on the net to be performing translation services for you which you can't track down the administrators of. You can get /48's from HE. Our external IPv6 web accesses are still very low, but have grown linearly over the last five years from 0.1% in 2005/06 to 0.5% of total web traffic now. Internally of course our figures are higher. Of that IPv6 traffic, 1% comes from 2002::/16 prefixes. Even less from Teredo prefixes. I guess we could run stats against known TB prefixes to determine who is using those. -- Tim
Re: ISP customer assignments
On Tue, Oct 20, 2009 at 10:15:39PM -0400, Roland Dobbins wrote: On Oct 20, 2009, at 8:41 PM, Karl Auer wrote: In practice, changing stuff, especially globally, is not as simple as that. From http://tools.ietf.org/html/rfc4192: 'Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft.' We tried Fred's procedure some 4 years ago within 6NET: http://www.6net.org/publications/deliverables/D3.6.2.pdf The 'prefix schizo' actually worked out quite well. The routing changes and multi-refix links generally behaved as expected. Address selection did its thing. The basics worked as advertised. The complexity is of course not in the routing and hosts, it's as pointed out in the firewalls and similar devices (yours and more importantly other people's) for which new capabilities of IPv6 can't help. We captured some of these thoughts at the time in http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout-05 and since then Brian Carpenter has produced a much more up to date and rounded set of thoughts in http://tools.ietf.org/html/draft-carpenter-renum-needs-work-03 We're far from a magic button press. In smaller networks RFC4192 is workable, but the larger and more complex the network/site, there's still so many open issues that it's completely understandable the people will want PI. -- Tim
Re: ISP customer assignments
On Thu, Oct 08, 2009 at 10:24:30AM -0400, Curtis Maurand wrote: Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble? At this stage we're only 'being cavalier' with 1/8th of the space. We can be more restrictive with the the other 7/8ths if those predicting rapid consumption turn out to be correct. Right now that would be a nice problem to have. Tim
Re: ISP customer assignments
On Mon, Oct 05, 2009 at 11:34:51AM -0700, Wayne E. Bouchard wrote: Am I the only one that finds this problematic? I mean, the whole point of moving to a 128 bit address was to ensure that we would never again have a problem of address depletion. Now I'm not saying that this puts us anywhere in that boat (yet) but isn't saying oh, lets just put a /64 on every interface pretty well ignoring the lessons of the last 20 years? Surely a /96 or even a /112 would have been just as good. The current guidance applies only to one /3 out of eight. Different rules could be applied to the others. Like I said, I'm not necessarily saying we're going to find ourselves in that boat again but it does seem as though more thought is required. (And yes, I fully realize the magnitude of 2^64. I also fully realize how quickly inexhaustable resources become rationable.) As it happens, Windows boxes now generate random interface IDs (not based on MACs), which could have easily been 32 bits with the default subnet 96 bits long, rather than 64 bits. But we are where we are and we do have interesting ideas like CGAs as a result. -- Tim
Re: Repeated Blacklisting / IP reputation
On Sun, Sep 13, 2009 at 12:45:03PM -0400, Christopher Morrow wrote: On Wed, Sep 9, 2009 at 11:48 PM, Mark Andrews ma...@isc.org wrote: skip a note about isc having quite a few legacy blocks Note we all could start using IPv6 and avoid this problem altogether. There is nothing stopping us using IPv6 especially for MTA's. that'd solve the spam problem... for a while at least. (no ipv6 traffic == no spam) 30% of our incoming IPv6 SMTP connections are spam. -- Tim
Re: IPv6 Confusion
On Wed, Feb 18, 2009 at 03:05:43PM -0600, Dale W. Carder wrote: On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote: Is there something like this already that anyone knows of? http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt There will be an update of this prior to March's IETF. If anyone has any comments please send them directly to me and we'll try to work them in. Hopefully with this text as a 'why' and the RA Guard text as a 'how' we have some things to point vendors at. Though as some have pointed out RA Guard isn't applicable everywhere (just as SeND isn't too). -- Tim
Re: Network diagram software
On Wed, Feb 11, 2009 at 04:11:38PM +0100, Mathias Wolkert wrote: Thanks all for your input. One thing that hits me is how different networks are documented. Are there any best practice communicated (RFC/IETF)? As an aside, for ASCII network diagrams a la Internet Draft, I found that Email Effects (http://www.sigsoftware.com/emaileffects/) was rather useful. Obviously there's only so much you can do in 80 columns of ASCII :) -- Tim
NANOG stream - projector screens
Hi, Just a minor comment - yesterday the projector screen appeared larger in the streamed picture (I think we only saw one screen?) and was readable. Today the view seems to have been made wider, and both screens appear brighter and smaller and no longer readable on the HD stream. Would be nice if they were :) -- Tim
Re: NANOG stream - projector screens
Wow that was fast - much better now and the HE presentation graph legends are even readable :) Thanks! Tim On Tue, Jan 27, 2009 at 09:13:32AM -0500, Betty Burke wrote: Thanks for the note... we are making the adjustment. Betty Merit Network Inc. Merit/NANOG Project Manager - Original Message - From: Tim Chown t...@ecs.soton.ac.uk To: nanog@nanog.org Sent: Tuesday, January 27, 2009 9:10:52 AM GMT -05:00 US/Canada Eastern Subject: NANOG stream - projector screens Hi, Just a minor comment - yesterday the projector screen appeared larger in the streamed picture (I think we only saw one screen?) and was readable. Today the view seems to have been made wider, and both screens appear brighter and smaller and no longer readable on the HD stream. Would be nice if they were :) -- Tim -- Tim
Re: Mcast mpeg2 and unicast h.264 for NANOG-45
Nice quality feed, thanks, receiving fine here on UK academic network campus. Tim On Mon, Jan 26, 2009 at 09:57:26AM -0400, Anton Kapela wrote: The source for 233.0.59.45 is kona.doit.wisc.edu and has address 128.104.23.100, hope that helps! -Tk On Mon, Jan 26, 2009 at 9:47 AM, Antonio Querubin t...@lava.net wrote: On Mon, 26 Jan 2009, Anton Kapela wrote: mcast feed: 25 mbit HDV, mpeg Transport Stream, UDP: 233.0.59.45 port 1234 Not seeing the mcast feed at all. What's the source address so we can try to mtrace to it? Antonio Querubin whois: AQ7-ARIN -- Tim
Re: Inauguration streaming traffic
On Tue, Jan 20, 2009 at 12:38:11PM -0500, Christopher Morrow wrote: On Tue, Jan 20, 2009 at 12:26 PM, Brian Wallingford br...@meganet.net wrote: On Tue, 20 Jan 2009, Jay Hennigan wrote: :We're a regional ISP, about 80% SMB 20% residential. We're seeing :almost double our normal downstream traffic right now. Anyone else? We're seeing traffic levels nearly 2x normal. On 9/11/01, we were probably only about 50% higher than the norm. Of course, lots has changed, so that's probably not a fair comparison. As an aside... thanks to BBC for streaming this, I couldn't find another source that wasn't overloaded/jerky/ugly :( The Beeb's HD multicast feed is about 23Mbit/s to the host, and we received it at quite decent (subjective) quality here on a JANET-connected university site. The feed runs continuously (as far as any 'as-is' test stream does :) and this morning is pretty flawless. The interesting aspect of the HD stream was seeing how various systems coped with the CPU load. It was good to have some HD content available that encouraged people to install vlc, find out a little about multicast, and system issues in receiving it. Thanks again Beeb :) -- Tim
