[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

  INTERNET-DRAFT                                    Soohong Daniel Park
  Expires: September 2003                                    Hakgoo Lee
                                                    SAMSUNG Electronics
                                                             March 2003
  
  
  
  
       The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header
               <draft-park-pmtu-ipv6-option-header-00.txt>
  
  
  
  
  Status of This Memo
  
  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC2026 [RFC2026].
  
  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as Internet-
  Drafts.
  
  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time.  It is inappropriate to use Internet-Drafts
  as reference material or to cite them other than as "work in
  progress."
  
  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt
  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.
  
  
  
  Abstract
  
  This document presents a new method for the PMTU discovery for IPv6.
  To discover the PMTU of a path, a source node measures its actual PMTU
  using the newly defined Hop-by-Hop Option header, whereas a source
  node initially assumes that the PMTU of a path is the known MTU of
  the first hop in the path in the previous one [1981]. In order to
  measure the actual PMTU, the source node sends the IP packet with the
  newly defined Hop-by-Hop Option header to the destination node with
  the first data packet when node is beginning. This can eliminate the
  chance of occurrence of several iterations of the somewhat complex
  discovery cycle (sending a packet, receiving a Packet Too Big message,
  reducing a packet size). Most of all, since existing PMTU has a weak
  point for security and denial-of-service attacks, this document
  suggests a security function when PMTU is going on.
  
  All IPv6 nodes, including both hosts and routers, must implement newly
  Options as defined in this specification.
  
  Park,Lee                 Expires September 2003               [Page 1]


  INTERNET-DRAFT                                             March 2003
  
  Table of Contents
  
  Abstract
  1.    Introduction
  2.    Terminology
  3.    Proposed Method : Overview
  3.1   Request MAP Option Format
  3.2   Response MAP Option Format
  4.    Node Requirements for Discoverying PMTU
  4.1   Source Node and Destination Node
  4.2   Nodes on Routing Path
  4.3   Operation Procedure
  5.    Mode Requirements for Detecting PMTU
  5.1   Source Node and Destination Node
  5.2   Nodes on Routing Path
  5.3   Operation Procedure
  6.    Comparison with [1981]
  7.    Security Considerations
  8.    Normative Reference
  9.    Informative References
  10.   Acknowledgements
  11.   Authors' Addresses
  12.   Intellectual Property
  13.   Copyright
  
  
  
  1.  Introduction
  
  The discovery of the Path MTU (PMTU) is described in [1981]. The basic
  idea of [1981] is that a source node initially assumes that the a
  path's PMTU is the known MTU of the first hop in the path. If any of
  the packets sent on that path are too large to be forwarded by some
  node along the path, that node will discard them and return ICMPv6
  Packet Too Big messages [2463]. Upon receipt of such a message, the
  source node reduces its assumed PMTU for the path based on the MTU of
  the constricting hop as reported in the Packet Too Big message. The
  PMTU Discovery process ends when packets arrive at the destination
  node.
  
  However, in [1981], there may be several iterations of the somewhat
  complex discovery cycle (sending a packet, receiving a Packet Too Big
  message, reducing a packet size), before the actual PMTU is obtained.
  In the worst case, the number of interactions becomes the number of
  hops in the path. This method might be somewhat inefficient.
  
  Therefore, a new method for the PMTU discovery is suggested in this
  document. In this new method, to discover the PMTU of a path, the
  source node measures its actual PMTU using the newly defined
  Hop-by-Hop Option header. To measure the actual PMTU, the source node
  sends the IP packet with the newly defined Hop-by-Hop Option header
  to the destination node with the first data packet which should be the
  its link MTU when node is beginning. After then, the measured PMTU is
  used to send the subsequent packets.
  
  
  
  Park,Lee                 Expires September 2003               [Page 2]


  INTERNET-DRAFT                                             March 2003
  
  Now, another problem can be considered in PMTU Discovery [1981]. Due
  to changes in the routing topology, the PMTU of a path may change over
  time. In [1981], to detect increases of the PMTU of a path, the source
  node periodically increases its assumed PMTU although this is done
  infrequently (10 minutes in general). However, in this method, the
  assumed PMTU is increased by the source node's link MTU
  unconditionally. This may also result in several iterations of the
  discovery cycle. This problem can be also resolved by the proposed
  method.
  
  Therefore, in both discovering PMTU and detecting PMTU's increases,
  the proposed method can eliminate the chance of occurrence of several
  iterations of the somewhat complex discovery cycle. Thus, the proposed
  method in this document can be helpful for the best-conditioned
  network environment because the actual PMTU is measured dynamically
  for changes in the routing topology.
  
  Finally, existing PMTU [1981] mechanism makes possible some denial-of-
  service attacks, most of all, both are based on a malicious party
  sending false Packet Too Big messages to a victim. Accordingly both
  weak points, it will result in suboptimal performance and availability
  of denial-of-service attacks. This document suggests the secure PMTU
  method. It is described in section 7.
  
  
  2.  Terminology
  
        o PMTU                  is the minimum link MTU of all the links
                                in a path between a source node and a
                                destination node.
  
        o MTU                   is stands for Maximum Transmission Unit.
                                i.e., maximum packet size in octets,
                                that can be conveyed in one piece over
                                a link.
  
        o Detection Timer       Nodes may send PMTU packet at infrequent
                                intervals in order to detect an increase.
                                The recommended setting for this timer
                                is same value as [1981]. (10 minutes)
  
        o Response Timer        If the source node does not receive the
                                packet with Response MAP Option until
                                the Response Timer expires, the source
                                node initially assumes that the PMTU
                                of a path is the MTU of the first hop
                                in the path as [1981].
  
        o MAP                   is stands for Measuring Actual PMTU. In
                                order to perform MAP, newly MAP Option
                                must be done.
  
        o Discoverying PMTU     When node is beginning, node should
                                perform PMTU to discovery its own value.
  
  
  
  Park,Lee                 Expires September 2003               [Page 3]


  INTERNET-DRAFT                                             March 2003
  
        o Detecting PMTU's Increase
                                Nodes may detect increases in PMTU.
  
  
        o Request MAP Option    is used to request MAP information to
                                destination. See section 3.1
  
        o Response MAP Option   is used to response MAP information to
                                source. See section 3.2
  
  
  3.  Proposed Method : Overview
  
  This section gives a brief overview of the new method for the
  discoverying and detecting PMTU mechanisms.
  
  A router on routing path examines only IP header, Hop-by-Hop Option
  header and routing header in extension header. Other extension headers
  and data are examined only by a source node and destination node.
  In the new method, Hop-by-Hop Option header is used to measure
  increases in a path's PMTU
  
  The Hop-by-Hop Option header and Option is defined as below.
  
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Next Header  |  Hdr Ext Len  |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  |                                                               |
  .                                                               .
  .                            Options                            .
  .                                                               .
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
                <Figure 1 Hop-by-Hop Option Header>
  
  
  Currently, Hop-by-Hop Option headers are Pad1, PadN, Jumbo Payload,
  and Router Alert Options.  This document defines a new Option. It is
  called 'Measuring Actual PMTU (MAP Option)'. Then, the IP packet
  including Hop-by-Hop Option header with MAP Option has the following
  format.
  
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Version| Traffic Class |            Flow Label                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Payload Length         |  Next Header  |   Hop Limit   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                        Source Address                         +
  |                                                               |
  +                                                               +
  
  
  
  Park,Lee                 Expires September 2003               [Page 4]


  INTERNET-DRAFT                                             March 2003
  
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                      Destination Address                      +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Next Header  |       0       |  Option Type  |  Opt Data Len |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Option Data(PMTU)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  
  Option Type          8-bit identifier of the type of Option.
  
  Opt Data Len         8-bit unsigned integer.  Length of the Option
                       Data field of this Option, in octets.
  
  Option Data(PMTU)    Measured PMTU value with 4 bytes
  
                 <Figure 2 IP Packet with MAP Option>
  
  
  The Option Type identifiers are internally encoded such that their
  highest-order two bits specify the action that must be taken when
  the router does not recognize the Option Type. The third highest
  order bit of the Option Type specifies whether or not the Option
  Data (PMTU) of that Option can change en-route to the packet's
  final destination. The other five bits are defined arbitrarily.
  The MAP Option has two Option Types. The one is Request MAP Option
  and the other is Response MAP Option, which will be shown in
  following subsections. If any of the routers en-route cannot
  recognize the Option Types, it skips over or discards the packet
  silently. It depends on operator policy.
  
        o The highest-order two bits of the Option type is 00
                If routers are not understand MAP Options, this packet
                must be skipped over this Option and continue processing
                the header. When this Option meets with possible router,
                this PMTU must be modified. When source node receives
                this response, it is not actual PMTU because all routers
                are not understand. If received MTU is larger than its
                own value, this MTU should be ignored.
                Note : In initiation case, node must use "00" value
                because of response error message
                (Packet Too Big message).
  
        o The highest-order two bits of the Option type is 01
                If routers are not understand MAP Options, this packet
                must be discarded, at this case, source node has its
                waiting time. When this time is expired without any
                response, this node should perform original PMTU as
                [1981].
  
  Park,Lee                 Expires September 2003               [Page 5]


  INTERNET-DRAFT                                             March 2003
  
  This document suggests that if specific link should be performed with
  small PMTU value, at this point, MAP Options should be applied.
  
  
  
  3.1  Request MAP Option Format
  
  The Request MAP Option format is defined to measure real PMTU as
  shown in Figure 3. The source node sends the IP packet with this
  Request MAP Option format to the destination node.
  
  
  
                                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  |0 x 1|1 0 0 0 0|0 0 0 0 0 1 0 0|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            P M T U                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  Highest-order two bits
        00 - Skip over this Option and continue processing the header
        01 - discard the packet
  
  The third-highest-order bit
        1  - Option Data may change en-route
  
  Option Type - 112 (temporary value)
  
  Option Length - 4
  
  PMTU - 4 Octets
  
                 <Figure 3 Request MAP Option Format>
  
  
  
  3.2  Response MAP Option Format
  
  The Response MAP Option format is defined to response measured
  real PMTU as shown in Figure 3. The destination node sends the IP
  packet with this Response MAP Option format to the source node.
  
  
                                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  |0 x 0|1 1 0 0 0|0 0 0 0 0 1 0 0|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            P M T U                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  Highest-order two bits
        00 - Skip over this Option and continue processing the header
        01 - discard the packet
  
  The third-highest-order bit
        0  - Option Data does not change en-route
  
  
  Park,Lee                 Expires September 2003               [Page 6]


  INTERNET-DRAFT                                             March 2003
  
  Option Type - 88 (temporary value)
  
  Option Length - 4
  
  PMTU - 4 Octets
  
                <Figure 4 Response MAP Option Format>
  
  
  3.3  Discoverying PMTU with MAP Options
  
  The source node sends IP packet with Request MAP Option to the
  destination node when node is beginning to communicate. Initial MTU
  value should be its link MTU of the source node. After node receives
  Response MAP Option with PMTU, the subsequent packets will be sent of
  course using obtained PMTU. If the first packet with the IPv6 minimum
  link MTU don't go through the next-hop, its node must not reduce its
  estimate of the PMTU below the IPv6 minimum link MTU. At this case,
  node may receive a Packet Too Big message reporting a next-hop MTU
  that is less than IPv6 minimum link MTU. Then, node must include a
  Fragment header in those packets. This packet should be composed of
  the following headers:
  
        IPv6 Header
        Hop-by-Hop Options with Request/Response MAP Option
        Fragment
        ...
  
  While the packet is passing through nodes en-route, the following
  action occurs.
  
  - Compare PMTU in Request MAP Option and Link MTU of next hop.
  - Store the smaller value between them on PMTU field of the packet.
  
  By doing the same action on routers en-route, PMTU field of the IP
  packet with Request MAP Option is updated to have minimum PMTU.
  This is the actual PMTU value. The destination node that receives
  the IP packet returns back this value to the source node using
  Response MAP Option. The source node that receives the actual PMTU
  value determines the transmission length of a packet. However, if
  all routers don't recognize MAP Options, responsed MTU is not actual
  PMTU.
  
  
  3.4  Detecting PMTU with MAP Options
  
  As described on Path MTU Discovery [1981], a source node sends IP
  packet with Request MAP Option to a destination node before the
  Detection Timer expires so that it wants to increase PMTU value.
  Default MTU value is link MTU of the source node. This packet
  should be composed of the following headers:
  
        IPv6 Header
        Hop-by-Hop Options with Request/Response MAP Option
  
  
  
  Park,Lee                 Expires September 2003               [Page 7]


  INTERNET-DRAFT                                             March 2003
  
  While the packet is passing through nodes en-route, the actions are
  the same as section 3.3
  
  By doing the same action on routers en-route, PMTU field of the IP
  packet with Response MAP Option is updated to have minimum PMTU.
  This is the optimal PMTU value. The destination node that receives
  the IP packet returns back this value to the source node using
  Response MAP Option. The source node that receives the optimal PMTU
  value determines the transmission length of a packet. This method can
  reduce the number of ICMP-Packet Too  Big Error message, otherwise
  happens more frequently. This also reduce waste of network resource.
  
  
  4.  Node Requirements for Discoverying PMTU
  
  4.1  Source Node and Destination Node
  
  When the IPv6 source node has a large amount of packets to send to the
  destination node, the source node sends the IP packet with Request MAP
  Option to the destination when node is beginning. The PMTU field of
  Request MAP Option of the packet initialized by the value of its link
  MTU of the source node. If router does not understand the MAP Options,
  the packet is skipped over this Option and continue processing the
  header (See section 3.). When node receives the Packet Too Big message
  this node should be performed existing PMTU as [1981].
  
  Whenever the destination node receives the IP packet with Request MAP
  Option, it must response the IP packet with Response MAP Option
  immediately. By the Option Type, this packet cannot be modified by
  routers on routing path.
  
  
  4.2  Nodes on Routing Path
  
  Nodes on a routing path are routers. When the IP packet with Request
  MAP Option arrives on these routers, they compare the PMTU in Request
  MAP Option and link MTU of the next hop. They select a smaller value
  between them and forward the packet with a PMTU value. After doing
  the same procedure, the final destination node comes to know minimum
  PMTU. If the IP packet with Response MAP Option arrives on theses
  routers, they forward the packet without any modification. If routers
  can not recognize two MAP Options, it skips over this Option and
  continue processing the header since the first two bits of the MAP
  Option is 00. (See section 3.).
  
  
  4.3  Operation Procedure
  
  When the IPv6 source node sends to the destination node, the source
  node sends the IP packet with Request MAP Option and its link MTU of
  the source node to a destination. In this case, the Option Type in
  Request MAP Option is 112 (temporary  value). While the packet is
  
  
  
  
  
  Park,Lee                 Expires September 2003               [Page 8]


  INTERNET-DRAFT                                             March 2003
  
  en-route, intermediate routers compare the PMTU in Request MAP Option
  and link MTU of the next hop. They select a smaller value between
  them, store the value to PMTU field of Request MAP Option and forward
  the packet with the updated PMTU. PMTU of the packet arrived at the
  destination node becomes minimum PMTU. The destination node sends the
  IP packet Response MAP Option to inform the source node. In this case,
  the Option Type in Request MAP Option is 88 (temporary value). After
  then, the source node sends packets using new PMTU. If routers
  implements only previous PMTU Discovery [1981] on routing path, in
  this case the router can skip over this Option and continue processing
  the header. If node receives the Packet Too Big message, the source
  node should be performed existing PMTU as [1981]. If node receives
  Response MAP Option, the source node must compare with its own MTU
  value. The source node selects a smaller value between them and store.
  
  Therefore, in discovering PMTU, the proposed method can eliminate
  the chance of occurrence of several iterations of the discovery
  cycle.
  
  
  5.  Node Requirements for Detecting PMTU
  
  5.1  Source Node and Destination Node
  
  A source node does not change the PMTU value for some amount of time
  after it comes to know PMTU based on PMTU Discovery [1981]. When the
  source node wants to increase PMTU by the Detection Timer, it sends
  the IP packet with MAP Options to a destination. The PMTU field of
  MAP Options of the packet contains the value of link MTU of the
  source node and the data. Whenever a destination node receives the
  IP packet with Request MAP Option, it must response the IP packet
  with Response MAP Option immediately. By the Option Type, this packet
  cannot be modified by routers on routing path. Also, it can use both
  type "00" and "01". It depends on operator policy. In order to use
  type "01", source node must have its timer, Response Timer.
  
  
  5.2  Nodes on Routing Path
  
  This processing is same as section 4.2
  
  
  5.3  Operation Procedure
  
  When the source node wants to increase PMTU by the Detection Timer,
  it sends the IP packet with Request MAP Option to a destination.
  In this case, the Option Type in Request MAP Option is 112 (temporary
  value). While the packet is en-route, intermediate routers compare the
  PMTU in MAP Option and link MTU of the next hop. They select a smaller
  value between them, store the value to PMTU field of MAP Option and
  forward the packet with the updated PMTU. PMTU of the packet arrived
  at the destination node becomes  minimum PMTU. The destination node
  sends the IP packet Response MAP Option to inform the source node. In
  
  
  
  
  Park,Lee                 Expires September 2003               [Page 9]


  INTERNET-DRAFT                                             March 2003
  
  this case, the Option Type in Response MAP Option is 88 (temporary
  value). After then, the source node sends packets using new PMTU.if
  routers implements only previous PMTU Discovery [1981] on routing
  path, in this case the router can silently discard the packet
  without response error message by the highest-order two bits, 01,
  in Option Type field or skip over this Option and continue processing
  the header with MAP Options by the highest-order two bits, 00, in
  Option Type field. If the source node does not receive the IP packet
  with Response MAP Option until the Response Timer expires, the source
  node initially assumes that the PMTU of a path is the MTU of the first
  hop in the path as [1981].
  
  
  6.  Comparison with [1981]
  
  This section should be discussed more detail.
  
        o  In order to perform PMTU, [1981] uses ICMPv6, but MAP uses
           only basic IPv6 protocol and extension header with newly
           Option. We assure that it should be implemented very easy in
           host and router as well.
  
        o  In the aspect of implementation, all IPv6 nodes, including
           both hosts and routers, must implement newly Options as
           defined in this specification.
  
        o  As described in [1981], MAP should consider all
           implementation issues.
  
  
  7.  Security Considerations
  
  As we knew, existing PMTU [1981] mechanism makes possible two denial
  -of-service attacks, most of all, both are based on a malicious
  party sending false Packet Too Big messages to a victim.
  Accordingly both weak points, it will result in suboptimal
  performance and availability of denial-of-service attacks.
  
  MAP mechanism is not likely to do denial-of-service attacks. However
  when malicious node sends false MAP response with its correct type,
  there are still simpler denial-of-service attacks available.
  
  This document considers the protection method from various attacks.
  In order to avoid spoofing or attacking with incorrect response,
  MAP mechanisms can use the 64-bit Nonce field. Its value in a MAP
  Option is always copied from the corresponding Request MAP by the
  responder. This method is an Optional, therefore the usage of this
  method depends on operator. However this document recommends this
  method is implemented with MAP Options for the secure PMTU.
  
  
  
  
  
  
  
  
  Park,Lee                 Expires September 2003               [Page 10]


  INTERNET-DRAFT                                             March 2003
  +...                                                            +
  |                    Original IPv6 Header                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Next Header  |       1       |MAP Option Typ |0 0 0 0 1 1 0 0|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                            Nonce                              |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Option Data(PMTU)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  
                <Figure 5 Secure PMTU with MAP Option>
  
  The Nonce should be a random or good pseudo-random value to foil
  spoofed replied. An implementation which allows multiple independent
  processes to send MAP Option may use the Nonce value to deliver MAP
  Option to the correct process. Nonetheless, such processes must
  check the received Nonce and ignore extraneous response.
  
  
  8.  Normative Reference
  
  [1981]        J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for
                IP version 6", RFC 1981, August 1996.
  
  9.  Informative References
  
  [2460]        S. Deering, R. Hinden, "Internet Protocol, Version 6
                (IPv6)", RFC 2460, December 1998.
  
  [2463]        A. conta, S. Deering, "Internet Control message Protocol
                (ICMP) for the Internet Protocol Version 6 (IPv6)
                Specification", RFC 2463, December 1998.
  
  
  9.  Acknowledgements
  
  The authors would like to thank Robert Hinden for his careful reviews
  of this draft.
  
  
  10.  Authors' Addresses
  
  Soohong Daniel Park
  SAMSUNG Electronics
  Digital Media R&D Center
  Tel : +82-31-200-3728
  Fax : +82-31-200-3147
  E-mail : soohong.park@samsung.com
  
  
  
  
  
  
  
  Park,Lee                 Expires September 2003               [Page 11]


  INTERNET-DRAFT                                             March 2003
  
  Hakgoo Lee
  SAMSUNG Electronics
  Digital Media R&D Center
  Tel : +82-31-200-9309
  Fax : +82-31-200-3147
  E-mail : solited@samsung.co.kr
  
  
  11.  Intellectual Property
  
  The following notice is copied from RFC 2026 [Bradner, 1996],
  Section 10.4, and describes the position of the IETF concerning
  intellectual property claims made against this document.
  
  The IETF takes no position regarding the validity or scope of any
  intellectual property or other rights that might be claimed to
  pertain to the implementation or use other technology described in
  this document or the extent to which any license under such rights
  might or might not be available; neither does it represent that it
  has made any effort to identify any such rights.  Information on the
  IETF's procedures with respect to rights in standards-track and
  standards-related documentation can be found in BCP-11.  Copies of
  claims of rights made available for publication and any assurances
  of licenses to be made available, or the result of an attempt made
  to obtain a general license or permission for the use of such
  proprietary rights by implementers or users of this specification
  can be obtained from the IETF Secretariat.
  
  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights which may cover technology that may be required to practice
  this standard.  Please address the information to the IETF Executive
  Director.
  
  12.  Copyright
  
  The following copyright notice is copied from RFC 2026 [Bradner,
  1996], Section 10.4, and describes the applicable copyright for this
  document.
  
  Copyright (C) The Internet Society July 12, 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.
  
  
  Park,Lee                 Expires September 2003               [Page 12]


  INTERNET-DRAFT                                             March 2003
  
  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assignees.
  
  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.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Park,Lee                 Expires September 2003               [Page 13]
  

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/