Re: NHRP/MARS version number location.

[James Luciani <[e-mail]>]

Tim,

> > >>I was surprised to find the MARS version number in byte 16 of the fixed
> > >>part of the MARS header.
> > >>Locating the version number this far into the header appears to be
> > >>a poor idea.
> > >>It seems that in most protocols, version numbers are located near the
> > >>beginning of the packet on the assumption that packet formats may change
> > >>across versions.
> > 
> > Your last sentence is generally correct, but you've overlooked what
> > is meant by a 'fixed header'. It is exactly that. A fixed header.
> > Any MARS/NHRP client or server parses the 20 byte fixed header before
> > deciding what to do about the rest of the packet. Whether various
> > fields are in the 1st or 19th position of the _fixed header_ is
> > somewhat arbitrary. Its the mandatory parts and TLVs that may change
> > if substantial protocol changes mandate a new version number.
> > 	[...]
> 
> Grenville,
> 
> With all due respect, I think you missed my point completely.
I think Grenville is completely on target with this.

> You are "overlooking" what is meant by "version."  MARS Version 1 has a
> format which is well known.  However, I don't think that you or anyone
> else knows what the format of the MARS Version 2 messages will be,
> including the format of the Version 2 "fixed header."  In other words,
> your "fixed header" ought to be viewed as fixed within MARS Version 1,
> not as fixed in perpetuity across all versions of MARS and across
> all address resolution protocols.
Using your reasoning, it does not matter in what position the 
version field resides because you cannot depend on the version field to 
be there anyway.  Ignoring that for a moment, using your reasoning,
we cannot depend on that field keeping the same size so there is no
way to cast the octet string into the appropriately ranged
variable anyway.  So the actual position has no meaning.

Basically, a change in version should never modify a fixed part 
(except perhaps to make use of fields marked "unused" within the fixed part) 
which is why it is called a "fixed" part.

If you modify the fixed part (except to make use of fields previously marked
as unused) you have to use a different LLC/SNAP codepoint.  Doing anything
would be a poor design.  You'll note that IPv4 and IPv6 have different
PIDs.

> I haven't seen any argument that MARS is somehow different than the
> rest of the Internet protocols and therefore shouldn't have a version
> number fairly early in the message.
> 
> However, as you show below, the MARS header doesn't really have a
> version number...
What is ar$op.version then? 

> > It may not be clear, but both MARS control messages and NHRP control
> > messages share the same, unique, non-rfc1577 LLC/SNAP codepoint
> > (in the ATM environment at least):
> > 	[...]
> I think this is a probably a mistake.  See below.
This was a very good idea.  I think you missed the whole point of the
harmonization of the MARS and NHRP protocols.

> > Now, within the context of this generic control message there is a
> > version field (along with fields indicating the protocol address types
> > being mapped, etc) indicating which address resolution protocol
> > is being used. MARS is version 0. NHRP is version 1. If there is
> > some future alternative that we'd like to multiplex onto the VCs
> > that are carrying MARS or NHRP message, we'll give it version 2, and
> > so on.
> 
> So, it appears that what you have been calling a "version" number is
> really a protocol identifier.  In other words, there is no protocol
> version number within the MARS header, only a [mislabeled] field which
> indicates the protocol.
Again, you missed the point of the harmonization of the NHRP and MARS.
The version number identifies the instance of the address resolution
protocol.

Regards,
-- Jim Luciani
__________________________________________________________________________
James V. Luciani    Ascom Nexion                    voice: [phone]
[e-mail]   289 Great Rd., Acton MA 01720   FAX: [phone]