tong@aussie.enet.dec.com (Benny Tong) (09/24/90)
RFC 1122 2.3.3 (p.24) says:
The IP encapsulation for Ethernets is described in RFC-894
[LINK:3], while RFC-1042 [LINK:4] describes the IP
encapsulation for IEEE 802 networks. RFC-1042 elaborates and
replaces the discussion in Section 3.4 of [INTRO:2].
Every Internet host connected to a 10Mbps Ethernet cable:
o MUST be able to send and receive packets using RFC-894
encapsulation;
o SHOULD be able to receive RFC-1042 packets, intermixed
with RFC-894 packets; and
o MAY be able to send packets using RFC-1042 encapsulation.
An Internet host that implements sending both the RFC-894 and
the RFC-1042 encapsulations MUST provide a configuration switch
to select which is sent, and this switch MUST default to RFC-894.
[...]
Note that 894-only systems cannot interoperate directly
with 1042-only systems. If the two system types are set
up as two different logical networks on the same cable,
they can communicate only through an IP gateway.
Furthermore, it is not useful or even possible for a
dual-format host to discover automatically which format to
send, because of the problem of link-layer broadcasts.
<end of quote>
Question :
Why is it not useful, or even possible for a dual-format host
to determine automatically which format to send? What is the
problem with link-layer broadcasts?
Will this scheme work?
When an IP datagram needs to be sent to an unknown Internet host, ARP
request packets of both ethernet and 802.3 types are broadcasted to the
ethernet. The IP datagram is queued for later transmission. When an ARP
reply comes back, the same packet type and ethernet address as the ARP
reply is used for sending the IP datagram. If replies with two packet
types come back, the default packet type can be used.romkey@ASYLUM.SF.CA.US (John Romkey) (09/24/90)
The Hosts Requirements group talked about the issue and decided that if you want to run both encapsulations on one ethernet, they must be two different subnets; you should not try to automatically negotiate which encapsulation to use. You need a router to switch packets, even though they're the same cable, logically they're two separate subnets. I was a proponent of using ARP to negotiate encapsulation, similarly to the way 4BSD TCP now uses ARP to negotiate trailers, but I agree with the decision. The broadcast problem is that you need to decide which format to broadcast in, and you don't want to broadcast twice (I don't recall there being more to it than that). Another problem is that the MTU is different between ethernet and IEEE 802. And this scheme is also idealogically more pure: you want to switch packets between encapsulations, you use a router. I would recommend that if you want to support both, you create two different logical network interfaces that use the same physical interface, and have them use different encapsulations and different network numbers. That's the way I'm handling it in an IP implementation I'm working on now. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com
romkey@ASYLUM.SF.CA.US (John Romkey) (09/25/90)
The ARP scheme you suggested is what I and other people suggested. When we talked about it in the Host Requirements group, problem after problem surfaced until someone finally said, "Look, why don't we do it the right way? They're different encapsulations; put a router between them." And we were enlightened. The router solution can be made to work now, and I really think it's the right one. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com
jqj@HOGG.CC.UOREGON.EDU (09/25/90)
>The Hosts Requirements group talked about the issue and decided that >if you want to run both encapsulations on one ethernet, they must be >two different subnets ... >I would recommend that if you want to support both, you create two >different logical network interfaces that use the same physical >interface, and have them use different encapsulations and different >network numbers. I wasn't there, but that's not my interpretation of rfc1122 as published. If your interpretation were correct, there would be no need for the requirement that all hosts be able to hear Ethernet encapsulation. My reading of the paragraph referencing "two different logical networks on the same cable," is that this appears as a justification fo NOT allowing 1042-only systems, not as a recommendation for how to deal with 1042-only systems! As I read it, the expectation is that you'll normally have a single subnet, and that Ethernet is dominant; the assumption is that everybody normally uses Ethernet, but that consenting systems might agree by some unspecified means to use rfc1042 (possibly unidirectionally) for unicast traffic. As I read it, if you support rfc1042 at all you must support it by treating receipt of such packets just as if they had been received in rfc894 encapsulation. This interpretation is particularly plausible given the advent of heterogenous bridging. Most proposals for transparent bridging between Ether/802.3 and other 802.x media (e.g. FDDI or IBM TR) imply that packets (not just IP) generated on the Ethernet in 1042 encapsulation may arrive at their destination on another Ethernet in Ethernet encapsulation. This breaks Appletalk II, of course, but was not supposed to break IP.
romkey@ASYLUM.SF.CA.US (John Romkey) (09/25/90)
Well, I speak only for myself and say only me perception of the matter. I don't speak for the Hosts Requirements group. I believe that the reason for all hosts to be able to hear Ethernet packets is that very few vendors supported (and even now, support) RFC 1042 encapsulation, and the group wanted to ensure interoperability. In practical terms, if you want to interoperate with TCP/IP on ethernet/IEEE 802.3 networks, you must support RFC 894 encapsulation. I think that requirement is just a reflection of the practical situation we're living with now. If you want the voice of Host Requirements on the matter, Bob Braden will have to speak up. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com
tong@aussie.enet.dec.com (Benny Tong) (09/26/90)
RFC1122 says:
Furthermore, it is not useful or even possible for a
dual-format host to discover automatically which format to
send, because of the problem of link-layer broadcasts.
I suggest:
When an IP datagram needs to be sent to an unknown Internet host, ARP
request packets of both ethernet and 802.3 types are broadcasted to the
ethernet. The IP datagram is queued for later transmission. When an ARP
reply comes back, the same packet type and ethernet address as the ARP
reply is used for sending the IP datagram. If replies with two packet
types come back, a default packet type can be used.
In article <9009241126.AA00500@asylum.sf.ca.us>, romkey@ASYLUM.SF.CA.US (John
Romkey) writes:
|>The ARP scheme you suggested is what I and other people suggested.
|>When we talked about it in the Host Requirements group, problem after
|>problem surfaced until someone finally said, "Look, why don't we do it
|>the right way? They're different encapsulations; put a router between
|>them." And we were enlightened.
|>
What are the problems with link-layer broadcasts? Can you list some of them
please?