The IP over ATM Mailing List Archive by date

[Mark Laubach <laubach@terra.com21.com>]

>     Useful note, thanks!  By the way, everyone should understand that Mark
> asked me to take a shot at characterizing the fixed-length vs. variable
> length approach.  I currently have an implementation that does variable length
> and if we stick to that, it is not a problem for me -- though I think it is
> a coding style that encourages bugs.

Yes, and you did Craig.  I wanted to break the ice and get another
implementer's opinion on the issue and I figured you were the best
target....<g>
 
>     Generally, with traditional ARP the ar$op field lets you know which
>     fields are valid. It would be nice of we could maintain some consistency in
>     this regard without introducing any ambiguity.
> 
> Good point.

Yes, a point, but again, this ATMARP is not the same as traditional
broadcast ARP.  The father of broadcast ARP never envisioned the problems
of ATM subaddresses, variable length addresses, and non-broadcast
networks, even in his worst dreams most likely.  By the way, for
historical reference, I was not permitted to use the term "ARP" for the
RFC1577 address resolution service.  I was told by members of the IESG to
change the term to something that did not imply it was in any way
connected to RFC826 ARP because in their opinion, it wasn't.
 
> Generally, my view is that the real question is: do we want to do offset
> arithmetic (i.e., compute where to find addresses) or not?  Once you buy into
> computing offsets, you buy into a larger class of problems -- more range
> checking and length checking and more chances for bizzare corrupted packets.
> But if we need to do it, then let's do it.  I think all Mark was asking for
> was that we make sure we aren't adding complexity unnecessarily.

Yes, thanks for the concise statement Craig.  I also tend to look at this
as whether you want variability or not - a halfway solution doesn't make
sense to me.  My thoughts follow the line that if we move from the current
format, then all ATM and IP address fields will be allocated a fix length
buffer (20 octets), with specific rules to indicate null.  IP address
null is 0's.  ATM address nulls will be the length = 0.

Mark