Slashdot Mirror

Photobit, a Pasadena, California company that designs and fabricates a wide variety of CMOS sensors, has developed a working prototype of one. Glued directly onto a 1- by 2-inch CMOS-wafer--small enough to fit into a wallet billfold--is a tiny BB-size fixed focus lens. On the same chip is a frame buffer, an analog-to-digital converter, and a variety of standard digital camera features and controls such as auto-focus, auto-exposure control, shutter, and white balance. The chip also has an interface on its edge for connecting to a parallel cable and port. The most significant detail of this camera-on-a-chip is its ample space for additional functions. Look for manufacturers to add lots of extras, such as image memory, image stabilization, motion tracking for surveillance, videoconferencing, a battery, and even a wireless modem for remote control and access. The camera can be miniaturized, and its cost reduced to a few dollars. When this happens, get ready for an explosion of image monitors and capture devices.

One role promoted for MEMS in a 1995 report by the Pentagon's Advanced Research Projects Agency is as "surveillance dust": several thousand microminiaturized camera/infrared-detector/microphone packages dropped via individual parachutes over a battlefield. This "dust" would float like dandelion fuzz for several hours and track a potential enemy's every move. The civilian applications of this technology need scarcely be mentioned

Ever hear of DNSSEC?
RFC 2065
It is supported as of BIND 8.2:
BIND 8.2 highlights

The following RFC on Portable Network Graphics is from RFC2083.txt.

Features:
---------
* PNG supports truecolor images.
* "In particular, GIF is well adapted for online communications because of its streamability and progressive display capability. PNG shares those attributes. (Stress added).
====Can some one tell me .. does this mean that PNG can support animation?? what does "progressive display capability" mean ??====
* PNG has been expressly designed not to be completely dependent on a single compression technique.
*"Indexed-color,grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits."

Limitations:
------------
* There is no uncompressed variant of PNG.
* There is no standard chunk for thumbnail views of images.
* There is no lossy compression in PNG.

Hope that clarifies where PNG stands

Manifest

Paul.

RFC 1918 reserves certain subnets that aren't routable over the public Internet. If you use them, you can set up a masquerading gateway without needing a second NIC (if you can set up two routes over the same interface). I'll grant that a separate segment for your subnet is more efficient and secure, especially if your end of the DSL/cable connection is promiscuous - all your subnet's traffic will otherwise be forwarded to the nearest router and then dropped.

The network number is assigned by the network and is used to route the packet back to you, just as in IPv4.

See RFC2373: IP Version 6 Addressing Architecture as well as Privacy Extensions for Stateless Address Autoconfiguration in IPv6 for more details.

If you like doom processes, you might want to check out lavaps . It provides a somewhat more peaceful way to visualize processes, including how much memory and CPU they consume. (Just recently posted to freshmeat.)

Try the The DICT Development Group. They run FILE: The Free Internet Lexicon and Encyclopedia - it's really a dictionary rather than an Encyclopedia, but it is open source, and it is an attempt to fulfill and extend RFC 2229 - A Dictionary Server Protocol.

Here's the snippet from RFC 1591, written by Jon Postel himself:

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

Using the network card MAC address as part of the IPv6 address is only one way of setting up the global IPv6 addresses (it's unmanaged autoconfiguration used by rtadvd). Alternatives are manual configuration or using DHCP with IPv6 extension.

It's also possible to use the IPv6 stateless manager autoconfiguration (without DHCP) using an interface identifier that changes over time. It's documented in draft-ietf-ipngwg-addrconf-privacy-00.txt. A must read before starting complaints like this.
--

He says Institute for Information Sciences. I think he means Information Sciences Institute. They're the ones working with Microsoft Research on an IPv6 stack.

He also implies that ISI's work is DoD funded, when it's not (Microsoft is footing the bill, and from what I understand has also done the majority of the work), that's it's a reference implementation (there is no official "reference" IPv6 implementation annointed as such by the IETF), and that ISI (or government spooks) are trying to slip this into Windows 2000 (which is also not happening).

A better title for this article would be "Where's the Outrage Over Bad Reporting?".

He says Institute for Information Sciences. I think he means Information Sciences Institute. They're the ones working with Microsoft Research on an IPv6 stack.

He also implies that ISI's work is DoD funded, when it's not (Microsoft is footing the bill, and from what I understand has also done the majority of the work), that's it's a reference implementation (there is no official "reference" IPv6 implementation annointed as such by the IETF), and that ISI (or government spooks) are trying to slip this into Windows 2000 (which is also not happening).

A better title for this article would be "Where's the Outrage Over Bad Reporting?".

It's not the bottom 48bits.
The 48 bits are used, but break it into 24 and 24, put an 0xfffe between them, and you've got your 64bit identifier.
RFC 2373 IP Version 6 Addressing Architecture

The currently proposed IPv6 addressing scheme called EUI-64 does not infringe on privacy issues. It is true that some Ethernet NICs have the ability to change their hardware addresses, some can't. There are also duplicate MAC addresses anyway.

I have not seen much discussion that shows people how much they are giving away already. Just to post this comment I had to give up tons of private information, and Andover now has most of the information people are giving away PC's for. So, it's not like the current situation is so private anyway.

Now, even with the EUI-64.txtaddressing scheme proposed in RFC 2373, does not *require* the use of a hardware address in the lower 64 bits. For "Links without Identifiers" you can use an identifier which is assigned to the node itself. You can give yourself a unique identifier if you choose, which is just what an IPv4 address is supposed to be. And you can bet that Linux and the other free operating systems will give you this ability from userland. I doubt the same thing will be true of other proprietary operating systems, but they might. When using a proprietary operating system without source, you don't have a clue what's happening anyway.

Further exerpts from the RFC:
If there is no global interface identifier available for use on the link the implementation needs to create a local scope interface identifier. The only requirement is that it be unique on the link. There are many possible approaches to select a link-unique interface identifier. They include:
Manual Configuration
Generated Random Number
Node Serial Number (or other node-specific token)


Synthetic Truth: please RTFM!

• Bones is an implementation of the Kerberos Version 4 API that has had all calls to encryption libraries removed and that does not provide any form of security whatsoever. This is a partial solution to this problem, in that it provides a system that looks like Kerberos from an application's point of view.
• 
  
  Outside the United States, you can get Bones via anonymous ftp from ftp.funet.fi (128.214.6.100) in pub/unix/security/kerberos. A DES library is available from the same place.
  
  Copies of the Kerberos Bones with DES routines and calls added back in by foreign programmers are called `eBones', and are available by anonymous FTP from machines in Sweden, Germany, Israel, Finland, Australia, and France (so far); check with "archie".

It looks to me like this draft is saying:
A) The author feels nobody explains IP Addressing well;
B) There is some discrepancy between the standard decimal representation of an IP address and the standard binary representation of it;
C) The original class A/B/C method of assigning IP addresses is obsolete;
D) The 32 bit IPv4 system could be used for another hundred years without upgrading to IPv6 if you use some obscure addressing scheme that appears to depend on B, above, and hiding some of the address in the subnet mask;
E) Adopting this scheme will be easier than teaching people how to use IPv6.

Well, point A is obvious, if he considers this draft to be a "logical...explanation", than no previous documentation would quite pass muster.

He provides no clear evidence for point B. The number 119 is the same if you represent it in decimal (119) or binary (01110111). If this is not the case, I want to hear it from a mathemetician, not an IETF draft.

Point C is true, that's why we no longer use it. He apparently has either not read or not understood RFC 950, which describes how to get away from the unnecessarily coarse class A/B/C system, without using his equally coarse class A-1/A-2/A-3/B-1/... system.

Point D is not adequately documented to be of any use to anyone. The current IPv4 address allocation scheme still has a lot of wasted addresses, which could extend its life if tapped. I can't even tell if this scheme taps them, or if it just pushes big words around on the page.

Point E is false in this instance, since fully grocking this draft is much harder than understanding and implementing IPv6. Even if it is translated and better explained, I doubt any scheme to tap a significant number of wasted IPv4 addresses would be easier than just upgrading to IPv6. This is because most of the waste is considered "expansion space" by the owners of the network addresses. Any use of these addresses would require not only reprogramming many routers, but spending a lot more time maintaining the resulting routing tables as addresses here and there get used.

The bottom line, IPv4's not dead yet, but IPv6 is still inevitable, and this paper proposes nothing coherant.

----

For a quick introduction to some of the issues in the design of IPv6, I recommend RFC 1752 "The Recommendation for the IP Next Generation Protocol". Also peruse the RFC Index for some of the whitepapers submitted as input to the IPng process, which led to the current IPv6 Proposed Standard.

For a quick introduction to some of the issues in the design of IPv6, I recommend RFC 1752 "The Recommendation for the IP Next Generation Protocol". Also peruse the RFC Index for some of the whitepapers submitted as input to the IPng process, which led to the current IPv6 Proposed Standard.

For a quick introduction to some of the issues in the design of IPv6, I recommend RFC 1752 "The Recommendation for the IP Next Generation Protocol". Also peruse the RFC Index for some of the whitepapers submitted as input to the IPng process, which led to the current IPv6 Proposed Standard.

I've never used it, but I think something similar already exists (I could be wrong, since I didn't read the link from the story yet).

Compositional C++

-ElJefe

Here's a link that has several of the well known TCP ports. These are the common points of connection for certain services over a network. Wish I had a better explanation, but this should get you started.

fireproof wrote:

A wise man once told me "There are two ways to get something done -- the right way and the cheap way."

I've heard it a slightly different way:

Good, Fast, Cheap: Pick any two (you can't have all three)
-- From RFC 1925, The Twelve Networking Truths, by R. Callon, I.O.O.F.


----

If you want to be able to share love letters with your girlfriend but not with the spies, you could have a look at RFC 1149 which suggest a solution that might be immune to the usual packet filters (or at least it makes the filtering a bit harder for the spies). I recommend that you have a look at the "Security Considerations" chapter in that RFC, for potential risks of that solution.

Note that RFC 1149 has recently been updated by RFC 2549 which provides additional Quality of Service considerations. This is something that you should care about if you want to be sure that your message is delivered before you have switched to another girlfriend.

If you want to be able to share love letters with your girlfriend but not with the spies, you could have a look at RFC 1149 which suggest a solution that might be immune to the usual packet filters (or at least it makes the filtering a bit harder for the spies). I recommend that you have a look at the "Security Considerations" chapter in that RFC, for potential risks of that solution.

Note that RFC 1149 has recently been updated by RFC 2549 which provides additional Quality of Service considerations. This is something that you should care about if you want to be sure that your message is delivered before you have switched to another girlfriend.

I guess it depends on whether we're going for a survey of important documents (think executive summary) or an in depth catalog of every minutae that shaped the Internet, directly or indirectly.

This probably hinges on who the intended audience is. If it's for ourselves (geeks), then anything but the deep catalog will probably bore us. If it's for everyone else (non-geeks). Then anything more comprehensive than a survey of the topic will be overwhelming. I'm not implying that non-geeks are stupid, but who else but a geek would care about each individual Internet protocol? Perhaps we should do both.

For a survey level collection of important Internet documents, I'd suggest that RFC1 [ 1] is the single most important RFC, simply because it started it all. RFC2555 [ 2], a.k.a. "30 years of RFCs" would be a usefull citation for giving context to RFC1.

For in an in depth catalog, covering all relevant RFCs, the large majority (if not all) of the the work has already been done. You simply need to link to, or include the index of RFCs that form the Internet standards, RFC2500 [ 3].

Tim

[ 1] RFC 0001 Host Software

[ 2] RFC 2555 30 Years of RFCs

[ 3] RFC 2500 Internet Official Protocol Standards

DCOM is indeed publically documented. In fact, the DCOM wire protocol (ORPC) has been in the hands of the IETF since January 1998. The most recent version of the Internet-draft, which is a work-in-progress until such time as the IETF formally acts upon it, is draft-brown-dcom- v1-spec-03.txt located at ftp://ftp.isi.edu. (Be polite, substitute your local IETF mirror site if you do chase this link.) There's a header file there, written in standard C, which specifies the format of the DCOM packet header.

NSI Closes Top Level Domain Servers

NSI challenged over "obscene" domains

NSI Modifies "whois" agreement

Other related "alternative" DNS and related resources which I have seen mentioned here on /. or elsewhere: Not the European Union: eu.org (free domain names), The Internet Namespace Cooperative (provides alternative to mainstream root servers), The .us domain (an often overlooked alternative for those in the united states), Granite Canyon (free primary/secondary DNS). eu.org recently got very efficient and cleared a backlog of domains; Granite Canyon has had a lot of complaints about spotty service.

Suggested other readings: In whose domain, Exclusion and Coordination in Cyberspace, for the advanced user; Ask Mr. DNS and the FAQ for comp.protocols.tcp-ip.domains.

Here are a few more links for more information about HTTP and some neat things that are being done with it...

• Get the latest dirt from the World Wide Web Consortium.
• RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 ( text, PostScript, PDF)
• Berkeley's TranSend service is a cluster of workstations working together to act as a massive HTTP proxy. This proxy "transforms" Web pages based on clients settings. Was the basis of the ( now-commercial) Top Gun Wingman Web browser for the PalmPilot.
• The Anonymizer acts as a proxy that strips out all the unwanted/unneeded header lines that your Web browser sends.

I had started hacking together an HTTP/1.1-compliant proxy in perl that did on-the-fly compression if the client supported it, but I never got around to completing it. Initial results were impressive, especially when it was paired with a caching proxy like Squid or a CacheFlow box. Of course, with DSL and cable modems getting more widespread use, people like myself that are still pinned to a 33.6k connection are being left behind.

Caching/compressing/proxying is still in widespread usage outside North America (most notably Australia and European countries). Their problem was (is!) outrageous access prices and relatively slow overseas connections, so they've been using caching for a long time to help solve it. The US and Canada have solved their "problem" of Web pages not instantaneously loading by throwing more bandwidth at it...

Unless I missed something, the configuration was done in house. Having reps from specific companies would be the way to go. Of course neither Microsoft or Redhat is likely to release specifics: they both have their certified engineers to protect.

Another thing I saw is their client program does not use keep-alives. Any site not supporting these is just crazy. I noticed images.slashdot.org supports them, but with a limit of 5 requests and a timeout of 5 seconds. That may be fine for a local ethernet but the connection is going to close a couple of times on a dialup user like me. It is a FreeBSD box so it could run RFC 1323 or 1644 for even more speed. Linux 2.2.x has 1323 extensions on by default I think.

Unless I missed something, the configuration was done in house. Having reps from specific companies would be the way to go. Of course neither Microsoft or Redhat is likely to release specifics: they both have their certified engineers to protect.

Another thing I saw is their client program does not use keep-alives. Any site not supporting these is just crazy. I noticed images.slashdot.org supports them, but with a limit of 5 requests and a timeout of 5 seconds. That may be fine for a local ethernet but the connection is going to close a couple of times on a dialup user like me. It is a FreeBSD box so it could run RFC 1323 or 1644 for even more speed. Linux 2.2.x has 1323 extensions on by default I think.

Personally, I prefer the ball semiconductor approach for microelectronics on curved surfaces. :-)

Or for antenna-type structures, go for EFAB.

...and then there's that microphone reported a while back.

Anonymous Coward wrote:

IPv6 implies a level of object addressability that is, frankly, scary to anyone who has an iota of sense. You'll pry my non-routable addresses from my cold, dead hands.


According to the IPv6 Addressing Architecture ( RFC2373) section 2.5.8, there are plenty of non-routable IPv6 addresses. They're called "link-local" and "site-local" addresses, and each group has more addresses in it than the entire IPv4 address space.

For those of you who haven't registered your domain yet and don't care if it is a *.com,*.net or *.org domain, you might want to look into getting either a *.us or a *.nu domain.

For info on the *.us domain (wasn't too easy to find) check this out.

Among others, usnic.net seems to see *.nu domains for those interested:
http://www.usnic.net/main.htm

If you've got a static IP, you can always go the dynip.com route, too. (I perfer www.ez-ip.net, but that's just me).

Good Luck!

uselinux@email.com

On Yahoo, I found a mirror locator in addition to mirrors at Ohio State, Switzerland, Internet FAQ Consortium, Japan, California, and the United Kingdom. Also noted in the discussion is a Slashdot reader mirror which could get Slashdotted.

I don't know why some are missing (perhaps it's because they currently only exist in their original medium - typewritten hardcopy), but you can find RFC 1 at ftp://ftp.isi.edu/in-notes/rfc1.txt.

The FTP server has been /.-ed. Try:
http://info.internet.isi.edu/in-notes/rfc/files/rf c2549.txt http://info.internet.isi.edu/in-notes/rfc/files/rf c2550.txt http://info.internet.isi.edu/in-notes/rfc/files/rf c2551.txt
- Dan Anderson

The FTP server has been /.-ed. Try:
http://info.internet.isi.edu/in-notes/rfc/files/rf c2549.txt http://info.internet.isi.edu/in-notes/rfc/files/rf c2550.txt http://info.internet.isi.edu/in-notes/rfc/files/rf c2551.txt
- Dan Anderson

The FTP server has been /.-ed. Try:
http://info.internet.isi.edu/in-notes/rfc/files/rf c2549.txt http://info.internet.isi.edu/in-notes/rfc/files/rf c2550.txt http://info.internet.isi.edu/in-notes/rfc/files/rf c2551.txt
- Dan Anderson