draft-ietf-mpls-in-ip-or-gre-05.txt   draft-ietf-mpls-in-ip-or-gre-06.txt 
Network Working Group Tom Worster Network Working Group Tom Worster
Internet Draft Internet Draft
Expiration Date: August 2004 Expiration Date: September 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.
February 2004 March 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-05.txt draft-ietf-mpls-in-ip-or-gre-06.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 2, line 14 skipping to change at page 2, line 14
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 ................................... 5 4 Encapsulation in GRE ................................... 5
5 Common Procedures ...................................... 6 5 Common Procedures ...................................... 6
5.1 Preventing Fragmentation and Reassembly ................ 6 5.1 Preventing Fragmentation and Reassembly ................ 6
5.2 TTL or Hop Limit ....................................... 7 5.2 TTL or Hop Limit ....................................... 7
5.3 Differentiated Services ................................ 7 5.3 Differentiated Services ................................ 8
6 Applicability .......................................... 8 6 Applicability .......................................... 8
7 IANA Considerations .................................... 8 7 IANA Considerations .................................... 9
8 Security Considerations ................................ 9 8 Security Considerations ................................ 9
8.1 Securing the Tunnel Using IPsec ........................ 9 8.1 Securing the Tunnel Using IPsec ........................ 9
8.2 In the Absence of IPsec ................................ 11 8.2 In the Absence of IPsec ................................ 11
9 Acknowledgments ........................................ 11 9 Acknowledgments ........................................ 12
10 Normative References ................................... 12 10 Normative References ................................... 12
11 Informative References ................................. 12 11 Informative References ................................. 13
12 Author Information ..................................... 13 12 Author Information ..................................... 13
13 Intellectual Property Notice ........................... 13 13 Intellectual Property Notice ........................... 14
14 Copyright Notice ....................................... 14 14 Copyright Notice ....................................... 14
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
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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".
In the case where IPv6 is being used (for either MPLS-in-IPv6 or 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 MPLS-in-GRE-in-IPv6), the procedures of [RFC2473] are generally
applicable. However, in the next section, this specification does applicable.
establish an optional modification of those procedures with regard to
fragmentation.
5.1. Preventing Fragmentation and Reassembly 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. When the tunnel tail is a router, this is likely to 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 undesirable; the tunnel tail may not have the ability or the
resources to perform reassembly at the necessary level of resources to perform reassembly at the necessary level of
performance. performance.
skipping to change at page 6, line 40 skipping to change at page 6, line 38
Whether fragmentation of the tunneled packets is allowed MUST be Whether fragmentation of the tunneled packets is allowed MUST be
configurable at the tunnel head. The default value MUST be that configurable at the tunnel head. The default value MUST be that
packets are not to be fragmented. The default value would only be packets are not to be fragmented. The default value would only be
changed if it were known that the tunnel tail could perform the changed if it were known that the tunnel tail could perform the
reassembly function adequately. reassembly function adequately.
THE PROCEDURES SPECIFIED IN THE REMAINDER OF THIS SECTION ONLY APPLY THE PROCEDURES SPECIFIED IN THE REMAINDER OF THIS SECTION ONLY APPLY
IN THE CASE WHERE PACKETS ARE NOT TO BE FRAGMENTED. IN THE CASE WHERE PACKETS ARE NOT TO BE FRAGMENTED.
Obviously, if packets are not to be fragmented, the tunnel head MUST Obviously, if packets are not to be fragmented, the tunnel head MUST
NOT fragment a packet before encapsulating it. If IPv6 is being NOT fragment a packet before encapsulating it.
used, this requirement is a modification of [RFC2473].
If IPv4 is being used, then the tunnel MUST set the DF bit. This If IPv4 is being used, then the tunnel MUST set the DF bit. This
prevents intermediate nodes in the tunnel from performing prevents intermediate nodes in the tunnel from performing
fragmentation. (If IPv6 is being used, intermediate nodes do not fragmentation. (If IPv6 is being used, intermediate nodes do not
perform fragmentation in any event.) perform fragmentation in any event.)
The tunnel head SHOULD perform Path MTU Discovery ([RFC1191] for The tunnel head SHOULD perform Path MTU Discovery ([RFC1191] for
IPv4, or [RFC1981] for IPv6). IPv4, or [RFC1981] for IPv6).
The tunnel head MUST maintain a "Tunnel MTU" for each tunnel; this is The tunnel head MUST maintain a "Tunnel MTU" for each tunnel; this is
the minimum of (a) an administratively configured value, and, if the minimum of (a) an administratively configured value, and, if
known, (b) the discovered Path MTU value minus the encapsulation known, (b) the discovered Path MTU value minus the encapsulation
overhead. 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. 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 it is large packets
that are the cause of 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 properly
identify the originating sender. 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 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 encapsulation. (That is, the 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 Tunnel MTU value minus the size of the MPLS encapsulation is the MTU
skipping to change at page 10, line 6 skipping to change at page 10, line 15
The MPLS-in-IP or MPLS-in-GRE encapsulated packets should be The MPLS-in-IP or MPLS-in-GRE encapsulated packets should be
considered as originating at the tunnel head and as being destined considered as originating at the tunnel head and as being destined
for the tunnel tail; IPsec transport mode SHOULD thus be used. 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 IP header of the MPLS-in-IP packet becomes the outer IP header of
the resulting packet when IPsec transport mode is used by the tunnel the resulting packet when IPsec transport mode is used by the tunnel
head to secure the MPLS-in-IP packet. This is followed by an IPsec head to secure the MPLS-in-IP packet. This is followed by an IPsec
header followed by the MPLS label stack. The IPsec header needs to header followed by the MPLS label stack. The IPsec header needs to
set the payload type to MPLS by using the IP protocol number set the payload type to MPLS by using the IP protocol number
specified in section 3. If IPsec transport mode is applied on a specified in section 3. If IPsec transport mode is applied on a
MPLS-in-GRE packket, the GRE header follows the IPsec header. MPLS-in-GRE packet, the GRE header follows the IPsec header.
At the tunnel tail, IPsec outbound processing recovers the contained At the tunnel tail, IPsec outbound processing recovers the contained
MPLS-in-IP/GRE packet. The tunnel tail then strips off the MPLS-in-IP/GRE packet. The tunnel tail then strips off the
encapsulating IP/GRE header to recover the MPLS packet, which is then encapsulating IP/GRE header to recover the MPLS packet, which is then
forwarded according to its label stack. forwarded according to its label stack.
Recall that the tunnel tail and the tunnel head are LSP adjacencies, Recall that the tunnel tail and the tunnel head are LSP adjacencies,
which means that the topmost label of any packet sent through the which means that the topmost label of any packet sent through the
tunnel must be one which was distributed by the tunnel tail to the tunnel must be one which was distributed by the tunnel tail to the
tunnel head. The tunnel tail MUST know precisely which labels it has tunnel head. The tunnel tail MUST know precisely which labels it has
skipping to change at page 11, line 19 skipping to change at page 11, line 26
tunnels between a given pair of nodes, each tunnel must have unique tunnels between a given pair of nodes, each tunnel must have unique
pair of IP addresses. pair of IP addresses.
8.2. In the Absence of IPsec 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. If the tunnel lies entirely within a single tunnel head. If the tunnel lies entirely within a single
administrative domain, address filtering at the boundaries can be administrative domain, address filtering at the boundaries can be
used to ensure that packets with the IP source and/or destination used to ensure that no packet with the IP source address of a tunnel
address of a tunnel endpoint cannot enter the domain from outside. endpoint or with the IP destination address of a tunnel endpoint can
the domain from outside.
However, when the tunnel head and the tunnel tail are not in the same However, when the tunnel head and the tunnel tail are not in the same
administrative domain, this may become difficult, and it can even administrative domain, this may become difficult, and filtering based
become impossible if the packets must traverse the public Internet. on the destination address can even become impossible if the packets
must traverse the public Internet.
This document does not require that the decapsulator validate the IP Sometimes only source address filtering (but not destination address
source address of the tunneled packets; failure to do so may enhance filtering) is done at the boundaries of an administrative domain. If
performance, and performing this validation does not protect against this is the case, the filtering does not provide effective protection
packets that have spoofed source addresses (though it does protect at all unless the decapsulator of an MPLS-in-IP or MPLS-in-GRE
against packets which do not have spoofed source addresses and were validates the IP source address of the packet. This document does not
not really sent by a remote tunnel endpoint.) require that the decapsulator validate the IP source address of the
tunneled packets, but it should be understood that failure to do so
presupposes that there is effective destination-based (or combination
of source-based and destination-based) filtering at the boundaries.
9. Acknowledgments 9. Acknowledgments
This specification combines prior work on encapsulating MPLS in IP, This specification combines prior work on encapsulating MPLS in IP,
by Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew by Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew
G. Malis, and Rick Wilder, with prior work on encapsulating MPLS in G. Malis, and Rick Wilder, with prior work on encapsulating MPLS in
GRE, by Yakov Rekhter, Daniel Tappan, and Eric Rosen. The current GRE, by Yakov Rekhter, Daniel Tappan, and Eric Rosen. The current
authors wish to thank all these authors for their contribution. authors wish to thank all these authors for their contribution.
Many people have made valuable comments and corrections, including Many people have made valuable comments and corrections, including
 End of changes. 

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