Re: Apple IP-over-IEEE1394

[Guy Harris <guy () alum mit edu>]

On Mar 24, 2004, at 8:46 AM, Gisle Vanem wrote:

> To me it looks like from reading the print-ap1394.c that it
> handles "anything-over-IEEE1394" and not just IP.

Well, not *anything* - it probably won't handle SCSI-over-1394, or 
pictures or videos from your digital camera, for example.

> I know next to nothing about IEEE-1394, so I'm a bit confused.
> Why the emphasis on IP? Is that an industry mis-nomer?

Perhaps - see RFC 2734, which is entitled "IPv4 over IEEE 1394", but 
lists Ethernet types other than 0x0800 (0x0806 for 1394 ARP and 0x8861 
for MCAP, which is a "multicast channel allocation protocol") and says

   NOTE: Other network protocols, identified by different values of
   ether_type, may use the encapsulation formats defined herein but such
   use is outside of the scope of this document.

> Same goes for IP-over-Fibre channel.

See RFC 2625, which speaks only of IP and ARP, but indicates that 
there's an LLC/SNAP header, so it *could* be used for other protocols.

I think the "IP-over" part might come from the fact that the 
encapsulations were designed by people primarily thinking of running IP 
over those link layers - but they designed them in a way that they 
*could* be used to support other protocols; however, as they weren't 
involved in actually *implementing* those protocols on those link 
layers, perhaps they didn't want to use an RFC title suggesting that 
they were what would be used for all networking protocols.

I don't know whether, in practice, protocols other than IPv4 (and now 
IPv6, which does show up in some IP-over-1394 captures I've seen; 
presumably people can and perhaps do run it over Fibre Channel as 
well), and supporting protocols for them (e.g., ARP and MCAP) are run 
over those link layers.

> BTW. How is ARP over IPFC printed? Seems it requires a LLC
> header, but print-llc.c doesn't handle ARP.

print-llc.c handles LLC/SNAP, and LLC/SNAP is handled by processing the 
Ethernet type if the OUI is 0; SNAP packets will be handed to 
"snap_print()", and with an OUI of 0 they'll be handed to 
"ether_encap_print()", which will hand them to "print_arp()" if they 
have an Ethernet type of 0x0806 (or 0x8035 for reverse ARP).

> BTW2. Is there an easy releationship between a 6-byte MAC addresses
> and 8-byte EUI64 addresses used in IEEE-1394?

        http://standards.ieee.org/regauth/oui/tutorials/EUI64.html

An EUI-64 *can* include a 6-byte MAC address ("MAC-48 value"), but it 
need not do so.  If the EUI-64 is of the form

        XX-XX-XX-FF-FF-YY-YY-YY

then the corresponding MAC address is XX-XX-XX-YY-YY-YY.  That 
encapsulation is, however, listed as "deprecated", and the IP-over-1394 
captures I've seen have EUI-64's that encapsulate EUI-48's:

        http://standards.ieee.org/regauth/oui/tutorials/EUI48.html

i.e. XX-XX-XX-FF-FE-YY-YY-YY, rather than encapsulating MAC addresses.

(See also

        http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html

for more information on MAC-48's, EUI-48's, and EUI-64's.)

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe