Slashdot Mirror

Each service on each host of the private side of your firewall box grabs a port number on the public side of the firewall and registers a corresponding SRV record with a DNS server, and any application out on the real Internet that wants to reach it finds the port number dynamically from DNS instead of statically hard-coding it. The public side still needs genuine registered addresses, but the private side can use RFC1918 space (e.g. 10.x.x.x), and each public-side IPv4 address can support as many machines behind the firewall as it takes to run out of ports. So if your cellphone has a web server, instead of reaching it through its own IP address and port 80, it looks like 10.11.12.13:80 on the hidden site, but you reach it from the real world at firewall123.cellphone-example.net:4567, and firewall123.cellphone has a real IPv4 address 123.456.789.10. Somebody in the real world who wants to reach your phone either looks up _http_.13115551212.cellphone-example.net and gets an SRV record telling them it's port 4567 on 123.456.789.10, or else you just advertise http://13115551212.cellphone-example.net:4567/ and let their browser go there directly. So if the average cellphone has 16 ports active(counting both directions), then that one IPv4 address can support 4000 phones.

And yes, this still has problems - it encourages service providers of cellphones, DNS, and cable modems to hide their users behind NAT-like service, but it's a two-way NAT-like service, and they don't have to limit the ports or protocols the users offer to the world but many of them will. And it also encourages service providers to provide big web-proxy farms on the private side to reduce the number of ports used on the public side, which makes censorship a bit easier. And there are protocols that *know* which port they live on, so the client and sometimes the server applications would need to change to use SRV records instead, but that's probably less disruptive than teaching them to use IPv6 addresses. Other protocols like http (using URLs with port numbers) and smtp (using MX records) already have ways to specify the port numbers. Some protocols like IPSEC aren't happy with NAT, especially port NAT, but they often end up doing Stupid UDP-wrapper Tricks to work around that.

I'd like to reiterate what the parent says about v4 compatible v6 addresses. I've had to study RFC2373 (http://www.faqs.org/rfcs/rfc2373.html) and the people who designed IPv6 didn't do it without consideration of the current system and how a transition would go. In fact, a lot of effort went into making it possible to transition to a larger address system while using both systems at the same time.

It's actually similar to how the x86 archetecture has advanced. When we moved up to 32-bit CPUs, in order to access the upper bits, new registers were created to address those upper bits while the lower ones stayed. An older 16-bit program would merely only use the lower bits, ignoring the upper ones since it wasn't designed to use them.

IPv6 allows for the last 32 bits to be used as an IPv4 address. You can even write out an IPv4 compatible IPv6 address using a combiniation of both hex and dotted decimal. eg: 0:0:0:0:0:FFFF:129.144.52.38 which in IPv6 can be compressed to ::FFFF:129.144.52.38 and which an IPv4 device would see it as merely 129.144.52.38. The idea being, when transferring over, only devices that actually need IPv4 compatibility would have an IPv6/IPv4 address. Quick example using NAT technology:

Say I have an office with 500 devices that need net connections. Now I also have a remote office with another 200 devices. These devices all like to connect to each other.. with various servers and services on each that make using NAT translation a PITA, but also buying 700 IPv4 addresses is mighty expensive. Now most of these devices are for internal use.. (I'll get to that). Now we do have 5 web servers that need to be accessed by people outside of the company (sales servers with web pages to sell stuff or show off our company). We give all 700 devices IPv6 addresses so that they can access each other over the internet. We give those 5 that need to be seen by everyone IPv6 addresses that have IPv4 mappings so that everyone can see them. We can get a few IPv6 addresses with IPv4 mappings to act as a NAT-like access point for internal devices to get to external IPv4 places for say viewing web pages or the like from internal machines.

But now one has to think.. why would we need 700 externally accessable devices? Isn't that a security nightmare? Managing all of them so that they don't get hit by a worm or such could really suck... but why do those devices have to be computers? What about VoIP phones or something similar?

I currently manage a VoIP setup that I implimented and support myself, and let me tell you.. NATs SUCK for VoIP. SIP hates it.. works half the time and the other half no go. If two devices are behind NATs, plain and simple they cannot talk to each other. If they have external addresses on most phones you can just dial straight to the IP address of another VoIP phone without even needing an intermediate server.. which can be handy at times.

It's just a minor example and I'm sure it can be picked apart and made to work on IPv4 (I've been doing such). But the time/cost savings of IPv6 along with just the mirade of possibilities it brings shouldn't be thrown aside because it would be "too hard" or "too expensive". The cost isn't as high as a lot of people think.. most are just afraid because they don't know anything about IPv6 and what you can do with it in reguards to IPv4. And of course no one knows, because no one is going to train in an area that has no use currently, which will remain that way until people educate themselves in it.

You have to go to all kinds of lengths (using special session border controllers, media proxies, etc.) to be able to support SIP calls where one or both parties are behind a NAT. It is awful. NAT is a hack--a useful one in certain situations, but still a hack.

I really love The Art of Unix Programming. http://www.faqs.org/docs/artu/ Maybe the simplicity of the kernel confuses them. What they are probably looking for is a driver development kit. http://www.jungo.com/linux.html This is nice, but what about all the new features that are added to the kernel. Plus, what about different architectures? You can run linux on an Xbox now. Do the companies think about that? Open source would be nice, but only shows half the picture. I vote for full documentation of hardware and half written software. Have a relaxed use policy where the documentation can only be used to create drivers. The company could use code words in the driver that confuse people, but they still release the source code. The function printk could be renamed to eaksdjfkasd and it could still work, but it is more difficult to understand.

One rant of mine is restricted use of products. Who says I can't use a screwdriver as a hammer? Why can I use a piece of software in any (legal) way I want? Pencil and pen companies don't bother writers about wanting a share of the profits.

WE WANT AND NEED FULL DOCUMENTATION and k.i.s.s.

frank
fsuarez2005@yahoo.com

That is wrong. This is a myth that has been disproved several times. See for example the "IEEE Annals of Computer History" where Adm. Grace Hopper said that that the term "bug" was used at least since the 30s, and maybe earlier, to describe an electrical problem in a system. See also here.

In interview, Hopper confirmed that the notebook moth's caption, "First actual case of bug being found", clearly shows that it was a joke referring to a term that was already in use at the time.

Any idiot researching this anecdote for five minutes could have found about it. I guess Wired couldn't be bothered. At this level of laziness and incompetence, one wonders why they just don't start publishing printouts of slashdot laced with ads. At least, this place contains occasional nudgets of truth.

Once again, Wired blew it. Nice jobs, guys.

Well, the US pretty much already controls the 'evil bit'. Remember when we applied it to Iraq, Iran, and North Korea?

http://www.faqs.org/faqs/tv/sat-night-live/commerc ials/

Much funnier stuff when you don't have to explain the pop culture reference

First, tell me which law I'd be in violation of if I required a customer's SSN as a prerequisite to doing business with them.

Second, from the SSN FAQ:

In addition, that section makes it illegal for Federal, state, and local government agencies to deny any rights, privileges or benefits to individuals who refuse to provide their SSNs unless the disclosure is required by Federal statute.

As a private business owner, I am none of these.

Just ...admit you're passing around bum info and be done with it.

It's actually never legally allowed to require a social security number; "they" can request it, but not demand it, unless "they" are a government agency

For more info, see:

http://www.faqs.org/faqs/privacy/ssn-faq/
http://archive.cpsr.net/cpsr/privacy/ssn/SSN-Priva te.html

Like any other human being, a woman wants to have friends and be appreciated for who she is. Every time she gets an email asking her on a date, she is reminded that she isn't viewed as part of the group, but instead as different, an object of desire, and is certainly not being judged on her technical merit alone.

This may be hard to stomach, but you need to not hit on women who show up for Linux events, at least not right away. In all likelihood, you are NOT throwing away your only chance at true love by not coming on to her immediately, but you are throwing away your chance to have a fun new member of the Linux community. And even if you still think you're missing a chance at true love, keep in mind that many women brave enough to show up at a LUG or your local mailing list will frequently make the first move anyway. By hitting on them at the first opportunity, you're scaring them away, and you're also scaring away all the other women who might have become interested if the first woman had stayed.

This goes double for women you meet over email or on IRC. You may think that your "Are you single?" line is hysterically witty and suave, but she's heard it a million times. Even if you're joking, even if you already have a girlfriend or are married--don't do it.

Sounds like that's approaching what Plan 9 was supposed to be...very interesting. I don't like network filesystems (an example from the linked article) that much, though, because mv, cp, rm, and friends don't give you progress indications.

A simple Google query would've given you what you seek, but what you need is ncpmount. There are numerous HOWTOs and FAQs on this topic. If people have written these HOWTOs, they've surely implemented it at some point.

I doubt any prison in the US has Internet access.

Of course you can get internet access in prison. You just have to be creative enough.

Firstly, why would a Telco be developing this technology? It doesn't appear to further their business.

Then it dawned on me. With Avian Flu concerns, sending packets via that method is dangerous RFC 1149. Obviously if the Telco's controlled humans, they could deliver packets with them via a maximum of 6 hops (six degrees of separation).

I for one welcome our new communication specification. Long live IPviaH.

This has been covered countless times before. Please see RFC 3675 for more information.

I'm appalled that, in 2005, we still have to jump through hoops to include arbitrary objects in arbitrary documents. Why can't HTML include a tag, with an "HREF" argument, that points at any object at any URL? Like a text object that is maintained by the server, not necessarily the one maintaining the document in which the document is embedded. To do so now, I have to use IFRAMEs, which have all kinds of quirks and cross-platform differences. How about email, where the Content-Disposition MIME header has, since at latest 1997, let us include a message body from an arbitrary URL, rather than always including every (often huge) object inline, such as "attachments"?

While we're at it, I'd like servers to keep a "reference count" of objects they serve, so documents which refer to their objects can (optionally) register. I'd like servers to keep a database of all their referrable objects and their URLs, so an object whose URL changes (moved internally, externally or deleted) can simply return the response code so indicating. Servers like the "Internet Archive" could be much more useful if they accepted archives of low- or old- refcount objects from elsewhere. Other servers wouldn't be able to "disappear" objects without notice, which is extremely important now that publishers often deny some publications that have such an important effect on politics and business, revising them without notice to coverup various deceptions without accountability.

Many of the problems with making and using Internet documents in WWW and email are solved directly with those two "embedded reference" technologies. This Internet is starting to get old, without outgrowing some of its basic limitation. I want to quote any object (or fragment) from any document in any other, without copying it - just include a reference. We don't need to make a quantum leap to Nelson's Xanadu just to get some things right. Where are the versions of Evolution or Firefox that just use these simple technologies to do that?

In point of fact, XML is not just intended for rendering non-document structured data (XHTML being one example of this, just as HTML is an example of this relating to SGML).

XML and SGML both had the intent of allowing open definitions of document content within a specific framework (delimiters, keywords, general syntax rules), and XML is a restricted subset of SGML. The fact that the most common use of XML to date has been for data and data transformation does not make it a data-container-only language any more than the same fact makes SGML a data-container-only language. The difference comes in the specific restrictions used in XML that make it more practical to implement.

All that aside, if we go back to heredity, if SGML is not covered by the patent, and XML is substantially a subset of SGML, then does it make sense that XML should be covered by the patent? In Dec, 1997 you find an example of a way to create an XML declaration in SGML. The RFC says in section 4:

XML, as a subset of SGML, has the same security considerations as specified in [RFC-1874].

XML is defined here as 'An initiative from the W3C defining an "extremely simple" dialect of SGML suitable for use on the World-Wide Web.', which says to me that the patent holder and the USPTO ought to examine the relationship between SGML and XML more closely, as well as examining the SGML-based applications that still exist.

Seeing as how SGML is not designed specifically for web-based transactions, it is probably broad enough to cover any situation that the patent applies to, unless they have somehow designed a process that implements SGML/XML-like behavior outside of computing devices.

I prefer carrier pigeons.

I prefer carrier pigeons.

Latest implementation of RFC 1149 ?

Or, should that be, "Aviation Carriers"?

RFC 3041 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6

Supported by at least Windows XP and Linux 2.6.

how does it work? you tell me, details are not easy to find. ots of talk, few working implementations (if I'm wrong, please tell me, I'm genuinely very interested).

I haven't read the RFC myself though, but here's my impresson on how it works: The device attempts to connect to whatever network is available at its location (be it a WiFi hotspot or 3G cell phone connection or anything) and does all the normal IPv6 negotiation stuff so that it gets at least a link-local address and a globally routable unicast address. Using that unicast address, it contacts the Home Agent (HA) to get a "Home Address". In other words, the device will have at least two globally routable unicast addresses. The normal source address selection algorithm has provisions that say that the Home Address should always be preferred (see RFC 3484). IPv6 mobility then uses an IPSec tunnel between the device and the HA. When you leave the current network or just want to use another network, the tunnel is renegotiated with the HA.

how does it work? you tell me, details are not easy to find. ots of talk, few working implementations (if I'm wrong, please tell me, I'm genuinely very interested).

I haven't read the RFC myself though, but here's my impresson on how it works: The device attempts to connect to whatever network is available at its location (be it a WiFi hotspot or 3G cell phone connection or anything) and does all the normal IPv6 negotiation stuff so that it gets at least a link-local address and a globally routable unicast address. Using that unicast address, it contacts the Home Agent (HA) to get a "Home Address". In other words, the device will have at least two globally routable unicast addresses. The normal source address selection algorithm has provisions that say that the Home Address should always be preferred (see RFC 3484). IPv6 mobility then uses an IPSec tunnel between the device and the HA. When you leave the current network or just want to use another network, the tunnel is renegotiated with the HA.

That's not generally agreed upon.

http://www.faqs.org/faqs/sci-math-faq/specialnumbe rs/0to0/

There were/are mathematicians who argue that 0^0 is 1, and those that argue that it's undefined.

I was going to say "duh, of course not, 0^0 is undefined, everyone knows that", since that's what I remember being taught all through school and university. However, a Google search tells me apparently it's not necessarily black or white. So I guess you have to go with what's useful for you. Anyway, it seems not even all software agrees; for example, both the built-in Windows calculator and Maple 8 say it's 1, but the PowerToys PowerCalc shows an error.

Dude, you earned youself some foe-points. I hate nothing more than a superficial, "conciliatory" post backed by nothing. If you actually used one of the *NIX systems, you would KNOW the difference. I guess your " Both systems blow, and just as equally" post is for the rest of the Windows crowd. Something like 'Nothing to see here, move along'.

Or maybe your post is skewed from a windows developer's point of view. Let's take the "disadvantages" one by one:

        no standard exists

There are clean standards of configuration files in linux:
DSV Style
RFC 822 Format
RFC 822 metaformat for records
Cookie-Jar Format

More information can be found here: http://www.faqs.org/docs/artu/ch05s02.html

        better security (advanced ACL support, not every app has it own parser)

Theoretically. But in practice, who needs advanced ACL support when your users login as root? About parsers, see above, all of the standard formats are trivial.

        weaker security (it is either put in user or etc, you do not have an option of put in etc but allow just this setting for users)

I really do not follow this. How is this weaker security? But after all it can be done. Default settings in /etc, modified setting for property foo in ~/. User settings override default settings.

Please mod parent down (-1,misinformed,troll)

Well, just check the evil bit on that data.

Real Usenet junkies use trn from a command line shell.

I rather hope it is standards compliant.

What else you ask?
Uhhh, I just thought of an important one. What about "how to make money?"

On this point, I think the example of Zope is illustrative. Investor Hadar Pedhazur was willing to pony up venture capital to fund Zope Corporation, on the condition that they open-source Zope. I'm not really a Zope fan, but the idea of an investor requiring a company to open-source their principal asset struck me as a hard-dollar vote for the value of OSS.

See this for refs:

http://www.faqs.org/docs/ZopeBook/IntroducingZope. html ("Zope History" section)

More detail:

http://washington.bizjournals.com/washington/stori es/1999/05/24/focus4.html

and it better be a bitchen password, with known parts of files to look for.

Well, as you say, it's risk versus rewards. You get some measure of security with PBE, and there are some techniques that make it more or less reliable. RFC 2898 deals with this. Of course RFC 2898, and PKCS have become a bit dated, but things could certainly be brought up to date using similar techniques, and a little obfuscation never hurt anyone. (Hashing your pre-encrypted data, rather than just your password, with a salt value would probably throw off an automated tool wielded by a non-expert.)

Been there done that, AFS http://www.faqs.org/faqs/afs-faq/ works wonders. Pretty much it's a nice fault tolerant file sharing system that supports direconnected ops meaning you can work with everything in disk cache and checkout / checkin things as needed.

According to the Rules of Engagement, I invoke Godwin's Law.

...with few people even remembering that OSI was supposed to be a competitor to TCP and built along fundamentally different assumptions ...
The problem is compounded by broken requirements like knowing the OSI model which is not only dead but broken.

I'll bite.

Why does the fact TCP and OSI were once competitors matter in modern discourse? Further, what is more dead and broken about the OSI 7 layer model versus the DoD 4 layer model? Finally, how exactly are the basic assumptions of OSI and TCP so different? (The prioritization of goals may be somewhat different, interoperability versus reliability for instance, but I don't see how the basic problem spaces differ so extremely.)

I certainly hope you're not arguing against layering of protocols altogether.

Per the RFC

...it must make use of the widely adopted RFC 7812, i.e. the Illegal Flag. This popular RFC was derived off of RFC 3514, known to many as the Evil Bit. Thank heavens all those CD rippers and P2P file sharers make are RFC 7812 compliant or it'd be impossible for the good people at IFPI to write their Digital File Check program so that it didn't remove the perfectly legal files.

What an age we live in!

>>Unless you start to give your hash keys as the same size as the original file, there is not anything that can be done about it, ever.''

>No. If I run deflate or some other compression algorithm on a file, chances are it will come out smaller. Still, the compressed file maps one to one with the original.

The parent is correct. Given a number of purely random files and a good compressor of patterned information, most, if not all, of are the "compressed" files will be larger than the original. It is mathematically impossible to create a compressor that can reduce the size of any arbitrary file. See the counting argument in section 9.2 of the compression FAQ for an explanation.

For related 'extra' information... Chapter 2 in the Art of Unix Programming (Eric S. Raymond) contains a very interesting discourse about the history of the UNIX operating system, and offers insight into operating system wars in general.

One of his points is that many early UNIXes suffered because of licensing issues. I definitely feel that Linux's edge over older UNIXes is its open source license.

This has been provided for. Creationists never believe scientists about the monkeys.

in order to get a .org you have to be a 503(c) or whatever

Why? That's not even the spirit of the TLD. It's not some unenforced rule. .org was for organizations that didn't fit in some other category, not for "non-profits" or some such mythical flamewar initiated nonsense.

From RFC 1591: ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non-government organizations may fit here.

I don't know off the top of my head what the criteria for .net and such would be.

Perhaps you should read the RFC. After learining the original intentions for the TLDs, you may change your mind to something more sensible than shaking up well-established names to meet your whim.

For those who don't know evil bit:
http://www.faqs.org/rfcs/rfc3514.html

• work with an engineering faculty to design the replacement board,
• require spec's as part of the manufacturing contract, or
• that the specifications are placed in escrow to be released if the company goes into bankrupcy, or is no longer able to provide duplicates at specified rates.

You can still download those viruses here:
http://www.hackcanada.com/whacked/filelists/aol.ht ml

Read more about them here:
http://www.faqs.org/faqs/computer-virus/macintosh- faq/
http://www.nd.edu/~madmacs/virus.html

I had the nVIR A virus on my LC II running System 7.0 in 1993. I got it from a floppy disk with a game on it given to me by a relative. It would screw up the System so that you couldn't launch any apps but it wouldn't harm your data. If you read the above info you'll see that most of these viruses are benign.

The upgrade to MacOS 8 broke most of these threats. Even the 1995 autostart worm if I remember correctly. Considering that The OS X classic environment requires Mac OS 9.1 there is no chance that any of these threats can infect a computer running Mac OS X.

I don't believe that is accurate -- there were some that did not work under System 7, but many that did, even some created just for System 7+. Here's a list from 2000 that mentions many that originated after 1991.

That's in the QMTP server, not the SMTP server. That's the protocol described here, not the one described here.

HTTP isn't that outdated. I mean, at least it was updated more recently that MSIE's renderring engine was!

Basically, SSL 2.0 is to HTTP/1.0 as SSL 3.0 is to HTTP/1.1

RFC 3489

MySQL is great for some things, but we use PostgreSQL at my job because it supports CIDR:
http://www.faqs.org/rfcs/rfc1519.html
If you have a table in your database full of IP addresses, this is invaluable because you can query blocks of IP addresses using CIDR notation.

Nobody has mentioned XDR yet. Although it's probably not what you'd really prefer (as NetCDF seems to be very popular with CFD projects, and there's presumably a good reason), I'll describe it for completeness. EXternal Data Represenation it sits nicely in the midpoint between pure native data and human-readable text of the numbers (including XML).

Free libxdr code is available everyplace, although often quite ancient (some written in 1982 or so). Just run your data structs through xdr calls, write it out with the MPI native interface, and apply reverse versions of the same calls when loading. It's a lot like the htonl/ntohl functions you may be familiar with (but more elaborate, of course, because it handles marshalling and padding in addition to just endianness).

Advantage of XDR: files are portable, but hardly any bigger than the original data in RAM (prehaps even a little smaller)

Disadvantage of XDR: files are not human-readable, decellerating the processes of debugging or informing others how to inspect your files. Plus, it simply lacks the cool-factor of XML.

http://www.faqs.org/rfcs/rfc1832.html

I went to a Christian boarding school. Some of the priests [salesians.org] there pointed out that there are many ways to read Genesis.

That number in Genesis--6000 or so?--is given by the simple recursion

X:= me;
AgeEarth:= 0;
While X != Adam do
{
Age(Earth) := Age(Earth)+Age(X);
X:=Father_of_X;
}
end do.

The number was not figurative to the Jews of 1500 AD [or many Orthodox Jews today].

Not that there's anything wrong with disagreement... It's that one ought to consult experts when one wants to interpret Torah. I imagine priests don't, as said experts take a different view of the whole Messiah thing.