Talk:Evil bit

Untitled

I thought "evil bit" could also refer to the phenomenon in campy science fiction, in which an AI could turn from good to evil at the flip of a switch. --π! 21:22, 20 July 2006 (UTC)

Possible use for the field?

Wouldn't it be possible for intrusion detection software running on an Internet-facing firewall to use this field to indicate, on a local network, whether the packet is likely part of a possible intrusion? Has such a proposal been reported in a reliable source? --Damian Yerrick (☎) 18:25, 12 October 2006 (UTC)

This RFC is contradicting to other existing standards, which may render the whole internet inoperable, therefore it cannot be implemented. From the RFC, "Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil bit on such packets. "Transparent" http and email proxies SHOULD set the evil bit on their reply packets to the innocent client host.", obviously it is common case in the network. Also, who can prove that the evil bit can be set correctly, hackers obvious don't want this evil bit to be set by themselves :-) . This is the point of this April Fool's RFC. See RFC 3751 — Omniscience Protocol Requirements, which is a very similar self-contradicting joke. --Leeyc0 (Talk) 03:50, 12 January 2007 (UTC)

Any known implementation in the wild?

Is there any trojan/worm/virus/spam that has been known to set this bit? I could easily imagine some hacker implementing it as a joke, knowing that no hardware will filter it. 129.42.208.182 18:25, 11 September 2007 (UTC)

To my knowledge: no, but i think nmap supports it. cavac (talk) 10:44, 26 May 2009 (UTC)

Expected behavior of network equipment

I'm the guy who ported the FreeBSD patch to FreeBSD 7 and did some tests. Most network equipment does indeed leave the bit "as is" (although some don't, which helps in identifying the operating systems used). The Bit is actually reserved for future use as an additional fragmentation option.

Therefore, my interpretation of the RFCs in respect to the correct handling of packets with this bit set would be thus: Network equipment that does NOT work with the payload should forward the packet as is (in the future, this might be a valid fragment of a packet), equipment that does work on the payload - like endpoints and high-level routing equipment - must drop the packets because they don't understand that fragmentation option (it's now undefined - when it's defined, that equipment will need a software/firmware update to handle the packets correctly). Network equipment that drops the packet should also respond with ICMP type 12 code 0 packet (Parameter Problem: Bad IP header / Pointer indicates the error) with the pointer set to the FLAGS field... While that seems to be indicated by the various RFC's, it's not written down like that (e.g. original research). If i put a documentation about that on my homepage, would this still count as original research, even though i'm the guy who wrote big parts of the code? cavac (talk) 10:44, 26 May 2009 (UTC)

Synonym or Metaphor?

The article uses the word synonym where metaphor might be more appropriate.

I don't know enough about editing etiquette to start editing main text and invoking reversion engines and all that. — Preceding unsigned comment added by Hicksw (talk • contribs) 15:51, 5 July 2018 (UTC)