doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc4023.txt b/doc/rfc/rfc4023.txt
new file mode 100644
index 0000000..a0341a6
--- /dev/null
+++ b/doc/rfc/rfc4023.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                         T. Worster
+Request for Comments: 4023                                Motorola, Inc.
+Category: Standards Track                                     Y. Rekhter
+                                                  Juniper Networks, Inc.
+                                                           E. Rosen, Ed.
+                                                     Cisco Systems, Inc.
+                                                              March 2005
+
+
+    Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   Various applications of MPLS make use of label stacks with multiple
+   entries.  In some cases, it is possible to replace the top label of
+   the stack with an IP-based encapsulation, thereby enabling the
+   application to run over networks that do not have MPLS enabled in
+   their core routers.  This document specifies two IP-based
+   encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing
+   Encapsulation).  Each of these is applicable in some circumstances.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worster, et al.             Standards Track                     [Page 1]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+Table of Contents
+
+   1.  Motivation  ..................................................  2
+   2.  Specification of Requirements  ...............................  3
+   3.  Encapsulation in IP  .........................................  3
+   4.  Encapsulation in GRE  ........................................  4
+   5.  Common Procedures  ...........................................  5
+       5.1.  Preventing Fragmentation and Reassembly  ...............  5
+       5.2.  TTL or Hop Limit  ......................................  6
+       5.3.  Differentiated Services  ...............................  7
+   6.  Applicability  ...............................................  7
+   7.  IANA Considerations  .........................................  8
+   8.  Security Considerations  .....................................  8
+       8.1.  Securing the Tunnel with IPsec .........................  8
+       8.2.  In the Absence of IPsec  ............................... 10
+   9.  Acknowledgements ............................................. 11
+   10. Normative References  ........................................ 11
+   11. Informative References  ...................................... 12
+   Authors' Addresses ............................................... 13
+   Full Copyright Statement ......................................... 14
+
+1.  Motivation
+
+   In many applications of MPLS, packets traversing an MPLS backbone
+   carry label stacks with more than one label.  As described in section
+   3.15 of [RFC3031], each label represents a Label Switched Path (LSP).
+   For each LSP, there is a Label Switching Router (LSR) that is the
+   "LSP Ingress", and an LSR that is the "LSP Egress".  If LSRs A and B
+   are the Ingress and Egress, respectively, of the LSP corresponding to
+   a packet's top label, then A and B are adjacent LSRs on the LSP
+   corresponding to the packet's second label (i.e., the label
+   immediately beneath the top label).
+
+   The purpose (or one of the purposes) of the top label is to get the
+   packet delivered from A to B, so that B can further process the
+   packet based on the second label.  In this sense, the top label
+   serves as an encapsulation header for the rest of the packet.  In
+   some cases, other sorts of encapsulation headers can replace the top
+   label without loss of functionality.  For example, an IP header or a
+   Generic Routing Encapsulation (GRE) header could replace the top
+   label.  As the encapsulated packet would still be an MPLS packet, the
+   result is an MPLS-in-IP or MPLS-in-GRE encapsulation.
+
+   With these encapsulations, it is possible for two LSRs that are
+   adjacent on an LSP to be separated by an IP network, even if that IP
+   network does not provide MPLS.
+
+
+
+
+
+Worster, et al.             Standards Track                     [Page 2]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+   To use either of these encapsulations, the encapsulating LSR must
+   know
+
+      -  the IP address of the decapsulating LSR, and
+
+      -  that the decapsulating LSR actually supports the particular
+         encapsulation.
+
+   This knowledge may be conveyed to the encapsulating LSR by manual
+   configuration, or by means of some discovery protocol.  In
+   particular, if the tunnel is being used to support a particular
+   application and that application has a setup or discovery protocol,
+   then the application's protocol may convey this knowledge.  The means
+   of conveying this knowledge is outside the scope of the this
+   document.
+
+2.  Specification of Requirements
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in [RFC2119].
+
+3.  Encapsulation in IP
+
+   MPLS-in-IP messages have the following format:
+
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+             |                                     |
+             |             IP Header               |
+             |                                     |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+             |                                     |
+             |          MPLS Label Stack           |
+             |                                     |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+             |                                     |
+             |            Message Body             |
+             |                                     |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         IP Header
+             This field contains an IPv4 or an IPv6 datagram header
+             as defined in [RFC791] or [RFC2460], respectively.  The
+             source and destination addresses are set to addresses
+             of the encapsulating and decapsulating LSRs, respectively.
+
+
+
+
+
+
+Worster, et al.             Standards Track                     [Page 3]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+         MPLS Label Stack
+             This field contains an MPLS Label Stack as defined in
+             [RFC3032].
+
+         Message Body
+             This field contains one MPLS message body.
+
+   The IPv4 Protocol Number field or the IPv6 Next Header field is set
+   to 137, indicating an MPLS unicast packet.  (The use of the MPLS-in-
+   IP encapsulation for MPLS multicast packets is not supported by this
+   specification.)
+
+   Following the IP header is an MPLS packet, as specified in [RFC3032].
+   This encapsulation causes MPLS packets to be sent through "IP
+   tunnels".  When the tunnel's receive endpoint receives a packet, it
+   decapsulates the MPLS packet by removing the IP header.  The packet
+   is then processed as a received MPLS packet whose "incoming label"
+   [RFC3031] is the topmost label of the decapsulated packet.
+
+4.  Encapsulation in GRE
+
+   The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE
+   [RFC2784].  The packet then consists of an IP header (either IPv4 or
+   IPv6), followed by a GRE header, followed by an MPLS label stack as
+   specified in [RFC3032].  The protocol type field in the GRE header
+   MUST be set to the Ethertype value for MPLS Unicast (0x8847) or
+   Multicast (0x8848).
+
+   This encapsulation causes MPLS packets to be sent through "GRE
+   tunnels".  When the tunnel's receive endpoint receives a packet, it
+   decapsulates the MPLS packet by removing the IP and the GRE headers.
+   The packet is then processed as a received MPLS packet whose
+   "incoming label" [RFC3031] is the topmost label of the decapsulated
+   packet.
+
+   [RFC2784] specifies an optional GRE checksum, and [RFC2890] specifies
+   optional GRE key and sequence number fields.  These optional fields
+   are not very useful for the MPLS-in-GRE encapsulation.  The sequence
+   number and checksum fields are not needed, as there are no
+   corresponding fields in the native MPLS packets being tunneled.  The
+   GRE key field is not needed for demultiplexing, as the top MPLS label
+   of the encapsulated packet is used for that purpose.  The GRE key
+   field is sometimes considered a security feature, functioning as a
+   32-bit cleartext password, but this is an extremely weak form of
+   security.  In order (a) to facilitate high-speed implementations of
+   the encapsulation/decapsulation procedures and (b) to ensure
+   interoperability, we require that all implementations be able to
+   operate correctly without these optional fields.
+
+
+
+Worster, et al.             Standards Track                     [Page 4]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+   More precisely, an implementation of an MPLS-in-GRE decapsulator MUST
+   be able to process packets correctly without these optional fields.
+   It MAY be able to process packets correctly with these optional
+   fields.
+
+   An implementation of an MPLS-in-GRE encapsulator MUST be able to
+   generate packets without these optional fields.  It MAY have the
+   capability to generate packets with these fields, but the default
+   state MUST be that packets are generated without these fields.  The
+   encapsulator MUST NOT include any of these optional fields unless it
+   is known that the decapsulator can process them correctly.  Methods
+   for conveying this knowledge are outside the scope of this
+   specification.
+
+5.  Common Procedures
+
+   Certain procedures are common to both the MPLS-in-IP and the MPLS-
+   in-GRE encapsulations.  In the following, the encapsulator, whose
+   address appears in the IP source address field of the encapsulating
+   IP header, is known as the "tunnel head".  The decapsulator, whose
+   address appears in the IP destination address field of the
+   decapsulating IP header, is known as the "tunnel tail".
+
+   If IPv6 is being used (for either MPLS-in-IPv6 or MPLS-in-GRE-in-
+   IPv6), the procedures of [RFC2473] are generally applicable.
+
+5.1.  Preventing Fragmentation and Reassembly
+
+   If an MPLS-in-IP or MPLS-in-GRE packet were fragmented (due to
+   "ordinary" IP fragmentation), the tunnel tail would have to
+   reassemble it before the contained MPLS packet could be decapsulated.
+   When the tunnel tail is a router, this is likely to be undesirable;
+   the tunnel tail may not have the ability or the resources to perform
+   reassembly at the necessary level of performance.
+
+   Whether fragmentation of the tunneled packets is allowed MUST be
+   configurable at the tunnel head.  The default value MUST be that
+   packets are not fragmented.  The default value would only be changed
+   if it were known that the tunnel tail could perform the reassembly
+   function adequately.
+
+   THE PROCEDURES SPECIFIED IN THE REMAINDER OF THIS SECTION ONLY APPLY
+   IF PACKETS ARE NOT TO BE FRAGMENTED.
+
+   Obviously, if packets are not to be fragmented, the tunnel head MUST
+   NOT fragment a packet before encapsulating it.
+
+
+
+
+
+Worster, et al.             Standards Track                     [Page 5]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+   If IPv4 is used, then the tunnel MUST set the DF bit.  This prevents
+   intermediate nodes in the tunnel from performing fragmentation.  (If
+   IPv6 is used, intermediate nodes do not perform fragmentation in any
+   event.)
+
+   The tunnel head SHOULD perform Path MTU Discovery ([RFC1191] for
+   IPv4, or [RFC1981] for IPv6).
+
+   The tunnel head MUST maintain a "Tunnel MTU" for each tunnel; this is
+   the minimum of (a) an administratively configured value, and, if
+   known, (b) the discovered Path MTU value minus the encapsulation
+   overhead.
+
+   If the tunnel head receives, for encapsulation, an MPLS packet whose
+   size exceeds the Tunnel MTU, that packet MUST be discarded.  However,
+   silently dropping such packets may cause significant operational
+   problems; the originator of the packets will notice that his data is
+   not getting through, but he may not realize that large packets are
+   causing packet loss.  He may therefore continue sending packets that
+   are discarded.  Path MTU discovery can help (if the tunnel head sends
+   back ICMP errors), but frequently there is insufficient information
+   available at the tunnel head to identify the originating sender
+   properly.  To minimize problems, it is advised that MTUs be
+   engineered to be large enough in practice to avoid fragmentation.
+
+   In some cases, the tunnel head receives, for encapsulation, an IP
+   packet, which it first encapsulates in MPLS and then encapsulates in
+   MPLS-in-IP or MPLS-in-GRE.  If the source of the IP packet is
+   reachable from the tunnel head, and if the result of encapsulating
+   the packet in MPLS would be a packet whose size exceeds the Tunnel
+   MTU, then the value that the tunnel head SHOULD use for fragmentation
+   and PMTU discovery outside the tunnel is the Tunnel MTU value minus
+   the size of the MPLS encapsulation.  (That is, the Tunnel MTU value
+   minus the size of the MPLS encapsulation is the MTU that is to be
+   reported in ICMP messages.)  The packet will have to be discarded,
+   but the tunnel head should send the IP source of the discarded packet
+   the proper ICMP error message as specified in [RFC1191] or [RFC1981].
+
+5.2.  TTL or Hop Limit
+
+   The tunnel head MAY place the TTL from the MPLS label stack into the
+   TTL field of the encapsulating IPv4 header or the Hop Limit field of
+   the encapsulating IPv6 header.  The tunnel tail MAY place the TTL
+   from the encapsulating IPv4 header or the Hop Limit from the
+   encapsulating IPv6 header into the TTL field of the MPLS header, but
+   only if this does not increase the TTL value in the MPLS header.
+
+
+
+
+
+Worster, et al.             Standards Track                     [Page 6]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+   Whether such modifications are made, and the details of how they are
+   made, will depend on the configuration of the tunnel tail and the
+   tunnel head.
+
+5.3.  Differentiated Services
+
+   The procedures specified in this document enable an LSP to be sent
+   through an IP or GRE tunnel.  [RFC2983] details a number of
+   considerations and procedures that have to be applied to support the
+   Differentiated Services Architecture properly in the presence of IP-
+   in-IP tunnels.  These considerations and procedures also apply in the
+   presence of MPLS-in-IP or MPLS-in-GRE tunnels.
+
+   Accordingly, when a tunnel head is about to send an MPLS packet into
+   an MPLS-in-IP or MPLS-in-GRE tunnel, the setting of the DS field of
+   the encapsulating IPv4 or IPv6 header MAY be determined (at least
+   partially) by the "Behavior Aggregate" of the MPLS packet.
+   Procedures for determining the Behavior Aggregate of an MPLS packet
+   are specified in [RFC3270].
+
+   Similarly, at the tunnel tail, the DS field of the encapsulating IPv4
+   or IPv6 header MAY be used to determine the Behavior Aggregate of the
+   encapsulated MPLS packet. [RFC3270] specifies the relation between
+   the Behavior Aggregate and the subsequent disposition of the packet.
+
+6.  Applicability
+
+   The MPLS-in-IP encapsulation is the more efficient, and it would
+   generally be regarded as preferable, other things being equal.  There
+   are, however, some situations in which the MPLS-in-GRE encapsulation
+   may be used:
+
+      -  Two routers are "adjacent" over a GRE tunnel that exists for
+         some reason that is outside the scope of this document, and
+         those two routers have to send MPLS packets over that
+         adjacency.  As all packets sent over this adjacency must have a
+         GRE encapsulation, the MPLS-in-GRE encapsulation is more
+         efficient than the alternative, that would be an MPLS-in-IP
+         encapsulation which is then encapsulated in GRE.
+
+      -  Implementation considerations may dictate the use of MPLS-in-
+         GRE.  For example, some hardware device might only be able to
+         handle GRE encapsulations in its fastpath.
+
+
+
+
+
+
+
+
+Worster, et al.             Standards Track                     [Page 7]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+7.  IANA Considerations
+
+   The IANA has allocated IP Protocol Number 137 for MPLS-in-IP
+   encapsulation, as described in section 3.  No future IANA actions
+   will be required.  The MPLS-in-GRE encapsulation does not require any
+   IANA action.
+
+8.  Security Considerations
+
+   The main security problem faced when IP or GRE tunnels are used is
+   the possibility that the tunnel's receive endpoint will get a packet
+   that appears to be from the tunnel, but that was not actually put
+   into the tunnel by the tunnel's transmit endpoint.  (The specified
+   encapsulations do not by themselves enable the decapsulator to
+   authenticate the encapsulator.)  A second problem is the possibility
+   that the packet will be altered between the time it enters the tunnel
+   and the time it leaves. (The specified encapsulations do not by
+   themselves assure the decapsulator of the packet's integrity.)  A
+   third problem is the possibility that the packet's contents will be
+   seen while the packet is in transit through the tunnel.  (The
+   specification encapsulations do not ensure privacy.)  How significant
+   these issues are in practice depends on the security requirements of
+   the applications whose traffic is being sent through the tunnel.  For
+   example, lack of privacy for tunneled packets is not a significant
+   issue if the applications generating the packets do not require
+   privacy.
+
+   Because of the different potential security requirements, deployment
+   scenarios, and performance considerations of different applications
+   using the described encapsulation mechanism, this specification
+   defines IPsec support as OPTIONAL.  Basic implementation requirements
+   if IPsec is implemented are described in section 8.1.  If IPsec is
+   not implemented, additional mechanisms may have to be implemented and
+   deployed.  Those are discussed in section 8.2.
+
+8.1.  Securing the Tunnel with IPsec
+
+   All of these security issues can be avoided if the MPLS-in-IP or
+   MPLS-in-GRE tunnels are secured with IPsec.  Implementation
+   requirements defined in this section apply if IPsec is implemented.
+
+   When IPsec is used, the tunnel head and the tunnel tail should be
+   treated as the endpoints of a Security Association.  For this
+   purpose, a single IP address of the tunnel head will be used as the
+   source IP address, and a single IP address of the tunnel tail will be
+   used as the destination IP address.  The means by which each node
+   knows the proper address of the other is outside the scope of this
+   document.  If a control protocol is used to set up the tunnels (e.g.,
+
+
+
+Worster, et al.             Standards Track                     [Page 8]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+   to inform one tunnel endpoint of the IP address of the other), the
+   control protocol MUST have an authentication mechanism, and this MUST
+   be used when the tunnel is set up.  If the tunnel is set up
+   automatically as the result of, for example, information distributed
+   by BGP, then the use of BGP's MD5-based authentication mechanism is
+   satisfactory.
+
+   The MPLS-in-IP or MPLS-in-GRE encapsulated packets should be viewed
+   as originating at the tunnel head and as being destined for the
+   tunnel tail; IPsec transport mode SHOULD thus be used.
+
+   The IP header of the MPLS-in-IP packet becomes the outer IP header of
+   the resulting packet when the tunnel head uses IPsec transport mode
+   to secure the MPLS-in-IP packet.  This is followed by an IPsec
+   header, followed by the MPLS label stack.  The IPsec header has to
+   set the payload type to MPLS by using the IP protocol number
+   specified in section 3.  If IPsec transport mode is applied on a
+   MPLS-in-GRE packet, the GRE header follows the IPsec header.
+
+   At the tunnel tail, IPsec outbound processing recovers the contained
+   MPLS-in-IP/GRE packet.  The tunnel tail then strips off the
+   encapsulating IP/GRE header to recover the MPLS packet, which is then
+   forwarded according to its label stack.
+
+   Note that the tunnel tail and the tunnel head are LSP adjacencies,
+   which means that the topmost label of any packet sent through the
+   tunnel must be one that was distributed by the tunnel tail to the
+   tunnel head.  The tunnel tail MUST know precisely which labels it has
+   distributed to the tunnel heads of IPsec-secured tunnels.  Labels in
+   this set MUST NOT be distributed by the tunnel tail to any LSP
+   adjacencies other than those that are tunnel heads of IPsec-secured
+   tunnels.  If an MPLS packet is received without an IPsec
+   encapsulation, and if its topmost label is in this set, then the
+   packet MUST be discarded.
+
+   An IPsec-secured MPLS-in-IP or MPLS-in-GRE tunnel MUST provide
+   authentication and integrity.  (Note that the authentication and
+   integrity will apply to the entire MPLS packet, including the MPLS
+   label stack.)  Thus, the implementation MUST support ESP will null
+   encryption.  ESP with encryption MAY be supported if a source
+   requires confidentiality.  If ESP is used, the tunnel tail MUST check
+   that the source IP address of any packet received on a given SA is
+   the one expected.
+
+   Key distribution may be done either manually or automatically by
+   means of IKE [RFC2409].  Manual keying MUST be supported.  If
+   automatic keying is implemented, IKE in main mode with preshared keys
+
+
+
+
+Worster, et al.             Standards Track                     [Page 9]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+   MUST be supported.  A particular application may escalate this
+   requirement and request implementation of automatic keying.
+
+   Manual key distribution is much simpler, but also less scalable, than
+   automatic key distribution.  Therefore, which method of key
+   distribution is appropriate for a particular tunnel has to be
+   carefully considered by the administrator (or pair of administrators)
+   responsible for the tunnel endpoints.  If replay protection is
+   regarded as necessary for a particular tunnel, automatic key
+   distribution should be configured.
+
+   If the MPLS-in-IP encapsulation is being used, the selectors
+   associated with the SA would be the source and destination addresses
+   mentioned above, plus the IP protocol number specified in section 3.
+   If it is desired to secure multiple MPLS-in-IP tunnels between a
+   given pair of nodes separately, each tunnel must have unique pair of
+   IP addresses.
+
+   If the MPLS-in-GRE encapsulation is being used, the selectors
+   associated with the SA would be the source and destination addresses
+   mentioned above, and the IP protocol number representing GRE (47).
+   If it is desired to secure multiple MPLS-in-GRE tunnels between a
+   given pair of nodes separately, each tunnel must have unique pair of
+   IP addresses.
+
+8.2.  In the Absence of IPsec
+
+   If the tunnels are not secured with IPsec, then some other method
+   should be used to ensure that packets are decapsulated and forwarded
+   by the tunnel tail only if those packets were encapsulated by the
+   tunnel head.  If the tunnel lies entirely within a single
+   administrative domain, address filtering at the boundaries can be
+   used to ensure that no packet with the IP source address of a tunnel
+   endpoint or with the IP destination address of a tunnel endpoint can
+   enter the domain from outside.
+
+   However, when the tunnel head and the tunnel tail are not in the same
+   administrative domain, this may become difficult, and filtering based
+   on the destination address can even become impossible if the packets
+   must traverse the public Internet.
+
+   Sometimes only source address filtering (but not destination address
+   filtering) is done at the boundaries of an administrative domain.  If
+   this is the case, the filtering does not provide effective protection
+   at all unless the decapsulator of an MPLS-in-IP or MPLS-in-GRE
+   validates the IP source address of the packet.  This document does
+   not require that the decapsulator validate the IP source address of
+   the tunneled packets, but it should be understood that failure to do
+
+
+
+Worster, et al.             Standards Track                    [Page 10]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+   so presupposes that there is effective destination-based (or a
+   combination of source-based and destination-based) filtering at the
+   boundaries.
+
+9. Acknowledgements
+
+   This specification combines prior work on encapsulating MPLS in IP,
+   by Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew
+   G. Malis, and Rick Wilder, with prior work on encapsulating MPLS in
+   GRE, by Yakov Rekhter, Daniel Tappan, and Eric Rosen.  The current
+   authors wish to thank all these authors for their contribution.
+
+   Many people have made valuable comments and corrections, including
+   Rahul Aggarwal, Scott Bradner, Alex Conta, Mark Duffy, Francois Le
+   Feucheur, Allison Mankin, Thomas Narten, Pekka Savola, and Alex
+   Zinin.
+
+10.  Normative References
+
+   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+             1981.
+
+   [RFC792]  Postel, J., "Internet Control Message Protocol", STD 5, RFC
+             792, September 1981.
+
+   [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+             November 1990.
+
+   [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+             for IP version 6", RFC 1981, August 1996.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2463] Conta, A. and S. Deering, "Internet Control Message
+             Protocol (ICMPv6) for the Internet Protocol Version 6
+             (IPv6) Specification", RFC 2463, December 1998.
+
+   [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
+             Specification", RFC 2473, December 1998.
+
+   [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
+             "Generic Routing Encapsulation (GRE)", RFC 2784, March
+             2000.
+
+
+
+
+Worster, et al.             Standards Track                    [Page 11]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+   [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+             Label Switching Architecture", RFC 3031, January 2001.
+
+   [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+             Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+             Encoding", RFC 3032, January 2001.
+
+11.  Informative References
+
+   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+             Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+             2402, November 1998.
+
+   [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+             Payload (ESP)", RFC 2406, November 1998.
+
+   [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+             (IKE)", RFC 2409, November 1998.
+
+   [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
+             and W. Weiss, "An Architecture for Differentiated Service",
+             RFC 2475, December 1998.
+
+   [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
+             RFC 2890, September 2000.
+
+   [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983,
+             October 2000.
+
+   [RFC3260] Grossman, D., "New Terminology and Clarifications for
+             Diffserv", RFC 3260, April 2002.
+
+   [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
+             P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
+             Protocol Label Switching (MPLS) Support of Differentiated
+             Services", RFC 3270, May 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worster, et al.             Standards Track                    [Page 12]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+Authors' Addresses
+
+   Tom Worster
+   Motorola, Inc.
+   120 Turnpike Road
+   Southborough, MA 01772
+
+   EMail: tom.worster@motorola.com
+
+
+   Yakov Rekhter
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA 94089
+
+   EMail: yakov@juniper.net
+
+
+   Eric Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+
+   EMail: erosen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worster, et al.             Standards Track                    [Page 13]
+
+RFC 4023            Encapsulating MPLS in IP or GRE           March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Worster, et al.             Standards Track                    [Page 14]
+