Slashdot Mirror

It's faster than IP-over-Bird.

Is it just me, or is assuring the quality of open source projects (both in terms of openness and functionality) more or less impossible? I mean, by its nature, open source holds no associations to any governing bodies that carry sway. There's the argument that accepted standards organizations for open source just don't exist, but that's not even true...it's more a case of public trust being a fickle thing.

Industries that market tangible products have no problems creating standardization bureaus and bodies, usually because these sorts of things can be governed in turn by governments, by qualified authorities, by laws. Could the FCC have been created without respected, universally trusted leadership? Doubtful. Who then will take on the challenge of developing an overseer for open-source?

It has been tried...there are any number of open-source websites that act as collectives for development. There have been attempts to create instituions of authority as well, notably the group led by Eric S. Raymond, the Open Source Initiative, which has had undetermined effectiveness, as far as i can tell. Still, i can't help but think that, currently, excellent open source becomes accepted by reputation, and reputation alone.

I wonder if this lab will have the power to start the responsible monitoring of open source...just an interesting idea. Really, do we even need such a system, or can the open Freshmeat bazaar and word of mouth serve as adequate testing grounds? Sometimes i think it would take an organization with direct influence over the net, like the IETF or ISOC to get the ball rolling...from innovators to watchdogs.

If anyone else knows of any other certitification programs for open source, i'd like to hear about them.

-j

• First, my prediction: they'll eventually chose to open up the SLD to follow the UK conventions of .co.uk, org.uk, ac.uk
• Second; a comparison. For some time, the registrars of the .nhs.uk namespace tried to enforce a similar root structure of institution.area.nhs.uk. Sadly they caused suffering on a scale comparable with 1480, coming up with snappy domains like:
  • leicester-ha.trent.nhs.uk
  • northants-ha.anglox.nhs.uk
  • sw-devon-ha.swest.nhs.uk
  all of which are rather like 1480's examples of
  • IVY.PRS.K12.NJ.US
  • DMHS.JCPS.K12.KY.US
  • OHS.EUNION.K12.CA.US
  Are any of these domains memorable (or even vaguely comprehensible)? No. Thats why 1480 and the UK NHS namespace people both fail.
• Finally, given the abject failure of nic.gov to prevent politicians from running a coach and four horses through RFC 2146 in the matter of GOP.GOV, FREEDOM.GOV and FLATTAX.GOV (see slashdot passem 1, 2) we can have little confidence that the same government will manage to do other than screw up .US

A cryptographic hash takes an exact set of bits to result in the hash, a very exclusive operation. It's excluding all of the wrong values. If any of the bits in the configuration are slightly off, then there's a very high likelyhood that the hash will be completely different.

I believe common sense will tell you it is easier to do that than to loosely define a large set of bits that will result in the same hash. And furthermore, the boundary for the bit bag is defined by human intuition (psychoacustics) and empirical research (trial and error).

Granted, lots of hashes are created by people tinkering with an algorithm, but there are excruciatingly detailed and highly refined tests that'll tell how good the algorithm is. The development of the algorithms and tests are based on information theory and statistics.

What are the tests for the audio fingerprinting based on? The answer appears to be our grossly underdeveloped understanding about how the human mind processes sound all the way through to making comparisons between different samples of music. I seriously doubt that something hinging on human intuition and interpretation as part of the algorithm can overcome the fact we don't understand how people's mind work to any acceptable degree.

I spent some time thinking about a way to fingerprint music, and it is a very hard problem to come up with something that captures the essense of our perception of music. Simply doing that is a huge accomplishment. It involves distilling down human methodology for sound recognition, something that is based on a massivly parralel biochemical neural network, or at least something we can only crudely model as a neural network, into a mathematical formula that can be implemented efficiently on a processor.

It is much more likely this won't work because there's a fundamental difference in the platform these two tasks are done on: subjective analysis by a person of some music as to what is and is not the same and some convoluted algorithm attempting to approximate that process on a von-neuman style computer. I won't hold my breath, no matter how cool the idea is. And it is very cool.

They would probably have better luck building a neural network and training it against a large set of people to attempt to capture their collective equality operation

I doubt they will reach their goal, but if they can come up with an algorithm that reasonably sorts music the way people do and to satisfactorally compare music, it will still be very powerful. I personally would love to see such technology be successful.

The ability to emulate how people discern music and to detect differences between samples is tremendous. If nothing else I can finally catalog my music intelligently and to seek new music that will be something I very likely will dig.

Imagine listening to a song that really scratches an itch, taking the fingerprint of that song, even if it is from the radio and getting songs that scratch the itch the same way from a database. How cool would that be?

Not only that, but we'd need that sort of technology in order to find musicians and bands (there is a distinction) that we like if there isn't a huge mega-media-greedy conglomerate driving the mindshare and play time. Combine that with reputation certificates and something like SPKI and you've got a very successful way to implement the Street Performer's Protocol (see the recent /. story)

A reputation certificate is similar in concept to what eBay does with its sellers in capturing the history of the person to create a mark of how reputable that person or entity is, but it goes one step further and cryptographically binds that information to to an identity. See the SPKI document above for detailed information.

This is stuff that needs to be worked on and I salute tuneprint for working towards that goal.

There would be a whole different debate if AOL had sanctioned an official release of Gnutella (after the fashion of the Napster trial), but considering that Gnutella was allegedly developed and released without their consent, it would seem that there is little ground for them to be held liable. Can you be held liable for something that an employee of yours does without your permission? Seems a little dubious. The last time that I checked, development on the origonal Nullsoft Gnutella client had stopped at the Gnutella site in favor of clonese using the same protocol, meaning that they would be basically sued for the development of a communications protocol. Maybe we ought to go after the authors of The Infinite Monkey Protocol for cruelty to animals. . .

"Sweet creeping zombie Jesus!"

I believe you are thinking of RFC #1217, "Memo from the Consortium for Slow Commotion Research (CSCR)." From the RFC:

The basic unit is the M1A1 tank. Each tank is labelled with the number 0 or 1 painted four feet high on the tank turret in yellow, day-glo luminescent paint.

If you find that one to hard to use, you may wish to instead attempt to use RFC #1149 which has been updated by RFC #2549 to send IP information using little scrolls and swallows. (Actually, the bird type is unspecified and is left to the implementation.) Unfortunately, the latter types do not work under Linux implementations, since they have had troubles getting the penguins to fly.

I believe you are thinking of RFC #1217, "Memo from the Consortium for Slow Commotion Research (CSCR)." From the RFC:

The basic unit is the M1A1 tank. Each tank is labelled with the number 0 or 1 painted four feet high on the tank turret in yellow, day-glo luminescent paint.

If you find that one to hard to use, you may wish to instead attempt to use RFC #1149 which has been updated by RFC #2549 to send IP information using little scrolls and swallows. (Actually, the bird type is unspecified and is left to the implementation.) Unfortunately, the latter types do not work under Linux implementations, since they have had troubles getting the penguins to fly.

I believe you are thinking of RFC #1217, "Memo from the Consortium for Slow Commotion Research (CSCR)." From the RFC:

The basic unit is the M1A1 tank. Each tank is labelled with the number 0 or 1 painted four feet high on the tank turret in yellow, day-glo luminescent paint.

If you find that one to hard to use, you may wish to instead attempt to use RFC #1149 which has been updated by RFC #2549 to send IP information using little scrolls and swallows. (Actually, the bird type is unspecified and is left to the implementation.) Unfortunately, the latter types do not work under Linux implementations, since they have had troubles getting the penguins to fly.

A lot of these research projects are funded by the millitary, because ad-hoc networks are an obvious solution for situations where you don't have or cannot trust the infrastructured networks (be they wireless or wired).

Both wireless LAN and Bluetooth are capable of ad-hoc networks, but higher layers (the IP layer) must have some form of configuration to talk to each other. This is being developed in the IETF in the MANET and ZeroConf working groups.

Speed of these networks will improve over time, the other developments are at least as important and they will take some more years to mature I believe, so when it all comes together, heaven is upon us ;-)

Another interesting subject is ubiquitos or pervasive Internet. Meaning the accessibility of Internet in all (reasonably capable) devices and in all physical locations.
One complication is that Internet should not just be accessible to the rich, but also the poor and the people in the developing countries (this is important for a lot of reasons, but I digress...)

A lot of these research projects are funded by the millitary, because ad-hoc networks are an obvious solution for situations where you don't have or cannot trust the infrastructured networks (be they wireless or wired).

Both wireless LAN and Bluetooth are capable of ad-hoc networks, but higher layers (the IP layer) must have some form of configuration to talk to each other. This is being developed in the IETF in the MANET and ZeroConf working groups.

Speed of these networks will improve over time, the other developments are at least as important and they will take some more years to mature I believe, so when it all comes together, heaven is upon us ;-)

Another interesting subject is ubiquitos or pervasive Internet. Meaning the accessibility of Internet in all (reasonably capable) devices and in all physical locations.
One complication is that Internet should not just be accessible to the rich, but also the poor and the people in the developing countries (this is important for a lot of reasons, but I digress...)

Haven't you read RFC 1437?

ShareZilla is network abuse and Gnutella itself isn't? That's rich. (I'm one of those annoying gits who think that tcp/80 ought to be used for http and if you're running something other than http over that port, then you're abusing the network. Gnutella shouldn't let users bind below tcp/1024. It's that simple.)

About ShareZilla-- I'm laughing my sorry ass off. All those boneheads who were hyping Gnutella when it first arrived on the scene should have listened to us oldtimers who were telling you that, as an application protocol, it sucks rocks. You're getting what you asked for.

ShareZilla is only the beginning. I'm waiting for the real fun to begin when the blackhats start swinging their malevolent gaze around to it. If you want to prevent network abuse you have to design the network to resist tampering by abusers.

The Gnutella network is a child's toy. (And Jason, if you're reading this, you should read this and give me a call. I may have a hobby project for you.)

Could I suggest someone protests to the delegated naming authority, which is listed as:

Federal Networking Council
4001 N. Fairfax Drive
Arlington, VA 22203
Phone: (703) 522-6410
EMail: execdir@fnc.gov
URL: http://www.fnc.gov

.

--

The Jabber folks did submit an RFC -- it's here.

It's based on IPP, the Internet Printing Protocol, which is being standardized by the IETF.

The correct Transport Layer Security RFC is 2246, not 2446. It is available at http://www.ietf.org/rfc/rfc2246.txt

DHCP does more than hand out dynamic IPs...the server tells the client about who the DNS servers are on its network, what the subnet mask is, etc. What you're really asking is "will dynamic IP addresses die". DHCP is potentially very useful even if you're not using dynamic addressing. Nitpicking, perhaps, but I see this misconception about the purpose of DHCP far too often. It is actually quite underutilized IMO.

All of this is taken care of for you in IPv6 as well, albeit in a different sort of way. The subnet mask is handled by "Router Advertisements", DNS is handled by an "All DNS Servers" multicast (if I remember correctly, I could be wrong - this may be an advertisement as well), etc. IPv6 is truly a next generation protocol in *many* ways. There is a DHCPv6 spec, but I doubt that many (if any) installations will have to use it as all of the functionality in DHCPv4 is automatic in IPv6 via its 'stateless autoconfiguration'.

For more information, see:

• RFC 2462, "IPv6 Stateless Address Autoconfiguration"
• RFC 2461, "Neighbor Discovery for IP Version 6 (IPv6)"
• RFC 1883, "Internet Protocol, Version 6 (IPv6)"

Every IPv6 RFC I've read (that I can remember) has been a good read, so check 'em out. :-)

DHCP does more than hand out dynamic IPs...the server tells the client about who the DNS servers are on its network, what the subnet mask is, etc. What you're really asking is "will dynamic IP addresses die". DHCP is potentially very useful even if you're not using dynamic addressing. Nitpicking, perhaps, but I see this misconception about the purpose of DHCP far too often. It is actually quite underutilized IMO.

All of this is taken care of for you in IPv6 as well, albeit in a different sort of way. The subnet mask is handled by "Router Advertisements", DNS is handled by an "All DNS Servers" multicast (if I remember correctly, I could be wrong - this may be an advertisement as well), etc. IPv6 is truly a next generation protocol in *many* ways. There is a DHCPv6 spec, but I doubt that many (if any) installations will have to use it as all of the functionality in DHCPv4 is automatic in IPv6 via its 'stateless autoconfiguration'.

For more information, see:

• RFC 2462, "IPv6 Stateless Address Autoconfiguration"
• RFC 2461, "Neighbor Discovery for IP Version 6 (IPv6)"
• RFC 1883, "Internet Protocol, Version 6 (IPv6)"

Every IPv6 RFC I've read (that I can remember) has been a good read, so check 'em out. :-)

DHCP does more than hand out dynamic IPs...the server tells the client about who the DNS servers are on its network, what the subnet mask is, etc. What you're really asking is "will dynamic IP addresses die". DHCP is potentially very useful even if you're not using dynamic addressing. Nitpicking, perhaps, but I see this misconception about the purpose of DHCP far too often. It is actually quite underutilized IMO.

All of this is taken care of for you in IPv6 as well, albeit in a different sort of way. The subnet mask is handled by "Router Advertisements", DNS is handled by an "All DNS Servers" multicast (if I remember correctly, I could be wrong - this may be an advertisement as well), etc. IPv6 is truly a next generation protocol in *many* ways. There is a DHCPv6 spec, but I doubt that many (if any) installations will have to use it as all of the functionality in DHCPv4 is automatic in IPv6 via its 'stateless autoconfiguration'.

For more information, see:

• RFC 2462, "IPv6 Stateless Address Autoconfiguration"
• RFC 2461, "Neighbor Discovery for IP Version 6 (IPv6)"
• RFC 1883, "Internet Protocol, Version 6 (IPv6)"

Every IPv6 RFC I've read (that I can remember) has been a good read, so check 'em out. :-)

Some links:
Sun http://www.sun.com/software/solaris/ipv6/
IBM http://domino.ngi.ibm.com/patrick /pages/ipv6.html
Cisco http://www.cisco.com/warp /public/784/packet/july98/9.html
W3C W3c site and mailing list search
IETF http://www.ietf.org/html.charter s/nat-charter.html
___

And you don't even have to wait for your ISP to support it. Just turn on 6to4, and with one IPv4 address you can get quite a few IPv6 subnets (each of which contains 2^64 addresses).

Windows already supports 6to4, BSD probably does, and I don't know about Linux.

There is an IETF draft for doing FTP over SSL. Widespread use of SSL(except through browsers) is still not possible because of the RSA patent(which lapses soon).

C: REQ . 1 14 94 0
C:
C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start>
C: END

Longer, more complicated examples are shown later, but this pretty clearly illustrates there probably won't be significant overhead.

Here is another internet draft, which describes the thinking that went into the design of the protocol.

Actually, content was the whole point behind the protocol. We were trying to solve a class of problems, all driven by content requirements. Examples are the SEC's EDGAR database, a variety of other "deep wells", and a class of problems ranging from mapping network topology to creating personalized "maps" (views) of the Internet. See here for more on the philosophy behind the content requirements.

The protocol emerged from long discussions about how to solve these content problems. We tried as hard as possible to reuse existing protocol infrastructure, but quickly found that there were no protocols that handled the metadata problems we were trying to attack.

The (IMHO) brilliant thing Marshall did was to build two levels into the solution. BXXP is the general-purpose framework that was used for the Simple Exchange Profile application we were going for in the first place. The nice thing was that BXXP works for a broad range of other applications, such as asynchronous messaging.

The bottom line is why reinvent the wheel more than once?

Carl

Here is the IETF working draft of the protocol. Lots of good info on the architecture of the protocol.

However, many problems still plague the infant platform such as standards and a central company to enforce those standards.

I apologise. I have clearly spent the whole of my life misunderstanding standards. Apparently, you need a central company to enforce them. I am so sorry for having thought that open standards work, and closed ones don't. Where do I sign up for re-education?

Please, just look at which standards are used and which aren't. TCP/IP is used by quite a lot of systems. AppleTalk isn't. FTP is used a fair bit. ICQ's proprietary 'send file' doesn't seem to be very popular outside AOL. More people use Ethernet on LANs than use Myrinet (which is often faster). More VCRs use VHS than (the technologically superior) Betamax.

What do the successful standards have in common, I wonder? Are they managed by a single company? I think not.

A standard is only succesful if it is truly open. If it's not, why should I (or anyone else) invest time, effort and shedloads of money developing for it? What's the guarantee that the 'controller' of the standard won't change it tomorrow for competitive advantage? Ever looked at Microsoft Office file formats? They are almost always incompatible between versions.

Succesful standards are there because they get used by lots of people. They get used by lots of people because those users believe that the standard will be stable, and that they can (if neccesary) influence development of the standard.

If you want a gaming standard for Linux (by which I assume you really mean X), then propose one. Invite the interested parties to contribute. Encourage feedback. Keep the process open. I'll say that again: Keep the process open.

Who do you trust for Internet standards? IETF or Microsith?

.sig missing due to ethanol consumption

IMXP is, as the authors of the IETF draft put it, "extensible, asynchronous message relaying service for application layer programs."

Another way to look at IMXP is a kind of SMTP for instant messaging, except that communication takes place in XML instead of some other format, and instead of handling mail messages, IMXP handles IM requests and responses.

IMXP is implemented as a profile for a new protocol framework called BXXP, or the Blocks eXtensible eXchange Protocol. This protocol framework also uses XML instead of some other format to specify authentication and transport security, as well as the type of data communication profile used between two endpoints.

Here is more information about BXXP.

............ kris

Kris Magnusson
Director, Developer Relations

UPnP has several IETF drafts, and SLP does not cover the Auto-IP solved problem.

I do like the fact that SSDP utilizes XML to encode the service data, this makes it extremely flexible.

UPnP has several IETF drafts, and SLP does not cover the Auto-IP solved problem.

I do like the fact that SSDP utilizes XML to encode the service data, this makes it extremely flexible.

UPnP has several IETF drafts, and SLP does not cover the Auto-IP solved problem.

I do like the fact that SSDP utilizes XML to encode the service data, this makes it extremely flexible.

The main trend I have noticed from this is that the number of RFC's produced has increased dramatically, and there are now competing RFCs and drafts sponsored by different commercial interests that are intended to handle basically the same problem. This is in part because some of the companies in question use the fact that there is an RFC for their implementation as a marketing tool.

The upside is of course there are a lot more resources devoted to working on problems. I would imagine that the situation with Open Source software will be better than that in the IETF because GPL is not (yet?) a sticker that can be put on something to make it more marketable.

Well, if it's only a few km away, you could try the link proposed in RFC1149.

------

Nautilus is an open-source file manager and graphical shell being developed by Eazel, Inc. and others. It is part of the GNOME project, and its source code can be found in the GNOME CVS repository. Nautilus is still in the early stages of development. It will become an integral part of the GNOME desktop environment when it is finished.

• Nautilus Mailing List
• Nautilus Bug Database
• Nautilus Change Log
• Nautilus Screen Shots

Nautilus has many neat features, including:

• Bookmarks to local directories or files
• Graphics such as XPM and PNG have icons of their contents
• Zooming is supported
• Nautilus can display files in List view
• Any URI can have notes attached to it
• The man: URL scheme points to man pages
• Icons can be stretched
• JPEGs and other images can be displayed and edited with the GIMP
• MIME Content-Type header is shown
• New tabs can be created
• Text files contain preview of file using head command
• Eazel can be config ured
• Folder icon
• MP3s can be played and information on them can be viewed
• Root directory (file:///) view
• Gataxx
• Deskto p view
• Web DAV can be used. WebDAV is HTTP Extensions for Distributed Authoring, RFC2518 describes the official WebDAV standard

[Steve Golldsmiths] assessment of his agent's abilities is blunt: "If every node on the Internet was run by one of these agents, the I-Love-You virus would not have got beyond the first machine." ... decentralised control makes each agent autonomous yet cooperative ... Cyberagents faced with a runaway barrage of incoming network requests close the gates of the system to prevent it from being flooded.

Closing the gates doesn't stop a DDos attack, it merely limits the damage which can be caused. One defence mechanism is having redundant links which are 'turned on' when currently active links come under attack. If you detect the attack quickly enough, it is, theoretically, possible to redirect valid connections to your new links. In practice it's difficult to implement as you run the risk of redirecting the attackers to your new links too. Of course the attack is still effective, it's closed rendered the link that was there useless, and should the attackers be dynamic enough, the can start attacking the new links.

Sandia's system offers up a new defence - Assume multiple ISPs had agents deployed, say ISP A comes under an attack routed through ISP B from a user connected to ISP C.

Assuming also that the ISPs cooperated, their agents would have a certain level of trust. ISP A's agents could, upon detecting an attack, seek help from ISP B's agents. ISP B then filters that route, and asks ISP C what the hell is going on. And so forth. Of course, one ISPs bot couldn't control another, but I think them saying "Help!!! I'm getting these from here. Please make them go away..." is acceptable.

The thing I don't like about this however is the trust issue. As they say, Trust no one. Practical authentication methods are never 100% reliable. Distributed security agents should never have to trust anybody else. If they do, they run the risk of being compromised if the trusted party is compromised. I accept that trust is neccessary in order that network immune systems, anti-virus distributors, and agents like these are effective. But the control that one agent has over another agent is something to be wary of. I'm wondering whether Santia may opensource their non-munitions version when it's releaed. They appear keen on the idea of their system being implemented worldwide. Of course, if they didn't opensource, then its all just a government plot to control the world. :)

The other defence of course, is everybody could just implement RFC 2267 to prevents address spoofing.

"A goldfish was his muse, eternally amused"

As for a public implementation - I should have a Linux VRRP implementation out this week.

Very interesting. I suppose that this is related to http://sourceforge.net/project/?group_id=2181, or is that a different project?

As for VRRP, I believe that an accurate description of the protocol is available here

Has anyone considered VRRP (Virtual Router Redundancy Protocol)? It's an actual open standard, and it works. It not only works, it works amazingly well.

One of the major users of VRRP technology is Nokia. They've done extensive work on the protocol, and use it in their line of firewalls (which btw run a heavily modified FreeBSD codebase).

VRRP uses multicast packets that are similar to OSPF "Hello" packets to let the partner(s) know it is alive. If the primary machine dies, the backup instantly takes over. When the takeover happens, it not only assumes the IP address of the dead machine, but it also answers for the MAC address of the dead machine.
--

When a specification is updated, a new RFC is posted. If a new RFC was written for Kerberos v6 (or whatever Clifford Neuman wants to call it), Microsoft could still (rightfully) claim full compliance with the original Kerberos specification (RFC 1510).

My personal take on this is that it's sour grapes. It appears to me that the other commercial Kerberos implementations are not fully compatible with MIT v5 either, and probably for the same or similar reasons, and where's the righteous indignation about those?

CyberSafe's TrustBroker (Acrobat Reader needed) indicates in it's FAQ that it's compatible "at the protocol layer", and strongly implies that there are interoperability problems or limitations.

DCE Kerberos is not interoperable with MIT's implementation. I don't see anyone screaming about that.

I'd like to see a reasonable discourse on this issue, without all the "Evil Micro$oft" rhetoric. Should standards all be written in such a way that no one is free to innovate?

Here's a side note. Regardless of what OS you use, don't you advocate the spread of Kerberos as an authentication protocol standard? If so, you should probably be grateful. I'll bet more computers have been running Kerberos since February than have ever run it before.

RFC2826, which was issued last week, is an IAB comment on this kind of unilateral TLD "creation" by third parties. The use of non-standard DNS roots is generally a Bad Thing as it creates all kinds of problems, not only limited to breaking the global nature of the DNS namespace. In summary, the IAB are of the view that a globally unique DNS root is essential, and that isn't going to change.

The problem with this alleged TLD is that it will only be visible for people using this guy's root servers, rather than the standard Internet roots. In other words, it's not a proper TLD and therefore sucks. It's just gold-digging.

1. RFC 2309
describes the need for some kind of proactive congestion control to
deal with protocols that do not implement any kind of backoff. This
proposal spawned a whole lot of research into testing for fairness.
Sally Floyd, one of the authors of the RFC, has the slides (PS) for a
talk which gives a good basic overview of the issues.

2. A standard for congestion control is proposed in RFC 2481. It is easy
to spot abuse by end users who claim to comply with this proposal.

I'll ask about the blacklisting and post here when I have some
references.

1. RFC 2309
describes the need for some kind of proactive congestion control to
deal with protocols that do not implement any kind of backoff. This
proposal spawned a whole lot of research into testing for fairness.
Sally Floyd, one of the authors of the RFC, has the slides (PS) for a
talk which gives a good basic overview of the issues.

2. A standard for congestion control is proposed in RFC 2481. It is easy
to spot abuse by end users who claim to comply with this proposal.

I'll ask about the blacklisting and post here when I have some
references.

Basically roughly every 20,000 packets, a router chooses a packet at random and sends an ICMP traceback message to the packet's destination listing the router's address and the previous and next hop that the data packet took. At the receiver, if you're being seriously flooded, you start monitoring the traceback packets and when you get enough you can piece together the paths back to the attackers.

It won't stop the attack itself, but will at least help in discovering the cracked hosts being used to launch the attack.

-Fzz

If you want the low-down information, the obvious thing to do is check out the RFCs. Here are several that I have found interesting:

• RFC1883, a top-level specification of IPv6 which includes ALL KINDS of cool stuff. If you're only going to read one, make it this one.
• RFC2374, which involves assigning Unicast (like the IPv4 address you have now, only bigger) addresses
• RFC2462, stateless autoconfiguration; why many hosts won't need DHCP any more

• These documents barely scratch the surface, but they're interesting and they have splendid references. :-) For random RFCs, go to http://www.ietf.org/rfc/rfc####.txt, where #### is, obviously, the RFC number. Happy reading...

If you want the low-down information, the obvious thing to do is check out the RFCs. Here are several that I have found interesting:

• RFC1883, a top-level specification of IPv6 which includes ALL KINDS of cool stuff. If you're only going to read one, make it this one.
• RFC2374, which involves assigning Unicast (like the IPv4 address you have now, only bigger) addresses
• RFC2462, stateless autoconfiguration; why many hosts won't need DHCP any more

• These documents barely scratch the surface, but they're interesting and they have splendid references. :-) For random RFCs, go to http://www.ietf.org/rfc/rfc####.txt, where #### is, obviously, the RFC number. Happy reading...

If you want the low-down information, the obvious thing to do is check out the RFCs. Here are several that I have found interesting:

• RFC1883, a top-level specification of IPv6 which includes ALL KINDS of cool stuff. If you're only going to read one, make it this one.
• RFC2374, which involves assigning Unicast (like the IPv4 address you have now, only bigger) addresses
• RFC2462, stateless autoconfiguration; why many hosts won't need DHCP any more

• These documents barely scratch the surface, but they're interesting and they have splendid references. :-) For random RFCs, go to http://www.ietf.org/rfc/rfc####.txt, where #### is, obviously, the RFC number. Happy reading...

You're both sorely in need of catching up with the program:

RFC 2246 defines (and has for well over a year now) the protocol, and the latest commercial releases of sendmail implement it.

So does the Sun Internet Mail Server

Finally, Weitse Venema's postfix MTA has a freely-available TLS patch that implements SMTP encryption for those of us who don't want to pay for it.

There's even an RPM available.

Postfix, BTW, which used to be called vmailer, is the IBM Alphaworks free MTA project that was covered here in /. back in the day.

As, indeed, was this entire portion of this thread.

--

The nature of the internet is 2-way not broadcast communications. This talk about broadcasted data seems a lot like the promise of satellite Internet (eg give us a big pipe to suck on, but then make us dial in to upload anything) Check out the IETF's MANET to see what the spectrum really should be used for. Wireless, high-speed, free internet for all. With little difference between router's and hosts.

• RFC 2295: Transparent Content Negotiation in HTTP
• RFC 2296: HTTP Remote Variant Selection Algorithm -- RVSA/1.0

• RFC 2295: Transparent Content Negotiation in HTTP
• RFC 2296: HTTP Remote Variant Selection Algorithm -- RVSA/1.0