Network Working Group D. Farinacci Request for Comments: 2784 T ...

Network Working GroupRequest for Comments: 2784Category: Standards TrackD. FarinacciT. LiProcket NetworksS. HanksEnron CommunicationsD. MeyerCisco SystemsP. TrainaJuniper NetworksMarch 2000Generic Routing Encapsulation (GRE)Status of this MemoThis document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved.AbstractThis document specifies a protocol for encapsulation of an arbitrarynetwork layer protocol over another arbitrary network layer protocol.1. IntroductionA number of different proposals [RFC1234, RFC1226] currently existfor the encapsulation of one protocol over another protocol. Othertypes of encapsulations [RFC1241, RFC1479] have been proposed fortransporting IP over IP for policy purposes. This memo describes aprotocol which is very similar to, but is more general than, theabove proposals. In attempting to be more general, many protocolspecific nuances have been ignored. The result is that this proposalmay be less suitable for a situation where a specific "X over Y"encapsulation has been described. It is the attempt of this protocolto provide a simple, general purpose mechanism which reduces theproblem of encapsulation from its current O(n^2) size to a more

Campagne de qualification 2013 - pièces complémentaires demandées par les sections du CNUToutes les pièces à joindre obligatoirement au dossier et dont la liste est fixée par l'arrêté relatif à la qualification doivent figurer dans l'envoi destinéaux rapporteurs. En cas de dossier incomplet celui-ci sera déclaré "irrecevable". Le strict respect du calendrier est également indispensable,sinon la candidature sera considérée comme "hors délai".En complément des pièces obligatoires, les sections du CNU demandent des pièces complémentaires listées dans le tableau ci -dessous, enl'absence desquelles le dossier du candidat peut ne pas être examiné.Les candidats sont donc invités à envoyer l'ensemble des pièces obligatoires et complémentaires aux rapporteurs dès qu'ils en ont connaissance etau plus tard le 19 décembre.Les candidats à une requalification ne sont pas dispensés de l’envoi de ces pièces.Vous êtes invités à consulter le site de la CPCNU (http://www.cpcnu.fr/listes-des-sections-cnu)pour connaitre les préconisations de chaque section.N° de section Pièces complémentaires demandées Mode de transmission exigé20 Pour les MCF : la thèse en format pdf;ElectroniqueLa thèse en format Papier pour lesrapporteurs qui le demandent21Pour les MCF : la thèse (ou le livre qui en est tiré si la thèse a été publiée)pour les PR : le mémoire scientifique original (ou le livre qui en est tiré si le mémoire aété publié) et le dossier autobiographique ainsi que le recueil d’articles intégré audossier d’habilitation.Pour les travaux réalisés en langue étrangère, une synthèse scientifique en françaiscomportant notamment un résumé étendu de la thèse (environ 30 pages) pour lesMCF ou du mémoire scientifique d’habilitation (environ 50 pages) pour les PR.Papier2223242526Pour les MCF : la thèse (ou le livre qui en est tiré si la thèse a été publiée)pour les PR : le mémoire scientifique original (ou le livre qui en est tiré si le mémoire aété publié) et le dossier autobiographique ainsi que le recueil d’articles intégré audossier d’habilitation.Pour les travaux réalisés en langue étrangère, une synthèse scientifique en françaiscomportant notamment un résumé étendu de la thèse (environ 30 pages) pour lesMCF ou du mémoire scientifique d’habilitation (environ 50 pages) pour les PR.Pour les MCF: 1 exemplaire de la thèse; pour les PR: le mémoire original (inédit) et ledossier auto-biographique ainsi que le recueil d'articles intégré au dossierd'habilitation.Pour les MCF: la thèse; Pour les PR: le dossier d'HDR; pour les thèses rédigées enlangue étrangère, un résumé en français et une traduction du ou des rapportsafférents; un résumé substanciel en français de tout travail présenté dans une langueétrangère.Les rapports de pré-soutenance et un exemplaire de la thèse si les documentsscientifiques fournis (articles, perprints ...) ne couvrent pas les travaux de thèse.Pour les MCF : le rapport de soutenance de la thèse et les rapports des rapporteursde la thèse ;Pour les PR : le rapport de soutenance de la HDR et les rapports des rapporteurs dela HDR;Pour les MCF: la copie des rapports signés de pré-soutenance du doctorat;pour les PR: la copie des rapports signés de pré-soutenance de l'HDR;PapierPapierPapierPapierPapier ou électronique pour lesrapporteurs qui le demandent27Papier28 Pas de pièce complémentaire PapierLa fiche de synthèse téléchargeable sur le site de la CP-CNU section 2929 Une liste complète et détaillée de publications et communications, classées selon lesElectroniquecatégories détaillées dans la fiche synthétique30 Pas de pièce complémentairePapier ou électronique pour lesrapporteurs qui le demandent31 Pas de pièce complémentaire Papier32Pour les MCF : résumé des activités de recherche en 4 pages et copies despublications ;pour les PR : notice de 15 pages incluant un projet de recherche, la liste complète despublications, communications, séminaires et conférences.Papier33 Pas de pièce complémentaire Papier34 Pas de pièce complémentairePapier ou électronique pour lesrapporteurs qui le demandent35 Pas de pièce complémentaire Papier36Pour les MCF : la thèse, les rapports de pré-soutenance, rapports de jury ou autrespour les doctorats étrangers, la lettre d’acceptation de l’éditeur pour les articles encours de publication;Pour les PR : le dossier complet d’HDR comprenant les rapports de pré-soutenance,Papierles rapports de jury ou autres pour les HDR/ doctorats étrangers, une liste despublications, un descriptif des activités (recherche, enseignement) et des projetsd’activités.37 Pas de pièce complémentaire Papier* L'administration se réserve le droit de procéder à une vérification et, le cas échéant, de porter plainte pour déclaration frauduleuse.

The GRE packet header has the form:0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C| Reserved0 | Ver | Protocol Type |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Checksum (optional) | Reserved1 (Optional) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Farinacci, et al. Standards Track [Page 2]RFC 2784 Generic Routing Encapsulation March 20002.2. Checksum Present (bit 0)If the Checksum Present bit is set to one, then the Checksum and theReserved1 fields are present and the Checksum field contains validinformation. Note that a compliant implementation MUST accept andprocess this field.2.3. Reserved0 (bits 1-12)A receiver MUST discard a packet where any of bits 1-5 are non-zero,unless that receiver implements RFC 1701. Bits 6-12 are reserved forfuture use. These bits MUST be sent as zero and MUST be ignored onreceipt.2.3.1. Version Number (bits 13-15)The Version Number field MUST contain the value zero.2.4. Protocol Type (2 octets)The Protocol Type field contains the protocol type of the payloadpacket. These Protocol Types are defined in [RFC1700] as "ETHERTYPES" and in [ETYPES]. An implementation receiving a packetcontaining a Protocol Type which is not listed in [RFC1700] or[ETYPES] SHOULD discard the packet.2.5. Checksum (2 octets)The Checksum field contains the IP (one's complement) checksum sum ofthe all the 16 bit words in the GRE header and the payload packet.For purposes of computing the checksum, the value of the checksumfield is zero. This field is present only if the Checksum Present bitis set to one.

2.6. Reserved1 (2 octets)The Reserved1 field is reserved for future use, and if present, MUSTbe transmitted as zero. The Reserved1 field is present only when theChecksum field is present (that is, Checksum Present bit is set toone).3. IPv4 as a PayloadWhen IPv4 is being carried as the GRE payload, the Protocol Typefield MUST be set to 0x800.Farinacci, et al. Standards Track [Page 3]RFC 2784 Generic Routing Encapsulation March 20003.1. Forwarding Decapsulated IPv4 Payload PacketsWhen a tunnel endpoint decapsulates a GRE packet which has an IPv4packet as the payload, the destination address in the IPv4 payloadpacket header MUST be used to forward the packet and the TTL of thepayload packet MUST be decremented. Care should be taken whenforwarding such a packet, since if the destination address of thepayload packet is the encapsulator of the packet (i.e., the other endof the tunnel), looping can occur. In this case, the packet MUST bediscarded.4. IPv4 as a Delivery ProtocolThe IPv4 protocol 47 [RFC1700] is used when GRE packets areenapsulated in IPv4. See [RFC1122] for requirements relating to thedelivery of packets over IPv4 networks.5. Interoperation with RFC 1701 Compliant ImplementationsIn RFC 1701, the field described here as Reserved0 contained a numberof flag bits which this specification deprecates. In particular, theRouting Present, Key Present, Sequence Number Present, and StrictSource Route bits have been deprecated, along with the RecursionControl field. As a result, the GRE header will never contain theKey, Sequence Number or Routing fields specified in RFC 1701.There are, however, existing implementations of RFC 1701. Thefollowing sections describe correct interoperation with suchimplementations.

5.1. RFC 1701 Compliant ReceiverAn implementation complying to this specification will transmit theReserved0 field set to zero. An RFC 1701 compliant receiver willinterpret this as having the Routing Present, Key Present, SequenceNumber Present, and Strict Source Route bits set to zero, and willnot expect the RFC 1701 Key, Sequence Number or Routing fields to bepresent.5.2. RFC 1701 Compliant TransmitterAn RFC 1701 transmitter may set any of the Routing Present, KeyPresent, Sequence Number Present, and Strict Source Route bits set toone, and thus may transmit the RFC 1701 Key, Sequence Number orRouting fields in the GRE header. As stated in Section 5.3, a packetwith non-zero bits in any of bits 1-5 MUST be discarded unless thereceiver implements RFC 1701.Farinacci, et al. Standards Track [Page 4]RFC 2784 Generic Routing Encapsulation March 20006. Security ConsiderationsSecurity in a network using GRE should be relatively similar tosecurity in a normal IPv4 network, as routing using GRE follows thesame routing that IPv4 uses natively. Route filtering will remainunchanged. However packet filtering requires either that a firewalllook inside the GRE packet or that the filtering is done on the GREtunnel endpoints. In those environments in which this is consideredto be a security issue it may be desirable to terminate the tunnel atthe firewall.7. IANA ConsiderationsThis section considers the assignment of additional GRE VersionNumbers and Protocol Types.7.1. GRE Version NumbersThis document specifies GRE version number 0. GRE version number 1 isused by PPTP [RFC2637]. Additional GRE version numbers are assignedby IETF Consensus as defined in RFC 2434 [RFC2434].7.2. Protocol Types

GRE uses an ETHER Type for the Protocol Type. New ETHER TYPES areassigned by Xerox Systems Institute [RFC1700].8. AcknowledgmentsThis document is derived from the original ideas of the authors ofRFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush,Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler,Tim Gleeson and others provided many constructive and insightfulcomments.Farinacci, et al. Standards Track [Page 5]RFC 2784 Generic Routing Encapsulation March 20009. Appendix -- Known IssuesThis document specifies the behavior of currently deployed GREimplementations. As such, it does not attempt to address thefollowing known issues:o Interaction Path MTU Discovery (PMTU) [RFC1191]Existing implementations of GRE, when using IPv4 as the DeliveryHeader, do not implement Path MTU discovery and do not set theDon't Fragment bit in the Delivery Header. This can cause largepackets to become fragmented within the tunnel and reassembled atthe tunnel exit (independent of whether the payload packet is usingPMTU). If a tunnel entry point were to use Path MTU discovery,however, that tunnel entry point would also need to relay ICMPunreachable error messages (in particular the "fragmentation neededand DF set" code) back to the originator of the packet, which isnot a requirement in this specification. Failure to properly relayPath MTU information to an originator can result in the following

ehavior: the originator sets the don't fragment bit, the packetgets dropped within the tunnel, but since the originator doesn'treceive proper feedback, it retransmits with the same PMTU, causingsubsequently transmitted packets to be dropped.o IPv6 as Delivery and/or Payload ProtocolThis specification describes the intersection of GRE currentlydeployed by multiple vendors. IPv6 as delivery and/or payloadprotocol is not included in the currently deployed versions of GRE.o Interaction with ICMPo Interaction with the Differentiated Services Architectureo Multiple and Looping Encapsulations10. REFERENCES[ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernetnumbers[RFC1122] Braden, R., "Requirements for Internet hosts -communication layers", STD 3, RFC 1122, October 1989.[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,November 1990.Farinacci, et al. Standards Track [Page 6]RFC 2784 Generic Routing Encapsulation March 2000[RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25Frames", RFC 1226, May 1991.[RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",RFC 1234, June 1991.[RFC1241] Woodburn, R. and D. Mills, "Scheme for an InternetEncapsulation Protocol: Version 1", RFC 1241, July 1991.[RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous",RFC 1326, May 1992.[RFC1479] Steenstrup, M., "Inter-Domain Policy Routing ProtocolSpecification: Version 1", RFC 1479, July 1993.

[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700, October 1994.[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "GenericRouting Encapsulation", RFC 1701, October 1994.[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "GenericRouting Encapsulation over IPv4 networks", RFC 1702,October 1994.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March, 1997.[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner,"Internet Security Association and Key Management Protocol(ISAKMP)", RFC 2408, November 1998.[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing anIANA Considerations Section in RFCs", BCP 26, RFC 2434,October, 1998.[RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol(PPTP)", RFC 2637, July, 1999.Farinacci, et al. Standards Track [Page 7]RFC 2784 Generic Routing Encapsulation March 200011. Authors' AddressesDino FarinacciProcket Networks3850 No. First St., Ste. CSan Jose, CA 95134EMail: dino@procket.com

Tony LiProcket Networks3850 No. First St., Ste. CSan Jose, CA 95134Phone: +1 408 954 7903Fax: +1 408 987 6166EMail: tony1@home.netStan HanksEnron CommunicationsEMail: stan_hanks@enron.netDavid MeyerCisco Systems, Inc.170 Tasman DriveSan Jose, CA, 95134EMail: dmm@cisco.comPaul TrainaJuniper NetworksEMail: pst@juniper.netFarinacci, et al. Standards Track [Page 8]RFC 2784 Generic Routing Encapsulation March 200012. Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain itor assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph areincluded on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Farinacci, et al. Standards Track [Page 9]