Subject: [OPSAWG] syslogMsgSDTable, syslog-msg-mib-01

From: WashamFan <[email-masked]>
Date: Wed, 18 Feb 2009 15:22:03 +0800

Hi,

I found that syslogMsgSDTable can not exactly tell
the position of parameters in SDE. E.g.,

  [sd-id para="1" value="1" para="2" value="2"]

syslogMsgSDTable can tell para="1" is before
para="2" and value="1" is before value="2" according
to syslogMsgSDParamIndex, but can not tell value="1"
position between para="1" and para="2".

Think about how to represent snmp SDE defined in your 
another draft in syslogMsgSDTable, there is the same
concern.

I am not sure if you have considered it. What do you
think of it?

BTW: Why mark 'syslogMsgSDElementName', 'syslogMsgSDParamName',
'syslogMsgParamIndex' as 'not-accessible', you don't want user
to read them?

a typo: page12 :
"syslogMsgSDParamIndex OBJECT-TYPE
    SYNTAX      Unsigned32 (1..4294967295)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
       "This objects indexes the instance of a structured data element
        that occurs multiple times in a structured data element,
        starting from 1. For parameters that only occure once, the
        value of this object is 1."
    REFERENCE
       "RFCYYYY: The syslog Protocol (section 6.3.3)"
    ::= { syslogMsgSDEntry 3 }"
s/the instance of a structured data element/the instance of a parameter/

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Feb 2009 08:50:24 +0100

> position between para="1" and para="2".

The SYSLOG specification says:

SD-PARAM        = PARAM-NAME "=" %d34 PARAM-VALUE %d34

So [sd-id para="1" para="2" value="1" value="2"] just does not make
sense in SYSLOG. I do not see the problem.

> another draft in syslogMsgSDTable, there is the same

I do not see the problem. Please give me an example where things do
not work.

> 'syslogMsgParamIndex' as 'not-accessible', you don't want user

This is how SMIv2 works (RFC 2578 section 7.7). You read auxilliary
objects by unpacking the instance identifier.
 
> s/the instance of a structured data element/the instance of a parameter/

Good catch - I will fix this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: WashamFan <[email-masked]>
Date: Wed, 18 Feb 2009 17:09:11 +0800

>  I do not see the problem. Please give me an example where things do

Below is syslog messages from page10, syslog-snmp-00:

<29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47
   [snmp ctxEngine="800002b804616263" ctxName="ctx1"
     v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860"
     v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4"
     v="1.3.6.1.2.1.2.2.1.1.3" d="3"
     v="1.3.6.1.2.1.2.2.1.7.3" d="1"
     v="1.3.6.1.2.1.2.2.1.8.3" d="1"]

I assume the corresponding entries in syslogMsgSDTable:

syslogMsgIndex.1 = 1
...
syslogMsgSDParamValue.1."snmp"."v".1="1.3.6.1.2.1.1.3.0"
syslogMsgSDParamValue.1."snmp"."v".2="1.3.6.1.6.3.1.1.4.1.0"
syslogMsgSDParamValue.1."snmp"."v".3="1.3.6.1.2.1.2.2.1.1.3"
...
syslogMsgSDParamValue.1."snmp"."l".1="sysUpTime.0"
syslogMsgSDParamValue.1."snmp"."l".2="snmpTrapOID.0"
...

How can you tell the first occurrence of "l" is after "v".1 or "v".2?
I.e., there may be possible that it is not 1:1 mapping from SDE to 
Table entries. Does that make sense?

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Feb 2009 11:30:58 +0100

> Table entries. Does that make sense?

OK, I now get your point. So if I understand correctly, a shorter
example would be the following structured data element:

  [a c="c" b="b"]

This maps to the following SNMP table entries (assuming syslogMsgIndex.1 = 1):

  syslogMsgSDParamValue.1."a"."b".1="b"
  syslogMsgSDParamValue.1."a"."c".1="c"

The information that param c was before param b is lost. The question
is whether this is relevant information to preserve. Perhaps it is. By
changing the indexing structure, we can easily address this:

  syslogMsgSDParamValue.1."a".1."c"="c"
  syslogMsgSDParamValue.1."a".2."b"="b"

The index before the param name would now be the position of the param
within the structured data element. I think this change makes sense.

Does everybody agree?

/js

---

From: WashamFan <[email-masked]>
Date: Wed, 18 Feb 2009 20:09:43 +0800

Hi,

> within the structured data element. I think this change makes sense.

Yes, I agree. That is what I was concerned.

washam

> Fax:   +49 421 200 3103         <
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Feb 2009 14:00:36 +0100

> within the structured data element. I think this change makes sense.

Thinking further; we have the same issue with the order of structured
data elements. Consider this:

   [b b="b"][a c="c" a="a"]

We would now get:

   syslogMsgSDParamValue.1."a".1."c"="c"
   syslogMsgSDParamValue.1."a".2."a"="a"
   syslogMsgSDParamValue.1."b".1."b"="b"

So perhaps the position needs to be the second index and increment
across structured data element boundaries:

   syslogMsgSDParamValue.1.1."b"."b"="b"
   syslogMsgSDParamValue.1.2."a"."c"="c"
   syslogMsgSDParamValue.1.3."a"."a"="a"

This way, it should be possible to reconstruct all structured data
elements in the correct order.

/js

---

From: WashamFan <[email-masked]>
Date: Thu, 19 Feb 2009 09:52:56 +0800

Hi,

>  elements in the correct order.

Yes. When we parse SDE, we may take into account where params
position, but SDEs as a whole seems be independent with each other,
I am not sure. But now it is a 1:1 mapping from syslog SDEs to 
syslogMsgSDTable entries, I think;)

washam

---

From: Rainer Gerhards <[email-masked]>
Date: Tue, 24 Feb 2009 17:17:49 +0100

> syslogMsgSDTable entries, I think;)

SDEs, by concept, do not necessarily have a specific order. They shall
be addressed by the SD-ID and not by order of appearance. This permits
several elements in a syslog chain (e.g. before the message is put on
the wire for the first time) to add parameters.

The order of params inside the SDE is actually not mandated. One may
argue that this should have been specified, but it has not. So the
spirit of syslog-transport was that equally named params form a set of
values, where order of appearance is irrelevant. Thus there is only
very brief text on it:

"A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT."

Rainer

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Feb 2009 17:28:24 +0100

> the wire for the first time) to add parameters.

OK. But once the message has been sent the first time, the order is
not expected to change, right?

> "A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT."

Fine. The MIB currently preserves the order and it turned out that
doing so actually comes almost for free by just changing the INDEX
order and the semantics of one index component. So the MIB kind of
preserves the order as it was in the original message once it did hit
the wire. We were probably not required to do this but I believe it is
a feature that we can preserve the order.

/js

---

From: Rainer Gerhards <[email-masked]>
Date: Tue, 24 Feb 2009 17:43:55 +0100

> not expected to change, right?

"not expected" is good wording here. syslog-protocol permits relays to
modify messages, what includes modification on the order of SDEs. But
it also cautions against doing so. The spelled-out case is that
digital signatures (hashes) may be invalidated.

However, there may be some cases where message modifications, and
especially SDE modifications, may happen. The dominant case that comes
up my minds is relays that record (inside the message) that the
message was passed over this relay. This, if done, is expected to
happen to the SDE.

The reason such behavior was not outruled is that syslog is simplex.
So we do not have any other way to convey that information. At least
not with all transports. It can not be done with -transport-udp and
also not with -transport-tls. RFC3195 provides a mechanism to convey
message path information, but it is not widely accepted. RFC3195bis
will probably keep that ability.

Currently existing implementations tend to add message path
information by modifying the syslog message, so we can expect this
will happen in the future, too.

Thinking in the context of syslog-msg-mib, I would expect that all of
this happened before the message hits the translator (but not
necessarily before hitting the wire). If I now assume that a
translated message will be re-emitted as syslog message (after "snmp
tunneling"), the order would be correctly reconstructed, which is well
within the recommendations of syslog-protocol. So this is probably the
best thing to do.

> a feature that we can preserve the order.

I fully agree, this is a good way to handle the situation.

Rainer

---

From: WashamFan <[email-masked]>
Date: Wed, 25 Feb 2009 11:52:54 +0800

Hi,

The new indexing schema make sure 1:1 mapping between
syslog SD parameters and SDTable entries. When reconstructing
syslog SDEs from SDTable entries, no infomation is lost.
Take a look at snmp SDE which is defined in syslog-snmp-00,
interpretation of this SDE heavily depends on the order of 
SD parameters.

washam

---

From: Rainer Gerhards <[email-masked]>
Date: Wed, 25 Feb 2009 09:58:54 +0100

> interpretation of this SDE heavily depends on the order of

Yes, and this is why I commented. In theory, a syslog relay may
reorder elements. I do not expect any such implementation in practice
(other than those I pointed out), but still one could argue that it is
valid to do so.

Rainer
>>  > On Tue, Feb 24, 2009 at 05:17:49PM +0100, Rainer Gerhards wrote:
>>  >
>>  >> SDEs, by concept, do not necessarily have a specific order. They shall
>>  >> be addressed by the SD-ID and not by order of appearance. This permits
>>  >> several elements in a syslog chain (e.g. before the message is put
>> on
>>  >> the wire for the first time) to add parameters.
>>  >
>>  > OK. But once the message has been sent the first time, the order is
>>  > not expected to change, right?
>>
>>  >> The order of params inside the SDE is actually not mandated. One may
>>  >> argue that this should have been specified, but it has not. So the
>>  >> spirit of syslog-transport was that equally named params form a
>> set of
>>  >> values, where order of appearance is irrelevant. Thus there is only
>>  >> very brief text on it:
>>  >>
>>  >> "A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT."
>>  >
>>  > Fine. The MIB currently preserves the order and it turned out that
>>  > doing so actually comes almost for free by just changing the INDEX
>>  > order and the semantics of one index component. So the MIB kind of
>>  > preserves the order as it was in the original message once it did hit
>>  > the wire. We were probably not required to do this but I believe it
>> is
>>  > a feature that we can preserve the order.
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Feb 2009 11:50:17 +0100

> (other than those I pointed out), but still one could argue that it is

I understand now the following:

a) The SYSLOG -> SNMP mapping is fine since it preserves the SD-PARAM
   and the SD-ID order, even though this is not strictly required by
   SYSLOG.

b) The SNMP -> SYSLOG mapping was written under the assumption that
   SYSLOG maintains the SD-PARAM order within the "snmp" SD-ID. 

   It is now somewhat unclear to me whether it is valid to make this
   assumption.  If we can't make this assumption, we would have to
   encode the varbind positions in the param names:

   [snmp ctxEngine="800002b804616263" ctxName="ctx1"
     v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860"
     v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0" o2="1.3.6.1.6.3.1.1.5.4"
     v3="1.3.6.1.2.1.2.2.1.1.3" d3="3"
     v4="1.3.6.1.2.1.2.2.1.7.3" d4="1"
     v5="1.3.6.1.2.1.2.2.1.8.3" d5="1"]

   Is this the right approach?

/js

---

From: Rainer Gerhards <[email-masked]>
Date: Wed, 25 Feb 2009 13:54:02 +0100

>   and the SD-ID order, even though this is not strictly required by

yes

>   Is this the right approach?

Yes, that would work in all cases and without any doubt. However, as
unfortunately often in syslog, we need to weigh what is the least
worse approach: That binding will always work, but it requires some
more space (which is a scarce resource in syslog). Without the
sequence identifiers, there is a slight chance that SD-Params get
rerodered, but we preserve the space.

I am not SNMP literate enough, so can you tell me how long (roughly)
you would expect a typical SNMP notification, encoded as syslog
message, would be? If it is over 2K, there is a problem.

In any case, I lean towards the approach with the sequence
identifiers. I envision that syslog implementations will parse the
SDEs into a set-like structure, with the primary navigational key
being the SD-ID. Then, I'd expect that each node contains a set of
param names, identified by param name and each of them contains a set
of values. Note that I intentionally use the word "set" over "tupel",
because I have the assumption that when traversing this structure,
sequence of occurrence will not necessarily be taken into account. But
obviously, the sequence will most probably exist in the in-memory
representations and will lead to correct reconstruction of the
sequence when a message is forwarded.  All of this is not normative,
but just my thought about how a syslog engine may implement structured
data elements. Other implementers may have totally different (and
valid) ways to approach this.

Rainer

---

From: Rainer Gerhards <[email-masked]>
Date: Wed, 25 Feb 2009 13:58:03 +0100

I forgot to mention that all syslog engines are cautioned against
changing the message content (a recommendation inside the normative
text), so I would assume that order of SD-PARAMS is almost never
changed. The big motivator behind this was syslog-sign. The syslog WG
did not mandate it, though, as a number of exotic use cases popped up
where modification of SDEs would have benefit and may be preferred
over keeping everything as is - even if that means problems with e.g.
signatures. The primary use case, as written yesterday, were relays
recording path information inside the message.

Rainer

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Feb 2009 14:11:56 +0100 (CET)

Rainer Gerhards <[email-masked]> wrote:
> Yes, that would work in all cases and without any doubt.

An alternative might be to introduce another SD-ID "snmpVarbind" or
"snmpVb" which enapsulates the v/l/d/... parameters.  It would also
need an index parameter:

   [snmp ctxEngine="800002b804616263" ctxName="ctx1"]
   [snmpVb i="1" v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860"]
   [snmpVb i="2" v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0"
           o="1.3.6.1.6.3.1.1.5.4"]
   [snmpVb i="3" v="1.3.6.1.2.1.2.2.1.1.3" d="3"]
   [snmpVb i="4" v="1.3.6.1.2.1.2.2.1.7.3" d="1"]
   [snmpVb i="5" v="1.3.6.1.2.1.2.2.1.8.3" d="1"]

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Feb 2009 16:53:45 +0100

> recording path information inside the message.

For us, it is OK if someone adds SD-IDs. We only have a problem if
someone rearranges the params in an SD-ID. Is it safe to assume that
nobody rearranges params in SD-IDs?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Feb 2009 16:55:30 +0100

On Wed, Feb 25, 2009 at 02:11:56PM +0100, Martin Bjorklund wrote:
> > > ? [snmp ctxEngine="800002b804616263" ctxName="ctx1"
> > > ? ? v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860"
> > > ? ? v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0" o2="1.3.6.1.6.3.1.1.5.4"
> > > ? ? v3="1.3.6.1.2.1.2.2.1.1.3" d3="3"
> > > ? ? v4="1.3.6.1.2.1.2.2.1.7.3" d4="1"
> > > ? ? v5="1.3.6.1.2.1.2.2.1.8.3" d5="1"]
> > >
> > > ? Is this the right approach?
> > 

But the order of the snmpVb matters as well, so you have to number
them and the overall saving will be close to zero if not negative.

/js

---

From: Rainer Gerhards <[email-masked]>
Date: Wed, 25 Feb 2009 17:02:21 +0100

> nobody rearranges params in SD-IDs?

Hard to say. Let me phrase it that way: it is not forbidden. So I
can't outrule someone at some time will do... In my personal view, it
is highly unlikely, though. Adding sequence identifiers will work in
all cases, but I do not know if the extra space required may cause
problems (as I do not know the anticipated average message sizes).

Rainer

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Feb 2009 18:05:48 +0100

> problems (as I do not know the anticipated average message sizes).

Well, the sequence number usually adds two bytes per SNMP varbind. If
we want to save space, we can invent more compact OID notations (e.g.
compressing well known prefixes) or we can move from hex encoding to
base64 encoding of binary values.

I can try to dig out common notification sizes form some studies we
did several years ago or with some more effort we could check the 
SNMP traces we collected from operational networks and recode the
notifications in there. But this takes some time and effort.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Feb 2009 19:38:51 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> them 

... which I did with the 'i' parameter.

> and the overall saving will be close to zero if not negative.

Yes this encoding uses more bytes.   The only advantage would be that
it looks a bit "cleaner".

/martin

---

From: WashamFan <[email-masked]>
Date: Thu, 26 Feb 2009 10:16:23 +0800

Hi,
 
>     [snmpVb i="5" v="1.3.6.1.2.1.2.2.1.8.3" d="1"]

I am afraid this approach is even not allowed. Check the 1st para,
sec 6.3.2, syslog-protocol-23:

  SD-IDs are case-sensitive and uniquely identify the type and purpose
  of the SD-ELEMENT.  The same SD-ID MUST NOT exist more than once in a
  message.

washam

---

From: WashamFan <[email-masked]>
Date: Thu, 26 Feb 2009 11:25:42 +0800

Hi,

>     Is this the right approach?

How many parameters do you like to define? v1-v100, d1-d100,...?
It seems to me not a conventional way to define a SDE.
But I can't come up with a better way to do order issue;)

washam

---

From: WashamFan <[email-masked]>
Date: Thu, 26 Feb 2009 11:32:30 +0800

>  notifications in there. But this takes some time and effort.

It seems more issues to be handled when we put complicated thing like SNMP
upon simple thing like syslog. order issue is a thing and size truncation seems
another. I think SNMP messages go through syslog tunnel may lose some 
information, now.

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Feb 2009 09:34:34 +0100

> How many parameters do you like to define? v1-v100, d1-d100,...?

I will define them without putting an explicit upper bound into place.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Feb 2009 09:36:25 +0100

On Thu, Feb 26, 2009 at 11:32:30AM +0800, WashamFan wrote:
 
> It seems more issues to be handled when we put complicated thing
> like SNMP upon simple thing like syslog. 

Complicated and simple? Both protocols at the end carry name/value
pairs. One of two has them ordered, the other does not maintain an
order. Both protocols have size constraints due to their UDP
transports. I fail to see a big difference in complexity/simplicity.

> I think SNMP messages go through syslog tunnel may lose some
> information, now.

Yes, and mind you that truncation is a normal part of life of a SYSLOG
message. On the other hand, the majority of SNMP notifications are
really short, mainly due to the 484 guaranteed SNMP message size over
UDP. The SYSLOG UDP transport says receivers SHOULD be able to receive
datagrams with messages size of up to 2048 octets. For SNMP, it is
recommended that implementations be capable of accepting messages of
up to 1472 octets in size.

So the situation is not really so bad, but we should still keep the SD
encoding compact. And for corner case situations, you have to pick a
different transport. And essentially this text needs to be added is
some nicer words to the documents, as suggested by Rainer.

/js

---

From: WashamFan <[email-masked]>
Date: Thu, 26 Feb 2009 17:00:12 +0800

>  I will define them without putting an explicit upper bound into place.

OK.It seems no text to prohibit unlimited numbers of params appearing in 
a SDE, so I assume it is allowed for by syslog-protocol.

washam

---

From: Rainer Gerhards <[email-masked]>
Date: Thu, 26 Feb 2009 10:07:47 +0100

On Thu, Feb 26, 2009 at 10:00 AM, WashamFan
<[email-masked]> wrote:
>>  > How many parameters do you like to define? v1-v100, d1-d100,...?
>>

It is not prohibited and I can not envision why an implementation
should have an issue with that. In practice, however, the size
limitations put an implicit upper limit on the number of parameters.
But that is a general issue, nothing to be addressed in the context of
the encoding here.

Rainer

---

From: Rainer Gerhards <[email-masked]>
Date: Thu, 26 Feb 2009 10:19:56 +0100

> up to 1472 octets in size.

Thank for spelling out these numbers. Being not involved in SNMP, I
did not have them on my mind. Now I agree that this should be not so
much of an issue. The main thing is the BER is more compact than
SD-IDs.

> some nicer words to the documents, as suggested by Rainer.

I suggest the following:

- use a compact encoding, what is provided already looks good
- suggest that a translator by default drops optional human-readable
parts if the syslog message would go beyond a specific size (2K seems
like a good default)
- suggest to put more important parameters early in the syslog
message. If a syslog receiver truncates and processes the message, it
is specified that the end of the message must be truncated. Thus,
putting the important parts first enhances the chance they will not
get truncated
- add a note to operators that they should configure the syslog
subsystem with reasonable max message sizes

The last suggestion, I think, requires some explanation:
syslog-protocol does not set any upper limit on syslog message sizes.
This is left to the transports and WG consensus was that we put no
explicit upper boound in any transport unless strictly necessary. This
was done to allow some use cases (IHE, Windows event forwarding) that
require much larger messages (64K+ may be required in some cases). I
expect that all major syslog implementations will support configurable
max sizes. I also expect that only few operators will actually now
about this feature. My expectation is that product that require larger
sizes will include that in their operator manual. In that spirit, I
think it would be good to hint SNMP/syslog translator
implementors/deployers on the size issue and the potential
work-around. If someone actually tunnels SNMP via syslog, it would be
appropriate to make sure that each syslog system in that tunnel
supports e.g. 4K max message size, which would sufficiently address
the syslog size limitation issue.

Rainer

---

From: WashamFan <[email-masked]>
Date: Thu, 26 Feb 2009 18:47:30 +0800

>  much of an issue. The main thing is the BER is more compact than
I'd like to add that, SYSLOG UDP transport would not support up to 2048 octets
in practice due to IP fragmentation avoidance. As I know, majority of syslog
information are short, too. According to syslog-transport-udp, 480 octets and
1180 octets are MUST for IPv4 and IPv6 respectively, 2048 octets are recommended.

washam

---

From: Rainer Gerhards <[email-masked]>
Date: Thu, 26 Feb 2009 11:57:48 +0100

On Thu, Feb 26, 2009 at 11:47 AM, WashamFan
<[email-masked]> wrote:
>
>>  >> I think SNMP messages go through syslog tunnel may lose some
>>  >> information, now.
>>  >
>>  > Yes, and mind you that truncation is a normal part of life of a SYSLOG
>>  > message. On the other hand, the majority of SNMP notifications are
>>  > really short, mainly due to the 484 guaranteed SNMP message size over
>>  > UDP. The SYSLOG UDP transport says receivers SHOULD be able to receive
>>  > datagrams with messages size of up to 2048 octets. For SNMP, it is
>>  > recommended that implementations be capable of accepting messages of
>>  > up to 1472 octets in size.
>>

Well, actually UDP syslog works well up to 4K on many platforms. I did
a quick survey, never fully completed, while we worked on
syslog-protocol. It can be found here:

http://www.monitorware.com/Common/en/articles/ihe-syslog.php

But as you say, 480 is the only guaranteed size. In practical
implementations, I'd expect that 2K is used for UDP, too. But under
network stress conditions, anything larger than 480 octets may have
more trouble reaching the destination.

Rainer