PAD bytes change through VLAN

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi,

I have come across a hypothetical situation in which the content of
the pad bytes after a short packet will change through a network.

1. Generate short packet over 802.2 LLC SNAP (which requires that we
put the length in the length/type field).

2. Pad packet (with pad#1) to 64 bytes, send over LAN.

3. Add VLAN tag (32 bits total). If I've interpreted 802.1Q
correctly, the equipment doing this is allowed to remove pad so that
the frame is still only 64 bytes long (rather than 68). It can tell
pad from packet because of the length field.

4. Strip VLAN tag. The frame is now short, so add another 4 bytes of
pad (pad#2) and send over LAN.


The initial frame had the packet followed by pad#1. The final frame
has the same packet followed by pad#2.

The standard doesn't require the pad to be any particular value, so
pad#2 isn't necessarily the same as pad#1.


Does anyone know if this scenario actually ever happens in real life?

It requires
(a) pad values to be different (every implementation I've seen uses
zero) and
(b) the device adding the VLAN tag needs to strip pad (does this
happen?) and
(c) we have to put a length in the length/type field, which happens
when we use SNAP.

I guess that last one would also include SAP, but I think that's less
common than SNAP.

TIA,
Allan.
11 answers Last reply
More about bytes change vlan
  1. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<f40bc0pqhcifh535aomcqjc8av9snnf5b6@4ax.com>...

    > It requires
    > (a) pad values to be different (every implementation I've seen uses
    > zero) and

    Why can't one use zeroes for both pads?

    > (b) the device adding the VLAN tag needs to strip pad (does this
    > happen?) and

    I'm not sure, but why would it matter?

    > (c) we have to put a length in the length/type field, which happens
    > when we use SNAP.

    A few years ago, Xylan (a company that is now part of Alcatel) used
    to build an Omniswitch that could switch between different encapsulations
    and media.
    >
    > I guess that last one would also include SAP, but I think that's less
    > common than SNAP.

    Anoop
  2. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <f40bc0pqhcifh535aomcqjc8av9snnf5b6@4ax.com>,
    Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

    >
    > I have come across a hypothetical situation in which the content of
    > the pad bytes after a short packet will change through a network.
    >
    > 1. Generate short packet over 802.2 LLC SNAP (which requires that we
    > put the length in the length/type field).
    >
    > 2. Pad packet (with pad#1) to 64 bytes, send over LAN.
    >
    > 3. Add VLAN tag (32 bits total). If I've interpreted 802.1Q
    > correctly, the equipment doing this is allowed to remove pad so that
    > the frame is still only 64 bytes long (rather than 68). It can tell
    > pad from packet because of the length field.
    >

    At this point, the number of pad bytes is (pad#1 - 4). Note that the
    Length field is *unchanged*. (There is still the same amount of data
    payload being carried in the frame.)

    There must have been at least 4 bytes of pad for a device to be able to
    insert a Q-tag and yet keep the frame length at the 64 byte minimum.

    > 4. Strip VLAN tag. The frame is now short, so add another 4 bytes of
    > pad (pad#2) and send over LAN.
    >

    So, you first removed 4 bytes of pad to compensate for the 4-byte Q-tag.
    Now you are adding 4 bytes of pad to bring the stripped frame back up to
    the 64 byte minimum. Therefore, (pad#2) = (pad#1), i.e., the number of
    pad bytes is the same at the beginning and end of this sequence.

    >
    > The initial frame had the packet followed by pad#1. The final frame
    > has the same packet followed by pad#2.
    >

    Which both have the same number of pad bytes. While this does provide
    "consistency", it is not even strictly required. The receiver will
    deliver to the LLC client the payload bytes, as determined by the
    payload field qualified by the Length field (which indicates the number
    of *valid* bytes of payload). Even if intermediate devices changed the
    length of the pad, there would be no operational issue, since the Length
    field always indicates those bytes that are valid.

    Indeed, there is no requirement that frames only be padded to the 64
    byte minimum. It is perfectly permissible to pad frames to 68 bytes, 146
    bytes, 73 bytes or any other implementation-dependent value. If you
    like, you can build a device that only sends 1500 byte frames, and pads
    everything to that value. It's not efficient, but it would work properly
    if implemented per the standard.

    > The standard doesn't require the pad to be any particular value, so
    > pad#2 isn't necessarily the same as pad#1.
    >

    Since the values of the pad bytes are ignored, it is irrelevant that
    they are different between the original sender and the ultimate receiver
    (if indeed they are).

    >
    > Does anyone know if this scenario actually ever happens in real life?
    >

    I'm sure you can configure some devices to do this, but it is not a
    common case.

    > It requires
    > (a) pad values to be different (every implementation I've seen uses
    > zero)

    Why do pad values have to be different? Every device can pad with zeroes
    if it likes. The pad is stripped by the Length field, not the pad value.

    > and
    > (b) the device adding the VLAN tag needs to strip pad (does this
    > happen?) and

    It doesn't *need* to strip the pad; you stated it as a *given* that the
    device stripped the pad. It would be perfectly OK to add the VLAN tag,
    *not* strip the pad, and send out a 68 byte frame.

    This is the typical behavior, as it avoids: (1) Having to parse whether
    the frame is Length-encapsulated, (2) Checking the length of the frame
    vis-a-vis the Length field to see if there are four extra pad bytes that
    can be dispensed with, and (3) Stripping the excess pad. Since all of
    these operations take time and effort, and NONE are necessary for proper
    operation, why bother to do it? To regain the minor efficiency advantage
    of sending 64 vs. 68 byte frames? It's just not worth the trouble.

    > (c) we have to put a length in the length/type field, which happens
    > when we use SNAP.
    >

    The Length field is already there. None of these operations affect the
    value of the Length field, which indicates the number of valid bytes in
    the payload (and NOT the length of the frame itself). The valid bytes in
    the payload do not change through these transformations, so the Length
    value is constant.


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
  3. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Rich Seifert wrote:

    > In article <f40bc0pqhcifh535aomcqjc8av9snnf5b6@4ax.com>,
    > Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote:
    >
    >
    >>I have come across a hypothetical situation in which the content of
    >>the pad bytes after a short packet will change through a network.

    (big snip)


    > It doesn't *need* to strip the pad; you stated it as a *given* that the
    > device stripped the pad. It would be perfectly OK to add the VLAN tag,
    > *not* strip the pad, and send out a 68 byte frame.

    > This is the typical behavior, as it avoids: (1) Having to parse whether
    > the frame is Length-encapsulated, (2) Checking the length of the frame
    > vis-a-vis the Length field to see if there are four extra pad bytes that
    > can be dispensed with, and (3) Stripping the excess pad. Since all of
    > these operations take time and effort, and NONE are necessary for proper
    > operation, why bother to do it? To regain the minor efficiency advantage
    > of sending 64 vs. 68 byte frames? It's just not worth the trouble.

    >>(c) we have to put a length in the length/type field, which happens
    >>when we use SNAP.

    I would have thought that a layer 2 device shouldn't look at
    the length field at all. It might be that the standard doesn't
    say that, though.

    A layer 3 device, which I believe could also do VLAN tagging,
    would reasonably be expected to look at the length field,
    and might only store the appropriate number of bytes in the
    buffer.

    The OP didn't indicate any specific layer 3 protocol, though.

    -- glen
  4. Archived from groups: comp.dcom.lans.ethernet (More info?)

    On Tue, 08 Jun 2004 09:14:22 -0700, Rich Seifert
    <usenet-@-richseifert-dot-com.invalid> wrote:

    >> (b) the device adding the VLAN tag needs to strip pad (does this
    >> happen?) and
    >
    >It doesn't *need* to strip the pad; you stated it as a *given* that the
    >device stripped the pad. It would be perfectly OK to add the VLAN tag,
    >*not* strip the pad, and send out a 68 byte frame.
    >
    >This is the typical behavior, as it avoids: (1) Having to parse whether
    >the frame is Length-encapsulated, (2) Checking the length of the frame
    >vis-a-vis the Length field to see if there are four extra pad bytes that
    >can be dispensed with, and (3) Stripping the excess pad. Since all of
    >these operations take time and effort, and NONE are necessary for proper
    >operation, why bother to do it? To regain the minor efficiency advantage
    >of sending 64 vs. 68 byte frames? It's just not worth the trouble.

    Are you saying this *never* happens in practice? Can you guarantee
    that all future implementations will not do it?

    I got the idea from a post of yours, in which you implied it was
    possible (your point (3)) :
    http://groups.google.com/groups?threadm=seifert-ya023060040404971238460001%40192.0.2.3

    Thanks,
    Allan.
  5. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <0ttcc0lhqqkiu8k1qdm98agf8ukekhll3k@4ax.com>,
    Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

    >
    > Are you saying this *never* happens in practice? Can you guarantee
    > that all future implementations will not do it?
    >

    Since this behavior is permitted, one can never *guarantee* that it will
    not occur. On the other hand, the frequency of its occurrence may be so
    low that you could choose to ignore this boundary case for your product.

    However, if the combination of [your product] and [this boundary case]
    ever occurred in the real world, it might not behave properly, and it
    would be *your* implementation's fault.


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
  6. Archived from groups: comp.dcom.lans.ethernet (More info?)

    On 8 Jun 2004 07:00:38 -0700, anoop@alumni.duke.edu (Anoop Ghanwani)
    wrote:

    >Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<f40bc0pqhcifh535aomcqjc8av9snnf5b6@4ax.com>...
    >
    >> It requires
    >> (a) pad values to be different (every implementation I've seen uses
    >> zero) and
    >
    >Why can't one use zeroes for both pads?

    One could (and would) use zeros, however the standard doesn't demand
    that the pad be any particular value, so there *may* be
    implementations out there that pad with values other than zero.

    So the last few bytes of a frame may change as it passes through the
    network. Of course, the bytes that change aren't *valid* bytes, and
    devices should ignore those bytes.

    My application deals with frames, and I was hoping to have to avoid
    the complexity of having to decode the length/type field to work out
    whether there is padding.

    Regards,
    Allan.
  7. Archived from groups: comp.dcom.lans.ethernet (More info?)

    On Wed, 09 Jun 2004 10:06:20 -0700, Rich Seifert
    <usenet-@-richseifert-dot-com.invalid> wrote:

    >In article <0ttcc0lhqqkiu8k1qdm98agf8ukekhll3k@4ax.com>,
    > Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote:
    >
    >>
    >> Are you saying this *never* happens in practice? Can you guarantee
    >> that all future implementations will not do it?
    >>
    >
    >Since this behavior is permitted, one can never *guarantee* that it will
    >not occur. On the other hand, the frequency of its occurrence may be so
    >low that you could choose to ignore this boundary case for your product.
    >
    >However, if the combination of [your product] and [this boundary case]
    >ever occurred in the real world, it might not behave properly, and it
    >would be *your* implementation's fault.

    That's what I was worried about.

    Thanks for your input.

    Regards,
    Allan.
  8. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
    > On Wed, 09 Jun 2004 10:06:20 -0700, Rich Seifert
    > > Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote:
    > >>
    > >> Are you saying this *never* happens in practice? Can you guarantee
    > >> that all future implementations will not do it?
    > >>
    > >
    > >Since this behavior is permitted, one can never *guarantee* that it will
    > >not occur. On the other hand, the frequency of its occurrence may be so
    > >low that you could choose to ignore this boundary case for your product.
    > >
    > >However, if the combination of [your product] and [this boundary case]
    > >ever occurred in the real world, it might not behave properly, and it
    > >would be *your* implementation's fault.
    >
    > That's what I was worried about.

    Allan Said:
    "It requires
    (a) pad values to be different (every implementation I've seen uses
    zero) and"

    How do know they use zero?

    I was intrigued that anyone should bother. As a non programmer,
    well not much of one anyway, I would set up a Tx buffer, put the
    data in it that I wanted, set the length up for the hardware
    transmitter and pass off control to the Tx hardware. Anything in
    the buffer that happened to be there would be the pad.

    Of course some hardware might be able to generate pad bytes for
    you (to any required specification). Once again though why would
    anyone do this.

    So:-
    Out with the sniffers. I have an old Sniffer (Windows 98) and
    Ethereal on a modern PC.

    They both agree than MOST pad fields are indeed all zeros on our
    network.

    They both agree that certain (ARP) replies from a PC running Linux
    uses FFs.

    Ethereal sees various 'random' values too.

    HOWEVER:- I don't *really trust* any of the observations since the
    issue may be that the receiving device may not be telling the
    whole truth.

    If you need to KNOW this (however as far as I can see you MUSTN'T)
    it is time to break out the oscilliscope.

    On your original point, my view is that you should do what you are
    supposed to do and *ignore* the pad field. Why do anything else?
  9. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <3adc58e4.0406140140.725dff8b@posting.google.com>,
    anybody43@hotmail.com (AnyBody43) wrote:

    > Out with the sniffers. I have an old Sniffer (Windows 98) and
    > Ethereal on a modern PC.
    >
    > They both agree than MOST pad fields are indeed all zeros on our
    > network.
    >
    > They both agree that certain (ARP) replies from a PC running Linux
    > uses FFs.
    >

    Note that what you are seeing in ARP replies is *NOT* "pad" in the 802.3
    (Length encapsulation) sense. 802.3-pad applies when clients use Length
    encapsulation, as the syntax of the data payload is unknown, and can
    conceivably be less than the 46 bytes allocated. When using Type
    encapsulation, 802.3 places the burden of providing a minimum-length
    frame on the client protocol.

    ARP packets use Type encapsulation (Type = 0x0806). The salient fields
    in an ARP packet indeed comprise less than 46 bytes, however the ARP
    entity can distinguish between the salient data and the pad because the
    frame format of an ARP message is well-defined.

    In preparing the ARP frame for transmission on an Ethernet, ARP (or
    perhaps the device driver) fills in the remaining bytes with whatever
    value it chooses. However, from an 802.3 perspective, this is not "pad",
    it is simply a minimum-length frame submitted by a higher-layer protocol
    client.

    Thus *architecturally*, the 802.3 MAC provides the pad when supplied
    with a Length field less than 46 bytes. When presented with a Type
    encapsulated frame, the 802.3 MAC does not supply any pad; it is the
    responsibility of the client protocol to provide pad (if needed), but
    this "pad" is considered data payload from the perspective of the 802.3
    MAC.

    In neither case (802.3-pad or client-pad) is the value of the pad bytes
    generally specified by standard, as it is irrelevant.


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
  10. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Rich Seifert wrote:

    (snip regarding length encapsulation and padding)

    > Note that what you are seeing in ARP replies is *NOT* "pad" in the 802.3
    > (Length encapsulation) sense. 802.3-pad applies when clients use Length
    > encapsulation, as the syntax of the data payload is unknown, and can
    > conceivably be less than the 46 bytes allocated. When using Type
    > encapsulation, 802.3 places the burden of providing a minimum-length
    > frame on the client protocol.

    How is it actually divided up between software and hardware.

    Will the hardware pad a frame, in either encapsulation, supplied
    to it by the device driver? I might guess that it would.

    As it is usual for hardware to support both, I would expect it
    not to special case length encapsulation, and expect the driver
    to provide padding or the hardware to supply it, without looking
    at the length field.

    > ARP packets use Type encapsulation (Type = 0x0806). The salient fields
    > in an ARP packet indeed comprise less than 46 bytes, however the ARP
    > entity can distinguish between the salient data and the pad because the
    > frame format of an ARP message is well-defined.

    For SNAP encapsulated IP is ARP still type encapsulated? We ran into
    a strange bug some years ago on an HP-UX machine running third
    party Appletalk (ethertalk) software. It might be that it would
    sometimes send out SNAP IP packets, or ARP packets. The workaround
    was to ping any machine on the subnet not recently accessed,
    such that an ARP request would have to be made. That ARP request
    would remind the router that IP was type encapsulated and things
    would work again.

    (snip)

    > In neither case (802.3-pad or client-pad) is the value of the pad bytes
    > generally specified by standard, as it is irrelevant.

    In days past, I have known systems that one could open a new
    file and start reading the data previously stored on those
    disk blocks. For security reasons most have plugged that
    hole. I would expect leaving data in buffers as pad for ethernet
    frames would also be considered a security hole and not allowed.

    -- glen
  11. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <30szc.24135$Hg2.5414@attbi_s04>,
    glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

    > Rich Seifert wrote:
    >
    > (snip regarding length encapsulation and padding)
    >
    > > Note that what you are seeing in ARP replies is *NOT* "pad" in the 802.3
    > > (Length encapsulation) sense. 802.3-pad applies when clients use Length
    > > encapsulation, as the syntax of the data payload is unknown, and can
    > > conceivably be less than the 46 bytes allocated. When using Type
    > > encapsulation, 802.3 places the burden of providing a minimum-length
    > > frame on the client protocol.
    >
    > How is it actually divided up between software and hardware.
    >
    > Will the hardware pad a frame, in either encapsulation, supplied
    > to it by the device driver? I might guess that it would.
    >

    Most Ethernet silicon can be configured to automatically insert pad
    bytes, although very few systems ever enable this "feature". In
    practice, the device driver (software) ensures that the buffer presented
    to the controller IC contains the minimum required number of bytes. This
    is especially the case for protocols using Type encapsulation (e.g., IP
    and ARP).


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
Ask a new question

Read More

VLAN Ethernet Card Networking