PAD bytes change through VLAN

[Guest]

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.

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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.

 

[Guest]

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?

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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