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 |