2

In IPv4 header, there is 3 bits field called "flags". The MSB of this field must be reset to zero (as many networking blogs say without telling why). i want to know what will happen if I managed to set that bit to 1? Why should it be zero?

Thanks in advance.

Improve this question
0

2 Answers 2

Reset to default
3

Must be zero (MBZ) is a standard convention in networking, and frequently in API design for things that have no current use but might do in the future. It is because it has no meaning that it must be 0.

You might think that doesn't make much sense. Howevr, suppose I invent IPv4+ (unlikely), and persuade IANA to allocate me that bit (fantastically unlikely). The standard can then be amended to say: set to 0 for an IPv4 packet, set to 1 for an IPv4+ packet. If people have been randomly setting it to 0 or 1 before then, I have made an extension that isn't backward compatible. It would be if people had been setting it to 0 as required.

It's very unlikely that this flag would ever be used in IPv4 but it's much better to have a spare flag and not use it, than not have one and want it.

For an idea on how it works in practice, you can look at the DNS extension (https://www.rfc-editor.org/rfc/rfc2671), which defined previously MBZ fields in the DNS header.

As you asked what would happen, the answer is probably 'ignore bit and carry on'. You might find thant some firewalls might just drop the packet though. It is the Evil bit, after all.

Improve this answer
3

The IPv4 header is defined in RFC 791 Clause 3.1.

Bit 0 in the flags field is reserved and "must be zero".

It's also called the Evil Bit and all hell will break loose if it's ever set to 1.

   Currently-assigned values are defined as follows:

   0x0  If the bit is set to 0, the packet has no evil intent.  Hosts,
        network elements, etc., SHOULD assume that the packet is
        harmless, and SHOULD NOT take any defensive measures.  (We note
        that this part of the spec is already implemented by many common
        desktop operating systems.)

   0x1  If the bit is set to 1, the packet has evil intent.  Secure
        systems SHOULD try to defend themselves against such packets.
        Insecure systems MAY chose to crash, be penetrated, etc.
Improve this answer
2
  • I am pleased to announce that the ethernet frame/packet decoder I've been working on supports "the evil bit". Here's a test case from PackageEtherCapture: "XCTAssert(ipv4.evilBit == false)" Sadly, one of the problems with IPv6 is that it does not have the evil bit functionality. :-(
    – Darrell Root
    Commented Mar 9, 2020 at 23:53
  • 2
    More seriously, one of the general guidelines for implementing IP protocols is "Postel's law" named after Jon Postel who wrote "TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others." RFC761 Section 2.10 (Robustness Principle) tools.ietf.org/html/rfc761 So obey RFC791 and do not set that bit, but if someone else sets it you should probably ignore it as a harmless error. The Evil Bit RFC is, of course, an April 1st RFC.
    – Darrell Root
    Commented Mar 9, 2020 at 23:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.