The IP over ATM Mailing List Archive by date

[zaumen@hsmpk12a-53.Eng.Sun.COM (Bill Zaumen)]

> I agree with what you say in regard to IP addresses for different subnets, 
> but what if the IP addresses are on the same subnet?

Aside from questions about what the RFCs state, sending multiple ARP
response frames using the currently defined format is risky.  If
multiple invARP responses are sent (each in a different AAL5 frame),
what happens if a frame is lost?  One may still receive some other
frame, so there is no way of knowing without some additional mechanisms.
The client could try to verify its new entries by sending ARP requests,
and then send an invARP response if the ARP request fails, but there
is no obvious requirement that the server respond to unsolicited ARP replies.

There is also a question of what happens if a client moves.  Suppose two
clients C1 and C2 share the same ATM address, and C2 moves to a new location,
but the connection to the ARP server, which is also used by C1, is preserved.
Then when C2 tries to register with the server, the server will discover
that (a) C2 has an existing entry and (b) a connection to that ATM address
exists.  In that case, C2 will not be able to register with the ARP server
until its entry is cleared (see Section 6.3 of RFC 1577):

   If the InATMARP IP address duplicates a table entry IP address and
   the InATMARP ATM address does not match the table entry ATM address
   and there is an open VC associated with that table entry, the
   InATMARP information is discarded and no modifications to the table
   are made.


Bill