idnits 2.17.00 (12 Aug 2021) /tmp/idnits55546/draft-martini-l3vpn-rd-zero-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 101. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 112. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 125. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2006) is 5690 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC4364' on line 72 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Keyur Patel 4 Expiration Date: April 2007 Cisco Systems Inc. 6 October 2006 8 Route Distinguisher Zero Value Usage 10 draft-martini-l3vpn-rd-zero-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The behaviour that must be followed when an route distinguisher (RD) 37 of value zero is received is not clearly defined in rfc4364. This 38 document clarifies the use of an RD with a value of zero in the 39 context defined in rfc 4364. 41 Table of Contents 43 1 Specification of Requirements ........................ 2 44 2 Introduction ......................................... 2 45 3 RFC4364 definitions .................................. 2 46 3.1 Usage of RD value of zero ........................... 3 47 4 Full Copyright Statement ............................. 3 48 5 Intellectual Property Statement ...................... 3 49 6 IANA Considerations .................................. 4 50 7 Normative References ................................. 4 51 8 Author Information ................................... 4 53 1. Specification of Requirements 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119. 59 2. Introduction 61 This document refines the Route Distinguisher semantics detailed in 62 [RFC4364]. The Route Distinguisher consist of an 8-byte value whose 63 encoding is detailed in [RFC4364]. The Route Distinguisher is used in 64 conjunction with VPN prefixes and VPN nexthops in VPN networks to 65 solely allow one to create distinct routes to a common IPv4 address 66 prefix. 68 3. RFC4364 definitions 70 Currently in [RFC4364] section 4.3.2, the RD is used with a value of 71 0 in the next hop field of the BGP NLRI. This is a special case that 72 is allowed by the design. In section 4.2 of [RFC4364], the enconding 73 of the RD for type 0 is defines as a type field , and a value field. 74 If the type field is 0, then the value field in interpreted as 75 containing an autonomous system number (ASN), and a assigned Number 76 subfield. The ASN cannot contain 0 as it is a reserved ASN number. 78 3.1. Usage of RD value of zero 80 Whenever the RD is used within the VPN nexthop field of the BGP NLRI, 81 the RD is used with the value of 0. However whenever the RD is used 82 with VPN prefix field of the BGP NLRI , the Route Distinguisher MUST 83 never be used with the value of 0. Hence, VPN routes received with 84 the Route Distinguisher value of 0 MUST be discarded with an 85 appropriate error. 87 4. Full Copyright Statement 89 Copyright (C) The Internet Society (2006). 91 This document is subject to the rights, licenses and restrictions 92 contained in BCP 78, and except as set forth therein, the authors 93 retain all their rights. 95 This document and the information contained herein are provided on an 96 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 97 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 98 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 99 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 100 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 101 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 103 5. Intellectual Property Statement 105 The IETF takes no position regarding the validity or scope of any 106 Intellectual Property Rights or other rights that might be claimed to 107 pertain to the implementation or use of the technology described in 108 this document or the extent to which any license under such rights 109 might or might not be available; nor does it represent that it has 110 made any independent effort to identify any such rights. Information 111 on the procedures with respect to rights in RFC documents can be 112 found in BCP 78 and BCP 79. 114 Copies of IPR disclosures made to the IETF Secretariat and any 115 assurances of licenses to be made available, or the result of an 116 attempt made to obtain a general license or permission for the use of 117 such proprietary rights by implementers or users of this 118 specification can be obtained from the IETF on-line IPR repository at 119 http://www.ietf.org/ipr. 121 The IETF invites any interested party to bring to its attention any 122 copyrights, patents or patent applications, or other proprietary 123 rights that may cover technology that may be required to implement 124 this standard. Please address the information to the IETF at ietf- 125 ipr@ietf.org. 127 6. IANA Considerations 129 This document has no IANA Actions. 131 7. Normative References 133 [RFC4364]] "BGP/MPLS IP Virtual Private Networks (VPNs)" 134 E. Rosen, Y. Rekhter, RFC 4364 February 2006 136 8. Author Information 138 Luca Martini 139 Cisco Systems, Inc. 140 9155 East Nichols Avenue, Suite 400 141 Englewood, CO, 80112 142 e-mail: lmartini@cisco.com 144 Keyur Patel 145 510 McCarthy Blvd. 146 Milpitas , CA, 95035 147 e-mail: keyupate@cisco.com