4

As stated in IEEE 802.3 section 3.2.6 the former Ethertype field can be used as a length field with a value <= 1500. Now I wonder how such packets are handled regarding the upper next layer. Can Ethernet frames, with the length field used, still contain e.g. an IP packet? If yes, how can a router or PC detect this? And what will a router typically do with a frame using length instead of Ethertype?

Or more generally asked: How will the receiver decide on how to handle the payload data if no Ethertype but length is specified?

1
  • The background for this question is this: I would like to implement a proprietary protocol on top of 802.3 MAC frames and use the length field. So, what will using the length field imply for other hard- and software? E.g. will it be safe to send such frames to cots systems, which will not know about my protocol inside.
    – Christian
    Commented Jul 20, 2015 at 8:35

2 Answers 2

4

Can Ethernet frames, with the length field used, still contain e.g. an IP packet?

Yes, you're asking about IP over 802.3 SNAP frames, which is covered in RFC 1042.

A 802.3 SNAP IPv4 frame looks like this...

+----+----+----+----+----+----+----+----+---------+-----+
| DA | SA |  L | DS | SS | CL | OI | ET | Payload | FCS |
+----+----+----+----+----+----+----+----+---------+-----+
  • DA: Destination Mac Addr (6 Bytes)
  • SA: Source Mac Addr (6 Bytes)
  • L: Length (2-Bytes); (Length <= 0x05DC hex, or 1500 decimal)
  • DS: DSAP (1-Byte); (DSAP == 0xAA hex, or 170 decimal)
  • SS: SSAP (1-Byte); (SSAP == 0xAA hex, or 170 decimal)
  • CL: Control (1-Byte); (Control == 0x03 hex, or 3 decimal)
  • OI: Organizationally Unique Identifier (3-Bytes); (OUI == 0x000000 hex, or 0 decimal)
  • ET: Ethertype (2-Bytes); (Ethertype == 0x0800 hex, or 2048 decimal)
  • Payload: Ethernet Payload (Ethernet Payload <= 1492 Bytes); this payload size includes the size of the IPv4 header.
  • FCS: Frame Checksum (4-Bytes)

If yes, how can a router or PC detect this?

By "detect this", I assume you mean IP over 802.3 SNAP; the SNAP frame is first distinguished from an Ether II / ARPA frame because Type / Length <= 0x05DC hex. Then the router looks at the other fields specified above...

Computers have to be explicitly configured with SNAP encapsulation, to include a lower-than normal MTU (IP MTU <= 1492 bytes). While it's theoretically possible to include 802.3 SNAP IPv4 in the broadcast domain as Ethernet II (ARPA), most people would think you're crazy to do so.

And what will a router typically do with a frame using length instead of Ethertype?

There aren't many 802.3 IP SNAP networks left... Cisco IOS used to process IPv4 over SNAP in the punt path; but I haven't looked at this in depth in a long time.

To test with recent Cisco IOS, I attempted to ping one of my Cisco 3560 switches (debug ip icmp enabled) with an 802.3 SNAP IPv4 frame, but the switch just gave me dumb looks...

[mpenning@tsunami ~]$ sudo python
Python 2.7.3 (default, Jan  2 2013, 13:56:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from scapy.all import SNAP, Dot3, LLC, IP, ICMP
>>> from scapy.all import srp1
>>> pak = Dot3(dst="64:ae:de:ad:be:ef", src="80:ee:73:20:00:00") / LLC() / SNAP() / IP(src="10.0.0.5", dst="10.0.0.1") / ICMP()
>>> pak
<Dot3  dst=64:ae:de:ad:be:ef src=80:ee:73:20:00:00 |
<LLC  dsap=0xaa ssap=0xaa ctrl=3 |<SNAP  code=0x800 |
<IP  frag=0 proto=icmp dst=10.0.0.1 |<ICMP  |>>>>>
>>> srp1(pak)
Begin emission:
Finished to send 1 packets.
...................^C
Received 19 packets, got 0 answers, remaining 1 packets

Christian said: The background for this question is this: I would like to implement a proprietary protocol on top of 802.3 MAC frames and use the length field. So, what will using the length field imply for other hard- and software? E.g. will it be safe to send such frames to cots systems, which will not know about my protocol inside.

I personally would discourage you from implementing a private ethernet protocol; people did this kind of thing all the time twenty or thirty years ago, but it's increasingly rare to find custom protocols today.

Why? It just doesn't make sense for the exactly the reason you're asking. Practically the entire world uses "something" on top of IPv4 or IPv6.

  • UDP is available if you want a "connectionless" service
  • TCP or SCTP are good choices for "connection-oriented" services

What happens if you build your own protocol?

  • It's hard to talk to anything else, even on the same ethernet broadcast domain... because other things invariably are using IP and ethertype (RFC 894) frames.

  • You've got no routing (i.e. the capability to send traffic across multiple ethernet broadcast domains, such as the networks people build between cities and countries); this also means you could be doing stuff like bridging across the internet, which requires building IP tunnels.

  • Do you want network services? Guess what you get to build:

    • Want file transfers? Build your own FTP or TFTP
    • Want name resolution? Build your own DNS
    • Want network errors and monitoring? Build your own ICMP protocols
    • Want security? Build your own firewalls, encryption, and PKI (ick)
    • Want to talk to other computers? Build kernel drivers for those operating systems (see below)

Speaking broadly, custom ethernet protocols require a kernel driver for all operating systems in question; do you really want to build and distribute a kernel driver? If you use IP it's simpler, because you can have services listening on top of an existing IP kernel driver; just bind to a port number and leverage the built-in IP kernel drivers.

However, building with IP comes at the cost of using Ethernet II (ARPA) encapsulation (i.e. no length field in the ethernet frame).

Maybe you still want to use your own custom ethernet protocol; at least by now you understand more about the associated tradeoffs.

5
  • RFC 1042 is not used since a long time. it was for a multiprotocol environnment, 802.3, 802.4 and 802.5. In 802.3, RFC 894 is applicable: IP is directly over MAC. Best regards, Michel
    – Michelo
    Commented Jul 18, 2015 at 19:50
  • That's interesting. For me this answer sounds like: Devices which do not implement SNAP cannot actually process the contents of Ethernet packets which have a length instead of an Ethertype as bytes 12+13. Correct?
    – Christian
    Commented Jul 20, 2015 at 8:05
  • You asked about IP, so I gave an answer specific to IPv4. IPv4 with a length field require SNAP encapsulation. It would help if we knew what problem you're trying to solve Commented Jul 20, 2015 at 8:10
  • I tried to outline it in my new comment on the question - does that help?
    – Christian
    Commented Jul 20, 2015 at 11:32
  • The custom protocol shall be very efficient and does not need routing or forwarding frames over IP networks. (There are other reason why I would have liked implementing it on top of IP, but that should not be the topic here. ) But from your answer I would read that at least routers would not "believe" they have an IP packet at hand when receiving my custom frame. That's enough for me for now.
    – Christian
    Commented Jul 21, 2015 at 11:24
-1

When a MAC frame has a length field (L/T <= 05-DC) the payload is sent to the LLC layer, not to IP. It is used for the MAC control plane, e.g. for spanning tree.

Best regards, Michel

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.