draft-ietf-mpls-in-ip-or-gre-03.txt   draft-ietf-mpls-in-ip-or-gre-04.txt 
Network Working Group Tom Worster Network Working Group Tom Worster
Internet Draft Internet Draft
Expiration Date: March 2004 Expiration Date: July 2004
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
Eric C. Rosen, editor Eric C. Rosen, editor
Cisco Systems, Inc. Cisco Systems, Inc.
September 2003 January 2004
Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
draft-ietf-mpls-in-ip-or-gre-03.txt draft-ietf-mpls-in-ip-or-gre-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
In various applications of MPLS, label stacks with multiple entries Various applications of MPLS make use of label stacks with multiple
are used. In some cases, it is possible to replace the top label of entries. In some cases, it is possible to replace the top label of
the stack with an IP-based encapsulation, thereby enabling the the stack with an IP-based encapsulation, thereby enabling the
application to run over networks which do not have MPLS enabled in application to run over networks which do not have MPLS enabled in
their core routers. This draft specifies two IP-based their core routers. This draft specifies two IP-based
encapsulations, MPLS-in-IP, and MPLS-in-GRE (Generic Routing encapsulations, MPLS-in-IP, and MPLS-in-GRE (Generic Routing
Encapsulation). Each of these is applicable in some circumstances. Encapsulation). Each of these is applicable in some circumstances.
Table of Contents Table of Contents
1 Specification of Requirements .......................... 2 1 Specification of Requirements .......................... 2
2 Motivation ............................................. 2 2 Motivation ............................................. 2
3 Encapsulation in IP .................................... 3 3 Encapsulation in IP .................................... 3
4 Encapsulation in GRE ................................... 4 4 Encapsulation in GRE ................................... 5
5 Common Procedures ...................................... 4 5 Common Procedures ...................................... 6
5.1 Fragmentation, Reassembly, and MTU ..................... 5 5.1 Preventing Fragmentation and Reassembly ................ 6
5.2 TTL .................................................... 5 5.2 TTL or Hop Limit ....................................... 7
5.3 EXP and DSCP fields .................................... 6 5.3 Differentiated Services ................................ 7
6 Applicability .......................................... 6 6 Applicability .......................................... 8
7 IANA Considerations .................................... 6 7 IANA Considerations .................................... 8
8 Security Considerations ................................ 7 8 Security Considerations ................................ 9
9 Intellectual Property Notice ........................... 7 8.1 Securing the Tunnel Using IPsec ........................ 9
10 Copyright Notice ....................................... 8 8.2 In the Absence of IPsec ................................ 10
11 Acknowledgments ........................................ 8 9 Acknowledgments ........................................ 11
12 Normative References ................................... 8 10 Normative References ................................... 11
13 Informative References ................................. 9 11 Informative References ................................. 12
14 Author Information ..................................... 9 12 Author Information ..................................... 12
13 Intellectual Property Notice ........................... 13
14 Copyright Notice ....................................... 13
1. Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Motivation 2. Motivation
In many applications of MPLS, packets traversing an MPLS backbone In many applications of MPLS, packets traversing an MPLS backbone
carry label stacks with more than one label. As described in carry label stacks with more than one label. As described in section
[RFC3031], section 3.15, each label represents a Label Switched Path 3.15 of [RFC3031], each label represents a Label Switched Path (LSP).
(LSP). For each such LSP, there is a Label Switching Router (LSR) For each such LSP, there is a Label Switching Router (LSR) which is
which is the "LSP Ingress", and an LSR which is the "LSP Egress". If the "LSP Ingress", and an LSR which is the "LSP Egress". If LSRs A
LSRs A and B are the Ingress and Egress, respectively, of the LSP 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 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 on the LSP corresponding to the packet's second label (i.e., the
label immediately beneath the top label) label immediately beneath the top label)
The purpose (or one of the purposes) of the top label is to get the 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 delivered from A to B, so that B can further process the
packet based on the second label. In this sense, the top label packet based on the second label. In this sense, the top label
serves as an encapsulation header for the rest of the packet. In serves as an encapsulation header for the rest of the packet. In
some cases the top label can be replaced, without loss of some cases the top label can be replaced, without loss of
functionality, by other sorts of encapsulation headers. For example, functionality, by other sorts of encapsulation headers. For example,
the top label could be replaced by an IP header or a Generic Routing the top label could be replaced by an IP header or a Generic Routing
Encapsulation (GRE) header. As the encapsulated packet would still Encapsulation (GRE) header. As the encapsulated packet would still
be an MPLS packet, the result is an MPLS-in-IP or MPLS-in-GRE be an MPLS packet, the result is an MPLS-in-IP or MPLS-in-GRE
encapsulation. encapsulation.
skipping to change at page 3, line 17 skipping to change at page 3, line 19
functionality, by other sorts of encapsulation headers. For example, functionality, by other sorts of encapsulation headers. For example,
the top label could be replaced by an IP header or a Generic Routing the top label could be replaced by an IP header or a Generic Routing
Encapsulation (GRE) header. As the encapsulated packet would still Encapsulation (GRE) header. As the encapsulated packet would still
be an MPLS packet, the result is an MPLS-in-IP or MPLS-in-GRE be an MPLS packet, the result is an MPLS-in-IP or MPLS-in-GRE
encapsulation. encapsulation.
With these encapsulations, it is possible for two LSRs that are 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 adjacent on an LSP to be separated by an IP network, even if that IP
network does not provide MPLS. network does not provide MPLS.
In order 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 this knowledge may be conveyed by the application's protocol.
The means of conveying this knowledge is outside the scope of the
current document.
3. Encapsulation in IP 3. Encapsulation in IP
MPLS-in-IP messages have the following format: MPLS-in-IP messages have the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Header | | IP Header |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MPLS Label Stack | | MPLS Label Stack |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Header IP Header
This field contains an IPv4 or an IPv6 datagram header This field contains an IPv4 or an IPv6 datagram header
as defined in [RFC791] and [RFC2460] respectively. The as defined in [RFC791] or [RFC2460] respectively. The
source and destination addresses are set to addresses source and destination addresses are set to addresses
of the encapsulating and decapsulating LSRs respectively. of the encapsulating and decapsulating LSRs respectively.
MPLS Label Stack MPLS Label Stack
This field contains an MPLS Label Stack as defined in This field contains an MPLS Label Stack as defined in
[RFC3032]. [RFC3032].
Message Body Message Body
This field contains one MPLS message body. This field contains one MPLS message body.
The Protocol Number field in an IPv4 header and the Next Header field The IPv4 Protocol Number field or the IPv6 Next Header field is set
in an IPv6 are set as follows: to [value to be assigned by IANA], indicating an MPLS unicast packet.
(The use of the MPLS-in-IP encapsulation for MPLS multicast packets
- [value to be assigned by IANA] indicates an MPLS unicast packet, is not supported by this specification.)
- [value to be assigned by IANA] indicates an MPLS multicast
packet. (The use of the MPLS-in-IP encapsulation for MPLS
multicast packets is for further study.)
Following the IP header is an MPLS packet, as specified in [RFC3032]. Following the IP header is an MPLS packet, as specified in [RFC3032].
This encapsulation causes MPLS packets to be sent through "IP This encapsulation causes MPLS packets to be sent through "IP
tunnels". When a packet is received by the tunnel's receive tunnels". When a packet is received by the tunnel's receive
endpoint, the receive endpoint decapsulates the MPLS packet by endpoint, the receive endpoint decapsulates the MPLS packet by
removing the IP header. The packet is then processed as a received removing the IP header. The packet is then processed as a received
MPLS packet whose "incoming label" [RFC3031] is the topmost label of MPLS packet whose "incoming label" [RFC3031] is the topmost label of
the decapsulated packet. the decapsulated packet.
4. Encapsulation in GRE 4. Encapsulation in GRE
The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE
[RFC2784]. The packet then consists of an IP header followed by a [RFC2784]. The packet then consists of an IP header (either IPv4 or
GRE header followed by an MPLS label stack as specified in [RFC3032]. IPv6) followed by a GRE header followed by an MPLS label stack as
The protocol type field in the GRE header MUST be set to the specified in [RFC3032]. The protocol type field in the GRE header
Ethertype value for MPLS Unicast (0x8847) or Multicast (0x8848). The MUST be set to the Ethertype value for MPLS Unicast (0x8847) or
optional GRE checksum, key [RFC2890] and sequence number [RFC2890] Multicast (0x8848).
fields MUST NOT be used.
This encapsulation causes MPLS packets to be sent through "GRE This encapsulation causes MPLS packets to be sent through "GRE
tunnels". When a packet is received by the tunnel's receive endpoint, tunnels". When a packet is received by the tunnel's receive endpoint,
the receive endpoint decapsulates the MPLS packet by removing the IP the receive endpoint decapsulates the MPLS packet by removing the IP
header and the GRE header. The packet is then processed as a header and the GRE header. The packet is then processed as a
received MPLS packet whose "incoming label" [RFC3031] is the topmost received MPLS packet whose "incoming label" [RFC3031] is the topmost
label of the decapsulated packet. 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 that are 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 to be a security feature,
functioning as a 32-bit cleartext password, but this is an extremely
weak form of security. In order to (a) facilitate high speed
implementations of the encapsulation/decapsulation procedures, and
(b) ensure interoperability, we require that all implementations be
able to operate correctly without these optional fields.
More precisely, an implementation of an MPLS-in-GRE decapsulator MUST
be able to correctly process packets without these optional fields.
It MAY be able to correctly process packets 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 5. Common Procedures
Certain procedures are common to both the MPLS-in-IP and the MPLS- Certain procedures are common to both the MPLS-in-IP and the MPLS-
in-GRE encapsulations. In the following, the encapsulator, whose in-GRE encapsulations. In the following, the encapsulator, whose
address appears in the IP source address field of the encapsulating address appears in the IP source address field of the encapsulating
IP header, is known as the "tunnel head". The decapsulator, whose IP header, is known as the "tunnel head". The decapsulator, whose
address appears in the IP destination address field of the address appears in the IP destination address field of the
decapsulating IP header, is known as the "tunnel tail". decapsulating IP header, is known as the "tunnel tail".
5.1. Fragmentation, Reassembly, and MTU In the case where IPv6 is being used (for either MPLS-in-IPv6 or
MPLS-in-GRE-in-IPv6), the procedures of [RFC2473] are generally
applicable. However, in the next section, this specification does
establish an optional modification of those procedures with regard to
fragmentation.
5.1. Preventing Fragmentation and Reassembly
If an MPLS-in-IP or MPLS-in-GRE packet were to get fragmented (due to If an MPLS-in-IP or MPLS-in-GRE packet were to get fragmented (due to
"ordinary" IP fragmentation), it would have to be be reassembled by "ordinary" IP fragmentation), it would have to be be reassembled by
the tunnel tail before the contained MPLS packet could be the tunnel tail before the contained MPLS packet could be
decapsulated. To avoid the need for the tunnel tail to perform decapsulated. When the tunnel tail is a router, this is likely to be
reassembly, the tunnel head MUST set the Don't Fragment flag of the undesirable; the tunnel tail may not have the ability or the
encapsulating IPv4 header. resources to perform reassembly at the necessary level of
performance.
The tunnel head SHOULD perform Path MTU Discovery [RFC1191] over each Whether fragmentation of the tunneled packets is allowed MUST be
MPLS-in-IP and MPLS-in-GRE tunnel. configurable at the tunnel head. The default value MUST be that
packets are not to be fragmented. The default value would only be
changed if it were known that the tunnel tail could perform the
reassembly function adequately.
The tunnel head MUST maintain a Tunnel MTU value for each MPLS-in-IP THE PROCEDURES SPECIFIED IN THE REMAINDER OF THIS SECTION ONLY APPLY
or MPLS-in-GRE tunnel. This is the minimum of (a) an administratively IN THE CASE WHERE PACKETS ARE NOT TO BE FRAGMENTED.
configured value, and, if known, (b) the discovered Path MTU value
minus the encapsulation overhead. Obviously, if packets are not to be fragmented, the tunnel head MUST
NOT fragment a packet before encapsulating it. If IPv6 is being
used, this requirement is a modification of [RFC2473].
If IPv4 is being used, then the tunnel MUST set the DF bit. This
prevents intermediate nodes in the tunnel from performing
fragmentation. (If IPv6 is being 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 If the tunnel head receives, for encapsulation, an MPLS packet whose
size exceeds the Tunnel MTU, that packet MUST be discarded. size exceeds the Tunnel MTU, that packet MUST be discarded.
In some cases, the tunnel head receives, for encapsulation, an IP In some cases, the tunnel head receives, for encapsulation, an IP
packet, which it first encapsulates in MPLS and then encapsulates in 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 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 reachable from the tunnel head, and if the result of encapsulating
the packet in MPLS would be a packet whose size exceeds the Tunnel the packet in MPLS would be a packet whose size exceeds the Tunnel
MTU, then the value which the tunnel head SHOULD use for the purposes MTU, then the value which the tunnel head SHOULD use for the purposes
of fragmentation and PMTU discovery outside the tunnel is the Tunnel of fragmentation and PMTU discovery outside the tunnel is the Tunnel
MTU value minus the size of the MPLS sencapsulation. 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 needs to get 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 5.2. TTL or Hop Limit
The tunnel head MAY place the TTL from the MPLS label stack into the The tunnel head MAY place the TTL from the MPLS label stack into the
encapsulating IP header. The tunnel tail MAY place the TTL from the TTL field of the encapsulating IPv4 header or the Hop Limit field of
encapsulating IP header into the MPLS header, but only if that does the encapsulating IPv6 header. The tunnel tail MAY place the TTL
not cause the TTL value in the MPLS header to become larger. from the encapsulating IPv4 header or the Hop Limit form the
encapsulating IPv6 header into the TTL field of the MPLS header, but
only if that does not cause the TTL value in the MPLS header to
become larger.
Whether such modifications are made, and the details of how they are Whether such modifications are made, and the details of how they are
made, will depend on the configuration of the tunnel tail and the made, will depend on the configuration of the tunnel tail and the
tunnel head. tunnel head.
5.3. EXP and DSCP fields 5.3. Differentiated Services
The tunnel head MAY consider the EXP field of the encapsulated MPLS The procedures specified in this document enable an LSP to be sent
packet when setting the DSCP field of the encapsulating IP header. through an IP or GRE tunnel. [RFC2983] details a number of
The tunnel tail MAY modify the EXP field of the encapsulated MPLS considerations and procedures which need to be applied to properly
packet, based on consideration of the DSCP field of the encapsulating support the Differentiated Services Architecture in the presence of
IP header. IP-in-IP tunnels. These considerations and procedures also apply in
the presence of MPLS-in-IP or MPLS-in-GRE tunnels.
Whether such modifications are made, and the details of how they are Accordingly, when a tunnel head is about to send an MPLS packet into
made, will depend on the configuration of the tunnel tail and the an MPLS-in-IP or MPLS-in-GRE tunnel, the setting of the DS field of
tunnel head. 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 6. Applicability
The MPLS-in-IP encapsulation is the more efficient, and would The MPLS-in-IP encapsulation is the more efficient, and would
generally be regarded as preferable, other things being equal. There generally be regarded as preferable, other things being equal. There
are however some situations in which the MPLS-in-GRE encapsulation are however some situations in which the MPLS-in-GRE encapsulation
may be used: may be used:
- Two routers are "adjacent" over a GRE tunnel that exists for some - Two routers are "adjacent" over a GRE tunnel that exists for some
reason that is outside the scope of this document, and those two reason that is outside the scope of this document, and those two
skipping to change at page 6, line 38 skipping to change at page 8, line 35
the MPLS-in-GRE encapsulation is more efficient than the the MPLS-in-GRE encapsulation is more efficient than the
alternative, which would be an MPLS-in-IP encapsulation which is alternative, which would be an MPLS-in-IP encapsulation which is
then encapsulated in GRE. then encapsulated in GRE.
- Implementation considerations may dictate the use of MPLS-in-GRE. - Implementation considerations may dictate the use of MPLS-in-GRE.
For example, some hardware device might only be able to handle For example, some hardware device might only be able to handle
GRE encapsulations in its fastpath. GRE encapsulations in its fastpath.
7. IANA Considerations 7. IANA Considerations
The MPLS-in-IP encapsulation requires that IANA allocate two IP The MPLS-in-IP encapsulation requires that IANA allocate an IP
Protocol Numbers, as described in section 3. No future IANA actions Protocol Number, as described in section 3. No future IANA actions
will be required. The MPLS-in-GRE encapsulation does not require any will be required. The MPLS-in-GRE encapsulation does not require any
IANA action. IANA action.
8. Security Considerations 8. Security Considerations
MPLS-in-IP or MPLS-in-GRE tunnels may be secured using IPsec. When The main security problem faced when using IP or GRE tunnels is the
using IPsec, the tunnel head and the tunnel tail should be treated as possibility that the tunnel's receive endpoint will get a packet
the endpoints of a Security Association. The MPLS-in-IP or MPLS- which appears to be from the tunnel, but which was not actually put
in-GRE encapsulated packets should be considered as originating at into the tunnel by the tunnel's transmit endpoint. (I.e., the
the tunnel head and as being destined for the tunnel tail; IPsec specified encapsulations do not by themselves enable the decapsulator
transport mode should thus be used. Key distribution may be done to authenticate the encapsulator.) A second problem is the
either manually or automatically. possibility that the packet will be altered between the time it
enters the tunnel and the time it leaves the tunnel. (I.e., 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. (I.e., 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. E.g., lack of privacy for tunneled
packets is not a significant issue if the applications generating the
packets do not require privacy.
8.1. Securing the Tunnel Using IPsec
All of these security issues can be avoided if the MPLS-in-IP or
MPLS-in-GRE tunnels are secured using IPsec.
When using IPsec, 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.,
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 setting up the tunnel. If the tunnel is set up
automatically as the result, e.g., of 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
considered as originating at the tunnel head and as being destined
for the tunnel tail; IPsec transport mode SHOULD thus be used.
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.) Whether additional security, i.e., confidentiality
and/or replay protection, is required will depend upon the needs of
the applications whose data is being sent through the tunnel. If
confidentiality is not needed, then either the AH or the ESP
protocols MAY be used. If confidentiality is needed, the ESP
protocol MUST be used, and the payload must be encrypted. If ESP is
used, the tunnel tail MUST check that the source IP address of any
packet that is received on a given SA is the one that is expected.
Key distribution may be done either manually, or automatically by
means of IKE [RFC2409]. Manual key distribution is much simpler, but
also less scalable, than automatic key distribution. Which method of
key distribution is appropriate for a particular tunnel thus needs 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 MUST be used.
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 separately secure multiple MPLS-in-IP tunnels
between a given pair of nodes, 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 the source and destination
addresses mentioned above, and the IP protocol number representing
GRE (47). If it is desired to separately secure multiple MPLS-in-GRE
tunnels between a given pair of nodes, each tunnel must have unique
pair of IP addresses.
8.2. In the Absence of IPsec
If the tunnels are not secured using IPsec, then some other method If the tunnels are not secured using IPsec, then some other method
should be used to ensure that packets are decapsulated and forwarded should be used to ensure that packets are decapsulated and forwarded
by the tunnel tail only if those packets were encapsulated by the by the tunnel tail only if those packets were encapsulated by the
tunnel head. This can be done by address filtering at the boundaries tunnel head. If the tunnel lies entirely within a single
of an administrative domain. When the tunnel head and the tunnel administrative domain, address filtering at the boundaries can be
tail are not in the same domain, this may become difficult, and it used to ensure that packets with the IP source and/or destination
can even become impossible if the packets must traverse the public address of a tunnel endpoint cannot enter the domain from outside.
Internet.
9. Intellectual Property Notice However, when the tunnel head and the tunnel tail are not in the same
administrative domain, this may become difficult, and it can even
become impossible if the packets must traverse the public Internet.
This document does not require that the decapsulator validate the IP
source address of the tunneled packets; failure to do so may enhance
performance, and performing this validation does not protect against
packets that have spoofed source addresses (though it does protect
against packets which do not have spoofed source addresses and were
not really sent by a remote tunnel endpoint.)
9. Acknowledgments
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
Scott Bradner, Alex Conta, Mark Duffy, Francois Le Feucheur, Allison
Mankin, Thomas Narten, and Pekka Savola.
10. Normative References
[RFC791] "Internet Protocol," J. Postel, Sep 1981
[RFC792] "Internet Control Message Protocol", J. Postel, Sept 1981
[RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November
1990
[RFC1981] "Path MTU Discovery for IP version 6", J. McCann, S.
Deering, J. Mogul, August 1996
[RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S.
Deering and R. Hinden, RFC 2460,Dec 1998
[RFC2463] "Internet Control Message Protocol (ICMPv6) for the
Internet Protocol Version 6 (IPv6) Specification", A. Conta, S.
Deering, December 1998
[RFC2473] "Generic Packet Tunneling in IPv6 Specification", A. Conta,
S. Deering, December 1998
[RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li,
S. Hanks, D. Meyer, P. Traina, March 2000
[RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A.
Viswanathan, R. Callon, January 2001
[RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G.
Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001
11. Informative References
[RFC2401] "Security Architecture for the Internet Protocol", S. Kent,
R. Atkinson, November 1998
[RFC2402] "IP Authentication Header", S. Kent, R. Atkinson, November
1998
[RFC2406] "IP Encapsulating Security Payload (ESP)", S. Kent
R.Atkinson, November 1998
[RFC2409] "The Internet Key Exchange (IKE)", D. Harkins, D. Carrel,
November 1998
[RFC2475] "An Architecture for Differentiated Service", S. Blake, D.
Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998
[RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety,
August 2000
[RFC2983] "Differentiated Services and Tunnels", D. Black. October
2000
[RFC3260] "New Terminology and Clarifications for Diffserv", D.
Grossman, April 2002
[RFC3270] "Multiprotocol Label Switching (MPLS) Support of
Differentiated Services", F. Le Faucheur, L. Wu, B. Davie, S. Davari,
P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. May 2002
12. Author Information
Tom Worster
Email: fsb@thefsb.org
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
13. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
skipping to change at page 8, line 5 skipping to change at page 13, line 32
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
10. Copyright Notice 14. Copyright Notice
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 8, line 32 skipping to change at line 570
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
11. Acknowledgments
This specification combines a draft on encapsulating MPLS in IP, by
Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew G.
Malis, and Rick Wilder, with a draft 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. We also
think Mark Duffy and Scott Bradner for their comments.
12. Normative References
[RFC791] "Internet Protocol," J. Postel, Sep 1981
[RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November
1990
[RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li,
S. Hanks, D. Meyer, P. Traina, March 2000
[RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A.
Viswanathan, R. Callon, January 2001
[RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G.
Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001
13. Informative References
[RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S.
Deering and R. Hinden, RFC 2460,Dec 1998
[RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety,
August 2000
14. Author Information
Tom Worster
Email: fsb@thefsb.org
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
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/