17981 lines
507 KiB
Plaintext
17981 lines
507 KiB
Plaintext
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group H. Kennedy
|
|||
|
|
Request for Comments: 3252 Mimezine
|
|||
|
|
Category: Informational 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This memo provides information for the Internet community. It does
|
|||
|
|
not specify an Internet standard of any kind. Distribution of this
|
|||
|
|
memo is unlimited.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document defines a reformulation of IP and two transport layer
|
|||
|
|
protocols (TCP and UDP) as XML applications.
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
1.1. Overview
|
|||
|
|
|
|||
|
|
This document describes the Binary Lexical Octet Ad-hoc Transport
|
|||
|
|
(BLOAT): a reformulation of a widely-deployed network-layer protocol
|
|||
|
|
(IP [RFC791]), and two associated transport layer protocols (TCP
|
|||
|
|
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
|
|||
|
|
describes methods for transporting BLOAT over Ethernet and IEEE 802
|
|||
|
|
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
|
|||
|
|
across the public Internet.
|
|||
|
|
|
|||
|
|
1.2. Motivation
|
|||
|
|
|
|||
|
|
The wild popularity of XML as a basis for application-level protocols
|
|||
|
|
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
|
|||
|
|
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
|
|||
|
|
investigation into the possibility of extending the use of XML in the
|
|||
|
|
protocol stack. Using XML at both the transport and network layer in
|
|||
|
|
addition to the application layer would provide for an amazing amount
|
|||
|
|
of power and flexibility while removing dependencies on proprietary
|
|||
|
|
and hard-to-understand binary protocols. This protocol unification
|
|||
|
|
would also allow applications to use a single XML parser for all
|
|||
|
|
aspects of their operation, eliminating developer time spent figuring
|
|||
|
|
out the intricacies of each new protocol, and moving the hard work of
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 1]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
parsing to the XML toolset. The use of XML also mitigates concerns
|
|||
|
|
over "network vs. host" byte ordering which is at the root of many
|
|||
|
|
network application bugs.
|
|||
|
|
|
|||
|
|
1.3. Relation to Existing Protocols
|
|||
|
|
|
|||
|
|
The reformulations specified in this RFC follow as closely as
|
|||
|
|
possible the spirit of the RFCs on which they are based, and so MAY
|
|||
|
|
contain elements or attributes that would not be needed in a pure
|
|||
|
|
reworking (e.g. length attributes, which are implicit in XML.)
|
|||
|
|
|
|||
|
|
The layering of network and transport protocols are maintained in
|
|||
|
|
this RFC despite the optimizations that could be made if the line
|
|||
|
|
were somewhat blurred (i.e. merging TCP and IP into a single, larger
|
|||
|
|
element in the DTD) in order to foster future use of this protocol as
|
|||
|
|
a basis for reformulating other protocols (such as ICMP.)
|
|||
|
|
|
|||
|
|
Other than the encoding, the behavioral aspects of each of the
|
|||
|
|
existing protocols remain unchanged. Routing, address spaces, TCP
|
|||
|
|
congestion control, etc. behave as specified in the extant standards.
|
|||
|
|
Adapting to new standards and experimental algorithm heuristics for
|
|||
|
|
improving performance will become much easier once the move to BLOAT
|
|||
|
|
has been completed.
|
|||
|
|
|
|||
|
|
1.4. Requirement Levels
|
|||
|
|
|
|||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
|
document are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
|
[RFC2119].
|
|||
|
|
|
|||
|
|
2. IPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC.
|
|||
|
|
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
|
|||
|
|
(section 3.) and higher-level application protocols.
|
|||
|
|
|
|||
|
|
The DTD for this document type can be found in section 7.1.
|
|||
|
|
|
|||
|
|
The routing of IPoXML can be easily implemented on hosts with an XML
|
|||
|
|
parser, as the regular structure lends itself handily to parsing and
|
|||
|
|
validation of the document/datagram and then processing the
|
|||
|
|
destination address, TTL, and checksum before sending it on to its
|
|||
|
|
next-hop.
|
|||
|
|
|
|||
|
|
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
|
|||
|
|
wider deployment of IPv4 and the fact that implementing IPv6 as XML
|
|||
|
|
would have exceeded the 1500 byte Ethernet MTU.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 2]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
|
|||
|
|
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
|
|||
|
|
formed and include the XMLDecl.
|
|||
|
|
|
|||
|
|
2.1. IP Description
|
|||
|
|
|
|||
|
|
A number of items have changed (for the better) from the original IP
|
|||
|
|
specification. Bit-masks, where present have been converted into
|
|||
|
|
human-readable values. IP addresses are listed in their dotted-
|
|||
|
|
decimal notation [RFC1123]. Length and checksum values are present
|
|||
|
|
as decimal integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the IP element, a
|
|||
|
|
canonicalized form of the element MUST be used. The canonical form
|
|||
|
|
SHALL have no whitespace (including newline characters) between
|
|||
|
|
elements and only one space character between attributes. There
|
|||
|
|
SHALL NOT be a space following the last attribute in an element.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums, as the
|
|||
|
|
length field will vary based on the size of the checksum.
|
|||
|
|
|
|||
|
|
The payload element bears special attention. Due to the character
|
|||
|
|
set restrictions of XML, the payload of IP datagrams (which MAY
|
|||
|
|
contain arbitrary data) MUST be encoded for transport. This RFC
|
|||
|
|
REQUIRES the contents of the payload to be encoded in the base-64
|
|||
|
|
encoding of RFC 2045 [RFC2045], but removes the requirement that the
|
|||
|
|
encoded output MUST be wrapped on 76-character lines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 3]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example IPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
<ip>
|
|||
|
|
<header length="474">
|
|||
|
|
<version value="4"/>
|
|||
|
|
<tos precedence="Routine" delay="Normal" throughput="Normal"
|
|||
|
|
relibility="Normal" reserved="0"/>
|
|||
|
|
<total.length value="461"/>
|
|||
|
|
<id value="1"/>
|
|||
|
|
<flags reserved="0" df="dont" mf="last"/>
|
|||
|
|
<offset value="0"/>
|
|||
|
|
<ttl value="255"/>
|
|||
|
|
<protocol value="6"/>
|
|||
|
|
<checksum value="8707"/>
|
|||
|
|
<source address="10.0.0.22"/>
|
|||
|
|
<destination address="10.0.0.1"/>
|
|||
|
|
<options>
|
|||
|
|
<end copied="0" class="0" number="0"/>
|
|||
|
|
</options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</ip>
|
|||
|
|
|
|||
|
|
3. TCPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.2.
|
|||
|
|
|
|||
|
|
3.1. TCP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original TCP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the TCP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1.
|
|||
|
|
|
|||
|
|
An iterative method SHOULD be used to calculate checksums as in
|
|||
|
|
section 2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 4]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
The TCP offset element was expanded to a maximum of 255 from 16 to
|
|||
|
|
allow for the increased size of the header in XML.
|
|||
|
|
|
|||
|
|
TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
3.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example TCPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
<tcp>
|
|||
|
|
<tcp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<sequence number="322622954"/>
|
|||
|
|
<acknowledgement number="689715995"/>
|
|||
|
|
<offset number=""/>
|
|||
|
|
<reserved value="0"/>
|
|||
|
|
<control syn="1" ack="1"/>
|
|||
|
|
<window size="1"/>
|
|||
|
|
<urgent pointer="0"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
<tcp.options>
|
|||
|
|
<tcp.end kind="0"/>
|
|||
|
|
</tcp.options>
|
|||
|
|
<padding pad="0"/>
|
|||
|
|
</tcp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</tcp>
|
|||
|
|
|
|||
|
|
4. UDPoXML
|
|||
|
|
|
|||
|
|
This protocol MUST be implemented to be compliant with this RFC. The
|
|||
|
|
DTD for this document type can be found in section 7.3.
|
|||
|
|
|
|||
|
|
4.1. UDP Description
|
|||
|
|
|
|||
|
|
A number of items have changed from the original UDP specification.
|
|||
|
|
Bit-masks, where present have been converted into human-readable
|
|||
|
|
values. Length and checksum and port values are present as decimal
|
|||
|
|
integers.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 5]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
To calculate the length and checksum fields of the UDP element, a
|
|||
|
|
canonicalized form of the element MUST be used as in section 2.1. An
|
|||
|
|
iterative method SHOULD be used to calculate checksums as in section
|
|||
|
|
2.1.
|
|||
|
|
|
|||
|
|
The payload element MUST be encoded as in section 2.1.
|
|||
|
|
|
|||
|
|
UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
|
|||
|
|
as well as the <!DOCTYPE> declaration.
|
|||
|
|
|
|||
|
|
4.2. Example Datagram
|
|||
|
|
|
|||
|
|
The following is an example UDPoXML datagram with an empty payload:
|
|||
|
|
|
|||
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
<udp>
|
|||
|
|
<udp.header>
|
|||
|
|
<src port="31415"/>
|
|||
|
|
<dest port="42424"/>
|
|||
|
|
<udp.length value="143"/>
|
|||
|
|
<checksum value="2988"/>
|
|||
|
|
</udp.header>
|
|||
|
|
<payload>
|
|||
|
|
</payload>
|
|||
|
|
</udp>
|
|||
|
|
|
|||
|
|
5. Network Transport
|
|||
|
|
|
|||
|
|
This document provides for the transmission of BLOAT datagrams over
|
|||
|
|
two common families of physical layer transport. Future RFCs will
|
|||
|
|
address additional transports as routing vendors catch up to the
|
|||
|
|
specification, and we begin to see BLOAT routed across the Internet
|
|||
|
|
backbone.
|
|||
|
|
|
|||
|
|
5.1. Ethernet
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
|
|||
|
|
exception that the type field of the Ethernet frame MUST contain the
|
|||
|
|
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
|
|||
|
|
be 0x3c 3f 78 6d 6c ("<?xml".)
|
|||
|
|
|
|||
|
|
5.2. IEEE 802
|
|||
|
|
|
|||
|
|
BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
|
|||
|
|
that the protocol type code for IPoXML is 0xBEEF.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 6]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Gatewaying over IP
|
|||
|
|
|
|||
|
|
In order to facilitate the gradual introduction of BLOAT into the
|
|||
|
|
public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
|
|||
|
|
gateway between networks that run BLOAT natively on their LANs.
|
|||
|
|
|
|||
|
|
7. DTDs
|
|||
|
|
|
|||
|
|
The Transport DTDs (7.2. and 7.3.) build on the definitions in the
|
|||
|
|
Network DTD (7.1.)
|
|||
|
|
|
|||
|
|
The DTDs are referenced by their PubidLiteral and SystemLiteral (from
|
|||
|
|
[XML]) although it is understood that most IPoXML implementations
|
|||
|
|
will not need to pull down the DTD, as it will normally be embedded
|
|||
|
|
in the implementation, and presents something of a catch-22 if you
|
|||
|
|
need to load part of your network protocol over the network.
|
|||
|
|
|
|||
|
|
7.1. IPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for IP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
<!--
|
|||
|
|
DTD data types:
|
|||
|
|
|
|||
|
|
Digits [0..9]+
|
|||
|
|
|
|||
|
|
Precedence "NetworkControl | InternetworkControl |
|
|||
|
|
CRITIC | FlashOverride | Flash | Immediate |
|
|||
|
|
Priority | Routine"
|
|||
|
|
|
|||
|
|
IP4Addr "dotted-decimal" notation of [RFC1123]
|
|||
|
|
|
|||
|
|
Class [0..3]
|
|||
|
|
|
|||
|
|
Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
|
|||
|
|
Restricted | Secret | Top Secret | Reserved"
|
|||
|
|
|
|||
|
|
Compartments [0..65535]
|
|||
|
|
|
|||
|
|
Handling [0..65535]
|
|||
|
|
|
|||
|
|
TCC [0..16777216]
|
|||
|
|
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 7]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ENTITY % Digits "CDATA">
|
|||
|
|
<!ENTITY % Precedence "CDATA">
|
|||
|
|
<!ENTITY % IP4Addr "CDATA">
|
|||
|
|
<!ENTITY % Class "CDATA">
|
|||
|
|
<!ENTITY % Sec "CDATA">
|
|||
|
|
<!ENTITY % Compartments "CDATA">
|
|||
|
|
<!ENTITY % Handling "CDATA">
|
|||
|
|
<!ENTITY % TCC "CDATA">
|
|||
|
|
|
|||
|
|
<!ELEMENT ip (header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
|
|||
|
|
protocol, checksum, source, destination, options,
|
|||
|
|
padding)>
|
|||
|
|
<!-- length of header in 32-bit words -->
|
|||
|
|
<!ATTLIST header
|
|||
|
|
length %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT version EMPTY>
|
|||
|
|
<!-- ip version. SHOULD be "4" -->
|
|||
|
|
<!ATTLIST version
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tos EMPTY>
|
|||
|
|
<!ATTLIST tos
|
|||
|
|
precedence %Precedence; #REQUIRED
|
|||
|
|
delay (normal | low) #REQUIRED
|
|||
|
|
throughput (normal | high) #REQUIRED
|
|||
|
|
relibility (normal | high) #REQUIRED
|
|||
|
|
reserved CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT total.length EMPTY>
|
|||
|
|
<!--
|
|||
|
|
total length of datagram (header and payload) in octets, MUST be
|
|||
|
|
less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
|
|||
|
|
ethernets).
|
|||
|
|
-->
|
|||
|
|
<!ATTLIST total.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT id EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST id
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT flags EMPTY>
|
|||
|
|
<!-- df = don't fragment, mf = more fragments -->
|
|||
|
|
<!ATTLIST flags
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 8]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
reserved CDATA #FIXED "0"
|
|||
|
|
df (may|dont) #REQUIRED
|
|||
|
|
mf (last|more) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT ttl EMPTY>
|
|||
|
|
<!-- 0 <= ttl <= 255 -->
|
|||
|
|
<!ATTLIST ttl
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT protocol EMPTY>
|
|||
|
|
<!-- 0 <= protocol <= 255 (per IANA) -->
|
|||
|
|
<!ATTLIST protocol
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT checksum EMPTY>
|
|||
|
|
<!-- 0 <= checksum <= 65535 (over header only) -->
|
|||
|
|
<!ATTLIST checksum
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT source EMPTY>
|
|||
|
|
<!ATTLIST source
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT destination EMPTY>
|
|||
|
|
<!ATTLIST destination
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT options ( end | noop | security | loose | strict | record
|
|||
|
|
| stream | timestamp )*>
|
|||
|
|
|
|||
|
|
<!ELEMENT end EMPTY>
|
|||
|
|
<!ATTLIST end
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT noop EMPTY>
|
|||
|
|
<!ATTLIST noop
|
|||
|
|
copied (0|1) #REQUIRED
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT security EMPTY>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 9]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST security
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "11"
|
|||
|
|
security %Sec; #REQUIRED
|
|||
|
|
compartments %Compartments; #REQUIRED
|
|||
|
|
handling %Handling; #REQUIRED
|
|||
|
|
tcc %TCC; #REQUIRED>
|
|||
|
|
<!ELEMENT loose (hop)+>
|
|||
|
|
<!ATTLIST loose
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "3"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT hop EMPTY>
|
|||
|
|
<!ATTLIST hop
|
|||
|
|
address %IP4Addr; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT strict (hop)+>
|
|||
|
|
<!ATTLIST strict
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "9"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT record (hop)+>
|
|||
|
|
<!ATTLIST record
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "7"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT stream EMPTY>
|
|||
|
|
<!-- 0 <= id <= 65,535 -->
|
|||
|
|
<!ATTLIST stream
|
|||
|
|
copied CDATA #FIXED "1"
|
|||
|
|
class CDATA #FIXED "0"
|
|||
|
|
number CDATA #FIXED "8"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
id %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT timestamp (tstamp)+>
|
|||
|
|
<!-- 0 <= oflw <=15 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 10]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST timestamp
|
|||
|
|
copied CDATA #FIXED "0"
|
|||
|
|
class CDATA #FIXED "2"
|
|||
|
|
number CDATA #FIXED "4"
|
|||
|
|
length %Digits; #REQUIRED
|
|||
|
|
pointer %Digits; #REQUIRED
|
|||
|
|
oflw %Digits; #REQUIRED
|
|||
|
|
flag (0 | 1 | 3) #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tstamp EMPTY>
|
|||
|
|
<!ATTLIST tstamp
|
|||
|
|
time %Digits; #REQUIRED
|
|||
|
|
address %IP4Addr; #IMPLIED>
|
|||
|
|
<!--
|
|||
|
|
padding to bring header to 32-bit boundary.
|
|||
|
|
pad MUST be "0"*
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT padding EMPTY>
|
|||
|
|
<!ATTLIST padding
|
|||
|
|
pad CDATA #REQUIRED>
|
|||
|
|
|
|||
|
|
<!-- payload MUST be encoded as base-64 [RFC2045], as modified
|
|||
|
|
by section 2.1 of this RFC -->
|
|||
|
|
<!ELEMENT payload (CDATA)>
|
|||
|
|
|
|||
|
|
7.2. TCPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for TCP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!-- the pseudoheader is only included for checksum calculations -->
|
|||
|
|
<!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
|
|||
|
|
reserved, control, window, checksum, urgent,
|
|||
|
|
tcp.options, padding)>
|
|||
|
|
|
|||
|
|
<!ELEMENT src EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
<!ATTLIST src
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT dest EMPTY>
|
|||
|
|
<!-- 0 <= port <= 65,535 -->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 11]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ATTLIST dest
|
|||
|
|
port %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT sequence EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST sequence
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT acknowledgement EMPTY>
|
|||
|
|
<!-- 0 <= number <= 4294967295 -->
|
|||
|
|
<!ATTLIST acknowledgement
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT offset EMPTY>
|
|||
|
|
<!-- 0 <= number <= 255 -->
|
|||
|
|
<!ATTLIST offset
|
|||
|
|
number %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT reserved EMPTY>
|
|||
|
|
<!ATTLIST reserved
|
|||
|
|
value CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT control EMPTY>
|
|||
|
|
<!ATTLIST control
|
|||
|
|
urg (0|1) #IMPLIED
|
|||
|
|
ack (0|1) #IMPLIED
|
|||
|
|
psh (0|1) #IMPLIED
|
|||
|
|
rst (0|1) #IMPLIED
|
|||
|
|
syn (0|1) #IMPLIED
|
|||
|
|
fin (0|1) #IMPLIED>
|
|||
|
|
|
|||
|
|
<!ELEMENT window EMPTY>
|
|||
|
|
<!-- 0 <= size <= 65,535 -->
|
|||
|
|
<!ATTLIST window
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
checksum as in ip, but with
|
|||
|
|
the following pseudo-header added into the tcp element:
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT tcp.pseudoheader (source, destination, protocol,
|
|||
|
|
tcp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
tcp header + data length in octets. does not include the size of
|
|||
|
|
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 12]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.length EMPTY>
|
|||
|
|
<!ATTLIST tcp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT urgent EMPTY>
|
|||
|
|
<!-- 0 <= pointer <= 65,535 -->
|
|||
|
|
<!ATTLIST urgent
|
|||
|
|
pointer %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.end EMPTY>
|
|||
|
|
<!ATTLIST tcp.end
|
|||
|
|
kind CDATA #FIXED "0">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.noop EMPTY>
|
|||
|
|
<!ATTLIST tcp.noop
|
|||
|
|
kind CDATA #FIXED "1">
|
|||
|
|
|
|||
|
|
<!ELEMENT tcp.mss EMPTY>
|
|||
|
|
<!ATTLIST tcp.mss
|
|||
|
|
kind CDATA #FIXED "2"
|
|||
|
|
length CDATA #FIXED "4"
|
|||
|
|
size %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
7.3. UDPoXML DTD
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
DTD for UDP over XML.
|
|||
|
|
Refer to this DTD as:
|
|||
|
|
|
|||
|
|
<!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
<!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.header (src, dest, udp.length, checksum)>
|
|||
|
|
|
|||
|
|
<!ELEMENT udp.pseudoheader (source, destination, protocol,
|
|||
|
|
udp.length)>
|
|||
|
|
|
|||
|
|
<!--
|
|||
|
|
udp header + data length in octets. does not include the size of
|
|||
|
|
the pseudoheader.
|
|||
|
|
-->
|
|||
|
|
<!ELEMENT udp.length EMPTY>
|
|||
|
|
<!ATTLIST udp.length
|
|||
|
|
value %Digits; #REQUIRED>
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 13]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. Security Considerations
|
|||
|
|
|
|||
|
|
XML, as a subset of SGML, has the same security considerations as
|
|||
|
|
specified in SGML Media Types [RFC1874]. Security considerations
|
|||
|
|
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
|
|||
|
|
not attempt to correct for issues not related to message format.
|
|||
|
|
|
|||
|
|
9. References
|
|||
|
|
|
|||
|
|
[JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
|
|||
|
|
February 2002. (Work in Progress)
|
|||
|
|
|
|||
|
|
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
|
August 1980.
|
|||
|
|
|
|||
|
|
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
|
September 1981.
|
|||
|
|
|
|||
|
|
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
|||
|
|
793, September 1981.
|
|||
|
|
|
|||
|
|
[RFC894] Hornig, C., "Standard for the Transmission of IP
|
|||
|
|
Datagrams over Ethernet Networks.", RFC 894, April 1984.
|
|||
|
|
|
|||
|
|
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
|
|||
|
|
Transmission of IP Datagrams Over IEEE 802 Networks", STD
|
|||
|
|
43, RFC 1042, February 1988.
|
|||
|
|
|
|||
|
|
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
|||
|
|
Application and Support", RFC 1123, October 1989.
|
|||
|
|
|
|||
|
|
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
|
|||
|
|
1995.
|
|||
|
|
|
|||
|
|
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
|
October 1996.
|
|||
|
|
|
|||
|
|
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
|
Extensions (MIME) Part One: Format of Internet Message
|
|||
|
|
Bodies", RFC 2045, November 1996.
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
|
10646", RFC 2279, January 1998.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 14]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
|||
|
|
(IPv6) Specification", RFC 2460, December 1998.
|
|||
|
|
|
|||
|
|
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
|
|||
|
|
RFC 3080, March 2001.
|
|||
|
|
|
|||
|
|
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
|
|||
|
|
Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
|
|||
|
|
"Simple Object Access Protocol (SOAP) 1.1" World Wide Web
|
|||
|
|
Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
|
|||
|
|
|
|||
|
|
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
|
|||
|
|
Markup Language (XML)" World Wide Web Consortium
|
|||
|
|
Recommendation REC- xml-19980210.
|
|||
|
|
http://www.w3.org/TR/1998/REC-xml-19980210
|
|||
|
|
|
|||
|
|
10. Author's Address
|
|||
|
|
|
|||
|
|
Hugh Kennedy
|
|||
|
|
Mimezine
|
|||
|
|
1060 West Addison
|
|||
|
|
Chicago, IL 60613
|
|||
|
|
USA
|
|||
|
|
|
|||
|
|
EMail: kennedyh@engin.umich.edu
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 15]
|
|||
|
|
|
|||
|
|
RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
|
|||
|
|
|
|||
|
|
|
|||
|
|
11. Full Copyright Statement
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|||
|
|
|
|||
|
|
This document and translations of it may be copied and furnished to
|
|||
|
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
|
or assist in its implementation may be prepared, copied, published
|
|||
|
|
and distributed, in whole or in part, without restriction of any
|
|||
|
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
|
included on all such copies and derivative works. However, this
|
|||
|
|
document itself may not be modified in any way, such as by removing
|
|||
|
|
the copyright notice or references to the Internet Society or other
|
|||
|
|
Internet organizations, except as needed for the purpose of
|
|||
|
|
developing Internet standards in which case the procedures for
|
|||
|
|
copyrights defined in the Internet Standards process must be
|
|||
|
|
followed, or as required to translate it into languages other than
|
|||
|
|
English.
|
|||
|
|
|
|||
|
|
The limited permissions granted above are perpetual and will not be
|
|||
|
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|
|||
|
|
This document and the information contained herein is provided on an
|
|||
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|
|||
|
|
Acknowledgement
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kennedy Informational [Page 16]
|
|||
|
|
|