Re: Why IPv6 is a must?
Caitlin Bestler wrote: > > > > 3) new devices that plug into residential networks (mostly new) > > > > > > What stops the new devices from having v4 with NAT to translate between the > > > internet and the house. > > > > nothing stops them, but if you want to access the devices from outside the > > house (and in many cases that's the point of such devices) then NAT gets > > in the way. > > > > Keith > > > > That's exactly why you want NAT/firewalling and other existing mechanisms. > These are devices that do not require global addressability. In fact they > SHOULD NOT be globally addressable. > "SHOULD NOT be globally addressable"? Every conceivable device in the home? That's quite a broad policy to impose on home networks. I draw two distinctions: - firewalling is a technology designed to implement policy - NAT is intended to enable connectivity It is quite possible for globally addressable IPv6 devices to be firewalled according to some policy, i.e. IPv6 supports *both* global connectivity and security of the firewalling variety. > IPv6 needs to be justified on the number of nodes that truly need a > globally accessible public address, not by insisting on counting devices > that should remain anonymous or under limited (and controlled) visibility. > I think it was being justified on the basis of enabling connectivity, specifically from outsite-the-home to inside-the-home. This is a problematic scenario for privately addressed IPv4 networks using NAT. Also, there is no reason why IPv6 devices in the home can't decline global addresses and stick with link-local or site-local addressing. > At times I suspect an administrative standard for uniquely referring > to a private IP address is a specific private IP network would have > been the only required improvement in global addressing. Like RSIP? - aidan
Re: Last Call: Extensions to FTP to Proposed Standard
>The IESG has received a request from the Extensions to FTP Working >Group to consider Extensions to FTP as >a Proposed Standard. There are a couple of unclarities in the specification that should be cleaned up: Section 2.4 states that "unless stated to the contrary, any reply to any FTP command ... may be of the multi-line format". It doesn't say what counts as stating to the contrary, except to say that ABNF indicating a single-line response format is not sufficient to require a single-line response. This makes those parts of the specification that provide a more restricted syntax for certain replies ambiguous: it isn't clear where multi-line responses are permitted. This happens in section 3.1 (defining a successful MDTM reply) and 4.1 (SIZE): both give ABNF that on its face allows only for a single-line reply, and in neither case is the applicability of 2.4's implicit multi-line reply rule explicitly addressed. Neither section says what a valid multi-line success reply (to MDTM or SIZE) would look like. I guess that multi-line replies aren't intended to be permitted in this case, but in the light of section 2.4 it's unclear. Shouldn't we instead have an explicit note in cases where an ABNF rule is intended to be taken *non*-literally? Section 3.1, on the MDTM command, says "Attempts to query the modification time of files that are unable to be retrieved generate undefined responses.". The phrase "undefined responses" sounds like it permits what would otherwise be violations of the protocol, such that the client cannot correctly infer any information from what happens later in the session, and in fact that the client cannot determine whether this has happened. Sections 3.1 and 3.2 go on to provide perfectly sensible ways of handling error conditions within the protocol, so "undefined responses" seem unnecessary. Probably the "undefined responses" sentence should be removed or modified, perhaps to something like "Attempts ... may generate either errors or successful responses that might not be meaningful.". If "undefined responses" was intended to permit some other historical behaviour, the limits of such behaviour should be specified. -zefram
Re: Why IPv6 is a must?
> "John" == John Stracke <[EMAIL PROTECTED]> writes:
John> Think water meters. Utility companies would love to be able to
John> stop sending out expensive
John> humans just to read one dial at each customer each month. You *could*
John> have a reverse proxy in your home NAT, but that gets harder to
John> standardize; "does customer X have a compatible NAT?" is a harder question
John> than "does customer X have an IPv6 network?". Besides, if you've
And, given shipworm, if the water meter sees no router advertisements, but
notices DHCP, it does that, and does either IPv6-over-UDP-through-NAT, or
just plain 6to4 if possible. You run IPsec over that with a manual keys that is
configured into the meter when it was installed.
As you say - the water company does want security.
Why would anyone pay for this? Well, not for water or electricity in these
parts, but in places where either is scarce, you need this to provide
variable water/electricity rates (In most places in Canada a "Hydro" bill is
for electricity, which speaks for the abundance of one leading to the
abundance of the other...)
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
Re: Why IPv6 is a must?
> "Anthony" == Anthony Atkielski <[EMAIL PROTECTED]> writes:
Anthony> That's exactly why you only need one telephone per family.
Anthony> These are people who don't need to be individually reachable.
Families are going toward a telephone per person with caller id and/or
distinctive ring to figure out who should answer. That sure sounds like NAT
to me!
They would take a phone number per person, but someone there aren't enough
phone numbers available cheaply enough or a mechanism to communicate them to
the end-node to make this work.
Mobile phone companies are offering cell phones for each member of the
family with calling plans.
My wife and I possess a total of 5 telephone numbers (counting mobile and
pagers) because the phone company does not offer the equivalent of mobileIP.
Plus her work number, at which I can't reach her after the receptionist has
gone home, and her mobile phone is non-functional due to building issues, but
that's okay since her patient's pace-makers prefer it that way.
Anthony> That's also exactly why you only need one telephone per
Anthony> business. These are employees who don't need to be individually
Anthony> reachable. The receptionist can have one telephone, and he or
Anthony> she can just physically bring any other employee who needs to be
Anthony> contacted to the phone in the reception area.
That works for some businesses perhaps. It fails in most white collar work.
Ever try to get ahold of someone *AFTER THE RECEPTIONIST HAS GONE HOME*?
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
Re: Why IPv6 is a must?
>If a node only requires accessibility by a few specialized nodes (such >as a water meter) then making it *visible* to more is just creating >a security hole that has to be plugged. > >Yes, the hole can be plugged easily. If there's a security hole in the meter, putting a firewall in front of it won't help. Remember that the person most likely to be interested in hacking the meter is the customer (reduce their costs); the water company's engineers should consider the LAN the *most* likely point of attack, not the least likely. Meanwhile, if the meter is insecure, the customer should not allow it on their LAN, because it might get used as a way to attack the LAN. (This applies even if the meter uses only outbound connections, as through a NAT; if the attacker can spoof the water company's DNS, then they can feed the meter false instructions.) So, firewalls (and NATs) don't meet either party's needs. Only true security on the device itself will do. You might also want a firewall to protect the rest of the LAN in case the device's security fails; but protecting the device from the outside world is irrelevant. Once again, security and visibility are orthogonal. /\ |John Stracke |Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | || |Never underestimate the power of human stupidity. --I forget who| \/
Re: Why IPv6 is a must?
> Plus her work number, at which I can't reach her after the receptionist has >gone home, and her mobile phone is non-functional due to building issues, but >that's okay since her patient's pace-makers prefer it that way. Let me see if I understand this correctly ... your wife is behind a NAT (the receptionist) and it's causing a denial of service? :-) --Ken
Re: Why IPv6 is a must?
Lloyd Wood wrote: > > On Mon, 26 Nov 2001, Caitlin Bestler wrote: ... > > My point remains, a globally meaningful address is something that > > should only be applied when it is useful for that endpoint to > > be globally addressable. > > I think we're lucky that this point was not applied to the design of > IP twenty-odd years ago. We'd then have a bunch of restricted gateways > that translate email - badly - no universal telnet, no universal ftp, > and certainly no web... Actually, it *was* applied earlier (by default), and it was as a result of the ensuing disconnects and general uselessness that the Internet (a.k.a. Catenet) concept was developed by Pouzin, Cerf and Kahn. NAT has simply pushed us back to the pre-1978 situation. The references are in RFC 2775, section 2.3. Brian
Re: Why IPv6 is a must?
> Let me see if I understand this correctly ... your wife is behind a NAT > (the receptionist) and it's causing a denial of service? :-) close. the receptionist is an ALG.
Re: Why IPv6 is a must?
> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes:
>> Let me see if I understand this correctly ... your wife is behind a NAT
>> (the receptionist) and it's causing a denial of service? :-)
Keith> close. the receptionist is an ALG.
Application Layer Gateway. Yes. that precisely true.
Caused by the lack of ability to address the phone in her lab directly.
PBXs with extensions are just the application layer gateways that speak DTMF.
The point is that: the phone certainly should *NOT* be held up as an
example of a system that functions well despite lack of end-node
identification. In fact, large amounts of money have been spent (and made,
which is the problem - it created new opportunities, which people want to
exploit. Ditto for NAT) on the problem.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
Re: Last Call: Extensions to FTP to Proposed Standard
Date:Tue, 27 Nov 2001 02:32:56 + From:Zefram <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Thanks for the comments. I'm quoting almost your entire message for the benefit of the ftpext WG list ... | There are a couple of unclarities in the specification that should be | cleaned up: | | Section 2.4 states that "unless stated to the contrary, any reply to any | FTP command ... may be of the multi-line format". It doesn't say what | counts as stating to the contrary, except to say that ABNF indicating a | single-line response format is not sufficient to require a single-line | response. This makes those parts of the specification that provide a | more restricted syntax for certain replies ambiguous: it isn't clear | where multi-line responses are permitted. This happens in section 3.1 | (defining a successful MDTM reply) and 4.1 (SIZE): both give ABNF that | on its face allows only for a single-line reply, and in neither case | is the applicability of 2.4's implicit multi-line reply rule explicitly | addressed. Neither section says what a valid multi-line success reply | (to MDTM or SIZE) would look like. I guess that multi-line replies aren't | intended to be permitted in this case, but in the light of section 2.4 | it's unclear. Shouldn't we instead have an explicit note in cases where | an ABNF rule is intended to be taken *non*-literally? I'm not sure about that, though SIZE and MDTM should both say that only one line is permitted I think. After the last call has ended, and working group permitting, I will fix that (along with anything else discovered that needs fixing). I'll see if there are any others. But in the general case, any ftp response, can be multi-line (which certainly applies to all of the error responses) so I don't think that changing the sense of the comment in 2.4 would be the right solution. It might also be worth asking whether there is really any reason for the SIZE, MDTM commands, etc, to actually be restricted to one line replies, provided that however many lines are generated, just the required information is returned. | Section 3.1, on the MDTM command, says "Attempts to query the modification | time of files that are unable to be retrieved generate undefined | responses.". The phrase "undefined responses" sounds like it permits | what would otherwise be violations of the protocol, such that the client | cannot correctly infer any information from what happens later in the | session, and in fact that the client cannot determine whether this has | happened. That wasn't the intent, perhaps this could be clarified. Clearly though, I think, it is only the response generated that is undefined, nothing that would affect the rest of the session (that is, it doesn't say it has an undefined effect, just generates an undefined response).But more than that, the intent is that the syntax would still be correctly generated, but that the value returned might be rubbish - and yes, without the client having any way to tell that it happened. | Sections 3.1 and 3.2 go on to provide perfectly sensible ways | of handling error conditions within the protocol, so "undefined responses" | seem unnecessary. No, the expectation is that the server is not required to check whether the object for which the mod time is requested has a sensible mod time to return. If the underlying OS generates an error, then the server will generally reply with an error code. If not, but simply returns some value which isn't what would normally be considered as a modification time, then the server is allowed to simply send that back to the client, it doesn't have to test whether the value it obtained is rational or not. | Probably the "undefined responses" sentence should be | removed or modified, perhaps to something like "Attempts ... may generate | either errors or successful responses that might not be meaningful.". That is more or less what "generate undefined responses" was intended to convey. That is, you'll get a response, but what that response might be isn't defined... | If "undefined responses" was intended to permit some other historical | behaviour, the limits of such behaviour should be specified. Certainly, the MTDM (and SIZE) sections (and stream mode restart) are just intended to document functions that have been in ftp servers for 15 years or so now, both so their functionality can be reliably used, and so others know exactly what is required to implement them. About the only limit that I can see being reasonable here is that if a response that looks like a success response is generated, then it should conform to the syntax. kre
Re: Why IPv6 is a must?
Michael writes: > Families are going toward a telephone per person > with caller id and/or distinctive ring to figure > out who should answer. That sure sounds like NAT > to me! How so? Are they all using the same telephone number? > They would take a phone number per person, but > someone there aren't enough phone numbers available > cheaply enough or a mechanism to communicate > them to the end-node to make this work. Where is this? > My wife and I possess a total of 5 telephone > numbers (counting mobile and pagers) because the > phone company does not offer the equivalent > of mobileIP. So how is this anything like NAT? NAT would be one telephone number. > That works for some businesses perhaps. It fails > in most white collar work. It fails in all businesses, in this century. > Ever try to get ahold of someone *AFTER THE > RECEPTIONIST HAS GONE HOME*? Ever try to connect to machine B when NAT insists in directing all incoming connections to a given port on the one and only external IP address to machine A?
Cable Co's view: NAT is bad because we want to charge per IP
NAT is an ugly hack that's impairing people's connectivity, right? For some, it might be. Others find different faults with NAT. A highly unusual for an IETFer (and very disturbing) perspective of cable companies is provided in an article in CED magazine "The CAT and the NAT" by Leslie Ellis, Technology Analyst: http://www.cedmagazine.com/ced/2001/1101/11d.htm (Link appeared on Slashdot.) This article proceeds to describe NATs as incarnations of everything evil. One of the reasons they are so evil, according to Leslie Ellis, is that they allow users to avoid paying for extra IP numbers: > What's the value of the stolen goods? Revenues associated with > additional IP addresses, for one. Let's say one in 10 of the 5 > million U.S. cable modem subscribers are usurping IP addresses > without paying the $4.95 per month fee that's typically charged > (beyond a pre-specified limit, which varies MSO to MSO.) Right off > that bat, that's just shy of $30 million lost, annually. [I replaced the Microsoft character for the apostrophe with ASCII in the paragraph above.] I can see it: "So, you'd like to purchase a /48 with your eye-pee-vee-sex package? Are you saying it should be the default allocation? I don't know who told you that it should be the default, but we can do that for you. It would be for our everyday low price of $6044629098073145873530880 per month, first month prepaid. Yes, that's six septillion, forty-four sextillion, six hundred twenty-nine queen-... quintillion... Are you there? Hello? We actually do have a 15% discount package! Hello?!" The article then proceeds to describe some snake oil "solution" (the CAT part) that would "go one step further, essentially saying, `Pardon, NAT, but what's that behind you?'" (Microsoft characters replaced with ASCII, again). The important thing to realize here is that there are many people who read "THE PREMIER MAGAZINE OF BROADBAND TECHNOLOGY" and absorb the infinite wisdom of its Techology Analysts. Boy, am I glad I don't have to deal with a cable company! "Cable... Where idiotic business models and complete lack of understanding of networks are combined!" P.S.: Just to be clear, the other problem that the article finds with NAT is that it enables you to share your connection with neighbors. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Nuclear war would really set back cable [television]." -- Ted Turner
Re: Why IPv6 is a must?
Anthony Atkielski wrote: > > Caitlin writes: > > > If a node only requires accessibility by a > > few specialized nodes (such as a water meter) > > then making it *visible* to more is just > > creating a security hole that has to be plugged. > > Only if the information made thus available itself constitutes a security > breach, which is not necessarily the case. Knowing how much water someone > consumes or how many cans of Coke remain in a distributing machine would > probably not be a security issue for most users... I can't help myself. Actually, having access to such stats as amount of power used, coke consumed, late-night pizzas ordered from the Pentagon, or number of routine status messages transmitted from ships of a specific call sign, can reveal a surprising amount of detail. It's fairly well known that the Americans had broken the Japanese codes during World War II, but it's less well known that this was not a one shot break, but an ongoing process of breaks, loss of capability and rebreaks. Periodically the Japanese would reissue their code books and change the callsigns of their various ships. The U.S. code breakers would then have to recreate their penetration by identifying each vessel's new call sign, identify specific message types and using these to rediscover the code groups. One technique they had for this was to detect traffic patterns from specific callsigns; by detecting similar patterns before and after the change, they could identify specific ships. They could then attack the message traffic looking for identical or similar messages, which in turn would lead to new breaks into the system. Another technique was to monitor ambient traffic patterns. A spike in traffic for a vessel or group would indicate potential upcoming operations, especially if you were monitoring major capital ships. Operations research has come a long way since then, and these or similar techniques are now used in industry for marketing and sales purposes. U.S. law enforcement was even using power consumption (as measured by infrared detectors) as an indicator of potential pot growing in your hydroponic basement garden for a while. This last one ran afoul of the illegal search and seizure bits of the U.S. constitution but The World Is A Very Big Place and not everybody might be as picky as the U.S. on such things. The moral of the story? Traffic patterns and metadata can be powerful tools and one person's junk is another person's data. You should not assume that the majority of people shouldn't or wouldn't care about it leaking out, even if at first glance it seems pretty mundane. - peterd -- -- Peter Deutsch work email: [EMAIL PROTECTED] Director of Engineering Edge Delivery Products Content Networking Business Unit private: [EMAIL PROTECTED] Cisco Systems Many people can predict the future. Me, I can predict the past... --
Re: Why IPv6 is a must?
Peter writes: > I can't help myself. So I see. > Actually, having access to such stats as amount > of power used, coke consumed, late-night pizzas > ordered from the Pentagon, or number of routine > status messages transmitted from ships of a specific > call sign, can reveal a surprising amount of detail. Yes, but it does not necessarily reveal anything you wish to keep secret, and even if it does, the traffic analysis required to recover the information may be more costly than the information is worth. > It's fairly well known that the Americans had > broken the Japanese codes during World War II, > but it's less well known that this was not a one > shot break, but an ongoing process of breaks, > loss of capability and rebreaks. So I suppose anyone planning to bomb Pearl Harbor should use NAT. > U.S. law enforcement was even using power consumption > (as measured by infrared detectors) as an indicator > of potential pot growing in your hydroponic basement > garden for a while. They need to recalibrate their equipment. I don't have a garden. I don't even have a basement. > This last one ran afoul of the illegal search > and seizure bits of the U.S. constitution but > The World Is A Very Big Place and not everybody > might be as picky as the U.S. on such things. The U.S. is getting pretty fast and loose on the respect of these rights, too. > The moral of the story? Traffic patterns and metadata > can be powerful tools and one person's junk is > another person's data. Sure ... but I really don't think that monitoring Coke machines or water meters is likely to be a source of major security breaches. And for anyone who feels otherwise, there are firewalls, proxies, NAT, and so on. > You should not assume that the majority of people > shouldn't or wouldn't care about it leaking out, > even if at first glance it seems pretty mundane. I'm not merely assuming it, I'm certain of it. Anyone willing to put his signature on a charge slip that contains all his credit-card information is not likely to care about someone monitoring his water consumption, and certainly if he does then he has some pretty skewed priorities.
Re: Cable Co's view: NAT is bad because we want to charge per IP
You'd think that an ISP, cable-company or not, would tend to charge by volume or connection time rather than the number of IP addresses in use. The last of these makes about as much sense as charging for all the one bits transmitted, and leaving the zeroes free. - Original Message - From: "stanislav shalunov" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 23:51 Subject: Cable Co's view: NAT is bad because we want to charge per IP > NAT is an ugly hack that's impairing people's connectivity, right? > For some, it might be. Others find different faults with NAT. > A highly unusual for an IETFer (and very disturbing) perspective of > cable companies is provided in an article in CED magazine "The CAT and > the NAT" by Leslie Ellis, Technology Analyst: > > http://www.cedmagazine.com/ced/2001/1101/11d.htm > > (Link appeared on Slashdot.) > > This article proceeds to describe NATs as incarnations of everything > evil. One of the reasons they are so evil, according to Leslie Ellis, > is that they allow users to avoid paying for extra IP numbers: > > > What's the value of the stolen goods? Revenues associated with > > additional IP addresses, for one. Let's say one in 10 of the 5 > > million U.S. cable modem subscribers are usurping IP addresses > > without paying the $4.95 per month fee that's typically charged > > (beyond a pre-specified limit, which varies MSO to MSO.) Right off > > that bat, that's just shy of $30 million lost, annually. > > [I replaced the Microsoft character for the apostrophe with ASCII in > the paragraph above.] > > I can see it: "So, you'd like to purchase a /48 with your > eye-pee-vee-sex package? Are you saying it should be the default > allocation? I don't know who told you that it should be the default, > but we can do that for you. It would be for our everyday low price of > $6044629098073145873530880 per month, first month prepaid. Yes, > that's six septillion, forty-four sextillion, six hundred twenty-nine > queen-... quintillion... Are you there? Hello? We actually do have > a 15% discount package! Hello?!" > > The article then proceeds to describe some snake oil "solution" (the > CAT part) that would "go one step further, essentially saying, > `Pardon, NAT, but what's that behind you?'" (Microsoft characters > replaced with ASCII, again). > > The important thing to realize here is that there are many people who > read "THE PREMIER MAGAZINE OF BROADBAND TECHNOLOGY" and absorb the > infinite wisdom of its Techology Analysts. > > Boy, am I glad I don't have to deal with a cable company! > > "Cable... Where idiotic business models and complete lack of > understanding of networks are combined!" > > P.S.: Just to be clear, the other problem that the article finds with > NAT is that it enables you to share your connection with neighbors. > > -- > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > "Nuclear war would really set back cable [television]." -- Ted Turner > >
Re: Why IPv6 is a must?
Anthony Atkielski wrote: > Keith writes: > > .and you can tell a lot about me by > > watching the temperature sensors at my house > > (http://www.cs.utk.edu/~moore/home_temp.html) > Such as what? Well, for starters, he lists temperature in both F and C, so he's probably not an "American". In fact, he lists C first, so it's almost certain that he's not 'Merkin. Also, the general locus of values for outside air temp would imply that it's damned cold outside, so he's probably somewhere rather closer to the North pole than I am. Another conclusion, probably related to this, is that he consistantly keeps his house significantly warmer than the outside, so he is likely to be a mammal, a bird, or a reptile. What else? Ah, yes investigating the periodic changes in outside temperature, it becomes clear that it is, in fact, on a daily cycle, but it's nothing like the skewed sine wave one would expect from a sun-driven heat system. It's more like a sawtooth waveform. Hmmm. The temperature is lowest in late morning, long after the sun would have started warming things up if his idea of "outside" involved things that the sun would warm, but then it skyrockets upward until late afternoon, whereupon it starts a slow drop back down. Perhaps Keith's outside air thermometer is _really_ outside, in full view of the sun, but on the west side of his house so the sun doesn't start cooking it until about 9 AM or so? This would explain the absurdly fast temperature rise that is both compressed, and delayed from normal daylight heating hours. See? Nothing more than a simple graph, and we have learned a great deal about this "Keith" character (and probably more about the rest of us). If his thermometers (and his thermostat) are available through the web, perhaps we could run some tests here What kind of experiments would we need to run, in order to tie this sub-thread back into the security discussion? -- : Unable to locate coffee. Operator halted.
Re: Why IPv6 is a must?
> Actually, having access to such stats as amount of power used, coke > consumed, late-night pizzas ordered from the Pentagon, or number of > routine status messages transmitted from ships of a specific call sign, > can reveal a surprising amount of detail. entirely agree. and you can tell a lot about me by watching the temperature sensors at my house (http://www.cs.utk.edu/~moore/home_temp.html) security is potentially important for any device or service, no matter how trivial it seems. and since you can't rely on network topology to provide security, security has to be implemented - at least partially - by the device itself. Keith
Re: Why IPv6 is a must?
Keith writes: > entirely agree. and you can tell a lot about me by > watching the temperature sensors at my house > (http://www.cs.utk.edu/~moore/home_temp.html) Such as what? Your home heating system cycles frequently, but that's about it. I can't read the stuff in bright green.
Re: Why IPv6 is a must?
> Such as what? that would be telling.
