Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days
On 19/08/2011, at 4:18 AM, Owen DeLong wrote: It'd really suck for end users to start actively avoiding IPv6 connectivity because it keeps breaking and for organisations that have active records to break peoples connectivity to their resources. +1 -- I'm all for publishing records as everyone knows, but, if you publish records for a consumer facing service, please support and monitor that service with a similar level to what you do for your IPv4 versions of the service. The coming years are going to be difficult enough for end-users without adding unnecessary anti-IPv6 sentiments to the mix. Owen +1 to Owen's comment. I'd also add some more comments: A lot of eyeballs that have v6 right now are the people with a lot of clue. Do you want these people, who'll often be buying or recommending your services to rate your ability to deliver as a fail? Our experience with IPv6 consumer broadband has been that the early adopters are the people who, well, goto IETF meetings, follow standards and ask the bloody hard questions. Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated as HE?? :-) ) most end users prefer IPv6 over IPv4. Deeply this means there is a tendency for v6 traffic to grow and be more important to connectivity than you may imagine. The tipping point for IPv6 traffic being dominant I suspect is going to be a lower threshold of take up than people might expect. Consider this when thinking about the level of thought you give to IPv6 infrastructure and PPS rates. MMC
Re: IPv6 end user addressing
Hi, The CPE we're providing to our customers from Billion (78xxN/NL, 74xxNX etc) and AVM (Fritz!Box 7290 and 7390) that have IPv6 code do have IPv6 stateful firewalls. Our requirement was that, as much as possible that the IPv4 and IPv6 outcome should be similar (with obvious exceptions around NAT). Without IPv6 having a firewall in the CPE it'd be a difficult thing to convince people to do. And here I'm speaking about normal customers. The people who've taken up our IPv6 service so far are not typical customers but people who are, well, fairly switched on to this stuff. So we had to look beyond the initial desires of our customers to what the general population would want. (ie. someone who's regularly attending IETF meetings typically has a different outlook on what they want in a CPE vs what my Dad wants). MMC On 14/08/2011, at 5:49 AM, Carlos Martinez-Cagnazzo wrote: You are assuming (as many, many people do) that public addresses equal no firewall, and that IPv6 CPEs will have no stateful firewalling. The thing is, just as they have a stateful firewall now for IPv4 they will have one for IPv6 as well. The fact that your addressing is public (or let's say, routeable) does not make a difference. Again, it is not the NAT layer of your IPv4 CPE that protects you, it's the stateful firewall. regards Carlos On Thu, Aug 11, 2011 at 2:52 PM, Greg Ihnen os10ru...@gmail.commailto:os10ru...@gmail.com wrote: On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote: On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote: Owen wrote: -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Wednesday, August 10, 2011 9:58 PM To: William Herrin Cc: nanog@nanog.orgmailto:nanog@nanog.org Subject: Re: IPv6 end user addressing On Aug 10, 2011, at 6:46 PM, William Herrin wrote: On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong o...@delong.commailto:o...@delong.com wrote: Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use. Nah... That's short-term thinking. The future holds advanced pantries with RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc. And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;) This definitely helps explain your misconceptions about NAT as a security tool. Globally addressable != globally reachable. Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful. And your average home user, whose WiFi network is an open network named linksys is going to do that how? Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys? Owen I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an appliance about to break, call repairman idiot light on appliances yet. But I predict the coming of IPv6 to the home in a big way will have unintended consequences. I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, password for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6. Greg -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net = -- Matthew Moyle-Croft Peering Manager
Re: IPv6 end user addressing
On 11/08/2011, at 1:33 PM, Owen DeLong wrote: On Aug 10, 2011, at 7:45 PM, Mark Newton wrote: On 11/08/2011, at 8:42 AM, Owen DeLong wrote: I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future. I see the lack of agreement on whether /48 or /56 or /60 is good for a home network to be a positive thing. As long as there's no firm consensus, router vendors will have to implement features which don't make silly hard-coded assumptions. Yes and no. In terms of potential innovations, if enough of the market chooses /60, they will hard code the assumption that they cannot count on more than a /60 being available into their development process regardless of what gets into the router. Sure, they won't be able to assume you can't get a /48, but, they also won't necessarily implement features that would take advantage of a /48. Abundance doesn't drive innovations. Scarcity does. IPv6 does not have a scarcity issue. I assert that IPv6 addressing is not going to now or ever do anything particularly innovative that can't be done better at other, more relevant, layers. The time for arguing about arbitrary things that make no difference to the end customers has passed. The navel gazing must cease and we must move forward on IPv6 to the home rather than continuing the confusion about this and other IPv6 arbitrary bit obsession stuff. We need to stop spending our time on rearranging the Titanic's deckchairs and get the profanity on with stopping the crashing into the iceberg by providing clear leadership on getting IPv6 to the masses to enable their APPLICATIONS and EXPERIENCE without the impending doom of IPv4 CGN. My name is Matthew, I HAVE given my customers the ability to get IPv6 and I don't give a flying one about the prefix length, I care about getting ANY prefix to the end users so they can use it and solve the issues at their end. I AM enabling innovation just by doing that. MMC
Re: IPv6 end user addressing
Hi Brian, From someone who's actually done this. - Our customer base is primarily PPP connected broadband users (variety of technologies, mostly ADSL). - We do a DYNAMIC /64 on the PPP interface so that people who terminate directly on a PC can get IPv6 without DHCPv6 PD. - In addition for the subnet assigned via DHCPv6 Prefix delegation which is STATIC as that's what customers have been asking for: In our trial phase we did /60s to customers - this worked just fine. I don't recall anyone actually saying I need more. (The /60 was the first nibble boundary and it allowed us to do some dumb things for allocation which didn't compromise the allocation strategy later). In production we've chosen a more conventional /56. At some point it becomes a little arbitrary. Our feeling is that at the point your have 256 /64s in production then ADSL is probably NOT what you need or want as a technology so we can do things differently for ethernet connected customers. We're getting there with support for customers bringing their own PI space. (For an idea of scale - we're tiny globally, but have around 250k customers across mainly Australia. We run our own global dualstack network). MMC On 06/08/2011, at 1:47 AM, Brian Mengel wrote: In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred. I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user. Does anyone have opinions on the BCP for end user addressing in IPv6? -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.aumailto:m...@internode.com.auWeb: http://www.on.nethttp://www.on.net/ Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: dynamic or static IPv6 prefixes to residential customers
On 03/08/2011, at 11:25 PM, Jay Ashworth wrote: - Original Message - From: Mikael Abrahamsson swm...@swm.pp.se On Wed, 3 Aug 2011, Owen DeLong wrote: Europe is a little odd in that way, especially DE and NO in that there seems to be this weird FUD running around claiming that static addresses are in some way more antithetical to privacy. Yes, I agree. I know people who choose provider based on the availability of static addresses, I know very few who avoid static address ISPs because of this fact. FUD indeed. You guys aren't *near* paranoid enough. :-) If the ISP a) Assigns dynamic addresses to customers, and b) changes those IPs on a relatively short scale (days) then c) outside parties *who are not the ISP or an LEO* will have a relatively harder time tying together two visits solely by the IP address. While this isn't privacy, per se, that making harder is at least somewhat useful to a client in reducing the odds that such non-ISP/LEO parties will be unable to tie their visits, assuming they've controlled the items they *can* control (cookies, flash cookies, etc). We've gone with static /56 v6 ranges for customers. Why? Customers told us they wanted address stability. Pretty much more than anything else. Admittedly the people who opt'ed into the trial part are not typical customers, but it's something they were all fairly adamant about. We're small globally, but we're the 5th largest broadband provider in Australia and we've actually gone and delivered IPv6 natively to our broadband customer base (as well as corporate and other clients). We also sell only v6 capable ADSL CPE (ie. have actual firmware that works with dual stack broadband. MMC
Re: dynamic or static IPv6 prefixes to residential customers
Jordi, We're doing: - dynamic /64 on the link to the customer (PPPoE at this stage) so that PPP directly to a PC will work. (ie. we run SLAAC on this). - static /56 for the customer via DHCPv6 Prefix Delegation. Given our architecture a dynamic /56 would have been better (smaller routing tables in some places), but the reality is we've been somewhat wedged and a static range proves to be a better outcome. FWIW - we're doing IPv6 to customers, today, from our production BNG/BRAS/LNS (whatever you want to call them). MMC -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.aumailto:m...@internode.com.auWeb: http://www.on.nethttp://www.on.net/ Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: Ping - APAC Region
On 03/04/2011, at 8:42 AM, Franck Martin wrote: Also remember, you would be serving Australia only from Australia. if I'm not mistaken, the Australia backbone is more or less volume based cahrged... AARNET is the Academic and Research Network, it's not THE backbone. (Note: in previous incarnations many years ago it was). Australia is an island, approximately the same size as continental USA but with only about 22M people. It's not really on the way anywhere, so the submarine capacity is pretty much limited to what is needed to serve Australia. There exist various submarine cables which go North to Guam and beyond (AJC/PPC1) and East from Sydney (SCCN, Endeavour) as well as SMW3 from Perth to Singapore. SMW3 is a great path into Singapore, except it's old and capacity is limited. Another cable is meant to being built on that path - many people have tried, let's hope the next attempt will work. Connecting these we have really only four sets of land based networks (Telstra, Optus, AAPT, NextGen - not all of these have complete coverage and/or rely on others for redundancy). We're very like Canada in some ways - small population along and edge (Canada is the US border, we're along the Southern and Eastern coasts). Various providers have capacity on different sets of cables. It's difficult to generalise as, for instance, some providers use the cable into Asia to provide business customers with good connectivity but don't generalise that to residential customers. The kinds of connectivity at the end of those cables varies as well. If you want to get content into Australia then generally to get the best delivery: a) Put it on the West Coast of the USA - LA or San Jose - everyone has good connectivity to those places. Look for places you can easily get content into AS4637, AS7473/7474, AS4826 and AS4739. AS4648 for NZ and some of AU as well. (AS4739 will peer with you there :-) (*) b) Deliver it domestically in Australia in Sydney. Equinix Sydney is a good place to start. You can get domestic transit as well as good peering to most providers. It's also close to the large population centres on the East Coast (SYD, MEL). c) Failing that - try Japan first, then Hong Kong then Singapore. But you will need to combine with a) or b) to give good connectivity to all providers. Consider various acceleration things like CDNs - especially LLNW, AKAM and EdgeCast who all have delivery capability in AU already. If anyone has any specific AU questions then I'm happy to try and answer off list. (I work for AS4739 and am responsible for peering and transit so have reasonable interest in delivery of content to customers in AU - we're keen to have GOOD connectivity). (*) AS4637 has AS1221 behind it, AS7473 has AS7474 (their customers are in AS4804) - they have around 50% of the market together in terms of traffic delivered to the AU market. Tools like peeringdb.comhttp://peeringdb.com and bgp.he.nethttp://bgp.he.net will tell you how everyone's connected. MMC -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.aumailto:m...@internode.com.auWeb: http://www.on.nethttp://www.on.net/
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 10/02/2011, at 4:39 PM, Mark Andrews wrote: In message alpine.bsf.2.00.1102092156050.16...@goat.gigo.com, Jason Fesler wri tes: In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them. Because it is a waste of time and money. That's an assertion I've heard, but has anyone quantified it? How much time and money would it take? Has anyone just asked the 22 /8 holders mentioned above nicely if they might just like to give them back for some good publicity? You know, US DoD migrates to IPv6 and returns X /8s for the good of the American people (assume ARIN) so that broadband might continue to grow and thrive in the land of the free? MMC
Re: Weekend Gedankenexperiment - The Kill Switch
On 05/02/2011, at 8:57 AM, Matthew Petach wrote: As has been noted previously, it's all about your frame of reference. If the US is removed from the Internet, it does not mean the Internet stops working; from the perspective of the rest of the world, the Internet is still there. I suspect you'll find it would be pretty crippled if the US was removed. Given the majority of my country's (Australia) internet connectivity is to the USA (English language speakers looking for English language content) we'd probably find that we were left with very limited connectivity. Quite a number of Australian ISPs would have no international connectivity at all. We'd have limited capacity to Europe as the Westward paths are thin and expensive and it's mostly via the USA. This is one of the risks the world, now relying on the Interwebz for communication runs.The heavy centralisation of the core of the internet (ie. really Tier1 defines connectivity inside the USA only and is vague for the rest of the world) as well as Asia especially having very poor intra-Asia connectivity for various reasons. (ie. A number of Asian carriers optimise for connectivity to the USA and have silly views about regional tier 1 that means they peer poorly within Asia. This leads to a lack of local connectivity. If the USA went dark then we'd lose connectivity to them). So, really, this is a call to the rest of the world to start thinking about the benefits of more regional connectivity and connectivity between Asia and Europe avoiding the USA so that any kill switch implemented doesn't cause the world to have any more problems than it needs to face. MMC
Re: Weekend Gedankenexperiment - The Kill Switch
On 04/02/2011, at 3:43 PM, Paul Ferguson wrote: Also, make sure you have staff attorneys well-versed in Internet law -- you'll need them either way. The Internet has it's own law now? MMC -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.aumailto:m...@internode.com.auWeb: http://www.on.nethttp://www.on.net/ Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: test-ipv6.com
On 28/01/2011, at 10:46 AM, Mark Andrews wrote: d. Please direct any comments, flames, etc directly to me instead of the list. I've added enough noise already :-) Note you can have totally broken IPv6 connectivity and still be fine on World IPv6 day. You just need applications with good multi-homing support. No web site can check this for you. Anyone for peering cake? MMC
Re: Pointer for documentation on actually delivering IPv6
On 05/12/2010, at 2:29 PM, Mark Radabaugh wrote: On 12/4/10 10:52 PM, Ben Jencks wrote: On Sat, Dec 4, 2010 at 22:40, Mark Radabaughm...@amplex.net wrote: Probably a case of something being blindingly obvious but... I have seen plenty of information on IPv6 from a internal network standpoint. I have seen very little with respect to how a ISP is supposed to handle routing to residential consumer networks. I have seen suggestions of running RIPng. The thought of letting Belkin routers (if you can call them that) into the routing table scares me no end. Is this way easier than I think it is? Did somebody already write the book that I can't find? DHCPv6-PD (prefix delegation) with the relay installing static routes is probably the most straightforward way. Letting home CPE participate in routing does indeed seem like bad idea; I haven't heard that seriously suggested before. -Ben I had found the documentation on DHCPv6-PD but didn't see the mechanism for getting the assigned prefixes into the router. RADIUS. When your session comes up you get, in our trial (http://ipv6.internode.on.net) a /64 assigned to your PPP interface. You can choose to send an RA and assigned your router an IP in this or not. Otherwise your router sends a DHCPv6 PD request to our BRAS. Our BRAS knows who you are and does a radius request. Our RADIUS server sends back either a pool name or a static /60 (for the trial) which then gets routed to your interface. You then assign internally as required. MMC
Re: Level 3 Communications Issues Statement Concerning Comcast's Actions
On 30/11/2010, at 6:17 PM, Kevin Blackham wrote: On Nov 29, 2010, at 15:57, William Warren hescomins...@emmanuelcomputerconsulting.com wrote: I think Karl Denninger has this one called right: http://market-ticker.org/post=173522 I don't think so. Let's do a little math exercise: Comcast charges me $75/mo for my pipe, but let's discount that for bundling, promos and lower tier services. $30-40 avg ok? For that money I get 250GB a month. Let's assume I actually use it - which I never do, even with Netflix, other VOD, and many habits common to eyeballs - but for the sake of a number to work with, I do. That's less than 1Mbps average per month. I'm not factoring in deviation from avg to peak, so I am going to assume 1Mbps per sub is peak per sub and 250GB is not the average for the user base. Average is easy - but the not factoring in the deviation from avg to peak is basically ignoring the actual meat of the problem. The human being using a network wants a quite large instantaneous peak during, say, 5pm to 11pm week nights.If you're doing network dimensioning and look at the 5min/avg and assume that's enough then you're wrong and will see packet loss. The more customers the smoother the curve, but at the far edge of the network near the last mile where aggregation starts the difference in cost to cope with this starts to add up when you start doing it cookie cutter style over hundreds/thousands or more sites. Especially if these sites are remote and have power/size restrictions. MMC
Re: As the NANOG Community Moves to IPv6...
On 04/04/2010, at 7:54 PM, IPv3.com wrote: As the NANOG Community Moves to IPv6... ... it might be a Public Service to post the IPv4 /8s made available. ... http://www.iana.org/assignments/ipv4-address-space/ MMC
Re: Optical fiber question
On 11/12/2009, at 4:58 AM, Jared Mauch wrote: You can reach much further on this, but the optics tend to be more expensive. If you are going a short distance (eg: 2km or less) multi-mode is the way. I can buy LH GigE SFPs for AU$67 each, MM GigE SFPs for AU$61.AU$6 difference is really noise. Bring on Vendor equipment with SFP+ optic support for 10G - AU$1199 for 10G-LR SFP+! ($AU = Australian Dollar which is about US 91c) MMC -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
They work pretty well. They're one of the few that you can buy which supports DSL and they work. IPv6 support on the WIFI interfaces is IOS version dependent. They support DHCPv6 PD etc. I'm using one right now with v6. MMC On 04/12/2009, at 10:41 PM, Jorge Amodio wrote: I guess Cisco's 800's are out of the Consumer Grade price range, but any comments about v6 support on them and how they compare with other options. Just looking for feedback about good options for sort remote/branch/home office. Regards Jorge -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
Mohacsi Janos wrote: According to Apple the latest Apple Airport Extreme does support DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. Airports don't support DHCPv6 PD yet. I'm led to believe that they may in the future from my Apple friends but not yet. MMC
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
DHCPv6 PD is pretty crucial. I'd love to see the code in an ADSL box (hint hint hint DLINK). MMC Frank Bulk wrote: Give their emulator a try: http://support.dlink.com/emulators/dir615_revC/310NA/login.htm Perhaps this is a dumb question, but without DHCPv6 IA_PD support, how are other large service providers rolling out IPv6 for their cable broadband, xDSL, BWA, and FTTH customers? 100% SLAAC? Frank -Original Message- From: jason.w...@cox.com [mailto:jason.w...@cox.com] Sent: Thursday, December 03, 2009 8:54 PM To: jba...@brightok.net; new...@internode.com.au Cc: nanog@nanog.org Subject: RE: Consumer Grade - IPV6 Enabled Router Firewalls. One of the better/only decent implementations I have run across in the retail world so far is the D-Link 615SW. Look for the IPv6_Ready Gold cert emblem (found this on an encap at Fry's and nobody in the department knew what IPv6 was) on the front of the box for easy recognition although there are other modems with RevC (think Rev_B works as well) firmware that don't have the label but work as well. The major feature missing is DHCPv6 IA_PD but you won't find this on any retail router that I am aware of today. What you will find though is WAN interface config via static, stateful or stateless DHCPv6 as well as stateful and stateless PPPoEv6. It even offers a DHCPv6 server for your LAN interfaces to boot. I am not sure if this product was built for the Japanese market and is now being released here to determine interest from the retail sector but it is useful for a trial lab or for testing at home. The major caveat of course is that all the IPv6 configs are done in Advanced Config mode and hence not designed for plug-and-play for your average home user. Jason From: Jack Bates [jba...@brightok.net] Sent: Thursday, December 03, 2009 7:06 PM To: Mark Newton Cc: nanog@nanog.org Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. Mark Newton wrote: The fact that someone got OpenWRT working in less than a week of spare time makes it totally clear why the commercial vendors haven't done anything: They're just simply not interested, nothing more, nothing less. I suspect they didn't use DHCPv6-PD with that OpenWRT. I've had issues with the dhcp client that comes with it in the past, though I've had an ubuntu box acting as a router with wide-dhcp doing -PD. It works okay, although the devs really should look at better support on the automatic address assignment model and support for PD issued from PD. Of course, I suspect there's just not enough interest in the linux dev community to bother. Finally, one of the home router firmware companies (which I believe linksys used when they didn't use linux) has had IPv6 support in their codebase for a year now. See nanog history. The manufacturers that use their code don't seem to have implemented the new IPv6 code. Jack (sick, so if it doesn't make sense, sorry)
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On 03/12/2009, at 11:24 AM, Fred Baker wrote: There are specifications for them being developed in the IETF, BBF, and Cable Labs. Basically, all of the usual suspects are interested in having product that meets needs. I challenge the usual suspects to deliver actual working dual stack IPv6 ADSL CPE rather than feigning interest. None of the major CPE vendors appear to have a v6 plan despite your claims. We have an IPv6 dual stack trial for ADSL going on and not a single CPE from the _major consumer CPE vendors_. Come on CPE vendors - most of your run Linux in your CPEs these days. How hard is it to make it work? Someone got an image working for us with OpenWRT in his spare time in a week, surely you CPE vendors can cobble something together for people to try out in a real piece of ADSL CPE I can buy at a shop? I don't mean 6to4 or pseudo dual stack stuff. I mean real ADSL CPE with dual stack PPP and DHCPv6 in one box. MMC
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
I note that a lot of those have IPv6 support because of 3rd party DDWRT images :-) A lot of them support 6to4 only - and often quite poorly. MMC On 03/12/2009, at 1:27 PM, Frank Bulk wrote: I think they're (all) listed here: http://www.getipv6.info/index.php/Broadband_CPE Frank -Original Message- From: Wade Peacock [mailto:wade.peac...@sunwave.net] Sent: Wednesday, December 02, 2009 5:16 PM To: nanog@nanog.org Subject: Consumer Grade - IPV6 Enabled Router Firewalls. We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. Does anyone have any leads to information about such products (In production or planned production)? We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. Thoughts? -- Wade Peacock Sun Country Cablevision Ltd -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: Happy Thanksgiving
I think most fathers who have daughters have that happen when they start going out with boys ... Happy Thanksgiving USA people. MMC On 27/11/2009, at 10:04 AM, Shane Ronan wrote: The reality is, lets see you create something that ends up being used in a manner wildly different from your intentions, and not be emotional about it. On Nov 26, 2009, at 5:41 PM, Warren Bailey wrote: I was wondering when someone was gonna tell Paul to go have a stiff drink and relax lol Sent from my Blackberry. Please execute spelling errors. - Original Message - From: Shane Ronan sro...@fattoc.com To: nanog na...@merit.edu Sent: Thu Nov 26 13:38:43 2009 Subject: Happy Thanksgiving Happy Thanksgiving eom -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile
Re: IPv6 Deployment for the LAN
Amen to that Randy. MMC Randy Bush wrote: This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is s wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol. v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills. randy
Re: BGP Update Report
I'm guessing that the top 20 unstable ASes are Korean or Asian is related to the cable cuts in Asia? cidr-rep...@potaroo.net wrote: BGP Update Report Interval: 13-Aug-09 -to- 20-Aug-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS4961 516762 6.6%6379.8 -- DISC-AS-KR Daewoo Information System 2 - AS9767 323141 4.1%8733.5 -- DONGBUIT-AS-KR Dongbulife Insurance co.,LTD 3 - AS18157 219917 2.8%8796.7 -- CHUNGJU-AS-KR chungju university 4 - AS9459 204123 2.6%8874.9 -- ASKONKUK Konkuk University 5 - AS9956 201087 2.6%8742.9 -- KONGJU-AS kongju national university 6 - AS9686 194396 2.5%8836.2 -- SKKUNET-AS SungKyunKwan University (SKKU) 7 - AS23716 154216 2.0%5507.7 -- CHANGWON23716-AS-KR Changwon College 8 - AS10159 149403 1.9%5976.1 -- HAUNET-AS-KR HANKUK Aviation University 9 - AS9530 135249 1.7%7118.4 -- SHINSEGAE-AS SHINSEGAE IC Co., Ltd. 10 - AS9628 122729 1.6%6459.4 -- SSEM-AS-KR Seoul Education Science Research Institute 11 - AS986899583 1.3%7113.1 -- CUTH-AS Catholic University of DAEGU 12 - AS10088 96758 1.2%8063.2 -- KWANGWOON-UNIV-AS-AP KWANGWOON University in Seoul, Korea 13 - AS18027 88348 1.1%8834.8 -- NSU-AS-KR namseoul university 14 - AS18023 87965 1.1%3518.6 -- KMU-AS-KR Korea Maritime University 15 - AS18026 87648 1.1%8764.8 -- CHEJU-AS-KR Cheju University 16 - AS17865 87569 1.1%7960.8 -- SCOURT-AS-KR Supreme Court of Korea 17 - AS10045 80256 1.0%8917.3 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 18 - AS997079372 1.0%8819.1 -- KUT-AS Korea University of Technology and Education 19 - AS10176 79196 1.0%8799.6 -- TENET-AS Taejon Institute of Education Science 20 - AS755779010 1.0%8778.9 -- KTNET-AS Korea Trade Network TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS9456 8920 0.1%8920.0 -- POSCO-AS POSCO 2 - AS10045 80256 1.0%8917.3 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 3 - AS9846 8908 0.1%8908.0 -- FIRSTDATA-AS-KR FDIK 4 - AS178408890 0.1%8890.0 -- KOREACERT-AS-KR KECA, Inc. 5 - AS957117776 0.2%.0 -- INICIS-AS INICIS Co., Ltd 6 - AS176008883 0.1%8883.0 -- ENVICO-AS-KR Korea Environment Resources Corporation 7 - AS10042 17764 0.2%8882.0 -- DPC-AS-KR DAEGU POLYTECHNIC COLLEGE 8 - AS9459 204123 2.6%8874.9 -- ASKONKUK Konkuk University 9 - AS10055 35488 0.5%8872.0 -- KORAIL-AS-KR Korean National Railroad Administration 10 - AS10058 26615 0.3%8871.7 -- CU-AS-KR NACUFOK 11 - AS23983 26613 0.3%8871.0 -- DJU-AS-KR Daejeon University 12 - AS235578848 0.1%8848.0 -- YUHWA-AS-KR Yuhwa Securities Co., LTD 13 - AS23573 26532 0.3%8844.0 -- OCIC-AS-KR OCI Information Communication 14 - AS18324 53042 0.7%8840.3 -- MASANC-AS-KR Masan College 15 - AS23562 17674 0.2%8837.0 -- BCRC-AS-KR Busan Cycle Racing Corporation 16 - AS9686 194396 2.5%8836.2 -- SKKUNET-AS SungKyunKwan University (SKKU) 17 - AS18027 88348 1.1%8834.8 -- NSU-AS-KR namseoul university 18 - AS17601 17664 0.2%8832.0 -- KCGF-AS-KR KOREA CREDIT GUARANTEE FUND 19 - AS18319 61824 0.8%8832.0 -- YJNET-AS-KR Yeungnam College of Science Technology 20 - AS9452 8829 0.1%8829.0 -- KUNET-AS Korea University TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 210.90.28.0/24 8941 0.1% AS23568 -- CRA-AS-KR Cycle Racing Association 2 - 163.239.192.0/20 8925 0.1% AS3813 -- SOGANG-AS-KR sogang university 3 - 163.239.208.0/21 8923 0.1% AS3813 -- SOGANG-AS-KR sogang university 4 - 163.239.128.0/18 8923 0.1% AS3813 -- SOGANG-AS-KR sogang university 5 - 163.239.0.0/17 8923 0.1% AS3813 -- SOGANG-AS-KR sogang university 6 - 210.110.248.0/22 8922 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 7 - 210.98.40.0/22 8920 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 8 - 203.246.186.0/24 8920 0.1% AS9456 -- POSCO-AS POSCO 9 - 210.119.112.0/24 8920 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 10 - 203.230.104.0/22 8920 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 11 - 203.230.96.0/218918 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 12 - 202.30.46.0/23 8916 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 13 - 220.66.143.0/248916 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL
Re: TransAtlantic 40 Gig Waves
Congrats Rod. Southern Cross and Nortel have been trialing 40Gbps waves on the 8000km segment from Hawaii to New Zealand. http://www.itnews.com.au/News/152866,southern-cross-trials-40gbps-nortel-kit.aspx The 8000km segment is a LONG way - a very long way but it should mean stability for any cable system (I'm not sure there are segments that are much longer on any other system) - the bandwidth limit hasn't been hit yet! MMC Rod Beck wrote: http://www.hiberniaatlantic.com/documents/Hibernia40GAcrossAtlanticPR-JSA2-FINAL.pdf Roderick S. Beck Director of European Sales Hibernia Atlantic Budapest, New York, and Paris
Re: [inquiry] Internet/cell in Tehran down?
Maybe there's just a lot of congestion and it's not actually down? Happens here (Australia) on some mobile networks at large events - just not enough bandwidth to go around and so you can't make calls and sms are delayed. Given that there's a lot of protests etc and a lot of people out and about in Tehran it could be similar. MMC Eric Brunner-Williams wrote: I exchanged notes with someone in Tehran shortly after 6am EDT this morning. NPR is at least partially incorrect. Steve Pirk wrote: Npr (All things considered) is reporting that cell phones and Internet access in at least Teheran if not all of Iran is down. Reporters are unable to connect out. Anyone hear of anything? -steve
Re: Why choose 120 volts?
Jay Hennigan wrote: Most of the rest of the world has 240v as conventional domestic power, and most server rooms or datacenters supporting 2KVA single devices have 208 or 240v available, so it makes sense for manufacturers of high-power gear to save the money on copper and connectors and insist on higher input voltages for full spec output. We're all 230vac here in Oz (it's a compromise between our old 240v standard and the Euro 220v one). In Oz we basically have a single style of outlet for AC for low amps and a couple of ones for higher amps. The higher powered PSUs are much easier to deal with on that - everytime we get ready to commission a new router etc for the US or Japan we look in amazement at the endless list of NEMA plugs and voltage options and different kinds of APC power gear we need to do everything. It kind of freaks me out - locking, not locking etc. Admittedly I find the standard 2 pin US style power connector somewhat wobbly and scary - ours seems to lock in much better. Since we get the same gear as North America mostly almost all of it copes with 90v to 240v AC 50/60hz. It's rare these days to find things without switching PSUs. It's worth noting that despite higher voltages here there aren't more deaths or injuries - but maybe it's because people take it more seriously. Admittedly no one I know is nuts enough to use body parts for liveness testing. MMC Yes, it would be nice to be able to plug in your laptop charger, etc. And the voltage on that charger is likely compatible with anything from 100 to 240V. Wiring a NEMA 5-15 with 208V is just wrong, though. I have an IEC male to NEMA 5-15 female pigtail (old-school monitor cord) with a big sticker saying 208V - Be very careful what you plug in here for just that purpose. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: Where to buy Internet IP addresses
James Hess wrote: A /62 takes care of that unusual case, no real need for a /56 for the average residential user; that's just excessive. Before wondering about the capabilities of home routers.. one might wonder if there will even be _home_ routers ? I think you'd want to do a /60 so it's on a nibble boundary. But by then you might as well do a /56. My personal feeling is that 99% of home networks will use a single /64, but we'll be giving out /60s and /56s to placate the 1% who are going to jump up and down and shout at us about it because of some reason that they feel makes it all unfair or that we're thinking like ipv4 not ipv6 etc. It's possible that home networks will gain some ability (in a standard fashion) to use more than one /64, but I doubt it - it's much easier to do resource discovery on a single broadcast domain for things like printers, file sharing etc. MMC
Re: google noc
http://www.peeringdb.com/view.php?asn=15169 On 20/04/2009, at 7:22 AM, John Martinez wrote: Anyone have any contact information for the google noc or adsense noc? Thanks in advance. -- Matthew Moyle-Croft Networks, Internode/Agile Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: IXP
Arnold Nipper wrote: On 17.04.2009 20:52 Paul Vixie wrote Large IXP have 300 customers. You would need up to 45k vlan tags, wouldn't you? Not agreeing or disagreeing with this as a concept, but I'd imagine that since a number of vendors support arbitrary vlan rewrite on ports that in simple environment you could do some evil things with that. (ie. you could use QinQ like ATM Virtual Paths between core switches and then reuse the VLAN tag as a VC). Then, as long as no peer has more than 4096 peers you're sweet. It'd hurt your head and probably never work, but heck, there's a concept to argue about. (Please note: I don't endorse this as an idea). I guess the other option is to use MPLS xconnect style or, heck, most vendors have gear that'll allow you to do Layer 3 at the same speed as Layer 2, so you could go for routing everyone to a common routing core with either EBGP multihop or MLPA with communities to control route entry and exit. Then broadcast isn't an issue and multicast would kind of be okay. (Please note: I don't endorse this as an idea). None of these options, to be honest, are nice and all more complex than just a Layer2 network with some protocol filtering and rate limiting at the edge. So, it's not clear what more complex arrangements would fix. My feeling is that IXes are just a substitute for PNIs anyway, so peering does naturally migrate that way as the flow get larger. If you're an IX as a business then this may afront you, but more IXes-as-a-business are Colo people (eg. SD, Equinix) who make good money on xconnects anyway. Or you have a business model that means you accept this happens. Clearly, given the number of 10Gbps ports on some exchanges it's not that much of an issue. MMC
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
Charles Wyble wrote: So allow me to think out loud for a minute 1) Why wasn't the fiber protected by some sort of hardened/locked conduit? Is this possible? Does it add extensive cost or hamper normal operation? Some people do lock their vaults/pits/manholes. But, to be honest, I'm not sure it helps a lot. How many passersby would stop someone appearing to be in a phone company/telco high-vis vest using bolt cutters - telling them the lock had seized? (I can also think of quite a few options which don't require opening a lid, but here's not the place to discuss!) 2) Why didn't an alarm go off that someone had entered the area? It was after business hours, presumably not in response to a trouble ticket, and as such a highly suspicious action. Does it make sense for these access portals to have some sort of alarm? I mean there is fiber running through and as such it could carry the signaling. Would this be a massive cost addition during construction? Alarms mean power. Adding power to hundreds of km of a route to every pit/manhole would cost a lot - it's underground and often quite wet. Better to provide diverse route protection for the same cost - then you protect against accidental external aggression. Maybe you could do something neat with fibre and some of the active monitoring stuff to detect pit openning passively, but you'd want it to be pretty good and reliable. Lots of false alarms lead to NOCs not caring. 3) From what I understand it's not trivial to raise a manhole cover. Most likely can't be done by one person. Can they be locked? Or were the carriers simply relying on obscurity/barrier to entry? Obscurity and that most people are blissfully unaware of manholes and other street furniture. Locking is certainly possible but I'm not convinced it adds a LOT (see above). Accidental external aggression is far more likely. Backhoe fade and equipment failure is a bigger problem than vandalism. MMC
Re: Google Over IPV6
Everything is a tunnel... Tube man. Everything is a tube... and Al Gore invented tubes. MMC Nick -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Re: IPv6 Confusion
On 19/02/2009, at 9:20 AM, Adrian Chadd wrote: Who says the IPv6 solutions need to be better than IPv4? Actually, with IPv6 I'd like _a_ solution that at least is viable and works - it's doesn't have to be the final one, it doesn't have to even be as good as IPv4, it just has to be able to be productized for delivery to real customers like my mum and dad and not the 1337-g33ks from Planet Geekdom. Given it's 2009 and IPv6 has been around, for, well, sometime, I find it as someone trying to implement IPv6 on a large general scale for broadband that there's still a lot of proposals, drafts, general misunderstanding and turf wars over basic stuff like how the heck we're going to give IPv6 addresses to broadband customers. I understand that there are lot of people reading this who've spent time and effort trying to make forward progress and I salute you all, but come on - let's try and make this work so that all the lovely IPv6 stuff can be given to the masses rather than forcing us to spend our lives squabbling about how evil NAT is at an SP level. Does anyone here _really_ want Geoff Houston to be right about deploying IPv6? MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Re: IPv6 Confusion
On 19/02/2009, at 12:27 PM, Nathan Ward wrote: From other discussion with you, your main concern is vendor support for a few things, right? The issue is that the vendors aren't actually sure what to implement because there's a distinct lack of standards as opposed to competing drafts, p***ing contests, turf wars etc. What exactly do I ask vendors (as a group) to implement so that when I do, it's what everyone else is going to be following the same path? Is there actually a set of things that can be put together to work so that customer can experience hassle free internet in the same way as they do with IPv4? My discussions with people in the last few weeks regarding where it's all at and how I might do IPv6 broadband have made me feel despair not happiness about the future with this. It's people inside the standards bodies that also seem frustrated with this situation. MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Bill Stewart wrote: That's not because it's doing dynamic address assignment - it's because you're only advertising the aggregate route from the BRAS/DSLAM/etc., and you can just as well do the same thing if you're using static addresses. Customers can land on one of a fleet of large BRAS across multiple POPs in a geographic region so that a failure of one piece of equipment or POP doesn't cause an outage. If I want to run a hint of redundancy then I need to propogate statics out of the POP itself. There are corners that can be cut but none seem to fit into the kind of redundancy we like. Unlike a most BGP routes DSL circuits tend to go up and down a lot, this adds to convergence time and CPU load on the router. My issue is not basic network design skills. My issue is that customers have indicated that they feel statics are a given for IPv6 and this would be a problem if I went from tens of thousands of statics to hundreds of thousands of static routes (ie. from a minority to all). Even injecting statics into iBGP rather than an IGP I feel would add considerably to the load routers face and give a big hit in the event of failure. (We already have a class of customer with statically assigned addresses or ranges). The indication so far seems to be that on this list at least people don't see IPv6 statics for all as the general option. This gives me a bit more hope. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
My comment was regarding customers believing that they were going to, by default, get a statically allocated range, whatever the length. If most customers get dynamically assigned (via PD or other means) then the issue is not a major one. MMC On 06/02/2009, at 8:56 PM, Paul Jakma wrote: On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be for a long time with IPv6). So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64. Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for hierarchical routing of bits past 64 is highly rare). Think of IPv6 as a 64bit network address + host address. At least for now. regards, -- Paul Jakma p...@clubi.ie p...@jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Stephen Sprunk wrote: You must be very sheltered. Most end users, even security folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on security through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users. At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream. (In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/insert favourite fw is for enterprise). MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Tell ya what Owen, When you can show me residential grade CPE which has a DECENT stateful firewall then PLEASE let me know. Needs to do other things well, not crash, not cost hundreds of dollars, supportable, does VOIP, WIFI etc are manufacturer supported etc. Of course, it needs to do IPv6 as well. (it's easy to say Owen, but quite frankly, the reality from my side of the fence as an operator is that it's not the norm). MMC On 07/02/2009, at 2:02 PM, Owen DeLong wrote: IPTables is decent firewall code. It's free. I don't buy that argument for a second. Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code. Owen
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Patrick W. Gilmore wrote: And before anyone says there are 281474976710656 /48s!, just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said four-point-two BILLION addresses, someone else said no $...@#%'ing way we will EVER use THAT many Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. (Think of the processing overhead of all the DSL/Cable customers going up and down). This is going to be far more of an issue and drive network design than a minor blow out in the v6 routing table. As Neil Finn of Split Enz fame once wrote: History never repeats, I tell myself before I go to sleep. Followed on the same album by a song called My Mistake. MMC (Who's trying to implement v6 native for DSL customers but finds that the world doesn't have useable solutions yet for DSL CPE, BRAS, IPv6 allocation etc and doesn't look like it will for a while). -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Anthony Roberts wrote: On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft m...@internode.com.au wrote: Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6). It's needed to prevent people from NATing in v6, as they'll still want their stuff behind a firewall, and some of them will want subnets. Why do we want to prevent people using NAT? If people choose to use NAT, then I have no issue with that. This anti-NAT zealotism is tiring and misplaced. Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. No larger than their ARP tables are now. And ARP tables are propogated around networks? No, they're local to a router. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Mark Andrews wrote: Assign the prefixes using PD and use aggregate routes out side of the pop. IPv6 nodes are designed to be renumbered. Use the technology. Stop thinking IPv4 and start thinking IPv6. IPv6 is not just IPv4 with bigger addresses. Currently with v4 I have one (majority) of customers where they have dynamic addresses. For those I'm happy to use PD - but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. This is my fear, is NOT being able to use PD for the residential grade customers. Having to provide static allocations is a problem if I have multiple POPs in a geographic region as I can't summarise and get the redundancy I want. (If I commit to a customer they have a static range then I can't easily change it on them - esp if they've done things like used the addresses statically in DNS etc as our customers are want to do). Has anyone out there actually done an implentation, across DSL of PD? If you have PLEASE let me know on list/off list/by dead letter drop in a park. Especially interested in CPE etc. Regards, Matthew Mark -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Anthony Roberts wrote: I don't think there's any need for the ISP's routers to advertise all the prefixes they delegate. They'll advertise the /48 or whatever it is, and then delegate chunks out of that. My apologies for not being clear: As I posted just before in reply to MarkA - I'm hoping that for the MAJORITY of customers that I can use PD and dynamic /64s (or whatever) local to a BRAS. My FEAR is that people (customers) are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that. I'm still not convinced though that, given DHCPv6 is going to be a reality for DNS assignment etc, that stateless autoconfig is needed and thus /64 doesn't have to be the smallest we assign. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Seth Mattinen wrote: Well, it is static, but like most static IP services offerd by an ISP, if you leave you can't take your addresses with you. Even with DSL from ATT if you move locations you get a different subnet. The issue is multiple POPs in a geographic region where customers could connect to either- if you have those and want them to work in adversity then you've got a problem as you need to allow the static addresses to propogate around. When that number is small then it's not a problem, but when you've got it large scale then you have a routing problem. This is my fear. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: Private use of non-RFC1918 IP space (IPv6-MW)
TJ wrote: No, we should hand each home a /56 (or perhaps a /48, for the purists out there) - allowing for multiple segments (aka subnet, aka links, etc.). If there are, say, 250-500 million broadband services in the world (probably more) then, if every ISP followed best practise for IPv6 address allocation, (sparse, bits for infrastructure, whatever etc) then what percentage of the space do we have left if we hand out /56 or /48s?). Taking into account the space already carved off for link local, private addressing, US Military etc. Has anyone done some analysis of what this might look like? Especially with growth etc. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
TJ wrote: However, many do not have DHCPv6 ... WinXP, MacOS, etc. are not capable. Also - does DHCPv6 currently have an option for prefix length? Just asking. I'm under no allusion that a /64 is going to be optional - it's really too late which is sad. I think people have just latched onto it and now accept it and defend it without thinking about is this still the answer?. Just because it's in an RFC doesn't mean it's still the right answer in a changing world. WRT /64s (or really, /56s and /48s being assigned to clients) - note that these are NOT static assignments permanently belonging to the client. They are hopefully dynamic, hopefully via DHCPv6-PD (hopefully available/supported by then) ... similar to the single public IPv4 address most of us dynamically get @home today. Yep - that's what I'm hoping (as I've said and clarified). But I think the reality is that in the provider world, no matter what people here say, customer demand for an unchanging IPv6 range will increase not decrease - driving up provider routing size and complexity. -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Leo Bicknell wrote: In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew Moyle-Croft wrote: My FEAR is that people (customers) are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that. Customers don't want static addresses. Customers want many different things. Customers don't think of their networks at home or in their offices as part of an ISP network. They think of it as an island that they control and run and which they buy connectivity to the internet to. They want flexibility and not the evil ISP telling THEM what to do or making them spend money on their IT consultants to change things when an ISP wants to renumber. They want DNS that works, with their own domain names, forward and reverse. Yep, but many want to run it themselves, independantly of an ISP. They want renumbering events to be infrequent, and announced in advance. Where infrequent = never. They want the box the cable/dsl/fios provider to actually work, that is be able to do really simple stuff without having to buy another stupid box to put behind it. Well, we let them chose here in AU ... None of these require static, and in fact I'd think it would be easier to get it right than it would be to do statics for most providers. But, I must be wrong, since the only solution virtually every provider offers is to move up to a static IP. I think some customers would like us to spend money running DNS for them for free, but most who care want to do it independently of us. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Hi James, I don't think anyone really has done it large scale properly. I've had basically nothing from anyone. Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!). There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience. Scary huh? I'm meant to have 250,000 customers running it by Christmas! MMC On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote: Hello Matthew , See way below ... On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: Scott Howard wrote: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore patr...@ianai.net wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft m...@internode.com.au wrote: but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers well, you might get renumbered randomly isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . Twyl , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkSystem Engineer | 2133McCullam Ave | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +--+ -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Hmm, Apologies for that - wasn't meant to goto the list. Was a bit frank. MMC On 05/02/2009, at 2:59 PM, Matthew Moyle-Croft wrote: Hi James, I don't think anyone really has done it large scale properly. I've had basically nothing from anyone. Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!). There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience. Scary huh? I'm meant to have 250,000 customers running it by Christmas! MMC On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote: Hello Matthew , See way below ... On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: Scott Howard wrote: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore patr...@ianai.net wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft m...@internode.com.au wrote: but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers well, you might get renumbered randomly isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . Twyl , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkSystem Engineer | 2133McCullam Ave | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +--+ -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909 -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: Shaping on a large scale
Bruce, Are these broadband customer using PPPoE or L2TP? If so, I suggest looking at the capabilities of your BRAS to do the work. Per user bandwidth quotas are the nature of the game here in Australia and doing it at the BRAS is the way we do it. RADIUS gives you byte counts and gives you the ability to pass back rate limits etc. MMC On 30/01/2009, at 4:03 PM, Bruce Grobler wrote: Hi, Does anyone know of any Shaping appliances to shape customers based on IP, allow for a quota per IP and qos mechanisms like LLQ?, This is should be something that can sit in between two border router's and support a small ISP (2 customers), also an opensource solution would be great! Regards, Bruce -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: IP networks will feel traffic pain in 2009 (C|Net Cisco)
Surely the whole point of this is that the end users (the eyeballs) get the best experience they can as they're the ultimate consumer. So working with everyone in the chain between the content owner and the eyeballs is important. If you're a content owner then you want the experience to be good so that either you sell more ads or that your brand (whatever that may mean) is well thought of. It's why content owners use CDNs - to ensure that it's delivered close to the end user. Surely that means, logically to me anyway, that working with caching providers local to the eyeballs is the next logical point. Certainly for the heavy bits that don't change (eg the video streams Adrian mentioned). It's a mutual benefit thing - if your content sucks for a school (for example) to use then they're not going to use it. That's not good for you as a content owner. I realise that CDNs probably aren't that keen on people caching as it reduces their revenue, but a level of being rational about helping the whole chain deliver means probably more traffic overall. MMC On 22/01/2009, at 8:13 AM, Patrick W. Gilmore wrote: (Or the people having to deliver said content to said eyeballs, and aren't being paid by the content deliverer on their behalf.) No, it does not. If I own something, it doesn't matter how important the people who want to buy it are. But I guess that's not operational. -- TTFN, patrick
Re: What to do when your ISP off-shores tech support
Martin Hannigan wrote: I'm not sure if I support off shoring or not as related to quality, but there is certainly a a business case to to be made supporting it as this thread ending up pointing out. There are trade offs which matter more to some than others. I'm quite fascinated by some of the examples given of offshoring. Cisco use Sydney as one of their locations for around the world coverage. From our point of view (being Australians) this isn't offshore - we have a local TAC who are closer and we tend to be able to get the same group of SP TAC people everytime to deal with our issues. My experience is that, given global companies like Cisco rely on locations to provide wide language support to people everywhere that the language issue is a bit moot. Some people in the Belgium TAC are easier to understand over the phone then people in the US TAC because the US TAC people have been employed for their Spanish skills or other language skills where as many Europeans have better English skills than, well, a lot of people. Some of the people in the TAC in Australia don't have English as their first language and are tricky to explain why my GSR crashed with an IPv6 issue over the phone (but fine via email). Some people on the other end of the phone just suck no matter which country or land of origin. (I use Cisco's TAC as an example purely because I'm familar - but the example can be reused). I think offshoring is more an issue because often it's built around a lie. If I'm talking to someone in another country, then I'm okay with that but I hate it when they're forced to lie about who they are and where they are. They're representing a company I deal with and as a customer I want it to be a good experience - if a company doesn't care about the overall customer experience and looks at it as a cost to be squashed and reduced then that (as someone else has said) is really the problem. Give them the tools and desire to help me as a customer no matter where they are or which god they pray to. The offshoring I think can be a problem isn't the customer facing part, but the anonymous part where backends of companies are taken offshore where data privacy laws etc aren't the same and suddenly my private data can be compromised in a way that is out of control of the laws of the country where I live. (I'm thinking banks, health care etc). Matthew
Re: an over-the-top data center
Gadi, I can't help that you need a few nights away in a lovely Swiss Hotel in order to help those cynical thoughts lift: http://www.news.com.au/travel/story/0,28318,24732642-5014090,00.html :-) MMC On 29/11/2008, at 2:05 PM, Gadi Evron wrote: On Fri, 28 Nov 2008, Howard C. Berkowitz wrote: It seems that all these cases are more under the bottom than over the top. Every couple of years there is a story about some anti virus company, data center, or whatever running out of an old nuclear bunker/military base/middle of no where. It is exciting the first few times. Gadi. -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Re: McColo: Are the 'Lights On at Telia?
Thanks for that Paul, It's a pity - the slightly hazy Sunday afternoon brain was hoping, for once, for an easy fix! MMC Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Nov 15, 2008 at 8:30 PM, Matthew Moyle-Croft [EMAIL PROTECTED] wrote: Is the spam SMTP meant to be originating from the McColo ranges or is it being used to control other machines elsewhere? The latter. Also a host of other badness, not just spam: http://hostexploit.com/index.php?option=com_contentview=articleid=12Item id=15 - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJH6N8q1pz9mNUZTMRAsnXAKClI4BUu8/qAQZ0tebwp0sPhFDWfQCfZV0/ LtUUpvA9GQVHIqs5whc5aQQ= =FG+e -END PGP SIGNATURE- -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED] Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: routing around Sprint's depeering damage
Dave Blaine wrote: There are at least three ways to address this Sprint / Cogent partition I'd be fairly reluctant to allow the government to get involved in peering relationships too deeply. Australia has some very wierd consquences of our government doing so almost ten years on. One of those is which is that the Gang of Four have effectively set a floor price on domestic transit that is much higher than it should be - meaning that much content is delivered to us from overseas because the cost of delivering in Australia to those networks is too high to do so economically. Even a lot of Australian content is hosted overseas for this reason. Consider that this is in a land where the broadband providers don't have to deliver unlimited for a fixed price. (Would things have been different without this government directive? Hmm. Dunno. Feel free to discuss). -- Matthew Moyle-Croft - Internode/Agile - Networks
Re: Sending vs requesting. Was: Re: Sprint / Cogent
Matthew Moyle-Croft wrote: I think it's a really odd reinterpretation of telephony concepts. In telephony interconnects are typically settlement based, sender pays receiver, in the settlement based world it seems to have gotten confused. in the settlement FREE world it seems to have gotten confused. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks
Re: Peering - Benefits?
Joe Provo wrote: A couple to add: - failure scoping: issues on a remote network can be better isolated from the rest of your traffic (or completely if it is the peer). Related to this is ability to contact the right people more quickly. If you've got a problem with/on someone's network then typically you can call their NOC directly. Compared with having to bounce through your transit providers helpdesk, who then escalate to their NOC, to the other NOC etc. This right is usually enshrined in most people's peering policy requirements. It's a powerful thing and not to be underestimated. MMC
Re: Atrivo/Intercage: Now Only 1 Upstream
On 16/09/2008, at 10:17 PM, *Hobbit* wrote: So in cases like this where the community appears to agree that there's a consistently bad apple, what's preventing everyone from simply nullrouting the netblocks in question and imposing the death penalty? Dunno - but something did occur to me this morning on the drive into work: Maybe there's another approach to this problem. Maybe, rather than having the antispam/virus vendors do non-real world lab tests we could get them all to donate some kit to whomever is the unlucky transit- provider du jour and see how well it works providing a nice clean feed and who's better at it? ;-) MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Re: Internet Traffic Begins to Bypass the U.S.
On 15/09/2008, at 10:06 PM, Joe Abley wrote: As an example, PacRimEast still had capacity in the late 90s, strictly speaking. But given the difficulty in ordering anything other than E1s on it at that time, did it really exist as a terrestrial option for New Zealand ISPs trying to send packets to the US? There was a lot of satellite transmission sold around that time on PanAmSat, IntelSat and Loral transponders, and it's not as if anybody was really using satellite out of choice. There are only so many discrete E1s you can comfortably inverse-mux together before it's really not worth bothering. Satellite was mainly because it was cheaper in a world where 2mbps out of Australia to the US cost US$150k/month. Circa around 1996 Telstra Internet had 16x2Mbps to the US plus 1x2Mbps to NZ.That didn't change until Southern Cross (SCCN) arrived in 2000. (I started in the ISP industry in 1994 in Australia, so whilst some of this is now a tad fuzzy, I was at least there for this bit. My home / 24 was 16 years old last month). The timelines are no doubt different, since Europe experienced a giant boom in Internet demand and infrastructure while smaller markets like New Zealand were still preoccupied with X.25. However, the original question was whether there had ever been a time during which Europe had no option but to cross oceans to get to Asia, and I'd be surprised if that wasn't the case. I guess it depends how far back you look in telecommunications history. The 1901 telegraph network was as extensive as today's submarine networks (if not broader) (http://atlantic-cable.com/Maps/1901EasternTelegraph.jpg ). Australia had telegraphy connectivity via Singapore and the All Red Route that the British ran and controlled since around 1879. Perhaps someone who actually knows this stuff can throw some facts into the thread and put a stop to my wild speculation. SEA-ME-WE predates FLAG by almost a decade. I'm sure some digging would reveal a bit more on that path either submarine or terrestrial. Before SEA-ME-WE4 and 3 there was SEA-ME-WE and SEA-ME-WE2. SEA-ME- WE had an inservice date of 1986. MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED]Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: Internet Traffic Begins to Bypass the U.S.
I think it began a while ago, but I suspect it'll increase. There's now two trans-Russian terrestrial systems, and more investment in Asia - Europe cables. Initially the capacity will be used for redundancy and to shorten latencies (ie. just to go around the other way and because it's quicker than going US-Atlantic-Europe from Asia). I don't think any of this will be because of sinister reasons, just for good engineering reasons and probably just to guarantee, without a doubt, that your circuit does NOT go through One Wilshire! MMC Hank Nussbacher wrote: http://www.nytimes.com/2008/08/30/business/30pipes.html?partner=rssuserlandemc=rsspagewanted=all -Hank -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED] Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: Internet Traffic Begins to Bypass the U.S.
Other cable systems predated FLAG (at least for voice). SEA-ME-WE predates FLAG by almost a decade. I'm sure some digging would reveal a bit more on that path either submarine or terrestrial. MMC On 15/09/2008, at 11:06 AM, Joe Abley wrote: On 14 Sep 2008, at 19:41, Jean-François Mezei wrote: Did western europe ever really have a primary route via the USA to reach asia ? Yes, I think so. If I remember correctly, before FLAG started laying cables, there was no terrestrial route to Asia from Europe that didn't involve North America. Joe -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED]Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: Internet Traffic Begins to Bypass the U.S.
Matthew Moyle-Croft wrote: I don't think any of this will be because of sinister reasons, just for good engineering reasons and probably just to guarantee, without a doubt, that your circuit does NOT go through One Wilshire! Just to ensure no confusion - this was just about redundancy and diversity to ensure that not all your circuits go through OW, which is a common US West Coast issue. MMC
Re: Internet Traffic Begins to Bypass the U.S.
On 15/09/2008, at 10:46 AM, Jean-François Mezei wrote: Matthew Moyle-Croft wrote: Most Asian providers (at least Northern Asia) use USA, Atlantic path to get to Europe. The capacity going Westt isn't that high in comparision, so the extra latency hit is well offset by the much reduced cost. I take it voice would have priority for use of the existing europe- asian links ? Probably - voice is pretty small in the scheme of things (my estimate is less than 1% of used capacity out of Australia (used not lit)). But, from Australia to Europe the difference in latency East vs West may not make a LOT of difference to voice where 150ms-200ms one way isn't too bad. When there were a number of cable cuts in middle east last year, I remember BBC mentioning that internet access to asia was much slowed due (this was significant to those companies who had outsourced a lot of stuff from europe to India). I guess this would have been more of media hype than reality ? I suspect it did slow it down - I was talking more Northern Asia (China, Japan, Korea) than India. Companies who relied on purchasing, corporate links between India and Europe (for example) would probably be happy to pay the premium for low latency path direct, whereas IP transit providers want cheap, bulk capacity that the Northern Pacific routers offer. For instance, out of Australia we have a single, old cable going West out of Perth to Singapore (SEA-ME-WE3) which allows only low speed circuits, Was there any thought about building cables to singapore from darwin now that it has had fibre links to the rest of australia for over a decade ? Ha! Darwin has the incumbent only. It's cheaper to go around the world than from Australia to Darwin. Perth will be the place again as there is a reasonable amount of trans- Australian capacity across the Nullabour. Although a Darwin break out from such a cable would be welcome, but the small population in the Northern Territory maybe doesn't make it viable unless a big mining /oil drilling/gas firm wants a lot of capacity. Hopefully the extension of the Singapore-Indonesia cable Matrix have/ are building to Perth will happen in 2010/11. Although, personally, I'd love to see a Perth-Chennai cable given what's going on in India. MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Re: Internet Traffic Begins to Bypass the U.S.
Pardon my ignorance here, but isn't this more of a case of traffic growing outside of the USA which means that traffic within the USA represents a smaller share of the total internet traffic ? I suspect so - especially with CDN/Content providers pushing traffic out to the edge it means that we (the rest of the world) don't pay so much to haul it back from Northern America! (Thanks to those who are doing it - you know who you are and we love you for it!). Japan has 80% of it's internet traffic as domestic, as do a lot of Asian countries. As China, Korea and others grow their domestic volumes the %age coming from the USA is a lot less. Did western europe ever really have a primary route via the USA to reach asia ? (I realise that during the cable cuts in middle east last year, traffic might have been rerouted via USA but this would be a temporary situation). Most Asian providers (at least Northern Asia) use USA, Atlantic path to get to Europe. The capacity going Westt isn't that high in comparision, so the extra latency hit is well offset by the much reduced cost. My point in my first post is that this is changing rapidly as people (eg Reliance/Flag) are building more capacity West to Europe plus the Trans-Russian terrestrial (eg. TEA) are going for fast (and expensive from my understanding). For instance, out of Australia we have a single, old cable going West out of Perth to Singapore (SEA-ME-WE3) which allows only low speed circuits, but we've got almost 4 (as of next year) cables going North and East out of Sydney. So most Europe traffic to/from Australia is via the USA. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED] Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: Internet Traffic Begins to Bypass the U.S.
Jamie A Lawrence wrote: What exactly would be sinister about moving traffic through routes that didn't intersect the U.S. border? Nothing if the reason isn't to avoid the US to prevent interception. ie. my point was the people are doing this for engineering reasons not political ones as was implied by that article. We have connectivity to Japan to reduce latency to Asia from Australia (ie. remove the trombone via the US) - this is purely an engineering/commercial decision to improve latency. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks
Re: community real-time BGP hijack notification service
Nathan Ward wrote: On 13/09/2008, at 5:48 PM, Matthew Moyle-Croft wrote: Arnaud de Prelle wrote: I think that most of us (me included) are already using it but the problem is that they don't have BGP collectors everywhere in the world. This is in fact a generic issue for BGP monitoring. In this case it's very important to have a lot of collectors broadly distributed listening in many ASes. For example: If I know there are two BGP collectors driving this service, and they're in, say, AS701 and AS1239, then if I wanted to do a partial hijack (which might be good enough for my evil purposes) then I could advertise a path which had those ASes stuffed in it and prevent downstream collectors in AS701 and AS1239 from learning the hijack path. Note that the attack becomes less and less effective if you're path stuffing ASes, as it will be preferred by fewer and fewer networks. Put collection points in say 10 networks, and the attack becomes pretty useless. Unless of course you are announcing a more specific prefix than the authentic one. Absolutely - but it depends how wide you want the hijack - a global one is very obvious, but you can see that a very narrow one of some sites it might be harder (take longer) to detect and live longer. ie. If I just wanted to disrupt a website to a country or region for political reasons or just to get the ad revenue for a small amount of time, then it might be acceptable to limit the scale in order to evade detection. I'm not saying this is the end of the world, just reenforcing that widely distributed BGP monitors are necessary for detection. It might be that various projects which have these distributed tools etc can help by becoming feeds for these kinds of notification projects. MMC -- Nathan Ward
Re: ingress SMTP
*Hobbit* wrote: How do you alert mail server operators who are smarthosting their e-mail through you that their outbound messages contain spam? You don't let them falsify their envelope or headers to contain fields utterly unrelated to your own infrastructure, for starters. They try it, their mail bounces. It's a very rare piece of spam that actually comes from who it says it comes from anymore. Are you suggesting that only ISP domains should be allowed through? (eg. [EMAIL PROTECTED]) If you're forcing people to use your mail servers as a smart host then you wouldn't be very popular ... MMC
Re: ingress SMTP
Hi Bill, Bill Stewart wrote: In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users. Except that this tends to lead to a worse situation for people like yourself who wish to run a mailserver - because ultimately you'll have to resort to using an ISP's forwarder anyway because there will be more spam from the IP ranges you're in leaving to the wide world, thus a worse reputation, and so more blocking. ie. by blocking outbound SMTP by default and getting customers to use our mail cluster their email is more likely to arrive and not be dropped as coming from a potential spam source. I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable. That's what we do - by default most customers have a small ACL applied which protects them from traffic from various windows ports, ensures SMTP goes via our mail cluster etc. Having customers send mail out via us is actually better because we do spam checking and can alert customers to their machines being compromised etc (or at least customers can look at their status themselves). But, customers can easily turn the filtering off via the portal we have. We have no issues with customers running servers - most people don't, and those who do value the ability to do so. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED] Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: community real-time BGP hijack notification service
Arnaud de Prelle wrote: I think that most of us (me included) are already using it but the problem is that they don't have BGP collectors everywhere in the world. This is in fact a generic issue for BGP monitoring. In this case it's very important to have a lot of collectors broadly distributed listening in many ASes. For example: If I know there are two BGP collectors driving this service, and they're in, say, AS701 and AS1239, then if I wanted to do a partial hijack (which might be good enough for my evil purposes) then I could advertise a path which had those ASes stuffed in it and prevent downstream collectors in AS701 and AS1239 from learning the hijack path. So the more we get the best it is and that's why I'll be using Gadi's BGP monitoring tool (and any other that might come) in parallel with the one provided by the RIPE. Hear hear for Gadi and others offering these tools. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks
Re: [NANOG] IOS rootkits
Simon Lockhart wrote: How long before we need to install Anti-virus / Anti-root-kit software on our routers? Nah - we'll just replace them all with Macs. They don't need anti-virus ... :-) MMC Simon ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] IOS rootkits
The question is who can't afford for these things to happen... Gadi. I can't help but feel you're pushing fear to further some other interest here Gadi. Do you actually have live examples of this or able to demonstrate it or are you just theorising about it all? MMC ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] IOS rootkits
It is alright to have feelings. Gadi. So I ask again, expecting nothing but another flippant answer: Do you actually have live examples of this or able to demonstrate it or are you just theorising about it all? MMC ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] IOS rootkits
I'd love to know what magical mystical protection your routers have that will enable them to avoid the same fate as every other device and operating system has. There's only one thing up there that doesn't have known rootkits in the wild. Yet. The question isn't IF routers have security vunerabilities, but whether Gadi has an example he can demonstrate now of installing a root kit on an IOS router NOW or not. MMC ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] peering between ASes
Kai Chen wrote: There is the model where all partcipants peer through agency of 3rd party. That tends to be looked on as an extremely bad idea, but some regulatory environments encourage or enforce that sort of behavior particularly around the monopoly PTT. I don't know if the 3rd party you mentioned is the IXP? Some IXPs have MLPA (MultiLateral Peering Agreements) where some or all of the participants agree to connect to a route server (usually with it's own AS) and exchange routes this way. It's reasonably common around AsiaPac - all the peering fabrics in Australia are MLPA for example, but I can think of optional examples in the USA (eg. Any2) that have it as an option or places like HKIX which have an MPLA which is mandatory for Hong Kong prefixes. This doesn't stop you doing bilateral as well across the same fabrics. MLPA works well in certain environments, especially where the major IP transit providers in a country won't peer, but rivalries tend to mean that a neutral (or fairly neutral) 3rd party can provide the routing part (this is pretty much what happened in Australia). It's convienient for content providers - they can hook up to one route server and often pickup half of the people on the exchange without having to spend ages negotiating with small networks who often don't have the technical know how or don't have the BGP experience, or indeed the smaller networks themselves as they can connect to an exchange and at least guarantee enough data to justify doing so. It gets more complex as some networks then become bigger and become transit providers and don't like customers sending routes to them via a peering fabric etc. Which is why, with a much more diverse range of networks and no one player dominating people the transit game (eg. in the USA, Western Europe) that MLPA isn't common. Some MLPAs give you some control over routing (eg. don't send my prefixes to AS), but a lot don't. Regards, Matthew ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] peering between ASes
Nathan Ward wrote: If the foreign AS really wants to send you routes that way, they can do it regardless of how you stop your advertisements being accepted by/ reaching them. We're hardly talking high security here. ip route prefix netmask 1.1.1.1 works a treat. I'm not quite sure of your point Nathan. That'd stop connectivity which isn't usually the point - especially if the issue is point (2) below. MLPAs are disliked for two main reasons that I've been able to discern. (1) Lack of control Because of the lack of direct relationships with the other networks you can get some fairly odd routing behaviours which gives suboptimal performance when you meet at multiple MLPAs in a theatre - leading to difficulty in doing traffic engineering. From traffic flows, to wierdness caused by people advertising prefixes inconsistently to transit and peering and blaming IOS bugs for it sigh. (2) Transit customers using an MLPA to not pay for traffic to your network A fair point - but, if they weren't a customer then you might be paying to get their traffic or they would be sending it that way anyway. MMC ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [Nanog] Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010]
[EMAIL PROTECTED] wrote: ... You need a way to insert non-technical information about the network into the decision-making process. The only way for this to work is to allow the network operator to have a role in every P2P transaction. And to do that you need a middlebox that sits in the ISP network which they can configure. You could probably do this with a variant of DNS. Use an Anycast address common to everyone to solve the discovery problem. Client sends a DNS request for a TXT record for, as an example, 148.165.32.217.p2ptopology.org. The topology box looks at the IP address that the request came from and does some magic based on the requested information and returns a ranking score based on that (maybe 0-255 worse to best) that the client can then use to rank where it downloads from. (might have to run DNS on another port so that normal resolvers don't capture this). The great thing is that you can use it for other things. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED] Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 The difficulty lies, not in the new ideas, but in escaping from the old ones - John Maynard Keynes ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [Nanog] Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010]
(I know, replying to your own email is sad ...) You could probably do this with a variant of DNS. Use an Anycast address common to everyone to solve the discovery problem. Client sends a DNS request for a TXT record for, as an example, 148.165.32.217.p2ptopology.org. The topology box looks at the IP address that the request came from and does some magic based on the requested information and returns a ranking score based on that (maybe 0-255 worse to best) that the client can then use to rank where it downloads from. (might have to run DNS on another port so that normal resolvers don't capture this). The great thing is that you can use it for other things. Since this could be dynamic (I'm guessing BGP and other things like SNMP feeding the topology box) you could then use it to balance traffic flows through your network to avoid congestion on certain links - that's a win for everyone. You could get webbrowsers to look at it when you've got multiple A records to chose which one is best for things like Flash video etc. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED] Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 The difficulty lies, not in the new ideas, but in escaping from the old ones - John Maynard Keynes ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
