Re: Question on RFC1577. (long, but two replies in one :-)

[[e-mail]]

> I must admit I thought Peter was looking from the other direction,
> i.e. what does a host make of the IP address carried in the InARP request
> _from_ the ARP Server? 

Exactly. 

> Perhaps an appropriate question is:
>
> "What IP address should the ARP Server insert in InARP REQUEST if it
> is 'standalone', i.e.  not supporting an IP stack" ?  

Also, what should the ARP client make of the SPA and SHA pair in the InATMARP
message from the server.  Is the SHA in the InATMARP packet the NSAPA of the
ARP server or the IP entity (if one exists) for the SPA?  Must these always
be the same? If no IP entity exists, should the SHA from the server be 0?  Since 
the SPA/SHA of the InARP packet can be used to build the local ARP cache  entry
(which is what we are doing), I would assume that this should be the NSAPA of the 
IP entity at the SPA (after all, the ATMARP server is not advertising its address 
in the InATMARP packet, but the SHA for the SPA).  This question arrises because, 
as you pointed out earlier, ATMARP and IP are not as tightly coupled as classical
ARP and IP are. 

> Ummm - I'm sorry, but I missed the place where this was ever proposed
> or argued for in the last few weeks. I have never been addressing this
> scenario. Who proposed it? (ref. email address and subject line so perhaps
> I can search back).

No one proposed this, I just see it as a logical fall out of the degree to
which the server and IP entity can be divorced.  That is, if the can
actually have separate NSAPAs then there's really nothing that prevents
them from being on two different machines.  For example, in Craig's drawing
he had the ARP server and IP entity using different NSAPAs, which makes them
sufficiently disjoint to even be on separate machines (especially since they
can't share traffic on their VCs).

> As for your question itself - if you mean 'disjoint' as in different NSAPAs
> then the answer is "they can't be". I'll illustrate why:
[ example snipped ]

This get's back to exactly what the server puts in its SHA field.  I agree
that the right way to do this is to have one NSAPA for the server and its
IP entity (if one exists).  This leads back to being able to use the
VC to the ARP server to send IP traffic to the associated IP entity.  Right?

What I'm really trying to get at is: is a single VC between a client and
ARP server expected to be able to carry IP traffic to the IP entity?  If not,
why? 

Thanks for everyone's patience if I'm covering old ground here.

 --- pete


------------------
Peter Schulter                                  [e-mail]
DEC OSF/1 Networking                            [phone]
Digital Equipment Corp
110 Spit Brook Road
Nashua, NH 03062