Re: World IPv6 Only Day.
On 9 Jun 2011, at 05:36, Karl Auer wrote: On Wed, 2011-06-08 at 17:37 -1000, Paul Graydon wrote: Dumb question.. what does the switch (L2) have to do with IPv6 (L3), or is it one of those 'somewhere in between the two' things? Well, a modern switch should work fine, even if not directly IPv6 aware, but it won't understand multicast and will generally flood multicast frames to all interfaces. So definitely stipulate IPv6 capability, even for switches And it won't have DHCPv6 snooping, or tools to mitigate rogue RAs. Tim
Re: Cogent IPv6
I had to ask this here a while back, so I can now share. :-) IPv6 addresses are written as 8 16-bit chunk separated by colons (optionally with the longest consecutive set of :0 sections replaced with ::). A /112 means the prefix is 7 of the 8 chunks, which means you can use ::1 and ::2 for every connection. Of course, just because you allocate a /112 (or shorter) in your database doesn't mean you have to use it. You could also allocate a /112 for a point-to-point link and use a /127 (e.g. addresses ::a and ::b). Still that doesn't give any reason to provide /112 for point to point connectivitiy. Seriously, I'm peering with a transit provider with /126 and when I asked for a reason they said, ease of management. How come Subnetting /32 to /126 is ease of management?? thats quite difficult to understand. This debate is there fore quite a long time but everytime it pops up I feel so uncomfortable with this granular subnetting. Regards, Aftab A. Siddiqui
Re: Hotmail?
As far as commercial packages go, Surgemail is worth a look. Very affordable and insanely powerful and customizable. The support team is the development team. It's not uncommon for bugs to be fixed in hours to day and even new features requests to be added in days to weeks. Runs on practically any major OS you prefer... -Vinny +1 for Surgemail Have been running it for years and it's rock solid. Wayne
Re: Cogent HE
On Jun 8, 2011, at 1:10 PM, Ken Chase wrote: On Wed, Jun 08, 2011 at 03:05:05PM -0500, Richard A Steenbergen said: global reachability, in the hopes that it will strengthen their strategic position for peering in the long term (i.e. they both want to be an IPv6 Tier 1). I'm not making a judgement call about the rightness or wrongness of the strategy (and after all, it clearly hasn't been THAT big of an issue considering that it has been this way for MANY months), but to attempt to blame one party for this issue is the height of absurdity. PR stunts and cake baking not withstanding, they're both equally complicit. So we have to buy from BOTH HE and Cogent?! Sounds like market fixing to me! :/ Not at all... You can peer with HE. Try that with Cogent and then tell me it's the same. Owen
Re: Cogent HE
On Jun 8, 2011, at 1:05 PM, Richard A Steenbergen wrote: On Wed, Jun 08, 2011 at 07:48:42PM +, Brielle Bruns wrote: Has been going on for a long while now. HE even made a cake for Cogent (IIRC), to no avail. But, this is not surprising. A lot of public/major peering issues with v4 over the past few years has been cogent vs. someone else. When two networks are not able to reach each other like this, it usually requires the active willing participation of both parties to allow the situation to continue. In this case, HE is doing *PRECISELY* the same thing that Cogent is doing. They're refusing to purchase transit, and making the decision to intentionally not carry a full table or have global reachability, in the hopes that it will strengthen their strategic position for peering in the long term (i.e. they both want to be an IPv6 Tier 1). Not exactly. We are perfectly willing to peer with Cogent. They are not only refusing to purchase transit, they are refusing to peer. To me, that's a pretty big difference. To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has aggressively tried to improve the situation through promiscuous peering in every way possible. If you are interested in peering with HE and you have a presence at any of the exchange points we are at, send an email to peering at HE.NET and we will peer. I'd say that's pretty different from what Cogent is doing. I'm not making a judgement call about the rightness or wrongness of the strategy (and after all, it clearly hasn't been THAT big of an issue considering that it has been this way for MANY months), but to attempt to blame one party for this issue is the height of absurdity. PR stunts and cake baking not withstanding, they're both equally complicit. Respectfully, RAS, I disagree. I think there's a big difference between being utterly unwilling to resolve the situation by peering and merely refusing to purchase transit to a network that appears to offer little or no value to the purchaser or their customers. Owen
Re: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day
On Wed, Jun 08, 2011 at 11:38:54AM -0400, David Swafford wrote: Overall though the day seems to be going well, I've sparked a lot of enthusiasm at work by bragging this event (I even made a shirt to promote it :-), and I'd love to see this become a regular occurrence. In fact, daily would be good... ;) Matthew -- Matthew Newton, Ph.D. m...@le.ac.uk Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, ith...@le.ac.uk
Re: Quick comparison of LSNs and NAT64
In message 4df053aa.50...@axu.tm, Aleksi Suhonen writes: Hello, Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why: NAT64 scales much better than NAT44 and NAT444(*) The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two records of different NAT64 boxes, in case that works better with some application protocols. You can add more capacity with DS-Lite as well though it does take a while for the DHCP option to be refreshed without push support. The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat. I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it: http://www.trex.fi/2011/dns64.html A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet. You don't have to pass all the traffic through the AFTR box or the LSN when dual stacked either. The AFTR box can be on the other side of the world or out sourced if you want it to be. The same can be done with NAT64. The biggest downsides I've encountered are: I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority. Not a problem with DS-Lite or NAT444. II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either. Not a problem with DS-Lite or NAT444 So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope. My 2 cents delivered, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail (*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Cogent IPv6
On Jun 8, 2011, at 7:24 PM, William Herrin wrote: On Wed, Jun 8, 2011 at 9:58 PM, Kelly Setzer kelly.set...@wnco.com wrote: IPv6 newbie alert! I thought the maximum prefix length for IPv6 was 64 bits, so the comment about a v6 /112 for peering vexed me. I have Googled so much that Larry Page called me and asked me to stop. Can someone please point me to a resource that explains how IPv6 subnets larger than 64 bits function and how they would typically be used? Hi Kelly, IPv6 netmasks work exactly like IPv4 netmasks. You can even route /128's if you want. Two major caveats: 1. SLAAC (stateless autoconfiguration, the more or less replacement for DHCP) only works if the subnet on your LAN is exactly /64. So unless you're manually configuring the IPv6 address on every machine on your subnet, you're using a /64. You can actually use DHCPv6 to assign addresses to hosts dynamically on longer than /64 networks. However, you may have to go to some effort to add DHCPv6 support to those hosts first. Owen
Re: Cogent IPv6
On Wed, 2011-06-08 at 23:39 -0400, ML wrote: Did Cogent have the gumption to charge you more for IPv6 too? We have a bit of transit from them (~20Mbit or so) to stay connected to their customers. Getting IPv6 setup was really simple. No extra charges. It's been easier than via our existing L3 reseller (Adapt). Tom
Re: Cogent HE
On (2011-06-09 00:55 -0700), Owen DeLong wrote: To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has aggressively tried to improve the situation through promiscuous peering in every way possible. If you are interested in peering with HE and you have a presence at any of the exchange points we are at, send an email to peering at HE.NET and we will peer. I look forward for IPv4 to go away, as in future I can have full free connectivity through HE to every other shop who all have full free connectivity to HE. Something went terribly wrong in IPv4 land, where we're being unfairly forced to pay to access other networks through them. As a gesture of good faith, when I get this 100% free Internet, I vouche to return the favor by sending all my downstream customers 5USD gift card to iTunes, you're welcome. -- ++ytti
Re: Cogent HE
Composed on a virtual keyboard, please forgive typos. On Jun 9, 2011, at 17:39, Saku Ytti s...@ytti.fi wrote: On (2011-06-09 00:55 -0700), Owen DeLong wrote: To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has aggressively tried to improve the situation through promiscuous peering in every way possible. If you are interested in peering with HE and you have a presence at any of the exchange points we are at, send an email to peering at HE.NET and we will peer. I look forward for IPv4 to go away, as in future I can have full free connectivity through HE to every other shop who all have full free connectivity to HE. Something went terribly wrong in IPv4 land, where we're being unfairly forced to pay to access other networks through them. Non sequitor. Even though HE gives away free transit now, Owen said nothing about free transit. As for free peering, LOTS of networks freely peer and make money, including my current employer. (Actually, I think more open peering networks make money than closed peering networks. :-) -- TTFN, patrick
Re: Cogent HE
On 2011-Jun-09 10:39, Saku Ytti wrote: On (2011-06-09 00:55 -0700), Owen DeLong wrote: To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has aggressively tried to improve the situation through promiscuous peering in every way possible. If you are interested in peering with HE and you have a presence at any of the exchange points we are at, send an email to peering at HE.NET and we will peer. I look forward for IPv4 to go away, as in future I can have full free connectivity through HE to every other shop who all have full free connectivity to HE. Something went terribly wrong in IPv4 land, where we're being unfairly forced to pay to access other networks through them. You could, today, setup a IPv6 over IPv4 tunnel and HE will pay for the IPv4 transit at the cost of a little smaller lower MTU ;) Just need to find folks on the other side to terminate those tunnels who find also that using a free service is a good idea for a commercial setup. I guess all this free IPv6 transit has a perfect SLA of course with quick resolution for problems and of course a proper clean prefix feed with properly aggregated prefixes. Greets, Jeroen
Re: Cogent HE
On (2011-06-09 18:03 +0900), Patrick W. Gilmore wrote: Even though HE gives away free transit now, Owen said nothing about free transit. Yes there might be that some networks are unable physically to connect to HE. But I'm sure within time HE will have global presence to reach all networks directly. -- ++ytti
RE: Hotmail?
On Wed, Jun 8, 2011 at 11:08 AM, Martin Hepworth max...@gmail.com wrote: Have a look at the Hermes mail system at cam.Ac.uk, built buy among people Philip Hazel of exam fame It will give you some insight into the challenges of building a scalable high perfomance mail system. I rolled postfix, OpenLDAP, MySQL and @mail on a bunch of blades and NetApp storage which ran about 200K users for years without any problems. We had Alteons for load balancing. For spam/virus/etc I used the IronPort boxes (before they were Cisco). We very rarely had any problems with this, OpenLDAP broke once, but since the LDAP front ends were behind Alteons nobody ever noticed it. The whole thing cost less than the licenses for most commercial systems we looked at. -- Leigh Porter __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Cogent IPv6
On Wed, Jun 08, 2011 at 10:33:29PM -0500, Chris Adams wrote: Once upon a time, William Herrin b...@herrin.us said: Now, as to why they'd choose a /112 (65k addresses) for the interface between customer and ISP, that's a complete mystery to me. I had to ask this here a while back, so I can now share. :-) IPv6 addresses are written as 8 16-bit chunk separated by colons (optionally with the longest consecutive set of :0 sections replaced with ::). A /112 means the prefix is 7 of the 8 chunks, which means you can use ::1 and ::2 for every connection. Of course, just because you allocate a /112 (or shorter) in your database doesn't mean you have to use it. You could also allocate a /112 for a point-to-point link and use a /127 (e.g. addresses ::a and ::b). Please don't use /127: Use of /127 Prefix Length Between Routers Considered Harmful http://tools.ietf.org/html/rfc3627 More below on use of various prefix lengths. You need to watch out for the EUI-64 'u' and 'g' bits, as well as subnet anycast addresses (top 127 addresses of every subnet): IPv6 Addressing Considerations: http://tools.ietf.org/html/rfc5375 IPv6 Address Assignment to End Sites: http://tools.ietf.org/html/rfc6177 Emerging Service Provider Scenarios for IPv6 Deployment: http://tools.ietf.org/html/rfc6036 IPv6 Optimal Address Plan and Allocation Tool: http://www.ipv6book.ca/allocation.html ARIN Wiki: http://www.getipv6.info/index.php/IPv6_Addressing_Plans (but some of the ARIN-related concepts here are obsolete, such as references to the HD Ratio and non-nibble-boundary allocations)
Re: Cogent IPv6
Please don't use /127: Use of /127 Prefix Length Between Routers Considered Harmful http://tools.ietf.org/html/rfc3627 Do keep up. :-) http://tools.ietf.org/html/rfc6164 Rob
Re: Cogent IPv6
On 09-06-11 14:01, Chuck Anderson wrote: Please don't use /127: Use of /127 Prefix Length Between Routers Considered Harmful http://tools.ietf.org/html/rfc3627 Well, this RFC says not to use PREFIX::/127. You are safe to use other /127's within your prefix. -- Grzegorz Janoszka
Re: Cogent IPv6
You can actually use DHCPv6 to assign addresses to hosts dynamically on longer than /64 networks. However, you may have to go to some effort to add DHCPv6 support to those hosts first. Also, there is no prefix-length (or default router) option in DHCPv6, so you have to configure the Router Advertisements with the longer prefix length in this case. It is perfectly possible to use RA *only* for the default router, and not announce any prefix at all. This implies a link-local next hop. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: Cogent IPv6
On 6/9/2011 4:39 AM, Tom Hill wrote: On Wed, 2011-06-08 at 23:39 -0400, ML wrote: Did Cogent have the gumption to charge you more for IPv6 too? We have a bit of transit from them (~20Mbit or so) to stay connected to their customers. Getting IPv6 setup was really simple. No extra charges. It's been easier than via our existing L3 reseller (Adapt). Tom I guess someone with a 1 Gb commit in a not so small city deserves to be charged extra for a few Mbps of IPv6... For a not so full table at that.
Re: Cogent HE
On Thu, Jun 9, 2011 at 3:39 AM, Saku Ytti s...@ytti.fi wrote: On (2011-06-09 00:55 -0700), Owen DeLong wrote: I look forward for IPv4 to go away, as in future I can have full free connectivity through HE to every other shop who all have full free connectivity to HE. Something went terribly wrong in IPv4 land, where we're being unfairly forced to pay to access other networks through them. The existence of free IPv6 transit from one peer to another is clearly a temporary situation; when IPv6 traffic picks up, expect to see the end of free transit, or a new rule like free transit only to our paying customers' networks, or Pay an extra port fee, get first XX megs transit for free. It's obvious HE wishes to get positioning as Tier1 on the IPv6 network. Once the amount of IPv6 traffic increases, $$ required for HE to provide transit between free peers will increase, and at some amount of traffic free transit will no longer be sustainable, due to additional network upgrades, ports, etc, required to carry additional transit. So they either lose massive $$, become a non-profit organization, and get sufficient donations from peers to fund upgrades, or at some point, limit the amount of (or type) of transit that is free, or stop adding peers. An assumption is that there will be such a thing as a Tier1 on the IPv6 network. Perhaps, the fact there are ISPs larger than all the others and the IP protocol suite tends to form a hierarchical structure logically, BUT There exists a possibility that no IPv6 network will be able to achieve transit-free status through peering; evidently, it just takes one large arrogant network operator to demand everyone else buy transit, in order to prevent any Tier1s from completely becoming Tier1 (and ironically -- preventing themselves from being classified Tier1, due to refusing to peer with HE). Unless you know... the operational definition of Tier1 is relaxed greatly to allow for partial connectivity; reaching 50% of the networks without transit does not make one Tier1. -- -JH
RE: Cogent HE
Does Cogent participate in the meetings/shows like the one coming up next week ? Would that not be a good place for NANOGers to voice their opinion? --- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of Learn RouterOS -Original Message- From: Jimmy Hess [mailto:mysi...@gmail.com] Sent: June 09, 2011 7:56 AM To: Saku Ytti Cc: nanog@nanog.org Subject: Re: Cogent HE On Thu, Jun 9, 2011 at 3:39 AM, Saku Ytti s...@ytti.fi wrote: On (2011-06-09 00:55 -0700), Owen DeLong wrote: I look forward for IPv4 to go away, as in future I can have full free connectivity through HE to every other shop who all have full free connectivity to HE. Something went terribly wrong in IPv4 land, where we're being unfairly forced to pay to access other networks through them. The existence of free IPv6 transit from one peer to another is clearly a temporary situation; when IPv6 traffic picks up, expect to see the end of free transit, or a new rule like free transit only to our paying customers' networks, or Pay an extra port fee, get first XX megs transit for free. It's obvious HE wishes to get positioning as Tier1 on the IPv6 network. Once the amount of IPv6 traffic increases, $$ required for HE to provide transit between free peers will increase, and at some amount of traffic free transit will no longer be sustainable, due to additional network upgrades, ports, etc, required to carry additional transit. So they either lose massive $$, become a non-profit organization, and get sufficient donations from peers to fund upgrades, or at some point, limit the amount of (or type) of transit that is free, or stop adding peers. An assumption is that there will be such a thing as a Tier1 on the IPv6 network. Perhaps, the fact there are ISPs larger than all the others and the IP protocol suite tends to form a hierarchical structure logically, BUT There exists a possibility that no IPv6 network will be able to achieve transit-free status through peering; evidently, it just takes one large arrogant network operator to demand everyone else buy transit, in order to prevent any Tier1s from completely becoming Tier1 (and ironically -- preventing themselves from being classified Tier1, due to refusing to peer with HE). Unless you know... the operational definition of Tier1 is relaxed greatly to allow for partial connectivity; reaching 50% of the networks without transit does not make one Tier1. -- -JH
Re: IPv6 day non-participants
On Wed, 8 Jun 2011 10:59:41 -0500, James Harr james.h...@gmail.com said: JH I noticed that one of our vendors wasn't actually participating when JH they very publicly put on their home page that they would. So I JH queried the IPv6 day participation list to see who didn't have 's JH for their listed website. It turned out to be around 9.5% IMHO, it's worse than that. Most sites only added a record for their website, and frequently didn't for their DNS server. So they weren't *really* doing a complete IPv6 test, IMHO. I actually ended up documenting my full results of testing for a number of things (including DNSSEC, just because I could) at: http://pontifications.hardakers.net/computers/celebrating-world-ipv6-day-by-testing-the-candidates/ -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/
Re: Cogent HE
On Jun 9, 2011, at 2:06 AM, Jeroen Massar wrote: On 2011-Jun-09 10:39, Saku Ytti wrote: On (2011-06-09 00:55 -0700), Owen DeLong wrote: To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has aggressively tried to improve the situation through promiscuous peering in every way possible. If you are interested in peering with HE and you have a presence at any of the exchange points we are at, send an email to peering at HE.NET and we will peer. I look forward for IPv4 to go away, as in future I can have full free connectivity through HE to every other shop who all have full free connectivity to HE. Something went terribly wrong in IPv4 land, where we're being unfairly forced to pay to access other networks through them. You could, today, setup a IPv6 over IPv4 tunnel and HE will pay for the IPv4 transit at the cost of a little smaller lower MTU ;) Just need to find folks on the other side to terminate those tunnels who find also that using a free service is a good idea for a commercial setup. I guess all this free IPv6 transit has a perfect SLA of course with quick resolution for problems and of course a proper clean prefix feed with properly aggregated prefixes. I was an HE Tunnel users long before I joined the company. In my experience, our free tunnel service is quite reliable and provides excellent connectivity. HE has been happily exchanging BGP and routing my /48 for several years. The high quality of this service and the quick resolution to my (very few) problems even on a free service is one of the things that attracted me to join the company. However, for those that want production-grade business-class tunnels, we have launched a paid tunnel service as well. Owen
Re: Cogent IPv6
On 6/9/2011 1:58 AM, Aftab Siddiqui wrote: Still that doesn't give any reason to provide /112 for point to point connectivitiy. Seriously, I'm peering with a transit provider with /126 and when I asked for a reason they said, ease of management. How come Subnetting /32 to /126 is ease of management?? thats quite difficult to understand. This debate is there fore quite a long time but everytime it pops up I feel so uncomfortable with this granular subnetting. Some networks prefer a uniform numbering scheme. /112 allows for reasonable addressing needs on a circuit. In addition, while Ethernet is often used in a point-to-point access circuit, such layouts may change and renumbering would be annoying. Finally, having chunks 4-7 define the circuit and chunk 8 provide the circuit addressing makes it more human readable and is prone to less mistakes by those who suck at math. Jack
Re: Quick comparison of LSNs and NAT64
On Jun 9, 2011 1:32 AM, Mark Andrews ma...@isc.org wrote: In message 4df053aa.50...@axu.tm, Aleksi Suhonen writes: Hello, Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why: NAT64 scales much better than NAT44 and NAT444(*) The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two records of different NAT64 boxes, in case that works better with some application protocols. You can add more capacity with DS-Lite as well though it does take a while for the DHCP option to be refreshed without push support. The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat. I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it: http://www.trex.fi/2011/dns64.html A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet. You don't have to pass all the traffic through the AFTR box or the LSN when dual stacked either. The AFTR box can be on the other side of the world or out sourced if you want it to be. The same can be done with NAT64. The biggest downsides I've encountered are: I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority. Not a problem with DS-Lite or NAT444. II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either. Not a problem with DS-Lite or NAT444 So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope. My 2 cents delivered, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail (*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN. All good and accurate info. I would just restate that nat64 unlike nat444 does not need to be on path, this is what drives its improved scaling over nat444. Also, unlike ds-lite, nat64 works without any special client, such as the b4 function in the ds-lite architecture. Any fully functional ipv6 system such as win7 can work out of the box (ipv4 only apps being the exception) Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by making ipv6 end to end and forcing applications to be AF agnostic as where the others enable ipv4 without any backpressure. Each solution fits well for some set of constraints and objectives Cb -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Cogent IPv6
On Thu, Jun 9, 2011 at 10:02 AM, Jack Bates jba...@brightok.net wrote: Some networks prefer a uniform numbering scheme. /112 allows for reasonable addressing needs on a circuit. In addition, while Ethernet is often used in a point-to-point access circuit, such layouts may change and renumbering would be annoying. Finally, having chunks 4-7 define the circuit and chunk 8 provide the circuit addressing makes it more human readable and is prone to less mistakes by those who suck at math. Hi Jack, I follow the reasoning, but unless you attach undue importance to the colons you get basically the same result with a /124. I guess choosing /112 for a point to point link is one of the weird side-effects of placing :'s in the address at fixed locations instead of arbitrary locations that serve the writer's mnemonic convenience. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Cogent IPv6
On Jun 9, 2011, at 7:02 AM, Jack Bates wrote: On 6/9/2011 1:58 AM, Aftab Siddiqui wrote: Still that doesn't give any reason to provide /112 for point to point connectivitiy. Seriously, I'm peering with a transit provider with /126 and when I asked for a reason they said, ease of management. How come Subnetting /32 to /126 is ease of management?? thats quite difficult to understand. This debate is there fore quite a long time but everytime it pops up I feel so uncomfortable with this granular subnetting. Some networks prefer a uniform numbering scheme. /112 allows for reasonable addressing needs on a circuit. In addition, while Ethernet is often used in a point-to-point access circuit, such layouts may change and renumbering would be annoying. Finally, having chunks 4-7 define the circuit and chunk 8 provide the circuit addressing makes it more human readable and is prone to less mistakes by those who suck at math. not to disagree how from my vantage point, it's fairly straight forward to assign a /64 and then deploy as a /127. that might be considered wasteful on the other hand a subnet is a subnet. Jack
Re: Quick comparison of LSNs and NAT64
On Thu, Jun 9, 2011 at 10:39 AM, Cameron Byrne cb.li...@gmail.com wrote: On Jun 9, 2011 1:32 AM, Mark Andrews ma...@isc.org wrote: In message 4df053aa.50...@axu.tm, Aleksi Suhonen writes: Hello, Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why: NAT64 scales much better than NAT44 and NAT444(*) The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two records of different NAT64 boxes, in case that works better with some application protocols. You can add more capacity with DS-Lite as well though it does take a while for the DHCP option to be refreshed without push support. The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat. I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it: http://www.trex.fi/2011/dns64.html A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet. You don't have to pass all the traffic through the AFTR box or the LSN when dual stacked either. The AFTR box can be on the other side of the world or out sourced if you want it to be. The same can be done with NAT64. The biggest downsides I've encountered are: I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority. Not a problem with DS-Lite or NAT444. II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either. Not a problem with DS-Lite or NAT444 So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope. My 2 cents delivered, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail (*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN. All good and accurate info. I would just restate that nat64 unlike nat444 does not need to be on path, this is what drives its improved scaling over nat444. Also, unlike ds-lite, nat64 works without any special client, such as the b4 function in the ds-lite architecture. Any fully functional ipv6 system such as win7 can work out of the box (ipv4 only apps being the exception) Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by making ipv6 end to end and forcing applications to be AF agnostic as where the others enable ipv4 without any backpressure. Each solution fits well for some set of constraints and objectives Cb -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org A handy/succinct phrase I often use for that (in total agreement, of course) is: NAT444 is NOT an IPv6 Transition Technology. Using an anycast-flavored model, where all DNS64 servers synthesize using the same prefix[es] and all NAT64 gateways are otherwise out of the critical path (injecting said prefix[es]), is indeed a highly scalable methodology. I've been deploying as such for the last ~6mo with great success. What was surprising was how Enterprise-applicable this has been in v6-only access client trials. The lack of need for gaming, streaming radio/media (i.e., hard-coded IPv4 literals), and desktop VoIP/P2P apps have turned out exceedingly well. -Jeff
Re: Cogent HE
On Jun 9, 2011, at 6:09 AM, Dennis Burgess wrote: Does Cogent participate in the meetings/shows like the one coming up next week ? Would that not be a good place for NANOGers to voice their opinion? generally telling another party how to run their business in specific is considered poor taste... e.g. I dont buy transit from them and I don't much care if they choose to carry full routes or not. If I were a customer I imagine I'd be rather unhappy with the quality of their ipv6 transit product, but I'm not. --- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of Learn RouterOS -Original Message- From: Jimmy Hess [mailto:mysi...@gmail.com] Sent: June 09, 2011 7:56 AM To: Saku Ytti Cc: nanog@nanog.org Subject: Re: Cogent HE On Thu, Jun 9, 2011 at 3:39 AM, Saku Ytti s...@ytti.fi wrote: On (2011-06-09 00:55 -0700), Owen DeLong wrote: I look forward for IPv4 to go away, as in future I can have full free connectivity through HE to every other shop who all have full free connectivity to HE. Something went terribly wrong in IPv4 land, where we're being unfairly forced to pay to access other networks through them. The existence of free IPv6 transit from one peer to another is clearly a temporary situation; when IPv6 traffic picks up, expect to see the end of free transit, or a new rule like free transit only to our paying customers' networks, or Pay an extra port fee, get first XX megs transit for free. It's obvious HE wishes to get positioning as Tier1 on the IPv6 network. Once the amount of IPv6 traffic increases, $$ required for HE to provide transit between free peers will increase, and at some amount of traffic free transit will no longer be sustainable, due to additional network upgrades, ports, etc, required to carry additional transit. So they either lose massive $$, become a non-profit organization, and get sufficient donations from peers to fund upgrades, or at some point, limit the amount of (or type) of transit that is free, or stop adding peers. An assumption is that there will be such a thing as a Tier1 on the IPv6 network. Perhaps, the fact there are ISPs larger than all the others and the IP protocol suite tends to form a hierarchical structure logically, BUT There exists a possibility that no IPv6 network will be able to achieve transit-free status through peering; evidently, it just takes one large arrogant network operator to demand everyone else buy transit, in order to prevent any Tier1s from completely becoming Tier1 (and ironically -- preventing themselves from being classified Tier1, due to refusing to peer with HE). Unless you know... the operational definition of Tier1 is relaxed greatly to allow for partial connectivity; reaching 50% of the networks without transit does not make one Tier1. -- -JH
Re: Quick comparison of LSNs and NAT64
Hi, On Thu, Jun 9, 2011 at 10:39 AM, Cameron Byrne cb.li...@gmail.com wrote: In message 4df053aa.50...@axu.tm, Aleksi Suhonen writes: Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why: My statement is that a *pure* ipv6-only network, in the sense you have 0 NAT:ed reachability to the IPv4 Internet, will only attract people like me. :) All good and accurate info. I would just restate that nat64 unlike nat444 does not need to be on path, this is what drives its improved scaling over nat444. Also, unlike ds-lite, nat64 works without any special client, such as the b4 function in the ds-lite architecture. Any fully functional ipv6 system such as win7 can work out of the box (ipv4 only apps being the exception) Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by making ipv6 end to end and forcing applications to be AF agnostic as where the others enable ipv4 without any backpressure. You are absolutely correct here. The proper solution is indeed to backtrack from the end-goal, which is to have only one stack in the network. Thanks, Martin
Re: Cogent HE
On Wed, Jun 8, 2011 at 4:10 PM, Ken Chase k...@sizone.org wrote: So we have to buy from BOTH HE and Cogent?! Sounds like market fixing to me! :/ Guess if we do we can advertise that on our webpage... now with BOTH halves of the ipv6 internets! Or just buy from someone who have sessions with both, who IOW can offer a full IPv6 Internet. Regards, Martin
Re: Cogent IPv6
On 6/9/2011 10:02 AM, William Herrin wrote: I follow the reasoning, but unless you attach undue importance to the colons you get basically the same result with a /124. I guess choosing /112 for a point to point link is one of the weird side-effects of placing :'s in the address at fixed locations instead of arbitrary locations that serve the writer's mnemonic convenience. For the most part, you are correct. I generally run a :town:router:linkid:linkaddresses format out of a single /64 per regional area. While I could shorten the number of linkaddresses more, I'm not sure of the need. Even if I assigned it as a /124, I'd still allocate it as a /112 and just set the first 2 nibblets as 0. My reluctance to do so has more to do with uniformity, especially when providing support. It's much easier to rattle off the standard length than to have to look it up. There are cases where a /124 wouldn't be enough. Honestly, it's all a matter of preference. There are technical issues against using /127 and there's pros and cons to using longer than /64. There are interoperability issues as well as ping pong handling issues. It was just my opinion that 16 bits was more than enough for each branch of allocation that I wanted. Jack
Re: Cogent IPv6
IPv6 newbie alert! I thought the maximum prefix length for IPv6 was 64 bits, so the comment about a v6 /112 for peering vexed me. I have Googled so much that Larry Page called me and asked me to stop. Can someone please point me to a resource that explains how IPv6 subnets larger than 64 bits function and how they would typically be used? thanks, Kelly The use of a 64-bit prefix is a requirement if using Stateless addressing, nothing more. Allocation of a 64-bit prefix for every host network means you won't need to play games with subnetting based on the number of current or potential hosts, and keeps things clean; you SHOULD allocate a 64-bit prefix for every host network, though extending this logic to everything is a bit ignorant. There is a denial of service attack vector that exists on most current production IPv6 routers: IPv6 Neighbor Table Exhaustion. Writing a quick program to sweep through every IPv6 address within a 64-bit prefix is enough to cause most routers to drop neighbor entries for known hosts once the table is full. This attack is specifically targeted against routers, which makes it more troubling. Note that I was a naysayer of this vector being a problem until I actually wrote an implementation of it in a lab. I was able to kill all IPv6 traffic within seconds from a single server. Because of this, I strongly encourage you to make use of smaller prefixes for link networks. We use 126-bit prefixes (see http://tools.ietf.org/rfc/rfc3627.txt for why we avoid 127). We also don't consider Stateless desirable for the majority of our host networks. If you enable stateless on a network, every host with an IPv6 stack will start making use of it. If you use DHCPv6 you can enable global IPv6 on a per-host basis. This makes it much, much, easier to get buy-in on rolling out IPv6 everywhere, and while IPv6 is nice, it's not required yet, so you have time for the non-DHCPv6 hosts to be upgraded over the next few years (Mac OS X Lion will actually introduce a full DHCPv6 client implementation, for example). If you don't require stateless, then using prefixes longer than 64 is an option. Our current practice is to allocate a full 64-bit prefix in the schema, but only use what is currently required for actual implementation. Most of our IPv6 prefixes are actually 119 or 120-bit prefixes. Once better protection against neighbor table exhaustion is available we plan to migrate to 64. Also very strongly recommend enabling IPv6 on all your networks even if you disable RA or don't hand out addresses. This provides you with viability of IPv6 traffic on your IPv4 networks (e.g. the ability to check for rogue IPv6 routers). Finally, until RA Guard is available, use of L3 switches that support IPv6 PACL's is highly desirable as they allow you to apply a port-level traffic filter to drop RA from unauthorized ports (we do this system-wide at this point, and network stability has improved dramatically as a result). MLD snooping still needs work; the current Cisco implementation is bugged to the point where it drops ND traffic. I'm strongly looking forward to support for things like DHCPv6 snooping, I was hoping that we'd see it by now but vendors are slow to come around. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: World IPv6 Only Day.
Wouldn't the multicast flooding be just like broadcasts tho? Some of my sites don't have switches that will be upgraded or upgradeable to software that will support IPv6 directly (at least not for a few years). Is that going to cause major headaches? I under stand the RA risks but the DHCPv6 snooping I'm not too clear on. On Thu, Jun 9, 2011 at 1:55 AM, Tim Chown t...@ecs.soton.ac.uk wrote: On 9 Jun 2011, at 05:36, Karl Auer wrote: On Wed, 2011-06-08 at 17:37 -1000, Paul Graydon wrote: Dumb question.. what does the switch (L2) have to do with IPv6 (L3), or is it one of those 'somewhere in between the two' things? Well, a modern switch should work fine, even if not directly IPv6 aware, but it won't understand multicast and will generally flood multicast frames to all interfaces. So definitely stipulate IPv6 capability, even for switches And it won't have DHCPv6 snooping, or tools to mitigate rogue RAs. Tim
Re: Cogent HE
On 6/9/11 3:06 AM, Jeroen Massar wrote: You could, today, setup a IPv6 over IPv4 tunnel and HE will pay for the IPv4 transit at the cost of a little smaller lower MTU;) Just need to find folks on the other side to terminate those tunnels who find also that using a free service is a good idea for a commercial setup. I guess all this free IPv6 transit has a perfect SLA of course with quick resolution for problems and of course a proper clean prefix feed with properly aggregated prefixes. If you need that guarantee and SLA, I'm pretty sure HE won't turn down a paying customer. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: Cogent HE
On 6/9/11 7:37 AM, Owen DeLong wrote: I was an HE Tunnel users long before I joined the company. In my experience, our free tunnel service is quite reliable and provides excellent connectivity. HE has been happily exchanging BGP and routing my /48 for several years. The high quality of this service and the quick resolution to my (very few) problems even on a free service is one of the things that attracted me to join the company. However, for those that want production-grade business-class tunnels, we have launched a paid tunnel service as well. For a while we were in a similar setup with HE - free BGP tunnel for our /48 to our provider who didn't have native IPv6 at the time. Turnaround time for issues was a few hours at most (if even that), and their knowledgeable BGP people helped us with some annoying/aggravating ARIN policies that initially prevented us from getting an AS number. So, maybe I'm biased in singing their praises. Its the little things that make all the difference, IMHO. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
RE: Cogent IPv6 [IPv6 newbie alert!]
As a matter of fact, an IPv6 address has a maximum (but not restricted) fixed lenght of 64 bits for the network and subnetwork definition, and 64bit for the interface identifier. The most left 64 bit in that address contains information about type of address, scope, network and subnetwork and another useful information. But the fixed restricted lenght is not mandatory, and if locally managed IPv6 addresses anre created, you can design routes via routing protocols to follow the same rules as in CIDR. Best regards xD. -- Message: 2 Date: Wed, 8 Jun 2011 20:58:18 -0500 From: Kelly Setzer kelly.set...@wnco.com Subject: RE: Cogent IPv6 To: nanog@nanog.org nanog@nanog.org Message-ID: fc8abe0e5d384a489cdb16c4a8eb77839b3e9c6...@msmail01.luv.ad.swacorp.com Content-Type: text/plain; charset=utf-8 -Original Message- From: r...@u13.net [mailto:r...@u13.net] Sent: Wednesday, June 08, 2011 9:19 AM To: nanog@nanog.org Subject: Re: Cogent IPv6 On Wed, 8 Jun 2011 09:51:21 -0400, Nick Olsen wrote: I'm sure someone here is doing IPv6 peering with cogent. We've got a Gig [SNIP] We have separate v4 and v6 sessions with them on the same dual-stack interface (a v4 /29 and v6 /112 on the interface). One session is between our v4 address and theirs, and carries v4 prefixes only. Then another session between v6 addresses that carries v6 prefixes only. IPv6 newbie alert! I thought the maximum prefix length for IPv6 was 64 bits, so the comment about a v6 /112 for peering vexed me. I have Googled so much that Larry Page called me and asked me to stop. Can someone please point me to a resource that explains how IPv6 subnets larger than 64 bits function and how they would typically be used? thanks, Kelly -- *Daniel Espejel Perez *
Re: World IPv6 Only Day.
On 9 jun 2011, at 6:36, Karl Auer wrote: Well, a modern switch should work fine, even if not directly IPv6 aware, but it won't understand multicast and will generally flood multicast frames to all interfaces. So definitely stipulate IPv6 capability, even for switches Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts?
Re: World IPv6 Only Day.
yes http://www.google.com/search?q=mld+snooping+switch On Jun 9, 2011, at 9:49 AM, Iljitsch van Beijnum wrote: On 9 jun 2011, at 6:36, Karl Auer wrote: Well, a modern switch should work fine, even if not directly IPv6 aware, but it won't understand multicast and will generally flood multicast frames to all interfaces. So definitely stipulate IPv6 capability, even for switches Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts?
Re: Cogent IPv6
On 9 jun 2011, at 10:32, Owen DeLong wrote: You can actually use DHCPv6 to assign addresses to hosts dynamically on longer than /64 networks. The trouble is that DHCPv6 can't tell you the prefix length for your address, so either set up the routers to advertise this prefix (but without the autonomous autoconfiguration flag set) or prepare for surprising results. I say: life is too short to fiddle with this kind of stuff, just use /64, at least for everything that isn't a point-to-point link or loopback address.
Re: Cogent IPv6
On 9 jun 2011, at 14:19, sth...@nethelp.no wrote: It is perfectly possible to use RA *only* for the default router, and not announce any prefix at all. This implies a link-local next hop. Router advertisements always use the router's link local address, you can't get a router's global address from this. IPv6 routing protocols also pretty much only use link locals, so link local next hop and default routes are completely routine.
Re: Cogent IPv6
On Thu, Jun 9, 2011 at 8:50 AM, ML m...@kenweb.org wrote: I guess someone with a 1 Gb commit in a not so small city deserves to be charged extra for a few Mbps of IPv6... For a not so full table at that. We canceled some 10GbE Cogent circuits because of Cogent's refusal to provision IPv6 without adding extra fees, and I expressed my reasoning well in advance of canceling the first one. I have been told that they have now eliminated the special fee for North American customers, but just two weeks ago I heard about this IPv6 surcharge stupidity still being applied to Cogent's customers in Europe. If you want to change your vendor, sometimes you have to change your vendor. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: Cogent IPv6
Don't assume that DHCPv6 is the same as DHCP. DHCPv6 does not provide route information because this task is handled by RA in IPv6. An IPv6 RA has flags for Managed (M), Other (O), and Autonomous (A) address configuration. None of these flags are exclusive. While most routers have the A flag set by default (which enables stateless addressing) it can be disabled, and hosts will not pick up a stateless address as a result. The M flag tells hosts to make use of DHCPv6 for an address, and the O flag tells hosts to make use of DHCPv6 for additional configuration, such as DNS. Most popular configurations: You can use the A and O flag for stateless addressing with DHCPv6 for DNS. You can use A, M, and O flags if you want every host to have a stateless address, but want to use DHCPv6 to also give some hosts a predictable address (e.g. for servers), and have them use DHCPv6 for DNS information. You can have only the M and O flags set and hosts will only use DHCPv6 for configuration. Most routers also support relaying of DHCPv6 information to a central server. For those who speak Cisco here is an example interface configuration for DHCPv6 only. ipv6 address 2001:DB8:100::1/64 no ipv6 unreachables ipv6 nd reachable-time 90 ipv6 nd prefix default 900 300 no-autoconfig ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 nd router-preference High ipv6 nd ra interval 300 ipv6 nd ra lifetime 300 no ipv6 redirects ipv6 verify unicast source reachable-via rx ipv6 dhcp relay destination 2001:DB8:200::2 ipv6 dhcp relay destination 2001:DB8:200::3 Leaving out the no-autoconfig will also allow stateless if your prefix-length is 64. If you don't have a 64-bit prefix stateless won't work regardless of whether the A flag is set or not. Also note, if using DHCPv6, a DUID is used instead of the MAC address, though 2 out of 3 valid DUID formats include a MAC address of the host and I haven't actually seen the 3rd implemented. DUIDs are stored after the first time they get generated, so if you're imaging hosts you'll need to included deleting the DUID as part of your imaging process, or you'll have conflicts. Ray On Thu, Jun 9, 2011 at 12:59 PM, Iljitsch van Beijnum iljit...@muada.com wrote: On 9 jun 2011, at 14:19, sth...@nethelp.no wrote: It is perfectly possible to use RA *only* for the default router, and not announce any prefix at all. This implies a link-local next hop. Router advertisements always use the router's link local address, you can't get a router's global address from this. IPv6 routing protocols also pretty much only use link locals, so link local next hop and default routes are completely routine. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Cogent IPv6
On 09/06/2011 17:59, Iljitsch van Beijnum wrote: can't get a router's global address from this. IPv6 routing protocols also pretty much only use link locals Really? I guess my eyes must be playing tricks on me then. Nick
Re: Cogent IPv6
On Thu, Jun 9, 2011 at 1:21 PM, Nick Hilliard n...@foobar.org wrote: On 09/06/2011 17:59, Iljitsch van Beijnum wrote: can't get a router's global address from this. IPv6 routing protocols also pretty much only use link locals Really? I guess my eyes must be playing tricks on me then. Nick What OS? The system could determine the global address for the prefix provided with a little work, but the implementation for RA is to set the default route to the link-local address. This is the behavior on Windows and Linux. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: World IPv6 Only Day.
Hi Iljitsch, The switches from Extreme Networks do MLD and MLD snooping, I know for sure on the x450's and up, probably below that line as well. Erik Bais Verstuurd vanaf mijn iPad Op Jun 9, 2011 om 18:49 heeft Iljitsch van Beijnum iljit...@muada.com het volgende geschreven: On 9 jun 2011, at 6:36, Karl Auer wrote: Well, a modern switch should work fine, even if not directly IPv6 aware, but it won't understand multicast and will generally flood multicast frames to all interfaces. So definitely stipulate IPv6 capability, even for switches Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts?
Re: World IPv6 Only Day.
Cisco has had MLD snooping support for some time. But they seem to have broken it in a recent release, so it drops ND traffic and breaks IPv6; been after them to fix it, but doesn't look like it's been resolved yet. But you're correct that without MLD snooping IPv6 ND traffic is on par with IPv4 broadcast traffic and not a major problem. It does mean, however, that a large IPv6 multicast stream, like video or system imaging, would be about as bad as doing so on IPv4 without IGMP snooping. On Thu, Jun 9, 2011 at 12:49 PM, Iljitsch van Beijnum iljit...@muada.com wrote: On 9 jun 2011, at 6:36, Karl Auer wrote: Well, a modern switch should work fine, even if not directly IPv6 aware, but it won't understand multicast and will generally flood multicast frames to all interfaces. So definitely stipulate IPv6 capability, even for switches Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts? -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Cogent IPv6
On 09/06/2011 18:19, Ray Soucy wrote: DHCPv6 does not provide route information because this task is handled by RA in IPv6. Thankfully this silliness is in the process of being fixed, along with prefix delegation - so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers. Nick
Re: Cogent IPv6
On 09/06/2011 18:26, Ray Soucy wrote: What OS? IOS, for example (as opposed to iOS which is just freebsd from that point of view). JunOS uses link-locals. Iljitsch noted: IPv6 routing protocols also pretty much only use link locals. This is not true in the general case. Nick
Re: World IPv6 Only Day.
Iljitsch, On Thu, Jun 9, 2011 at 12:49 PM, Iljitsch van Beijnum iljit...@muada.com wrote: Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts? Something as enterprisey as even HP Procurve (!) has been doing this for years. Regards, Martin
Re: Thank you Microsoft (and others)
On Wed, 08 Jun 2011 21:45:25 EDT, Ravi Pina said: We hit some vendor issues which prevented us from having a larger showing, sadly. Sorry you weren't able to deploy more. But the *important* question is: Did you get enough packet traces/logs/etc of the issue so the vendor is able to take some sort of action? pgpoSHINbaJtB.pgp Description: PGP signature
Re: Thank you Microsoft (and others)
On Thu, Jun 09, 2011 at 01:47:48PM -0400, valdis.kletni...@vt.edu wrote: On Wed, 08 Jun 2011 21:45:25 EDT, Ravi Pina said: We hit some vendor issues which prevented us from having a larger showing, sadly. Sorry you weren't able to deploy more. But the *important* question is: Did you get enough packet traces/logs/etc of the issue so the vendor is able to take some sort of action? The issue was specific to a version of the code and a working version was provided. We were reluctant to rush out the upgrade without due diligence. One could argue we should have upgraded a while ago. I'm not one of those people ;) -r
Re: Cogent IPv6
Discussion has been had on-list before, suffice to say I respectfully disagree that there is a problem with the current design. On Thu, Jun 9, 2011 at 1:37 PM, Nick Hilliard n...@foobar.org wrote: On 09/06/2011 18:19, Ray Soucy wrote: DHCPv6 does not provide route information because this task is handled by RA in IPv6. Thankfully this silliness is in the process of being fixed, along with prefix delegation - so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers. Nick -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Thank you Microsoft (and others)
+1 Jared. Big thanks to all the participants and the ISOC. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 6/8/11 9:20 PM, Jared Mauch ja...@puck.nether.net wrote: I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. Hope many other participants leave it on as well. I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. Looking forward to those sharing data at NANOG next week. (I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) - Jared On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: I dont think ISOC dashboard is updating any more. Google is no longer advertising but dashboard still shows green and TTLs were short on those records.
Re: Thank you Microsoft (and others)
Agreed, in fact, I don't usually applaud Microsoft, but IPv6 wouldn't be nearly as possible as it is today without them. They've been better than almost everyone in making sure IPv6 support has been in place and implemented correctly. On Wed, Jun 8, 2011 at 9:20 PM, Jared Mauch ja...@puck.nether.net wrote: I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. Hope many other participants leave it on as well. I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. Looking forward to those sharing data at NANOG next week. (I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) - Jared On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: I dont think ISOC dashboard is updating any more. Google is no longer advertising but dashboard still shows green and TTLs were short on those records. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: World IPv6 Only Day.
On 9 jun 2011, at 19:34, Ray Soucy wrote: But you're correct that without MLD snooping IPv6 ND traffic is on par with IPv4 broadcast traffic and not a major problem. It does mean, however, that a large IPv6 multicast stream, like video or system imaging, would be about as bad as doing so on IPv4 without IGMP snooping. Of course the ethernet hardware in the host will filter multicast packets the host isn't listening for, so it just wastes some bandwidth on ports where the traffic isn't needed. This is unlike ARP, each ARP packet wakes up the CPU.
Re: World IPv6 Only Day.
On Thu, Jun 9, 2011 at 13:34, Ray Soucy r...@maine.edu wrote: Cisco has had MLD snooping support for some time. But they seem to have broken it in a recent release, so it drops ND traffic and breaks IPv6; been after them to fix it, but doesn't look like it's been resolved yet. But you're correct that without MLD snooping IPv6 ND traffic is on par with IPv4 broadcast traffic and not a major problem. snip While I certainly agree it is not a major problem, it should be _even less_ of a problem than ARP. Yes, the non-MLD-snooping switch forwards all multicast to every port - but the other end of those cables (the nodes plugged in to the switch) don't need to process the frame at all - not listening for that MAC. Compared to ARP, where the frame is picked up and handed to layer3/IPv4 before being discarded. /TJ
Re: IPv6 day non-participants
Someone has told me that Microsoft switched off IPv6 for the day. Is that true? To what extent? j -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
RE: IPv6 day non-participants
They are probably referring to this: http://support.microsoft.com/kb/2533454/ The following Fix it solution will resolve the issue by configuring your computer to prefer IPv4, instead of IPv6. By default, Windows prefers IPv6 over IPv4. This Fix it solution is temporary, to resolve issues on World IPv6 Day for affected Internet users. On June 10, 2011 at 12:00AM, your computer will be configured to prefer IPv6 again after your next reboot. --h -Original Message- From: Joly MacFie [mailto:j...@punkcast.com] Sent: Thursday, June 09, 2011 3:03 PM To: Wes Hardaker Cc: nanog Subject: Re: IPv6 day non-participants Someone has told me that Microsoft switched off IPv6 for the day. Is that true? To what extent? j -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: IPv6 day non-participants
IMHO, it's worse than that. Most sites only added a record for their website, and frequently didn't for their DNS server. So they weren't *really* doing a complete IPv6 test, IMHO. There is a reason for that. First of all, we (my employer) took this as a brief test to simply see how much IPv6 traffic there really was, and who and what would actually attempt to reach us by IPv6. The idea here being to attempt to identify IPv6 native networks. We had to do this in a way that did not break our existing IPv4 services. We run some services that we do not consider breakable and our user profile is much different than a web site is. We might have millions of clients on a network that are, for the most part, identically configured. So for example, if one users device believes it has IPv6 but doesn't *really* have IPv6 (as a link local IP so it believes it has IPv6 or has IPv6 inside its network but not clean to the Internet), then there are probably tens of thousands of identically configured devices in that customer's network. So we don't face the some small fraction of one percent are broken problem, we face a if one is broken, then a significant portion of and possibly all of that customer's devices are broken. If we put IPv6 DNS records in place that caused 100,000 clients to break, we would have some serious explaining to do. In this case, a very safe approach was to place an IPv6 address for our web site in DNS. None of our business traffic goes to our website. In the course of IPv6 day for the roughly 18 hours it was operating, we might have had 200 hits on IPv6 compared to thousands of transactions per second on our business protocols. The test did, however, expose a bug in a piece of vendor gear that was catastrophic to the business service. The entire piece of gear blew up that handles the business traffic in addition to the web traffic. It rebooted itself but apparently did not boot cleanly. This was bad enough but it was rather quickly placed back into service (manual kick) and happened at the slowest traffic time of the day and few/no clients would have noticed. Had we also experienced customer complaints of slow/poor/no service during the time of the test, it would have been pretty bad. So enabling IPv6 DNS had the potential to cause global problems and not limited to a single data center, it could have had global impact to the domain. Placing a single IPv6 DNS glue record and DNS server in service would have also potentially resulted in local DNS servers from around the globe that might prefer IPv6 attempting to reach that one DNS server. In other words, it would have created a potential single point of failure and possibly degraded performance. So the IPv6 DNS infrastructure is being rolled out in a planned, methodical fashion. Dropping an record for the web site was an easy thing to do that was considered very low risk (as we assumed all of our other gear could simply pass IPv6 packets without exploding) and offered some participation with the community. George (speaking for himself)
Re: IPv6 day non-participants
On Jun 9, 2011, at 3:03 PM, Joly MacFie wrote: Someone has told me that Microsoft switched off IPv6 for the day. Is that true? To what extent? I think this depends on the division. their search (bing) folks turned it off. % host www.bing.com. www.bing.com is an alias for search.ms.com.edgesuite.net. search.ms.com.edgesuite.net is an alias for a134.b.akamai.net. a134.b.akamai.net has address 96.17.150.114 a134.b.akamai.net has address 96.17.150.112 a134.b.akamai.net has address 96.17.150.105 their gaming folks (xbox) left it on. % host www.xbox.com. www.xbox.com is an alias for www.gtm.xbox.com. www.gtm.xbox.com is an alias for msxbwsd.vo.llnwd.net. msxbwsd.vo.llnwd.net has address 208.111.170.165 msxbwsd.vo.llnwd.net has address 68.142.73.109 msxbwsd.vo.llnwd.net has IPv6 address 2607:f4e8:200:12:225:90ff:fe2a:9f9a msxbwsd.vo.llnwd.net has IPv6 address 2607:f4e8:200:11:230:48ff:fed2:5022 (another view on the world) 2011-06-08.out:www.bing.com.|216.156.249.136,216.156.249.152|2600:1406::5043:4aa7,2600:1406::5043:4a8e|OK|OK|OKOK 2011-06-09.out:www.bing.com.|63.236.253.34,63.236.253.75,63.236.253.82,63.236.253.81,63.236.253.32,63.236.253.41,63.236.253.48,63.236.253.25||OK|Name or service not known| 2011-06-08.out:www.xbox.com.|128.242.186.238,128.242.186.198|2001:418:2401:3::c6ad:1531,2001:418:2401:3::c6ad:1548|OK|OK|OKOK 2011-06-09.out:www.xbox.com.|128.242.186.198,128.242.186.238|2a02:26f0:c:1::5c7a:32ba,2a02:26f0:c:1::5c7a:32b2|OK|OK|OKOK
Re: Quick comparison of LSNs and NAT64
On Thu, Jun 09, 2011 at 07:39:17AM -0700, Cameron Byrne wrote: Each solution fits well for some set of constraints and objectives Indeed. Unfortunately there's no good way to support v6-only clients in an environment, where dual stacked endpoints do exist as well, see RFC6147 (DNS64) ch. 6.3.2. We still need to find some solution to that problem. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: World IPv6 Only Day.
On Thu, Jun 09, 2011 at 01:34:25PM -0400, Ray Soucy wrote: Cisco has had MLD snooping support for some time. But they seem to have broken it in a recent release, so it drops ND traffic and breaks IPv6; been after them to fix it, but doesn't look like it's been resolved yet. Nice. Juniper went a step farther - IGMP snooping breaks some IPv6 multicast on EX series (e.g. DHCPv6). :-) Chasing JNPR since November... Not a priority for them to fix though, I think it's planned for end of this year in 11.4 or so. Who needs DHCPv6 while using IGMP snooping anyway, eh? :-) So if IGMP snooping already breaks IPv6, I'm really looking forward to upcoming MLD snooping bugs :-) Best regards, Daniel PS: PR/456700 - closed state and resolved in information is bogus, they don't care to fix that either. It's definately NOT resolved in 10.4R3. And it affects more than just EX8200 - personally confirmed EX3200 and rumor is all EX. -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
RE: Cogent IPv6
Some networks prefer a uniform numbering scheme. /112 allows for reasonable addressing needs on a circuit. In addition, while Ethernet is often used in a point-to-point access circuit, such layouts may change and renumbering would be annoying. Finally, having chunks 4-7 define the circuit and chunk 8 provide the circuit addressing makes it more human readable and is prone to less mistakes by those who suck at math. Jack I actually see that as a pretty good compromise. You could have all of your point-to-points at a pop in the same /64, you can give them all ::1 and ::2 addressing, and the addressing scheme supports both point-to-point and point-to-multipoint topologies. A customer with multiple locations in a region could run a circuit from each location and they could possibly all be in the same /112. If they want to multihome to you, they run similar links to a different pop in a different /112 in a different /64 that is part of that pop's /48. And the numbering is consistent at the user end. The ::2 site or ::3 site would be the ::2 site or ::3 from both pops with a different prefix. Seems reasonable to me.
Re: Cogent IPv6
On Jun 9, 2011, at 9:56 AM, Iljitsch van Beijnum wrote: On 9 jun 2011, at 10:32, Owen DeLong wrote: You can actually use DHCPv6 to assign addresses to hosts dynamically on longer than /64 networks. The trouble is that DHCPv6 can't tell you the prefix length for your address, so either set up the routers to advertise this prefix (but without the autonomous autoconfiguration flag set) or prepare for surprising results. I say: life is too short to fiddle with this kind of stuff, just use /64, at least for everything that isn't a point-to-point link or loopback address. I don't disagree with you, but, the claim that you can only choose between SLAAC and Static and therefore only use /64 for dynamic addressing wasn't true. Owen
Multi Factor authentication options for wireless networks
Wondering what people are using to provide security from their Wireless environments to their corporate networks? 2 or more factors seems to be the accepted standard and yet we're being told that Microsoft's equipment can't do it. Our system being a Microsoft Domain... seemed logical, but they can only do 1 factor. What are you guys using? Thanks
Re: Multi Factor authentication options for wireless networks
On Thu, Jun 9, 2011 at 3:02 PM, eric clark cabe...@gmail.com wrote: Wondering what people are using to provide security from their Wireless environments to their corporate networks? 2 or more factors seems to be the accepted standard and yet we're being told that Microsoft's equipment can't do it. Our system being a Microsoft Domain... seemed logical, but they can only do 1 factor. What are you guys using? Move to 802.1X with Radius. Connect your APs or AP Controllers to a decent OTP system like otpd+rlm_otp+freeradius and then connect to the Microsoft domain using LDAP. Extend the LDAP schema to hold the private keys for the OTP system. Many vendors offer this solution, although I suggest that you don't go with SecurID or any token vendor that does not disclose their algorithm to you. Go open, and use OATH. The work being done on OATH is where future one-time, two-factor systems are headed: http://www.openauthentication.org/ -john
Re: Multi Factor authentication options for wireless networks
Tokens are an option but I should have been more clear. As we're a windows shop (apologies, but that's the way it is), we were planning on going with user credentials and the machine's domain certificate. Your solution might still be viable, but I'm not certain if I can get at the machine certs with LDAP that way,have to check that. On Thu, Jun 9, 2011 at 3:08 PM, John Adams j...@retina.net wrote: On Thu, Jun 9, 2011 at 3:02 PM, eric clark cabe...@gmail.com wrote: Wondering what people are using to provide security from their Wireless environments to their corporate networks? 2 or more factors seems to be the accepted standard and yet we're being told that Microsoft's equipment can't do it. Our system being a Microsoft Domain... seemed logical, but they can only do 1 factor. What are you guys using? Move to 802.1X with Radius. Connect your APs or AP Controllers to a decent OTP system like otpd+rlm_otp+freeradius and then connect to the Microsoft domain using LDAP. Extend the LDAP schema to hold the private keys for the OTP system. Many vendors offer this solution, although I suggest that you don't go with SecurID or any token vendor that does not disclose their algorithm to you. Go open, and use OATH. The work being done on OATH is where future one-time, two-factor systems are headed: http://www.openauthentication.org/ -john
Re: Multi Factor authentication options for wireless networks
You could always take the route of not trusting the wireless network at all. Users who get to wireless can only go to the Internet. Put all the APs in a DMZ. Users who can open up a VPN to your microsoft vpn servers can authenticate and get to the corporate network. This is the way things were done on the Apple campus for a long time. -john On Thu, Jun 9, 2011 at 3:15 PM, eric clark cabe...@gmail.com wrote: Tokens are an option but I should have been more clear. As we're a windows shop (apologies, but that's the way it is), we were planning on going with user credentials and the machine's domain certificate. Your solution might still be viable, but I'm not certain if I can get at the machine certs with LDAP that way,have to check that. On Thu, Jun 9, 2011 at 3:08 PM, John Adams j...@retina.net wrote: On Thu, Jun 9, 2011 at 3:02 PM, eric clark cabe...@gmail.com wrote: Wondering what people are using to provide security from their Wireless environments to their corporate networks? 2 or more factors seems to be the accepted standard and yet we're being told that Microsoft's equipment can't do it. Our system being a Microsoft Domain... seemed logical, but they can only do 1 factor. What are you guys using? Move to 802.1X with Radius. Connect your APs or AP Controllers to a decent OTP system like otpd+rlm_otp+freeradius and then connect to the Microsoft domain using LDAP. Extend the LDAP schema to hold the private keys for the OTP system. Many vendors offer this solution, although I suggest that you don't go with SecurID or any token vendor that does not disclose their algorithm to you. Go open, and use OATH. The work being done on OATH is where future one-time, two-factor systems are headed: http://www.openauthentication.org/ -john
Re: Cogent HE
On Thu, Jun 09, 2011 at 12:55:44AM -0700, Owen DeLong wrote: Respectfully, RAS, I disagree. I think there's a big difference between being utterly unwilling to resolve the situation by peering and merely refusing to purchase transit to a network that appears to offer little or no value to the purchaser or their customers. Owen, can you please name me one single instance in the history of the Internet where a peering dispute which lead to network partitioning did NOT involve one side saying hey, we're willing to peer and the other side saying no thanks? Being the one who wants to peer means absolutely NOTHING here, the real question is which side is causing the partitioning, and in this case the answer is very clearly HE. HE wants to peer with Cogent, Cogent doesn't want to peer with HE, and thus you have an impass and there will be no peering. HE has no problem using transit to reach Cogent for IPv4 (I see HE reaching Cogent via 1299/Telia, and Cogent reaching HE via 3549/Global Crossing, both very clearly HE transit providers and Cogent peers), but HE has chosen not to use transit for the IPv6 traffic. Quite simply, HE feels that they are entitled to peer with Cogent for the IPv6 traffic, and has deliberately chosen to create this partition to try and force the issue. These are *PRECISELY* the same motivations and actions as EVERY OTHER NETWORK who has ever created a network partition in pursuit of peering that the other party doesn't want to give them, period. Again, this isn't necessarily a bad thing if HE thinks it can work to their long term advantage, but to try and claim that this is anything else is completely disingenuous. I understand that you have a PR position to take, and you may even have done a good job convincing the weak minded who don't understand how peering works that HE is the victim, but please don't try to feed a load of bullshit to the rest of us. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Quick comparison of LSNs and NAT64
Indeed. Unfortunately there's no good way to support v6-only clients in an environment, where dual stacked endpoints do exist as well, see RFC6147 (DNS64) ch. 6.3.2. We still need to find some solution to that problem. We've been using two workarounds: 1. Separate DNS resolvers (both BIND 9.8; one DNS64 and the other DNS6). Have the client provisioning system assign the appropriate DNS server IPs (dual-stack to anycast set 1, v6-only to anycast set 2). 2. Use range-specific views to determine whether or not to apply DNS64 (this setup isn't standard BIND, though). One is a kludge, and the other is vendor-specific, but they work. -Jeff
Re: Cogent HE
RAS wrote: On Thu, Jun 09, 2011 at 12:55:44AM -0700, Owen DeLong wrote: Respectfully, RAS, I disagree. I think there's a big difference between being utterly unwilling to resolve the situation by peering and merely refusing to purchase transit to a network that appears to offer little or no value to the purchaser or their customers. Owen, can you please name me one single instance in the history of the Internet where a peering dispute which lead to network partitioning did NOT involve one side saying hey, we're willing to peer and the other side saying no thanks? Being the one who wants to peer means absolutely NOTHING here, the real question is which side is causing the partitioning, and in this case the answer is very clearly HE. I don't know if Owen can, but I know I can. Back in the day, when there were many fewer Tier-1's but the number was growing, there were enough disputes over peering requests that there was a danger of things actually getting regulated (e.g. by the dreaded FCC). As part of one of the many mergers, the biggest player at that time (AS 701), made their peering requirements public, *and* honored those requirements. So, long history short, there were in fact peering disputes that had one side saying, hey, we want to peer and the other side saying you don't have enough traffic, or your ratio is too imbalanced, or you're my customer - tough!. And some of those got resolved by the ratios changing, or the traffic levels reaching sufficiently high. (I can historically mention AS 6453.) Some of the other early players didn't play fair, and to my knowledge still don't. You have to know someone, or be named Ren to get peering with them. (Sorry, Ren. :-)) IMHO, what Cogent are effectively trying to do, is to extort paid peering, masquerading as transit. Personally, I think the global traffic patterns, loss/latency/jitter, and general karma of the Internet would be improved, if those who currently peer with Cogent were to do evaluate the impact of de-peering them: - How many networks are *single*-homed behind Cogent? - Is anyone who *needs* Internet connectivity that unwise (to be single homed anywhere, let alone behind Cogent)? - If they *are* single-homed-to-Cogent, they aren't *your* customers. :-) - (This could be applied to both IPv6 *and* IPv4 - the logic is the same) Brinksmanship, like virtue or stupidity, is its own reward. Brian P.S. In the ancient game go, there's a special rule on the two players playing alternate single-piece steals, that limits it to N times for very small N. The game becomes futile and pointless, beyond a certain number of repeated moves. Ditto for not peering.
Re: Cogent HE
On 06/09/2011 06:21 PM, Richard A Steenbergen wrote: On Thu, Jun 09, 2011 at 12:55:44AM -0700, Owen DeLong wrote: Respectfully, RAS, I disagree. I think there's a big difference between being utterly unwilling to resolve the situation by peering and merely refusing to purchase transit to a network that appears to offer little or no value to the purchaser or their customers. Owen, can you please name me one single instance in the history of the Internet where a peering dispute which lead to network partitioning did NOT involve one side saying hey, we're willing to peer and the other side saying no thanks? Being the one who wants to peer means absolutely NOTHING here, the real question is which side is causing the partitioning, and in this case the answer is very clearly HE. HE wants to peer with Cogent, Cogent doesn't want to peer with HE, and thus you have an impass and there will be no peering. HE has no problem using transit to reach Cogent for IPv4 (I see HE reaching Cogent via 1299/Telia, and Cogent reaching HE via 3549/Global Crossing, both very clearly HE transit providers and Cogent peers), but HE has chosen not to use transit for the IPv6 traffic. Quite simply, HE feels that they are entitled to peer with Cogent for the IPv6 traffic, and has deliberately chosen to create this partition to try and force the issue. These are *PRECISELY* the same motivations and actions as EVERY OTHER NETWORK who has ever created a network partition in pursuit of peering that the other party doesn't want to give them, period. Again, this isn't necessarily a bad thing if HE thinks it can work to their long term advantage, but to try and claim that this is anything else is completely disingenuous. I understand that you have a PR position to take, and you may even have done a good job convincing the weak minded who don't understand how peering works that HE is the victim, but please don't try to feed a load of bullshit to the rest of us. :) From reading everything you have said my impression is YOU either work for Cogent or have an axe to grind with HE. Otherwise I can see no reason for your obvious bias against HE. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com
Re: Cogent HE
On Thu, Jun 09, 2011 at 07:06:29PM -0400, Brian Dickson wrote: So, long history short, there were in fact peering disputes that had one side saying, hey, we want to peer and the other side saying you don't have enough traffic, or your ratio is too imbalanced, or you're my customer - tough!. And some of those got resolved by the ratios changing, or the traffic levels reaching sufficiently high. (I can historically mention AS 6453.) How is that different from what I said? One side wants to peer, the other side says no thanks. A list of reasons is nice, especially if they will actually grant peering after you meet those requirements (instead of just changing their requirements to deny you again :P), but immaterial to the point. In EVERY peering dispute there is one side who wants to peer, but that doesn't make this side any more noble or right, especially if they don't meet the requirements and are simply trying to force the peering through intentionally creating a partition then playing the propaganda game to blame the other side for it. Everyone complained when Cogent did it to others, why should it be any different when HE does it to Cogent? I'm sorry but I don't accept because Cogent is giving away free IPv6 transit right now as a valid reason, especially when it very clearly advances their goals of artificially inflating their customer base specifically so they CAN engage in these peering disputes. It's a perfectly valid tactic that has been used by the finest networks for years, but at least have the decency to admit it for what it is, that's all I'm saying. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Cogent HE
On Thu, Jun 9, 2011 at 5:21 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Thu, Jun 09, 2011 at 12:55:44AM -0700, Owen DeLong wrote: Er, Sorry... you are kind of siding with Cogent and claiming HE responsible without any logically sound argument explicitly stated that supports that position... I would consider them both responsible for the partition, with Cogent slightly more complicit, in that Cogent's expectation of selling HE transit is slightly less reasonable than HE's expectation of Cogent peering with HE. Perhaps Cogent is actually responsible, because Cogent has failed to ask HE to peer, and Cogent has not sought to buy transit from HE to correct the network partition. HE wants to peer with Cogent, Cogent doesn't want to peer with HE, and thus you have an impass and there will be no peering. HE has no problem using transit to reach Cogent for IPv4 (I see HE reaching Cogent via Cogent wants HE to buy IPv6 transit with Cogent, HE doesn't want to buy IPv6 transit with Cogent, and thus you have an impass, and there will be no buying of transit. [References to IPv4 networks are irrelevent; the IPv4 internet is not like the IPv6 internet.] 1299/Telia, and Cogent reaching HE via 3549/Global Crossing, both very clearly HE transit providers and Cogent peers), but HE has chosen not to use transit for the IPv6 traffic. Quite simply, HE feels that they are entitled to peer with Cogent for the IPv6 traffic, and has deliberately Cogent has chosen not to use transit for the IPv6 traffic to HE. Quite simply, Cogent feels they are entitled to sell transit to HE for the IPv6 traffic, and has deliberately chosen to create this partition to try and force the issue. These are *PRECISELY* the same motivations and actions as EVERY OTHER NETWORK who has ever created a network partition in pursuit of selling transit that the other party doesn't want to buy, period. Again, this isn't necessarily a bad thing if HE thinks it can work to Again, this isn't necessarily a bad thing if Cogent thinks it can work to their long term advantage, but to try and claim that this is anything else is completely disingenuous. I understand that you have a PR position to take, and you may even have done a good job convincing the weak minded who don't understand how peering works that HE is the weak minded who don't understand how peering works that Cogent is the victim, but please don't try to feed a load of bullshit to the rest of us. :) -- -JH
Re: Quick comparison of LSNs and NAT64
In message banlktimkba5hy3samtzb6w51mghgxqm...@mail.gmail.com, Cameron Byrne writes: --000e0ce0b4eaf1531104a5486aed Content-Type: text/plain; charset=ISO-8859-1 On Jun 9, 2011 1:32 AM, Mark Andrews ma...@isc.org wrote: In message 4df053aa.50...@axu.tm, Aleksi Suhonen writes: Hello, Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why: NAT64 scales much better than NAT44 and NAT444(*) The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two records of different NAT64 boxes, in case that works better with some application protocols. You can add more capacity with DS-Lite as well though it does take a while for the DHCP option to be refreshed without push support. The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat. I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it: http://www.trex.fi/2011/dns64.html A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet. You don't have to pass all the traffic through the AFTR box or the LSN when dual stacked either. The AFTR box can be on the other side of the world or out sourced if you want it to be. The same can be done with NAT64. The biggest downsides I've encountered are: I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority. Not a problem with DS-Lite or NAT444. II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either. Not a problem with DS-Lite or NAT444 So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope. My 2 cents delivered, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail (*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN. All good and accurate info. I would just restate that nat64 unlike nat444 does not need to be on path, this is what drives its improved scaling over nat444. NAT44 only needs to be on the IPv4 path. It does NOT need to be on the IPv6 path. Similarly NAT64 and AFTR need to be on the IPv4 path not the IPv6 path. Also, unlike ds-lite, nat64 works without any special client, such as the b4 function in the ds-lite architecture. Any fully functional ipv6 system such as win7 can work out of the box (ipv4 only apps being the exception) No. It needs a specialised nameserver with DNS64 support, which prevents machines running there own nameserver until they get such a nameserver and get the prefix information to configure the DNS64 component. As for the B4, I can manually configure that on 10 year old boxes. It's basically a IPv4 in IPv6 tunnel. Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by making ipv6 end to end and forcing applications to be AF agnostic as where the others enable ipv4 without any backpressure. DS-lite and NAT444 don't break existing applications. If you have a green field deployment the limitations of NAT64/DNS64 can often be overlooked. When you are deploying into a exist IPv4 network you don't have the luxury of breaking more existing applications that is absolutely necessary. Each solution fits well for some set of constraints and objectives Cb -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark
Re: Multi Factor authentication options for wireless networks
We use wireless authentication for the purposes of protecting the link layer... authenticated users are still outside the privileged corprate network and therefore need to vpn in. joel On Jun 9, 2011, at 3:02 PM, eric clark wrote: Wondering what people are using to provide security from their Wireless environments to their corporate networks? 2 or more factors seems to be the accepted standard and yet we're being told that Microsoft's equipment can't do it. Our system being a Microsoft Domain... seemed logical, but they can only do 1 factor. What are you guys using? Thanks
Re: Cogent HE
On Thu, Jun 09, 2011 at 06:26:01PM -0500, Jimmy Hess wrote: Er, Sorry... you are kind of siding with Cogent and claiming HE responsible without any logically sound argument explicitly stated that supports that position... You're confused, read again. :) I would consider them both responsible for the partition, with Cogent slightly more complicit, in that Cogent's expectation of selling HE transit is slightly less reasonable than HE's expectation of Cogent peering with HE. Cogent is (unfortunately, note I have no particular love for Cogent here) a transit free network, who peers with every other Tier 1. HE is a perfectly fine network, but they are not even CLOSE to a transit free network. HE buys transit from multiple other networks, including 3549/Global Crossing and 1299/Telia (both easily visible in the routing table), which they use to reach Cogent for IPv4. There is absolutely NO requirement that there be a direct interconnection between HE and Cogent. None, period, and if you think otherwise you are vastly confused about routing on the Internet. Let me say this again, there is NO requirement that HE buy transit from Cogent, but there is a requirement that HE buy transit from *SOMEONE* if they are not a transit free network. HE has deliberately chosen NOT to use transit for their IPv6 routes, in order to force people like Cogent to peer with them so they can become an IPv6 Tier 1, and thus you have a partition. These are the same tactics and strategies used by every other network in pursuit of becoming a Tier 1, including Cogent, and everyone complained their ass off when Cogent caused partitioning several times during THEIR peering disputes on the road to their current transit free status. If your answer is I like HE better than Cogent so I'm willing to overlook it, that's fine, but you're just making things up if you're trying to claim that they AREN'T causing this partition. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Cogent HE
On Thu, Jun 9, 2011 at 6:49 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Thu, Jun 09, 2011 at 06:26:01PM -0500, Jimmy Hess wrote: You seem to have missed it, so I will say again: IPv6 is not IPv4. They are two different internetworks, with different participants -- many IPv4 networks have no IPv6 counterpart as of yet. Having any kind of IPv6 network is a new thing for Cogent; they opened shop, when, 2008, sometime? I'm pretty sure HE had an IPv6 network and a greater degree of connectivity, before you could get IPv6 from Cogent. Many Tier1 IPv4 networks had no IPv6 network for a long time; the first day an IPv4 Tier1 turns on IPv6 doesn't magically make them IPv6 Tier1 -- because the v6 network has a different topology, there are many 'holes' in the graph, where the new network's peering arrangements will be IPv4 only. An IPv4 Tier1 might actually need to buy transit to get connected to the IPv6 internet, if they are sufficiently late for the show. There is a chance IPv4 and IPv6 topologies will become more similar in the future, but for now that is not the case, and that is no reason to confuse the two networks, or speak as if they are one and the same. Cogent doesn't have a transit-free global IPv6 network view. Cogent is (unfortunately, note I have no particular love for Cogent here) a transit free network, who peers with every other Tier 1. HE is a No, Cogent has a transit free IPv4 network; Cogent peers with every other IPv4 Tier 1. It appears as if they are trying to use their IPv4 Tier1 status as a strategic piece, to attempt to get Tier1 status on the IPv6 network. That might work well with other Tier1s who are also behind in IPv6 deployment, and possibly apt to peer with Cogent. But that effort doesn't automatically make Cogent a Tier1 on the IPv6 network. We'll just have to wait and see about that, I think. perfectly fine network, but they are not even CLOSE to a transit free network. HE buys transit from multiple other networks, including You mean HE is not close to being a transit free IPv4 network. They have a very nearly transit-free IPv6 network. There is absolutely NO requirement that there be a direct interconnection between HE and Cogent. None, period, and if you think otherwise you are vastly confused about routing on the Internet. Let me say this again, there is NO requirement that HE buy transit from Cogent, but there is a requirement that HE buy transit from *SOMEONE* if they are not a transit free network. HE doesn't need to buy IPv6 transit, because they are in effect transit-free (except to Cogent). HE has deliberately chosen NOT to use transit for their IPv6 routes, in order to force people like Cogent to peer with them so they can become an IPv6 Tier 1, and thus you have a partition. These are the same -JH
Re: OT: Google logo
- Original Message - From: Fairlight fairl...@fairlite.com Not just graphics...the fact that Chrome is HTML5 compliant. That's how they're doing what they're doing with this one, and the previous one with all the physics balls that would blow around, etc. FF4 too apparently; I had it. -- jr 'call you tomorrow, Brian' a -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Yup; the Internet is screwed up.
Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster That can't be good. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Ready For A Good Laugh
Ok, I have to paste this in time order so that the rest of you can play along it all started when I tried to transfer in a new domain name for - of all people, my future father in law. I am SO not screwing that up because I don't want to hear it at every family gathering Since my hunny bunny who is somewhat technical has been managing it, he wanted me take it over mainly so that we could host his email on the server I already run. I apologize in advance for the HTML email, but plain text just can't convey some things - including the phishy appearance of the official emails that come from these people. Email #1 - Dated May 4 * Aplus.Net 110 East Broward Boulevard, Suite 1650 Fort Lauderdale, FL 33301 Phone: 1.877.275.8763 * * Customer Information* Name: Jimi Thompson Customer number: * Amount due:* All amounts in US dollars. *Service Description* *Term* *Total* Domain Registration -- Domain name: XXX -- Ongoing fee from 2011-05-04 to 2012-05-04 1 year $12.99 1 month $0.00 *Total Savings* *$0.00* *Total Due Now* *$12.99* Keep in mind that this is just the domain registration - NO hosting. I do my own hosting. So I get this on May 5. Congratulations on your decision to host with Aplus.net! We're proud to have your business, and we're committed to making your web hosting experience a success. This email provides you with information on how to get started. Please keep this message for future reference. Thanks again for choosing Aplus.net! Best regards, Your Aplus.net Team Now what I can't paste in here are the several rather heated telephone conversations we had because they don't preserve the DNS servers when a domain name is transferred to them. Oh, no... YOU get a parking page until the transfer is complete and you can manage the name servers. And I was informed that the transfer would take at least 5 business days. And the user interface doesn't allow you to set the DNS servers until after the transfer is completed.With the weekend included, that was nearly a full week of down time. Completely unacceptable.Finally, they agreed to cancel the transfer. This missive arrives after a few hours of wrangling with their tech support and DNS support people, who incidentally are also unable to set the name servers until the transfer is complete. And during all this, I am required to recite both my user name and password. Since one phone call happened at Taco Bell during my lunch break, I'm understandably upset over having to give sensitive credentials in order to attempt to obtain some assistance. Dear Jimi Thompson We confirm that the following domain transfer has been cancelled. Followed Immediately By This Dear valued customer, Your email has been received by the Aplus.net Support Team. One of our technical support representatives will review and respond to your request. Should you have an immediate question or concern, please call us at 877.275.8763, or try our chat service at www.aplus.net (select Technical Support). Our reps are available 24 hours a day, 7 days a week. If you have questions related to the recent platform enhancements, please visit http://faq.aplus.net to view answers to many frequently asked questions. Thank you for choosing Aplus.net. We appreciate your continued business. Sincerely, Aplus.net And not long after that arrived, I got this: Hello Jimi, Thank you for contacting Aplus.net Technical Support! We have forwarded your question on to our Customer Service Department team, and they will be able to assist you with this issue. You will be hearing back from them directly. If you prefer to contact Customer Service Department directly, you can reach them at bill...@cs.aplus.net or by phone 877-275-8763 option 3+1 for United States and 858-410-6929 option 3+1 Worldwide. For more information about the Aplus.net Upgrade or for answers to Frequently Asked Questions please visit our Aplus.net FAQ at http://faq.aplus.net. To find out more about how to set up your email account visit http://faq.aplus.net/email To find out more about domain registration visit http://faq.aplus.net/domain To find out more about how to connect to your site using FTP visit http://faq.aplus.net To find out more about new DNS settings visit http://faq.aplus.net/dns Did You Know? You can review or submit tickets to the Aplus.net Support Team through your control panel. To review or submit a ticket simply take the following steps: 1. Log into your control panel. 2. Select My Account. 3. Click on the Tickets icon. To assist us in serving you better, please do not delete any portion of the Technical Support Specialist correspondences. For your convenience we are available 24 hours a day, 7 days a week and invite you to contact us if you have any additional concerns. Regards, Sylvia Y. Technical Support Specialist APLUS.NET http://aplus.net/, a Deluxe Company Phone: 877.275.8763 Email: supp...@aplus.net www.aplus.net I'm having a
Re: Ready For A Good Laugh
On Thu, Jun 9, 2011 at 8:22 PM, Jimi Thompson jimi.thomp...@gmail.comwrote: Ok, I have to paste this in time order so that the rest of you can play along tl';dr Summary: cheap registers abound. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 re a
Re: Ready For A Good Laugh
Jimi Thompson wrote: Now I'm going to go off on you people - What kind of crack are you people smoking? The same stuff they're smoking over at PayPal. Some genius decided to send out E-mails which said: Hello name removed, It looks like you may be using an outdated browser with known security issues. Help keep your computer and your PayPal account protected by updating your browser today. and included a link (different from what was represented). Even magaged to fool the folks at sp...@paypal.com 11 pages of wtf? at: https://www.paypal-community.com/t5/Fraud-phishing-and-spoof/New-scam/td-p/273626
Re: Ready For A Good Laugh
- Original Message - From: Joe Hamelin j...@nethead.com On Thu, Jun 9, 2011 at 8:22 PM, Jimi Thompson jimi.thomp...@gmail.comwrote: Ok, I have to paste this in time order so that the rest of you can play along tl';dr It's a damned shame there isn't a .dr ccTLD, isn't it? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Hotmail Problems
Any other operators getting complaints from subscribers about not being able to open emails in hotmail? The problem seems to be random. Are there are hotmail administrators on this list? Richard
Re: Hotmail Problems
On Fri, Jun 10, 2011 at 12:52:46AM -0400, Richard McNeilly wrote: Any other operators getting complaints from subscribers about not being able to open emails in hotmail? The problem seems to be random. Are there are hotmail administrators on this list? Richard At my work we do have some complaints about email to Hotmail not showing up. One users is sending email to two different users at Hotmail, one of those receives them, the other not. Both are accepted by the Hotmail relays.
Re: Cogent HE
On 2011-Jun-10 02:18, Jimmy Hess wrote: On Thu, Jun 9, 2011 at 6:49 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Thu, Jun 09, 2011 at 06:26:01PM -0500, Jimmy Hess wrote: You seem to have missed it, so I will say again: IPv6 is not IPv4. First you seem to have missed the point where the Internet is since the day before yesterday the combination of IPv4+IPv6. You also seemed to have missed the part where Tier1 are supposed to provide quality native multi-path connectivity globally and not peering mostly in a tunneled fashion (oh MTU what you don't reveal) with one little router stashed at an unmanned IX. Especially that tunneled part requires IPv4 to actually be able to transmit those IPv6 packets, thus without the Tier1 status in IPv4 you really cannot claim Tier1 in IPv6 in that case. Also note that prefix count says nothing, first aggregate all the prefixes properly, ignoring ASNs which use prefixes out of a PA dump, then see how many are actually left. Of course as an extra and possibly way more important metric: check how many of those prefixes you would actually like to reach (that is where you have an interest of sending packets to/from). You might indeed be able to 'complete' your routes with it, but are those routes worth it calling something a Tier1? ;) Greets, Jeroen
