idnits 2.17.1 draft-ietf-ospf-dynamic-hostname-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2009) is 5399 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) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) -- Obsolete informational reference (is this intentional?): RFC 2763 (Obsoleted by RFC 5301) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF WG S. Venkata 3 Internet-Draft Google Inc. 4 Intended status: Standards Track S. Harwani 5 Expires: January 13, 2010 C. Pignataro 6 Cisco Systems 7 D. McPherson 8 Arbor Networks, Inc. 9 July 12, 2009 11 Dynamic Hostname Exchange Mechanism for OSPF 12 draft-ietf-ospf-dynamic-hostname-05 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 13, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document defines a new OSPF Router Information (RI) TLV that 60 allows OSPF routers to flood their hostname-to-Router ID mapping 61 information across an OSPF network to provide a simple and dynamic 62 mechanism for routers running OSPF to learn about symbolic hostnames 63 just like for routers running IS-IS. This mechanism is applicable to 64 both OSPFv2 and OSPFv3. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 70 2. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Dynamic Hostname TLV . . . . . . . . . . . . . . . . . . . 6 73 3.1.1. Flooding Scope . . . . . . . . . . . . . . . . . . . . 7 74 3.1.2. Multiple OSPF Instances . . . . . . . . . . . . . . . 7 75 4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 OSPF uses a 32-bit Router ID to uniquely represent and identify a 87 node in the network. For management and operational reasons, network 88 operators need to check the status of OSPF adjacencies, entries in 89 the routing table and the content of the OSPF link state database. 90 When looking at diagnostic information, numerical representations of 91 Router IDs (e.g., dotted-decimal or hexadecimal representations) are 92 less clear to humans than symbolic names. 94 One way to overcome this problem is to define a hostname-to-Router ID 95 mapping table on a router. This mapping can be used bidirectionally 96 (e.g., to find symbolic names for Router IDs, and to find Router IDs 97 for symbolic names) or unidirectionally (e.g., to find symbolic 98 hostnames for Router IDs). Thus every router has to maintain a table 99 with mappings between router names and Router IDs. 101 These tables need to contain all names and Router IDs of all routers 102 in the network. If these mapping tables are built by static 103 definitions, it can become a manual and tedious process in 104 operational networks currently; modifying these static mapping 105 entries when additions, deletions or changes occur becomes a non- 106 scalable process very prone to error. 108 This document analyzes possible solutions to this problem (see 109 Section 2) and provides a way to populate tables by defining a new 110 OSPF Router Information TLV for OSPF, the Dynamic Hostname TLV (see 111 Section 3). This mechanism is applicable to both OSPFv2 and OSPFv3. 113 1.1. Specification of Requirements 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. Possible solutions 121 There are various approaches to providing a name-to-Router ID mapping 122 service. 124 One way to build this table of mappings is by static definitions. 125 The problem with static definitions is that the network administrator 126 needs to keep updating the mapping entries manually as the network 127 changes; this approach does not scale as the network grows, since 128 there needs to be an entry in the mapping table for each and every 129 router in the network, on every router in the network. Thus, this 130 approach greatly suffers from maintainability and scalability 131 considerations. 133 Another approach is having a centralized location where the name-to- 134 Router ID mapping can be kept. The DNS could be used for this. A 135 disadvantage with this centralized solution is that it is a single 136 point of failure; and although enhanced availability of the central 137 mapping service can be designed, it may not be able to resolve the 138 hostname in the event of reachability or network problems, which can 139 be particularly problematic in times of problem resolution. Also, 140 the response time can be an issue with the centralized solution, 141 which can be equally problematic. If the DNS is used as the 142 centralized mapping table, a network operator may desire a different 143 name mapping than the existing mapping in the DNS, or new routers may 144 not yet be in the DNS. 146 Additionally for OSPFv3, in native IPv6 deployments, the 32-bit 147 Router ID value will not map to IPv4-addressed entities in the 148 network, nor will it be DNS resolvable (see Section 4). 150 The third solution that we have defined in this document is to make 151 use of the protocol itself to carry the name-to-Router ID mapping in 152 a TLV. Routers that understand this TLV can use it to create the 153 symbolic name-to-Router ID mapping and Routers that don't understand 154 can simply ignore it. This specification provides these semantics 155 and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF 156 Router Information (RI) Link State Advertisement (LSA) ([RFC4970]). 158 3. Implementation 160 This extension makes use of the Router Information (RI) Opaque LSA 161 defined in [RFC4970] for both OSPFv2 and OSPFv3, by defining a new 162 OSPF Router Information (RI) TLV: The Dynamic Hostname TLV. 164 The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt 165 of the TLV a router may decide to ignore this TLV, or to install the 166 symbolic name and Router ID in its hostname mapping table. 168 3.1. Dynamic Hostname TLV 170 The format of Dynamic Hostname TLV is as follows: 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Hostname ... | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Type Dynamic Hostname TLV Type (TBD, see Section 6) 182 Length Total length of the hostname (value field) in octets, not 183 including the optional padding. 185 Value Hostname, a string of 1 to 255 octets, padded with zeroes to 186 4-octet alignment, encoded in the US-ASCII charset. 188 Routers that do not recognize the Dynamic Hostname TLV Type, ignore 189 the TLV (see [RFC4970]). 191 The value field identifies the symbolic hostname of the router 192 originating the LSA. This symbolic name can be the Fully Qualified 193 Domain Name (FQDN) for the Router ID, it can be a subset of the FQDN, 194 or it can be any string operators want to use for the router. The 195 use of FQDN or a subset of it is strongly recommended since it can be 196 beneficial to correlate the OSPF dynamic hostname and the DNS 197 hostname. The format of the DNS hostname is described in [RFC1035] 198 and [RFC2181]. If there is no DNS hostname for the Router ID, the 199 Router ID does not map to an IPv4-addressed entity (e.g., see 200 Section 4), or an alternate OSPF dynamic hostname naming convention 201 is desired, any string with significance in the OSPF routing domain 202 can be used. The string is not null-terminated. The Router ID of 203 this router is derived from the LSA header, in the Advertising Router 204 field of the Router Information (RI) Opaque LSA. 206 The Value field is encoded in 7-bit ASCII. If a user-interface for 207 configuring or displaying this field permits Unicode characters, that 208 user-interface is responsible for applying the ToASCII and/or 209 ToUnicode algorithm as described in [RFC3490] to achieve the correct 210 format for transmission or display. 212 The Dynamic Hostname TLV is applicable to both OSPFv2 and OSPFv3. 214 3.1.1. Flooding Scope 216 The Dynamic Hostname TLV MAY be advertised within an area-local or 217 autonomous system (AS) scope Router Information (RI) LSA. But the 218 Dynamic Hostname TLV SHOULD NOT be advertised into an area in more 219 than one RI LSA irrespective of the scope of the LSA. 221 In other words, if a router originates a Dynamic Hostname TLV with an 222 IGP domain (AS) flooding scope, it SHOULD NOT send area-scoped 223 Dynamic Hostname TLV except into any attached Not-So-Stubby Area 224 (NSSA) area(s). Similarly, if a router originates area-scoped 225 Dynamic Hostname TLV (other than NSSA area scoped), it SHOULD NOT 226 send AS-scoped Dynamic Hostname TLV. When the Dynamic Hostname TLV 227 is advertised in more than one LSA (e.g., multiple area-scoped LSAs, 228 or AS-scoped LSAs plus NSSA area-scope LSA(s)), the hostname SHOULD 229 be the same. 231 If a router is advertising any AS scope LSA (other than Dynamic TLV 232 RI LSA) such router SHOULD advertise Dynamic TLV RI LSA in AS scope. 233 Otherwise, it SHOULD advertise Dynamic TLV RI LSA in area scope. For 234 example, an AS boundary router (ASBR) SHOULD send an AS scope Dynamic 235 Hostname TLV, whereas area boundary router (ABRs) and internal 236 routers SHOULD send an area scope Dynamic Hostname TLV. 238 The flooding scope is controlled by the Opaque LSA type in OSPFv2 and 239 by the S1 and S2 bits in OSPFv3. For area scope, the Dynamic 240 Hostname TLV MUST be carried within an OSPFv2 Type 10 RI LSA or an 241 OSPFv3 RI LSA with the S1 bit set and S2 bit clear. If the flooding 242 scope is the entire routing domain (AS scope), the Dynamic Hostname 243 TLV MUST be carried within an OSPFv2 Type 11 RI LSA or OSPFv3 RI LSA 244 with the S1 bit clear and the S2 bit set. 246 3.1.2. Multiple OSPF Instances 248 When an OSPF Router Information (RI) LSA, including the Dynamic 249 Hostname TLV, is advertised in multiple OSPF instances, the hostname 250 SHOULD either be preserved, or include a common base element. It may 251 be useful for debugging or other purposes to assign separate 252 instances different hostnames with a consistent set of suffixes or 253 prefixes that can be associated with a specific instance. In 254 particular, when an instance is used for a discrete address family or 255 non-routing information. 257 4. IPv6 Considerations 259 Both OSPFv2 and OSPFv3 employ Router IDs with a common size of 32- 260 bits. In IPv4 the Router ID values were typically derived 261 automatically from an IPv4 address configured on a loopback or 262 physical interface defined on the local system, or explicitly defined 263 within the OSPF process configuration. With broader deployment of 264 IPv6, it's quite likely that OSPF networks will exist that have no 265 native IPv4 addressed interfaces. As a result, a 32-bit OSPF Router 266 ID will either need to be explicitly specified, or derived in some 267 automatic manner that avoids collisions with other OSPF routers 268 within the local routing domain. 270 Because this 32-bit value will not map to IPv4-addressed entities in 271 the network, nor will it be DNS resolvable, it is considered 272 extremely desirable from an operational perspective that some 273 mechanism exist to map OSPF Router IDs to more easily interpreted 274 values, ideally, human-readable strings. This specification enables 275 a mapping functionality which eases operational burdens that may 276 otherwise be introduced with native deployment of IPv6. 278 5. Security Considerations 280 Since the hostname-to-Router ID mapping relies on information 281 provided by the routers themselves, a misconfigured or compromised 282 router can inject false mapping information, including a duplicate 283 hostname for different Router IDs. Thus, this information needs to 284 be treated with suspicion when, for example, doing diagnostics about 285 a suspected security incident. 287 There is potential confusion from name collisions if two routers use 288 and advertise the same Dynamic Hostname. Name conflicts are not 289 crucial and therefore there is no generic conflict detection or 290 resolution mechanism in the protocol. However, a router that detects 291 that a received hostname is the same as the local one can issue a 292 notification or a management alert. 294 The use of the FQDN as OSPF dynamic hostname potentially exposes 295 geographic or other commercial information that can be deduced from 296 the hostname when sent in the clear. OSPFv3 supports confidentiality 297 via transport mode IPsec (see [RFC4552]). OSPFv2 could be operated 298 over IPsec tunnels if confidentiality is required. 300 This document raises no other new security issues for OSPF. Security 301 considerations for the base OSPF protocol are covered in [RFC2328] 302 and [RFC5340]. The use of authentication for the OSPF routing 303 protocols is encouraged. 305 6. IANA Considerations 307 IANA maintains the "OSPF Router Information (RI) TLVs" registry 308 reachable at [IANA-RI]. An additional OSPF Router Information TLV 309 Type is defined in Section 3. It is required to be assigned by IANA 310 from the Standards Action allocation range [RFC4970]. 312 Registry Name: OSPF Router Information (RI) TLVs 314 Type Value Capabilities Reference 315 ----------- -------------------------------------- --------- 316 TBD OSPF Dynamic Hostname This document 318 7. Acknowledgments 320 The authors of this document do not make any claims on the 321 originality of the ideas described. This document adapts format and 322 text from similar work done in IS-IS [RFC5301] (obsoletes [RFC2763]); 323 we would like to thank Naiming Shen and and Henk Smit, authors of 324 [RFC2763]. 326 The authors would also like to thank Acee Lindem, Abhay Roy, Anton 327 Smirnov, and Dave Ward for their valuable comments and suggestions. 329 8. References 331 8.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 337 Shaffer, "Extensions to OSPF for Advertising Optional 338 Router Capabilities", RFC 4970, July 2007. 340 8.2. Informative References 342 [IANA-RI] Internet Assigned Numbers Authority, "Open Shortest Path 343 First v2 (OSPFv2) Parameters", April 2009, 344 . 346 [RFC1035] Mockapetris, P., "Domain names - implementation and 347 specification", STD 13, RFC 1035, November 1987. 349 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 350 Specification", RFC 2181, July 1997. 352 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 354 [RFC2763] Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism 355 for IS-IS", RFC 2763, February 2000. 357 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 358 "Internationalizing Domain Names in Applications (IDNA)", 359 RFC 3490, March 2003. 361 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 362 for OSPFv3", RFC 4552, June 2006. 364 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 365 Mechanism for IS-IS", RFC 5301, October 2008. 367 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 368 for IPv6", RFC 5340, July 2008. 370 Authors' Addresses 372 Subbaiah Venkata 373 Google Inc. 375 Email: svenkata@google.com 376 URI: http://www.google.com 378 Sanjay Harwani 379 Cisco Systems 381 Email: sharwani@cisco.com 382 URI: http://www.cisco.com 384 Carlos Pignataro 385 Cisco Systems 387 Email: cpignata@cisco.com 388 URI: http://www.cisco.com 389 Danny McPherson 390 Arbor Networks, Inc. 392 Email: danny@arbor.net