idnits 2.17.1 draft-ietf-nimrod-eid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 43 instances of lines with control characters in the document. ** The abstract seems to contain references ([5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 1995) is 10387 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) == Outdated reference: A later version (-01) exists of draft-ietf-nimrod-routing-arch-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nimrod-routing-arch (ref. '1') ** Downref: Normative reference to an Informational draft: draft-ietf-nimrod-mobility (ref. '2') ** Downref: Normative reference to an Informational draft: draft-ietf-nimrod-multicast (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-spec is -01, but you're referring to -02. ** Obsolete normative reference: RFC 793 (ref. '7') (Obsoleted by RFC 9293) Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Lynn 2 Nimrod Working Group BBN Systems and Technologies 3 Expiration Date: May 1996 November 1995 4 draft-ietf-nimrod-eid-00.txt 6 Endpoint Identifier Destination Option 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress". 21 To learn the current status of any Internet-Draft, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ds.internic.net (US East Coast), 24 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 25 munnari.oz.au (Pacific Rim). 27 Please send comments on this draft to the Nimrod Working Group, 28 nimrod-wg@BBN.Com. 30 This Internet Draft expires May 1996. 32 Abstract 34 This document describes a Destination Option that is used to 35 convey topologically independent endpoint identification 36 information between source and destination endpoints in either IPv4 37 or IPv6 packets. The general format of Destination Options are 38 described in [5]. The Nimrod Routing System [1] will make use of 39 this option to convey Nimrod EIDs. 41 1 Introduction 43 Nimrod is a scalable internetwork routing architecture [1,2,3]. 44 The Nimrod architecture is designed to accommodate an internetwork 45 of arbitrary size, with heterogeneous service requirements and 46 restrictions, and to admit incremental deployment throughout an 47 internetwork. The key to Nimrod's scalability is its ability to 48 represent and manipulate routing-related information at multiple 49 levels of abstraction. 51 To do this efficiently, Nimrod separates the identification of 52 communicating entities (endpoints, or "hosts") from any topological 53 location information. Endpoint Identifiers (EIDs) are used to 54 specify and uniquely identify endpoints connected to the network. 55 Information about the topological location of an endpoint in an 56 internetwork is given by a locator. An endpoint's locator may 57 change as the network topology changes. Ongoing communication is 58 not disrupted when a locator changes since the communicating 59 endpoints are identified by their EIDs and not their locators. 61 The mapping from an endpoint name to an EID and set of locators 62 will be stored in the existing DNS system as two additional RRs [4] 63 under the Domain Name of the endpoint. This document describes how 64 the Source and Destination EIDs are communicated in IP packets 65 using the Destination Options Extension Header. 67 A Nimrod EID is a short binary identifier for an endpoint of a 68 communication (e.g., a host) and has no structure or significance 69 to the routing system other than global uniqueness. An endpoint 70 can retain the same EID forever, no matter where in the network it 71 is located. 73 2 Definition of the Endpoint Identifier Option 75 The Endpoint Identifier Option is contained in the Destinations 76 Options Extension Header (type 60) of an IPv4 or IPv6 packet. An 77 endpoint identifier may be of variable length and is not restricted 78 to the format used by Nimrod. This document specifies the encoding 79 for 8-octet Nimrod EIDs, which results in an option containing 80 twenty (20) octets. The alignment requirement for the encoding 81 specified herein is 8n. Subsequent versions of this document may 82 specify encodings for endpoint identifiers of other lengths or 83 formats. 85 Implementations are expected to verify that the Opt Data Len 86 field contains 18 and that the Src and Dst Len fields contain 8 87 when using the following encoding. 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | Option Type | Opt Data Len | Src Len | Dst Len | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 |0 0 1 0 0 | 93 +-+- Source EID -+-+ 94 | | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 |0 0 1 0 0 | 97 +-+- Destination EID -+-+ 98 | | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 Option Type 8-bit selector. The value is used for 101 the 5 least-significant bits of the Endpoint 102 Identifier Option. 104 The two most significant bits of the Option 105 Type may vary from instance to instance. The 106 value 00 should not be used. An endpoint may 107 use other values as it deems appropriate to 108 indicate whether or not an ICMP error message 109 should be returned. See [5]. 111 Since endpoint identifiers do not change en- 112 route, the third most significant bit should 113 be zero. 115 Opt Data Len 8-bit unsigned integer. The length, in 116 octets, of the endpoint identification data 117 in the Source and Destination EID fields. 119 Src Len 8-bit unsigned integer. The length, in 120 octets, of the endpoint identifier in the 121 Source EID field. 123 Dst Len 8-bit unsigned integer. The length, in 124 octets, of the endpoint identifier in the 125 Destination EID field. 127 Source EID The endpoint identifier of the source. Nimrod 128 EIDs begin with the five bits 00100. Other 129 formats may be defined in subsequent versions 130 of this document. 132 Destination EID The endpoint identifier of the destination. 133 Nimrod EIDs begin with the five bits 00100. 134 Other formats may be defined in subsequent 135 versions of this document. 137 3 Option Processing 139 The endpoint identifiers specified in the Endpoint Identifier 140 Option are used to perform demultiplexing of IP packets at the 141 transport layer. The Source EID field replaces the Source IP 142 Address, and the Destination EID replaces the Destination IP 143 Address, when identifying transport layer associations. They are 144 also used in any pseudo headers [5,6,7] that are included in 145 transport layer checksums. 147 The Endpoint Identifier Option need not appear in every packet. 148 When the communicating peers retain state information, as is the 149 case for connection oriented transports such as TCP [7], or the 150 packets are part of an IPv6 Flow [5], the endpoint identifiers 151 should be retained as part of the communication state, and thus 152 their presence in subsequent packets is optional. Note that the 153 option should not be omitted until the sending endpoint has 154 received notification from its communication peer(s) indicating 155 that they have received the identification information. For 156 example, the ACK of a TCP SYN is sufficient notification in the 157 case of TCP [7]. The endpoint identifiers are included in any 158 pseudo header even when they are not present in a given packet. 160 4 Security Considerations 162 In order to detect spoofing, packets that contain the Endpoint 163 Identifier Option should be protected by an authentication and 164 integrity mechanism. 166 5 Author's Address 168 Charles Lynn Email: CLynn@BBN.Com 169 BBN Systems and Technologies Phone: (617) 873 3367 170 10 Moulton Street 171 Cambridge, MA, 02138 173 6 References 175 [1] "The Nimrod Routing Architecture", I. Castineyra, J. N. 176 Chiappa, M. Steenstrup, draft-ietf-nimrod-routing-arch-00.txt, 177 March 1995. 179 [2] "Mobility Support for Nimrod : Requirements and Solution 180 Approaches", Ram Ramanathan, 181 draft-ietf-nimrod-mobility-01.txt, .ps, March 1995. 183 [3] "Multicast Support for Nimrod : Requirements and Solution 184 Approaches", Ram Ramanathan, 185 draft-ietf-nimrod-multicast-01.txt, .ps, March 1995. 187 [4] "DNS Resource Records for Nimrod Routing Architecture", M. A. 188 Patton, draft-ietf-nimrod-dns-01.txt, October 1995. 190 [5] "Internet Protocol, Version 6 (IPv6) Specification", S. 191 Deering, R. Hinden, draft-ietf-ipngwg-ipv6-spec-02.txt, June 192 19, 1995. 194 [6] "User Datagram Protocol", J. Postel, RFC 768, 28 August 1980. 196 [7] "TRANSMISSION CONTROL PROTOCOL", Information Sciences Institute, 197 RFC 793, September 1981.