Re: anyone else seeing very long AS paths?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I just received reply from Sloan-Park, that they have shutdown that customer yesterday 6:40pm CET and the customer has been requested to clean-up his config. BR Jens Jason Kalai Arasu schrieb: > I encountered it yesterday from AS47868. > > -Original Message- > From: Paul Ferguson [mailto:fergdawgs...@gmail.com] > Sent: Tuesday, February 17, 2009 01:02 PM > To: nanog@nanog.org > Subject: Re: anyone else seeing very long AS paths? > > On Mon, Feb 16, 2009 at 8:51 PM, Michael Ulitskiy > wrote: > >> It hit my routers at 11:26:40, EST. > >> Michael > >> On Monday 16 February 2009 07:26:23 pm Adam Greene wrote: >>> Anyone have an estimate as to when these long announcements began? >>> Seems like the first reports appeared just before noon, UTC-05. >>> >>> We noticed a significant dip in Internet traffic to AS11579 for a few > >>> minutes last night (19:00 UTC-05) which we've been trying to hunt >>> down the cause of. At first glance, the two events seem unrelated. >>> Anyone else see anything similar? > > > Just as a follow-up -- and in case anyone hasn't read these yet: > > http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml > http://asert.arbornetworks.com/2009/02/ahh-the-ease-of-introducing-globa > l-r > outing-instability/ > > - ferg > - -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ - -- === Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j@plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstraße 9-11 50354 Hürth Germany HRB 58428 / Amtsgericht Köln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschläger === -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmafQAACgkQMf0yjMLKfXowUACgi4F/j+eGkFfL+2G01r/Ohb0Q XgIAoI4jH6WrkngSOUlDK5lBUZZ3wuEE =/66k -END PGP SIGNATURE-
Re: anyone else seeing very long AS paths?
* Hank Nussbacher: > "They" will keep trying and until a vast majority of ISPs implement > maxas, this will keep happening. Or enthusiastic prepending will be used more often to override local preference. Hard to tell. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: anyone else seeing very long AS paths?
On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > A regular UN of attempts to do this previously: > > 24532 - PT. Inet Global Indo, Indonesia > 43179 - Team Consulting AS, Bosnia and Herzegovina > 48262 - Noblecom Ltd., Bulgaria > 6488 - Arizona Macintosh Users Group, USA > 39625 - Omni-Araneo, Poland > 33838 - BetaNET sp. z o.o, Poland > 47868 - SUPRO, spol. s r.o., Czech Republic > > "They" will keep trying and until a vast majority of ISPs implement > maxas, this will keep happening. Or until people who are still running multi-year old cisco code actually upgrade? This seems to primarily impact: 1) Old cisco code 2) PC based bgp daemons Both of which likely just need to be upgraded. I actually suspect that a lot of people who dropped their bgp sessions did not notice something happened, and still will not upgrade their code. I searched the archives, some variations of this have happened since 2001. There's been a few PSIRT and other issues since then, I suspect these people don't even know they have a bgp speaking device anymore. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
IP DSLAMs
All, Looking for a recommendation on DSLAMs to replace our unsupported Cisco 6015s. Requirements are: G.SHDSL 2 and 4 wire mode (CPEs are strictly Cisco 828, 878, and small cisco routers using WIC-1SHDSL and the V2/V3 of them) QOS would be nice, not a necessity SNMPv3 and SSHv2 support IPv6 support now or in a future upgrade Doesn't need to actually route, but if it can bridge one or more downstream CPEs into an ethernet dot1q VLAN on an uplink, that'll work Don't want ATM uplinks, ethernet only, dual uplinks preferred Looking for port density ranging from 15 to about 100 in a chassis Power can be DC, but AC is greatly preferred Off-list responses appreciated, since this is kind of OT. These are for large campus environments where some remote buildings are maybe a mile or two from a campus-owned telecom shack, with only copper connectivity to said building. No POTS is required over the DSL links, the copper pairs are dedicated. Thanks, Chuck
Re: anyone else seeing very long AS paths?
Jared Mauch wrote: On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: "They" will keep trying and until a vast majority of ISPs implement maxas, this will keep happening. Or until people who are still running multi-year old cisco code actually upgrade? This seems to primarily impact: 1) Old cisco code 2) PC based bgp daemons Both of which likely just need to be upgraded. I actually suspect that a lot of people who dropped their bgp sessions did not notice something happened, and still will not upgrade their codeI suspect these people don't even know they have a bgp speaking device anymore. On the other hand, the fact that various entities have gone out of their way to advertise that they're running old hardware/out-of-date software has been noted elsewhere. I'd strongly suggest, if you're reading NANOG, that you update, before someone less pleasant and friendly than myself finds you. Please. -- Remember, if it's in the news, don't worry about it. The very definition of news is "something that almost never happens." When something is so common that it's no longer news -- car crashes, domestic violence -- that's when you should worry about it. (Bruce Schneier)
Re: anyone else seeing very long AS paths?
On Tue, Feb 17, 2009, Etaoin Shrdlu wrote:
> On the other hand, the fact that various entities have gone out of their
> way to advertise that they're running old hardware/out-of-date software
> has been noted elsewhere. I'd strongly suggest, if you're reading NANOG,
> that you update, before someone less pleasant and friendly than myself
> finds you. Please.
What, and the other, "make sure you hard limit the max AS path length from
customers and peers, in case of ${LINK_TO_THIS_NANOG_THREAD} ?"
Adrian
Re: anyone else seeing very long AS paths?
My bgp speaking devices are a couple of 7200s running 12.2(40). Not the newest IOS out there, but it's been doing the job just fine up until yesterday. Yesterday, when that malformed announcement hit my routers they didn't crash, but they did reset bgp sessions (even though I didn't accept the route) and they kept doing so until I got my upstream to filter it out. According to cisco bug toolkit CSCdr54230 should be fixed in 12.2, so obviously it's not enough. Does anybody know what IOS version has fix this problem, 'cause I couldn't find this info at CCO? Thanks, Michael On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote: > Jared Mauch wrote: > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > > >>"They" will keep trying and until a vast majority of ISPs implement > >>maxas, this will keep happening. > > > Or until people who are still running multi-year old cisco code > > actually upgrade? This seems to primarily impact: > > > > 1) Old cisco code > > 2) PC based bgp daemons > > > Both of which likely just need to be upgraded. I actually suspect > > that a lot of people who dropped their bgp sessions did not notice > > something happened, and still will not upgrade their codeI > > suspect these people don't even know they have a bgp speaking device > > anymore. > > On the other hand, the fact that various entities have gone out of their > way to advertise that they're running old hardware/out-of-date software > has been noted elsewhere. I'd strongly suggest, if you're reading NANOG, > that you update, before someone less pleasant and friendly than myself > finds you. Please. >
Re: anyone else seeing very long AS paths?
On Tue, 17 Feb 2009, Jared Mauch wrote: Or until people who are still running multi-year old cisco code actually upgrade? This seems to primarily impact: 1) Old cisco code 2) PC based bgp daemons Both of which likely just need to be upgraded. I actually suspect that a lot of people who dropped their bgp sessions did not notice something happened, and still will not upgrade their code. I searched the archives, some variations of this have happened since 2001. There's been a few PSIRT and other issues since then, I suspect these people don't even know they have a bgp speaking device anymore. While at it - perhaps others wish to join this bugid so as to enhance IOS: CSCso47162 Bug Details BGP-6-ASPATH message should print offending prefix(es) None Symptoms Syslog message below doesn't print info about offending prefix(es) %BGP-6-ASPATH: Invalid AS path [chars] received from [int]: [chars] Further Problem Description Examples of such a message : %BGP-6-ASPATH: Long AS path 64501 64501 65000 65000 received from x.x.x.x: Morethan configured MAXAS-LIMIT %BGP-6-ASPATH: Invalid AS path (64721) 64700 64720 65400 65231 received from x.x.x.x: Non confederation peer I opened it in March 2008 and the more people who bug Cisco to implement this sev 6 request - the better off we will all be in the future. -Hank
IPv6 Confusion
So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either? >From what I can tell, this may still be a question of great debate. Everyone >seems to act like they know exactly what's going on but behind closed doors >admits that they don't really know x, y, or z. I realize this is typical of >my industry and even myself from time to time. J But so I am truly reaching out here. What is the deal with IPv6 addressing and subneting? Where is the official guide to this new galaxy? I will be sure to pass this information on to my equally less clueful peers to the benefit of all of us that are making this transition. There are people here at my company that seem to get it but can't seem to explain it clearly to me. To me, its basically just larger addressing space with some new logical boundaries But there are so many discussions of potential addressing methods that I am confused. I know from my lab setups that I can "make it work" but I'd like to "do it right". J I've been doing this for over 10 years now... IPv4 is native to me. If you can point me in the direction of some good, authoritative information or even say "Dood, go get IPv6 for dummies", that's fine I just need to know where to find some good information. Can someone say "well, you know how it would be nice to have like 100 different addresses on hosts to differentiate services and blah blah Well now that's what you account for and so then you know how a /24 almost always ends up being tight in IPv4? Right, so think of your basic bit boundaries that you adhere to as /?? And /??? In IPv6." Or "Throw all that old thought out the window. Now its kind of like how the Ford Probe is actually a Mazda... ummm Yeah I can't really explain it either but it makes sense. Here read this book and it'll make sense to you too." Respectfully yours, Carl Rosevear
Re: IPv6 Confusion
On Tue, 17 Feb 2009, Carl Rosevear wrote: So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? If you are interested about the addressing architecture only, have a look at RFC 4291: http://tools.ietf.org/html/rfc4291 If you want to have some allocation guidelines from experiences, have a look at these slides: http://www.6deploy.org/tutorials/030-6deploy_ipv6_addressing_v0_2.pdf http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.pdf http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_3.pdf Best Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
RE: IPv6 Confusion
>How does IPv6 addressing work? Short version: 2000::/3The currently active global unicast pool RIRx::/12 IANA (by default) assigns /12s to RIRs RIRx:ISPx::/32 RIRs (by default) assign /32s to ISPs RIRx:ISPx:ORGx::/48 ISPs (by default) assign /48s to enterprises (/56s to homes) RIRx:ISPx:ORGx:VLAN::/64Enterprises 'subnet' their allocation into /64s(debate over [/126 | /127] to P2P links) >I know it's been hashed and rehashed but several orgs I am associated with are >about to ask for their allocations from ARIN and we are all realizing we don't >really know how the network / subnet structure trickles down from the edge to >the host. We really don't have a firm grasp of all of this as there seems to >be multiple options regarding how many addresses should be assigned to a host, >if the MAC address should be included in the address or if that is just for >auto-configuration purposes or what the heck the deal is. There are a lot of >clear statements out there and a lot that are clear as mud. Unfortunately, >even when trying to analyze which RFC superseded another. Can I just subnet it Use the IETF/RFC web interface, clearly shows what RFCs where deprecated by, or deprecate/update, a given doc: e.g. - http://tools.ietf.org/html/rfc2461 ... has an obsoleted by, updated by, and obsoletes ... >all like IPv4 but with room to grow or is each host really going to need its >own /84 or something? I can't see why hosts would need any more addresses than >today but maybe I'm missing something because a lot of addressing models sure >allow for a huge number of unique addresses per host. > > >My buddy and I are about to go to Barnes and Noble, not having and luck with >standard internet media but then we realized... how will we know if any of >that is really what we are looking for either? Depends what you are looking for, and possibly your HW vendor of choice. <>
Re: IPv6 Confusion
You already have a fair bit of information, but the short answer to your question is... Apart from a few special purposes addresses (see RFC 4291), IPv6 addresses are a cross between IPv4-style CIDR addressing and XNS/IPX/ ISO-style network+host addressing. Bits 0..63 of the address are a CIDR prefix; there are various guidelines on what prefix lengths should be allocated in various cases, but they are just that - unenforceable and mutable. Bits 64..127 are a host part, which may be a MAC Address, a random number, or pretty much anything else. The key thing is that the host part is unique on a LAN. There are probably four important prefix lengths in the world - prefixes that might have special meaning, prefixes that get allocated by IANA, prefixes that get allocated by RIRs, and prefixes that get allocated to customers of ISPs. In general, IANA is treating IPv6 much like IPv4 - making sure that the RIRs have enough to work with. The RIRs are also treating IPv6 much like IPv4, with the exception that the rules require a lot less hoop-jumping. If folks need prefixes, they hand them out. The one difference is that they are trying to avoid PI addressing, as that is one of the major contributors to the current explosion of the route table (the others being "long prefixes" and "traffic engineering"). What to replace PI addressing with is a topic of ongoing discussion - various ideas have been proposed but all require some change to some business model or sacred cow somewhere, meaning that any idea that is viable gets dismissed pretty rapidly, something the folks who buy memory for routers will eventually pay the price of unless that nonsense passes. Edge networks are edge networks; they tend to assign subnets, or campuses with subnets in them. On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either? From what I can tell, this may still be a question of great debate. Everyone seems to act like they know exactly what's going on but behind closed doors admits that they don't really know x, y, or z. I realize this is typical of my industry and even myself from time to time. J But so I am truly reaching out here. What is the deal with IPv6 addressing and subneting? Where is the official guide to this new galaxy? I will be sure to pass this information on to my equally less clueful peers to the benefit of all of us that are making this transition. There are people here at my company that seem to get it but can't seem to explain it clearly to me. To me, its basically just larger addressing space with some new logical boundaries But there are so many discussions of potential addressing methods that I am confused. I know from my lab setups that I can "make it work" but I'd like to "do it right". J I've been doing this for over 10 years now... IPv4 is native to me. If you can point me in the direction of some good, authoritative information or even say "Dood, go get IPv6 for dummies", that's fine I just need to know where to find some good information. Can someone say "well, you know how it would be nice to have like 100 different addresses on hosts to differentiate services and blah
Re: IPv6 Confusion
I can't help directly with your biggest question, but there's a smaller point here that seems to come up a lot and I think is important to address... On Tue, Feb 17, 2009 at 8:59 AM, Carl Rosevear < carl.rosev...@demandmedia.com> wrote: > I can't see why hosts would need any more addresses than today but maybe > I'm missing something because a lot of addressing models sure allow for a > huge number of unique addresses per host. According to your website your head office is located at "1333 2nd St., Suite 100". Is there a 1331 2nd Street? Or a 1335? Or even a Suite 99? Or has the street addressing system been created in a wasteful manner in order to allow flexibility in addressing and allow the numbers themselves to be more than just numbers? Just like street numbers, IPv6 is a near limitless resource, which allows for the address assigned to be more than just a simple, single address. Yes, this results in some "waste", just like having to write "1333" in your address where "17" might have sufficed. IPv6 assigns a /something to each "thing", in the same way as many areas in the US simply assign 100 numbers to each block. In that sense IPv6 requires a mind-set change from IPv4 - you can stop thinking in terms of the absolute minimum requirements (eg, a single IP address in v4 because they are a scarce commodity) and start thinking about what works best for the larger environment (such as just handing out a /64 to each network and allowing autoconfig to handle the rest). Is that wasteful? Hell yeah! Does it matter? No! The bigger question here is of course what size "/something", and what is a "thing", and as recent discussions here and elsewhere have proven there's still some contention over those questions - especially around home users. The problem is that as an industry there simply hasn't been enough IPv6 deployment done to know what will work and what will not - or what is "best" (for some definition of "best") I'm sure many of us were around in the days when if even a smaller customer wanted a network routed you were just as likely to either give them a class C, or even to get them to register their own class C - because at the time we thought that was the right thing to do. Over the years as the commercial Internet grew we leant what was the "best" thing to do in most cases, and the same business who 15 years ago was registering their own class C would today probably get gives a single IP address - possibly even a dynamic one! Of course the hardware also changed with the times, so that now the $30 router you can buy at Walmart has NAT, DHCP, uPNP and the ability to update DDNS all buit in to make the model work. Odds are what is best is going to be "best" for IPv6 will be a similar iterative approach - the model the first round of IPv6 ISPs roll out will probably not be the same as the one we're using in 5-10 years. Part of this will be due to limitations in the infrastructure (not the least the home-user CPE), but part of it of it will simply come down to experiences, and learning what does and doesn't work well. Today you'll find numerous RFCs and IETF drafts telling you in theory how it could/should work, but until there's more people doing it these are little more than theory... Scott
Re: IPv6 Confusion
Mohacsi Janos wrote: If you are interested about the addressing architecture only, have a look at RFC 4291: http://tools.ietf.org/html/rfc4291 If you want to have some allocation guidelines from experiences, have a look at these slides: http://www.6deploy.org/tutorials/030-6deploy_ipv6_addressing_v0_2.pdf http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.pdf http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_3.pdf Just to add to this, beware the vendor documentation. In particular, I noticed many "examples" posted by vendors that used all kinds of notations. Cisco, for example, formally uses /64 in current documentation but still has a ton of old docs which use /112 or other similar boundaries. Since searches don't always turn up "most current", you may find obsolete documentation. -Jack
Re: IPv6 Confusion
On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? There are a lot of different possible answers to that question, many of which are accurate. In general: It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these are expected to be at least on nibble boundaries. There is an intent to support what is known as EUI-64, which means every subnet should be a /64, however, there are people who number smaller subnets and that is supposed to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is optional). I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. You can subnet it just like IPv4. Each host does not need it's own subnet (/64, not /84 for the most part). The theory behind /64 subnets was to support a way for a host to use what it already knows (MAC address) and possibly some additional clues (Router Announcement) from the wire to configure its own IPv6 address on an interface. Whether or not this was a good idea is still controversial, but, whether or not it's how IPv6 is going to work is not. IPv6 is designed to work with Stateless Autoconfiguration whether we like it or not. DHCPv6 so far is prevented from providing default router information (or many of the other things you're used to having DHCP do) as it currently stands. My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either? It's a fair point. There is a good FAQ/Wiki on the ARIN web site. That may be a good place to start. From what I can tell, this may still be a question of great debate. Everyone seems to act like they know exactly what's going on but behind closed doors admits that they don't really know x, y, or z. I realize this is typical of my industry and even myself from time to time. J But so I am truly reaching out here. What is the deal with IPv6 addressing and subneting? Where is the official guide to this new galaxy? I will be sure to pass this information on to my equally less clueful peers to the benefit of all of us that are making this transition. Officially, the best summary I can give is that the subnetting model is almost identical to IPv4, but, all subnets should be at least a /64 (and it's hard to imagine a scenario where a single subnet should be larger, but, it can be supported). The essential initial guidelines are: ISP /32 Enough for 4billion ISPs Enough for each ISP to support 65,536 /48 customers or 16.7M /56 customers, etc. Larger ISPs can get more than a /32 if needed. End Site/48 Enough for 65,536 /64 subnets Larger organizations can get more than a /48 if needed. Single Subnet /64 Enough for more hosts that most of us can imagine on a single subnet. Support for 64 bit MAC addresses Support for stateless autoconfiguration However, these guidelines can be violated in many circumstances to use smaller subnets if you really want to. I don't recommend it and there's really no reason to do so. Finally, if we're wrong about all of this, it's OK. We can renumber people into the other 7/8ths of the IPv6 space t
Re: anyone else seeing very long AS paths?
On Tue Feb 17, 2009, Michael Ulitskiy wrote: Hello, CSCee30718 – it removes the default value of bgp max-as from the router. The solution is introduced in CSCeh13489 BGP shouldn't propogate an update w excessive AS Path > 255 Symptoms: A router may reset its Border Gateway Protocol (BGP) session. Conditions: This symptom is observed when a Cisco router that peers with other routers receives an Autonomous System (AS) path with a length that is equal to or greater than 255. Workaround: Configure the bgp maxas limit command in such as way that the maximum length of the AS path is a value below 255. When the router receives an update with an excessive AS path value, the prefix is rejected and recorded the event in the log. This workaround has been suggested previously by Hank. Anyone knows about any possible CPU impacts in case that you implement bgp maxas? Thanks German > My bgp speaking devices are a couple of 7200s running 12.2(40). > Not the newest IOS out there, but it's been doing the job just fine up until > yesterday. > Yesterday, when that malformed announcement hit my routers they didn't crash, > but they did reset bgp sessions (even though I didn't accept the route) and > they kept doing so > until I got my upstream to filter it out. > According to cisco bug toolkit CSCdr54230 should be fixed in 12.2, so > obviously it's not enough. > Does anybody know what IOS version has fix this problem, 'cause I couldn't > find this info at CCO? > Thanks, > > Michael > > On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote: > > Jared Mauch wrote: > > > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > > > > >>"They" will keep trying and until a vast majority of ISPs implement > > >>maxas, this will keep happening. > > > > > Or until people who are still running multi-year old cisco code > > > actually upgrade? This seems to primarily impact: > > > > > > 1) Old cisco code > > > 2) PC based bgp daemons > > > > > Both of which likely just need to be upgraded. I actually suspect > > > that a lot of people who dropped their bgp sessions did not notice > > > something happened, and still will not upgrade their codeI > > > suspect these people don't even know they have a bgp speaking device > > > anymore. > > > > On the other hand, the fact that various entities have gone out of their > > way to advertise that they're running old hardware/out-of-date software > > has been noted elsewhere. I'd strongly suggest, if you're reading NANOG, > > that you update, before someone less pleasant and friendly than myself > > finds you. Please. > > > > pgptsqV6JzgBN.pgp Description: PGP signature
RE: IPv6 Confusion
Thanks to all that responded on and off-list. My confusion is mostly cleared-up. The points that are unclear at this point are generally unclear to most people, it seems due to lack of operational experience with IPv6. Feel free to keep responding to this topic as its all very interesting but I think my needs have been met. Owen, this one from you tied it all together. Thanks all! --Carl -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Tuesday, February 17, 2009 10:41 AM To: Carl Rosevear Cc: nanog@nanog.org Subject: Re: IPv6 Confusion On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: > So, I understand the main concepts behind IPv6. Most of my peers > understand. We all have a detailed understanding of most things > IPv4. I have Googled and read RFCs about IPv6 for HOURS. That > said, to quickly try to minimize people thinking I am an idiot who > asks before he reads, I need some answers. First of all, several of > my friends who feel they are rather authoritative on the subject of > things network-related have given me conflicting answers. So what's > the question? ... > > How does IPv6 addressing work? > There are a lot of different possible answers to that question, many of which are accurate. In general: It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these are expected to be at least on nibble boundaries. There is an intent to support what is known as EUI-64, which means every subnet should be a /64, however, there are people who number smaller subnets and that is supposed to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is optional). > I know it's been hashed and rehashed but several orgs I am > associated with are about to ask for their allocations from ARIN and > we are all realizing we don't really know how the network / subnet > structure trickles down from the edge to the host. We really don't > have a firm grasp of all of this as there seems to be multiple > options regarding how many addresses should be assigned to a host, > if the MAC address should be included in the address or if that is > just for auto-configuration purposes or what the heck the deal is. > There are a lot of clear statements out there and a lot that are > clear as mud. Unfortunately, even when trying to analyze which RFC > superseded another. Can I just subnet it all like IPv4 but with > room to grow or is each host really going to need its own /84 or > something? I can't see why hosts would need any more addresses than > today but maybe I'm missing something because a lot of addressing > models sure allow for a huge number of unique addresses per host. > You can subnet it just like IPv4. Each host does not need it's own subnet (/64, not /84 for the most part). The theory behind /64 subnets was to support a way for a host to use what it already knows (MAC address) and possibly some additional clues (Router Announcement) from the wire to configure its own IPv6 address on an interface. Whether or not this was a good idea is still controversial, but, whether or not it's how IPv6 is going to work is not. IPv6 is designed to work with Stateless Autoconfiguration whether we like it or not. DHCPv6 so far is prevented from providing default router information (or many of the other things you're used to having DHCP do) as it currently stands. > > My buddy and I are about to go to Barnes and Noble, not having and > luck with standard internet media but then we realized... how will > we know if any of that is really what we are looking for either? > It's a fair point. There is a good FAQ/Wiki on the ARIN web site. That may be a good place to start. >> From what I can tell, this may still be a question of great >> debate. Everyone seems to act like they know exactly what's going >> on but behind closed doors admits that they don't really know x, y, >> or z. I realize this is typical of my industry and even myself >> from time to time. J > > But so I am truly reaching out here. What is the deal with IPv6 > addressing and subneting? Where is the official guide to this new > galaxy? I will be sure to pass this information on to my equally > less clueful peers to the benefit of all of us that are making this > transition. > Officially, the best summary I can give is that the subnetting model is almost identical to IPv4, but, all subnets should be at least a /64 (and it's hard to imagine a scenario where a single subnet should be larger, but, it can be supported). The essential initial guidelines are: ISP /32 Enough for 4billion ISPs Enough for each ISP to support 65,536 /48 customers or 16.7M /56 customers, etc. Larger ISPs can get more than a /32 if needed. End Site/48 Enough for 65,536 /64 subnets Larger organizations can get more th
Re: anyone else seeing very long AS paths?
German Martinez wrote: Workaround: Configure the bgp maxas limit command in such as way that the maximum length of the AS path is a value below 255. When the router receives an update with an excessive AS path value, the prefix is rejected and recorded the event in the log. This workaround has been suggested previously by Hank. Anyone knows about any possible CPU impacts in case that you implement bgp maxas? bgp max-as will NOT protect you from this exploit (but if you are not vulnerable it should prevent you from propogating it). As far as I can tell the ONLY defense for a vulnerable IOS is to not run BGP. Dropping every received route with a filter on 0/0 does not mitigate the attack - as soon as that bogus as-path is received the BGP session resets, even if the route is never actually installed (and as far as I can tell the only real effect of the "bgp maxas-limit 75" is to cause all paths with more than 75 ASN to not be installed in the routing table).
Re: anyone else seeing very long AS paths?
On Tue Feb 17, 2009, Mike Lewinski wrote: > bgp max-as will NOT protect you from this exploit (but if you are not > vulnerable it should prevent you from propogating it). Are you trying to say that the receiving bgp speaker will drop the session no matter what but it won't forward the update? Here is what I have found on Cisco's website bgp maxas-limit To configure Border Gateway Protocol (BGP) to discard routes that have a number of as-path segments that exceed the specified value, use the bgp maxas-limit command in router configuration mode. To return the router to default operation, use the no form of this command. Usage Guidelines The bgp maxas-limit command is used to limit the number of as-path segments that are permitted in inbound routes. If a route is received with an as-path segment that exceeds the configured limit, the BGP routing process will discard the route. I heard about people running this command that were not impacted > > As far as I can tell the ONLY defense for a vulnerable IOS is to not run > BGP. Dropping every received route with a filter on 0/0 does not mitigate > the attack - as soon as that bogus as-path is received the BGP session > resets, even if the route is never actually installed (and as far as I can > tell the only real effect of the "bgp maxas-limit 75" is to cause all paths > with more than 75 ASN to not be installed in the routing table). > pgphPXgUDIi6Q.pgp Description: PGP signature
Re: anyone else seeing very long AS paths?
German Martinez wrote: On Tue Feb 17, 2009, Mike Lewinski wrote: bgp max-as will NOT protect you from this exploit (but if you are not vulnerable it should prevent you from propogating it). Are you trying to say that the receiving bgp speaker will drop the session no matter what but it won't forward the update? There are reports that some versions of IOS will drop a peer upon receiving the long AS, even with a bgp max-as command. I can only presume that there are some IOS versions that determine the update is invalid prior to the max-as command determining we are not keeping the route. The whole "is the update valid?" vs "do I want this in my routing table?" Jack
RE: anyone else seeing very long AS paths?
According to publicly available bug toolkit, CSCee30718 did not touch the maxas limit. The hard-coded maxas-limit in recent IOS releases is 254 (not 75 as suggested in a previous e-mail). Classic IOS (I did not test XE, XR or NX) can handle inbound updates with AS path lengths above 255, but fails miserably when it has to send an oversized update (producing invalid BGP UPDATE message), resulting in a flapping BGP session (anyone who wants to test this behavior and report/fix this bug can get all the files needed to reproduce it). The hard-coded maxas-limit prevents this behavior (254 + my AS = 255), but if you use AS-path prepending on outbound update, you're fried. The __ONLY__ way to be on the safe side is to configure "bgp maxas-limit", otherwise someone who knows you're doing AS-path prepending on major peering sessions (and no inbound AS-path filtering) can selectively target your peering points. I've summarized everything I've discovered in various stress tests today (well, not the targeted attack :) in this article: http://wiki.nil.com/Limit_the_maximum_BGP_AS-path_length Feel free to improve it:) Ivan http://blog.ioshints.info > -Original Message- > From: German Martinez [mailto:gmart...@ajax.opentransit.net] > Sent: Tuesday, February 17, 2009 7:55 PM > To: Michael Ulitskiy > Cc: nanog@nanog.org > Subject: Re: anyone else seeing very long AS paths? > > On Tue Feb 17, 2009, Michael Ulitskiy wrote: > > Hello, > CSCee30718 - it removes the default value of bgp max-as from the > router. > > The solution is introduced in CSCeh13489 > > BGP shouldn't propogate an update w excessive AS Path > 255 > Symptoms: A router may reset its Border Gateway Protocol > (BGP) session. > > Conditions: This symptom is observed when a Cisco router that peers > with other routers receives an Autonomous System (AS) path with a > length that is equal to or greater than 255. > > Workaround: Configure the bgp maxas limit command in such as way that > the maximum length of the AS path is a value below 255. When the > router receives an update with an excessive AS path value, the prefix > is rejected and recorded the event in the log. > > This workaround has been suggested previously by Hank. > > Anyone knows about any possible CPU impacts in case that you implement > bgp maxas? > > Thanks > German > > > My bgp speaking devices are a couple of 7200s running 12.2(40). > > Not the newest IOS out there, but it's been doing the job > just fine up until yesterday. > > Yesterday, when that malformed announcement hit my routers > they didn't > > crash, but they did reset bgp sessions (even though I didn't accept > > the route) and they kept doing so until I got my upstream > to filter it out. > > According to cisco bug toolkit CSCdr54230 should be fixed > in 12.2, so obviously it's not enough. > > Does anybody know what IOS version has fix this problem, > 'cause I couldn't find this info at CCO? > > Thanks, > > > > Michael > > > > On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote: > > > Jared Mauch wrote: > > > > > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > > > > > > >>"They" will keep trying and until a vast majority of ISPs > > > >>implement maxas, this will keep happening. > > > > > > > Or until people who are still running > multi-year old cisco code > > > > actually upgrade? This seems to primarily impact: > > > > > > > > 1) Old cisco code > > > > 2) PC based bgp daemons > > > > > > > Both of which likely just need to be upgraded. I > actually suspect > > > > that a lot of people who dropped their bgp sessions did > not notice > > > > something happened, and still will not upgrade their codeI > > > > suspect these people don't even know they have a bgp speaking > > > > device anymore. > > > > > > On the other hand, the fact that various entities have > gone out of > > > their way to advertise that they're running old > hardware/out-of-date > > > software has been noted elsewhere. I'd strongly suggest, > if you're reading NANOG, > > > that you update, before someone less pleasant and friendly than > > > myself finds you. Please. > > > > > > > >
RE: IPv6 Confusion
While people frequently claim that auto-config is optional, there are implementations (including OS-X) that don't support anything else at this point. The basic message is that you should not assume that the host implementations will conform to what the network operator would prefer, and you need to test. One last comment (because I hear "just more bits" a lot in the *nog community)... Approach IPv6 as a new and different protocol. If you approach it as "IPv4 with more bits", you will trip over the differences and be pissed off. If you approach it as a "different protocol with a name that starts with IP" and runs alongside IPv4 (like we used to do with decnet, sna, appletalk...), you will be comforted in all the similarities. You will also hear lots of noise about 'lack of compatibility', which is just another instance of refusing to recognize that this is really a different protocol. At the end of the day, it is a packet based protocol that moves payloads around. Tony > -Original Message- > From: Carl Rosevear [mailto:carl.rosev...@demandmedia.com] > Sent: Tuesday, February 17, 2009 10:58 AM > To: Owen DeLong > Cc: nanog@nanog.org > Subject: RE: IPv6 Confusion > > Thanks to all that responded on and off-list. My confusion is mostly > cleared-up. The points that are unclear at this point are generally > unclear to most people, it seems due to lack of operational experience > with IPv6. Feel free to keep responding to this topic as its all very > interesting but I think my needs have been met. Owen, this one from > you tied it all together. Thanks all! > > > > --Carl > > > > > -Original Message- > From: Owen DeLong [mailto:o...@delong.com] > Sent: Tuesday, February 17, 2009 10:41 AM > To: Carl Rosevear > Cc: nanog@nanog.org > Subject: Re: IPv6 Confusion > > > On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: > > > So, I understand the main concepts behind IPv6. Most of my peers > > understand. We all have a detailed understanding of most things > > IPv4. I have Googled and read RFCs about IPv6 for HOURS. That > > said, to quickly try to minimize people thinking I am an idiot who > > asks before he reads, I need some answers. First of all, several of > > my friends who feel they are rather authoritative on the subject of > > things network-related have given me conflicting answers. So what's > > the question? ... > > > > How does IPv6 addressing work? > > > There are a lot of different possible answers to that question, many > of which are accurate. > > In general: > > It's a 128 bit address. Routing is done on VLSM, but, generally for > DNS purposes, these > are expected to be at least on nibble boundaries. > > There is an intent to support what is known as EUI-64, which means > every subnet should > be a /64, however, there are people who number smaller subnets and > that is supposed > to work, but, it will break certain IPv6 things like stateless > autoconfiguration (which is > optional). > > > I know it's been hashed and rehashed but several orgs I am > > associated with are about to ask for their allocations from ARIN and > > we are all realizing we don't really know how the network / subnet > > structure trickles down from the edge to the host. We really don't > > have a firm grasp of all of this as there seems to be multiple > > options regarding how many addresses should be assigned to a host, > > if the MAC address should be included in the address or if that is > > just for auto-configuration purposes or what the heck the deal is. > > There are a lot of clear statements out there and a lot that are > > clear as mud. Unfortunately, even when trying to analyze which RFC > > superseded another. Can I just subnet it all like IPv4 but with > > room to grow or is each host really going to need its own /84 or > > something? I can't see why hosts would need any more addresses than > > today but maybe I'm missing something because a lot of addressing > > models sure allow for a huge number of unique addresses per host. > > > You can subnet it just like IPv4. Each host does not need it's own > subnet (/64, not /84 for the most part). > The theory behind /64 subnets was to support a way for a host to use > what it already knows (MAC > address) and possibly some additional clues (Router Announcement) from > the wire to configure > its own IPv6 address on an interface. Whether or not this was a good > idea is still controversial, but, > whether or not it's how IPv6 is going to work is not. IPv6 is > designed to work with Stateless > Autoconfiguration whether we like it or not. DHCPv6 so far is > prevented from providing > default router information (or many of the other things you're used to > having DHCP do) > as it currently stands. > > > > > My buddy and I are about to go to Barnes and Noble, not having and > > luck with standard internet media but then we realized... how will > > we know if any of that is really what we are looking for either? > > >
Re: anyone else seeing very long AS paths?
Ivan Pepelnjak wrote: Classic IOS (I did not test XE, XR or NX) can handle inbound updates with AS path lengths above 255, but fails miserably when it has to send an oversized update (producing invalid BGP UPDATE message), resulting in a flapping BGP session (anyone who wants to test this behavior and report/fix this bug can get all the files needed to reproduce it). Just to reconfirm. The issue arrives with sending an update, not receiving? So if an ISP does not have a limit and their IOS cannot handle this, they will send an invalid BGP UPDATE to the downstream peers causing them to reset regardless of their max as-path settings? Just trying to reconfirm, so I can inform my customers if there was anything they could do to prevent it, or if it is actually their provider that instigated the peer reset by sending invalid updates. -Jack
Re: anyone else seeing very long AS paths?
Jack Bates wrote: Just to reconfirm. The issue arrives with sending an update, not receiving? So if an ISP does not have a limit and their IOS cannot handle this, they will send an invalid BGP UPDATE to the downstream peers causing them to reset regardless of their max as-path settings? Just trying to reconfirm, so I can inform my customers if there was anything they could do to prevent it, or if it is actually their provider that instigated the peer reset by sending invalid updates. We were dropping ALL prefixes and the eBGP session was still resetting. I used this filter: ip prefix-list drop seq 1 deny 0.0.0.0/0 ge 32 router bgp neighbor x.x.x.x prefix-list drop in I confirmed via "show ip bgp sum" that there were 0 prefixes received. Of course "show ip bgp nei x.x.x.x received-routes" still showed the routes coming in, they just weren't being installed into the tables (or redistributed to any iBGP neighbors). So, to reiterate: 1) "bgp maxas-limit 75" had no effect mitigating this problem on the IOS we were using. That is: it was previously verified to be working just fine to drop paths longer than 75, but once we started receiving paths > 255 then BGP started resetting. 2) "prefix-list drop in" ensured that ALL eBGP learned routes were dropped before being installed or re-advertised. eBGP still reset itself every three minutes or so, which was about the length of time it took for the session to restore itself and get to the offending route. I believe that upgraded IOS is the ONLY possibly fix in some cases.
RE: anyone else seeing very long AS paths?
As far as I understand the issues :) There are two limits: the first one @ 128 AS numbers (where BGP switches to the 'extended length' of BGP attribute), the other one @ 256 AS numbers (where BGP has to use two AS_SEQUENCE segments). Old IOS releases break on the first boundary when processing INBOUND update. bgp maxas-limit cannot save you, as the router drops UPSTREAM BGP session before the update is fully processed. New IOS releases accept all INBOUND updates. Prefixes with AS-path length above 254 are never valid (the long printout contains maxas-limit status). bgp maxas-limit works on inbound updates and thus drops whatever you feel is oversized. New IOS release fail when sending OUTBOUND updates. If you've configured bgp maxas-limit, you're safe. If not, your DOWNSTREAM BGP session will be dropped by your neighbor receiving invalid BGP update. If your customers are using old IOS, there was nothing they could do to prevent the BGP session reset (apart from upgrading, obviously :). Who was the actual culprit depends on the AS-path length ... See above. Does this make sense? I know it's complex :) Ivan > -Original Message- > From: Jack Bates [mailto:jba...@brightok.net] > Sent: Tuesday, February 17, 2009 8:31 PM > To: Ivan Pepelnjak > Cc: nanog@nanog.org > Subject: Re: anyone else seeing very long AS paths? > > Ivan Pepelnjak wrote: > > Classic IOS (I did not test XE, XR or NX) can handle > inbound updates > > with AS path lengths above 255, but fails miserably when it has to > > send an oversized update (producing invalid BGP UPDATE message), > > resulting in a flapping BGP session (anyone who wants to test this > > behavior and report/fix this bug can get all the files > needed to reproduce it). > > Just to reconfirm. The issue arrives with sending an update, > not receiving? So if an ISP does not have a limit and their > IOS cannot handle this, they will send an invalid BGP UPDATE > to the downstream peers causing them to reset regardless of > their max as-path settings? > > Just trying to reconfirm, so I can inform my customers if > there was anything they could do to prevent it, or if it is > actually their provider that instigated the peer reset by > sending invalid updates. > > -Jack > >
Re: IPv6 Confusion
On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: While people frequently claim that auto-config is optional, there are implementations (including OS-X) that don't support anything else at this point. The basic message is that you should not assume that the host implementations will conform to what the network operator would prefer, and you need to test. I can configure OS-X statically, so, that simply isn't true. What is true is that there are many implementations which do not (yet) support DHCPv6. That is not the same as "don't support anything else". One last comment (because I hear "just more bits" a lot in the *nog community)... Approach IPv6 as a new and different protocol. If you approach it as "IPv4 with more bits", you will trip over the differences and be pissed off. If you approach it as a "different protocol with a name that starts with IP" and runs alongside IPv4 (like we used to do with decnet, sna, appletalk...), you will be comforted in all the similarities. You will also hear lots of noise about 'lack of compatibility', which is just another instance of refusing to recognize that this is really a different protocol. At the end of the day, it is a packet based protocol that moves payloads around. The problem here, IMHO, stems from the fact that unlike DECnet, Appletalk, SNA, et. al., IPv6 is intended as a replacement for IPv4. (None of the other protocols was ever intended to replace any of the others). As a replacement, the IETF realized that at the current scale of the internet when they began designing IPv6, a flag day conversion (like what happened when we went to IPv4) was not possible. Unfortunately, the migration plan set forth by the IETF made many assumptions (especially on vendor preparedness and rate of adoption prior to IPv4 runout) that have not proven out, so, the "Everyone who has IPv4 starts running dual-stack before we need any IPv6 only connectivity" plan is not going to prove out. More unfortunately, there is no real contingency plan for how migration happens absent that scenario and we are, therefore, in for some interesting times ahead. Owen
RE: anyone else seeing very long AS paths?
> We were dropping ALL prefixes and the eBGP session was still > resetting. Upstream or downstream? > 1) "bgp maxas-limit 75" had no effect mitigating this problem > on the IOS we were using. That is: it was previously verified > to be working just fine to drop paths longer than 75, but > once we started receiving paths > > 255 then BGP started resetting. I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The paths were generated by Quagga BGP daemon. 12.2SRC causes the downstream session to break when the installed AS-path length is close to 255 and you use downstream AS-path prepending. In your case, I'm assuming you were hit with an older bug (probably at the 128 AS-path length boundary). It would be very hard to generate just the right AS-path length to unintentionally break your upstream EBGP session (as I said before, it's a nice targeted attack if you know your downstream topology). If your IOS is vulnerable to the older bugs that break inbound processing of AS paths longer than 128, there's nothing you can do on your end. The internal BGP checks reject the inbound update before the inbound filters (or bgp maxas-limit) can touch it and reset the upstream BGP session. Hope this helps Ivan Disclaimer: as I don't have internal access to Cisco, all of the above is a result of lab tests.
Re: anyone else seeing very long AS paths?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 17, 2009, at 1:50 PM, Ivan Pepelnjak wrote: As far as I understand the issues :) There are two limits: the first one @ 128 AS numbers (where BGP switches to the 'extended length' of BGP attribute), the other one @ 256 AS numbers (where BGP has to use two AS_SEQUENCE segments). Old IOS releases break on the first boundary when processing INBOUND update. bgp maxas-limit cannot save you, as the router drops UPSTREAM BGP session before the update is fully processed. New IOS releases accept all INBOUND updates. Prefixes with AS-path length above 254 are never valid (the long printout contains maxas-limit status). bgp maxas-limit works on inbound updates and thus drops whatever you feel is oversized. New IOS release fail when sending OUTBOUND updates. If you've configured bgp maxas-limit, you're safe. If not, your DOWNSTREAM BGP session will be dropped by your neighbor receiving invalid BGP update. If your customers are using old IOS, there was nothing they could do to prevent the BGP session reset (apart from upgrading, obviously :). Who was the actual culprit depends on the AS-path length ... See above. Does this make sense? I know it's complex :) Ivan What is not yet clear is, what are the definitions of "Old IOS release" and "New IOS release"? There has been talk of a bug referred to as CSCdr54230. I have seen statements on another list that this was fixed in 12.1(4) and 12.0(10)S3, but yet this problem was experienced on such releases as 12.2(40). Has there been any definitive word yet on what it takes to qualify as a new IOS release? Steve - -- - --- Steven Saner Director of Network Operations Hubris Communications -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmbGI8ACgkQvgCxUpg3pZOfgQCeOCnoDIwX/IMF+wfnM8md2SiM LSEAoIptOHmO7yPhAGdVZ8+dlhCiOI8k =WD0q -END PGP SIGNATURE-
Re: anyone else seeing very long AS paths?
On Tue Feb 17, 2009, Ivan Pepelnjak wrote: > According to publicly available bug toolkit, CSCee30718 did not touch the > maxas limit. I will double check this with Cisco pgpeuQs06hcKd.pgp Description: PGP signature
Re: anyone else seeing very long AS paths?
Ivan, It is confusing but from what I have tested you have it correct. The confusing part comes from multiple issues. a) The documentation about the default maxas limit being 75 appears to be incorrect. I'll get that fixed. b) Prior to CSCee30718 there was a hard limit of 255. After that fix AS sets of more than 255 should work. c) CSCeh13489 implemented the maxas command to mark it as invalid and not send. There does appear to be an issue when you cross the 255 boundary and the next hop router sends a notification back. I've got it recreated in the lab and we are working to clearly understand why that is. I'll post an update once we have more. The way to prevent it is the upstream device that crosses the 255 boundary on sending needs to use the maxas limit command to keep it less than 255. It doesn't work on the device that receives the update with the AS path larger than 255. Rodney On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > We were dropping ALL prefixes and the eBGP session was still > > resetting. > > Upstream or downstream? > > > 1) "bgp maxas-limit 75" had no effect mitigating this problem > > on the IOS we were using. That is: it was previously verified > > to be working just fine to drop paths longer than 75, but > > once we started receiving paths > > > 255 then BGP started resetting. > > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The > paths were generated by Quagga BGP daemon. > > 12.2SRC causes the downstream session to break when the installed AS-path > length is close to 255 and you use downstream AS-path prepending. > > In your case, I'm assuming you were hit with an older bug (probably at the > 128 AS-path length boundary). It would be very hard to generate just the > right AS-path length to unintentionally break your upstream EBGP session (as > I said before, it's a nice targeted attack if you know your downstream > topology). > > If your IOS is vulnerable to the older bugs that break inbound processing of > AS paths longer than 128, there's nothing you can do on your end. The > internal BGP checks reject the inbound update before the inbound filters (or > bgp maxas-limit) can touch it and reset the upstream BGP session. > > Hope this helps > Ivan > > Disclaimer: as I don't have internal access to Cisco, all of the above is a > result of lab tests. >
Re: IPv6 Confusion
On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: Approach IPv6 as a new and different protocol. Unfortunately, I gather this isn't what end users or network operators want or expect. I suspect if we want to make real inroads towards IPv6 deployment, we'll need to spend a bit more time making IPv6 look, taste, and feel like IPv4 and less time berating folks for "IPv4- think" (not that you do this, but others here do). For example, getting over the stateless autoconfig religion (which was never fully thought out -- how does a autoconfig'd device get a DNS name associated with their address in a DNSSEC-signed world again?) and letting network operators use DHCP with IPv6 the way they do with IPv4. Or, we simply continue down the path of more NATv4. Regards, -drc
Re: IPv6 Confusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Feb 17, 2009 at 12:20 PM, David Conrad wrote: > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: >> >> Approach IPv6 as a new and different protocol. > > Unfortunately, I gather this isn't what end users or network operators > want or expect. I suspect if we want to make real inroads towards IPv6 > deployment, we'll need to spend a bit more time making IPv6 look, taste, > and feel like IPv4 and less time berating folks for "IPv4-think" (not > that you do this, but others here do). For example, getting over the > stateless > autoconfig religion (which was never fully thought out -- how does a > autoconfig'd device get a DNS name associated with their address in a > DNSSEC-signed world again?) and letting network operators use DHCP with > IPv6 the way they do with IPv4. > > Or, we simply continue down the path of more NATv4. > Isn't that the basis for the "Principle of Least Astonishment"? ;-) http://en.wikipedia.org/wiki/Principle_of_least_astonishment - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJmxzsq1pz9mNUZTMRAkNLAKDHw0tWUOKjnCOqcInCp5h+L1yG2gCg+TZ1 OC+4/th4rmLSMzpV1138rrk= =pKl5 -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: IPv6 Confusion
Hi, On Tue, 17 Feb 2009 11:48:49 -0800 Owen DeLong wrote: > > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > > While people frequently claim that auto-config is optional, there are > > implementations (including OS-X) that don't support anything else at > > this > > point. The basic message is that you should not assume that the host > > implementations will conform to what the network operator would > > prefer, and > > you need to test. > > I can configure OS-X statically, so, that simply isn't true. > > What is true is that there are many implementations which do not (yet) > support DHCPv6. That is not the same as "don't support anything > else". > Here are a couple of implementations of DHCPv6, including one that also works under Windows. I played with one of them on my Linux boxes a while back (I can't remember exactly which one), and it just worked: https://fedorahosted.org/dhcpv6/ http://klub.com.pl/dhcpv6/ Regards, Mark.
Re: IPv6 Confusion
On 18/02/2009, at 9:32 AM, Mark Smith wrote: Here are a couple of implementations of DHCPv6, including one that also works under Windows. I played with one of them on my Linux boxes a while back (I can't remember exactly which one), and it just worked: https://fedorahosted.org/dhcpv6/ http://klub.com.pl/dhcpv6/ Installable implementations don't really count if this is something my mother has to use. Perhaps an ISP gives customers a little "enabler" app to run that installs a DHCPv6 client, but that sounds nasty. Flashbacks to AOL/compuserve install disks. SLAAC works out of the box right now for dual-stack hosts (ie. they can get DNS resolvers on v4). That is fine for the mean time, if you are planning to go IPv6-only to end hosts then things are going to get hard, stick with IPv4 NAT for now until OS X gets DHCPv6, and people have moved off XP and older OS X boxes. ...or, until we have another way of getting resolvers that has widespread adoption.. -- Nathan Ward
RE: IPv6 Confusion
>do this, but others here do). For example, getting over the stateless >autoconfig religion (which was never fully thought out -- how does a >autoconfig'd device get a DNS name associated with their address in a DNSSEC- >signed world again?) and letting network operators use DHCP with IPv6 the way >they do with IPv4. While I wouldn't call SLAAC a religion, I will say (again) that it works in many cases for some people, today - and whether you consider SLAAC "half-baked" or "slim-by-design" is a subjective matter. In the meantime, I am also a proponent for letting ops use DHCPv6 ... especially DHCPv6-PD!
Re: IPv6 Confusion
On Tue, 17 Feb 2009 12:24:26 -0800 Paul Ferguson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tue, Feb 17, 2009 at 12:20 PM, David Conrad wrote: > > > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > >> > >> Approach IPv6 as a new and different protocol. > > > > Unfortunately, I gather this isn't what end users or network operators > > want or expect. I suspect if we want to make real inroads towards IPv6 > > deployment, we'll need to spend a bit more time making IPv6 look, taste, > > and feel like IPv4 and less time berating folks for "IPv4-think" (not > > that you do this, but others here do). For example, getting over the > > stateless > > autoconfig religion (which was never fully thought out -- how does a > > autoconfig'd device get a DNS name associated with their address in a > > DNSSEC-signed world again?) and letting network operators use DHCP with > > IPv6 the way they do with IPv4. > > > > Or, we simply continue down the path of more NATv4. > > > > Isn't that the basis for the "Principle of Least Astonishment"? ;-) > > http://en.wikipedia.org/wiki/Principle_of_least_astonishment > Alternatively, you can say, "if we're going to put effort into making these one or two changes (e.g. making IPv4 addresses bigger), is there an opportunity to make other improvements." Change always has a cost, so I think maximising the benefits from that cost, by considering additional changes at the same time, is of value. Some might say this is "second system syndrome." I think that only qualifies if you aren't ruthless in deciding which additional changes you make verses their additional costs vs benefits. The Internet's success isn't really attributable to IPv4, much like a road's success isn't really attributable to whether it is made of bitumen or concrete. The Internet's success is attributable to whom and to what it has and does provide connectivity to. IPv4 has been a good material to build the Internet from over the last 20 to 30 years, but there are limitations with it, and some other improvements, such as node autoconfiguration, proven useful in protocols mostly designed since IPv4 was, such as XNS, IPX, Appletalk and DECNET, can't be accomodated in it. I think IPv6 is similar enought to IPv4 that what you know about IPv4 can help you learn IPv6, but different enough that you shoudln't just consider IPv6 to be IPv4 with bigger addresses. Some principles and models are the same, some are similar, some are different. Anyway, that's the way I think about IPv6 vs IPv4. Regards, Mark.
Re: anyone else seeing very long AS paths?
Steven Saner wrote: What is not yet clear is, what are the definitions of "Old IOS release" and "New IOS release"? There has been talk of a bug referred to as CSCdr54230. I have seen statements on another list that this was fixed in 12.1(4) and 12.0(10)S3, but yet this problem was experienced on such releases as 12.2(40). Has there been any definitive word yet on what it takes to qualify as a new IOS release? I believe we are looking at multiple bugs with similar effects at different boundaries. Cisco, per earlier in the thread, will be having lots of coffee tonight. :) Jack
Re: IPv6 Confusion
> From: Owen DeLong > Date: Tue, 17 Feb 2009 11:48:49 -0800 > > > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > > While people frequently claim that auto-config is optional, there are > > implementations (including OS-X) that don't support anything else at > > this > > point. The basic message is that you should not assume that the host > > implementations will conform to what the network operator would > > prefer, and > > you need to test. > > I can configure OS-X statically, so, that simply isn't true. > > What is true is that there are many implementations which do not (yet) > support DHCPv6. That is not the same as "don't support anything > else". > > > > > > > > > One last comment (because I hear "just more bits" a lot in the *nog > > community)... Approach IPv6 as a new and different protocol. If you > > approach > > it as "IPv4 with more bits", you will trip over the differences and be > > pissed off. If you approach it as a "different protocol with a name > > that > > starts with IP" and runs alongside IPv4 (like we used to do with > > decnet, > > sna, appletalk...), you will be comforted in all the similarities. > > You will > > also hear lots of noise about 'lack of compatibility', which is just > > another > > instance of refusing to recognize that this is really a different > > protocol. > > At the end of the day, it is a packet based protocol that moves > > payloads > > around. > > > The problem here, IMHO, stems from the fact that unlike DECnet, > Appletalk, SNA, et. al., IPv6 is intended as a replacement for > IPv4. (None of the other protocols was ever intended to replace > any of the others). > > As a replacement, the IETF realized that at the current scale of the > internet when they began designing IPv6, a flag day conversion > (like what happened when we went to IPv4) was not possible. > Unfortunately, the migration plan set forth by the IETF made many > assumptions (especially on vendor preparedness and rate of > adoption prior to IPv4 runout) that have not proven out, so, the > "Everyone who has IPv4 starts running dual-stack before we > need any IPv6 only connectivity" plan is not going to prove out. > > More unfortunately, there is no real contingency plan for how > migration happens absent that scenario and we are, therefore, > in for some interesting times ahead. While this is very true, at least the IETF has recognized the problem and the BEHAVE WG is trying to come up with some way of getting out of the trap we have worked our way into. The big iron folks are proposing something called "Carrier Grade NAT". This one REALLY frightens me, but I understand a couple of hardware manufacturers are planning on building such a monster. It might actually work, but the amount of state carried strikes me as in invitation to disaster. There was a draft on CNG, but it expired last month. A copy is still available at: http://smakd.potaroo.net/ietf/all-ids/draft-nishitani-cgn-00.txt Also, a proposal for a different approach is at: http://mice.cs.columbia.edu/getTechreport.php?techreportID=560 (PDF) If you are really concerned about where we go whan v4 address space is exhausted, I strongly urge you to look at all of these issues. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: IPv6 Confusion
On 18/02/2009, at 8:28 AM, Tony Hain wrote: One last comment (because I hear "just more bits" a lot in the *nog community)... Approach IPv6 as a new and different protocol. If you approach it as "IPv4 with more bits", you will trip over the differences and be pissed off. If you approach it as a "different protocol with a name that starts with IP" and runs alongside IPv4 (like we used to do with decnet, sna, appletalk...), you will be comforted in all the similarities. You will also hear lots of noise about 'lack of compatibility', which is just another instance of refusing to recognize that this is really a different protocol. At the end of the day, it is a packet based protocol that moves payloads around. Having taught a bunch of IPv6 courses opening with a photo of Gaurab and his "96 more bits, no magic" tshirt and then having dealt with the confusion once we get in to the nitty gritty details, I am inclined to agree with you here. The intention of these sorts of statements is to remove the "I will have to learn IP all over again" fear (and the associated "it's too hard" etc.), but you are right, this has been causing people to get a bit surprised when stuff does not work the same as IPv4. I suppose it is fair to say that in the core of the network, it is essentially 96 more bits, and no magic. The access network is where this becomes a bit of a confusing statement. Anyway, comments taken on board, I'll have a think about how to do this differently. -- Nathan Ward
Re: IPv6 Confusion
On Tue, Feb 17, 2009 at 11:28:11AM -0800, Tony Hain wrote: [snip] > starts with IP" and runs alongside IPv4 (like we used to do with decnet, > sna, appletalk...), you will be comforted in all the similarities. You will This is highly amusing, as for myself and many folks the experience of these 'other protocols', when trying to run in open, scalable, and commercially-viable deployments, was to encapsulate in IP(v4) at the LAN/WAN boundary. It is no wonder that is the natural reaction to IPv6 by those who have survived and been successful with such operational simplicity. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: anyone else seeing very long AS paths?
On Tue, 17 Feb 2009, Mike Lewinski wrote: > German Martinez wrote: > bgp max-as will NOT protect you from this exploit (but if you are not > vulnerable it should prevent you from propogating it). > I can confirm this statement... (unfortunately) L.
RE: IPv6 Confusion
Owen DeLong wrote: > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > > While people frequently claim that auto-config is optional, there are > > implementations (including OS-X) that don't support anything else at > > this > > point. The basic message is that you should not assume that the host > > implementations will conform to what the network operator would > > prefer, and > > you need to test. > > I can configure OS-X statically, so, that simply isn't true. > > What is true is that there are many implementations which do not (yet) > support DHCPv6. That is not the same as "don't support anything > else". Fair enough about OS-X, but that is not the only non-dhcpv6 implementation out there. How exactly do you configure a static address on a sensor with no UI? My point was 'don't assume', & test. > > > > > > > > > One last comment (because I hear "just more bits" a lot in the *nog > > community)... Approach IPv6 as a new and different protocol. If you > > approach > > it as "IPv4 with more bits", you will trip over the differences and > be > > pissed off. If you approach it as a "different protocol with a name > > that > > starts with IP" and runs alongside IPv4 (like we used to do with > > decnet, > > sna, appletalk...), you will be comforted in all the similarities. > > You will > > also hear lots of noise about 'lack of compatibility', which is just > > another > > instance of refusing to recognize that this is really a different > > protocol. > > At the end of the day, it is a packet based protocol that moves > > payloads > > around. > > > The problem here, IMHO, stems from the fact that unlike DECnet, > Appletalk, SNA, et. al., IPv6 is intended as a replacement for > IPv4. (None of the other protocols was ever intended to replace > any of the others). > > As a replacement, the IETF realized that at the current scale of the > internet when they began designing IPv6, a flag day conversion > (like what happened when we went to IPv4) was not possible. > Unfortunately, the migration plan set forth by the IETF made many > assumptions (especially on vendor preparedness and rate of > adoption prior to IPv4 runout) that have not proven out, so, the > "Everyone who has IPv4 starts running dual-stack before we > need any IPv6 only connectivity" plan is not going to prove out. > > More unfortunately, there is no real contingency plan for how > migration happens absent that scenario and we are, therefore, > in for some interesting times ahead. Whine, whine, whine... we are where we are, and no amount of whining will change the fact that people outside of Japan chose not to think ahead. The primary point of dual-stack was to decouple the requirement for the end systems to change all the apps at once. Most of the *nog community doesn't get, or care to get, the costs of the end system operations staff because they are focused on the costs related to moving the bits around. There are tunneling functions defined, so you don't have to get 'dual-stack everywhere' before you can take another step. Those are not as 'efficient' as dual-stack when moving the bits around, and require operational management, but that is a cost trade-off that can be made. People that insist on delivering only one version will force unnatural acts at the edge, while delivering both will allow people to move at their own pace. Like it or not, the end systems are moving without the *nog community. Fire up uTorrent and see how many 6to4 & teredo connected peers you end up with (I am generally seeing about 1/4-1/3 of the set). This is 'real dual-stack at the edge', and works around the laggard ISP deployments. The Internet was built by tunneling over the laggard telco's using the voice technology available, and the next generation of it will be built the same way if the *nog community buries its head in the same dark place that the telco's did. Tony
RE: IPv6 Confusion
David Conrad wrote: > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > Approach IPv6 as a new and different protocol. > > Unfortunately, I gather this isn't what end users or network operators > want or expect. I suspect if we want to make real inroads towards > IPv6 deployment, we'll need to spend a bit more time making IPv6 look, > taste, and feel like IPv4 and less time berating folks for "IPv4- > think" (not that you do this, but others here do). I am not trying to berate anyone, just point out that your starting perspective will impact how you see the differences. From what I have seen, people are generally happy when they find similarities, and pissed off when the find differences. Therefore, if you start by assuming it is different, you will be much happier. > For example, > getting over the stateless autoconfig religion (which was never fully > thought out -- how does a autoconfig'd device get a DNS name > associated with their address in a DNSSEC-signed world again?) and > letting network operators use DHCP with IPv6 the way they do with IPv4. There are many religious positions here, and none are any more valid than the others. At the end of the day, each approach needs to be complete and stand-alone, but due to religious fighting, all approaches are required to exist at once for anything to work. This being a list of network engineers, there is a strong bias toward tools that allow explicit management of the network. This is a fine position, and those tools need to exist. There are others that don't want, or need to know about every bit on the wire, where 'as much automation as possible' is the right set of tools. Infighting at the IETF kept the RA from informing the end systems about DNS, and kept DHCPv6 from informing them about their router. The result is that you have to do both DHCP & RA, when each should be capable of working without the other. As far as dnssec, while the question is valid, blaming the IPv6 design for not considering something that 10+ years later is still not deployed/deployable, is a bit of a stretch. This all comes down to trust anchors, and personally I question the wisdom of anyone that considers DHCP to be a valid trust anchor. It gets that status because it is something tangible that is reasonably well understood, but there is nothing in its design, or the way that it is deployed in practice that makes it worthy of anything related to trust. An out-of-band trust cert between an auto-configured end system and a ddns service makes much more sense than a DHCP service based on believing that the end system will not bother to spoof its mac address. > > Or, we simply continue down the path of more NATv4. While this is the popular position, those that have thought about it realize that what works for natv4 at the edge, does not work when that nat is moved toward the core. If people really go down this path, the end applications will do even more levels of tunneling over the few things that work, and the network operators will lose all visibility into what is really going on (IPv6 tunnel servers are just the modern modem pools, and tunneling over http will become more common if that is the only path that works). Tony
Re: anyone else seeing very long AS paths?
On Tue Feb 17, 2009, Rodney Dunn wrote: Hello Rodney, It will be great if you can share with us your findings. It seems like we are hitting different bugs in different platforms. Thanks German > Ivan, > > It is confusing but from what I have tested you have it correct. > > The confusing part comes from multiple issues. > > a) The documentation about the default maxas limit being 75 appears to be >incorrect. I'll get that fixed. > > b) Prior to CSCee30718 there was a hard limit of 255. After that fix >AS sets of more than 255 should work. > > c) CSCeh13489 implemented the maxas command to mark it as invalid and >not send. > > > There does appear to be an issue when you cross the 255 boundary > and the next hop router sends a notification back. > > I've got it recreated in the lab and we are working to clearly understand > why that is. I'll post an update once we have more. > > The way to prevent it is the upstream device that crosses the 255 boundary > on sending needs to use the maxas limit command to keep it less than 255. > > It doesn't work on the device that receives the update with the AS path > larger than 255. > > Rodney > > On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > > We were dropping ALL prefixes and the eBGP session was still > > > resetting. > > > > Upstream or downstream? > > > > > 1) "bgp maxas-limit 75" had no effect mitigating this problem > > > on the IOS we were using. That is: it was previously verified > > > to be working just fine to drop paths longer than 75, but > > > once we started receiving paths > > > > 255 then BGP started resetting. > > > > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The > > paths were generated by Quagga BGP daemon. > > > > 12.2SRC causes the downstream session to break when the installed AS-path > > length is close to 255 and you use downstream AS-path prepending. > > > > In your case, I'm assuming you were hit with an older bug (probably at the > > 128 AS-path length boundary). It would be very hard to generate just the > > right AS-path length to unintentionally break your upstream EBGP session (as > > I said before, it's a nice targeted attack if you know your downstream > > topology). > > > > If your IOS is vulnerable to the older bugs that break inbound processing of > > AS paths longer than 128, there's nothing you can do on your end. The > > internal BGP checks reject the inbound update before the inbound filters (or > > bgp maxas-limit) can touch it and reset the upstream BGP session. > > > > Hope this helps > > Ivan > > > > Disclaimer: as I don't have internal access to Cisco, all of the above is a > > result of lab tests. > > pgpKi14UX012c.pgp Description: PGP signature
Re: anyone else seeing very long AS paths?
If you want to take this offline send it unicast or we could move it to cisco-nsp. What scenarios are you seeing that appear broken other than when a notification is sent when a > 255 hop update is received? That's the one I'm working on right now. Rodney On Tue, Feb 17, 2009 at 05:31:49PM -0500, German Martinez wrote: > On Tue Feb 17, 2009, Rodney Dunn wrote: > > Hello Rodney, > It will be great if you can share with us your findings. It seems > like we are hitting different bugs in different platforms. > > Thanks > German > > > Ivan, > > > > It is confusing but from what I have tested you have it correct. > > > > The confusing part comes from multiple issues. > > > > a) The documentation about the default maxas limit being 75 appears to be > >incorrect. I'll get that fixed. > > > > b) Prior to CSCee30718 there was a hard limit of 255. After that fix > >AS sets of more than 255 should work. > > > > c) CSCeh13489 implemented the maxas command to mark it as invalid and > >not send. > > > > > > There does appear to be an issue when you cross the 255 boundary > > and the next hop router sends a notification back. > > > > I've got it recreated in the lab and we are working to clearly understand > > why that is. I'll post an update once we have more. > > > > The way to prevent it is the upstream device that crosses the 255 boundary > > on sending needs to use the maxas limit command to keep it less than 255. > > > > It doesn't work on the device that receives the update with the AS path > > larger than 255. > > > > Rodney > > > > On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > > > We were dropping ALL prefixes and the eBGP session was still > > > > resetting. > > > > > > Upstream or downstream? > > > > > > > 1) "bgp maxas-limit 75" had no effect mitigating this problem > > > > on the IOS we were using. That is: it was previously verified > > > > to be working just fine to drop paths longer than 75, but > > > > once we started receiving paths > > > > > 255 then BGP started resetting. > > > > > > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. > > > The > > > paths were generated by Quagga BGP daemon. > > > > > > 12.2SRC causes the downstream session to break when the installed AS-path > > > length is close to 255 and you use downstream AS-path prepending. > > > > > > In your case, I'm assuming you were hit with an older bug (probably at the > > > 128 AS-path length boundary). It would be very hard to generate just the > > > right AS-path length to unintentionally break your upstream EBGP session > > > (as > > > I said before, it's a nice targeted attack if you know your downstream > > > topology). > > > > > > If your IOS is vulnerable to the older bugs that break inbound processing > > > of > > > AS paths longer than 128, there's nothing you can do on your end. The > > > internal BGP checks reject the inbound update before the inbound filters > > > (or > > > bgp maxas-limit) can touch it and reset the upstream BGP session. > > > > > > Hope this helps > > > Ivan > > > > > > Disclaimer: as I don't have internal access to Cisco, all of the above is > > > a > > > result of lab tests. > > >
RE: IPv6 Confusion
Joe Provo wrote: > This is highly amusing, as for myself and many folks the experience > of these 'other protocols', when trying to run in open, scalable, > and commercially-viable deployments, was to encapsulate in IP(v4) > at the LAN/WAN boundary. It is no wonder that is the natural reaction > to IPv6 by those who have survived and been successful with such > operational simplicity. There is nothing preventing you from doing the same thing again, ... except oh yea, lack of addresses and the bloating routing table as ever smaller address blocks are traded on eBay. Seriously, you could easily do the same thing by encapsulating IPv4 over IPv6. One might even consider using one /64 for internal IPv4 routes (embedding the IPv4 as the next 32 bits), then another /64 for each IPv4 peer, to reduce the number of IPv6 routes you need to carry everywhere. At the edges where it matters there would be a /96 routing entry, but even if all of the /96 prefixes were enumerated everywhere the table would be the same size as the IPv4 one would have been. Tony
Re: IPv6 Confusion
In message , David Conrad writes: > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > Approach IPv6 as a new and different protocol. > > Unfortunately, I gather this isn't what end users or network operators > want or expect. I suspect if we want to make real inroads towards > IPv6 deployment, we'll need to spend a bit more time making IPv6 look, > taste, and feel like IPv4 and less time berating folks for "IPv4- > think" (not that you do this, but others here do). For example, > getting over the stateless autoconfig religion (which was never fully > thought out -- how does a autoconfig'd device get a DNS name > associated with their address in a DNSSEC-signed world again?) and > letting network operators use DHCP with IPv6 the way they do with IPv4. David you know as well as I do that DNSSEC is a orthognal issue here. The first issue is how do you assign a name to a object? The second issue is how do you add that name to the DNS? The third issue is how do you sign that change? I solve it by give the machine a name. Adding a KEY record at that name to the DNS, the private part the machine knows. I then use SIG(0) to update the address records of the machine whenever the addresses change. The DNS server that accepts that update generated new RRSIGs for the records affected by that change and the zone propogates out to the servers using NOTIFY. I update the reverse PTR records using tcp-self as the authentication mechanism. tcp-self is weak but is strong enough for the level of trust assigned to PTR records. Again the DNS server generates appropriate signatures. The machine's name is not tied to the network on which it lives. Mark > Or, we simply continue down the path of more NATv4. > > Regards, > -drc > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: IPv6 Confusion
At Tue, 17 Feb 2009 11:28:11 -0800, Tony Hain wrote: > > While people frequently claim that auto-config is optional, there are > implementations (including OS-X) that don't support anything else at this > point. The basic message is that you should not assume that the host > implementations will conform to what the network operator would prefer s/network operator would prefer/specifications/ > One last comment (because I hear "just more bits" a lot in the *nog > community)... Approach IPv6 as a new and different protocol. If you approach > it as "IPv4 with more bits", you will trip over the differences and be > pissed off. If you approach it as a "different protocol with a name that > starts with IP" and runs alongside IPv4 (like we used to do with decnet, > sna, appletalk...), you will be comforted in all the similarities. You will > also hear lots of noise about 'lack of compatibility', which is just another > instance of refusing to recognize that this is really a different protocol. > At the end of the day, it is a packet based protocol that moves payloads > around. unfortunately, this view leads to two internets, and one not reachable from the other. this is not very realistic from the business and user point of view. randy
Re: IPv6 Confusion
> Also, a proposal for a different approach is at: > http://mice.cs.columbia.edu/getTechreport.php?techreportID=560 (PDF) which has an internet draft, draft-ymbk-aplusp-02.txt randy
Re: IPv6 Confusion
On Wed, 18 Feb 2009 10:55:30 +1100, Mark Andrews said:
> I solve it by give the machine a name. Adding a KEY record
> at that name to the DNS, the private part the machine knows.
I think the issue is that the machine in question may not know its own hostname
to start, much less that dnssec is in use, or that a private key is supposed to
be remembered on the machine. So there's a bit of a bootstrapping problem
there.
Of course, you can skip over that issue by letting the DHCP server do
the DNS updates as a proxy for the just-DHCP'ed machine, but that has
other issues...
(or just pre-populate the DNS with DHCP-2001-9A98-D247-{5more}.ISP.com and be
done with it like many places do for IPv4)
pgpF2F5uAUaJj.pgp
Description: PGP signature
Re: IPv6 Confusion
On Feb 17, 2009, at 1:55 PM, Mark Andrews wrote: (which was never fully thought out -- how does a autoconfig'd device get a DNS name associated with their address in a DNSSEC-signed world again?) and letting network operators use DHCP with IPv6 the way they do with IPv4. David you know as well as I do that DNSSEC is a orthognal issue here. My understanding, which may well be wrong, is that: - stateless auto-configuration assumes the client will update the address to name association once it has obtained the address. - In order to do this, the DNS server needs to support Dynamic DNS. - If DNSSEC is in use, it requires the use of on-line signing keys. - Security folks get unhappy when you mention on-line signing keys. Solution? - Don't have address to name associations - Don't worry about (or accept lesser) security on address to name associations. Of course the DNSSEC bit is sort of moot, as I suspect there aren't a whole lot of ISPs in a position to support dynamic updates from clients... Regards, -drc
Re: IPv6 Confusion
In message <14076.1234917...@turing-police.cc.vt.edu>, valdis.kletni...@vt.edu
writes:
> --==_Exmh_1234917735_3892P
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, 18 Feb 2009 10:55:30 +1100, Mark Andrews said:
> > I solve it by give the machine a name. Adding a KEY record
> > at that name to the DNS, the private part the machine knows.
>
> I think the issue is that the machine in question may not know its own hostna
> me
> to start, much less that dnssec is in use, or that a private key is supposed
> to
> be remembered on the machine. So there's a bit of a bootstrapping problem
> there.
There are lots of bootstrap issues.
> Of course, you can skip over that issue by letting the DHCP server do
> the DNS updates as a proxy for the just-DHCP'ed machine, but that has
> other issues...
Indeeded.
> (or just pre-populate the DNS with DHCP-2001-9A98-D247-{5more}.ISP.com and be
> done with it like many places do for IPv4)
Which still leaves the problem of how does the machine get its
name in a trusted manner.
> --==_Exmh_1234917735_3892P
> Content-Type: application/pgp-signature
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Exmh version 2.5 07/13/2001
>
> iD8DBQFJm1lncC3lWbTT17ARAm8iAKCbx6hoYDgRqHMk5JyG0uKIt0Ki1ACgz7ij
> z3amg/2yC8HtcnFbg03Bmw4=
> =TqDw
> -END PGP SIGNATURE-
>
> --==_Exmh_1234917735_3892P--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: IPv6 Confusion
In message <33415e7e-23f2-45f2-9281-ab1685dee...@virtualized.org>, David Conrad writes: > > On Feb 17, 2009, at 1:55 PM, Mark Andrews wrote: > >> (which was never fully > >> thought out -- how does a autoconfig'd device get a DNS name > >> associated with their address in a DNSSEC-signed world again?) and > >> letting network operators use DHCP with IPv6 the way they do with > >> IPv4. > > David you know as well as I do that DNSSEC is a orthognal > > issue here. > > My understanding, which may well be wrong, is that: > > - stateless auto-configuration assumes the client will update the > address to name association once it has obtained the address. > - In order to do this, the DNS server needs to support Dynamic DNS. > - If DNSSEC is in use, it requires the use of on-line signing keys. > - Security folks get unhappy when you mention on-line signing keys. Security is about managing risk not eleminating all risks as that is a unobtainable goal. Security folks that don't understand that don't understand their jobs. > Solution? > > - Don't have address to name associations > - Don't worry about (or accept lesser) security on address to name > associations. DNSSEC is design to work with off-line signing if that is the security level you require. It doesn't however require off-line signing. A HSM which just prevents access to the private key is more than enough for most deployment senarios. > Of course the DNSSEC bit is sort of moot, as I suspect there aren't a > whole lot of ISPs in a position to support dynamic updates from > clients... Actually I suspect they are all in a position to do so as the software to do this was deployed by the major vendors last century. What it takes is for them to move from the arcane dialup model where there was not point in doing this to the semi-static model where there is a point in letting the leasees have the ability to record the names of their machines in the DNS. In otherwords ISP's need to enter the 21st century. Mark > Regards, > -drc > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
RE: IPv6 Confusion
Hi, I find it a shame that NAT-PT has become depreciated, with people talking about carrier grade NATS I think combining these with NAT-PT could help with the transition after we run out of IPv4 space. ISP gets a chunk of IPv6 address space, sets up customers with it, gets their big lovely carrier grade NAT device that NAT's from customers IPv6 address to whatever IPv4 service they need. I'm probably missing something but does this not seem like a good option? Why not use IPv6 instead of private IPv4, end user gets end-to-end connectivity with anything that is IPv6 enabled while still being able to access the legacy IPv4 network. Also see it of long term benefit to ISP's as will first have to get big expensive equipment for CGN, but over time they won't have the big expensive of continuously upgrading these units as IPv4 dwindles Just my 2c Steve -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Wednesday, 18 February 2009 10:03 AM To: Tony Hain Cc: 'Carl Rosevear'; nanog@nanog.org Subject: Re: IPv6 Confusion At Tue, 17 Feb 2009 11:28:11 -0800, Tony Hain wrote: > > While people frequently claim that auto-config is optional, there are > implementations (including OS-X) that don't support anything else at this > point. The basic message is that you should not assume that the host > implementations will conform to what the network operator would prefer s/network operator would prefer/specifications/ > One last comment (because I hear "just more bits" a lot in the *nog > community)... Approach IPv6 as a new and different protocol. If you approach > it as "IPv4 with more bits", you will trip over the differences and be > pissed off. If you approach it as a "different protocol with a name that > starts with IP" and runs alongside IPv4 (like we used to do with decnet, > sna, appletalk...), you will be comforted in all the similarities. You will > also hear lots of noise about 'lack of compatibility', which is just another > instance of refusing to recognize that this is really a different protocol. > At the end of the day, it is a packet based protocol that moves payloads > around. unfortunately, this view leads to two internets, and one not reachable from the other. this is not very realistic from the business and user point of view. randy
Re: IPv6 Confusion
Mark Andrews wrote:
>> >> (or just pre-populate the DNS with DHCP-2001-9A98-D247-{5more}.ISP.com
>> >> and be
>> >> done with it like many places do for IPv4)
> >
> > Which still leaves the problem of how does the machine get its
> > name in a trusted manner.
> >
I don't know about that, but I do have an idea about how you could atleast have
a start to verify the things you receive. Tell me if I'm stupid and need more
sleep. And yes I didn't check, but I don't think anyone created a protocol for
this yet. It's just some things that came to mind.
Let's see...
For a start, you might want to be able to validate through DNSSEC the
PTR-records
of the global-addresses you receive 'from the network'.
Let's say you have a few /64 (global, fe80:: and possible also ULA) on the
network,
you autoconfigure an address with SLAAC, you get information about a gateway
and a recursive nameserver (yes maybe from DHCPv6, doesn't really matter for
this discussion).
The host with the newly aquired address(es) has a forwarding DNSSEC-validating
recursor on localhost with the public key for the root.
Which asks the recursive nameserver on the network for all the DNSSEC-records
it needs from the root down to verify any PTR-record about the global-addresses
it received like gateway or that recursive nameserver. This means you can use
the
recursive nameserver on the network, without trusting it (at first ?), you are
just using it as a cache.
After that you can check the -record for the name you got from the PTR to
see if they all match up (like HELO/MX/PTR-records for mailservers).
If everything checks out ok, then you know everything is controlled by the same
organisaion(s) and that they are legit.
If you have that information you could use it to get other key-material from
DNS,
maybe even opportunistic IPSec-keys, so you can start encrypting all
communications.
I do know I don't like the complexity of DNSSEC, but if we do get it to work,
maybe something like this could actually work (atleast in theory).
I'm going to have a good night's sleep now, although I'll probably kick myself
in
the morning for mentioning something stupid.
I keep wondering which we'll implement first, DNSSEC or IPv6. My guess is on
IPv6,
because of the implementation complexity of DNSSEC.
PS I'm not a native english speaker
Re: IPv6 Confusion
> I find it a shame that NAT-PT has become depreciated the ietf has recanted and is hurriedly trying to get this back on track. of course, to save face, the name has to be changed. > with people talking about carrier grade NATS I think combining > these with NAT-PT could help with the transition cgn is not a transition tool. it is a dangerous hack to deal with the problems of a few very large consumer isps who lack sufficient space to number their customer edge. randy
Re: IPv6 Confusion
On 2/17/09, Randy Bush wrote: > > > I find it a shame that NAT-PT has become depreciated > > the ietf has recanted and is hurriedly trying to get this back on > track. of course, to save face, the name has to be changed. > > > with people talking about carrier grade NATS I think combining > > these with NAT-PT could help with the transition > > cgn is not a transition tool. it is a dangerous hack to deal with > the problems of a few very large consumer isps who lack sufficient > space to number their customer edge. > > randy > > Sounds like those consumer ISPs better get started on rolling out dual stacks to the CPE. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbra...@gmail.com
Re: IPv6 Confusion
> cgn is not a transition tool. it is a dangerous hack to deal with > the problems of a few very large consumer isps who lack sufficient > space to number their customer edge. > Sounds like those consumer ISPs better get started on rolling out > dual stacks to the CPE. except that, if you do not have enough ipv4 pace to number your cpe perimeter, you can't do that. again, take a look at draft-ymbk-aplusp-02.txt randy
Re: IPv6 Confusion
On 18/02/2009, at 3:23 PM, Randy Bush wrote: I find it a shame that NAT-PT has become depreciated the ietf has recanted and is hurriedly trying to get this back on track. of course, to save face, the name has to be changed. Sort of - except it is only for IPv6 "clients" to connect to named IPv4 "servers". NAT-PT allowed for the opposite direction, IPv4 "clients" connecting to IPv6 "servers" - NAT64 does not. The server must have an A record in DNS, and the client must use that name to connect to - just like NAT-PT. -- Nathan Ward
Re: IPv6 Confusion
So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? -brandon On 2/17/09, Nathan Ward wrote: > On 18/02/2009, at 3:23 PM, Randy Bush wrote: > >>> I find it a shame that NAT-PT has become depreciated >> >> the ietf has recanted and is hurriedly trying to get this back on >> track. of course, to save face, the name has to be changed. > > Sort of - except it is only for IPv6 "clients" to connect to named > IPv4 "servers". NAT-PT allowed for the opposite direction, IPv4 > "clients" connecting to IPv6 "servers" - NAT64 does not. > > The server must have an A record in DNS, and the client must use that > name to connect to - just like NAT-PT. > > -- > Nathan Ward > > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbra...@gmail.com
Re: IPv6 Confusion
On 18/02/2009, at 3:04 PM, Steven Lisson wrote: ISP gets a chunk of IPv6 address space, sets up customers with it, gets their big lovely carrier grade NAT device that NAT's from customers IPv6 address to whatever IPv4 service they need. I'm probably missing something but does this not seem like a good option? Why not use IPv6 instead of private IPv4, end user gets end-to-end connectivity with anything that is IPv6 enabled while still being able to access the legacy IPv4 network. Or, you do dual-stack, so their applications do not have to be modified to support IPv6 - they only need to support IPv4 (with NAT) like they always have. They have IPv6 to do end-to-end, and IPv4 to do client-to-server, or for legacy application support. How many of your customers are likely to be running Windows XP in 2 years? Probably still quite a few - they will not be able to function on IPv6-only, as they do not have DHCPv6. In the current state of things, IPv4 to the edge is going to be required for some time still I believe. Sure, over time applications will need IPv6 support. That is not going to be likely to be done by the time we run out of IPv4 resources for the edge. -- Nathan Ward
Re: IPv6 Confusion
Tony, On Feb 17, 2009, at 12:17 PM, Tony Hain wrote: This being a list of network engineers, there is a strong bias toward tools that allow explicit management of the network. This is a fine position, and those tools need to exist. There are others that don't want, or need to know about every bit on the wire, where 'as much automation as possible' is the right set of tools. No question. However, as this is a list of network engineers who are the folks who need to deploy IPv6 in order for others who may not care about every bit on the wire to make (non-internal) use of it, I'd think the bias displayed here something that might carry some weight. Infighting at the IETF kept the RA from informing the end systems about DNS, and kept DHCPv6 from informing them about their router. The result is that you have to do both DHCP & RA, when each should be capable of working without the other. Yeah. Rants about the IETF should probably be directed elsewhere. As far as dnssec, while the question is valid, blaming the IPv6 design for not considering something that 10+ years later is still not deployed/deployable, is a bit of a stretch. Uh, no. That's not what I was saying. I was saying that stateless auto-configuration made certain assumptions about how naming and addressing worked that weren't necessarily well thought out (clients updating the reverse directly in a DNSSEC-signed environment was just an example). Perhaps it's just me, but it feels like there was a massive case of NIH syndrome in the IPv6 working groups that network operators are now paying the price for. However, as I said, rants about the IETF should probably be directed elsewhere. Or, we simply continue down the path of more NATv4. While this is the popular position, those that have thought about it realize that what works for natv4 at the edge, does not work when that nat is moved toward the core. Yeah, multi-layer NAT sucks. I was amazed when I was speaking with some African ISPs that had to go this way today because their telecoms regulatory regime required them to obtain addresses from the national PTT and that PTT only gave them a single address. I would argue that if we want to avoid this outcome (and make no mistake, there are those who like this outcome as it means end users are only content consumers, which fits into their desired business models much more nicely), we need to make IPv6 look more like IPv4 so that network operators, end users, content providers, network application developers, etc., have minimal change in what they do, how they do it, or how they pay for it. Part of that is getting familiar tools (e.g., DHCP, customer provisioning, management, etc.) working the way it works in IPv4. Taking advantage of all the neato features IPv6 might provide can come later. However, I have a sneaking suspicion it might already be too late... Regards, -drc
RE: IPv6 Confusion
Basically that is what I was thinking, not sure could say problem solved as would still be using big nat boxes, but if we are going to 'have' to have nat, why not in a form that encourages adoption of IPv6? Having have said that, from someone else's comment would have to agree with them about using ipv4 nat dual stacked with ipv6 instead. Would likely be more realistic due to how little time have before ipv6 exhaustion and end systems that need additional configuration to enable ipv6 (and I know how much support people hate having to help end users setup things they don't understand... like email settings, they at least know what e-mail is and why they are setting it up, how many don't know what IP is and would just get frustrated at doing something they don't understand why?) -Original Message- From: Brandon Galbraith [mailto:brandon.galbra...@gmail.com] Sent: Wednesday, 18 February 2009 1:14 PM To: Nathan Ward; nanog list Subject: Re: IPv6 Confusion So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? -brandon On 2/17/09, Nathan Ward wrote: > On 18/02/2009, at 3:23 PM, Randy Bush wrote: > >>> I find it a shame that NAT-PT has become depreciated >> >> the ietf has recanted and is hurriedly trying to get this back on >> track. of course, to save face, the name has to be changed. > > Sort of - except it is only for IPv6 "clients" to connect to named > IPv4 "servers". NAT-PT allowed for the opposite direction, IPv4 > "clients" connecting to IPv6 "servers" - NAT64 does not. > > The server must have an A record in DNS, and the client must use that > name to connect to - just like NAT-PT. > > -- > Nathan Ward > > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbra...@gmail.com
RE: IPv6 Confusion
Except for the fact that it's actually not so uncommon for "clients" to act as servers some of the time. Things have long ago left the days of clients were only clients and have since moved on to a muddier state of affairs. - S -Original Message- From: Brandon Galbraith [mailto:brandon.galbra...@gmail.com] Sent: Tuesday, February 17, 2009 10:14 PM To: Nathan Ward; nanog list Subject: Re: IPv6 Confusion So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? -brandon On 2/17/09, Nathan Ward wrote: > On 18/02/2009, at 3:23 PM, Randy Bush wrote: > >>> I find it a shame that NAT-PT has become depreciated >> >> the ietf has recanted and is hurriedly trying to get this back on >> track. of course, to save face, the name has to be changed. > > Sort of - except it is only for IPv6 "clients" to connect to named > IPv4 "servers". NAT-PT allowed for the opposite direction, IPv4 > "clients" connecting to IPv6 "servers" - NAT64 does not. > > The server must have an A record in DNS, and the client must use that > name to connect to - just like NAT-PT. > > -- > Nathan Ward > > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbra...@gmail.com
Re: IPv6 Confusion
On 18/02/2009, at 4:13 PM, Brandon Galbraith wrote: So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? I have been suggesting that for a long time. However I am not suggesting IPv6-only to clients. See my other email on this from a minute or so ago. The way I see things going in the medium term: * IPv4 SP-NAT * IPv6 native to clients Clients with no DHCPv6 can get DNS resolvers etc, and they can get to IPv4 hosts through IPv4 NAT which they already understand, and does not require application changes. They can use the native IPv6 transit from their ISPs to get to other IPv6 hosts. I do not expect the other IPv6 hosts I mention to be IPv6-only - but chances are they will be behind IPv4 NAT. That doesn't matter of course, because we are reaching them on native IPv6. I also recommend that you hold on to a /22 or something, and use that for customer assignment - but replicate it many times in your network. This way, your numbers assigned to customers will never conflict with their internal RFC1918 addressing, and their "deny RFC1918 to/from outside" automatic firewall things will not have any problems. Public IPv4 addresses behind NAT is quite common, so applications are used to dealing with it by now, for the most part - there are a few bugs with this and some implementations of 6to4 so I will write up a work around for this. We now have a bunch of IPv4 addresses we can re-purpose for servers and things, because we require less IPv4 addresses to serve our end user customers base. We will not be able to put servers on IPv6-only for a long time - we will have legacy applications, client hosts, and access networks that do not support IPv6. IPv4 will be required for public servers until these client hosts are a smaller percentage than they are now. Dirty trick - if you are an access-only provider, wait until the IPv4 pools are depleted, and then push all your customers in to SP-NAT, and then sell your now unused addresses[1] to other providers who cannot make do with hosts behind IPv4 NAT (ie, colocation, business Internet services, etc.). Use this income to pay for your IPv6 rollout, so your customers can continue to do end-to-end stuff. I forget what Geoff's speculation of what an IP address would cost - I seem to recall around about $1M per /16, but I could be wrong. -- Nathan Ward [1] Yes I know that this is not allowed under current policy at any RIR.
Re: IPv6 Confusion
On Feb 17, 2009, at 3:55 PM, Mark Andrews wrote: In otherwords ISP's need to enter the 21st century. Yeah, those stupid, lazy, ISPs. I'm sure they're just sitting around every day, kicking back, eating Bon Bons(tm), and thinking of all the new and interesting ways they can burn the vast tracts of ill-gotten profits they're obviously rolling in. Reality check: change in large scale production networks is hard and expensive. There needs to be a business case to justify making substantive changes. You are arguing that ISPs should make changes without any obvious mechanism to guarantee some return on the investment necessary to pay for those changes. This is a waste of time. In general, NAT is paid for by the end user, not the network provider. Migrating to IPv6 on the other hand is paid for entirely by the network provider. Guess which is easier to make a business case for? Note that I'm not saying I like the current state of affairs, rather I'm suggesting that jumping up and down demanding ISPs change because you think they're stuck in the last century is unlikely to get you very far. You want a concrete suggestion? Make configuring DDNS on BIND _vastly_ simpler, scalable to tens or hundreds of thousands of clients, and manageable by your average NOC staff. Regards, -drc
Re: IPv6 Confusion
>You are arguing that ISPs should make changes >without any obvious mechanism to guarantee some return on the >investment necessary to pay for those changes. Nail on the head and the 800 pound gorilla in the room. Japan gave tax incentives which helped their ISP's to move to IPv6. Find a lazy lobbyist who can educate a senator to say that there will be no more tubes left on the internet and slide a tax incentive into the next stimulus package :) Zaid - Original Message - From: "David Conrad" To: "Mark Andrews" Cc: "NANOG list" Sent: Tuesday, February 17, 2009 8:18:33 PM GMT -08:00 US/Canada Pacific Subject: Re: IPv6 Confusion On Feb 17, 2009, at 3:55 PM, Mark Andrews wrote: > In otherwords ISP's need to enter the 21st century. Yeah, those stupid, lazy, ISPs. I'm sure they're just sitting around every day, kicking back, eating Bon Bons(tm), and thinking of all the new and interesting ways they can burn the vast tracts of ill-gotten profits they're obviously rolling in. Reality check: change in large scale production networks is hard and expensive. There needs to be a business case to justify making substantive changes. You are arguing that ISPs should make changes without any obvious mechanism to guarantee some return on the investment necessary to pay for those changes. This is a waste of time. In general, NAT is paid for by the end user, not the network provider. Migrating to IPv6 on the other hand is paid for entirely by the network provider. Guess which is easier to make a business case for? Note that I'm not saying I like the current state of affairs, rather I'm suggesting that jumping up and down demanding ISPs change because you think they're stuck in the last century is unlikely to get you very far. You want a concrete suggestion? Make configuring DDNS on BIND _vastly_ simpler, scalable to tens or hundreds of thousands of clients, and manageable by your average NOC staff. Regards, -drc
Re: IPv6 Confusion
> Japan gave tax incentives which helped their ISP's to move to IPv6. i am writing this from my home office in tokyo. i have the latest fanciest wizbang ftth bflets 100/100 from ntt. native ipv6 is not offered on it. if i connect a v6 device to it, it gives me a v6 AC and RA. but that is for the closed walled garden voip phone service. randy
Re: IPv6 Confusion
Steven Lisson wrote: Hi, I find it a shame that NAT-PT has become depreciated, with people talking about carrier grade NATS I think combining these with NAT-PT could help with the transition after we run out of IPv4 space. For me the bigger problem is how do I enable IPv6 on my assorted CE-facing edges when management is still buying edge hardware that can not and will not ever support IPv6. Our CATV solution can't support IPv6 (it's not a DOCSIS 3 thing; it's that the specific model of CMTS we're buying can not do IPv6). Our shiny new ADSL2+ solution can't do IPv6 and support in hardware can't be added down the road. For that matter our FTTH solution which is L2 only doesn't really support IPv6 with their pseudo L3 security options. So 1) how does one get management of a US SP to realize that IPv6 is coming well within the lifetime of the brand-new equipment that we're purchasing and should be a major show-stopping purchasing decision, and 2) how do we get common equipment manufacturers to build in IPv6 support to the equipment we're buying? During our FTTH dog and pony show process with half a dozen different vendors, I asked each of them about their IPv6 support and they all unanimously claimed that there was no demand for it from their customers. At this point I'm looking at doing 6to4 tunnels far into the future. Justin
Re: IPv6 Confusion
In message <6f7ba817-320b-414f-9811-03b476990...@virtualized.org>, David Conrad
writes:
> On Feb 17, 2009, at 3:55 PM, Mark Andrews wrote:
> > In otherwords ISP's need to enter the 21st century.
>
> Yeah, those stupid, lazy, ISPs. I'm sure they're just sitting around
> every day, kicking back, eating Bon Bons(tm), and thinking of all the
> new and interesting ways they can burn the vast tracts of ill-gotten
> profits they're obviously rolling in.
>
> Reality check: change in large scale production networks is hard and
> expensive. There needs to be a business case to justify making
> substantive changes. You are arguing that ISPs should make changes
> without any obvious mechanism to guarantee some return on the
> investment necessary to pay for those changes. This is a waste of time.
Adding support to accept dynamic updates is a small
configuration change.
> In general, NAT is paid for by the end user, not the network
> provider. Migrating to IPv6 on the other hand is paid for entirely by
> the network provider. Guess which is easier to make a business case
> for?
No. It also requires the end user to also upgrade equipment.
Mind you a lot of that upgrading has already been paid for
by both the ISP and the end user.
I'll most probably need to upgrade to a DOCSIS 3 modem for
native IPv6 support. I own my current modem.
> Note that I'm not saying I like the current state of affairs, rather
> I'm suggesting that jumping up and down demanding ISPs change because
> you think they're stuck in the last century is unlikely to get you
> very far. You want a concrete suggestion? Make configuring DDNS on
> BIND _vastly_ simpler, scalable to tens or hundreds of thousands of
> clients, and manageable by your average NOC staff.
For the reverse namespace we have tcp-self and 6to4-self
we could trivially add a 56-self for ISP's that want to
deploy on the /56 boundary rather than the /48 boundary
that 6to4-self uses. TCP is used as the authenticator
for these updates.
zone "23.2.1.in-addr.arpa" {
type master;
...
update-policy {
grant * tcp-self * PTR;
};
};
TSIG or SIG(0) can be used in the forward direction.
zone "example.net" {
type master;
...
update-policy {
grant * self *;
};
};
It doesn't get much simpler than that.
Mark
> Regards,
> -drc
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: IPv6 Confusion
On Tue, 17 Feb 2009 23:08:21 CST, Justin Shore said: > For me the bigger problem is how do I enable IPv6 on my assorted > CE-facing edges when management is still buying edge hardware that can > not and will not ever support IPv6. Find out if Randy Bush's companies are still buying non-IPv6-capable gear, and ask if you're a competitor to those companies... :) pgp5xup7ClKue.pgp Description: PGP signature
Re: IPv6 Confusion
On Tue, 17 Feb 2009, Justin Shore wrote: different vendors, I asked each of them about their IPv6 support and they all unanimously claimed that there was no demand for it from their customers. Well, this is just ignorance or a kind of a lie. There might be few customers who are willing to treat IPv6 support as a showstopper, but saying that there is no demand simply isn't true, it's just that they can get away without IPv6 support right now. We all hear the same thing when we ask for IPv6 support. Most of the time the vendors don't educate their sales force (both the droids and the sales engineers) about IPv6 because they themselves have made the strategic decision that IPv6 isn't important to them (personal view). I've seen IPv6 show up on presentations more and more though, so it's going in the right direction. But as you say, any new equipment decisions done today should include lack of IPv6 support as a show stopper (it should at least be committed in roadmap), plus it needs to be specified exactly what kind of IPv6 support should be in it. I agree with you that 6to4 seems to be the tunneling mechanism of choice for the forseeable future. It's easy to implement in the home gateways, but there too, you need to force the CPE vendors to include 6to4 into their CPE software. If any CPE NAT box vendor comes around and has 6to4 with proper IPv6, I'll happily recommend all our customers who want IPv6 to buy that perticular box. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 Confusion
On Feb 17, 2009, at 7:40 PM, Mikael Abrahamsson wrote: Most of the time the vendors don't educate their sales force (both the droids and the sales engineers) about IPv6 because they themselves have made the strategic decision that IPv6 isn't important to them (personal view). Suggestion: next time you buy equipment from competing vendors, tell the sales folk from the losing vendors that one deciding factor was (vendor or product) IPv6 support. That (and perhaps only that) will get their attention... :-) If any CPE NAT box vendor comes around and has 6to4 with proper IPv6, I'll happily recommend all our customers who want IPv6 to buy that perticular box. Apple Airport Extreme? (Seems to work, but I don't know how standards conformant it is) Regards, -drc
Re: IPv6 Confusion
On Tue, 17 Feb 2009, David Conrad wrote: Suggestion: next time you buy equipment from competing vendors, tell the sales folk from the losing vendors that one deciding factor was (vendor or product) IPv6 support. That (and perhaps only that) will get their attention... :-) Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. Even the companies who do support IPv6 very well in some products, not all their BUs do on their own products (you know who you are :P ). I'm hopeful though, I see more and more references to IPv6 show up in product powerpoint presentations, so it's moving in the right direction. If any CPE NAT box vendor comes around and has 6to4 with proper IPv6, I'll happily recommend all our customers who want IPv6 to buy that perticular box. Apple Airport Extreme? (Seems to work, but I don't know how standards conformant it is) Too expensive. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 Confusion
On Wed, Feb 18, 2009, Mikael Abrahamsson wrote: > >>If any CPE NAT box vendor comes around and has 6to4 with proper IPv6, ^ > >>I'll happily recommend all our customers who want IPv6 to buy that > >>perticular box. > > > >Apple Airport Extreme? (Seems to work, but I don't know how standards > >conformant it is) > > Too expensive. Oh, so you want the $50 almost-but-not-quite-functional CPE device which causes headaches for you and your techies, complete with almost-but-not-quite "upgrade" firmware updates which somewhat-wierdly subtly break existing functionality for a small-but-statistically-annoying portion of your userbase. Gotcha! :) Adrian (Yeah I know, Apple have shipped busted updates too..)
Re: IPv6 Confusion
On Wed, 18 Feb 2009, Adrian Chadd wrote: Oh, so you want the $50 almost-but-not-quite-functional CPE device which causes headaches for you and your techies, complete with almost-but-not-quite "upgrade" firmware updates which somewhat-wierdly subtly break existing functionality for a small-but-statistically-annoying portion of your userbase. Gotcha! For my USD30 a month 24 megabit ADSL2 residential broadband service, yes, you got it right, apart from that the cost should probably be more in the USD20-30 range. But at this point in the development cycle, I was more expecting this functionality in the USD100+ high-end consumer NAT/wifi-gateways. For the corporate offering with managed service, no, I do want something better there. -- Mikael Abrahamssonemail: swm...@swm.pp.se
