The IP over ATM Mailing List Archive by date

[Grenville Armitage <gja@thumper.bellcore.com>]

	[..]
>>implementations, we've learned that the ATMARP packet format specification
>>is ambiguous enough to allow implementers to choose different incompatible
>>approaches - everyone has to conform/change to some specification.

Just a thought, but are the same coders who 'optimized' their
implementations with fixed field widths planning on pulling
a similar stunt when they have to write NHRP clients?
If not, why not? (perhaps because the NBMA address starts at a different
offset within the Request and Reply packets).  Re-phrased - if
people think NHRP processing will be 'fast enough', why should
we bother formalizing this optimization to the simpler ATMARP?

Maybe a little harsh, but I'm tempted to ask why we don't
just declare vendors who didn't read rfc1577 to be wrong.
Simple as that. After all, the packet format picture quite
obviously identifies the field widths as being variable
(qoctets, roctets, etc).

(On the issue of IPv6, I have a sneaking suspicion IPng'ers
want to kill ARP anyway in  favour of a multicasted query.
Of course, this begs a whole new set of questions for
IPv6 over ATM. Haven't had time to read the docs for awhile,
so take this as a rumour designed to prompt a fiery rebuttal from
anyone who knows better :-)

gja