Guy Harris
changed
bug 11802
| What |
Removed |
Added |
| Status |
UNCONFIRMED
|
INCOMPLETE
|
| Ever confirmed |
|
1
|
Comment # 1
on bug 11802
from Guy Harris
(In reply to boaz.brickner from comment #0)
> In the attached pcap file there's a single ISO Internet Protoocl over IPv6
> packet.
> Event though the IPv6 Authentication header says the next protocol is ISO
> Internet Protocol,
According to RFC 1070:
http://tools.ietf.org/html/rfc1070
Encapsulating ISO-grams in IP datagrams
The entire OSI network layer PDU, whether it be an ISO 8473 PDU, an
ISO DP 9542 PDU, or an IS-IS PDU, will be placed in the data portion
of an IP datagrams at the source. The ISO 8473 entity may fragment
an NSDU into several NPDUs, in which case each NPDU will be
encapsulated in an IP datagram. The intent is for the OSI CLNL to
fragment rather than to have IP fragment, for the purpose of testing
the OSI CLNL. Of course, there is no guarantee that fragmentation
will not occur within the IP subnet, so reassembly must be supported
at the IP level in the destination participating system.
SNPA-addresses (Internet addresses) will be algorithmically derived
from the NSAP-addresses as described below. The "protocol" field of
the IP datagram will take the value 80 (decimal), which has been
assigned for this purpose.
and an "ISO-gram" is
An NPDU for any protocol in the OSI CLNL, including ISO 8473
(CLNP), ISO DP 9542 (ES-IS), and ISO TC 97/SC 6/N xxxx (IS-IS).
I.e., if the IP protocol type/next header field is 80 (0x50), then the payload
is not necessarily a CLNP packet - it could be an ES-IS or IS-IS packet.
Therefore, something else is needed to indicate whether it's CLNP, ES-IS, or
IS-IS. ISO/IEC TR 9577, "Information technology — Protocol identification in
the network layer", says that a one-byte "initial protocol identifier", at the
beginning of the PDU, indicates that 0xcc as an IPI is "not categorized by this
recommendation", but is "in widespread use", with that use being for "RFC 791",
a/k/a IPv4.
Furthermore, RFC 1070 also seems to indicate that there's an "SNAcP header"
before the ISO-gram.
So, as I read RFC 1070, if the "next header" field of an IPv6 datagram header
or extension header has the value 80, what follows that header is *NOT* an ISO
CLNP packet. Perhaps some hardware or software transmits packets in which it
is, but that would require that the sending and receiving hosts agree to use an
encapsulation different from the one specified by RFC 1070.
The Protocol Numbers database at
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1
lists 80 as "ISO-IP", or "ISO Internet Protocol", with no reference other than
"Marshall T Rose", who was one of the authors of RFC 1070. It doesn't have "Y"
in the "IPv6 Extension Header" column, just as 6 (TCP) and 17 (UDP) don't, so
presumably it, like TCP and UDP, are handled the same (other than for
checksumming) in IPv4 and IPv6.
So if there are encapsulations being used for a protocol identifier value of 80
other than the one in RFC 1070, there would need to be a preference controlling
how to handle those packets.
You are receiving this mail because:
- You are watching all bug changes.
