draft-ietf-mpls-in-ip-or-gre-04.txt   draft-ietf-mpls-in-ip-or-gre-05.txt 
Network Working Group Tom Worster Network Working Group Tom Worster
Internet Draft Internet Draft
Expiration Date: July 2004 Expiration Date: August 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.
January 2004 February 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-04.txt draft-ietf-mpls-in-ip-or-gre-05.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 19 skipping to change at page 2, line 19
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 ................................ 7
6 Applicability .......................................... 8 6 Applicability .......................................... 8
7 IANA Considerations .................................... 8 7 IANA Considerations .................................... 8
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 ................................ 10 8.2 In the Absence of IPsec ................................ 11
9 Acknowledgments ........................................ 11 9 Acknowledgments ........................................ 11
10 Normative References ................................... 11 10 Normative References ................................... 12
11 Informative References ................................. 12 11 Informative References ................................. 12
12 Author Information ..................................... 12 12 Author Information ..................................... 13
13 Intellectual Property Notice ........................... 13 13 Intellectual Property Notice ........................... 13
14 Copyright Notice ....................................... 13 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
In many applications of MPLS, packets traversing an MPLS backbone In many applications of MPLS, packets traversing an MPLS backbone
skipping to change at page 9, line 48 skipping to change at page 9, line 48
control protocol MUST have an authentication mechanism, and this MUST control protocol MUST have an authentication mechanism, and this MUST
be used when setting up the tunnel. If the tunnel is set up be used when setting up the tunnel. If the tunnel is set up
automatically as the result, e.g., of information distributed by BGP, automatically as the result, e.g., of information distributed by BGP,
then the use of BGP's MD5-based authentication mechanism is then the use of BGP's MD5-based authentication mechanism is
satisfactory. satisfactory.
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 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
header followed by the MPLS label stack. The IPsec header needs 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 packket, 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.
Recall 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 which 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 which 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 An IPsec-secured MPLS-in-IP or MPLS-in-GRE tunnel MUST provide
authentication and integrity. (Note that the authentication and authentication and integrity. (Note that the authentication and
integrity will apply to the entire MPLS packet, including the MPLS integrity will apply to the entire MPLS packet, including the MPLS
label stack.) Whether additional security, i.e., confidentiality label stack.) Whether additional security, i.e., confidentiality
and/or replay protection, is required will depend upon the needs of and/or replay protection, is required will depend upon the needs of
the applications whose data is being sent through the tunnel. If the applications whose data is being sent through the tunnel. If
confidentiality is not needed, then either the AH or the ESP confidentiality is not needed, then either the AH or the ESP
protocols MAY be used. If confidentiality is needed, 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 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 used, the tunnel tail MUST check that the source IP address of any
skipping to change at page 11, line 18 skipping to change at page 11, line 42
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
Scott Bradner, Alex Conta, Mark Duffy, Francois Le Feucheur, Allison Rahul Aggarwal, Scott Bradner, Alex Conta, Mark Duffy, Francois Le
Mankin, Thomas Narten, and Pekka Savola. Feucheur, Allison Mankin, Thomas Narten, and Pekka Savola.
10. Normative References 10. Normative References
[RFC791] "Internet Protocol," J. Postel, Sep 1981 [RFC791] "Internet Protocol," J. Postel, Sep 1981
[RFC792] "Internet Control Message Protocol", J. Postel, Sept 1981 [RFC792] "Internet Control Message Protocol", J. Postel, Sept 1981
[RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November [RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November
1990 1990
 End of changes. 

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