Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Mon, 9 Feb 2009, Ricky Beam wrote: On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk step...@sprunk.org wrote: Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate. This is exactly the same with NAT and non-NAT -- making any anti-NAT arguments null. In the case of NAT, the helper has to understand the protocol to know what traffic to map. In the case of a stateful firewalling (non-NAT), the helper has to understand the protocol to know what traffic to allow. Subtle difference, but in the end, the same thing... if your gateway doesn't know what you are doing, odds are it will interfere with it. In all cases, end-to-end transparency doesn't exist. (as has been the case for well over a decade.) You arguments making any pro-NAT arguments null. You agree, that NAT and Stateful Packet Inspetion firewall doing similar things. Advantage of the SPI firewall is that you have to maintain only one forwarding/state table. While in NAT you have to maintain two table. Therefore SPI firewall is more scalable 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 --Ricky
Re: Network equipments process utilization
Good morning (from here), lion...@samsung.com (???×?) wrote: I wonder which percentage is good level of CPU and Memory util of network equipment ? In my case, I try to keep under 30% cpu util and 70% memory util. My most equipment are Cisco product. I have no technical reference about that, it is just a rule of mine or my predecessor. Could you tell me how other operators are doing ? what is your operation baseline ? or is there any guideline about process utilization ? I'm trying to keep all Cisco equipment idle, if at all possible, since there may come worse times... Typical exceptions are - software forwarding routers, where CPU load is directly depending on current traffic levels; should the load stay above 15-20% all the time, it's time for an upgrade - slow-CPU boxes like everything Cisco with SUPs, since the CPU load _always_ jumps to 100% for short periods of time - BGP needs something calculated ;-) I get interested whenever CPU load _stays_ high - switches; Cisco switches need like 5% CPU to blink the LEDs ;) It gets more interested with packet filters and load balancers, where CPU loads depend on traffic levels and patterns. I try to keep the baseline between 5 and 10%. HTH, Elmar.
Re: Network equipments process utilization
At 09:39 AM 10-02-09 +0100, Elmar K. Bins wrote: - slow-CPU boxes like everything Cisco with SUPs, since the CPU load _always_ jumps to 100% for short periods of time - BGP needs something calculated ;-) I get interested whenever CPU load _stays_ high Yeah - Cisco would like to know why as well: http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html :-) -Hank
Re: Network equipments process utilization
h...@efes.iucc.ac.il (Hank Nussbacher) wrote: - slow-CPU boxes like everything Cisco with SUPs, since the CPU load _always_ jumps to 100% for short periods of time - BGP needs something calculated ;-) I get interested whenever CPU load _stays_ high Yeah - Cisco would like to know why as well: http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html I know ;-) But: This is not a churn problem, it's a problem of slow CPUs in allegedly big-and-fast boxes. I'd like a NPE-G2 blade for my 76's, as RP. Still, this is getting off-topic. Elmar.
Re: Network equipments process utilization
Elmar K. Bins wrote: h...@efes.iucc.ac.il (Hank Nussbacher) wrote: - slow-CPU boxes like everything Cisco with SUPs, since the CPU load _always_ jumps to 100% for short periods of time - BGP needs something calculated ;-) I get interested whenever CPU load _stays_ high Yeah - Cisco would like to know why as well: http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html I know ;-) But: This is not a churn problem, it's a problem of slow CPUs in allegedly big-and-fast boxes. I'd like a NPE-G2 blade for my 76's, as RP. Still, this is getting off-topic. The MSFC4 in the RSP720 has a 1.2GHz 8548 PPC whereas the NPE-G2 has a 1.67GHz 7448 PPC. I'd guess the performance isn't all that far apart, especially as the MSFC4's processor isn't doing any forwarding. adam.
Re: Network equipments process utilization
li...@memetic.org (Adam Armstrong) wrote: CPU load _always_ jumps to 100% for short periods of time - BGP needs something calculated ;-) I get interested whenever CPU load _stays_ high Yeah - Cisco would like to know why as well: http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html I know ;-) But: This is not a churn problem, it's a problem of slow CPUs in allegedly big-and-fast boxes. I'd like a NPE-G2 blade for my 76's, as RP. Still, this is getting off-topic. The MSFC4 in the RSP720 has a 1.2GHz 8548 PPC whereas the NPE-G2 has a 1.67GHz 7448 PPC. I'd guess the performance isn't all that far apart, especially as the MSFC4's processor isn't doing any forwarding. That's why I wrote with SUPs (and not RSPs). RSP is fairly new, and they got it right this time.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Tue, 10 Feb 2009 18:03:40 +1100, Matthew Palmer said: Considering that RFC1918 says nothing about IPv at all, could that be a blocker for deployment in general? That'd also make for an interesting discussion re: other legacy protocols (IPX, anyone?)... I was all set to call shenanigans on this one - except I double-checked the dates on the RFCs, and RFC1752 pre-dates 1918 by a year... Not sure what it says about our industry that both RFCs are 13+ years old now, and we still can't collectively do either one right... pgpUXbgEq87yq.pgp Description: PGP signature
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
IPTables is decent firewall code. Not really. It's quite complicated for a non-engineer type to manage. Think of all the unpatched windows xp/vista users of the world. It's free. ... Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code. No. It's not. While you might not be paying anyone for the software, it does come with some significant costs... a moderately powerful processor and a lot of memory. Ah, but both are cheap these days, and getting cheaper, you say. Tell me where I can get 500MHz+ processors and 16+ MB of ram for pennies. Case in point... (in case you missed it) Linksys stopped using Linux on their popular WRT54G line years ago in favor of vxWorks because it took less resources and therefor meant they could use less memory (flash and ram) and save money despite paying a license fee for vxWorks. (They still use vxWorks on the 54g, but have used linux on their newer (much more expensive) hardware.) Well thank goodness that VxWorks 6.x (or with 3rd party hackery) can both do IPv6 and can have firewalling functionality as well (or so Google tells me). Oh, and Linux can be tiny - even with iptables. I suspect Cisco (nee Linksys) chose VxWorks for a number of reasons, footprint being but one of them. DSL and cable modems are extremely simple devices. I'm amazed they have any amount of router in them at all. And I've yet to see one running Linux. (the 2 popular brands around here -- westell and motorola -- run vxworks.) Actually, the DOCSIS 3.0 spec may be changing that ... eRouter ...
Re: Private use of non-RFC1918 IP space
Just for the record, the original post was in reference to use of non-RFC1918 space on an *air-gapped* network. --Trey Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon. Anybody feel like starting a pool for when we'll see a posting to NANOG about somebody who's managed to burn through a /32? ++++ Kingfisher Operations Trey Darley - Principal
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ... SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX. Fair enough, but my point was that it isn't the auditors' faults in _all_ cases. When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do. Please cite references. I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required. Minor correction (I did say I wasn't sure it was SOX) ... It is PCI that requires RFC1918 and translation. For SOX, what is your assessment of (IPv6) internal controls and risk based on? Has anyone (with the authority to do so) developed and released guidance? Do we have a repository of current best practices to rely on (yet)? Interestingly, with SOX, I am curious if lack of IPv6 preparation will play into the risk assessment as well :). Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply tend to omit IPv6 completely, and generally require everything not explicitly called out to be disabled ... thus, no IPv6 on any network that falls under any of these regulations. We are just starting to see finalized product profiles and STIGs for IPv6 configuration - without that guidance Defense networks really couldn't wink run IPv6 either. (In other words (again, generally speaking) - if you run IPv6, your current CA (or perhaps your CTO (Certificate To Operate)) is invalid).
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
However the PCI DSS does contain a Compensating controls section, which allows for the use of functionality which provide[s] a similar level of defense to the stated requirements, where the stated requirements can not be followed due to legitimate technical or documented business constraints Now the fact that RFC1918 addresses don't work with IPv6 is clearly a legitimate technical ... constraint, so as long as you could successfully argue that a stateful firewall or other measures in place provided equivalent security as NAT you should be fine. Excellent loophole! Although I wonder how many clueful auditors are out there and able to make this fly ...
RE: IPv6 delivery model to end customers
My pleasure, now everyone - feel free to ring up your local sales/support rep and encourage their product to implement this ... please! What about DHCPv6 / DHCPV6-PD sniffing (and using that info to create L3 filter rules in L2 devices), is a standard needed or is it obvious to vendors how to implement it? An analogy to DHCP Guard - yes, please do encourage them to also do this. (And an RFC might not be a bad idea ... ) While we are at it - MLD Snooping should (IMHO) be a switch's default behavior as well!
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Considering that RFC1918 says nothing about IPv at all, That may technically be true, but it does explicitly reference IPv4 addresses. Oh, and when RFC1918 (or more correctly, RFC1597) was written, IP, TCP/IP, etc. all directly meant IPv4. (RFC1597 @ 03/94 ... RFC1883 @ 12/95)
Re: IPv6 delivery model to end customers
On Feb 10, 2009, at 9:01 AM, TJ wrote: My pleasure, now everyone - feel free to ring up your local sales/support rep and encourage their product to implement this ... please! What about DHCPv6 / DHCPV6-PD sniffing (and using that info to create L3 filter rules in L2 devices), is a standard needed or is it obvious to vendors how to implement it? An analogy to DHCP Guard - yes, please do encourage them to also do this. (And an RFC might not be a bad idea ... ) While we are at it - MLD Snooping should (IMHO) be a switch's default s/MLD/MLD v2/ Marshall behavior as well!
New IPv4 blocks allocated to RIPE NCC
[Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 109/8 and 178/8 from the IANA in January 2009. We will begin allocating from these ranges in the near future. The minimum allocation size from these two /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Please also note that several pilot prefixes are being announced from each /8. These prefixes are: 178.0.0.0/16, pingable 178.0.0.1 178.1.0.0/21, pingable 178.1.0.1 178.1.24.0/24, pingable 178.1.24.1 109.0.0.0/16, pingable 109.0.0.1 109.1.0.0/21, pingable 109.1.0.1 109.1.24.0/24, pingable 109.1.24.1 They all originate in AS12654. More information on this pilot activity is available in the document De-Bogonising New Address Blocks, which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator
Is whois.apnic.net down?
I get Connection timed out on whois commands to it.
Re: Is whois.apnic.net down?
I get Connection timed out on whois commands to it. Sorry to attempt to answer my own question, but maybe it's the fires in Australia, as the last traceroute hop is a Brisbane.telstra.net domain name.
RE: Is whois.apnic.net down?
Times out for me as well. Last hop in AU. 8 240 ms 238 ms 239 ms 10.14.254.125.unassigned.comindico.com.au [125.254.14.10] -Original Message- From: Dale Carstensen [mailto:d...@lampinc.com] Sent: Tuesday, February 10, 2009 11:45 AM To: nanog@nanog.org Subject: Is whois.apnic.net down? I get Connection timed out on whois commands to it.
Re: Is whois.apnic.net down?
On 2/10/09, Dale Carstensen d...@lampinc.com wrote: I get Connection timed out on whois commands to it. Sorry to attempt to answer my own question, but maybe it's the fires in Australia, as the last traceroute hop is a Brisbane.telstra.net domain name. Backhoe fade I'm used to. But now fire fade? Lovely. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbra...@gmail.com
Re: Is whois.apnic.net down?
On Tue, Feb 10, 2009 at 09:48:21AM -0700, Dale Carstensen wrote: I get Connection timed out on whois commands to it. Sorry to attempt to answer my own question, but maybe it's the fires in Australia, as the last traceroute hop is a Brisbane.telstra.net domain name. Brisbane's about 2000km north of the major fires. Instead, they're recovering from a cyclone. Gotta love this country. - Matt -- Talk about unlucky. D'you know, if I fell in a barrel of tits I'd come out sucking me thumb. -- Seen on the 'net: http://thelawwestofealingbroadway.blogspot.com/2006/01/bang-to-rights.html
Re: Is whois.apnic.net down? (IPv6-MW)
On Tue, Feb 10, 2009 at 8:48 AM, Dale Carstensen d...@lampinc.com wrote: I get Connection timed out on whois commands to it. Sorry to attempt to answer my own question, but maybe it's the fires in Australia, as the last traceroute hop is a Brisbane.telstra.net Brisbane (where APNIC is) is close to 1000 miles from Melbourne (where the fires are). Ironically the state Brisbane is in is currently experiencing very bad flooding over most of the state... But I digress. www.apnic.net is also down over IPv4, but reachable over IPv6. whois.apnic.net doesn't seem to have an IPv6 address. Scott.
[NANOG-announce] NANOG45 Updates
Dear Community... One more thank you to Terremark for hosting NANOG45, and to all those in the Dominican Republic who made our stay a bit more enjoyable. However, it sure is nice to be home. Before moving on to our next adventure together, a few pieces of closure information for NANOG45 follows: http://www.surveymonkey.com/s.aspx?sm=xAI_2bhyaMaWjl2diOG8lBKQ_3d_3d Survey open until Friday, February 13, be sure you completed yours!! http://nanog.org/meetings/nanog45/agenda.php Now includes the video archive Meeting attendance and survey information will be posted in approximately 2 weeks. Moving forward, we are excited about NANOG46 in Philly! and look forward to seeing everyone there. Sincerely, Betty Merit NANOG Community Project Manager ___ NANOG-announce mailing list nanog-annou...@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Feb 10, 2009, at 8:52 AM, TJ wrote: Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply tend to omit IPv6 completely, and generally require everything not explicitly called out to be disabled ... thus, no IPv6 on any network that falls under any of these regulations. TJ - You attempted to say that for PCI, and then it was shown that there's clear language regarding compensating controls that could easily be considered applicable. I haven't had the honor of running an IPv6-enabled system through a PCI compliance audit, but have little doubt that it will happen shortly and will require auditor education just like every other technology introduction. I run a data center which specializes in secure, compliant managed services, and have been through hundreds of audits in support of our clients which include federal civilian, federal defense, health care, and financial services firms. There are very few IT standards which have precise protocol or address requirements embedded in them, and there is almost always an opportunity to provide compensating controls where necessary. If you've got an example from one of the above compliance frameworks to the contrary that would actually preclude IPv6 deployment, please cite it. (In other words (again, generally speaking) - if you run IPv6, your current CA (or perhaps your CTO (Certificate To Operate)) is invalid). Sure... change your network, and you need to update your CA package as part of maintaining your ATO. It's up to your DAA as to whether they want to use IPv6 prior to equipment being certified under the DoD IPv6 Profile. /John John Curran EVP, COO, CTO ServerVault Corp
Re: Is whois.apnic.net down? (IPv6-MW)
Quoting Scott Howard sc...@doc.net.au: On Tue, Feb 10, 2009 at 8:48 AM, Dale Carstensen d...@lampinc.com wrote: I get Connection timed out on whois commands to it. Sorry to attempt to answer my own question, but maybe it's the fires in Australia, as the last traceroute hop is a Brisbane.telstra.net Brisbane (where APNIC is) is close to 1000 miles from Melbourne (where the fires are). Ironically the state Brisbane is in is currently experiencing very bad flooding over most of the state... But I digress. www.apnic.net is also down over IPv4, but reachable over IPv6. whois.apnic.net doesn't seem to have an IPv6 address. Scott. 933 ms33 ms33 ms 203.119.76.66 1036 ms35 ms35 ms whois.apnic.net [202.12.29.13] Trace complete. It's reachable from where I'm sitting (NSW)
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply tend to omit IPv6 completely, and generally require everything not explicitly called out to be disabled ... thus, no IPv6 on any network that falls under any of these regulations. TJ - You attempted to say that for PCI, and then it was shown that there's clear language regarding compensating controls that could easily be considered applicable. I haven't had the honor of running an IPv6-enabled system through a PCI compliance audit, but have little doubt that it will happen shortly and will require auditor education just like every other technology introduction. First off - me neither; this is related to my realm, but not within it. Secondly - we largely agree; although I think the level of auditor education that will need to occur is more burdensome than might be expected - partially due to lack of underlying guidance. Again, I don't live and breathe compliance, but the best I have seen is that some have started developing these procedures/guidelines. Started. Additionally, I suspect (but do not know that) the compensating control clause is meant to be a special case ... I'd love to hear more ... I run a data center which specializes in secure, compliant managed services, and have been through hundreds of audits in support of our clients which include federal civilian, federal defense, health care, and financial services firms. There are very few IT standards which have precise protocol or address requirements embedded in them, and there is almost always an opportunity to provide compensating controls where necessary. If you've got an example from one of the above compliance frameworks to the contrary that would actually preclude IPv6 deployment, please cite it. Sure, general language meant to be semi-technology-independent. Perhaps not outright preclude deployment altogether, but certainly cause (possibly rather expensive) delays or complications. Note - I am merely pseudo-quoting from what auditors and policy people have told me and my colleagues, through the course of several briefings. Allow me to more directly quote one of my colleagues: * Current CA auditors are not checking for IPv6-based vulnerabilities. They do not understand the process or have the tools to do IPv6 CA. * IPv6 is already deployed in a surprising number of IT systems, networks, and software - we find it operating in audits of agencies and enterprises that are not deploying IPv6 * Is your FISMA CA complete/valid without considering IPv6? Note that the last bullet is a somewhat rhetorical question - the answer is obviously no, but you might be surprised to see the look on some peoples' faces when you tell them that ... Or let's take this - http://72.34.43.90/IPV6/usipv6_reston_2004/thu/Kruger-Schifalacqua.pdf ... and while the goal is to show that/how it is possible to obtain your ATO, I think it makes a strong case in the opposite direction. How can you be assured that you live up to Do no harm when the definition of harm, based on the (until very recently) absent standards upon which to make this basis? Or with a staff (local network or auditor) that is not IPv6 savvy at day -1 (meaning prior to the expected deployment of IPv6). (And in fact, after just re-reading it - this presentation seems to make a case for disabling DAD (albeit in a specific case) - something that violates the protocol spec as well as the DoD APL requirements ... so who wins that decision?) To take it a step further (and perhaps be over-simplsitic): The guidance to disable all unused protocols and services applies. So, if you aren't using IPv6 today it must be off. If you want to turn it on, you must redo your CA. That costs money, therefore doesn't happen - atleast not soon. Therefore, no IPv6. I would love to hear more from those who have done CA (of any flavor) on an IPv6 enabled network - specifically, was IPv6 actually considered/evaluated and any problems it caused for the process. (In other words (again, generally speaking) - if you run IPv6, your current CA (or perhaps your CTO (Certificate To Operate)) is invalid). Sure... change your network, and you need to update your CA package as part of maintaining your ATO. It's up to your DAA as to whether they want to use IPv6 prior to equipment being certified under the DoD IPv6 Profile. But that is my point - Do any of the compliance frameworks / requirements / audit standards today address IPv6, or detail how it could be implemented in such a fashion as to 'pass' an audit (including the in-house / consultant-specific audit guidelines)? If it can be done, but is solely a you and your (current) auditor figure it out, on a case by case basis, every time I would argue that that is not good enough for the general case. And while I agree with you, any change = redo I would argue that not everyone realizes that all of their CA work will need to be re-done in order to retain their CTOs/ATOs if they move forward
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, 09 Feb 2009 21:11:50 -0500, TJ trej...@gmail.com wrote: Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router? More frequently than the DHCP server, but neither are frequent events. Cisco's software is not 100% perfect, and when you plug it into moderately unstable things like phone lines (DSL) and cable networks, those little bugs cause reloads -- you'd think they'd have better error handling, but they don't. (I don't buy millions in equipment from Cisco so they don't care about my problems.) While I could use backup links, flip-floping between ISPs with different addresses is not ideal (and that's as true for v6 as v4.) Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6? Because it doesn't fit the needs of *every* network. In fact, it's only good enough for very few networks. As such it just adds more useless layers of bloat. Well, as it stands now the RA isn't useless. ... Also, it is not true in every case that hosts need a lot more than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6). It's useless. It does NOT provide enough information alone for a host to function. In your own words, you need a DNS server. That is NOT provided by RA thus requires yet another system to get that bit of configuration to the host -- either entered manually, DHCPv6, or from IPv4 network configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. We've had a system to provide *ALL* the information a host needs or wants in the IPv4 world for years. Why it's not good enough for IPv6 is beyond me. --Ricky
Re: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Rob, Eloy Paris from the Cisco PSIRT here. Please see below (inline) for some comments regarding the issue you brought up in your email to the cisco-nsp and nanog mailing lists this past Jan. 16th: On Fri Jan 16 07:57:52 2009, Rob Shakir wrote: Strict RFC 4893 (4-byte ASN support) BGP4 implementations are vulnerable to a session reset by distant (not directly connected) ASes. This vulnerability is a feature of the standard, and unless immediate action is taken an increasingly significant number of networks will be open to attack. Accidental triggering of this vulnerability has already been seen in the wild, although the limited number of RFC 4893 deployments has limited its effect. Summary: It is possible to cause BGP sessions to remotely reset by injecting invalid data into the AS4_PATH attribute provided to store 4-byte ASN paths. Since AS4_PATH is an optional transitive attribute, the invalid data will be transited through many intermediate ASes which will not examine the content. To be vulnerable, an operator does not have to be actively using 4-byte AS support. This problem was first reported by Andy Davidson on NANOG in December 2008 [0], furthermore we have been able to demonstrate that a device running Cisco IOS release 12.0(32)S12 behaves as per this description. Details: [...] Cisco Bug CSCsx10140 was filed for Cisco IOS. Cisco IOS behaves exactly as you described - upon receipt of AS_CONFED_SEQUENCE data in the AS4_PATH attribute IOS will send a NOTIFICATION message to the peer, which causes a termination of the BGP session. After the fix for this bug IOS will ignore AS_CONFED_SEQUENCE data in the AS4_PATH attribute of received BGP UPDATE messages and continue to process the UPDATE. This is the new behavior that the revised RFC 4893 will require. CSCsx18598 was filed for Cisco IOS XR. Cisco IOS XR doesn't reset the session but accepts and forwards the invalid AS4_PATH data, so this bug was filed to change this behavior. CSCsx23179 was filed for Cisco NX-OS (for the Nexus switches.) Cisco NX-OS behaves like IOS (it will reset the BGP session when it sees AS_CONFED_SEQUENCE data in the AS4_PATH attribute), and this bug was filed to change this and have the BGP implementation in Cisco NX-OS follow the revised RFC 4893. The Release Notes for each bug may have some additional information. These are available via the Bug Toolkit on cisco.com (http://tools.cisco.com/Support/BugToolKit) To date, the only version of Cisco IOS that supports 4-byte AS numbers is 12.0(32)S12, released in late December. A fix to the 12.0(32)Sxx branch has been committed so the next 12.0(32)S-based release will have the fix. 12.0(32)SY8 is coming out soon, and it will also have support for 4-byte AS numbers, as well as the fix for the problem. Thanks for bringing attention to this issue and for working with us, specifically with the Cisco TAC, to get to the bottom of it and test the proposed fix. Cheers, - -- Eloy Paris Cisco PSIRT -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmR9OoACgkQagjTfAtNY9jv5ACgg3fKuuWKv38h8F8d8QHBML5J CTsAnAnGMB/fBIQhk5z4E922JlhHVU5A =FSOP -END PGP SIGNATURE-
unsolicited name transfers from Godaddy
I have been receiving a high number of unsolicited domain transfer requests from Godaddy and have also written to Godaddy support about unsolicited domain transfer requests. Since I am not a Godaddy customer I got a standard talk to the hand. I have colleagues confirming that some similar chatter is also happening in the ICANN space with respect to Godaddy. Are folks here experiencing this also? Thanks, Zaid
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router? More frequently than the DHCP server, but neither are frequent events. Cisco's software is not 100% perfect, and when you plug it into moderately unstable things like phone lines (DSL) and cable networks, those little bugs cause reloads -- you'd think they'd have better error handling, but they don't. (I don't buy millions in equipment from Cisco so they don't care about my problems.) While I could use backup links, flip-floping between ISPs with different addresses is not ideal (and that's as true for v6 as v4.) But my real point was if the router is failed, traffic isn't being forwarded regardless of how the host got the information ... correct? And vendor support issues are a layer 8-11 problem ... no layer 3 fix for that! (8-11 == people politics religion money ... in no particular order) Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6? Because it doesn't fit the needs of *every* network. In fact, it's only good enough for very few networks. As such it just adds more useless layers of bloat. Obviously we disagree, fundamentally. Well, as it stands now the RA isn't useless. ... Also, it is not true in every case that hosts need a lot more than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6). It's useless. It does NOT provide enough information alone for a host to function. In your own words, you need a DNS server. That is NOT provided by RA thus requires yet another system to get that bit of configuration to the host -- either entered manually, DHCPv6, or from IPv4 network configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. We've had a system to provide *ALL* the information a host needs or wants in the IPv4 world for years. Why it's not good enough for IPv6 is beyond me. Technically, that is a gap RFC5006 would fill - once supported, which should have been long before now but too late for that, eh? And I think we also disagree on a fundamental aspect, specifically - I see it this way: 1) the RAs are there primarily to allow a router to provide information about itself to the hosts on the link a) which becomes the default gateway from the hosts' perspective 2) Everything after that is a separate thing, namely - host addressing and other configuration a) which could be SLAAC, by including a prefix in the RA ... and maybe a DNS server option, someday. -) and maybe Stateless DHCPv6 as well, for the DNS or other missing info b) which could be DHCPv6, providing all of the addressing and config info (but not router info) I think the key factor to our disagreement is that I think it makes great sense for the router to provide information about itself to the hosts, and you'd rather it be centralized. I don't really care either way, to be honest - it just seems to make good sense (to me) the way it works now. If I understand correctly the answer, from your standpoint, would be to author an RFC specifying a default gateway option for DHCPv6 (and maybe a prefix length option as well?). And then get DHCPv6 client functionality itself, and this option, more widely supported (and in fact, on by default). As to why it's not good enough ... well, suffice it to say this debate has raged for a LNG time and apparently sufficient consensus (for reasons good or ill) was reached at some point for the way it is now. Build consensus to change that (factoring in the pain it would cause to current deployments) ... maybe starting off small, with just defining the option and convincing a major vendor or two to implement it ... if the world agrees, it will migrate to working that way ... isn't that how this whole open standards process is supposed to work? (OK, that last question was a bit rhetorical and was not meant to spark a debate about this being the IETF vs the IVTF vs the __ etc. etc. Sorry!) Failing that (or while that is ongoing?) ... we have what we have. And it does indeed work, today, for almost all * cases. So let's get deploying, go team! * - as discussed at length on this list and others /TJ Be conservative in what you send and liberal in what you accept. --Jon Postel The future belongs to those who see possibilities before they become obvious. --unknown In essentials, unity; in non-essentials, liberty; in all things, charity --various Everyone's a hero in their own way, in their own not that heroic way. --Joss Whedon
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 10/02/2009, at 3:20 PM, Christopher Morrow wrote: IPv6 it's easier, but you're still limiting the uptime of your system to that of the DHCPv6 server. Router advertisements is much more robust. 'more robust'... except it doesnt' actually get a device into a usable state without admins walking around to each machine and poking at them randomly. if you have 5 machines that's cool, knock yourself out, if you have 5000 or 5 you are in a completely different ballpark of work. DHCP servers do this today, the servers pass out all the relevant bits require for dynamic-addressed and static-addressed systems, they can be rebooted, moved, re-addressed, re-homed... all without the masses of clients stopping their work. I believe you are mis-interpreting Iljitsch's comments. I believe he is talking about SLAAC, you are talking about *no* DHCPv6. The difference is, SLAAC can still use DHCPv6 to get configuration information. If the DHCPv6 server goes away when using SLAAC for addressing, configuration information is already there. I have a lot of problems with DHCP and most people don't _need_ it. Still, can you explain how 'most people don't need it'?? is that because most people have an admin to go configure their DNS servers in their resolver config?? Consumer Internet users are a great example of this, if necessary an ISP can pass out new DNS servers, and in 8-10 days easily remove the old DNS servers from the network, or move them to another place in the network seemlessly without having to touch each consumer device. Why would anyone NOT want that?? what replaces that option in current RA deployments? Again, this seems to be confusion with SLAAC vs. no DHCPv6 what so ever. I could be wrong though - I don't want to be putting words in to Iljitsch's mouth. -- Nathan Ward
Re: 97.128.0.0/9 allocation to verizon wireless
Mark Andrews schrieb: I don't see any reason to complain based on those numbers. It's just a extremely high growth period due to technology change over bring in new functionality. OTOH, Verizon is not the only provider of smartphone connectivity in the world. Most of them try to be good citizens and do not waste a scarce resource (IPv4 space). If more providers would act like Verizon, we would have run out of IPv4 addresses a long time ago (whether or not that is a good or bad thing is left as an exercise to the reader). -- Matthias
Re: 97.128.0.0/9 allocation to verizon wireless
On Feb 10, 2009, at 5:31 PM, Matthias Leisi wrote: Mark Andrews schrieb: I don't see any reason to complain based on those numbers. It's just a extremely high growth period due to technology change over bring in new functionality. OTOH, Verizon is not the only provider of smartphone connectivity in the world. Most of them try to be good citizens and do not waste a scarce resource (IPv4 space). You mean like the 10.x.x.x addresses give to all iPhones in the US? Wait, I thought NAT was bad? So who is the good citizen? -- TTFN, patrick If more providers would act like Verizon, we would have run out of IPv4 addresses a long time ago (whether or not that is a good or bad thing is left as an exercise to the reader). -- Matthias
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 11/02/2009, at 10:41 AM, Ricky Beam wrote: It's useless. It does NOT provide enough information alone for a host to function. In your own words, you need a DNS server. That is NOT provided by RA thus requires yet another system to get that bit of configuration to the host -- either entered manually, DHCPv6, or from IPv4 network configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. We've had a system to provide *ALL* the information a host needs or wants in the IPv4 world for years. Why it's not good enough for IPv6 is beyond me. You are correct, alone RA does not provide enough for a host to function. We have two mechanisms of providing addressing information to hosts - SLAAC and DHCPv6. How do you, as a network manager, tell hosts which one to use? RA performs this function. Without RA you need to go around all the machines and manually configure how they will discover what addresses to use. That seems a bit silly, and going around every machine is something you have already indicated you don't want to do. RA has two functions - telling your hosts which of SLAAC and DHCPv6 to use for addressing information, and providing addressing information in the case of SLAAC. Also, in the case of SLAAC, it might hint to the client to get additional information from DHCPv6 - DNS servers and so on - in this case it will not get addressing information. Perhaps you have a problem with SLAAC? That is fine, you might not want to use it. Other people *do* want to use it, and RA is the best place to signal which of SLAAC and DHCPv6 a host should use for addressing. Please do not use blanket comments that RA is bad if you actually mean SLAAC. Yes, if we do not have SLAAC then we don't need RA, because hosts will always know to use DHCPv6. However, many people do want SLAAC, so we need RA. If you have an idea for alternative to RA for indicating whether to use SLAAC or DHCPv6 then I encourage you to get involved in the IETF and get your idea written up. If you would like to deprecate/fix SLAAC because you have a problem with it then again, I encourage you to get involved in the IETF. -- Nathan Ward
Re: 97.128.0.0/9 allocation to verizon wireless
On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote: Mark Andrews schrieb: I don't see any reason to complain based on those numbers. It's just a extremely high growth period due to technology change over bring in new functionality. OTOH, Verizon is not the only provider of smartphone connectivity in the world. Most of them try to be good citizens and do not waste a scarce resource (IPv4 space). I disagree that using global IPv4 space is a waste. Every device deserves to have real internet connectivity and not this NAT crap.
Re: 97.128.0.0/9 allocation to verizon wireless
Chuck Anderson wrote: On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote: Mark Andrews schrieb: I don't see any reason to complain based on those numbers. It's just a extremely high growth period due to technology change over bring in new functionality. OTOH, Verizon is not the only provider of smartphone connectivity in the world. Most of them try to be good citizens and do not waste a scarce resource (IPv4 space). I disagree that using global IPv4 space is a waste. Every device deserves to have real internet connectivity and not this NAT crap. Why must it be always real versus NAT? 99% of users don't care one way or another. Would it be so hard for the carrier to provide a switch between NAT and real IP if the user needs or wants it?
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Feb 10, 2009, at 4:30 PM, TJ wrote: But that is my point - Do any of the compliance frameworks / requirements / audit standards today address IPv6, or detail how it could be implemented in such a fashion as to 'pass' an audit (including the in-house / consultant-specific audit guidelines)? If it can be done, but is solely a you and your (current) auditor figure it out, on a case by case basis, every time I would argue that that is not good enough for the general case. Compliance frameworks are generally technology agonistic. They tell you have an information boundary for your system, manage your user identifiers, etc. Aside from the DoD IA STIGs (and small handful of NIST areas such as encryption), you don't find specifications that particular protocols or technology is required. They don't require major updating for IPv6 because there's very little IPv4 specific contents in them already. That's not to say that moving an application to IPv6 is trivial from a compliance and security perspective, as you've still got a pile of mandatory firewall, load-balancing, and IDS infrastructure that needs to handle IPv6 correctly before you can get started. In organizations that are planning ahead, this is common security control infrastructure, and gets done once centrally rather than each little component. And while I agree with you, any change = redo I would argue that not everyone realizes that all of their CA work will need to be re-done in order to retain their CTOs/ATOs if they move forward with any sort of IPv6 deployment. I have heard the gasps (I didn't see the faces, that was a coworker of mine did and said it was amusing - in a sad way.) Look, systems change. Change your database software, and you get to update the corresponding pieces of the CA package. Add IPv6, you have to update the network portions. This shouldn't be a surprise to anyone, and it certainly doesn't mean all of their CA work will need to be re-done. /John
Re: 97.128.0.0/9 allocation to verizon wireless
On Tue, 10 Feb 2009 14:52:52 PST, Dave Temkin said: Why must it be always real versus NAT? 99% of users don't care one way or another. Would it be so hard for the carrier to provide a switch between NAT and real IP if the user needs or wants it? You're almost always better off not providing a user-accessible switch. Especially not a shiny one labeled Do not touch unless you know what you are doing. (FWIW, this is exactly the same issue as block port 25 unless user requests opt-out from the block) pgpi6taC8ZGqT.pgp Description: PGP signature
Re: 97.128.0.0/9 allocation to verizon wireless
On Feb 10, 2009, at 5:52 PM, Dave Temkin wrote: Chuck Anderson wrote: On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote: Mark Andrews schrieb: I don't see any reason to complain based on those numbers. It's just a extremely high growth period due to technology change over bring in new functionality. OTOH, Verizon is not the only provider of smartphone connectivity in the world. Most of them try to be good citizens and do not waste a scarce resource (IPv4 space). I disagree that using global IPv4 space is a waste. Every device deserves to have real internet connectivity and not this NAT crap. Why must it be always real versus NAT? 99% of users don't care one way or another. Would it be so hard for the carrier to provide a switch between NAT and real IP if the user needs or wants it? Lots of providers do. Sometimes the choice between static dynamic is bundled with the choice between NAT real on some broadband providers. I've also seen hotels do it, and even charge extra for it. (Yes, I paid. ;) -- TTFN, patrick
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message op.uo5nvrmrtfh...@rbeam.xactional.com, Ricky Beam writes: On Mon, 09 Feb 2009 21:11:50 -0500, TJ trej...@gmail.com wrote: Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router? More frequently than the DHCP server, but neither are frequent events. Cisco's software is not 100% perfect, and when you plug it into moderately unstable things like phone lines (DSL) and cable networks, those little bugs cause reloads -- you'd think they'd have better error handling, but they don't. (I don't buy millions in equipment from Cisco so they don't care about my problems.) While I could use backup links, flip-floping between ISPs with different addresses is not ideal (and that's as true for v6 as v4.) Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6? Because it doesn't fit the needs of *every* network. In fact, it's only good enough for very few networks. As such it just adds more useless layers of bloat. Good. You admit it fits the needs of some networks. Well, as it stands now the RA isn't useless. ... Also, it is not true in every case that hosts need a lot more than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6). It's useless. It does NOT provide enough information alone for a host to function. Hogwash. The only thing needed for I used from DHCP on my laptop is router, address and netmask. I actually discard anything else that is offered. RA's meet my needs perfectly fine. In fact they do a better job than DHCP for my needs. I don't trust dns servers returned by dhcp. Lots of them don't offer the level of functionality I require. I run my own recursive resolver to get the level of functionality I require. In your own words, you need a DNS server. That is NOT provided by RA thus requires yet another system to get that bit of configuration to the host -- either entered manually, DHCPv6, or from IPv4 network configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. We've had a system to provide *ALL* the information a host needs or wants in the IPv4 world for years. Why it's not good enough for IPv6 is beyond me. --Ricky -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: 97.128.0.0/9 allocation to verizon wireless
Patrick W. Gilmore wrote: On Feb 10, 2009, at 5:52 PM, Dave Temkin wrote: Chuck Anderson wrote: On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote: Mark Andrews schrieb: I don't see any reason to complain based on those numbers. It's just a extremely high growth period due to technology change over bring in new functionality. OTOH, Verizon is not the only provider of smartphone connectivity in the world. Most of them try to be good citizens and do not waste a scarce resource (IPv4 space). I disagree that using global IPv4 space is a waste. Every device deserves to have real internet connectivity and not this NAT crap. Why must it be always real versus NAT? 99% of users don't care one way or another. Would it be so hard for the carrier to provide a switch between NAT and real IP if the user needs or wants it? Lots of providers do. Sometimes the choice between static dynamic is bundled with the choice between NAT real on some broadband providers. I've also seen hotels do it, and even charge extra for it. (Yes, I paid. ;) Exactly. I've seen this as well in both instances but haven't seen it on mobile phones. It's something so obscure that you're going to have to really want it to turn it on. I don't think the Port 25 example holds much water here. -Dave
Re: 97.128.0.0/9 allocation to verizon wireless
On Tue, Feb 10, 2009 at 3:29 PM, Dave Temkin dav...@gmail.com wrote: Exactly. I've seen this as well in both instances but haven't seen it on mobile phones. It's something so obscure that you're going to have to really want it to turn it on. I don't think the Port 25 example holds much water here. Many/most GSM/GPRS/etc operators will have multiple APN's - one which is setup for NAT, and the other which gives a public IP address. By default, most dumb phones will use the former. Data cards will use the latter, and smartphones seem to be split between the two - although obviously it will vary between providers. Scott.
Re: Is whois.apnic.net down? (IPv6-MW)
On Wed, Feb 11, 2009 at 2:13 AM, j...@miscreant.org wrote: 933 ms33 ms33 ms 203.119.76.66 1036 ms35 ms35 ms whois.apnic.net [202.12.29.13] Trace complete. It's reachable from where I'm sitting (NSW) Reachable just fine (from my dsl box in India, and from my personal colo near los angeles) srs -- Suresh Ramasubramanian (ops.li...@gmail.com)
World famous cabling disasters?
I'm looking for a couple of pictures of the worst cabling infrastructure ever seem. One Wilshire meet me room comes to mind. Anyone got any links to their photo albums, etc? Joe McGuckin ViaNet Communications j...@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax
Re: World famous cabling disasters?
On Tue, 10 Feb 2009, joe mcguckin wrote: I'm looking for a couple of pictures of the worst cabling infrastructure ever seem. One Wilshire meet me room comes to mind. Anyone got any links to their photo albums, etc? You might find some links in the archives. I've seen a few in person that still make me cringe. jms
Re: World famous cabling disasters?
On Feb 10, 2009, at 10:16 PM, joe mcguckin wrote: I'm looking for a couple of pictures of the worst cabling infrastructure ever seem. One Wilshire meet me room comes to mind. Anyone got any links to their photo albums, etc? I've always considered this the worst: http://englishrussia.com/images/home_networks/4.jpg Google shows lots of pictures, such as http://englishrussia.com/? p=1836. -- TTFN, patrick
RE: World famous cabling disasters?
Joe, I'm looking for a couple of pictures of the worst cabling infrastructure ever seem. One Wilshire meet me room comes to mind. Anyone got any links to their photo albums, etc? The One Wilshire pictures you are referring to were within this Wired article: http://www.wired.com/techbiz/it/multimedia/2008/03/gallery_one_wilshire?slid e=3slideView=2 Also there are some great photos at http://www.darkroastedblend.com/2007/03/really-bad-wiring-jobs_20.html Joe McGuckin ViaNet Communications Regards, Randy
