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()
<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 |>>>>>
Finished to send 1 packets.
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?
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.