[Ns-bugs] [Bug 1318] New: Ipv6L3Protocol::LocalDeliver doesn't process ns3::Ipv6RawSocket packets correctly

[code@nsnam.ece.gatech.edu]

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1318

           Summary: Ipv6L3Protocol::LocalDeliver doesn't process
                    ns3::Ipv6RawSocket packets correctly
           Product: ns-3
           Version: ns-3-dev
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ipv6
        AssignedTo: vincent at clarinet.u-strasbg.fr
        ReportedBy: tommaso.pecorella at unifi.it
                CC: ns-bugs at isi.edu, egamess at gmail.com
   Estimated Hours: 0.0


Created attachment 1284
  --> https://www.nsnam.org/bugzilla/attachment.cgi?id=1284
test program

The attached test program (provided by Eric) shows the bug.

The packet sent is zero-filled, and it's a Ipv6RawSocket, so basically a clean,
bare-bone IPv6 packet with a zero-filled payload. Nothing bad with it. Right?
Wrong.

Ipv6L3Protocol::LocalDeliver goes nuts.
1) it doesn't find any L4 protocol (ofc).
2) it tries to decode a ghost IPV6_EXT_HOP_BY_HOP, as nextHeader is zero
(there's NO next header at all!)

Right now using ns3::Ipv6RawSocket from an application is equivalent to
shooting in a barrel full of bugs: you'll hit one. Problem:
Ipv6L3Protocol::LocalDeliver is doing **exactly** what is supposed to do (minus
one thing, see later on).

THE problem is: IPv6 is not keen on having no L4 information in the IPv6
header, and Ipv6RawSocket does not set anything. So the packet is not
well-formed.

The correct procedure is: if you wanna use Ipv6RawSocket from anything but low
(L4) layers, you should:
1) set an L4 protocol number, even a temporary one, not conflicting with the
other ones already defined,
2) register your protocol number in the L4demux (by deriving it from
Ipv4L4Protocol) and so on.
3) etc.

Basically you have to define a L4 protocol, or things go bad. Very bad.

Now, where is the bug? The bug is that Ipv6RawSocket does exist but it
shouldn't be used at all. By anyone. Unless they do know what they're doing AND
they're setting up a new L4 protocol.

So where's the bug? In the documentation. A bug is a feature once it's
documented.

T.

Oh, forgot the "minus one thing". This is a real one. We do expect that the
extension we're reading is the right length. No check is done, not even in
debug mode, that the buffer have enough bytes to hold the option we're reading.

If, like in this case, the packet is not well formed, ns-3 will happily keep
decoding the packet. Forever...

And this is the real bug. But I don't know how to fix it.

-- 
Configure bugmail: https://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.