1 

     2 

     3 

     4 

     5 

     6 

     7 Network Working Group                                         H. Kennedy

     8 Request for Comments: 3252                                      Mimezine

     9 Category: Informational                                     1 April 2002

    10 

    11 

    12                  Binary Lexical Octet Ad-hoc Transport

    13 

    14 Status of this Memo

    15 

    16    This memo provides information for the Internet community.  It does

    17    not specify an Internet standard of any kind.  Distribution of this

    18    memo is unlimited.

    19 

    20 Copyright Notice

    21 

    22    Copyright (C) The Internet Society (2002).  All Rights Reserved.

    23 

    24 Abstract

    25 

    26    This document defines a reformulation of IP and two transport layer

    27    protocols (TCP and UDP) as XML applications.

    28 

    29 1.   Introduction

    30 

    31 1.1. Overview

    32 

    33    This document describes the Binary Lexical Octet Ad-hoc Transport

    34    (BLOAT): a reformulation of a widely-deployed network-layer protocol

    35    (IP [RFC791]), and two associated transport layer protocols (TCP

    36    [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also

    37    describes methods for transporting BLOAT over Ethernet and IEEE 802

    38    networks as well as encapsulating BLOAT in IP for gatewaying BLOAT

    39    across the public Internet.

    40 

    41 1.2. Motivation

    42 

    43    The wild popularity of XML as a basis for application-level protocols

    44    such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple

    45    Object Access Protocol [SOAP], and Jabber [JABBER] prompted

    46    investigation into the possibility of extending the use of XML in the

    47    protocol stack.  Using XML at both the transport and network layer in

    48    addition to the application layer would provide for an amazing amount

    49    of power and flexibility while removing dependencies on proprietary

    50    and hard-to-understand binary protocols.  This protocol unification

    51    would also allow applications to use a single XML parser for all

    52    aspects of their operation, eliminating developer time spent figuring

    53    out the intricacies of each new protocol, and moving the hard work of

    54 

    55 

    56 

    57 

    58 Kennedy                      Informational                      [Page 1]

    59 

    60 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

    61 

    62 

    63    parsing to the XML toolset.  The use of XML also mitigates concerns

    64    over "network vs. host" byte ordering which is at the root of many

    65    network application bugs.

    66 

    67 1.3. Relation to Existing Protocols

    68 

    69    The reformulations specified in this RFC follow as closely as

    70    possible the spirit of the RFCs on which they are based, and so MAY

    71    contain elements or attributes that would not be needed in a pure

    72    reworking (e.g. length attributes, which are implicit in XML.)

    73 

    74    The layering of network and transport protocols are maintained in

    75    this RFC despite the optimizations that could be made if the line

    76    were somewhat blurred (i.e. merging TCP and IP into a single, larger

    77    element in the DTD) in order to foster future use of this protocol as

    78    a basis for reformulating other protocols (such as ICMP.)

    79 

    80    Other than the encoding, the behavioral aspects of each of the

    81    existing protocols remain unchanged.  Routing, address spaces, TCP

    82    congestion control, etc. behave as specified in the extant standards.

    83    Adapting to new standards and experimental algorithm heuristics for

    84    improving performance will become much easier once the move to BLOAT

    85    has been completed.

    86 

    87 1.4. Requirement Levels

    88 

    89    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

    90    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

    91    document are to be interpreted as described in BCP 14, RFC 2119

    92    [RFC2119].

    93 

    94 2.   IPoXML

    95 

    96    This protocol MUST be implemented to be compliant with this RFC.

    97    IPoXML is the root protocol REQUIRED for effective use of TCPoXML

    98    (section 3.) and higher-level application protocols.

    99 

   100    The DTD for this document type can be found in section 7.1.

   101 

   102    The routing of IPoXML can be easily implemented on hosts with an XML

   103    parser, as the regular structure lends itself handily to parsing and

   104    validation of the document/datagram and then processing the

   105    destination address, TTL, and checksum before sending it on to its

   106    next-hop.

   107 

   108    The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the

   109    wider deployment of IPv4 and the fact that implementing IPv6 as XML

   110    would have exceeded the 1500 byte Ethernet MTU.

   111 

   112 

   113 

   114 Kennedy                      Informational                      [Page 2]

   115 

   116 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   117 

   118 

   119    All BLOAT implementations MUST use - and specify - the UTF-8 encoding

   120    of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-

   121    formed and include the XMLDecl.

   122 

   123 2.1. IP Description

   124 

   125    A number of items have changed (for the better) from the original IP

   126    specification.  Bit-masks, where present have been converted into

   127    human-readable values.  IP addresses are listed in their dotted-

   128    decimal notation [RFC1123].  Length and checksum values are present

   129    as decimal integers.

   130 

   131    To calculate the length and checksum fields of the IP element, a

   132    canonicalized form of the element MUST be used.  The canonical form

   133    SHALL have no whitespace (including newline characters) between

   134    elements and only one space character between attributes.  There

   135    SHALL NOT be a space following the last attribute in an element.

   136 

   137    An iterative method SHOULD be used to calculate checksums, as the

   138    length field will vary based on the size of the checksum.

   139 

   140    The payload element bears special attention.  Due to the character

   141    set restrictions of XML, the payload of IP datagrams (which MAY

   142    contain arbitrary data) MUST be encoded for transport. This RFC

   143    REQUIRES the contents of the payload to be encoded in the base-64

   144    encoding of RFC 2045 [RFC2045], but removes the requirement that the

   145    encoded output MUST be wrapped on 76-character lines.

   146 

   147 

   148 

   149 

   150 

   151 

   152 

   153 

   154 

   155 

   156 

   157 

   158 

   159 

   160 

   161 

   162 

   163 

   164 

   165 

   166 

   167 

   168 

   169 

   170 Kennedy                      Informational                      [Page 3]

   171 

   172 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   173 

   174 

   175 2.2. Example Datagram

   176 

   177    The following is an example IPoXML datagram with an empty payload:

   178 

   179    <?xml version="1.0" encoding="UTF-8"?>

   180    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">

   181    <ip>

   182    <header length="474">

   183    <version value="4"/>

   184    <tos precedence="Routine" delay="Normal" throughput="Normal"

   185         relibility="Normal" reserved="0"/>

   186    <total.length value="461"/>

   187    <id value="1"/>

   188    <flags reserved="0" df="dont" mf="last"/>

   189    <offset value="0"/>

   190    <ttl value="255"/>

   191    <protocol value="6"/>

   192    <checksum value="8707"/>

   193    <source address="10.0.0.22"/>

   194    <destination address="10.0.0.1"/>

   195    <options>

   196    <end copied="0" class="0" number="0"/>

   197    </options>

   198    <padding pad="0"/>

   199    </header>

   200    <payload>

   201    </payload>

   202    </ip>

   203 

   204 3.   TCPoXML

   205 

   206    This protocol MUST be implemented to be compliant with this RFC.  The

   207    DTD for this document type can be found in section 7.2.

   208 

   209 3.1. TCP Description

   210 

   211    A number of items have changed from the original TCP specification.

   212    Bit-masks, where present have been converted into human-readable

   213    values.  Length and checksum and port values are present as decimal

   214    integers.

   215 

   216    To calculate the length and checksum fields of the TCP element, a

   217    canonicalized form of the element MUST be used as in section 2.1.

   218 

   219    An iterative method SHOULD be used to calculate checksums as in

   220    section 2.1.

   221 

   222    The payload element MUST be encoded as in section 2.1.

   223 

   224 

   225 

   226 Kennedy                      Informational                      [Page 4]

   227 

   228 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   229 

   230 

   231    The TCP offset element was expanded to a maximum of 255 from 16 to

   232    allow for the increased size of the header in XML.

   233 

   234    TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header

   235    as well as the <!DOCTYPE> declaration.

   236 

   237 3.2. Example Datagram

   238 

   239    The following is an example TCPoXML datagram with an empty payload:

   240 

   241    <?xml version="1.0" encoding="UTF-8"?>

   242    <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">

   243    <tcp>

   244    <tcp.header>

   245    <src port="31415"/>

   246    <dest port="42424"/>

   247    <sequence number="322622954"/>

   248    <acknowledgement number="689715995"/>

   249    <offset number=""/>

   250    <reserved value="0"/>

   251    <control syn="1" ack="1"/>

   252    <window size="1"/>

   253    <urgent pointer="0"/>

   254    <checksum value="2988"/>

   255    <tcp.options>

   256    <tcp.end kind="0"/>

   257    </tcp.options>

   258    <padding pad="0"/>

   259    </tcp.header>

   260    <payload>

   261    </payload>

   262    </tcp>

   263 

   264 4.   UDPoXML

   265 

   266    This protocol MUST be implemented to be compliant with this RFC.  The

   267    DTD for this document type can be found in section 7.3.

   268 

   269 4.1. UDP Description

   270 

   271    A number of items have changed from the original UDP specification.

   272    Bit-masks, where present have been converted into human-readable

   273    values.  Length and checksum and port values are present as decimal

   274    integers.

   275 

   276 

   277 

   278 

   279 

   280 

   281 

   282 Kennedy                      Informational                      [Page 5]

   283 

   284 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   285 

   286 

   287    To calculate the length and checksum fields of the UDP element, a

   288    canonicalized form of the element MUST be used as in section 2.1.  An

   289    iterative method SHOULD be used to calculate checksums as in section

   290    2.1.

   291 

   292    The payload element MUST be encoded as in section 2.1.

   293 

   294    UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header

   295    as well as the <!DOCTYPE> declaration.

   296 

   297 4.2. Example Datagram

   298 

   299    The following is an example UDPoXML datagram with an empty payload:

   300 

   301    <?xml version="1.0" encoding="UTF-8"?>

   302    <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">

   303    <udp>

   304    <udp.header>

   305    <src port="31415"/>

   306    <dest port="42424"/>

   307    <udp.length value="143"/>

   308    <checksum value="2988"/>

   309    </udp.header>

   310    <payload>

   311    </payload>

   312    </udp>

   313 

   314 5.   Network Transport

   315 

   316    This document provides for the transmission of BLOAT datagrams over

   317    two common families of physical layer transport.  Future RFCs will

   318    address additional transports as routing vendors catch up to the

   319    specification, and we begin to see BLOAT routed across the Internet

   320    backbone.

   321 

   322 5.1. Ethernet

   323 

   324    BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the

   325    exception that the type field of the Ethernet frame MUST contain the

   326    value 0xBEEF.  The first 5 octets of the Ethernet frame payload will

   327    be 0x3c 3f 78 6d 6c ("<?xml".)

   328 

   329 5.2. IEEE 802

   330 

   331    BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except

   332    that the protocol type code for IPoXML is 0xBEEF.

   333 

   334 

   335 

   336 

   337 

   338 Kennedy                      Informational                      [Page 6]

   339 

   340 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   341 

   342 

   343 6. Gatewaying over IP

   344 

   345    In order to facilitate the gradual introduction of BLOAT into the

   346    public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to

   347    gateway between networks that run BLOAT natively on their LANs.

   348 

   349 7. DTDs

   350 

   351    The Transport DTDs (7.2. and 7.3.) build on the definitions in the

   352    Network DTD (7.1.)

   353 

   354    The DTDs are referenced by their PubidLiteral and SystemLiteral (from

   355    [XML]) although it is understood that most IPoXML implementations

   356    will not need to pull down the DTD, as it will normally be embedded

   357    in the implementation, and presents something of a catch-22 if you

   358    need to load part of your network protocol over the network.

   359 

   360 7.1.  IPoXML DTD

   361 

   362    <!--

   363     DTD for IP over XML.

   364     Refer to this DTD as:

   365 

   366     <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">

   367    -->

   368    <!--

   369     DTD data types:

   370 

   371       Digits      [0..9]+

   372 

   373       Precedence  "NetworkControl | InternetworkControl |

   374                    CRITIC | FlashOverride | Flash | Immediate |

   375                    Priority | Routine"

   376 

   377       IP4Addr     "dotted-decimal" notation of [RFC1123]

   378 

   379       Class       [0..3]

   380 

   381       Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |

   382                     Restricted | Secret | Top Secret | Reserved"

   383 

   384       Compartments [0..65535]

   385 

   386       Handling     [0..65535]

   387 

   388       TCC          [0..16777216]

   389 

   390    -->

   391 

   392 

   393 

   394 Kennedy                      Informational                      [Page 7]

   395 

   396 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   397 

   398 

   399    <!ENTITY % Digits "CDATA">

   400    <!ENTITY % Precedence "CDATA">

   401    <!ENTITY % IP4Addr "CDATA">

   402    <!ENTITY % Class "CDATA">

   403    <!ENTITY % Sec "CDATA">

   404    <!ENTITY % Compartments "CDATA">

   405    <!ENTITY % Handling "CDATA">

   406    <!ENTITY % TCC "CDATA">

   407 

   408    <!ELEMENT ip (header, payload)>

   409 

   410    <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,

   411                     protocol, checksum, source, destination, options,

   412                     padding)>

   413    <!-- length of header in 32-bit words -->

   414    <!ATTLIST header

   415              length %Digits; #REQUIRED>

   416 

   417    <!ELEMENT version EMPTY>

   418    <!-- ip version. SHOULD be "4" -->

   419    <!ATTLIST version

   420              value   %Digits;  #REQUIRED>

   421 

   422    <!ELEMENT tos EMPTY>

   423    <!ATTLIST tos

   424              precedence   %Precedence;    #REQUIRED

   425              delay    (normal | low)  #REQUIRED

   426              throughput   (normal | high) #REQUIRED

   427              relibility   (normal | high) #REQUIRED

   428              reserved     CDATA #FIXED "0">

   429 

   430    <!ELEMENT total.length EMPTY>

   431    <!--

   432     total length of datagram (header and payload) in octets, MUST be

   433     less than 65,535 (and SHOULD be less than 1024 for IPoXML on local

   434     ethernets).

   435    -->

   436    <!ATTLIST total.length

   437              value %Digits; #REQUIRED>

   438 

   439    <!ELEMENT id EMPTY>

   440    <!-- 0 <= id <= 65,535  -->

   441    <!ATTLIST id

   442              value %Digits; #REQUIRED>

   443 

   444    <!ELEMENT flags EMPTY>

   445    <!-- df = don't fragment, mf = more fragments  -->

   446    <!ATTLIST flags

   447 

   448 

   449 

   450 Kennedy                      Informational                      [Page 8]

   451 

   452 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   453 

   454 

   455           reserved CDATA  #FIXED "0"

   456           df (may|dont)   #REQUIRED

   457           mf (last|more)  #REQUIRED>

   458 

   459    <!ELEMENT offset EMPTY>

   460    <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->

   461    <!ATTLIST offset

   462              value %Digits; #REQUIRED>

   463 

   464    <!ELEMENT ttl EMPTY>

   465    <!-- 0 <= ttl <= 255 -->

   466    <!ATTLIST ttl

   467              value %Digits; #REQUIRED>

   468 

   469    <!ELEMENT protocol EMPTY>

   470    <!-- 0 <= protocol <= 255 (per IANA) -->

   471    <!ATTLIST protocol

   472              value %Digits; #REQUIRED>

   473 

   474    <!ELEMENT checksum EMPTY>

   475    <!-- 0 <= checksum <= 65535 (over header only) -->

   476    <!ATTLIST checksum

   477              value %Digits; #REQUIRED>

   478 

   479    <!ELEMENT source EMPTY>

   480    <!ATTLIST source

   481              address %IP4Addr; #REQUIRED>

   482 

   483    <!ELEMENT destination EMPTY>

   484    <!ATTLIST destination

   485              address %IP4Addr; #REQUIRED>

   486 

   487    <!ELEMENT options ( end | noop | security | loose | strict | record

   488                      | stream | timestamp )*>

   489 

   490    <!ELEMENT end EMPTY>

   491    <!ATTLIST end

   492              copied (0|1) #REQUIRED

   493              class  CDATA #FIXED "0"

   494              number CDATA #FIXED "0">

   495 

   496    <!ELEMENT noop EMPTY>

   497    <!ATTLIST noop

   498              copied (0|1) #REQUIRED

   499              class  CDATA #FIXED "0"

   500              number CDATA #FIXED "1">

   501 

   502    <!ELEMENT security EMPTY>

   503 

   504 

   505 

   506 Kennedy                      Informational                      [Page 9]

   507 

   508 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   509 

   510 

   511    <!ATTLIST security

   512              copied CDATA #FIXED "1"

   513              class  CDATA #FIXED "0"

   514              number CDATA #FIXED "2"

   515              length CDATA #FIXED "11"

   516              security %Sec; #REQUIRED

   517              compartments %Compartments; #REQUIRED

   518              handling %Handling; #REQUIRED

   519              tcc %TCC; #REQUIRED>

   520    <!ELEMENT loose (hop)+>

   521    <!ATTLIST loose

   522              copied CDATA #FIXED "1"

   523              class  CDATA #FIXED "0"

   524              number CDATA #FIXED "3"

   525              length %Digits; #REQUIRED

   526              pointer %Digits; #REQUIRED>

   527 

   528    <!ELEMENT hop EMPTY>

   529    <!ATTLIST hop

   530              address %IP4Addr; #REQUIRED>

   531 

   532    <!ELEMENT strict (hop)+>

   533    <!ATTLIST strict

   534              copied CDATA #FIXED "1"

   535              class  CDATA #FIXED "0"

   536              number CDATA #FIXED "9"

   537              length %Digits; #REQUIRED

   538              pointer %Digits; #REQUIRED>

   539 

   540    <!ELEMENT record (hop)+>

   541    <!ATTLIST record

   542              copied CDATA #FIXED "0"

   543              class  CDATA #FIXED "0"

   544              number CDATA #FIXED "7"

   545              length %Digits; #REQUIRED

   546              pointer %Digits; #REQUIRED>

   547 

   548    <!ELEMENT stream EMPTY>

   549    <!-- 0 <= id <= 65,535 -->

   550    <!ATTLIST stream

   551              copied CDATA #FIXED "1"

   552              class  CDATA #FIXED "0"

   553              number CDATA #FIXED "8"

   554              length CDATA #FIXED "4"

   555              id %Digits; #REQUIRED>

   556 

   557    <!ELEMENT timestamp (tstamp)+>

   558    <!-- 0 <= oflw <=15 -->

   559 

   560 

   561 

   562 Kennedy                      Informational                     [Page 10]

   563 

   564 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   565 

   566 

   567    <!ATTLIST timestamp

   568              copied CDATA #FIXED "0"

   569              class  CDATA #FIXED "2"

   570              number CDATA #FIXED "4"

   571              length %Digits;  #REQUIRED

   572              pointer %Digits; #REQUIRED

   573              oflw %Digits;    #REQUIRED

   574              flag (0 | 1 | 3)  #REQUIRED>

   575 

   576    <!ELEMENT tstamp EMPTY>

   577    <!ATTLIST tstamp

   578              time %Digits;   #REQUIRED

   579              address %IP4Addr; #IMPLIED>

   580    <!--

   581        padding to bring header to 32-bit boundary.

   582        pad MUST be "0"*

   583     -->

   584    <!ELEMENT padding EMPTY>

   585    <!ATTLIST padding

   586              pad CDATA #REQUIRED>

   587 

   588    <!-- payload MUST be encoded as base-64 [RFC2045], as modified

   589         by section 2.1 of this RFC -->

   590    <!ELEMENT payload (CDATA)>

   591 

   592 7.2.  TCPoXML DTD

   593 

   594    <!--

   595       DTD for TCP over XML.

   596       Refer to this DTD as:

   597 

   598       <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">

   599    -->

   600 

   601    <!-- the pseudoheader is only included for checksum calculations -->

   602    <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>

   603 

   604    <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,

   605                          reserved, control, window, checksum, urgent,

   606                          tcp.options, padding)>

   607 

   608    <!ELEMENT src EMPTY>

   609    <!-- 0 <= port <= 65,535 -->

   610    <!ATTLIST src

   611              port %Digits; #REQUIRED>

   612 

   613    <!ELEMENT dest EMPTY>

   614    <!-- 0 <= port <= 65,535 -->

   615 

   616 

   617 

   618 Kennedy                      Informational                     [Page 11]

   619 

   620 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   621 

   622 

   623    <!ATTLIST dest

   624              port %Digits; #REQUIRED>

   625 

   626    <!ELEMENT sequence EMPTY>

   627    <!-- 0 <= number <= 4294967295 -->

   628    <!ATTLIST sequence

   629              number %Digits; #REQUIRED>

   630 

   631    <!ELEMENT acknowledgement EMPTY>

   632    <!-- 0 <= number <= 4294967295 -->

   633    <!ATTLIST acknowledgement

   634              number %Digits; #REQUIRED>

   635 

   636    <!ELEMENT offset EMPTY>

   637    <!-- 0 <= number <= 255 -->

   638    <!ATTLIST offset

   639              number %Digits; #REQUIRED>

   640 

   641    <!ELEMENT reserved EMPTY>

   642    <!ATTLIST reserved

   643              value CDATA #FIXED "0">

   644 

   645    <!ELEMENT control EMPTY>

   646    <!ATTLIST control

   647              urg (0|1) #IMPLIED

   648              ack (0|1) #IMPLIED

   649              psh (0|1) #IMPLIED

   650              rst (0|1) #IMPLIED

   651              syn (0|1) #IMPLIED

   652              fin (0|1) #IMPLIED>

   653 

   654    <!ELEMENT window EMPTY>

   655    <!-- 0 <= size <= 65,535 -->

   656    <!ATTLIST window

   657              size %Digits; #REQUIRED>

   658 

   659    <!--

   660       checksum as in ip, but with

   661       the following pseudo-header added into the tcp element:

   662      -->

   663    <!ELEMENT tcp.pseudoheader (source, destination, protocol,

   664                                tcp.length)>

   665 

   666    <!--

   667       tcp header + data length in octets. does not include the size of

   668 

   669       the pseudoheader.

   670     -->

   671 

   672 

   673 

   674 Kennedy                      Informational                     [Page 12]

   675 

   676 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   677 

   678 

   679    <!ELEMENT tcp.length EMPTY>

   680    <!ATTLIST tcp.length

   681              value %Digits; #REQUIRED>

   682 

   683    <!ELEMENT urgent EMPTY>

   684    <!-- 0 <= pointer <= 65,535 -->

   685    <!ATTLIST urgent

   686              pointer %Digits; #REQUIRED>

   687 

   688    <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>

   689 

   690    <!ELEMENT tcp.end EMPTY>

   691    <!ATTLIST tcp.end

   692              kind CDATA #FIXED "0">

   693 

   694    <!ELEMENT tcp.noop EMPTY>

   695    <!ATTLIST tcp.noop

   696              kind CDATA #FIXED "1">

   697 

   698    <!ELEMENT tcp.mss EMPTY>

   699    <!ATTLIST tcp.mss

   700              kind CDATA #FIXED "2"

   701              length CDATA #FIXED "4"

   702              size %Digits; #REQUIRED>

   703 

   704 7.3.  UDPoXML DTD

   705 

   706    <!--

   707       DTD for UDP over XML.

   708       Refer to this DTD as:

   709 

   710       <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">

   711    -->

   712 

   713    <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>

   714 

   715    <!ELEMENT udp.header (src, dest, udp.length, checksum)>

   716 

   717    <!ELEMENT udp.pseudoheader (source, destination, protocol,

   718                                udp.length)>

   719 

   720    <!--

   721       udp header + data length in octets. does not include the size of

   722       the pseudoheader.

   723     -->

   724    <!ELEMENT udp.length EMPTY>

   725    <!ATTLIST udp.length

   726              value %Digits; #REQUIRED>

   727 

   728 

   729 

   730 Kennedy                      Informational                     [Page 13]

   731 

   732 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   733 

   734 

   735 8. Security Considerations

   736 

   737    XML, as a subset of SGML, has the same security considerations as

   738    specified in SGML Media Types [RFC1874].  Security considerations

   739    that apply to IP, TCP and UDP also likely apply to BLOAT as it does

   740    not attempt to correct for issues not related to message format.

   741 

   742 9.   References

   743 

   744    [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,

   745                February 2002. (Work in Progress)

   746 

   747    [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,

   748                August 1980.

   749 

   750    [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,

   751                September 1981.

   752 

   753    [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC

   754                793, September 1981.

   755 

   756    [RFC894]    Hornig, C., "Standard for the Transmission of IP

   757                Datagrams over Ethernet Networks.", RFC 894, April 1984.

   758 

   759    [RFC1042]   Postel, J. and J. Reynolds, "Standard for the

   760                Transmission of IP Datagrams Over IEEE 802 Networks", STD

   761                43, RFC 1042, February 1988.

   762 

   763    [RFC1123]   Braden, R., "Requirements for Internet Hosts -

   764                Application and Support", RFC 1123, October 1989.

   765 

   766    [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December

   767                1995.

   768 

   769    [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,

   770                October 1996.

   771 

   772    [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail

   773                Extensions (MIME) Part One: Format of Internet Message

   774                Bodies", RFC 2045, November 1996.

   775 

   776    [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate

   777                Requirement Levels", BCP 14, RFC 2119, March 1997.

   778 

   779    [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO

   780                10646", RFC 2279, January 1998.

   781 

   782 

   783 

   784 

   785 

   786 Kennedy                      Informational                     [Page 14]

   787 

   788 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   789 

   790 

   791    [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6

   792                (IPv6) Specification", RFC 2460, December 1998.

   793 

   794    [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",

   795                RFC 3080, March 2001.

   796 

   797    [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,

   798                Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,

   799                "Simple Object Access Protocol (SOAP) 1.1" World Wide Web

   800                Consortium Note, May 2000 http://www.w3.org/TR/SOAP/

   801 

   802    [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible

   803                Markup Language (XML)" World Wide Web Consortium

   804                Recommendation REC- xml-19980210.

   805                http://www.w3.org/TR/1998/REC-xml-19980210

   806 

   807 10.  Author's Address

   808 

   809    Hugh Kennedy

   810    Mimezine

   811    1060 West Addison

   812    Chicago, IL 60613

   813    USA

   814 

   815    EMail: kennedyh@engin.umich.edu

   816 

   817 

   818 

   819 

   820 

   821 

   822 

   823 

   824 

   825 

   826 

   827 

   828 

   829 

   830 

   831 

   832 

   833 

   834 

   835 

   836 

   837 

   838 

   839 

   840 

   841 

   842 Kennedy                      Informational                     [Page 15]

   843 

   844 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   845 

   846 

   847 11.  Full Copyright Statement

   848 

   849    Copyright (C) The Internet Society (2002).  All Rights Reserved.

   850 

   851    This document and translations of it may be copied and furnished to

   852    others, and derivative works that comment on or otherwise explain it

   853    or assist in its implementation may be prepared, copied, published

   854    and distributed, in whole or in part, without restriction of any

   855    kind, provided that the above copyright notice and this paragraph are

   856    included on all such copies and derivative works.  However, this

   857    document itself may not be modified in any way, such as by removing

   858    the copyright notice or references to the Internet Society or other

   859    Internet organizations, except as needed for the purpose of

   860    developing Internet standards in which case the procedures for

   861    copyrights defined in the Internet Standards process must be

   862    followed, or as required to translate it into languages other than

   863    English.

   864 

   865    The limited permissions granted above are perpetual and will not be

   866    revoked by the Internet Society or its successors or assigns.

   867 

   868    This document and the information contained herein is provided on an

   869    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

   870    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

   871    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

   872    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

   873    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   874 

   875 Acknowledgement

   876 

   877    Funding for the RFC Editor function is currently provided by the

   878    Internet Society.

   879 

   880 

   881 

   882 

   883 

   884 

   885 

   886 

   887 

   888 

   889 

   890 

   891 

   892 

   893 

   894 

   895 

   896 

   897 

   898 Kennedy                      Informational                     [Page 16]

   899 

   900 

   901 

   902 

   903 

   904 

   905 

   906 Network Working Group                                         H. Kennedy

   907 Request for Comments: 3252                                      Mimezine

   908 Category: Informational                                     1 April 2002

   909 

   910 

   911                  Binary Lexical Octet Ad-hoc Transport

   912 

   913 Status of this Memo

   914 

   915    This memo provides information for the Internet community.  It does

   916    not specify an Internet standard of any kind.  Distribution of this

   917    memo is unlimited.

   918 

   919 Copyright Notice

   920 

   921    Copyright (C) The Internet Society (2002).  All Rights Reserved.

   922 

   923 Abstract

   924 

   925    This document defines a reformulation of IP and two transport layer

   926    protocols (TCP and UDP) as XML applications.

   927 

   928 1.   Introduction

   929 

   930 1.1. Overview

   931 

   932    This document describes the Binary Lexical Octet Ad-hoc Transport

   933    (BLOAT): a reformulation of a widely-deployed network-layer protocol

   934    (IP [RFC791]), and two associated transport layer protocols (TCP

   935    [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also

   936    describes methods for transporting BLOAT over Ethernet and IEEE 802

   937    networks as well as encapsulating BLOAT in IP for gatewaying BLOAT

   938    across the public Internet.

   939 

   940 1.2. Motivation

   941 

   942    The wild popularity of XML as a basis for application-level protocols

   943    such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple

   944    Object Access Protocol [SOAP], and Jabber [JABBER] prompted

   945    investigation into the possibility of extending the use of XML in the

   946    protocol stack.  Using XML at both the transport and network layer in

   947    addition to the application layer would provide for an amazing amount

   948    of power and flexibility while removing dependencies on proprietary

   949    and hard-to-understand binary protocols.  This protocol unification

   950    would also allow applications to use a single XML parser for all

   951    aspects of their operation, eliminating developer time spent figuring

   952    out the intricacies of each new protocol, and moving the hard work of

   953 

   954 

   955 

   956 

   957 Kennedy                      Informational                      [Page 1]

   958 

   959 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

   960 

   961 

   962    parsing to the XML toolset.  The use of XML also mitigates concerns

   963    over "network vs. host" byte ordering which is at the root of many

   964    network application bugs.

   965 

   966 1.3. Relation to Existing Protocols

   967 

   968    The reformulations specified in this RFC follow as closely as

   969    possible the spirit of the RFCs on which they are based, and so MAY

   970    contain elements or attributes that would not be needed in a pure

   971    reworking (e.g. length attributes, which are implicit in XML.)

   972 

   973    The layering of network and transport protocols are maintained in

   974    this RFC despite the optimizations that could be made if the line

   975    were somewhat blurred (i.e. merging TCP and IP into a single, larger

   976    element in the DTD) in order to foster future use of this protocol as

   977    a basis for reformulating other protocols (such as ICMP.)

   978 

   979    Other than the encoding, the behavioral aspects of each of the

   980    existing protocols remain unchanged.  Routing, address spaces, TCP

   981    congestion control, etc. behave as specified in the extant standards.

   982    Adapting to new standards and experimental algorithm heuristics for

   983    improving performance will become much easier once the move to BLOAT

   984    has been completed.

   985 

   986 1.4. Requirement Levels

   987 

   988    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   989    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

   990    document are to be interpreted as described in BCP 14, RFC 2119

   991    [RFC2119].

   992 

   993 2.   IPoXML

   994 

   995    This protocol MUST be implemented to be compliant with this RFC.

   996    IPoXML is the root protocol REQUIRED for effective use of TCPoXML

   997    (section 3.) and higher-level application protocols.

   998 

   999    The DTD for this document type can be found in section 7.1.

  1000 

  1001    The routing of IPoXML can be easily implemented on hosts with an XML

  1002    parser, as the regular structure lends itself handily to parsing and

  1003    validation of the document/datagram and then processing the

  1004    destination address, TTL, and checksum before sending it on to its

  1005    next-hop.

  1006 

  1007    The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the

  1008    wider deployment of IPv4 and the fact that implementing IPv6 as XML

  1009    would have exceeded the 1500 byte Ethernet MTU.

  1010 

  1011 

  1012 

  1013 Kennedy                      Informational                      [Page 2]

  1014 

  1015 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

  1016 

  1017 

  1018    All BLOAT implementations MUST use - and specify - the UTF-8 encoding

  1019    of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-

  1020    formed and include the XMLDecl.

  1021 

  1022 2.1. IP Description

  1023 

  1024    A number of items have changed (for the better) from the original IP

  1025    specification.  Bit-masks, where present have been converted into

  1026    human-readable values.  IP addresses are listed in their dotted-

  1027    decimal notation [RFC1123].  Length and checksum values are present

  1028    as decimal integers.

  1029 

  1030    To calculate the length and checksum fields of the IP element, a

  1031    canonicalized form of the element MUST be used.  The canonical form

  1032    SHALL have no whitespace (including newline characters) between

  1033    elements and only one space character between attributes.  There

  1034    SHALL NOT be a space following the last attribute in an element.

  1035 

  1036    An iterative method SHOULD be used to calculate checksums, as the

  1037    length field will vary based on the size of the checksum.

  1038 

  1039    The payload element bears special attention.  Due to the character

  1040    set restrictions of XML, the payload of IP datagrams (which MAY

  1041    contain arbitrary data) MUST be encoded for transport. This RFC

  1042    REQUIRES the contents of the payload to be encoded in the base-64

  1043    encoding of RFC 2045 [RFC2045], but removes the requirement that the

  1044    encoded output MUST be wrapped on 76-character lines.

  1045 

  1046 

  1047 

  1048 

  1049 

  1050 

  1051 

  1052 

  1053 

  1054 

  1055 

  1056 

  1057 

  1058 

  1059 

  1060 

  1061 

  1062 

  1063 

  1064 

  1065 

  1066 

  1067 

  1068 

  1069 Kennedy                      Informational                      [Page 3]

  1070 

  1071 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

  1072 

  1073 

  1074 2.2. Example Datagram

  1075 

  1076    The following is an example IPoXML datagram with an empty payload:

  1077 

  1078    <?xml version="1.0" encoding="UTF-8"?>

  1079    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">

  1080    <ip>

  1081    <header length="474">

  1082    <version value="4"/>

  1083    <tos precedence="Routine" delay="Normal" throughput="Normal"

  1084         relibility="Normal" reserved="0"/>

  1085    <total.length value="461"/>

  1086    <id value="1"/>

  1087    <flags reserved="0" df="dont" mf="last"/>

  1088    <offset value="0"/>

  1089    <ttl value="255"/>

  1090    <protocol value="6"/>

  1091    <checksum value="8707"/>

  1092    <source address="10.0.0.22"/>

  1093    <destination address="10.0.0.1"/>

  1094    <options>

  1095    <end copied="0" class="0" number="0"/>

  1096    </options>

  1097    <padding pad="0"/>

  1098    </header>

  1099    <payload>

  1100    </payload>

  1101    </ip>

  1102 

  1103 3.   TCPoXML

  1104 

  1105    This protocol MUST be implemented to be compliant with this RFC.  The

  1106    DTD for this document type can be found in section 7.2.

  1107 

  1108 3.1. TCP Description

  1109 

  1110    A number of items have changed from the original TCP specification.

  1111    Bit-masks, where present have been converted into human-readable

  1112    values.  Length and checksum and port values are present as decimal

  1113    integers.

  1114 

  1115    To calculate the length and checksum fields of the TCP element, a

  1116    canonicalized form of the element MUST be used as in section 2.1.

  1117 

  1118    An iterative method SHOULD be used to calculate checksums as in

  1119    section 2.1.

  1120 

  1121    The payload element MUST be encoded as in section 2.1.

  1122 

  1123 

  1124 

  1125 Kennedy                      Informational                      [Page 4]

  1126 

  1127 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002

  1128 

  1129 

  1130    The TCP offset element was expanded to a maximum of 255 from 16 to

  1131    allow for the increased size of the header in XML.

  1132 

  1133    TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header

  1134    as well as the <!DOCTYPE> declaration.

  1135