rfc3093.txt

RFC 的详细文档！

   IP_value_opt - This ASCII string represents the encoding type for the
      following  fields where a mandatory encoding type is not
      specified.  The legitimate values are the same as for
      TCP_value_opt.

   IP_Ver - The IP Version number, encoded as an UTF-8 string.  The
      legitimate values for the string are "four", "five", and "six."
      The encapsulation of the fields in the IP header are defined in
      this section if the value is "four", and in section 3.3 if the
      value is "six".  Encapsulations for headers with IP_Ver value of
      "five" will be developed if the right orders are received.
      Encapsulations for headers with the IP_Ver value of "eight" are
      empty.  Implementations MUST be able to support arbitrary native
      languages for these strings.

   IP4_Hlen - The IP Internet Header Length field, it is encoded in the
      same way as TCP_DODO.

   IP4_Type_of_Service (this name is case sensitive) - This is an
      obsolete name for a field in the IPv4 header, which has been
      replaced with IP_$$ and IP_CU.





Gaynor & Bradner             Informational                      [Page 6]

RFC 3093             Firewall Enhancement Protocol          1 April 2001


   IP_$$ - The 6-bit Differentiated Services field, encapsulated as an
      UTF-8 string representing the name of the DS codepoint in the
      field.

   IP_CU - The 2-bit field that was the two low-order bits of the TOS
      field.  Since  this field is currently being used for experiments
      it has to be coded in the most general way possible, thus it is
      encoded as two ASCII strings of the form "bit0=X" and "bit1=X,"
      where "X" is "on" or "off."  Note that bit 0 is the MSB.

   IP4_Total - The 16-bit Total Length field, encoded as an ASCII string
      representing the value of the field.

   IP4_SSN - The IP Identification field, encoded as an ASCII string
      representing the value of the field.

   IP4_Flags - The IP Flags, encoded as the set of 3 comma separated
      ASCII strings:  [{"Must Be Zero"}, {"May Fragment"|"Don't
      Fragment"}, {"Last Fragment"|"More Fragments"}]

   IP4_Frager - The 13-bit Fragment Offset field, encoded as an ASCII
      string  representing the value of the field.

   IP4_TTL - The 8-bit Time-to-Live field, encoded as an UTF-8 string of
      the form "X hops to destruction."  Where "X" is the decimal value
      -1 of the field.  Implementations MUST be able to support
      arbitrary languages for this string.

   IP4_Proto - The 8-bit Protocol field, encoded as an UTF-8 string
      representing  the common name for the protocol whose header
      follows the IP header.

   IP4_Checkit - The 16-bit Checksum field, encoded in the same way as
      TCP_Checkit.

   IP4_Apparent_Source - The 32-bit Source Address field.  For user
      friendliness this is encoded as an UTF-8 string representing the
      domain name of the apparent sender of the packet.  An alternate
      form, to be used when the domain name itself might be blocked by a
      firewall programmed to protect the innocence of the corporate
      users, is an ASCII string representing the dotted quad form of the
      IPv4 address.

   IP4_Dest_Addr - The 32-bit Destination Address field, encoded in the
      same way as is IP4_Apparent_Source.






Gaynor & Bradner             Informational                      [Page 7]

RFC 3093             Firewall Enhancement Protocol          1 April 2001


   IP4_Opp_Lst - A comma-separated list of all IPv4 options that are
      present.  Each option is encoded as an ASCII string representing
      the name of the option followed by option-specific information
      enclosed in square brackets.  Representative options and their
      encoding follow, other IP options follow the same form:

      End of Options option: ["End of Options"]

      Loose Source Routing option: ["Loose Source Routing", length,
         pointer, IP4_addr1, IP4_addr2, ...], where length and pointer
         are ASCII strings representing the value of those fields.

3.3 IPv6 Header Encapsulation:

   This proposal defines the following new HTTP headers for representing
   IPv6 header information:

   These optional headers encode the IPv6 [5] header for better
   readability.  These fields are encoded in a manner similar to the
   above TCP header fields.

   Since the base IP packet is already present in an HTTP header the
   following headers are optional.  None, some or all of them may be
   used depending on the whim of the programmer.  At this time only the
   base IPv6 header is supported.  If there is sufficient interest,
   support will be developed for IPv6 extension headers.

   IP_$$ - the 6-bit Differentiated Services field - see above

   IP_CU - the 2-bit unused field - see above

   IP6_Go_with_the_Flow - The 20-bit Flow Label field.  Since this field
      is not  currently in use it should be encoded as the UTF-8 string
      "do not care".

   IP6_PayLd - The 16-bit Payload Length field, encoded as an ASCII
      string representing the value of the field.  The use of FEP with
      IPv6 jumbograms is not recommended.

   IP6_NxtHdr - The 8-bit Next Header field, encoded in the same way as
      IP4_Proto.

   IP6_Hopping - The 8-bit Hop Limit field, encoded in the same way as
      IP4_TTL.







Gaynor & Bradner             Informational                      [Page 8]

RFC 3093             Firewall Enhancement Protocol          1 April 2001


   IP6_Apparent_Source - The 128-bit Source Address field.  For user
      friendliness, this is encoded as an UTF-8 string representing the
      domain name of the apparent sender of the packet.  An alternate
      form, to be used when the domain name itself might be blocked by a
      Firewall programmed to protect the innocence of the corporate
      users, is an ASCII string representing any one of the legitimate
      forms of representing an IPv6 address.

   IP6_Dest_Addr - The 128-bit Destination Address field, encoded the
      same way as IP6_Apparent_Source.

3.4 TCP Header Compression

   Compressing TCP headers in the face of a protocol such as this one
   that explodes the size of packets is silly, so we ignore it.

4.0 Security Considerations

   Since this protocol deals with Firewalls there are no real security
   considerations.

5.0 Acknowledgements

   We wish to thank the many Firewall vendors who have supported our
   work to re-enable the innovation that made the Internet great,
   without giving up the cellophane fig leaf of security that a Firewall
   provides.

6.0 Authors' Addresses

   Mark Gaynor
   Harvard University
   Cambridge MA 02138

   EMail [e-mail]


   Scott Bradner
   Harvard University
   Cambridge MA 02138

   Phone [phone]
   EMail [e-mail]








Gaynor & Bradner             Informational                      [Page 9]

RFC 3093             Firewall Enhancement Protocol          1 April 2001


References

   [1] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.

   [2] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in
       System Design".  2nd International Conference on Distributed
       Systems, Paris, France, April 1981.

   [3] Eastlake, D., "IP over MIME", Work in Progress.

   [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
       September 1981.

   [5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

   [6] Clark, D. and M. Blumenthal, "Rethinking the Design of the
       Internet: The end-to-end argument vs. the brave new world". 2000.


































Gaynor & Bradner             Informational                     [Page 10]

RFC 3093             Firewall Enhancement Protocol          1 April 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.



















Gaynor & Bradner             Informational                     [Page 11]