Skip to main content

Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
RFC 4023

Revision differences

Document history

Date Rev. By Action
2017-05-16
08 (System) Changed document authors from "Tom Worster, Yakov Rekhter" to "Tom Worster, Yakov Rekhter, Eric Rosen"
2015-10-14
08 (System) Notify list changed from <swallow@cisco.com>, <loa@pi.se>, erosen@cisco.com to erosen@cisco.com
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Thomas Narten
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Bert Wijnen
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Allison Mankin
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Steven Bellovin
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2005-03-24
08 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-03-24
08 Amy Vezza [Note]: 'RFC 4023' added by Amy Vezza
2005-03-08
08 (System) RFC published
2004-10-08
08 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-10-07
08 Amy Vezza IESG state changed to Approved-announcement sent
2004-10-07
08 Amy Vezza IESG has approved the document
2004-10-07
08 Amy Vezza Closed "Approve" ballot
2004-10-07
08 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2004-09-30
08 Alex Zinin Note field has been cleared by Alex Zinin
2004-09-30
08 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin
2004-06-25
08 (System) Removed from agenda for telechat - 2004-06-24
2004-06-23
08 (System) New version available: draft-ietf-mpls-in-ip-or-gre-08.txt
2004-06-16
08 Alex Zinin Placed on agenda for telechat - 2004-06-24 by Alex Zinin
2004-06-16
08 Alex Zinin [Note]: 'to clear Steve''s DISCUSS' added by Alex Zinin
2004-06-02
08 Alex Zinin Note field has been cleared by Alex Zinin
2004-06-02
08 Alex Zinin
Based on the discussion with smb, suggested changes
to the security section. The author is fine. Pending
smb's reply. Recorded the following RFC Editor note …
Based on the discussion with smb, suggested changes
to the security section. The author is fine. Pending
smb's reply. Recorded the following RFC Editor note
meanwhile.

Section 8: Security Considerations

After paragraph 1, ADD:

  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 need to be implemented and deployed. Those
  are discussed in section 8.2.

Section 8.1. Securing the Tunnel Using IPsec,

Paragraph 1:

OLD:
  All of these security issues can be avoided if the MPLS-in-IP or
  MPLS-in-GRE tunnels are secured using IPsec.

NEW:
  All of these security issues can be avoided if the MPLS-in-IP or
  MPLS-in-GRE tunnels are secured using IPsec. Implementation requirements
  defined in this section apply if IPsec is implemented.


Paragraph 7:

OLD:

  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.

NEW:

  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 with null
  encryption. ESP with encryption MAY be  supported if a specific application
  requires confidentiallity. 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.

Paragraph 8:

OLD:

  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.

NEW:

  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 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.  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 should be configured.
2004-06-02
08 Alex Zinin State Change Notice email list have been change to <swallow@cisco.com>, <loa@pi.se>, erosen@cisco.com from <swallow@cisco.com>, <loa@pi.se>
2004-05-28
08 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen
2004-05-27
08 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-05-26
08 Harald Alvestrand [Ballot comment]
Reviewed by Brian Carpenter, Gen-ART
2004-05-25
08 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-05-25
08 Steven Bellovin
[Ballot discuss]
This version is a lot better.  However, the spec still doesn't say whether or not AH, ESP, and IKE are mandatory to implement.  …
[Ballot discuss]
This version is a lot better.  However, the spec still doesn't say whether or not AH, ESP, and IKE are mandatory to implement.  It provides guidance on when they should be used, which is good, but doesn't tell implementors what to provide.

Note (2004/05/25): The above comments have still not been addressed.
2004-05-19
08 Alex Zinin State Changes to IESG Evaluation from IESG Evaluation::Revised ID Needed by Alex Zinin
2004-05-19
08 Alex Zinin Placed on agenda for telechat - 2004-05-27 by Alex Zinin
2004-05-19
08 Alex Zinin
[Note]: 'The WG discussed comments from Pekka (add mandatory to implement source-address checking). The WG consensus was not in favor of them. My personal review …
[Note]: 'The WG discussed comments from Pekka (add mandatory to implement source-address checking). The WG consensus was not in favor of them. My personal review of the technical arguements did not yield a solid reason to request the WG to add this feature to the spec.' added by Alex Zinin
2004-05-19
08 Alex Zinin Back on the agenda to clear Steve's and Bert's DISCUSSES.
2004-03-16
07 (System) New version available: draft-ietf-mpls-in-ip-or-gre-07.txt
2004-03-15
08 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to No Objection from Discuss by Thomas Narten
2004-03-11
06 (System) New version available: draft-ietf-mpls-in-ip-or-gre-06.txt
2004-02-19
08 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2004-02-19
08 Allison Mankin
[Ballot comment]
I gave my assent to the author on wording to clear my Discuss on this 6 weeks
ago.  It would have been helpful …
[Ballot comment]
I gave my assent to the author on wording to clear my Discuss on this 6 weeks
ago.  It would have been helpful to be given back my email when asked to
re-check the i-d, rather than having me find it.
2004-02-19
08 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin
2004-02-18
08 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-02-17
08 Steven Bellovin
[Ballot discuss]
This version is a lot better.  However, the spec still doesn't say whether or not AH, ESP, and IKE are mandatory to implement.  …
[Ballot discuss]
This version is a lot better.  However, the spec still doesn't say whether or not AH, ESP, and IKE are mandatory to implement.  It provides guidance on when they should be used, which is good, but doesn't tell implementors what to provide.
2004-02-10
08 Alex Zinin Placed on agenda for telechat - 2004-02-19 by Alex Zinin
2004-02-10
08 Alex Zinin State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Alex Zinin
2004-02-10
08 Alex Zinin [Note]: 'Back to telechat to check if comments have been addressed properly.' added by Alex Zinin
2004-02-08
08 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2004-02-06
08 Alex Zinin State Changes to IESG Evaluation::AD Followup from IESG Evaluation::Revised ID Needed by Alex Zinin
2004-02-06
08 Alex Zinin got an update, checking with DISCUSS holders.
2004-02-03
05 (System) New version available: draft-ietf-mpls-in-ip-or-gre-05.txt
2004-01-21
04 (System) New version available: draft-ietf-mpls-in-ip-or-gre-04.txt
2003-12-18
08 Amy Vezza Removed from agenda for telechat - 2003-12-18 by Amy Vezza
2003-12-18
08 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2003-12-18
08 Amy Vezza [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Undefined by Amy Vezza
2003-12-18
08 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-12-18
08 Allison Mankin
[Ballot discuss]
This is a small symptom from the larger problems raised by the others, but not trivial - on tunnel entrance the DSCP field …
[Ballot discuss]
This is a small symptom from the larger problems raised by the others, but not trivial - on tunnel entrance the DSCP field is set from the EXP field: does this include the ECN bits?  Please exclude them specifically.  How consistent is this EXP mapping option with MPLS diffserv?  It seems very throw-away which does not seem consistent with intended care with which MPLS diffserv is used according to  RFC 3564.



5.3. EXP and DSCP fields

  The tunnel head MAY consider the EXP field of the encapsulated MPLS
  packet when setting the DSCP field of the encapsulating IP header.
  The tunnel tail MAY modify the EXP field of the encapsulated MPLS
  packet, based on consideration of the DSCP field of the encapsulating
  IP header.
2003-12-18
08 Allison Mankin [Ballot Position Update] New position, Discuss, has been recorded for  by Allison Mankin
2003-12-18
08 Bill Fenner [Ballot Position Update] New position, Undefined, has been recorded for  by Bill Fenner
2003-12-18
08 Bert Wijnen
[Ballot comment]
Comments from Bert:

- I do not understand why RFC791 is normative while RFC2460 is
  Informative

Comments/Nits from OPS directorate (by Pekka). …
[Ballot comment]
Comments from Bert:

- I do not understand why RFC791 is normative while RFC2460 is
  Informative

Comments/Nits from OPS directorate (by Pekka).

We know that some are REAL NITs. just to record them in case
a new rev is done anyway.

Network Working Group                                        Tom Worster
Internet Draft
Expiration Date: March 2004
                                                          Yakov Rekhter
                                                  Juniper Networks, Inc.
                                                                                                                                     
                                                  Eric C. Rosen, editor
                                                    Cisco Systems, Inc.

==> s/Tom/T./, s/Yakov/Y./, s/Eric C./E./

7. IANA Considerations
                                                                                                                                     
  The MPLS-in-IP encapsulation requires that IANA allocate two IP
  Protocol Numbers, as described in section 3.  No future IANA actions
  will be required.  The MPLS-in-GRE encapsulation does not require any
  IANA action.

==> the last sentence should be removed, as it conflicts with the
rest of the section.

  [RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S.

==> s/]"/] "/

9. Intellectual Property Notice
                                                                                                                                     
10. Copyright Notice

==> I'd recommend moving these after Authors Information section (14.)

14. Author Information
                                                                                                                                     
==> s/Author Information/Authors' Addresses/
2003-12-17
08 Margaret Cullen [Ballot comment]
I share Thomas' concerns, but did not choose to enter a separate discuss.
2003-12-17
08 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for  by Margaret Wasserman
2003-12-17
08 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for  by Jon Peterson
2003-12-17
08 Bert Wijnen
[Ballot comment]
Comments/Nits from OPS directorate (by Pekka).
We know that some are REAL NITs. just to record them in case
a new rev is …
[Ballot comment]
Comments/Nits from OPS directorate (by Pekka).
We know that some are REAL NITs. just to record them in case
a new rev is done anyway.

Network Working Group                                        Tom Worster
Internet Draft
Expiration Date: March 2004
                                                          Yakov Rekhter
                                                  Juniper Networks, Inc.
                                                                                                                                     
                                                  Eric C. Rosen, editor
                                                    Cisco Systems, Inc.

==> s/Tom/T./, s/Yakov/Y./, s/Eric C./E./

7. IANA Considerations
                                                                                                                                     
  The MPLS-in-IP encapsulation requires that IANA allocate two IP
  Protocol Numbers, as described in section 3.  No future IANA actions
  will be required.  The MPLS-in-GRE encapsulation does not require any
  IANA action.

==> the last sentence should be removed, as it conflicts with the
rest of the section.

  [RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S.

==> s/]"/] "/

9. Intellectual Property Notice
                                                                                                                                     
10. Copyright Notice

==> I'd recommend moving these after Authors Information section (14.)

14. Author Information
                                                                                                                                     
==> s/Author Information/Authors' Addresses/
2003-12-17
08 Bert Wijnen
[Ballot discuss]
From OPS Directorate review (by Pekka)

I've several bigger issues with this specification, described below. 
I also have some nits, separated as a …
[Ballot discuss]
From OPS Directorate review (by Pekka)

I've several bigger issues with this specification, described below. 
I also have some nits, separated as a section of their own, further
below.

1) (see the text snipped below) the spec specifies that GRE
extensions, such as key and sequence number, MUST NOT be used.  The
reason has never been stated, but I guess it's the implementation
simplicity, being able to calculate right out the size of the packets.

However, the security extensions for GRE exist for a *reason*.  I do
not think it is appropriate to just say they MUST NOT be used. 
Further, this little security decision has not been explicitly
documented in Security Considerations.

So, to fix the problem, I'd suggest either:
1) GRE security extensions are allowed, or
2) it's properly documented why they cannot be used, in section 4 and
in security considerations.

4. Encapsulation 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
  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).  The
  optional GRE checksum, key [RFC2890] and sequence number [RFC2890]
  fields MUST NOT be used.

2) The specification does not take a stance on how it assumes these IP
or GRE tunnels are set up.  Are they expected to be set up already
manually, using unspecified mechanisms or what?

The reason why I'm interested is, how do the tunnel endpoints know
which protocols to use to reach the neighbor over an IP network.  If
the tunnels are assumed to be set up and working manually, that's no
problem, of course.  If they aren't, there is a matrix of
possibilities (IP, GRE; IPv4, IPv6) how to set up the tunnel, and
consequenly large possibility that the head and tail end of the tunnel
are not configured to use the same protocols.

I believe this issue could probably be clarified with a paragraph of a
couple of sentences in the introduction.

3) Some attempts have been made to "IPv6-enable" this specification,
but it hasn't been fully thought out I think. There are some
variations regarding IP fragmentation, Path MTU Discovery, the
terms TTL and DSCP with IPv6, for instance.

4) (See below for the text) partially regarding and depending on the
answer to issue 2) above, it would be interesting to know how the
decapsulator is implemented in practice.  What I'm interested in
particular is whether the decapsulator acts as an "open decapsulator",
decapsulating every IP protocol X (or Y) or GRE w/ MPLS
unicast/multicast without checking, or whether these are "configured
tunnels" (in a sense), that the packets whose source address does not
match are silently discarded without further processing.

So, in practice pretty close to "what can one do if the decapsulator
hasn't configured my IP address as a peer?". 

8. Security Considerations
[...]
  If the tunnels are not secured using 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.  This can be done by address filtering at the boundaries
  of an administrative domain.  When the tunnel head and the tunnel
  tail are not in the same domain, this may become difficult, and it
  can even become impossible if the packets must traverse the public
  Internet.
2003-12-17
08 Bert Wijnen [Ballot Position Update] New position, Discuss, has been recorded for  by Bert Wijnen
2003-12-17
08 Russ Housley
[Ballot discuss]
I agree with the point that Thomas already raised.  No justification
  is provided for the assignment of two IP protocol numbers.  Since …
[Ballot discuss]
I agree with the point that Thomas already raised.  No justification
  is provided for the assignment of two IP protocol numbers.  Since they
  are a scarce resource, a justification is needed for the assignment of
  two protocol numbers.
 
  The security considerations are weak.  What security services are needed
  from IPsec?  I expected a discussion of integrity, authentication,
  confidentiality, and perhaps protection from replay. What are the
  ramifications if theses security services are not provided?
2003-12-17
08 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for  by Russ Housley
2003-12-16
08 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Abstain from Undefined by Ted Hardie
2003-12-16
08 Ted Hardie
[Ballot comment]
As a general comment, I agree with all of Thomas's operational concerns, and I think there are probably more waiting in the weeds.  …
[Ballot comment]
As a general comment, I agree with all of Thomas's operational concerns, and I think there are probably more waiting in the weeds.  This seems to create a very generalized pair of mechanisms
that can probably actually only be used successfully in very tightly pre-configured situations. 

Melinda Shore has several times raised a flag that we're turning our end-to-end network into an all
tunnel network.  When we start tunnelling tunnelling protocols and protecting their security with tunnels, we're in trouble.
2003-12-16
08 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for  by Ted Hardie
2003-12-16
08 Thomas Narten
[Ballot discuss]
>      - [value to be assigned by IANA]  indicates an MPLS unicast packet,
>
>      - [value to be …
[Ballot discuss]
>      - [value to be assigned by IANA]  indicates an MPLS unicast packet,
>
>      - [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.)

One protocol number for this seems OK. Two requires some
justification, since protocol numbers are a scarce resource. Is there
a document describing the mcast version? Why can't they get by with
one protocol number (like other protocols do)?

The fragmentation rules seem like a recipe for operational
problems. Specifically:

>    decapsulated.  To avoid the need for the tunnel tail to perform
>    reassembly, the tunnel head MUST set the Don't Fragment flag of the
>    encapsulating IPv4 header.

the protocol says one MUST set DF. Then, the tunnel MTU can get larger
and smaller depending on conditions (with PMTU recommended be
implemented), but

>    If the tunnel head receives, for encapsulation, an MPLS packet whose
>    size exceeds the Tunnel MTU, that packet MUST be discarded.

So it seems like we will get situations where packets will just
silently get discarded. This doesn't seem very robust, especially if
the sender is sending normal size packets, but they become "too large"
for the tunnel due to added MPLS headers.

Seems like the protocol has no business mandating that DF MUST be
set; isn't this an operational issue between the tunnel endpoints?
Also, it seems like more effort needs to be done to ensure that big
packets don't just get silently dropped.At least send an ICMP error
in return?
2003-12-16
08 Thomas Narten [Ballot Position Update] New position, Discuss, has been recorded for  by Thomas Narten
2003-12-15
08 Steven Bellovin
[Ballot discuss]
"Just use IPsec" is too weak -- give more details.  (Many carriers tout MPLS VPNs as secure; this is a major weakening if …
[Ballot discuss]
"Just use IPsec" is too weak -- give more details.  (Many carriers tout MPLS VPNs as secure; this is a major weakening if the filtering and/or IPsec are done incorrectly.)

Should 5.1 have a sentence or two about IPv6 and MTU?  What to do is pretty obvious; should the document spell it out?
2003-12-15
08 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for  by Steve Bellovin
2003-12-12
08 Ned Freed [Ballot comment]
Copyright section has (date) rather than actual date
2003-12-12
08 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for  by Ned Freed
2003-12-11
08 Alex Zinin [Ballot Position Update] New position, Yes, has been recorded for Alex Zinin
2003-12-11
08 Alex Zinin Ballot has been issued by Alex Zinin
2003-12-11
08 Alex Zinin Created "Approve" ballot
2003-12-10
08 Alex Zinin State Changes to IESG Evaluation from Waiting for Writeup by Alex Zinin
2003-12-10
08 Alex Zinin ready to go to the agenda
2003-12-10
08 Alex Zinin Placed on agenda for telechat - 2003-12-18 by Alex Zinin
2003-11-24
08 (System) State has been changed to Waiting for Writeup from In Last Call by system
2003-11-10
08 Amy Vezza Last call sent
2003-11-10
08 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2003-11-09
08 Alex Zinin Last Call was requested by Alex Zinin
2003-11-09
08 Alex Zinin State Changes to Last Call Requested from AD Evaluation by Alex Zinin
2003-11-09
08 (System) Ballot writeup text was added
2003-11-09
08 (System) Last call text was added
2003-11-09
08 (System) Ballot approval text was added
2003-09-11
08 Alex Zinin State Changes to AD Evaluation from Publication Requested by Alex Zinin
2003-09-11
08 Natalia Syracuse State Changes to Publication Requested from AD is watching by Natalia Syracuse
2003-09-11
08 Natalia Syracuse Intended Status has been changed to Proposed Standard from None
2003-09-10
03 (System) New version available: draft-ietf-mpls-in-ip-or-gre-03.txt
2003-08-19
02 (System) New version available: draft-ietf-mpls-in-ip-or-gre-02.txt
2003-07-25
01 (System) New version available: draft-ietf-mpls-in-ip-or-gre-01.txt
2003-04-16
08 Alex Zinin Shepherding AD has been changed to Zinin, Alex from Bradner, Scott
2003-01-30
08 Scott Bradner 2003-01-29 - ID added to tracker
2003-01-30
08 Scott Bradner Draft Added by Bradner, Scott
2003-01-14
00 (System) New version available: draft-ietf-mpls-in-ip-or-gre-00.txt