[e2e] Ethernet Encapsulation

[Dennis Ferguson]

Tianbo Kuang wrote:
> Craig Partridge wrote:
> 
> > In message <3BEAE744.B9C0CD03 at cpsc.ucalgary.ca>, Tianbo Kuang writes:
> >
> > >> So, if the length
> > >> supplied by the link layer is is too short, the packet
> > >> should be discarded.  If it is longer, the excess data is
> > >> simply ignored.
> > >
> > >I thought the packets handed to IP layer by link layer are "clean" as the MAC
> > >layer has CRC. The situation you mentioned can only be caused by an error of
> > >higher layers. Am I wrong?
> >
> > I believe Ethernet specs used to permit padding to 16-bit boundaries.

IP packets transmitted on an Ethernet are frequently padded, but not
frequently for that reason.  Ethernet has a 64 byte minimum frame size,
which means the payload less MAC overhead can be no less than 46 bytes.  Many
IP packets are shorter than this.

> > In general, link layers are permitted to pad (and, for instance, ATM does)

Actually ATM doesn't have to (AAL5 takes care of this), but the observation
is still true regardless.  Even when the L2 framing is capable of
transmitting all valid IP packets without padding, I can't think of
an L2 encapsulation for IP which is defined to explicitly guarantee packets
will actually be sent without padding (ignoring exceptions like PPP header
compression).  In fact, forwarding the padded Ethernet packet without
stripping the padding will probably work given how most link layer
encapsulations for IP are defined, though the robustness principle suggests
that you likely shouldn't count on this unless you are desperate.

> > Truncation indicates an error somewhere in the transmission path
> > (not necessarily a higher layer -- it may have been a previous network
> > hop, or even an bug in the sending or receiving Ethernet hardware).
> > [I can't think of a case where truncation is not caused by error but
> > others may remember odd cases]
> 
> So because Ethernet frame does not have a length field, the link layer has to
> hand the padded frame to IP layer after ripping off the header and crc? What
> about the ieee 802.3 who has a length field? Will it get rid of the padding by
> itself?

The 802.3 length field could theoretically have been used to eliminate
padding from IP packets during L2 processing at the receiver, I guess,
though it was never actually used for this (i.e. the IP encapsulation
in 802.3 didn't preclude sending padded packets in the payload, including
the padding in the frame length) and this wasn't the purpose for its
invention.  Other 802.x LANs don't have the minimum-frame-length restriction
of 802.3, so I think the length-field encapsulation was invented so you
could do

    802.x -> 802.3 -> 802.x

MAC-level bridging without the final 802.x segment seeing a frame padded
with additional bytes to the 802.3 minimum length.  Unfortunately (or
fortunately, depending on your point of view) this type of MAC level bridging
had other problems, and never became anywhere near popular enough to cause
most people to want to switch from the original IP encapsulation for Ethernet.
These days using the 802.3 IP encapsulation on Ethernet would be a slightly
bad idea, in fact, since it reduces the IP MTU below 1500 bytes.  

So the answer is no, 802.3 encapsulation doesn't help since this isn't
even an issue which is limited to link layers, like Ethernet, which
require padding in some cases.   IP must generally be prepared to handle
frames delivered from L2 which are padded beyond the end of IP packet,
and it generally must be able to do this whether the link layer actually
requires padding or whether the neighbour who sent the packet just felt
like padding it.  Other L3 protocols might not work like this, but for
IP, frames where the L2 payload length exceeds the packet length in the
header are pretty much always acceptable.

Or I think so, at least.  A ten minute search for text explicitly
stating or refuting this revealed nothing, so I'm relying on section
3.2 of RFC 791 for authority.

Dennis Ferguson