Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message , "Ricky Beam" writes: > On Mon, 09 Feb 2009 21:11:50 -0500, TJ 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
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 C&A 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 C&A 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 C&A work will need to be re-done". /John
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 (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)]
>> 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 Mon, 09 Feb 2009 21:11:50 -0500, TJ 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
>> 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 C&A auditors are not checking for IPv6-based vulnerabilities. They do not understand the process or have the tools to do IPv6 C&A. * 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 C&A 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 C&A. That costs money, therefore doesn't happen - atleast not "soon". Therefore, no IPv6. I would love to hear more from those who have done C&A (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 C&A (or perhaps your CTO (Certificate To Operate)) is >> invalid). > >Sure... change your network, and you need to update your C&A 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 C&A work will need to be re-done
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 C&A (or perhaps your CTO (Certificate To Operate)) is invalid). Sure... change your network, and you need to update your C&A 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
>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
>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
>> >> > 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 run IPv6 either. (In other words (again, generally speaking) - if you run IPv6, your current C&A (or perhaps your CTO (Certificate To Operate)) is invalid).
Re: Private use of non-RFC1918 IP space
Just for the record, the original post was in reference to use of non-RFC1918 space on an *air-gapped* network. --Trey >> Let's face it - they're going to have to come up with much more creative >> $200/hour chucklehead consultants to burn through that much anytime soon. >> Anybody feel like starting a pool for when we'll see a posting to NANOG about somebody who's managed to burn through a /32? ++++ Kingfisher Operations Trey Darley - Principal
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
>> 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
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
On Mon, 9 Feb 2009, Ricky Beam wrote:
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk
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 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 [was: Private use of non-RFC1918 IP space
On Mon, Feb 9, 2009 at 9:54 PM, John Osmon 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
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" 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 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 (IPv6-MW)]
On Mon, Feb 9, 2009 at 9:47 PM, TJ 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
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
>> 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
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
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 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 (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
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
>> >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
John Peach wrote: > > On Mon, 9 Feb 2009 21:16:49 -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. 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 (IPv6-MW)]
On Mon, Feb 9, 2009 at 6:16 PM, Ricky Beam wrote: > On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum > 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
On Mon, 9 Feb 2009 21:16:49 -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. > > -- John
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
> 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)]
>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
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
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: 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
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
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
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
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 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
Ricky Beam wrote:
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk
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 (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 (IPv6-MW)]
On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum 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
On Feb 9, 2009, at 2:11 PM, Ricky Beam wrote:
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk
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 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 (IPv6-MW)]
On Sat, Feb 7, 2009 at 5:56 PM, Matthew Moyle-Croft wrote: > 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
Ricky Beam wrote:
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk
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
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk
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
On Fri, 06 Feb 2009 22:32:10 -0500, Owen DeLong 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 (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 [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: Private use of non-RFC1918 IP space
On Sun, Feb 8, 2009 at 11:42 PM, Joel Jaeggli wrote: > FD00::/8 > > ula-l rfc 4139 s/4139/4193/ -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Private use of non-RFC1918 IP space
Skeeve Stevens wrote: > Owned by an ISP? It isn't much different than it is now. > > As long as you are multi-homed you can get a small allocation (/48), > APNIC and ARIN have procedures for this. > > Yes, you have to pay for it, but the addresses will be yours, unlike > the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share > and hope we never interconnect/overlap. > > I can't find a RFC1918 equivalent for v6 with the exception of > 2001:0DB8::/32# which is the ranges that has been assigned for > documentation use and is considered to NEVER be routable. In that > /32 are 65536 /48's... way more than the RFC1918 we have now. FD00::/8 ula-l rfc 4139 > If I was going to build a v6 network right now, that was purely > private and never* going to hit the internet, and I could not afford > to be a NIC member or pay the fees... then I would be using the > ranges above I wonder if that will start a flame war *puts on > fire suit*.
Re: Private use of non-RFC1918 IP space
valdis.kletni...@vt.edu wrote: > On Tue, 03 Feb 2009 11:25:40 +0900, Randy Bush said: >>> Not quite.. >>> 2^96 = 79228162514264337593543950336 >>> 2^128-2^32 = 340282366920938463463374607427473244160 >> not quite. let's posit 42 devices on the average lan segment >> (ymmv). >> >> 42*(2^64) = 774763251095801167872 > > Let's face it - they're going to have to come up with much more creative > $200/hour chucklehead consultants to burn through that much anytime soon. > Anybody feel like starting a pool for when we'll see a posting to NANOG > about somebody who's managed to burn through a /32? two of them will separately just assign fc00::/7 to a network instead of following the instructions.
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)]
On Fri, Feb 6, 2009 at 7:12 PM, Matthew Moyle-Croft wrote: > Jack Bates wrote: > > Dynamic or static; how does this alter the state of the routing table?... > Dynamic assigned addresses mean that the BRAS the customer terminates on can > hand out a range out of a pool assigned to it. This means I can have a > single route in my routing table for a whole BRAS (maybe 20k customers) vs > 20k routes and associated processing when the dsl goes up/down/etc. 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. You've got pretty much the same sized bunch of addresses and subnets regardless of how you're assigning them (except in rare cases where you're getting some statistical gain from lightly-loaded dynamic address pools), and while static addresses make it easier to use a dynamic routing protocol instead of static routing, you don't have to, or you can optionally use a dynamic routing protocol to hand routing information to the end users and then summarize at/above your BRAS. In the ipv4 world, you'd be advertising 1.2.0.0/15 either way, or a /12 if you're handing out /29s to your users instead of /32s; in the ipv6 world you'd be advertising 1337::0/39 if you're giving them /56s or 1337::0/47 if you're giving them /64s. The real difference is that if they have a static address (and can therefore advertise it with DNS easily without resorting to dynamic-DNS trickery), they may start to serve web pages, and then want to do so reliably, and then start multihoming, and then want a routing protocol to do better routing, and then either you'll need to do real work, or else you'll need to tell them to get a real circuit for their server instead of broadband, or else you'll need to tell them to use tunnels over the broadband so it's not your DSLAM/BRAS's problem. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
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/ 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 [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 [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. Super, great and wonderful. Keep doing so. But I think Iljitsch's point is that I shouldn't have to run DHCPv6 when I can get everything I need from SLAAC. In other words, what is wrong with having two complimentary pieces: Router: Sends out RAs, gets hosts a default gateway ... and maybe a prefix ... and maybe a DNS server DHCPv6: Hands out other information (DNS server) and maybe addresses upon request from host >Having to deal with configuration and control of this in multiple places is >only going to make the sysadmins of the world hate you. Sorry, are your routers not getting any sort of configuration now? If it is a Cisco box once you give that Ethernet interface an address it will send out RAs by default, no extra work. In fact, less work - you don't need to configure your DHCPv6 server with the default gateway addresses of every subnet.
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 [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 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
Tell ya what Owen, When you can show me residential grade CPE which has a DECENT stateful firewall then PLEASE let me know. Needs to do other things well, not crash, not cost hundreds of dollars, supportable, does VOIP, WIFI etc are manufacturer supported etc. Of course, it needs to do IPv6 as well. (it's easy to say Owen, but quite frankly, the reality from my side of the fence as an operator is that it's not the norm). MMC On 07/02/2009, at 2:02 PM, Owen DeLong wrote: IPTables is decent firewall code. It's free. I don't buy that argument for a second. Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code. Owen
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
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/ 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 (IPv6-MW)]
Jack Bates wrote: 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. Dynamic assigned addresses mean that the BRAS the customer terminates on can hand out a range out of a pool assigned to it. This means I can have a single route in my routing table for a whole BRAS (maybe 20k customers) vs 20k routes and associated processing when the dsl goes up/down/etc. 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. My car is designed to go 200km/hr or more. But the roads are implemented poorly. IPv6 is design to do everything for everyone, but the reality is the implementations aren't there or it's not practical. Mobile just creates more mess, I'm trying to make this simple and make it work. 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
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/ 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 (IPv6-MW)]
Joe Abley wrote: On 4-Feb-2009, at 16:16, Patrick W. Gilmore wrote: I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem. All the advice I have heard about address assignment to broadband subscribers is to give each subscriber a /56, in addition to the link address (which is effectively a /128). The last time I looked, the v6 allocation of every RIR apart from ARIN recommended a /48 instead of a /56. I'm not sure that that counts as "advice". Current ARIN policy takes no position as to which ISPs should do. IIRC, the /56 allowance came at the behest of a particular cable ISP that wanted to assign addresses to every home passed, whether or not the residents signed up for service, but did not want to pay for the /24 or so that would be required if they were handing out /48s -- if ARIN would even accept that flimsy justification. I can understand the technical benefits of pre-assignment, and I would have preferred that the policy (and fee schedule) were amended to better handle that case. I have been specifically advised against assigning a /64 per subscriber on the grounds that it is short-sighted, since v6 residential gateways, when they come in large numbers, will expect to be able to assign addresses to more than one subnet in the customer network. ... which could be handled by giving out additional /64s via DHCP PD. I would expect the majority of customers to need no more than two or perhaps three subnets, with a huge fraction of that needing only one (not including the /127 to the CPE device). I suspect that for many regional ISPs a single allocation sufficient to number 16 million customers is probably good enough. In Canada, for example, that's half the total population, and probably larger than the total number of residences. No doubt there are a countable and significant number of super-ISPs in larger markets (or spanning multiple markets) that have requirements that out-strip that of a single /32, but I feel comfortable predicting that they are the minority in the grand scheme of things (and in any case, they can always request a larger allocation). More importantly, we can see that in Europe, RIPE has been perfectly willing to hand out enormous allocations to such mega-ISPs. A few in the US have also gotten larger-than-/32 allocations, and IMHO that is the "correct" route, not shrinking the size of customer assignments. There are more than enough prefixes to go around in the minuscule part of the IPv6 space we're currently using. The real concerns should be (a) how we keep the number of prefixes per AS as close to 1.00 as possible, and (b) how to deal with the explosion in the number of ASes due to multihomed leaf sites. However, those problems are much harder, so some engineers are looking at how to solve problems that we already know how to solve "successfully" but don't actually matter. 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
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 (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 [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. Hankins"If 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 [was: Private use of non-RFC1918 IP space(IPv6-MW)]
On Fri, Feb 6, 2009 at 10:22 AM, Jamie Bowden 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)]
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
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)]
On 6 feb 2009, at 0:55, David W. Hankins wrote: Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from here is "rarp". DCHP does far more than tell a host was address it should use. Actually it goes further back than rarp; IPv6 RA is actually more closely related to IPv4 ICMP Router Advertisements It makes more sense to look at it like this. In the 1990s we had: - IPv4: manual configuration - IPv4: DHCP - IPX: router advertised network prefix + MAC address - AppleTalk: router advertised network prefix + random number IPv6 gives us all of these. Let's just say it's a slightly restricted (feature-limited?) RIP. RIP is a routing protocol, not an address configuration protocol. But yeah, in that the static->RARP->BOOTP->DHCP progression was a dialogue between operators and IETF, IPv6 has basically thrown that dialogue out with the bathwater, and we're having it all over again. 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. Also, whenever you want to put something new in DHCP you must update the client and server SOFTWARE. Because on the clients, address configuration is a very fundamental thing, this is something buried deep inside the system where it's hard to make changes by anyone other than the OS vendor. 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.
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 [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.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
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 [was: Private use of non-RFC1918 IP space (IPv6-MW)]
My comment was regarding customers believing that they were going to, by default, get a statically allocated range, whatever the length. If most customers get dynamically assigned (via PD or other means) then the issue is not a major one. MMC On 06/02/2009, at 8:56 PM, Paul Jakma wrote: On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be "for a long time" with IPv6). So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64. Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for "hierarchical routing of bits past 64 is highly rare"). Think of IPv6 as a 64bit network address + host address. At least for now. regards, -- Paul Jakma p...@clubi.ie p...@jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (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)]
"David W. Hankins" 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 [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)]
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
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?" Quite unfortunately, that has come to mean something. Specifically, TCP or UDP (and no other IP protocol numbers) and application protocols that don't depend on their locally-derived host addresses as having any meaning to anyone else. Or, in other words, "whatever the NAT maker thought was enough in order to sell boxes", which mostly means "you can look up addresses in the DNS and open http and https connections to them, and if you're lucky some of your gaming and video streaming will work too". Matthew Kaufman
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
> 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?" randy
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 5 Feb 2009, Ricky Beam wrote: telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point? You have more computing power in your house than the Fortune 500 did 40 years ago to manage their entire billing, payroll etc. They had thousands of people and paid millions of dollars per year just to make sure that scarce resource was not wasted. You use it for watching TV shows and browsing the web a few hours per day. As others have pointed out giving every person on the planet a /56 and every business a /48 is only going to take up 0.01% of the total IP space. Allocating 0.01% of space to an "experiment in abundance" which will probably turn out to be enough space than will ever be needed this century seems a good risk to me. Sure we could have allocated just 0.1% of space to the experiment instead but then plug-and-play might not work out of the box or people would have to apply and pay for larger network spaces or I'd only get one network in my house ( and never get my SIP phone to work cause of NAT ). You may find this article interesting ( especially the first page ): "The sysadmin’s mantra: Manage time, think ‘abundance’ and softly does it" http://www.computerworld.com.au/article/272429/sysadmin_mantra_manage_time_think_abundance_softly_does_it -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
>So it fails in scenarios where enforcing network policy is important. If the policy is address specific, perhaps. If the policy is segment specific, no prob. /TJ PS - for emphasis, I am not arguing strictly for or against either SLAAC or DHCPv6. Both can work, and IMHO should be allowed to do so where desirable.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
George William Herbert wrote: Perhaps there are better ways to do all of this from the start. But IPv6 is not helping any of the ways we have evolved to deal with it. IPv6 does just fine with dynamic addressing and with static addressing. I'm not sure what your problem is. An ISP can still assign static addressing, and in fact, most ISP layouts will be *more* static than they were with IPv4. However, it will depend on their implementations and what they want. As was explained to me, there were many BIG providers definitely putting their $0.02 in concerning IPv6. That's actually where full blown IPv6 comes in, btw. Something to do with DOCSIS from what I understand; though that's way out of the scope of my telco self. I play with copper. Jack
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, Feb 05, 2009 at 04:30:12PM -0800, Joe Abley wrote: > The particular example I've been working with is with a JUNOSe server and > an IOS client which, as a solution for business DSL service, seems > deployable. Yes! Sorry, I just try to emit a little more skepticism about pervasive client support for DHCPv6 in jubliant encouragements of DHCPv6 operational experiments and deployment. >> [...] Joe is not entirely wrong. > > Hooray! :-) I am seriously considering admitting I know you. :) -- David W. Hankins"If 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 pgpnAIGUo35fd.pgp Description: PGP signature
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Leo writes: >Customers don't want static addresses. > >They want DNS that works, with their own domain names, forward and >reverse. > >They want renumbering events to be infrequent, and announced in >advance. > >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. > >None of these require static, and in fact I'd think it would be >easier to get it right than it would be to do statics for most >providers. But, I must be wrong, since the only solution virtually >every provider offers is to "move up" to "a static IP". I'm one of the geeky fringe here, obviously, but it's hard for my nameservers at home to not be static IPed be it IPv4 or v6. There are plenty of possible solutions, but they all involve more effort by the ISP or DNS provider... I and they can put in that effort, but just provisioning me statics is a lot easier, and that's what everyone has done so far. Nothing about the IPv6 transition on the transport end changes the provisioning effort / logistics / technical support difficulty issues associated with this. If you believe that geek houses are enough of an outlier to not worry about, consider the million or so internet connected small businesses who do their own DNS... Perhaps there are better ways to do all of this from the start. But IPv6 is not helping any of the ways we have evolved to deal with it. Perhaps it's time for some actual network operators and equipment vendors to go talk on the side about IPv7 and making our lives easier rather than harder. I urge everyone who is involved in the back-room "bring tar and feathers to next IETF meeting" discussions to do this instead. I really don't care how many bits are wasted on what - I want DNS, routing, endpoint mobility, multihoming, NAT, et al to work. If that means bigger packets or wasted address space so be it. We have pipe bandwidth and Moore's Law growth to work with here. Having to patch the net together for the next decade with baling wire and string because a bunch of non-operators got to set IPv6 up to be a more perfect way forward is not scaling. And 20 years between protocol design and rollout is absurd and insulting. -george william herbert gherb...@retro.com
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Fri, Feb 06, 2009 at 11:36:25AM +1100, 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. Amen brother Mark! Can I get a hallelujah from the chorus? (Meanwhile, I'll continue to leave my Wii outside of the trusted MAC address pool in DHCP -- so it'll get an RFC-1918 address, rather the a holy "true" IP.)
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
This is falling outside of the IPv6/RFC-1918 discussion, so I'll only answer questions with questions... If there's need for a real discussion, I'll let someone change the subject, and continue on... On Fri, Feb 06, 2009 at 01:11:13AM +0100, Sven-Haegar Koch wrote: [...] > > The flip side shows up when Nintendo creates a cool new protocol for the Wii > > that requires Internet access. You Wii won't be able to participate > > until you teach your proxy/NAT box about the new protocol. > > What's the difference to firewalling without NAT? (Noone should connect > their (home) network without at least inbound filtering) There I have to > wait for the firewall box to support connection tracking for the new > (broken) protocol. Why do I need an "Internet breaker" (firewall) to do connection tracking? Doesn't the host computer's software stack do that when an inbound packet arrives? Why do I need a separate box to do that work with I trust my host? > If the end-users really get public addresses for their WII and game-PCs, > do you really think they won't just open the box totally in their > firewall/router and catch/create even more problems? That's an issue of trusting the host... Note: All questions are hypothetical. No packets were harmed in the production of this hyperbolic response...
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message , Sven-Haegar Ko ch writes: > If the end-users really get public addresses for their WII and game-PCs, > do you really think they won't just open the box totally in their > firewall/router and catch/create even more problems? You mean they don't already list as the DMZ address. :-) WII's should be able to be directly connected to the network without any firewall. If they can't be then they are broken. > c'ya > sven -- 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 5-Feb-2009, at 16:14, David W. Hankins wrote: The truth is it is actually not very likely that you can build an IPv6 network today using DHCPv6, unless you have large populations of those systems. The particular example I've been working with is with a JUNOSe server and an IOS client which, as a solution for business DSL service, seems deployable. [...] Joe is not entirely wrong. Hooray! :-) Joe
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Feb 5, 2009, at 11:06 AM, Joe Abley wrote: On 5-Feb-2009, at 06:34, Christopher Morrow wrote: to be fair, there are 3 options for multihoming today in v6 (three sanctioned by the IETF, not ordered in any order, not including discussion about goodness/badness/oh-god-no-ness of these) 1) multiple addresses on each device, one per provider 2) shim-6 3) HIP (still in development, as I recall) 4) Obtain PA space and do what you're doing with v4. 5) Obtain PI space and do what you're doing with v4. (4) is problematic because filtering long prefixes in v6 seems to be more energetic than it is in v4. (5) is problematic if you don't qualify for PI space. Note, however, that the bar for (5) is VERY low if you are multi-homed. I would not be opposed to lowering it even further, but, there does not at this time seem to be community consensus to do so. Owen
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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. While I am ranting, my other pet peeve are proprietary protocols that the developer cannot take another couple of hours to provide a decoder for. If you develop the protocol any of the developers at the Wireshark group would help with the decode plugin. Robert D. Scott rob...@ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -Original Message- From: Sven-Haegar Koch [mailto:hae...@sdinet.de] Sent: Thursday, February 05, 2009 7:11 PM To: John Osmon Cc: NANOG list Subject: Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] On Thu, 5 Feb 2009, John Osmon wrote: > On Thu, Feb 05, 2009 at 04:44:58PM -0500, Ricky Beam wrote: > > [...] I've lived quite productively behind a single IPv4 address for > > nearly 15 years. I've run 1000 user networks that only used one IPv4 > > address for all of them. I have 2 private /24's using a single public > > IPv4 address right now -- as they have been for 6+ years. 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? > > Thank you. Your ability to live with proxied/NATed Internet access has > helped stave off the problems we're seeing now. > > The flip side shows up when Nintendo creates a cool new protocol for the Wii > that requires Internet access. You Wii won't be able to participate > until you teach your proxy/NAT box about the new protocol. What's the difference to firewalling without NAT? (Noone should connect their (home) network without at least inbound filtering) There I have to wait for the firewall box to support connection tracking for the new (broken) protocol. If the end-users really get public addresses for their WII and game-PCs, do you really think they won't just open the box totally in their firewall/router and catch/create even more problems? c'ya sven -- The lights are fading out, once more...
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 05 Feb 2009 17:42:27 -0500, Iljitsch van Beijnum 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. "NAT" didn't exist in '94. But, Yes. And, Yes. I had several computers networked behind one with a dialup (PPP) connection. And, as you'd expect, it was messy. 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? The point is... even large enterprises don't *need* 18 billion, billion addresses to get anything done. 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. Now of course that seems wasteful, ... 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. Well, it is extremely wasteful. 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. We do that already with IPv4. Why do we need to waste so much space with such a sparse address plan? We don't. But since IPv6 is H.U.G.E., "might as well." 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)? This is the exact same bull as the /8 allocations in the early days of IPv4. Oh no. ... Yes. It. Is. We have this incomprehensibly huge address space that we cannot possibly, EVER, use up, so let's divide it on ridiculously huge boundries. 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. I'm not. I'll be very surprised if IPv6 has been universally adopted by then. I'm not sure we'll be completely out of IPv4 space by then. IPv6 changes too much but it doesn't fix enough. 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. You don't use DHCP. Well, good for you. There are hunreds of thousands of people who do. We appreciate you telling us we don't need the technology we need. (It's the "I don't use it so nobody else needs to, either" attitude that has given us a whole bunch of things to re-invent for IPv6.) --Ricky
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, Feb 05, 2009 at 06:15:02PM -0500, Ricky Beam wrote: >> You might like to review the DHCPv6 specification and try some of its >> implementations. Joe is being a little overzealous. Unfortunately, there are very few DHCPv6 clients in the wild today. I think this has grown slightly since the last time I've had good information on it; Windows Vista, DOCSIS 3.0, Solaris and other platform specific unixes (unsure of all the right names and versions). Most free unixes have to be manhandled to install a client. The truth is it is actually not very likely that you can build an IPv6 network today using DHCPv6, unless you have large populations of those systems. Most IPv6 deployments today use SLAAC to get an address, and rely upon DHCPv4 to deliver configuration state (even IETF meetings do this). Still, it isn't bad to have a DHCPv6 server running to hand out some IPv6 addresses for configuration state now and again, so Joe is not entirely wrong. > I can recall many posts over the years from the IPng WG telling people they > didn't need DHCP. There is no need to recall! Subscribe to any IETF mailing list, and be assured you will still hear the same thing. -- David W. Hankins"If 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 pgpcpPI6Ekg8x.pgp Description: PGP signature
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 5 Feb 2009, John Osmon wrote: > On Thu, Feb 05, 2009 at 04:44:58PM -0500, Ricky Beam wrote: > > [...] I've lived quite productively behind a single IPv4 address for > > nearly 15 years. I've run 1000 user networks that only used one IPv4 > > address for all of them. I have 2 private /24's using a single public > > IPv4 address right now -- as they have been for 6+ years. 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? > > Thank you. Your ability to live with proxied/NATed Internet access has > helped stave off the problems we're seeing now. > > The flip side shows up when Nintendo creates a cool new protocol for the Wii > that requires Internet access. You Wii won't be able to participate > until you teach your proxy/NAT box about the new protocol. What's the difference to firewalling without NAT? (Noone should connect their (home) network without at least inbound filtering) There I have to wait for the firewall box to support connection tracking for the new (broken) protocol. If the end-users really get public addresses for their WII and game-PCs, do you really think they won't just open the box totally in their firewall/router and catch/create even more problems? c'ya sven -- The lights are fading out, once more...
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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. The point of the excercise is that DHCPv4 and DHCPv6 are both supersets of network management needs. RA is a vast subset. Herein lies the rub; you have to implement both anyway because a client can not predict what network(s) it is going to be used in. Nobody wins. -- David W. Hankins"If 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 pgp31Zvpm3F9i.pgp Description: PGP signature
