Our new mail list system (ipsec@tis.com) retransmits messages in a manner that removes the originators name (at least for the info displayed by my e-mail system). Most messages arrive as "from: ipsec-request@neptune.tis.com". If messages are not "signed", they usually appear anonymous to me. This may be a useful feature, but if you want attribution for your note please add your name in a signature line. Thanks, Paul palamber@us.oracle.com
-- BEGIN included message
- To: ipsec@tis.com
- Subject: traffic type header
- From: "ipsec-request@neptune.tis.com" <ipsec-request@neptune.tis.com>
- Date: 26 Feb 96 22:44:47
- Cc: braden@isi.edu,minshall@ipsilon.com
The suggestion has been made that we should have an optional traffic type header. That is, we need something that will disclose protocol and port numbers. The purpose would be (a) to permit traffic measurements, and (b) to permit routers to optimize their handling of certain kinds of traffic. (And yes, it's optional, in case traffic analysis is your foe.) Neither IPv6 flows nor IPv4 traffic types are a substitute. Apart from the fact that the former isn't here yet and the latter isn't used, they just don't disclose enough information. But if you're engineering a network, you need to know these things. To give just one example, the amount of http traffic to particular places can be used to justify or refute the need for an organizational Web proxy. As a strawman proposal, let me propose the following header format: u_char next_proto; u_char this_proto; short pad; u_short src_port; u_short dst_port; Arguably, pad should be length, in which case we could have two optional fields: struct in_addr src_host, dst_host; to account for tunnel mode. (Tunnel mode is useful even if you're not trying to hide the host names.) An alternate mechanism would be to define new transforms; if nothing else, that would avoid adding yet another header to the protocol type namespace. It would also be simpler to implement; the obvious ways to do this in a BSD-derived kernel or a streams-based kernel just don't work very well. If there's enough interest (and, of course, not too much opposition), I'll volunteer to write a draft RFC.
-- END included message