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: 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: 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: 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: 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: 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: 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: 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: 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: 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: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, Feb 05, 2009 at 07:19:37PM -0500, Robert D. Scott wrote: Wii should not even consider developing a cool new protocol for the Wii that is not NAT compliant via V4 or V6. And if they do, we should elect a NANOG regular to go POSTAL and handle the problem. The solution to many of these networking conundrums should rest with the application people, and NOT the network people. You are wrong, there are lots of new ... and not so new ... protocols that *can* work via ALGs or other NAT traversal systems, but tend to work worse than if they'd had end to end visibility. The various VoIP protocols are the perfect example. The end to end principal is the lifeblood of innovation on the internet and we need to do everything we can to allow anyone who wants it to have it. Kind regards, Andy Davidson
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, 9 Feb 2009, Andy Davidson wrote: On Thu, Feb 05, 2009 at 07:19:37PM -0500, Robert D. Scott wrote: Wii should not even consider developing a cool new protocol for the Wii that is not NAT compliant via V4 or V6. And if they do, we should elect a NANOG regular to go POSTAL and handle the problem. The solution to many of these networking conundrums should rest with the application people, and NOT the network people. You are wrong, there are lots of new ... and not so new ... protocols that *can* work via ALGs or other NAT traversal systems, but tend to work worse than if they'd had end to end visibility. The various VoIP protocols are the perfect example. Example please! Kind Regards, Janos Mohacsi
RE: v6 DSL / Cable modems
So far as I am aware, this is default behaviour only on certain versions of Mac OSX, and must be explicitly enabled on all others. Manually, on the console. RA does not dynamically distribute this behaviour; the client has to choose it. Usually it is a sysctl or a registry variable or the like. NIT: Add any IPv6 capable Windows workstation to that list (workstation meaning not server OS). Or any USAGI-derived 'nix kernel, AFAIK. (WinXP as described/expected, Vista with a twist (no EUI64 by default)) The philosophies of design of these two systems are entirely at odds. While I agree with that statement, I disagree just a little bit with your supporting argument. On either case, the host is initiating the discussion and trying to do what it wants (either appending randomized IIDs or asking the DHCPv6 server to supply it with randomly generated IIDs, and using the results as (a) temporary/privacy address(es)) ... in either case, if the hosts doesn't support it or doesn't ask, it doesn't happen. /TJ
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Fri, 06 Feb 2009 22:32:10 -0500, Owen DeLong o...@delong.com wrote: 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.) 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.) --Ricky
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
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.) --Ricky
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
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. Actually, it's worlds different. In the case of a stateful firewalling (non-NAT), the helper has to understand the protocol to know what traffic to allow. This is not completely true. Technologies such as uPNP can quickly open up a pinhole for traffic which needs to be initiated from the far end, but no address rewriting is necessary by the software (embedded in the protocol) or the firewall. For non-UDP/TCP packets, ports have no meaning, which is the biggest failing of NAT (since we are talking about overloading on one IP here, and not 1 to 1 translations). Firewall rules for packets that are not UDP/TCP usually allow the return traffic based on source and destination IP and IP protocol number. NAT, on the other hand can't do it. We have to make udp/tcp tunnels to carry the traffic through NAT instead. 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.) End-to-end addressing does exist, though. There are cases that are straight forward that NAT breaks without adding extra tunneling layers, or without either NAT or the software having to rewrite an embedded IP address in a packet to the public address. Sure, stateful firewalls can still block traffic and break certain scenarios without the assistance of uPNP(or application layer analysis). They will be simpler, and break less (we'd hope simpler means less). It's one thing to communicate with your firewall to dynamically open up ports for your address. It's another to start rewriting packets, analyzing specific protocols so that you can alter them. Feel free to disagree with me on all except non-TCP/UDP breakage. I've had too many support calls on that one, and NAT-T isn't always available, and even when available, it's not necessarily configurable. Jack
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Sat, Feb 7, 2009 at 5:56 PM, Matthew Moyle-Croft m...@internode.com.auwrote: My issue is that customers have indicated that they feel statics are a given for IPv6 and this would be a problem if I went from tens of thousands of statics to hundreds of thousands of static routes (ie. from a minority to all). Even injecting statics into But is this a general requirement, or just one from the types of people that are likely to be early adopters for IPv6? Go and ask those people who feel statics are a given for IPv6 if they would prefer static or dynamic IPv4 addresses, and I suspect most/all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I don't see static for IPv6 as any more (or less?) of an operational requirement than for IPv4. Certain users will definitely require static address, just as they do for IPv4, and IMHO these should be handled in exactly the same way - the exact mechanism for which will vary from ISP to ISP. Scott.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 10/02/2009, at 11:35 AM, Scott Howard wrote: Go and ask those people who feel statics are a given for IPv6 if they would prefer static or dynamic IPv4 addresses, and I suspect most/ all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I imagine there will be a difference - in my experience few people understand the automatic renumbering that you can do with IPv6, so think that static addressing is the only way forward. With IPv4 this is not an issue, as they do not re-number internal interfaces when their external IPv4 address changes. -- Nathan Ward
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Feb 9, 2009, at 2:11 PM, 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. And making the PRO-NAT arguments in this respect equally NULL. This was being touted as a benefit of NAT, not a reason not to do NAT. Your statement proves my point... It is NOT a reason to do NAT or a benefit derived from NAT. 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.) Right. This is the counterpoint to the argument that NAT is needed. You have now agreed that it is not. Owen
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum iljit...@muada.com wrote: If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address. Manual configuration doesn't scale. With IPv4, it's quite hard to make this work with DHCP, but mostly because of a lack of IPv4 addresses. With 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. As I read it, you don't want to use DHCP because it's an other service to fail. Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task. My point is simply, this whole mess with RA's should never have been on the table. DHCP has been around and used for years to provide IPv4 hosts with an address, gateway, and MANY other configuration options. It exists because (in many cases) hosts need more than just an address. Yet the protocol designers, staunch haters of DHCP, refused to see any value in DHCP for IPv6 and rolled back the clock 3 decades dooming us ALL to repeating the same bull. DHCPv6 can do everything SLAAC can plus infintely more. And an it just works configurationless setup could have been part of the standard instead; yet here we are... nobody 100% happy and a considerable amount of work being poured into reinventing the DHCP wheel. Manual static configuration is indeed a pain. That's why we have DHCP... set aside a range of addresses for machines that can move around (client workstations, etc.) and a pool of persistant addresses for servers, printers, etc. that you want to stay in one place -- some applications record addresses instead of names, *sigh*. Everything is in one, easy to manage location. For an ISP where a lot necessarily has to be manually configured, it can be more work, but is still simple -- even in the days of the NOC NOTEBOOK where only one person could be assigning addresses at a time. (we've had web based stuff for years now; feed rwhois directly, 'tho not automatic.) Isn't remembering stuff what we have computers for? If you aren't accessing machines by number, why do you care if it always has the same number? As long as the name always maps to the right number, it doesn't matter. I have a lot of problems with DHCP and most people don't _need_ it. Still, very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it. And I, likewise, don't want the utterly useless RA forced on my networks. Hosts need much more than just a unique address. And I don't want to have to walk around to every one of them to change anything. --Ricky
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Nathan Ward wrote: On 10/02/2009, at 11:35 AM, Scott Howard wrote: Go and ask those people who feel statics are a given for IPv6 if they would prefer static or dynamic IPv4 addresses, and I suspect most/all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I imagine there will be a difference - in my experience few people understand the automatic renumbering that you can do with IPv6, so think that static addressing is the only way forward. With IPv4 this is not an issue, as they do not re-number internal interfaces when their external IPv4 address changes. I wonder how much this is all going to change as there's an inevitable shift from my computer being The Client, to my computer being one of many servers that my cell phone uses, and is generally tethered to. Or just the situation that you have more than one place of residence and there is a somewhat indeterminate concept of what my computer really is. This is somewhat reminiscent of the pop/imap days, but there's just so much more stuff these days and broadband is still way too slow to really have a completely viable network/server solution. Fast servers in the network are great, but there are is a fairly large set of things that it just doesn't handle well; manifestly given the still huge split between local and network storage. (what percentage of stuff is in the cloud? 1%?) To me, that says that more and more people are going to want to access their home computer as if it were a server... which in fact it really is in the case of an iPhone wanting to suck down the latest dross from iTunes. And server means non-client accessiblity however you accomplish that. Mike
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
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.) Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled. This mangling can be a serious source of problems. With UDP, it can introduce checksum errors. With TCP, not only do you have possible checksum errors, you also have to mangle the sequence numbers in both directions if the length of the payload changes. The mangling will inherently break standard IPsec and other shim layers like HIP. And let's not forget that NAT makes widespread deployment of any L4 alternative to TCP and UDP (e.g. SCTP) virtually impossible, forcing every new transport or shim protocol to inefficiently ride on top of TCP or UDP... Some protocols, e.g. SIP/RTP, also work fine through a stateful firewall even without an ALG in most cases -- but not when you add in NAT. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On 10/02/2009, at 9:54 AM, Stephen Sprunk wrote: Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled. Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the inside and outside addresses happen to be the same. If I was a commodity consumer hardware manufacturer, that's how I'd handle the IPv6 firewalling problem, because that'd let me pass non-NAT'ed v6 packets and NAT'ed v4 packets through the same code paths, thereby enabling me to avoid reinventing the entire wheel (and an entire new set of bugs) to do v6 firewalling. DSL/Cable CPE is already full of v4 ALGs, and it's reasonable to expect that the only difference between those and the equivalent v6 ALGs will be the lack of v6 NAT. - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Feb 9, 2009, at 3:33 PM, Mark Newton wrote: On 10/02/2009, at 9:54 AM, Stephen Sprunk wrote: Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled. Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the inside and outside addresses happen to be the same. Uh, that's a pretty twisted view. I would say that NAT is a special additional capability of the firewall which mangles the address(es) in the packet. I would not regard passing the address unmangled as a special case of mangling. In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. Owen
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On 10/02/2009, at 10:17 AM, Owen DeLong wrote: Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the inside and outside addresses happen to be the same. Uh, that's a pretty twisted view. I would say that NAT is a special additional capability of the firewall which mangles the address(es) in the packet. I would not regard passing the address unmangled as a special case of mangling. You're passing a value judgement on NAT, using loaded terms like mangling and twisted. Fine, you don't like rewriting L3 addresses and L4 port numbers. Yep, I get that. Relevance? In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel. - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Owen DeLong wrote: In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. Unless your SOX auditor requires it in order to give you a non-qualified audit of your infrastructure. The real problem with IPv6 deployment is not that it can't be done, but that there are so many still-to-be-answered questions between here and there... Matthew Kaufman
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
In message 4990c38c.8060...@eeph.com, Matthew Kaufman writes: Owen DeLong wrote: In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. Unless your SOX auditor requires it in order to give you a non-qualified audit of your infrastructure. The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. The real problem with IPv6 deployment is not that it can't be done, but that there are so many still-to-be-answered questions between here and there... And the only way to answer them is to go ahead and find the gaps. Waiting and waiting won't find the problems and will just put you under more time presure. Mark Matthew Kaufman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Mark Newton wrote: Fine, you don't like rewriting L3 addresses and L4 port numbers. Yep, I get that. Relevance? Just out of what I like and might use, GRE (no port), ESP (no port), AH (no port), SCTP (would probably work fine with NAT, but I haven't seen it supported yet and because every box doing address rewrites MUST understand the protocol to perform NAT, it's likely to be back shelved despite it's cool features. Without NAT, it can be treated like GRE, ESP, and AH by a firewall, though improved security if the firewall does understand the protocol). And my favorite, 6-to-4, broken. There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel. ALG only fixes some problems, and it's not required for as much when address translations are not being performed. In addition, the bugs caused from address rewrites (and there have been some really poor implementations at the cheap home router level) will naturally disappear (to be replaced with new bugs concerning ALG/uPNP I'm sure). Jack
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On 10/02/2009, at 11:03 AM, Jack Bates wrote: There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel. ALG only fixes some problems, and it's not required for as much when address translations are not being performed. On a commodity consumer CPE device, the ALG code doubles as a stateful inspection engine. So it _is_ required when address translations are not being performed. Is security something that gets thought about now, or post-deployment? - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Mark Newton wrote: On a commodity consumer CPE device, the ALG code doubles as a stateful inspection engine. So it _is_ required when address translations are not being performed. H, the code may be there, but I suspect that not all of it will apply to v6 and be used. Is security something that gets thought about now, or post-deployment? I suspect that depends on who you ask. Security is always the top of my list. That being said, what security is there in removing NAT from v4 because it broke what the customer wanted to do? Then they are back to their host based stateful firewall; which apparently everyone believes is not good enough. Might as well throw in v6 and trash the NAT. Jack
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
As I read it, you don't want to use DHCP because it's an other service to fail. Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task. Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router? ... which would work the same way in an IPv6 scenario ... with the host knowing it's address for a period of time (Valid timer), and learning a new gateway in fairly short order (even sans FHRP). My point is simply, this whole mess with RA's should never have been on the table. DHCP has been around and used for years to provide IPv4 hosts with an address, gateway, and MANY other configuration options. It exists because (in many cases) hosts need more than just an address. Yet the protocol designers, staunch haters of DHCP, refused to see any value in DHCP for IPv6 and rolled back the clock 3 decades dooming us ALL to repeating the same bull. DHCPv6 can do everything SLAAC can plus infintely more. And an it just works configurationless setup could have been part of the standard instead; yet here we are... nobody 100% happy and a considerable amount of work being poured into reinventing the DHCP wheel. Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6? Manual static configuration is indeed a pain. That's why we have DHCP... set aside a range of addresses for machines that can move around (client workstations, etc.) and a pool of persistant addresses for servers, printers, etc. that you want to stay in one place -- some applications record addresses instead of names, *sigh*. Everything is in one, easy to manage location. For an ISP where a lot necessarily has to be manually configured, it can be more work, but is still simple -- even in the days of the NOC NOTEBOOK where only one person could be assigning addresses at a time. (we've had web based stuff for years now; feed rwhois directly, 'tho not automatic.) Isn't remembering stuff what we have computers for? If you aren't accessing machines by number, why do you care if it always has the same number? As long as the name always maps to the right number, it doesn't matter. I have a lot of problems with DHCP and most people don't _need_ it. Still, very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it. And I, likewise, don't want the utterly useless RA forced on my networks. Hosts need much more than just a unique address. And I don't want to have to walk around to every one of them to change anything. Well, as it stands now the RA isn't useless. It, and it alone, provides default gateway information ... from the default gateway itself. (I actually think that this is architecturally superior, but that is just my opinion ... ) ((The rest of the info, (addressing or other) can be obtained via RA/SLAAC or DHCPv6)) 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).
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 ...
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message 00cf01c98b24$efe42680$cfac73...@com, TJ writes: 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). address + default gateway. I know where the root servers live :-) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Mon, 9 Feb 2009 21:16:49 -0500 TJ trej...@gmail.com wrote: 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. -- John
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, Feb 9, 2009 at 6:16 PM, Ricky Beam jfb...@gmail.com wrote: On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum iljit...@muada.com wrote: If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address. Manual configuration doesn't scale. With IPv4, it's quite hard to make this work with DHCP, but mostly because of a lack of IPv4 addresses. With 'quite hard to make this work'?? what?? have you been making a dhcp server from scratch all these years? Iljitsch, what parts of making static mappings in DHCP, or setting the configuration bits required for dns/default-router/tftp-server/root-partition/wins-server/. is 'hard to do' in a dhcp server with decently wide use today? (isc dhcpd/windows-dhcp-server) 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. Why are you filling the discussion with FUD about dhcp servers?? As I read it, you don't want to use DHCP because it's an other service to fail. Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task. thank you Mr. Beam. 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? very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it. no, you don't today have to run it... but why are you arguing against the fact that admins at enterprises and ISP's have been making this very clear argument for equal functionality to what's available today? -Chris
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
John Peach wrote: On Mon, 9 Feb 2009 21:16:49 -0500 TJ trej...@gmail.com wrote: 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. Not just SOX. I vaguely remember something in PCI about NAT. It wouldn't surprise me if every auditing thing involving computers said something about requiring NAT. See my earlier comment about NAT=firewall. ~Seth
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.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
TJ wrote: 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. I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty sure the requirements will change as the addressing changes. Of course, I'm sure you will have a lot of NEW requirements. :) Jack
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Why would anyone NOT want that?? what replaces that option in current RA deployments? One nit - I like to differentiate between the presence of RAs (which should be every user where IPv6 is present) and the use of SLAAC (RA + prefix). Right now - Cheat off of IPv4's config. (Lack of DHCPv6 client-side support, and lack of DNS v6 transport (WinXP), necessitate this) Hopefully soon - RFC5006. Around the same timeframe - DHCPv6 (stateful or stateless, doesn't matter).
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Comtrend DSL modem use iptables in their code. I discovered this while trying to understood why small-MTU FTP breaks when issuing the PORT command. Frank -Original Message- From: Ricky Beam [mailto:jfb...@gmail.com] Sent: Monday, February 09, 2009 4:01 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space snip 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.) --Ricky
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
In message 00df01c98b27$3181b7e0$948527...@com, TJ writes: 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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
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. I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty sure the requirements will change as the addressing changes. Of course, I'm sure you will have a lot of NEW requirements. :) But that is the problem - it doesn't say You must use RFC1918 for IPv4 ... it just says You must use RFC1918. Meaning, you must not run IPv6. And some regulations do not mention/address IPv6 at all. Silence != security.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Mark Andrews wrote: Please cite references. I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required. (Skip if you've participated in a SOX audit from the IT department POV) The way it works is that the law doesn't call for specific measures. The law calls for audits. Audits are done by outside firms (like large accounting firms) using their internally-developed checklists for compliance. Passing the checklist gets you an unqualified audit. Failing a few items gets you a qualified audit. Failing more means you don't have the necessary audit document to present. The exact details of every line item are typically under non-disclosure when presented to the IT department for review, so for instance I can't post the ones from the last audit I participated in. Firms are also free to develop their own internal control guidelines, as long as they can convince the outside auditor that the controls are at least as strong as the ones on the checklist. Other regulations, like HIPPA, also require the same thing. For instance, the top Google hit for HIPPA and private address space links to a wustl.edu document regarding how their controls over HIPPA-protected information are implemented (including the use of private address space and the use of multiple layers of NAT). It takes a *lot* longer to get policies changed and auditors to sign off on the revised policies than it does to make a change in a router. That means that the process of updating policies should have started *even sooner* than the process of upgrading and reconfiguring routers for IPv6. But since there's still open questions (like the recent discussion of IPv6 NAT on the BEHAVE list) that have no answers at all, I can imagine why some folks might be putting off revising their policies and asking for external review of those. Matthew Kaufman
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, Feb 9, 2009 at 9:47 PM, TJ trej...@gmail.com wrote: Why would anyone NOT want that?? what replaces that option in current RA deployments? One nit - I like to differentiate between the presence of RAs (which should be every user where IPv6 is present) and the use of SLAAC (RA + prefix). Sure, but... RA is necessitated by the initial decision to use it and NOT support something akin to the bootp/dhcp sequence that v4 has. This could, it seems to me, be done... but since RA is there, it's not BAD to use it for prefix/default-route/ip-address it's just not anywhere near complete. Right now - Cheat off of IPv4's config. (Lack of DHCPv6 client-side support, and lack of DNS v6 transport (WinXP), necessitate this) agreed. -Chris
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Tue, Feb 10, 2009 at 02:16:10PM +1100, Mark Andrews wrote: In message 00df01c98b27$3181b7e0$948527...@com, TJ writes: [...SOX auditor stuff...] 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. It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: Implement IP address masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT) I know that some auditors want to hold people to that standard. I stopped working with the credit card people at that point...
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
security by obscurity is not the way, everyone knows it. those guys will figure it out sooner or later (where later, might take ages). in the meanwhile, a lot have pseudo-secured networks thru triple-nat, quadruple-nat, multiple ipsec'd layered and so, and others live with the hammer in their suitcase for fixing things around when the clue is gone. often they forgot the neat webserver box that run's some strange software, which no one updates, and... in the end is the cheese hole around their network... but, in the other end, money talks, and bulls**t walks, so, we might be all wrong, and they might be right, who knows ? who cares anyway ? :-) --nvieira - John Osmon jos...@rigozsaurus.com wrote: It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: Implement IP address masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT) I know that some auditors want to hold people to that standard. I stopped working with the credit card people at that point...
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Mon, Feb 9, 2009 at 9:54 PM, John Osmon jos...@rigozsaurus.com wrote: It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: Implement IP address masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT) It's moved to Requirement 1.3.8 of the current PCI DSS (V1.2, October 2008), and has been reworded slight : *1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies—for example, port address translation (PAT).* 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. Scott.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Mon, Feb 09, 2009 at 09:27:59PM -0500, TJ wrote: 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. 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?)... - Matt -- I tend to think of solution as just a pretentious term for thingy. Doing that word substitution in my head makes IT marketing literature somewhat more tolerable. -- lutchann, in http://lwn.net/Articles/124703/
RE: v6 DSL / Cable modems
I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents). I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. This does not seem to be generally true: - For the routers I am most familiar with (Juniper M/MX), you need to explicitly turn on router advertisement to make the router perform this. I.e. it is perfectly possible to have an interface with an IPv6 address which does *not* send RAs. Yes, vendors differ ... for Ciso/IOS - broadcast capable, multi-access interfaces (a la Ethernet) will automatically send RAs ones a /64 IPv6 address is configured. Or once you explicitly tell it to advertise one. - For the operating system I am most familiar with (FreeBSD), RAs are *not* accepted by default if the interface in question is configured with a static IPv6 address. I don't believe that is the general behavior, and specifically - for Win* a static being configured does not prevent autoconfiguration. And this is the correct behavior - to allow for cases where multiple prefixes are correct/expected, and only one is static. Both of these choices seem perfectly reasonable to me. I slightly disagree on the latter; autoconfiguration in the presence of RAs (including a (or several) prefix options) should be the default. ((... and now begins (continues, really) the pseudo-religious debate between the autoconfiguration people and the DHCPv6 people ...)) /TJ
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Feb 7, 2009, at 2:09 AM, Nathan Ward wrote: On 6/02/2009, at 12:00 PM, Joe Maimon wrote: This assignment policy is NOT enough for every particle of sand on earth, which is what I thought we were getting. There is enough for 3616 /64s, or 14 /56s per square centimetre of the earth's surface, modulo whatever we have set aside for multicast and non globally scoped unicast addresses and so on. If we pretend that hosts are only going to be on the area that is land, that gives us 12385 /64s, or 48 /56s per square centimetre. My suspicion is that before we get to a place where we have 48 humans per sq cm of land, we will run out of food. This has nothing to do with the number of blocks per area. Nice marketing, not useful for reality. How many IP-connected devices do you have on your person right now? How many non-IP-connected devices (e.g. bluetooth) that may someday be IP-connected? And how many more will we have? If you think you can answer the last one, you are lying to yourself. We will find a way to waste fritter away thing. We always have, we always will. In the mean time, we'll do the best with what we have. -- TTFN, patrick
Re: v6 DSL / Cable modems
I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents). I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. This does not seem to be generally true: - For the routers I am most familiar with (Juniper M/MX), you need to explicitly turn on router advertisement to make the router perform this. I.e. it is perfectly possible to have an interface with an IPv6 address which does *not* send RAs. - For the operating system I am most familiar with (FreeBSD), RAs are *not* accepted by default if the interface in question is configured with a static IPv6 address. Both of these choices seem perfectly reasonable to me. Steinar Haug, Nethelp consulting, sth...@nethelp.no
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)]
as I've said a few times now, reason #775 that autoconf is a broken and non- useful 'gadget' for network operators. There is a system today that does lots of client-conf (including the simple default-route + dns-server) called DHCP, there MUST be a similarly featured system in the 'new world order' of ipv6. This really is non-negotiable, why are people still holding out hope that autoconf is 'enough' when users and operators have so clearly said otherwise? There IS a similarly featured system. Why is it so hard to accept that in MANY cases SLAAC is enough (especially when RFC5006 is more widely supported, or while IPv4 is still around to cheat off of (glaring at WinXP)) ... and when it isn't enough, or when you feel like doing more DHCPv6 is there waiting for you? Almost no one is arguing that DHCPv6 can't exist, shouldn't exist, etc. Perhaps with the exception of Apple, that is - and that is still OK! I certainly see value in DHCPv6, but I see value in SLAAC as well. I don't want to force anyone to not do DHCPv6, why do others want to force me to do DHCPv6? Can't we all just get along?
RE: v6 DSL / Cable modems
What most people do of course is VRRP. Sure, or HSRP or GLBP ... all still doable. Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so. Indeed, not universal and in fact default behaviors vary wildly. When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents). The net result is that the client uses the default gateway which it used to reach the DHCP server, and so will automatically receive an updated value if that router fails, as part of DHCP lease rebinding (it will reach the server via the alternate router). Which I think is pretty slick. OOC - between the router fails and I renew/rebind my address, is the host down and out? So you are accepting either a noticeable outage or tweaking your lease times, yes?
Re: v6 DSL / Cable modems
On Sat, Feb 07, 2009 at 07:51:36PM +1300, Nathan Ward wrote: I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. Close, but it is worth clearing up. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. Most clients default out of the box to accept RA, getting a single address within each prefix indicating automatic address assignment. The ones that do support DHCPv6 will also initiate DHCPv6 services based on RA M and O flags. There are some bugs here and there, but it mostly works. This is all well and good, you are right on these points. However, Jack was referring to a practice of temporary address assignments. In this configuration, a client has one permanent (for as long as they are on that wire) address they use (per prefix, because that is how IPv6 multihomes, so they say) for general purpose and reachability from the outside world (dial in). They also have a range of temporary addresses which are in a state of preferred use, unpreferred use, or validity-timer expiration (again, per prefix, for multi-homing). Each temporary address is allocated based on a re-hash of a previously used seed, and half of the seed bits are not used in the public address (so outsiders can not easily predict what the client's next address will be). The theory is that these temporary addresses enhance privacy, as the client seems to hop from address to address. This seems to ignore application context hints such as cookies and keys embedded in URL's, so to my thinking the point of this is to enhance privacy for spammers or illegal file sharers. Anyway. So far as I am aware, this is default behaviour only on certain versions of Mac OSX, and must be explicitly enabled on all others. Manually, on the console. RA does not dynamically distribute this behaviour; the client has to choose it. Usually it is a sysctl or a registry variable or the like. Conversely, with DHCPv6, clients that support normal and temporary addresses simply always ask for them; this indicates they possess support. The service determines which type of address to actually provide (one, the other, both, with multiple bindings in either). In this way, all is automated from a central point. The philosophies of design of these two systems are entirely at odds. In RA the client determines what configuration it seeks, placing its own arbitrary demands upon the network, but still heeds some of its vague handwaving. In DHCPv6, the client submits to the network's will, but still has some of its own vague handwaving choices. It is Marxism (turned Socialism) vs Fascism at its root. I hope I have not spent my year's worth of NANOG tolerance for DHCP related discussions with the above. :) -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgp1JN3RhM7ce.pgp Description: PGP signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Matthew Moyle-Croft wrote: Stephen Sprunk wrote: You must be very sheltered. Most end users, even security folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on security through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users. I assume you're referring to ALG code? Indeed, I've found that turning off ALGs in NAT/FW boxes fixes a lot of problems, because every vendor's seem to be broken in a different way. I deal mainly with SIP these days, and the first step in any sort of firewall-related troubleshooting is to turn _off_ any SIP ALG functionality in the CPE because 90% of the time, that's whats breaking things; the end devices can deal with NAT as long as there's nobody in the middle mangling their packets. Ideally, ALGs would fix up the packets such that the endpoints didn't need to be NAT-aware, but they're all (and I mean all, not most) so hideously broken that they make things worse, not better. They can't get even simple, fossilized protocols like active FTP working most of the time; there's no way they'll do better with newer, more complicated ones like SIP or the dizzying array of P2P and IM protocols. At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream. 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. However, to be safe the endpoints cannot assume any firewalls in the path are going to work properly, and the absence of NAT makes it tougher for endpoints to detect firewalls' presence and react as needed... (In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/insert favourite fw is for enterprise). I've found the enterprise NAT/FW gear to be worse: they attempt to implement more ALGs, but they do no better a job at implementing them than the less-ambitious consumer vendors, so more things break. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
RE: v6 DSL / Cable modems
But I don't see how you could route some /48s without having software to route all /48s and that is hugemongous. As currently spec'ed, you [would|should|could] allow /48s from the specific PI ranges (1/RIR?) - not just auto-accept all /48s. /TJ
RE: v6 DSL / Cable modems
It would be nice if DHCPv6 (or DHCPv4 for that matter) could include not only a default, but, a static routing table in what it distributes. In theory, RAs can - more specific routes, although I don't believe any vendor (router or client side) supports these as of yet ... (Default Router Preference more widely supported, but less granular) Could you please explain a good reliable method for source address selection in a multiple IP binding scenario? RFC3484 being revisited as we speak, feel free to help :) ... may include things like policy table updates to clients ... Note - no great/clean answer yet to the multi-homed to disparate networks scenario. (It's a hard problem to automagically solve for all cases) /TJ
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Bill Stewart wrote: That's not because it's doing dynamic address assignment - it's because you're only advertising the aggregate route from the BRAS/DSLAM/etc., and you can just as well do the same thing if you're using static addresses. Customers can land on one of a fleet of large BRAS across multiple POPs in a geographic region so that a failure of one piece of equipment or POP doesn't cause an outage. If I want to run a hint of redundancy then I need to propogate statics out of the POP itself. There are corners that can be cut but none seem to fit into the kind of redundancy we like. Unlike a most BGP routes DSL circuits tend to go up and down a lot, this adds to convergence time and CPU load on the router. My issue is not basic network design skills. My issue is that customers have indicated that they feel statics are a given for IPv6 and this would be a problem if I went from tens of thousands of statics to hundreds of thousands of static routes (ie. from a minority to all). Even injecting statics into iBGP rather than an IGP I feel would add considerably to the load routers face and give a big hit in the event of failure. (We already have a class of customer with statically assigned addresses or ranges). The indication so far seems to be that on this list at least people don't see IPv6 statics for all as the general option. This gives me a bit more hope. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message 498bddac.7060...@eeph.com, Matthew Kaufman writes: Mark Andrews wrote: WII's should be able to be directly connected to the network without any firewall. If they can't be then they are broken. As I'm sure you know, you can tell the difference between an Internet evangelist and someone who mans the support lines by how they feel about X should be able to be directly connected to the network without any firewall. ...then they are broken applied to 4.3 BSD-running VAXen and Sun 3's in 1988, and neither the frequency of attacks launched nor the number of exploitable bugs in network stacks or network-packet-ingesting application programs has gone down since then. Matthew Kaufman I still believe that despite having to deal with all these issues at the time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
David W. Hankins david_hank...@isc.org writes: On Thu, Feb 05, 2009 at 11:42:27PM +0100, Iljitsch van Beijnum wrote: On 5 feb 2009, at 22:44, Ricky Beam wrote: I've lived quite productively behind a single IPv4 address for nearly 15 years. So you were already doing NAT in 1994? Then you were ahead of the curve. Ahh, the 90s. No need for NAT yet. http://en.wikipedia.org/wiki/SOCKS Does anyone remember http://en.wikipedia.org/wiki/The_Internet_Adapter ? People used to share the Internet connected *hosts*. Address sharing was implicit. Bjørn
Re: v6 DSL / Cable modems
Paul Vixie vi...@isc.org wrote on 02/06/2009 02:20:01 AM: the fundamental implication is, forget about address space, it's paperwork now, it's off the table as a negotiating item or any kind of constraint. but the size of the routing table is still a bogeyman, and IPv6 arms that bogeyman with nukes. Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big. Joe
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Matthew Moyle-Croft wrote: My comment was regarding customers believing that they were going to, by default, get a statically allocated range, whatever the length. If most customers get dynamically assigned (via PD or other means) then the issue is not a major one. Dynamic or static; how does this alter the state of the routing table? A network assigned is a network assigned. In addition, IPv6 has some decent support for mobile IP, which my limited understanding of says they enjoy routing tables the rest of us never get to see. IPv6 is designed to be renumbered. Not all implementations support this extremely well, but it is there. I believe the mobile technologies support renumber on the fly better than traditional aggregation networks who have no expectation of mobility. Jack On 06/02/2009, at 8:56 PM, Paul Jakma wrote: On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be for a long time with IPv6). So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64. Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for hierarchical routing of bits past 64 is highly rare). Think of IPv6 as a 64bit network address + host address. At least for now. regards, -- Paul Jakmap...@clubi.iep...@jakma.orgKey ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson
Re: v6 DSL / Cable modems
Joe Loiacono wrote: Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big. Let's also not forget, that many organizations went from multiple allocations to a single allocation. If we all filter anything longer than /32, we'll rearrange the flow of traffic that many over the years have altered through longer prefixes. Even I suspect I may occasionally have to let a /40 out now and then to alter it's traffic from the rest of the aggregate. Traffic comes to you as it wants to come to you. The only pseudo remedy that currently exists is to move some prefixes over to a different path. If you only have a /32, that'll be a bit hard. This, more than anything, is what will effect this list and the people on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare we go to /48 and treat them as the new /24? I know for myself, traffic manipulation can't begin until /40 (unless I split them further apart). Jack
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 5 Feb 2009, Paul Timmins wrote: John Schnizlein wrote: Maybe upgrades, service packs and updates will make them capable of using DHCPv6 for useful functions such as finding the address of an available name server by the time IPv6-only networks are in operation. And if not, hardcode em. It's not like your usual nameserver will be behind a nat anyway, and generally, a DNS server is a DNS server. Er, no, open recursive resolvers are a very bad idea. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: v6 DSL / Cable modems
On Friday 06 February 2009 08:51:04 Jack Bates wrote: Joe Loiacono wrote: Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big. Let's also not forget, that many organizations went from multiple allocations to a single allocation. If we all filter anything longer than /32, we'll rearrange the flow of traffic that many over the years have altered through longer prefixes. Even I suspect I may occasionally have to let a /40 out now and then to alter it's traffic from the rest of the aggregate. Traffic comes to you as it wants to come to you. The only pseudo remedy that currently exists is to move some prefixes over to a different path. If you only have a /32, that'll be a bit hard. This, more than anything, is what will effect this list and the people on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare we go to /48 and treat them as the new /24? I know for myself, traffic manipulation can't begin until /40 (unless I split them further apart). Jack I think we'll see this more and more. Our newest tier-1 IPv4 transit provider was the first to tell us that they don't allow deaggregation. If we were allocated /19s, we advertise /19s... Not to start another debate, but this will certainly highlight the deficiencies of the hop-by-hop, policy-based routing paradigm that all but ignores the load-balancing needs of 95% (fictitious number) of networks operating in a world which can't load-balance itself.
Re: v6 DSL / Cable modems
On Fri, Feb 6, 2009 at 8:51 AM, Jack Bates jba...@brightok.net wrote: Joe Loiacono wrote: Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big. Let's also not forget, that many organizations went from multiple allocations to a single allocation. If we all filter anything longer than /32, we'll rearrange the flow of traffic that many over the years have altered through longer prefixes. Even I suspect I may occasionally have to let a /40 out now and then to alter it's traffic from the rest of the aggregate. Traffic comes to you as it wants to come to you. The only pseudo remedy that currently exists is to move some prefixes over to a different path. If you only have a /32, that'll be a bit hard. This, more than anything, is what will effect this list and the people on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare we go to /48 and treat them as the new /24? I know for myself, traffic manipulation can't begin until /40 (unless I split them further apart). Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't. Tim:
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 6 feb 2009, at 1:15, Ricky Beam wrote: I see IPv6 address space being carved out in huge chunks for reasons that equate to little more than because the total space is inexhaustable. This is the exact same type of mis-management that plagues us from IPv4's early allocations. Think of it this way: if addresses are going to be wasted, I'll be happy to take my share an un-waste as required. For instance, there have been suggestions to move the /64 subnet boundary to /80 because 64-bit MAC addresses never took off. I'll take my /64s now and then move the boundary to /80 later so I can multiply the number of subnets that I have by 65536. This is a whole lot more pleasant that slicing and dicing that single IPv4 address in ever tinier parts as I get more stuff that runs IP in my house. (And there is a real risk that I won't even have that single IPv4 address anymore in the future but have to share one with my neighbors.) IPv6 is a whole new way of doing things. It doesn't make sense to apply IPv4 sensitivities here, just like in the middle of the ocean, water management is a different game than in the desert. You could make a fair case that 48 bits would have been sufficient for IPv6 (6/4th of 32 bits after all) and then we'd have to manage that space pretty much the same as today's IPv4 space. But it's almost three times that. you get to generate an address from a prefix through a function that gives you the same address without requiring anyone to remember that address, which is also useful. Well, it is extremely wasteful. Not really. The waste started and ended with the decison to make IPv6 addresses 128 bits. Now that you have to carry those 128 bits in all your packets, there is no additional penalty for actually using them. If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address. Manual configuration doesn't scale. With IPv4, it's quite hard to make this work with DHCP, but mostly because of a lack of IPv4 addresses. With 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. And face reality, many people have enough trouble remembering IPv4 addresses -- even when it's simplified to a /24 prefix plus 3 digit number. They will have an even harder time remembering a 48bit or 64bit MAC. Do you remember the MAC addresses of ANY of the NICs on your lan(s)? Isn't remembering stuff what we have computers for? It's not even that. Had they simply not ignored, and out-right dismissed as wrong, the way networks were being run, then we wouldn't have the mess we have today. I pick on autoconfig because it's the simplest bit of stupid on their part... we have Stateless Autoconfiguration, *jedi hand wave*, you don't need DHCP. It was bull the instant they said it. I have a lot of problems with DHCP and most people don't _need_ it. Still, very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it.
Re: v6 DSL / Cable modems
Tim Durack tdur...@gmail.com wrote on 02/06/2009 09:28:02 AM: Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't. That range alone is 25 bits of routing, equivalent to routing all the way down to /25s in the IPv4 world. But I don't see how you could route some /48s without having software to route all /48s and that is hugemongous. And then times 4 for 128 bits. But, I'm not a routing engine guy, so I'm probably missing something ... Joe
Re: v6 DSL / Cable modems
Joe Loiacono wrote: Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big. 2 times as big, if you believe that routers that need to care about table size won't do anything about what's past the /64 boundary. It still costs money. Especially since you'll also need to be carrying the v4 table for approximately forever, and it'll be deaggregating faster and faster at least for a while. Matthew Kaufman
Re: v6 DSL / Cable modems
Tim Durack wrote: Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't. The ideal solution, I believe, is to support filters of max networks advertised from origin AS. This would allow for some deaggregation with some amount of protection, even if peers are not filtering their downstreams. Not sure I've seen this level of sophistication out of IOS, though. Jack
Re: v6 DSL / Cable modems
On 6 feb 2009, at 16:02, Joe Loiacono wrote: Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't. That range alone is 25 bits of routing, equivalent to routing all the way down to /25s in the IPv4 world. But I don't see how you could route some /48s without having software to route all /48s and that is hugemongous. And then times 4 for 128 bits. But, I'm not a routing engine guy, so I'm probably missing something ... The problem is that ARIN reserves a /44 for every /48 they give out. So that means the most you'll see out of that /23 is 2M prefixes (I don't think there are many routers out there that can handle a v6 table this large) but since you need to accept /48s, this could be deaggregated into 32M prefixes. The RIRs need to stop this reservation stuff, it makes prefix length filtering impossible.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
This is straying from operational to protocol design and implementation, but as someone who has done a fair bit of both design and implementation... Iljitsch van Beijnum wrote: The problem is that DHCP seemed like a good idea at the time but it doesn't make any sense today. We know that parsing complex binary data formats is asking for security problems... Excuse me? This sounds like you've been hanging out with the SIP people for too long. The complexity of having a computer parse something like XML, or much worse, RFC822-style headers with complex rules about optional and mandatory options, a la SIP is *far* beyond what is required to parse things like DNS replies or even ASN.1. And *much* harder to generate strong proofs of correctness for. Just because it is easier to read without a decoder library installed in your sniffer doesn't mean it is more secure to parse and process. (Simple examples: binary tag/length/value formats allow immediate checking of the length to see if it is within bounds and to allocate the appropriate data structure size beforehand. With XML there's no way to know how long or deep a structure is until you've parsed the whole thing, just like with RFC822-style headers there's no way to know how long a line will be or whether or not there will be continuation lines for that tag until you've reached the next header. Which is more difficult to check for proper defense against buffer overrun attacks?) Matthew Kaufman
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)]
Five things? Really? My DHCP server hands out the following things to its clients: Default Route DNS Servers Log host Domain Name (or, our case, the sub-domain for the office) NIS Domain NIS Servers NTP Server WINS Servers SMTP Server POP Server NNTP Server Domain suffix search orders. All these useful and handy things that my Windows, Unix (Irix and Solaris), Linux, and FreeBSD clients all need some portion of, in one place where I configure and control it. Static reservations are handled here as well and it ties into the DNS servers to dynamically update forward and reverse as needed (which is rare since even non static allocations don't tend to change). Having to deal with configuration and control of this in multiple places is only going to make the sysadmins of the world hate you. I don't work in an ISP anymore, and I haven't had to deal with BGP/OSPF in almost a decade now other than for some minor internal routing, but you know what? I still have a network with several hundred hosts on it that have to be managed, and DHCP makes life easy for a large chunk of it. We're just one little piece of a larger pie. Our Corporate Overlords are eighty thousand users on seven continents with far more than a 1:1 end user to host ratio. Jamie -Original Message- From: Iljitsch van Beijnum [mailto:iljit...@muada.com] Sent: Thursday, February 05, 2009 5:42 PM To: Ricky Beam Cc: NANOG list Subject: Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)] On 5 feb 2009, at 22:44, Ricky Beam wrote: A single /64 isn't enough for a home user, because their gateway is a router and needs a different prefix at both sides. Users may also want to subnet their own network. So they need at least something like a /60. Mr. van B, your comments would be laughable if they weren't so absurdly horrific. That doesn't change the fact that users would be quite constrained by only having a /64 for their internal network. I've lived quite productively behind a single IPv4 address for nearly 15 years. So you were already doing NAT in 1994? Then you were ahead of the curve. I've run 1000 user networks that only used one IPv4 address for all of them. But how is that relevant for the discussion at hand? Is your point that if 1000 users can share an IPv4 address, 1000 users should share an IPv6 address? How would that make sense? Sharing addresses comes with significant downsides. (Like having to port map services running on hosts on the inside.) Sharing one address with 1000 active users comes with even more downsides. (There are applications that need more than 64 ports so the port number space becomes a limitation.) IPv6 was specifically designed to provide an enormous amount of address space, so accepting the limitation of using one address for a large number of users means foregoing a prime feature of IPv6--for no reason that I can see. Yet, in the new order, you're telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point? The logic is like this. 1. You need more than one. 2. You don't want to change the number often (or at all) 3. What is a number that is so large that it will always be enough? Answer: the size of a MAC address. 4. How large are MAC addresses? Answer: we have technologies that have 64-bit MAC addresses. So we use 64 bits to number subnets. Now of course that seems wasteful, but those 128-bit addresses are carried in all packets anyway, and at least with 64-bit subnet sizes you get some use out of them because you know subnets are always large enough and you get to generate an address from a prefix through a function that gives you the same address without requiring anyone to remember that address, which is also useful. Now if you want to argue that IPv6 should have had 48, 53 or 64 bit addresses, that's fine. But I have to warn you that that ship sailed almost 15 years ago. (My take: they should have been variable length.) This is the exact same bull as the /8 allocations in the early days of IPv4. Oh no. A /8 is only 16777216 addresses. A /48 for an end-user organization is 1208925819614629174706176 addresses. Or, more relavant: a /8 is almost 0.5% of the IPv4 address space. A / 48 is 0.0003% of the currently defined global unicast IPv6 address space. The idea of the connected home is still nowhere near *that* connected; It took us 15 years to get this far with IPv6. There is no IPv7 on the horizon currently, so even if we start that tomorrow we'll have to get by with IPv6 (and IPv4...) until about 2024. I'm pretty sure we'll be *that* connected by that time. no matter how many toys you have in your bathroom, it doesn't need a /96 of it's own. (which is an entire IPv4 of it's own.) Like I explained, we count 0, 1, many where the IPv6 definition of many happens to be 2^64. This is obviously
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)]
On Fri, Feb 6, 2009 at 10:22 AM, Jamie Bowden ja...@photon.com wrote: Five things? Really? My DHCP server hands out the following things to its clients: as I've said a few times now, reason #775 that autoconf is a broken and non-useful 'gadget' for network operators. There is a system today that does lots of client-conf (including the simple default-route + dns-server) called DHCP, there MUST be a similarly featured system in the 'new world order' of ipv6. This really is non-negotiable, why are people still holding out hope that autoconf is 'enough' when users and operators have so clearly said otherwise? -Chris
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be for a long time with IPv6). So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64. Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for hierarchical routing of bits past 64 is highly rare). Think of IPv6 as a 64bit network address + host address. At least for now. regards, -- Paul Jakma p...@clubi.ie p...@jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
My comment was regarding customers believing that they were going to, by default, get a statically allocated range, whatever the length. If most customers get dynamically assigned (via PD or other means) then the issue is not a major one. MMC On 06/02/2009, at 8:56 PM, Paul Jakma wrote: On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be for a long time with IPv6). So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64. Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for hierarchical routing of bits past 64 is highly rare). Think of IPv6 as a 64bit network address + host address. At least for now. regards, -- Paul Jakma p...@clubi.ie p...@jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems
The problem is that DHCP seemed like a good idea at the time but it doesn't make any sense today. We know that parsing complex binary data formats is asking for security problems. And parsing complex text data structures is better? What we need is a simple, fast, efficient way to distribute the basic information that a host needs to start sending and receiving packets and a pointer to a place where additional location dependent configuration information can be found. That would be: address+prefix, gateway and (arguably) DNS and then something like a URL for a server that has the config info. The system and applications can then load information from the config server over HTTP in XML format or some such. No, this information must be available in *one* place. It's called a DHCP server. As an operator, this is clearly what I want, both for IPv4 and IPv6. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: v6 DSL / Cable modems
sth...@nethelp.no wrote: No, this information must be available in *one* place. It's called a DHCP server. As an operator, this is clearly what I want, both for IPv4 and IPv6. DHCP is available, spec'd and implemented on some systems. However, there are times that DHCP fails (from my experience). Two routers, 2 default routes. Support for shim6 or other multiple IP protocol. 2 routers, 2 global IP's assigned to the host, different default routes, and support for backup default route to opposite router. There are lots of cool things that RA's are used for, and assigning an address is just one of them. This argument over DHCP seems to be more noise; as there's room for both, and the specs and implementations exist for both. Cable modems, in particular, have a DHCP oriented nature to them; and while there are bugs being worked out on specific implementations (according to cable operators I know), they will be using DHCP with IPv6 as well. Jack
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
I think this part of the thread is in danger of leaving the realm of operational relevance, so I will treat these as my closing arguments. On Fri, Feb 06, 2009 at 03:48:53PM +0100, Iljitsch van Beijnum wrote: It makes more sense to look at it like this. In the 1990s we had: No, I think that shopping checklist view is exactly the kind of wrong thinking that stunts the dialogue between tools and needs, and has been a cause in IPv6's current disconnect in operational reality. So no, I don't think it makes any sense to look at it like that. It makes the most sense to look at the IPv4 configuration protocols alone as a progression of tools, each built upon what was learned from the prior, and the conclusions that were determined to work best for most of the Internet's operators (neither Appletalk's nor IPX's). These conclusions were proper supersets of previously determined operational needs, and so became a pervasively deployed universal solution. This is a functioning model for tool growth. Shopping checklists only create Frankenstein monsters, stunted half-breeds that serve only their creators. RIP is a routing protocol, not an address configuration protocol. This is a statement whose context predicates that you think I don't know that, which further confers that my intended message has been lost on you. This is far afield from the point! I am predisposed not to correct this, as the message was not intended for you, I hope this is mutually agreeable. :) asking for security problems. Also, whenever you want to put something new in DHCP you must update the client and server SOFTWARE. Because on the This actually is not true, which I have told you before. But I have to admit it is a nice contrived false factoid that supports your a-priori conclusions. My analysis of your further arguments is that you have selected a proper subset of actual Internet operational needs in order to further justify these same conclusions. I will leave it at that. :) -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgp0OhzlcjfGx.pgp Description: PGP signature
Re: v6 DSL / Cable modems
DHCP items are end system considerations, not routing network considerations. The network operations staff and router configuration engineers do not generally concern themselves with end systems. End systems generally are managed quite independently from the routing network. And, they are more subject to the vagaries of day to day business variability. Note the one place in the quoted message below. The only overlap is broadcast forwarding for DHCP initiation. Besides, configuration control is hard enough for router engineers without adding the burden of changing end system requirements. Adding the forwarding entries is almost too much already! ;) So, for routing network operators to denigrate DHCP is probably due to lack of consideration of the end user system requirements. And those who denigrate DHCP and say just hard code it make end system management that much more difficult. I still conclude that DHCP is a useful tool for both IPv4 and IPv6 systems. Cutler On Feb 6, 2009, at 12:22 PM, sth...@nethelp.no wrote: The problem is that DHCP seemed like a good idea at the time but it doesn't make any sense today. We know that parsing complex binary data formats is asking for security problems. And parsing complex text data structures is better? What we need is a simple, fast, efficient way to distribute the basic information that a host needs to start sending and receiving packets and a pointer to a place where additional location dependent configuration information can be found. That would be: address +prefix, gateway and (arguably) DNS and then something like a URL for a server that has the config info. The system and applications can then load information from the config server over HTTP in XML format or some such. No, this information must be available in *one* place. It's called a DHCP server. As an operator, this is clearly what I want, both for IPv4 and IPv6. Steinar Haug, Nethelp consulting, sth...@nethelp.no James R. Cutler james.cut...@consultant.com
Re: v6 DSL / Cable modems
On Fri, Feb 06, 2009 at 11:50:55AM -0600, Jack Bates wrote: Two routers, 2 default routes. Support for shim6 or other multiple IP What most people do of course is VRRP. Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so. When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents). The net result is that the client uses the default gateway which it used to reach the DHCP server, and so will automatically receive an updated value if that router fails, as part of DHCP lease rebinding (it will reach the server via the alternate router). No need to take on 'routed -q' in the client, it can stay a simple dumb host, with all configuration complexity in the DHCP server or negotiated in HA by the routers. P.S. You can also set the DHCP server-identifier on the opposition of the giaddr field contents; so when the client reaches renewal time, if will be able to use the surviving router if its default router has failed (and thus will not have to wait for rebinding). This has further config implications as the server(s) are no longer able to detect the difference in a client's renewal or rebinding, but it can be an effective optimization. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpb1iKtLsD73.pgp Description: PGP signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Randy Bush wrote: Wii should not even consider developing a cool new protocol for the Wii that is not NAT compliant via V4 or V6. what is nat compliant? RFC 3235 discusses how to make your application work in the Internet reality that exists today, with NAT boxes everywhere. The document is entitled, Network Address Translator (NAT)-Friendly Application Design Guidelines. http://www.ietf.org/rfc/rfc3235.txt This was a product of the IETF NAT Working Group, published in 2002. Note though that this document provides guidance, not compliancy requirements. Nonetheless, application developers can find useful information on how to avoid problems. -- - Daniel Senied...@senie.com Amaranth Networks Inc.http://www.amaranth.com Kindness in words creates confidence. Kindness in thinking creates profoundness. Kindness in giving creates love. -- Lao Tsu
Re: v6 DSL / Cable modems
David W. Hankins wrote: What most people do of course is VRRP. I agree, and I have done this in the past. However, I am very happy with the support of IPv6 to do away with requiring VRRP. Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so. Always a problem, though arp doesn't timeout when a end node disappears in a reasonable fashion. When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents). This is a nice method as well, though limited by the half life of the DHCP lease. It also doesn't address the fact that you might be handing out IP addresses from *both* DHCP relay agents with cross redundancy for gateways. No need to take on 'routed -q' in the client, it can stay a simple dumb host, with all configuration complexity in the DHCP server or negotiated in HA by the routers. Dumb hosts is exactly what makes life infuriating. I want smart hosts. The network should be relatively dumb. Perhaps I'm mistaken, but the premise of IP was that hosts are smart and networks are dumb. Then we started making smart networks to break things. I want built in multiple IP bindings on my hosts. I'd like (Windows 7 without having to call netsh, perhaps?) support for static and dynamic addresses (privacy extensions are beautiful). I especially want support for multiple dynamic addresses with communication to the host that it should start using a newer address for future requests, yet finish up what it's doing with the old address before unbonding it. Please don't get me wrong. I don't run a corporate network. I have my own little server farm and I have support to edge customers. What customer's do with the prefixes I give them is up to them. DHCP/SLAAC, it's all good. I'd rather not run DHCP for my servers or my little helpdesk network. On a standard ISP edge, I expect to see hybrid solutions; depending on the layout. Jack
Re: v6 DSL / Cable modems
On Feb 6, 2009, at 12:37 PM, Jack Bates wrote: David W. Hankins wrote: What most people do of course is VRRP. I agree, and I have done this in the past. However, I am very happy with the support of IPv6 to do away with requiring VRRP. If RA does that in your situation, great. In my situation, there are actually cases where I need different VRRP groups on the same LAN and need to point different things at different routers from hosts. It would be nice if DHCPv6 (or DHCPv4 for that matter) could include not only a default, but, a static routing table in what it distributes. Nonetheless, the built in assumption in IPv6 RA that all routers are equal is simply not valid in all environments and VRRP with DHCP provides some ability to cope in environments where that isn't true. Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so. Always a problem, though arp doesn't timeout when a end node disappears in a reasonable fashion. Some OS handle this better than others. Try, wait, try, wait, re-arp, wait, fall over to other gateway -- 9 sec. delay in some situations. When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents). This is a nice method as well, though limited by the half life of the DHCP lease. It also doesn't address the fact that you might be handing out IP addresses from *both* DHCP relay agents with cross redundancy for gateways. I'm not sure what you mean by that. No need to take on 'routed -q' in the client, it can stay a simple dumb host, with all configuration complexity in the DHCP server or negotiated in HA by the routers. Dumb hosts is exactly what makes life infuriating. I want smart hosts. The network should be relatively dumb. Perhaps I'm mistaken, but the premise of IP was that hosts are smart and networks are dumb. Then we started making smart networks to break things. That's great on paper, but, in some real world scenarios, it's not as supportable as one might want. The best thing is if both are smart in helpful ways and are willing to be told not to out-smart themselves in environments where that is counterproductive. I want built in multiple IP bindings on my hosts. I'd like (Windows 7 without having to call netsh, perhaps?) support for static and dynamic addresses (privacy extensions are beautiful). I especially want support for multiple dynamic addresses with communication to the host that it should start using a newer address for future requests, yet finish up what it's doing with the old address before unbonding it. Could you please explain a good reliable method for source address selection in a multiple IP binding scenario? That last one is available albeit really hard to support in any sort of scale. Please don't get me wrong. I don't run a corporate network. I have my own little server farm and I have support to edge customers. What customer's do with the prefixes I give them is up to them. DHCP/ SLAAC, it's all good. I'd rather not run DHCP for my servers or my little helpdesk network. On a standard ISP edge, I expect to see hybrid solutions; depending on the layout. I don't know very many people who want DHCP for servers. However, when you're managing a bunch of user's desktops and laptops, DHCP is the only way to scale things reasonably in some environments. Owen
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Roger Marquis wrote: Seth Mattinen wrote: Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall. NAT provides some security, often enough to make a firewall unnecessary. It all depends on what's inside the edge device. But really, I've never heard anyone seriously equate a simple NAT device with a firewall. You must be very sheltered. Most end users, even security folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on security through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Stephen Sprunk wrote: You must be very sheltered. Most end users, even security folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on security through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users. At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream. (In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/insert favourite fw is for enterprise). MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Feb 6, 2009, at 7:06 PM, Matthew Moyle-Croft wrote: Stephen Sprunk wrote: You must be very sheltered. Most end users, even security folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on security through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users. At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream. IPTables is decent firewall code. It's free. I don't buy that argument for a second. Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code. Owen (In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/insert favourite fw is for enterprise). MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Tell ya what Owen, When you can show me residential grade CPE which has a DECENT stateful firewall then PLEASE let me know. Needs to do other things well, not crash, not cost hundreds of dollars, supportable, does VOIP, WIFI etc are manufacturer supported etc. Of course, it needs to do IPv6 as well. (it's easy to say Owen, but quite frankly, the reality from my side of the fence as an operator is that it's not the norm). MMC On 07/02/2009, at 2:02 PM, Owen DeLong wrote: IPTables is decent firewall code. It's free. I don't buy that argument for a second. Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code. Owen
Re: v6 DSL / Cable modems
On 7/02/2009, at 10:29 AM, David W. Hankins wrote: I want built in multiple IP bindings on my hosts. I'd like (Windows 7 I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents). I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. The RA message tells the host either here is a prefix, number yourself out of it or go to the DHCPv6 server to get an address. OS implementation here is identical - one does not configure a host to listen for RA messages or to request addresses from DHCPv6, the host *always* listens for RA messages. Changing from SLAAC to DHCPv6 based address assignment only requires touching the router sending the RA messages. -- Nathan Ward
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 6/02/2009, at 12:00 PM, Joe Maimon wrote: This assignment policy is NOT enough for every particle of sand on earth, which is what I thought we were getting. There is enough for 3616 /64s, or 14 /56s per square centimetre of the earth's surface, modulo whatever we have set aside for multicast and non globally scoped unicast addresses and so on. If we pretend that hosts are only going to be on the area that is land, that gives us 12385 /64s, or 48 /56s per square centimetre. My suspicion is that before we get to a place where we have 48 humans per sq cm of land, we will run out of food. -- Nathan Ward
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 6/02/2009, at 1:01 PM, David W. Hankins wrote: On Thu, Feb 05, 2009 at 05:12:19PM -0600, Jack Bates wrote: Operationally, this has been met from my experience. In fact, all of these items are handled with stateless DHCPv6 in coordination with SLAAC. Stateful DHCPv6 seems to be limited with some vendors, but unless they plan to do proxy-nd, I'm not sure they'll gain much except for end system compatibility. SLAAC fails in the end because you cannot predict what address the client will choose. So it fails in scenarios where enforcing network policy is important. It works fine, you set the additional information flag, and the host goes to the DHCPv6 server and you can now do whatever dynamic network policy you want. This might break with privacy extensions, I'm not sure. I'm a bit confused though - do you consider it to be a good idea to set network policy differently for multiple hosts on a single broadcast domain? There are some people that do that, but as Randy would say, it is something that I would encourage my competitors to do. -- Nathan Ward
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Feb 4, 2009, at 6:19 PM, Leo Bicknell wrote: In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew Moyle-Croft wrote: My FEAR is that people (customers) are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that. Customers don't want static addresses. I completely disagree. They want DNS that works, with their own domain names, forward and reverse. That's also necessary, but, it's not the full solution. They want renumbering events to be infrequent, and announced in advance. You need to define infrequent. Renumbering more than once a decade would be problematic and costly for me. There are lots of places where my static address is known in configurations that I do not necessarily control and getting those places all updated in sync. with some providers arbitrary change is, well, problematic. Sure, most customers aren't quite in that situation, but, more and more having to have your specific IP added to some firewall somewhere (or more than one) is a valid concern. With IPv6, this challenge will increase, not decrease. As such, I don't see non-static addresses meeting everyone's needs. They want the box the cable/dsl/fios provider to actually work, that is be able to do really simple stuff without having to buy another stupid box to put behind it. There is that, yes. None of these require static, and in fact I'd think it would be easier to get it right than it would be to do statics for most providers. But, I must be wrong, since the only solution virtually every provider offers is to move up to a static IP. Actually, statics aren't any harder than dynamics if you do your providing right. In IPv4, statics are complicated by the fact that there is a shortage of addresses and so providers try to recycle. However, in always on broadband services, statics really don't take any more effort if the provider does decent planning, and, providers seem to be able to get away with charging huge premiums for them. I doubt providers could charge huge premiums for just making the basic stuff work, and, they seem to get paid anyway without doing so. (*note, Comcast is not getting paid by me pending them actually getting some things right, but, I seem to be the exception, not the rule). Owen
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Wed, 4 Feb 2009, Roger Marquis wrote: Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network engineers will be interested in the rational behind statements like: * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what it saves consumers, ILECs, or ISPs?) Yes it cost more money in OPEX. Try to detect malicious host behind a NAT among thousand of hosts. * NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?) Yes. One of my colleague, who participated in development of RFC 1918 confirmed it. * NAT disadvantage #4: It requires more renumbering to join conflicting RFC1918 subnets than would IPv6 to change ISPs. (got stats?) This statement is true: Currently you encounter more private address usage than IPv6 usage. * NAT disadvantage #5: it provides no real security. (even if it were true this could not, logically, be a disadvantage) It is true. Lots of administrator behind the NAT thinks, that because of the NAT they can run a poor, careless software update process. Majority of the malware infection is coming from application insecurity. This cannot be prevented by NAT! OTOH, the claimed advantages of NAT do seem to hold water somewhat better: * NAT advantage #1: it protects consumers from vendor (network provider) lock-in. Use PI address and multi homing. * NAT advantage #2: it protects consumers from add-on fees for addresses space. (ISPs and ARIN, APNIC, ...) No free lunch. Or use IPv6. * NAT advantage #3: it prevents upstreams from limiting consumers' internal address space. (will anyone need more than a /48, to be asked in 2018) You can gen more /48, or use ULA. * NAT advantage #4: it requires new (and old) protocols to adhere to the ISO seven layer model. This statement is a bullshit. * NAT advantage #5: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft netbios), and other malicious inbound traffic. Same, if your implement proper firewall filtering. Best Regards, Janos Mohacsi
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Scott Howard wrote: And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... No, it's because neither need to do it. If they did the apparent catch-22 would be fixed Matthew Moyle-Croft wrote: As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? We have ADSL users with v4 and v6, they mostly use low end Ciscos, 837 and such (cheap on ebay so for the tech user base it's not too hard) Cheap retail CPE adding v6 by default would help. James W. Laferriere wrote: Hello Matthew , See way below ... It's not so far if you don't quote the entire message I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . The thread seemed long and noisy enough already without everyone doing a me too. We did it, to see if we could and because we have like minded users wanting access. I know there are others. brandon
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!). Indeed, that is a big part of the problem in the home-user space. There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience. To be fair, some of those yammering work with/for enterprises/agencies/etc. that have done this; home users are not the only ones on the Internet ...
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Feb 5, 2009, at 7:41 AM, TJ wrote: It doesn't solve the problem of an enterprise with more than one location/network-interconnect... we can go around this rose bush again and again and again, but honestly, deployment of v6 happens for real when there is a significant business reason to deploy it, and when the real concerns of enterprises today are actually addressed. Indeed, and the IETF's answer for multi-homing (SHIM6) is a non- starter for the majority of those interested in doing so. Enter PI space, now available from (most of) your local RIR(s). Yes, also enter DFZ growth ... That is an answer, not the answer. You might be interested in the discussion around LISP (routing, not language). http://www.ietf.org/mail-archive/web/lisp/current/msg00070.html https://www.ietf.org/mailman/listinfo/lisp Regards Marshall
