idnits 2.17.00 (12 Aug 2021) /tmp/idnits10254/draft-iannone-openlisp-implementation-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1832. 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 : ---------------------------------------------------------------------------- == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 16 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 227: '... * RLOC MUST not be used....' RFC 2119 keyword, line 1058: '...he destination port MUST be set to the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 153 has weird spacing: '... int rlo...' == Line 580 has weird spacing: '... u_char map_v...' == Line 582 has weird spacing: '... u_char map_t...' == Line 1601 has weird spacing: '... u_char map_v...' == Line 1602 has weird spacing: '... u_char map_t...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: u_int8_t priority; /* Each RLOC has a priority. * A value of 255 means that * RLOC MUST not be used. */ u_int8_t weight; /* Each locator has a weight. * Used for load balancing * purposes when two or more * locators have the same * priority. */ u_int16_t flags; /* RLOC-related flags. */ -- 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 (July 16, 2008) is 5050 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 935 -- Looks like a reference, but probably isn't: '6' on line 929 -- Looks like a reference, but probably isn't: '0' on line 933 -- Looks like a reference, but probably isn't: '1' on line 934 -- Looks like a reference, but probably isn't: '3' on line 936 -- Looks like a reference, but probably isn't: '4' on line 937 -- Looks like a reference, but probably isn't: '5' on line 938 == Missing Reference: '-dnqtv' is mentioned on line 1344, but not defined == Missing Reference: '-n' is mentioned on line 1396, but not defined == Missing Reference: '-local' is mentioned on line 1396, but not defined == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-07 == Outdated reference: draft-iab-raws-report has been published as RFC 4984 == Outdated reference: draft-irtf-rrg-design-goals has been published as RFC 6227 == Outdated reference: draft-templin-seal has been published as RFC 5320 == Outdated reference: A later version (-05) exists of draft-van-beijnum-multi-mtu-02 Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Iannone 3 Internet-Draft D. Saucez 4 Intended status: Informational O. Bonaventure 5 Expires: January 17, 2009 UCLouvain, Belgium 6 July 16, 2008 8 OpenLISP Implementation Report 9 draft-iannone-openlisp-implementation-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 17, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The RRG is working on the design of an alternate Internet 43 Architecture in order solve issues of the current architecture 44 related to scalability, mobility, multi-homing, and inter-domain 45 routing. Among the various proposals, LISP (Locator/ID Separation 46 Protocol) is one of the most advanced. The present draft describes 47 the overall architecture of OpenLISP, an open source implementation 48 of the LISP proposal. Further, the draft contains some general 49 remarks concerning the design and the implementation of the LISP 50 protocol. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terms Definition . . . . . . . . . . . . . . . . . . . . . 3 56 2. Map Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Protocol Stack Modifications . . . . . . . . . . . . . . . . . 8 58 3.1. Incoming Packets . . . . . . . . . . . . . . . . . . . . . 8 59 3.2. Outgoing Packets . . . . . . . . . . . . . . . . . . . . . 10 60 3.3. Implementation Status . . . . . . . . . . . . . . . . . . 12 61 4. Mapping Sockets API . . . . . . . . . . . . . . . . . . . . . 14 62 4.1. An example of mapping sockets usage . . . . . . . . . . . 18 63 5. Sysctl API . . . . . . . . . . . . . . . . . . . . . . . . . . 23 64 6. LISP and OpenLISP issues . . . . . . . . . . . . . . . . . . . 24 65 6.1. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 24 66 6.2. OpenLISP and LISP variants . . . . . . . . . . . . . . . . 24 67 6.3. OpenLISP as TE-ITR/TE-ETR . . . . . . . . . . . . . . . . 24 68 6.4. OpenLISP and nonce . . . . . . . . . . . . . . . . . . . . 24 69 6.5. OpenLISP and RLOC order . . . . . . . . . . . . . . . . . 25 70 6.6. LISP Source port and statefull firewall . . . . . . . . . 26 71 6.7. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 72 6.8. MTU Management . . . . . . . . . . . . . . . . . . . . . . 27 73 6.8.1. OpenLISP local MTU Management . . . . . . . . . . . . 27 74 6.8.2. OpenLISP Extended MTU Management . . . . . . . . . . . 28 75 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 30 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 79 10.1. Reachability bits DoS . . . . . . . . . . . . . . . . . . 33 80 11. Informative References . . . . . . . . . . . . . . . . . . . . 35 81 Appendix A. Man Pages . . . . . . . . . . . . . . . . . . . . . . 36 82 A.1. map(1) . . . . . . . . . . . . . . . . . . . . . . . . . . 36 83 A.2. map(4) . . . . . . . . . . . . . . . . . . . . . . . . . . 40 84 A.3. mapstat . . . . . . . . . . . . . . . . . . . . . . . . . 44 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 86 Intellectual Property and Copyright Statements . . . . . . . . . . 47 88 1. Introduction 90 Very recent activities in the IETF and in particular in the Routing 91 Research Group (RRG) have focused on defining a new Internet 92 architecture, in order to solve issues related to scalability, 93 addressing, mobility, multi-homing, inter-domain traffic engineering 94 and routing ([I-D.iab-raws-report], [I-D.irtf-rrg-design-goals]). It 95 is widely recognized that the approach based on the separation of the 96 end-systems' addressing space (the identifiers) and the routing 97 locators' space is the way to go. This separation is meant to 98 alleviate the routing burden of the Default Free Zone (DFZ), but it 99 implies the need of distributing and storing mappings between 100 identifiers and locators on caches placed on routers and to perform 101 tunneling or address translation operation. 103 Among the various proposals presented in various RRG's meeting, LISP 104 (Locator/ID Separation Protocol), based on the map-and-encap approach 105 [I-D.farinacci-lisp], is one of the most advanced and promising 106 proposals. UC Louvain his currently developing an implementation, 107 called OpenLISP, of this protocol in the FreeBSD kernel (version 7.0 108 - [FreeBSD]). OpenLISP can be downloaded from: 109 http://inl.info.ucl.ac.be. Note that the current release refers to 110 version 07 of the LISP draft. 112 This draft describes the overall architecture of this implementation 113 and its main data structures. The draft is structured as follows. 114 We first describe the kernels' data structures created to store the 115 mappings necessary to perform encapsulation and decapsulation 116 operations. Then, we show the architectural modifications made to 117 the FreeBSD protocol stack in order to support the LISP protocol. 118 Then, we describe the new mapping sockets that have been introduced 119 in order to access the mappings from user space. This feature will 120 be useful to develop Mapping Distribution Protocols in the user 121 space. Finally, we discuss some issues related to the design and the 122 implementation of the LISP proposal. 124 1.1. Terms Definition 126 The present draft uses the terms that are originally defined in 127 [I-D.farinacci-lisp]. For terms like EID, RLOC, ITR, ETR, etc, 128 please refer to the original LISP specification. 130 2. Map Tables 132 LISP defines two different databases to store mappings between EID- 133 prefixes and RLOCs. The "LISP Cache" stores short-lived mappings in 134 an on-demand fashion when new flows start. The "LISP Database" 135 stores all the local mappings, i.e., all the mappings of the EID- 136 Prefixes behind the router. In OpenLISP we merged the two databases 137 in a single radix tree data structure [TCPIP]. This allows to have 138 an efficient indexing structure for all the EID-Prefixes that need to 139 be stored in the system. EID-Prefixes that are part of the LISP 140 Database are marked by a "local" flag, indicating that they are EID- 141 Prefixes for which the mapping is owned locally. Thus, from a 142 logical point of view the two "databases" are still separated. 143 Actually there are two radix structures in the system, one for IPv4 144 EID-Prefixes and another for IPv6 EID-Prefixes. In both map tables, 145 each entry has the format depicted in Figure 1. 147 struct mapentry { 148 struct radix_node map_nodes[2]; /* tree glue, and other values */ 150 struct sockaddr_storage *EID; /* EID value */ 152 struct locator_chain * rlocs; /* Set of locators */ 153 int rlocs_cnt; /* Number of rlocs */ 155 u_long map_flags; /* up/down?, local */ 157 }; 159 The mapentry structure 161 Figure 1 163 Besides the fields necessary to build the radix tree itself, the 164 entries contain a pointer to a socket address structure that holds 165 the EID-Prefix to which the entry is related. 167 The "map_flags" field contains general flags that apply to the whole 168 mapping. Insofar, four flags have been defined and are listed in 169 Table 1. The MAPF_UP flag just states that the mapping is usable. 170 The MAPF_LOCAL flag means that the mapping is owned locally (i.e., it 171 is part of the LISP Database). In OpenLISP, when inserting a "local" 172 mapping it is mandatory that at least one RLOC is a local address; 173 i.e., an address of one of the interfaces of the system, otherwise, 174 during insertion, the system will return EINVAL error. This is 175 because, when OpenLISP performs encapsulation, it only selects source 176 RLOCs that are addresses of the system. Doing otherwise would 177 introduce the risk of packet filtering on upstream routers if packets 178 are sent with a source address that does not belong to the system 179 performing the encapsulation operation. The MAPF_STATIC indicates 180 that the mapping has been manually added, e.g., through the map 181 utility (see Appendix A.1). The MAPF_DONE flag is used for messages 182 through mapping sockets (see Section 4). Note that in the actual 183 release of OpenLISP, both static and non-static entries are treated 184 in the same way: they need to be explicitly deleted. Future releases 185 of OpenLISP will include the possibility to introduce a timeout for 186 non-local entries. 188 +-------------+-------+---------------------------------------------+ 189 | Constant | Value | Description | 190 +-------------+-------+---------------------------------------------+ 191 | MAPF_UP | 0x1 | Mapping usable. | 192 | | | | 193 | MAPF_LOCAL | 0x2 | Mapping is local. This means that it | 194 | | | should be considered as part of the LISP | 195 | | | Database. | 196 | | | | 197 | MAPF_STATIC | 0x4 | Mapping manually added. | 198 | | | | 199 | MAPF_DONE | 0x8 | Message confirmed. | 200 +-------------+-------+---------------------------------------------+ 202 Table 1: General mapping flags 204 The other main field of the mapentry data structure is the rlocs_cnt 205 field, containing the number of RLOCs present in the mapping. These 206 RLOCs are stored in a chained list whose head is referenced by the 207 "rlocs" pointer. The list of RLOCs is always maintained ordered by 208 increasing priority values, which means that RLOCs with higher 209 priority are at the head of the list. 211 Each element of the RLOCs list is a socket address structure 212 containing the locator and an rloc_mtx structure. The latter, 213 depicted in Figure 2, contains the priority and weight parameters, 214 whose meaning and use are defined in the original LISP specification 215 (including the particular 255 value for the priority field). Note 216 that load balancing is not yet implemented in OpenLISP, thus the 217 weight is not considered during RLOC selection. Future versions of 218 OpenLISP will include load balancing and hence full support of the 219 weight parameter. Furthermore, there is also a flags field, for 220 flags that are specific to a RLOC, and a mtu field. 222 struct rloc_mtx { /* Metrics associated to the RLOC 223 */ 225 u_int8_t priority; /* Each RLOC has a priority. 226 * A value of 255 means that 227 * RLOC MUST not be used. 228 */ 229 u_int8_t weight; /* Each locator has a weight. 230 * Used for load balancing 231 * purposes when two or more 232 * locators have the same 233 * priority. 234 */ 235 u_int16_t flags; /* RLOC-related flags. 236 */ 238 u_int32_t mtu; /* MTU for the specific RLOC. 239 */ 240 }; 242 RLOCs metric data structure. 244 Figure 2 246 +-------------+-------+---------------------------------------------+ 247 | Constant | Value | Description | 248 +-------------+-------+---------------------------------------------+ 249 | RLOCF_REACH | 0x1 | RLOC Reachable. | 250 | | | | 251 | RLOCF_LIF | 0x2 | RLOC is a local address. This valid only | 252 | | | for mappings with the MAPF_LOCAL flag set. | 253 +-------------+-------+---------------------------------------------+ 255 Table 2: RLOC Specific flags 257 Concerning flags, there are only two RLOC specific flags defined 258 insofar and described in Table 2. The RLOCF_REACH flag just 259 indicates if the RLOC is reachable or not. This flag is meaningful 260 no matter if the mapping is local or not. The RLOCF_LIF flag is 261 meaningful only for local mappings and indicates if the RLOC address 262 belongs to the system. When performing encapsulation, a RLOC is 263 selected from a local mapping only if it has this flag set, it is 264 reachable, and its priority is less than 255. This in order to issue 265 packets that have a source address which belongs to the system 266 itself. 268 The "mtu" field is used to check if the size of the LISP-encapsulated 269 packet fits the MTU (Maximum Transmission Unit) of the outgoing 270 interface. OpenLISP automatically fill this field when a local 271 mapping is added. In particular, OpenLISP checks all the RLOCs of 272 the local mappings, if it is an address belonging to the system it 273 sets the RLOCF_LIF flag and copies the MTU of the interface 274 associated to the address. Note that, the check is done only upon 275 insertion, thus changes in the local address or the MTU are not 276 automatically copied in the mapping entry. For details on the use of 277 this field please refer to Section 6.8. 279 The use in OpenLISP of a chained list to store the RLOCs, allows 280 mixing IPv4 and IPv6 RLOCs. This in turn allows to use IPv6 281 tunneling for IPv4 packets and vice versa. Even more, in this way it 282 is possible, for the same EID, to perform both IPv6 and IPv4 283 tunneling depending on the RLOC eventually chosen for the 284 encapsulation. This avoids the constraint of having the tunnels 285 toward the same EID either all IPv4 or all IPv6. Even if in the 286 actual implementation status of OpenLISP, both IPv4 and IPv6 EIDs 287 mapping tables are present, and both IPv4 and IPv6 RLOCs can be 288 introduced without limitation on the EID address family, the 289 encapsulation and decapsulation operation are implemented only for 290 IPv4, as long as the map and mapstat utility (see Appendix A.1 and 291 Appendix A.3). Future releases of OpenLISP will support IPv6 292 encapsulation. 294 3. Protocol Stack Modifications 296 Compared to the original protocol stack implementation of the FreeBSD 297 OS ([TCPIP], [FreeBSD]) four main modules have been added, namely 298 lisp_input(), lisp6_input(), lisp_output(), and lisp6_output(). As 299 should be clear from the names, the first two modules manage incoming 300 IPv4 and IPv6 LISP packets, while the last two modules are 301 responsible for outgoing IPv4 and IPv6 LISP packets. To describe the 302 global architecture, we use the same module representation as in 303 [TCPIP] and show how packets are processed inside the protocol stack. 305 3.1. Incoming Packets 307 The lisp_input() and lisp6_input() modules are positioned right above 308 respectively the ip_input() and ip6_input() modules, from which they 309 are called, as depicted in Figure 3. 311 Let us for simplicity assume that an IPv4 LISP packet is received by 312 the system. The packet will be first treated by the ip_input() 313 module. The ip_input() module has been patched in order to recognize 314 LISP packets. The patch consists simply to divert towards 315 lisp_input(), all incoming UDP packets destined to the local machine 316 and having destination port number set to the LISP reserved value 317 4341 (for encapsulated data packets). If the UDP packet has not such 318 a port number it is delivered as usual to the transport layer (i.e., 319 udp_input()). In the case of an encapsulated data packet (port 320 number 4341), the module strips the UDP header and then it treats the 321 reachability bits and the nonce of the LISP specific header. 323 OpenLISP checks all of the reachability bits and updates reachability 324 information in the map tables. While performing such an update a 325 consistency check is performed. In particular, the number of 326 reachability blocks (32 bits) present in the packet is compared to 327 the number of reachability blocks present in the matching mapping 328 entry, if different the packet is dropped for bad LISP encapsulation 329 and a message is sent through open mapping sockets (see Section 4). 331 Protocol Stack Modifications for incoming packets. 333 +------------------------>+--------+ 334 | | | 335 +-----+<-------------------------+ | | 336 | | | | | | 337 | +---------------+ +---------------+ | 338 | | | | | | 339 | | lisp_input() | | lisp6_input() | | 340 | | | | | | 341 | |_______________| |_______________| | 342 | ^ ^ | 343 | | | | 344 | | | | 345 | | | | 346 | | (Transport Layer) | | 347 | | ^ ^ | | 348 | | | | | | 349 | | / \ | | 350 | | / \ | | 351 | | / \ | | 352 | +--------------+ +---------------+ | 353 | | | | | | 354 | | ip_input() | | ip6_input() | | 355 | | | | | | 356 | |______________| |_______________| | 357 | ^ ^ | 358 +-------->| |<----------+ 359 | / 360 \ / 361 \ / 362 \ / 363 \ / 364 (Data Link Layer) 366 Figure 3 368 The same action is triggered if the number of reachability bits that 369 are set in the blocks differs from what expected. For instance, let 370 us assume the stored mapping contains two (2) RLOCs and the incoming 371 packets contains three (3) reachability bits set, this should never 372 happen, thus the packet is discarded and a message is sent through 373 open mapping sockets, in order to inform possible existing mapping 374 management processes. Note that a mismatch in the number of 375 reachability bits can be discovered only if they are set to 376 reachable. If everything matches, but some reachability bits have 377 changed, they are updated in the mapping and a message is sent 378 through open mapping sockets to notify this change. Note that this 379 last message is not a an error message, but just a notification 380 message, necessary to notify possible mapping management processes in 381 the user space about the reachability change. 383 After having performed these operations, the IP header of the 384 remaining packet is checked in order to decide to which module to 385 deliver the packet. In practice this means to re-inject the packet 386 in the IP protocol stack, by putting it in the input buffer either of 387 the ip_input() or the ip6_input() module. 389 In the case of an IPv6 LISP packet the overall process is the same. 390 The packet is first received by ip6_input(), where if the packet is a 391 locally destined UDP packet with destination port number equal to the 392 LISP reserved 4341 value it is delivered to lisp6_input(). The 393 latter module performs the same operations as lisp_input(), with the 394 only difference that it is specialized in treating IPv6 headers. If 395 the packet is a data packet, depending on the address family of the 396 inner header, once decapsulated it is re-injected either in the input 397 buffer of the ip_input() module or the input buffer of ip6_input() 398 module. 400 Once the packet is re-injected in the protocol stack, in both IPv4 401 and IPv6 cases, the packet follows the normal process. This means 402 that if the decapsulated packet is not destined to the local host it 403 will be first delivered to the forwarding module (ip_forward() or 404 ip6_forward()) that will in turn deliver it to the output module 405 (ip_output() or ip6_output()) in order to send it down to the data 406 link layer and transmit it toward its final destination. These last 407 actions are driven by the content of the routing table of the system. 409 3.2. Outgoing Packets 411 The lisp_output() and lisp6_output() modules are positioned right 412 above respectively the ip_output() and ip6_output() modules, from 413 which they are called, as depicted in Figure 4. 415 Protocol Stack Modifications for outgoing packets. 417 +-----+ +-------+ 418 | | | | 419 | V V | 420 | +---------------+ +---------------+ | 421 | | | | | | 422 | | lisp_output() | | lisp6_output()| | 423 | | | | | | 424 | |_______________| |_______________| | 425 | | | | | | 426 | | +--------------------+ | | 427 | | | | | | 428 | | +-------------------+ | | | 429 | | | | | | 430 | | | | | | 431 | | | | | | 432 | | | (Transport Layer) | | | 433 | | | / \ | | | 434 | | | / \ | | | 435 | V V V V V V | 436 | +--------------+ +---------------+ | 437 | | | | | | 438 | | ip_output() | | ip6_output() | | 439 | | | | | | 440 | |______________| |_______________| | 441 | | | | | | 442 +-----+ | | +------+ 443 \ / 444 \ / 445 V V 446 (Data Link Layer) 448 Figure 4 450 Let us for simplicity assume that an IPv4 is received by the 451 ip_output() module, coming either from the ip_forward() module or the 452 transport layer (i.e., either tcp_output() or udp_output()). Note 453 that we refer to a normal IPv4 packet, not a LISP encapsulated 454 packet. The ip_output() module has been patched in order to 455 recognize if the packet needs to be encapsulated with a LISP header. 456 The patch consists in first checking if there is a valid mapping in 457 the LISP database. This means to perform a search in the map table 458 using the source address (source EID) of the packet. If the lookup 459 returns an entry with the MAPF_LOCAL flag set (recall Section 2), 460 then a second lookup is performed in order to find a mapping for the 461 destination EID. 463 If there is no mapping available a message is sent through open 464 mapping sockets in order to notify the cache miss. This is needed in 465 order to trigger a mapping lookup, i.e., to send a Map-Request, by 466 the Mapping Distribution Protocol. Since there is no mapping 467 available the packet is not encapsulated. It is normally treated by 468 the IP layer, which means that if the destination EID is routable and 469 a route exist in the IP routing table it is forwarded without being 470 encapsulated. Otherwise the IP layer will drop it. 472 If a mapping for the destination EID is present, the packet is 473 diverted toward the lisp_output() module. The lisp_output(), will 474 first perform MTUs checks (see Section 6.8.1), then it prepends to 475 the packet the LISP header (i.e. reach bits and nonce). Final step 476 is to prepend a new IP + UDP header using selected RLOCs. The 477 destination RLOC is selected using the policy described in the 478 original LISP specification. The source RLOC is chosen in a slightly 479 more restrictive way, as described in Section 2. 481 Subsequently the packet is sent again to the IP layer in order to 482 ship it to the data-link layer. This does not mean that the packet 483 is delivered to ip_output(). Indeed, the mapping for the destination 484 address can have an IPv6 RLOC as a first element of the list of 485 locators, meaning that the prepended header is IPv6+UDP and that the 486 packet is delivered to the ip6_output() module. Note that the new 487 LISP encapsulated packet cannot be recursively encapsulated. Indeed, 488 the mbuf containing the packet is tagged with a new M_TAG_LISP tag, 489 which avoids to re-perform encapsulation check by performing lookups 490 on the map tables. This allows to reduce computational overhead 491 while protecting against bad setups generating loops where a packet 492 is recursively encapsulated until it is dropped due to MTU checks. 494 In the case of an outgoing IPv6 packet the overall process is the 495 same. The packet, if a mapping exists for the source EID, is first 496 diverted toward lisp6_output(), which prepends the correct headers to 497 the packet and, depending of the RLOC used, delivers the packet 498 either to the ip_output() module or the ip6_output() module. 500 Once the packet is re-injected in the protocol stack, in both IPv4 501 and IPv6 cases, the packet follows the normal process. This means 502 that the encapsulated packet will be delivered to the data-link 503 layer. 505 3.3. Implementation Status 507 In the current public release of OpenLISP, only the modules 508 lisp_input() and lisp_output() are present. Thus only IPv4 509 encapsulation/decapsulation operations are supported. Future 510 releases will include encapsulation/decapsulation support for IPv6. 512 Similarly, the gleaning mechanism is not yet supported. Thus, 513 OpenLISP is not able to generate and manage Data-Probe packets. 515 4. Mapping Sockets API 517 In line with the UNIX philosophy and to give the possibility for 518 future Mapping Distribution Systems running in the user space to 519 access the kernel's map tables a new type of socket, namely the 520 "mapping sockets", has been defined. 522 Mapping sockets are based on raw sockets in the new AF_MAP domain and 523 are very similar to the well known routing sockets ([TCPIP], 524 [NetProg].) A mapping socket is easily created in the following way: 526 #include 527 #include 528 #include 529 #include 530 #include 532 int s = socket(PF_MAP, SOCK_RAW, 0); 534 Note that is the header file containing all the 535 useful data structures and definitions. 537 Once a process has created a mapping socket, it can perform the 538 following operations by sending messages across it: 540 MAPM_ADD: used to add a mapping. The process writes the new mapping 541 to the kernel and reads the result of the operation on the same 542 socket. 544 MAPM_DELETE: used to delete a mapping. It works in the same way as 545 MAPM_ADD. 547 MAPM_GET: used to retrieve a mapping. The process writes on the 548 socket the request of a mapping for a specific EID and reads on 549 the same socket the result of the query. 551 The messages sent across mapping socket for the above operations all 552 use the same data structure, namely map_msghdr{}, depicted in 553 Figure 6. 555 The field map_type can be set only to the type listed above. The 556 fields map_msglen, map_version, map_pid, map_seq, and map_errno have 557 the same meaning and are used in the same way as for the rt_msghdr{} 558 structure for routing sockets. Details about these fields and their 559 use can be found in [TCPIP]. The map_flags field is used to set some 560 general flags that concern the whole mapping entry or the message. 561 The possible values are listed in Table 1 along with their meaning in 562 Section 2. The only value that was not described in Section 2 is the 563 MAPF_DONE flag. This particular flag is set by the kernel and just 564 state that the operation requested has been performed successfully. 565 Note that all of the messages are returned by the kernel and copies 566 are sent to all interested listeners (open mapping sockets). A 567 process may avoid the expense of reading replies to its own messages 568 by issuing a setsockopt(2) call indicating that the SO_USELOOPBACK 569 option at the SOL_SOCKET level is to be turned off. A process may 570 ignore all messages from the mapping socket by doing a shutdown(2) 571 system call for further input. 573 Mapping Message Header. 575 struct map_msghdr { /* From maptables.h 576 */ 577 u_short map_msglen; /* to skip over non-understood 578 * messages 579 */ 580 u_char map_version; /* future binary compatibility 581 */ 582 u_char map_type; /* message type */ 583 int map_flags; /* flags, incl. kern & message, 584 * e.g. DONE 585 */ 586 int map_addrs; /* bitmask identifying sockaddrs 587 * in msg 588 */ 589 int map_rloc_count; /* Number of rlocs appended to 590 the msg */ 591 pid_t map_pid; /* identify sender 592 */ 593 int map_seq; /* for sender to identify action 594 */ 595 int map_errno; /* why failed 596 */ 597 }; 599 Figure 6 601 When trying to install a new mapping, the OpenLISP code can return 602 the following error codes if something goes wrong: 604 ENOBUFS: If insufficient resources were available to install a new 605 mapping. 607 EEXIST: If the EID-Prefix already exists in the mapping table. 609 EINVAL: This error code can be returned in two cases. The first 610 case is when the list of RLOC provided for a mapping contains 611 replicated addresses. The second case is when a "local" mapping 612 is provided without any RLOC (address) belonging to the system. 613 Note the OpenLISP does not support Negative Mapping Entries. 615 As can be noted, the use of the MAPF_LOCAL flag allows to use the 616 mapping socket API for mappings in both the LISP Database and LISP 617 Cache. As explained in Section 2, they are merged in the radix data 618 structure in order to have an efficient lookup mechanism for all 619 possible EIDs. 621 The OpenLISP kernel code can trigger some messages to be sent through 622 the mapping sockets if some particular events take place. The 623 messages triggered by the kernel are the following: 625 MAPM_MISS: a lookup operation has generated a miss (mapping not 626 present). This message is generated when a LISP encapsulated 627 packet is received, but no mapping exists, in the map tables, 628 for the source EID. 630 MAPM_BADREACH: a LISP encapsulated packet has been received but the 631 reachability bits do not match existing mapping. This message 632 informs possible existing mapping distribution systems in the 633 user space that a non recoverable mismatch has been detected 634 between the reachability bits in the header of a LISP 635 encapsulated packet and what expected from the mapping present 636 in the map tables. Details on this case can be found in 637 Section 3.1. 639 MAPM_REACH: reachability bits have changed. This message informs 640 possible existing mapping distribution systems in the user space 641 that reachability bits in an existing mapping have changed due 642 to the reception of an LISP encapsulated packet. 644 Note that the above messages contain the EID for which the message 645 has been triggered. On the one hand, this allows interested existing 646 mapping distribution systems, in case of a MAPM_REACH message, to 647 retrieve the updated mapping by means of a MAPM_GET message. On the 648 other hand, for both MAPM_REACH and MAPM_BADREACH messages, the 649 mapping distribution system in the user space can issue a Map-Request 650 message in order to either ask confirmation of the change to the 651 mapping owner or to obtain a fresh mapping. 653 The complete list of possible mapping sockets messages and their type 654 values are summarized in Table 3. 656 +---------------+-------+-------------------------------------+ 657 | Constant | Value | Description | 658 +---------------+-------+-------------------------------------+ 659 | MAPM_ADD | 0x01 | Add Map. | 660 | | | | 661 | MAPM_DELETE | 0x02 | Delete Map. | 662 | | | | 663 | MAPM_GET | 0x04 | Returns mapping for a specific EID. | 664 | | | | 665 | MAPM_MISS | 0x05 | Lookup Failed. | 666 | | | | 667 | MAPM_BADREACH | 0x06 | Reachability Bits Problem. | 668 | | | | 669 | MAPM_REACH | 0x07 | Reachability Bits Changed. | 670 +---------------+-------+-------------------------------------+ 672 Table 3: Mapping Socket Message Types 674 +--------------+-------+--------------------------------------------+ 675 | Constant | Value | Description | 676 +--------------+-------+--------------------------------------------+ 677 | MAPA_EID | 0x1 | EID socket address present. | 678 | | | | 679 | MAPA_EIDMASK | 0x2 | EID netmask socket address present. | 680 | | | | 681 | MAPA_RLOC | 0x4 | At least one RLOC is present. The exact | 682 | | | number of RLOCs can be found in the | 683 | | | map_rloc_count field. | 684 +--------------+-------+--------------------------------------------+ 686 Table 4: Data structure bitmask 688 The map_addrs field is a bitmask identifying the nature and number of 689 data structures present in the message right after the header. The 690 possible values and related descriptions can be found in Table 4. 692 The map_addrs field does not contain exactly all the data structures, 693 in particular, for RLOCs, a bit just states if at least one RLOC is 694 present. The exact number of RLOCs present is contained in the 695 map_rloc_count field. While EID and its mask, if present, are simple 696 socket address structures, an RLOC is composed of a socket address 697 structure followed by an rloc_mtx structure containing the metrics of 698 that specific RLOC. The rloc_mtx data structure has been described 699 in Section 2, and is depicted in Figure 2 with a description of each 700 metric. 702 4.1. An example of mapping sockets usage 704 Hereafter is described an example using mapping sockets. Along with 705 the code in the kernel, a small utility called "map" has been 706 written. This utility has similar functionalities to the "route" 707 utility present in UNIX systems. It allows to manually manage map 708 tables. The complete man page of the map utility can be found in 709 Appendix A.1. 711 Assuming we want to retrieve the mapping for the EID 10.0.0.1, we can 712 type: 714 freebsd% map get -inet 10.0.0.1 716 The map utility first builds a buffer containing a map_msghdr{} 717 structure, followed by a socket address structure containing the EID 718 for the kernel to look up, as depicted in Figure 8. The map_type is 719 set to MAPM_GET and the map_addrs is set to MAPA_EID. The entire 720 buffer is written to a mapping socket previously open. 722 Data sent to the kernel across mapping socket for MAP_GET command. 724 +-----------------------+ 725 | | 726 | map_msghdr{} | 727 | | 728 | | 729 | map_type = MAP_GET | 730 |_______________________| 731 | | 732 | EID | 733 | Socket | 734 | Address | 735 | Structure | 736 |_______________________| 738 Figure 8 740 Afterwards, map reads from the socket the reply of the kernel. 741 Assuming that the kernel has a mapping for 10.0.0.0/16 associated to 742 two locators, the kernel will reply with a message which has the 743 format depicted in Figure 9. 745 Data sent from the kernel across mapping socket for MAP_GET command. 747 +-----------------------+ 748 | | 749 | map_msghdr{} | 750 | | 751 | | 752 | map_type = MAP_GET | 753 | | 754 | map_rloc_count = 2 | 755 |_______________________| 756 | | 757 | EID | 758 | Socket | 759 | Address | 760 | Structure | 761 |_______________________| 762 | | 763 | EID Netmask | 764 | Socket | 765 | Address | 766 | Structure | 767 |_______________________| 768 | | 769 | RLOC 1 | 770 | Socket | 771 | Address | 772 | Structure | 773 |_______________________| 774 | | 775 | RLOC 1 | 776 | rlocs_mtx | 777 | Structure | 778 |_______________________| 779 | | 780 | RLOC 2 | 781 | Socket | 782 | Address | 783 | Structure | 784 |_______________________| 785 | | 786 | RLOC 2 | 787 | rlocs_mtx | 788 | Structure | 789 |_______________________| 791 Figure 9 793 The first part of the message is a map_msghdr{} structure, with the 794 map_type unchanged, the map_addrs set to 0x07, which is equivalent to 795 MAPA_EID, MAPA_EIDMASK, and MAPA_RLOC all set, and finally the 796 map_rloc_count set to 2. Right after the map_msghdr{} there is a 797 first socket address structure containing the EID prefix, which is 798 10.0.0.0 in this example. The second socket address structure 799 contains the netmask, 255.255.0.0 in this case. The third socket 800 address structure contains the first RLOC. RLOCs are returned 801 ordered by increasing priority. After the first RLOC there is an 802 rloc_mtx structure containing the metrics associated to the first 803 RLOC. The message ends with the socket address structure for the 804 second RLOC and the rloc_mtx structure for its metrics. 806 When using the map utility a possible output for the get request for 807 EID 10.0.0.1 can be: 809 freebsd% map get -inet 10.0.0.1 810 Mapping for EID: 10.0.0.1 811 EID: 10.0.0.0 812 EID mask: 255.255.0.0 813 RLOC Addr: inet6 2001::1 P 1 W 100 Flags R MTU 0 814 RLOC Addr: inet 10.1.0.0 P 2 W 100 Flags MTU 0 815 flags: 817 The above output is of straightforward reading. The requested lookup 818 for EID 10.0.0.1 matches the entry with EID address 10.0.0.0 and EID 819 mask 255.255.0.0 (/16). Note that since the map tables are radix 820 trees, the longest prefix match is always returned. The mapping 821 contains two (2) RLOCs. The first is the IPv6 RLOC 2001::1, having 822 priority equal to 1, weight equal to 100, the R flag indicates that 823 the RLOC is reachable, the MTU equal to 0 just states that no MTU is 824 actually set. The second RLOC, is the IPv4 RLOC 10.1.0.0, having 825 priority equal to 2, weight equal to 100, it has no flags, thus it is 826 not reachable, and the MTU is not set. 828 Using the map utility, the command line to set the above-described 829 mapping is: 831 freebsd% map add -inet 10.0.0.0/16 -inet6 2001::1 1 100 1 832 -inet 10.1.0.0 2 100 0 834 Further examples of the map utility can be found in Appendix A.1. A 835 useful exercise in order to get familiar with the content of mapping 836 socket messages is to run the map utility in "monitor" mode in one 837 terminal, by typing: 839 freebsd% map monitor 841 while modifying the mapping tables using the map utility in another 842 terminal. The monitor mode of the map utility just dumps all the 843 messages going through mapping sockets. 845 Along with the map utility the "mapstat" utility is provided with 846 OpenLISP. Mapstat is a modification of the netstat utility, already 847 present on FreeBSD, able to provide LISP specific information. In 848 particular a new "-X" option has been added in order to obtain a dump 849 of the map tables. Referring to the mapping previously described, 850 the result of the mapstat utility would be: 852 freebsd% mapstat -X 853 Mapping tables 855 Internet: 856 EID Flags Refs # RLOC(s) 857 10.0.0.0/16 US 1 1 2001::1 1 100 R 0 34 858 2 10.1.0.0 2 100 0 43 860 The dump shows how only the 10.0/16 mapping is present in the map 861 tables. The general flags show that the mapping is up ("U") and 862 static "S", one reference exists to this mapping. Then there are the 863 RLOCs. The information for the two RLOCs is the same like for the 864 get command of the map utility, except for two differences. The 865 first difference is the "#" column, which shows the position of the 866 RLOC in the chained list of RLOCs. Second difference is the last 867 value of the line: it expresses the number of time the RLOC has been 868 selected for an encapsulation operation. 870 Along with the "-X" option, mapstat can show LISP-related network 871 status. Where applies, mapstat accepts also the word "lisp" as 872 protocol. As an example the following command: 874 freebsd% mapstat -sf inet -p lisp 876 will give the following result: 878 freebsd% mapstat -sf inet -p lisp 879 lisp: 880 0 datagrams received 881 0 with incomplete header 882 0 with bad encap header 883 0 with bad data length field 884 0 delivered 885 0 datagrams output 886 0 dropped on output 887 0 sent 889 The first five (5) counters concern incoming LISP encapsulated 890 packets. In particular, the first counter gives the total number of 891 LISP encapsulated packets received by the system. The following 892 three gives the number of LISP encapsulated received packets dropped 893 due to header problems or data length field problem. The fifth 894 counter expresses the total number of packets correctly decapsulated 895 and handed back to the IP layer. 897 The remaining three (3) counters concern packet received by the 898 OpenLISP module which have a mapping for both source and destination 899 EID and thus need to be encapsulated. The first of these three 900 counters expresses the total packets received for encapsulation by 901 the OpenLISP module. The second counter gives the number of packet 902 dropped due to error conditions. The last counter gives the total 903 number of LISP encapsulated packets that have been correctly sent. 905 For further information on the mapstat utility please refer to 906 Appendix A.3 908 5. Sysctl API 910 OpenLISP offer the possibility to mapping distribution system in the 911 user space to obtain a complete dump of the map tables through 912 sequence of mapping messages. This is done by using a sysctl system 913 call in the CTL_NET level. For details on the general sysctl API and 914 its levels, in the FreeBSD systems, please refer to sysctl(3) man 915 page. With OpenLISP is possible to use AF_MAP as second level and 916 NET_MAPTBL_DUMP as fifth level. The sequence of messages returned by 917 the system call is the same described in Section 4. 919 An example of sysctl usage to obtain a map tables' dump is the 920 following: 922 #include 923 #include 924 #include 925 #include 926 #include 927 #include 929 int mib[6]; 930 size_t spaceneeded; 931 char * buffer; 933 mib[0] = CTL_NET; 934 mib[1] = PF_MAP; 935 mib[2] = 0; 936 mib[3] = 0; 937 mib[4] = NET_MAPTBL_DUMP; 938 mib[5] = 0; 940 if (sysctl(mib, 6, NULL, &spaceneeded, NULL, 0) < 0) 941 /* code for error handling */ 943 if ((buffer = malloc(needed)) == NULL) 944 /* code for error handling */ 946 if (sysctl(mib, 6, buffer, &needed, NULL, 0) < 0) 947 /* code for error handling */ 949 At the end of this code, the memory buffer referenced by the "buffer" 950 pointer will contain a contiguous sequence of mapping messages, all 951 of them starting with the map_msghdr{} data structure, thus it can be 952 easily parsed. 954 6. LISP and OpenLISP issues 956 In this section, we briefly discuss several of the protocol/ 957 implementations issues/status related to OpenLISP and LISP. 959 6.1. Multicast 961 OpenLISP has no support for multicast. Future release of OpenLISP 962 may introduce support for it. 964 6.2. OpenLISP and LISP variants 966 OpenLISP does not implement any EID filtering policy, while adopting 967 a fallback strategy for encapsulation. This means that packets for 968 which there is no mapping available are handed back to the IP layer 969 for "traditional" processing. If the original packet has a non- 970 routable destination address it will be dropped, otherwise, if a 971 route is available, it will be forwarded. This means that OpenLISP 972 is able, with the correct mappings to support all variants of LISP 973 described in [I-D.farinacci-lisp]. 975 6.3. OpenLISP as TE-ITR/TE-ETR 977 The lack of EID filtering policies in OpenLISP allows it to be used 978 as also as TE-ITR/TE-ETR. The correct functioning is just a matter 979 of putting the correct mappings in the map tables. Nevertheless, 980 note that recursive encapsulation cannot be done on the same machine. 981 In order to avoid inner loops (see Section 3.2), each packet once 982 encapsulated is tagged and never checked again for further 983 encapsulation. 985 6.4. OpenLISP and nonce 987 The original proposal of LISP includes a "nonce" value to be included 988 in every LISP encapsulated packet. Formal definition is: 990 LISP Nonce: is a 32-bit value that is randomly generated by an ITR. 991 It is used to test route-returnability when an ETR echoes back 992 the nonce in a Map-Reply message. 994 In the current OpenLISP implementation, the nonce is generated and 995 put in the LISP header, but its value is never checked on reception 996 of a LISP encapsulated packet. This is because the current release 997 of OpenLISP does not support Map-Reply packets. Nevertheless, this 998 let us think that marking every packet with a nonce is not strictly 999 necessary, rather it introduces useless overhead. Moreover, the 1000 random generation of the nonce can be also expensive in terms of 1001 encapsulation operation performances. 1003 In order to reduce the overhead it would be desirable to avoid 1004 putting the nonce in normal LISP encapsulated packets. Nonce can be 1005 introduced in packets that really need the value present, which are 1006 easy to recognize. 1008 Indeed, a Map-Reply message is sent only in two cases: 1010 1 To reply to an explicit Map-Request message. 1012 2 In the case of the gleaning mechanism, to reply to a Data-Probe 1013 packet. 1015 In the first case, messages are generated in the user space using as 1016 port number the IANA reserved value 4342. In this case, it is easy 1017 to recognize LISP signaling packets (Map-Request and Map-Reply) since 1018 they use destination port 4342, and thus nonce value can be handled. 1020 In the second case, the Data-Probe should contain the nonce value in 1021 order to provide the value that needs to be returned by the 1022 subsequent Data-Reply. Data-Probe packets use destination port 4341, 1023 the same as normal LISP encapsulated data packets. However, Data- 1024 Probe packets are easily recognizable by the fact that the inner IP 1025 header and outer IP header contain the same destination address. 1026 Thus nonce can be correctly handled. 1028 To summarize, the suggestion here is to avoid in general the nonce in 1029 normal LISP encapsulated packets, while use it in Data-Probe, Map- 1030 Request, and Map-Reply packets, which are easy to recognize. This 1031 means to split the packets' format in two main types: with and 1032 without nonce. This would allow reducing overhead in both terms of 1033 bandwidth and efficiency in the encap/decap operations. 1035 6.5. OpenLISP and RLOC order 1037 The LISP specification clearly state that RLOCs are ordered by 1038 priority, however, it does not clarify what happens in the case of 1039 multiple RLOCs having the same priority value. The ordering of RLOC 1040 is very important since it is used in the reachability bits. 1042 OpenLISP uses the simple approach of considering the IP address of 1043 RLOCs (in network byte order) as an integer value and puts smaller 1044 values before bigger ones. When RLOCs belong to different address 1045 family, i.e., IPv4 and IPv6, IPv4 (AF_INET) address family is given 1046 priority. Since in OpenLISP duplicated RLOCs for the same EID-Prefix 1047 are not allowed this gives a strict ordering to the list of RLOCs. 1049 6.6. LISP Source port and statefull firewall 1051 During our tests with OpenLISP, we observed packet losses on high 1052 load traffic on a network protected by an IPFW statefull firewall. 1053 These packet losses were caused by the utilization of random UDP 1054 source ports for LISP packets. In [I-D.farinacci-lisp], Section 5.3, 1055 there is the following statement: 1057 UDP Header: contains a random source port allocated by the ITR when 1058 encapsulating a packet. The destination port MUST be set to the 1059 well-known IANA assigned port value 4341. 1061 This can be interpreted in two ways: 1063 o In each packet we put a random source port number. This has 1064 proved not to work well with the "keep-state" directive of IPFW. 1065 Loss of packets has been observed on high load traffic on a 1066 network protected by an IPFW statefull firewall. On statefull 1067 firewall, a state is kept for each flow, which is identified by 1068 source and destination IP addresses and source and destination 1069 port number. In presence of many different flows (due to random 1070 source port selection), the number of cached tuples (Source IP, 1071 Destination IP, Source Port, Source Destination, Protocol) can 1072 fill the firewall cache and block any new flow for a period of at 1073 least the time an entry remains in the firewall state. The random 1074 selection of UDP source ports caused a kind of DoS attack against 1075 the state maintained by the statefull firewall. 1077 o For the first packet to a certain RLOC we select a port number and 1078 use it as long as the mapping is valid. This is not much 1079 meaningful, since LISP never uses the source port for a reply or 1080 something else, thus this state is wasteful. 1082 For the above reasons, in OpenLISP, the LISPDATA (4341) port number 1083 is used for source port for all LISP encapsulated packets. 1085 6.7. ICMP 1087 In LISP, it is not possible to find the actual source of a packet 1088 responsible of an ICMP if it occurs during the transit (i.e., when 1089 the packet is encapsulated in a LISP message). 1091 The problem comes from the encapsulation. The returned ICMP message 1092 has sufficient space only to include the outer header, thus the one 1093 containing RLOCs as source and destination addresses. In this way it 1094 is not possible to forward the packet to the source of the original 1095 packet, since it is not possible to retrieve the original source EID. 1096 Even performing a lookup on the LISP database, using the source RLOC 1097 as search key, the result will be an EID-Prefix, not sufficient to 1098 forward the packet. 1100 A solution would be to increase the size of ICMP messages in order to 1101 include the inner header of the LISP encapsulated packet. This would 1102 allow to retrieve the correct information in order to forward the 1103 packet. Note, however, that before forwarding the ICMP packet needs 1104 to be cleaned from LISP specific information, since end-system are 1105 supposed to be unaware of being behind a LISP router. On the one 1106 hand, this proposition seems to be the efficient, but needs to modify 1107 ICMP and thus non-LISP routers. On the other hand, many routers that 1108 do not generate ICMP messages, or rate limit them, in the DFZ, thus 1109 reducing the real effectiveness of the solution. 1111 For the above mentioned reasons, OpenLISP does not implement any 1112 technique that allows the router to make a link between the LISP 1113 packet header the packet source in order to "translate" and re-route 1114 ICMP packets. 1116 The general ICMP problem in LISP can however be the pretext of a more 1117 philosophical discussion. Indeed, as LISP is a tunneling technique 1118 based on the separation of ID and locator space, is it required to 1119 send information about what happens between the RLOCs to the client 1120 running behind a LISP router? In principle the answer is no, since 1121 end-systems do not need to be aware of the routing infrastructure 1122 (i.e., the RLOC space). In this case LISP has to handle ICMP in a 1123 different way that needs to be explored. 1125 6.8. MTU Management 1127 In the present section we describe how OpenLISP deals with the MTU 1128 issue inside the local domain, and how this approach can be easily 1129 extended to solve the issue on an Internet scale, without modifying 1130 existing ICMP massages. 1132 6.8.1. OpenLISP local MTU Management 1134 During preliminary tests, we observed that the MTU issue is at the 1135 origin of many problems. OpenLISP does not (and will not) implement 1136 the fragmentation mechanism proposed in Sec. 5.4 of 1137 [I-D.farinacci-lisp]. The reason is because the proposed method 1138 sounds very primitive and does not appear to be efficient. The 1139 original LISP specification is based on an architectural constant 1140 used by the xTR to limit the MTU of LISP encapsulated packets. 1141 OpenLISP uses a more advanced solution, based on the real MTU of the 1142 local RLOCs present on the xTR, as described below. 1144 Currently OpenLISP manages the MTU issue in the following manner. As 1145 described in Section 2 for each local mapping, OpenLISP discovers the 1146 RLOCs that are local interfaces and copies the MTU associated to the 1147 interface to the RLOC entry. When a packet needs to be encapsulated 1148 the first step is to calculate the final packet size and compare it 1149 to the MTU contained in the source RLOC used. If the size exceeds 1150 the MTU the action taken depends on the origin of the packet. If the 1151 packet has been locally generated through a socket in the user space, 1152 the write operation on the socket will return an EMSGSIZE error. If 1153 the packet has been originated elsewhere, an ICMP Too Big message is 1154 sent back to the source address of the original packet. Note that 1155 this can be done since the size check is done before actually 1156 encapsulating the packet. 1158 6.8.2. OpenLISP Extended MTU Management 1160 The way OpenLISP manages MTU solves the problem only for the local 1161 domain and the first hop after the ITR. It does not yet solve the 1162 issue of having an ICMP Too Big message generated in the middle of 1163 the LISP tunnel. A possible solution could be the enlargement of the 1164 ICMP Too Big message, as described in Section 6.7. 1166 Another possible solution is to start using the mtu field in the 1167 rloc_mtx structure also for non-local mappings. In the current 1168 OpenLISP implementation, the mtu field for RLOCs of non-local mapping 1169 are set to zero (0), which means to ignore it. If an ICMP Too Big 1170 Message is triggered in the middle of a LISP tunnel, it will normally 1171 reach the ITR that has performed the encapsulation and its content is 1172 sufficient to retrieve the destination RLOC toward which the packet 1173 was sent. This in turns allows setting a MTU on the RLOC of the 1174 mapping entry containing it. This would allow perform a check on the 1175 subsequent packets before encapsulating them, and if necessary, to 1176 send an ICMP Too Big message back to the real source of the packet. 1178 From an architectural perspective, the proposed approach is very 1179 simple. Nevertheless, a limitation can be found in the fact that the 1180 approach suffers from some delay. Indeed, for an ICMP Too Big 1181 message to reach the original packet source, two large packets are 1182 needed. The first packet will trigger an ICMP message in the LISP 1183 tunnel, thus updating the ITR. Only the second packet will trigger 1184 an ICMP message from the ITR to the source, making the latter shrink 1185 its path MTU. However, this solution still needs to be carefully 1186 explored, since a burst of large packets must not have the results of 1187 generating a burst of ICMP messages reducing too much the MTU size on 1188 the ITR. A simple rate limitation approach can help in alleviating 1189 this problem. 1191 A second limitation of this approach can be found in the fact that in 1192 order to rapidly update the mapping when an ICMP Too Big message is 1193 received from a LISP tunnel, an RLOC-based lookup should be 1194 performed. In the current state of OpenLISP, this is not possible, 1195 since the mapping tables are radix trees using EIDs as key. On the 1196 other hand, RLOC-based lookup will not be that common (compared to 1197 the number of EID-based lookups), the trade-off between lookup 1198 efficiency and data structure complexity needs to be further 1199 explored. 1201 Note, finally, that MTU discovery between RLOCs can be also performed 1202 using proposals like [I-D.templin-seal] or 1203 [I-D.van-beijnum-multi-mtu], and adapting them in order to put the 1204 correct value in the mtu field associated to RLOCs in the OpenLISP 1205 implementation. Such an adaptation is out of the scope of OpenLISP, 1206 even if worth to be explored. 1208 7. Conclusion 1210 The present memo describes the overall architecture and the 1211 implementation status of OpenLISP, an implementation of the LISP 1212 proposal in the FreeBSD OS. OpenLISP provides support for encap/ 1213 decap operations and EID-to-RLOC mappings storage in the kernel 1214 space. OpenLISP is freely available at http://inl.info.ucl.ac.be. 1216 OpenLISP can work as both a router and end-host, thus providing a 1217 wide range of test scenarios. We think that the mapping sockets 1218 introduced by OpenLISP is a great tool for easy development of 1219 Mapping Distribution Protocols in the user space. People working in 1220 this area can contact authors. We believe that a complete working 1221 system composed by OpenLISP and a mapping distribution protocol would 1222 provide very helpful insights, leading to important improvements for 1223 both OpenLISP and the mapping distribution protocol. 1225 8. Acknowledgements 1227 The work described in the present memo has been partially supported 1228 by the European Commission within the IST AGAVE Project and a Cisco 1229 URP grant. 1231 9. IANA Considerations 1233 This memo includes no request to IANA. 1235 10. Security Considerations 1237 The present memo does not introduce any new security issue that is 1238 not already mentioned in [I-D.farinacci-lisp] and 1239 [I-D.bagnulo-lisp-threat]. Nevertheless, we discuss hereafter some 1240 issues related to the reachability bits. 1242 10.1. Reachability bits DoS 1244 An attacker can deactivate a particular RLOC on a mapping of an ITR 1245 with a single packet using the reachability bits. If the 1246 reachability bit of a RLOC is set to one, the RLOC is reachable, 1247 otherwise it is unreachable. 1249 Since reachability information on specific RLOCs can be modified by 1250 the reachability bits in the LISP header carried by data packets and 1251 not a control protocol, it is possible for an attacker to make a DoS 1252 on a EID by sending a single packet for that EID where all the 1253 reachability bits are at set to zero. To succeed the attack, it is 1254 not required to have a bi-directional flow, the only constraint is to 1255 build a LISP packet, for an EID mapping present in the ITR, with as 1256 source EID the one that is meant to be made unreachable and a 1257 correctly formed LISP header having reachability bits all set to 1258 zero. Once the packet has been received, all RLOCs will be set to 1259 unreachable, and the ITR will not be able to reach the EID used as 1260 source, until another packet (not spoofed) will set again the RLOCs 1261 to a reachable state. 1263 To tackle this issue two solutions are available: 1265 o Keep the reachability bits semantic, but add a confirmation phase 1266 to be sure the RLOC must be deactivated. When a reachability bit 1267 has changed compared to the mapping present in the cache, a Map- 1268 Request should be sent in order to obtain the new mapping with the 1269 correct reachabilty information. In OpenLISP, this can be easily 1270 implemented, since for any reachability change, a message is sent 1271 through the mapping sockets in order to inform the mapping 1272 distribution system, which in turn will perform the request. 1274 o Change the reachability bits semantic to become a version number. 1275 Instead of carrying reachability information for each RLOC, the 1276 bits contain the version number of the mapping. If the version 1277 number changes for an EID, a mapping request is sent. 1279 The two solutions are not "bulletproof", however, they can help in 1280 removing, or at least reducing, DoS attacks. Nevertheless, a control 1281 on the rate of Map-Request is needed in order to avoid DoS attacks on 1282 the mapping system. The solution based on version number is more 1283 DoS-proof as the attacker must be able to know the version number to 1284 launch the attack. If the version number is not near the real 1285 version number, the message can be considered as invalid. 1287 11. Informative References 1289 [FreeBSD] The FreeBSD Project, "FreeBSD, the power to serve", 1290 . 1292 [I-D.bagnulo-lisp-threat] 1293 Bagnulo, M., "Preliminary LISP Threat Analysis", 1294 draft-bagnulo-lisp-threat-01 (work in progress), 1295 July 2007. 1297 [I-D.farinacci-lisp] 1298 Farinacci, D., Fuller, V., Oran, D., and D. Meyer, 1299 "Locator/ID Separation Protocol (LISP)", 1300 draft-farinacci-lisp-07 (work in progress), April 2008. 1302 [I-D.iab-raws-report] 1303 Meyer, D., "Report from the IAB Workshop on Routing and 1304 Addressing", draft-iab-raws-report-02 (work in progress), 1305 April 2007. 1307 [I-D.irtf-rrg-design-goals] 1308 Li, T., "Design Goals for Scalable Internet Routing", 1309 draft-irtf-rrg-design-goals-01 (work in progress), 1310 July 2007. 1312 [I-D.templin-seal] 1313 Templin, F., "The Subnetwork Encapsulation and Adaptation 1314 Layer (SEAL)", draft-templin-seal-22 (work in progress), 1315 June 2008. 1317 [I-D.van-beijnum-multi-mtu] 1318 Beijnum, I., "Extensions for Multi-MTU Subnets", 1319 draft-van-beijnum-multi-mtu-02 (work in progress), 1320 February 2008. 1322 [NetProg] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network 1323 Programming, The Sockets Networking API.", Addison-Wesley 1324 Professional Computing Series Volume 1 - Third Edition, 1325 2004. 1327 [TCPIP] Wright, G. and W. Stevens, "TCP/IP Illustrated Volume 2, 1328 The Implementation.", Addison-Wesley 1329 Professional Computing Series, 1995. 1331 Appendix A. Man Pages 1333 The following sections contain the manpages that can be obtained on a 1334 FreeBSD system once OpenLISP has been completely installed. 1336 A.1. map(1) 1338 MAP(1) BSD General Commands Manual MAP(1) 1340 NAME 1341 map -- manually manipulate the LISP mappings 1343 SYNOPSIS 1344 map [-dnqtv] command [[modifiers] args] 1346 DESCRIPTION 1347 The map utility is used to manually manipulate the network mapping 1348 tables (both cache and database). Only the super-user may modify 1349 the mapping tables. It normally is not needed, as a system mapping 1350 table management daemon, such as LISP-ALT, should tend to this 1351 task. 1353 The map utility supports a limited number of general options, but 1354 a rich command language, enabling the user to specify any 1355 arbitrary request that could be delivered via the programmatic 1356 interface discussed in map(4). 1358 The following options are available: 1360 -d Run in debug-only mode, i.e., do not actually modify 1361 the routing table. 1363 -n Bypass attempts to print host and network names 1364 symbolically when reporting actions. (The process of 1365 translating between symbolic names and numerical 1366 equivalents can be quite time consuming, and may require 1367 correct operation of the network; thus it may be 1368 expedient to forget this, especially when attempting to 1369 repair networking operations). 1371 -v (verbose) Print additional details. 1373 -q Suppress all output from the add, change, and delete 1374 commands. 1376 The map utility provides five commands: 1378 add Add a mapping. 1379 delete Delete a specific mapping. 1380 get Lookup and display the mapping for an EID. 1381 monitor Continuously report any changes to the mapping 1382 information base, mapping lookup misses, etc. 1383 flush Remove all mappings. This includes mappings from both 1384 the cache and the database. 1386 The monitor command has the syntax: 1388 map [-n] monitor 1390 The flush command has the syntax: 1392 map [-n] flush 1394 The other commands have the following syntax: 1396 map [-n] command [-local] [-inet | -inet6] EID 1397 [-inet | -inet6] RLOC [Priority [Weight [Rechability]]] 1399 where EID is the address of the EID-Prefix (it can be also a full 1400 address), -local indicates if the mapping should be treated as 1401 part of the local mapping database or as part of the cache. 1402 Default is cache. The keyword -inet and -inet6 are not optional, 1403 they must be used before any address (both EID and RLOC). 1404 These keywords indicate if the following address should be 1405 treated as an IPv4 or IPv6 address/prefix. RLOC is the address of 1406 the RLOC argument. Likewise the EID, it must be preceded by 1407 -inet or -inet6 keyword in order to indicate the address family. 1408 The EID must be specified in the net/bits format. For example, 1409 -inet 128.32 is interpreted as -inet 128.0.0.32; -inet 128.32.130 1410 is interpreted as -inet 128.32.0.130; and -inet 192.168.64/20 is 1411 interpreted as the network prefix 192.168.64.0 with netmask 1412 255.255.240.0. 1414 The values Priority, Weight, and Reachability are optional to 1415 declare. 1416 If not declared, the following default values are set: 1417 Priority 255 (Not usable) 1418 Weight 100 1419 Reachability 1420 0 (not reachable) 1422 It is not mandatory to declare all of them, but when declaring 1423 one, all the previous must be also declared. This means that to 1424 declare a weight the priority must also be declared; and to set 1425 the reachability to 1 (reachable) both priority and weight must be 1426 declared. 1428 Mappings have associated flags that influence operation. These 1429 flags may be set (or sometimes cleared) by indicating the 1430 following corresponding modifiers: 1432 -static MAPF_STATIC - manually added mapping (default) 1433 -nostatic ~MAPF_STATIC - pretend mapping added by kernel or 1434 daemon 1436 All symbolic names specified for an EID or RLOC are looked up first 1437 as a host name using gethostbyname(3). If this lookup fails, 1438 getnetbyname(3) is then used to interpret the name as that of a 1439 network. 1441 The map utility uses a mapping socket and the message types 1442 MAPM_ADD, MAPM_DELETE, MAPM_GET, and MAPM_CHANGE. The flush 1443 command is performed using the sysctl(3) interface. As such, only 1444 the super-user may modify the mapping tables. 1446 EXAMPLES 1447 The command to add a mapping, in the LISP database, for EID 1448 1.1.0.0/16, having RLOC 2.2.2.2 and Priority 1, Weight 100, and 1449 marked as Reachable, is: 1451 map add -local -inet 1.1.0.0/16 -inet 2.2.2.2 1 100 1 1453 The command to delete the same mapping is: 1455 map delete -inet 1.1.0.0 1457 To add in the cache a mapping having several RLOCs, the command 1458 is: 1460 map add -inet 1.1.0.0/16 -inet 2.2.2.2 1 100 1 -inet 3.3.3.3 1461 2 100 1 1463 -inet 4.4.4.4 3 100 -inet 5.5.5.5 1465 The above command associate to the EID-Prefix 1.1.0.0/16 the 1466 following RLOCs and related Priority, Weight, and Reachability 1467 values: 1469 RLOC Priority Weight Reachability 1470 2.2.2.2 1 100 Reachable 1471 3.3.3.3 2 100 Reachable 1472 4.4.4.4 3 100 Unreachable 1473 5.5.5.5 255 100 Unreachable 1475 EXIT STATUS 1476 The map utility exits 0 on success, and >0 if an error occurs. 1478 SEE ALSO 1479 netintro(4), map(4), mapstat(1), 1481 L. Iannone and O. Bonaventure, OpenLISP Implementation Report, 1482 draft-iannone-openlisp-implementation-01.txt. 1484 D. Farinacci, V. Fuller, D. Oran, and D. Meyer, Locator/ID 1485 Separation protocol (LISP), draft-farinacci-lisp-07.txt. 1487 NOTE 1488 Please send any bug report or code contribution to the authors 1489 of OpenLISP. 1491 AUTHORS 1492 Luigi Iannone 1494 HISTORY 1495 The map utility appeared in FreeBSD 7.0. 1497 BSD July 15, 2008 BSD 1498 A.2. map(4) 1500 MAP(4) BSD Kernel Interfaces Manual MAP(4) 1502 NAME 1503 map -- kernel LISP mapping cache and database 1505 SYNOPSIS 1506 #include 1507 #include 1508 #include 1509 #include 1510 #include 1512 int 1513 socket(PF_MAP, SOCK_RAW, int family); 1515 DESCRIPTION 1516 OpenLISP provides some mapping facilities into the kernel of 1517 FreeBSD. The kernel maintains a mapping information database, 1518 which is used in selecting the appropriate RLOCs when 1519 transmitting/forwarding packets. 1521 A user process (or possibly multiple co-operating processes) 1522 maintains this database by sending messages over a special kind 1523 of socket. Mapping table changes may only be carried out by the 1524 super user. 1526 The operating system may spontaneously emit mapping messages in 1527 response to external events, such as receipt of a packet for 1528 which no mapping is available. The message types are described 1529 in greater detail below. 1531 When handling a packet, the kernel will attempt to find the most 1532 specific EID mappings matching the source and the destination 1533 addresses. If there is more then one RLOC in the mapping the 1534 actual RLOC used for encapsulation is chosen following the 1535 rules described in (LISP). Note, however, that for local 1536 mappings, i.e., mappings that are part of the database, the flag 1537 "i" must be set in order for the RLOC to be used. This is to 1538 avoid to emit packets with a source address that does not belong 1539 to the machine. If no mapping is found, for both source and 1540 destination EIDs, packet is handed back to normal IP operation, 1541 which may lead to sending the packet, if the EID is routable and 1542 a route is available in the IP routing table. 1544 One opens the channel for passing mapping control messages by 1545 using the socket call. There can be more than one routing socket 1546 open per system. 1548 Messages are formed by a header followed by a number of sockaddrs 1549 (of variable length depending on the address family) and RLOC 1550 metrics data structure. 1552 Any messages sent to the kernel are returned, and copies are sent 1553 to all interested listeners. The kernel will provide the process 1554 ID for the sender, and the sender may use an additional sequence 1555 field to distinguish between outstanding messages. 1556 However, message replies may be lost when kernel buffers are 1557 exhausted. 1559 The kernel may reject certain messages, and will indicate this by 1560 filling in the map_errno field. The OpenLISP code returns the 1561 following error codes if new mappings cannot be installed: 1563 ENOBUFS: If insufficient resources were available to install a new 1564 mapping. 1566 EEXIST: If the EID-Prefix already exist in the mapping table. 1568 EINVAL: This error code can be returned in two cases. The first 1569 case is when the list of RLOC provided for a mapping 1570 contains replicated addresses. The second case is when a 1571 "local" mapping is provided without any RLOC (address) 1572 belonging to the system. 1574 A process may avoid the expense of reading replies to its own 1575 messages by issuing a setsockopt(2) call indicating that the 1576 SO_USELOOPBACK option at the SOL_SOCKET level is to be turned off. 1577 A process may ignore all messages from the mapping socket by doing 1578 a shutdown(2) system call for further input. 1580 If a mapping is in use when it is deleted, the entry will be 1581 marked down and removed from the mapping table, but the resources 1582 associated with it will not be reclaimed until all references to 1583 it are released. User processes can obtain information about the 1584 mapping entry for a specific EID by using a MAP_GET message. 1586 Messages include: 1588 #define MAPM_ADD 0x1 /* Add Map */ 1589 #define MAPM_DELETE 0x2 /* Delete Map */ 1590 #define MAPM_CHANGE 0x3 /* Change Metrics or flags */ 1591 #define MAPM_GET 0x4 /* Report Metrics */ 1592 #define MAPM_MISS 0x5 /* Lookup Failed */ 1593 #define MAPM_BADREACH 0x6 /* Reachability Block Problem */ 1594 #define MAPM_REACH 0x7 /* Reachability Block Changed */ 1596 A message header consists of the following: 1598 struct map_msghdr { 1599 u_short map_msglen; /* to skip over non-understood 1600 messages */ 1601 u_char map_version; /* future binary compatibility */ 1602 u_char map_type; /* message type */ 1604 int map_flags; /* flags, incl. kern & message, 1605 e.g. DONE */ 1606 int map_addrs; /* bitmask identifying sockaddrs 1607 in msg */ 1608 int map_rloc_count; /* Number of rlocs appended to 1609 the msg */ 1610 pid_t map_pid; /* identify sender */ 1611 int map_seq; /* for sender to identify action 1612 */ 1613 int map_errno; /* why failed */ 1615 }; 1617 The ``int map_flags'' is as defined as: 1619 #define MAPF_UP 0x1 /* mapping usable */ 1620 #define MAPF_LOCAL 0x2 /* Mapping is local 1621 * This means that it should be 1622 * considered 1623 * as part of the LISP Database 1624 */ 1625 #define MAPF_STATIC 0x4 /* manually added */ 1626 #define MAPF_DONE 0x8 /* message confirmed */ 1628 Specifiers for which addresses are present in the messages are: 1630 #define MAPA_EID 0x1 /* EID sockaddr present */ 1631 #define MAPA_EIDMASK 0x2 /* netmask sockaddr present */ 1632 #define MAPA_RLOC 0x4 /* Locator present */ 1634 If MAPA_RLOC is set, it means that there are "int map_rloc_count" 1635 pairs of "struct sockaddr" and "struct rloc_mtx" present. 1637 The ``struct rloc_mtx'' is as defined as: 1639 struct rloc_mtx { /* Metrics associated to the RLOC 1640 * Usefull for messages mapping 1641 * sockets. 1642 */ 1643 u_int8_t priority; /* Each RLOC has a priority. 1644 */ 1645 u_int8_t weight; /* Each locator has a weight. 1646 */ 1647 u_int16_t flags; /* Flags concerning specific RLOC. 1648 */ 1649 u_int32_t mtu; /* MTU for the specific RLOC. 1650 */ 1651 }; 1653 The ``u_int16_t flags'' is as defined as: 1655 #define RLOCF_REACH 0x01 /* RLOC Reachable. */ 1656 #define RLOCF_LIF 0x02 /* RLOC is a local interface. 1657 * This is only valid for local 1658 * mappings. 1659 */ 1661 A good example of how top use mapping sockets can be found in 1662 /usr/src/sbin/map/map.c. 1664 SEE Also 1665 map(1), mapstat(1). 1667 L. Iannone and O. Bonaventure, OpenLISP Implementation Report, 1668 draft-iannone-openlisp-implementation-00.txt. 1670 D. Farinacci, V. Fuller, D. Oran, and D. Meyer, Locator/ID 1671 Separation protocol (LISP), draft-farinacci-lisp-07.txt. 1673 NOTE 1674 The MAPM_CHANGE message is not yet implemented. 1676 Please send any bug report or code contribution to the authors of 1677 OpenLISP. 1679 AUTHORS 1680 Luigi Iannone 1682 HISTORY 1683 A PF_MAP protocol family has been introduced with OpenLISP on 1684 FreeBSD 7.0. 1686 BSD July 15, 2008 BSD 1688 A.3. mapstat 1690 MAPSTAT(1) BSD General Commands Manual MAPSTAT(1) 1692 NAME 1693 mapstat -- Modification of the netstat(1) utility to show 1694 LISP-related network status 1696 DESCRIPTION 1697 The mapstat command symbolically displays the contents of various 1698 network-related data structures. It is a modification of the 1699 existing netstat command, thus it basically offers the same 1700 identical features and can be used in the same identical way. 1701 Please refer to netstat(1) for more information on the normal 1702 use of netstat. 1704 What mapstat introduces is that fact that it can show LISP-related 1705 network status. Where applies, mapstat accepts also the word 1706 "lisp" as protocol. Try the following command as an example: 1708 mapstat -sf inet -p lisp 1710 The mapstat adds the new following option: 1712 -X Displays the content of mapping tables. The mapping table 1713 display indicates the available mappings and their status. 1715 Each mapping consists of an EID, flags related to the whole 1716 mapping, references, and the list of RLOC. For each RLOC there is 1717 the address, its priority, its weight, and the flags related to 1718 that specific RLOC. It also shows the available MTU (Maximum 1719 Transmission Unit) for the specific RLOC, and the number of times 1720 that the RLOC has been selected for packet encapsulation. 1722 The flags field shows a collection of information about the 1723 mapping or the RLOC stored as binary choices. The individual flags 1724 are the listed hereafter. 1726 General flags 1728 U The mapping entry is "up" and usable. 1730 L The mapping entry "local", i.e., it is part of the lisp 1731 mapping database as defined in the original LISP 1732 proposal. 1734 S The mapping entry is "static", i.e., it has been 1735 manually added. 1737 RLOC specific flags 1739 R The specific RLOC is reachable. 1741 i The specific RLOC is a local interface. This flag can 1742 be set only for mappings that are part of the database, 1743 i.e., have the flag "L" set. 1745 SEE ALSO 1746 netstat(1), map(1), map(4) 1748 NOTE 1749 Please send any bug report or code contribution to the authors of 1750 OpenLISP. 1752 AUTHORS 1753 Luigi Iannone 1755 HISTORY 1756 The mapstat utility appeared in FreeBSD 7.0. 1758 BUGS 1759 The code is still exprimental. Some combinations of the -X option 1760 with other native options of netstat may not work or produce 1761 unexpected results. 1763 BSD July 15, 2008 BSD 1765 Authors' Addresses 1767 Luigi Iannone 1768 UCLouvain, Belgium 1769 Place St. Barbe 2 1770 Louvain la Neuve, B-1348 1771 Belgium 1773 Email: luigi.iannone@uclouvain.be 1774 URI: http://inl.info.ucl.ac.be 1776 Damien Saucez 1777 UCLouvain, Belgium 1778 Place St. Barbe 2 1779 Louvain la Neuve, B-1348 1780 Belgium 1782 Email: damien.saucez@uclouvain.be 1783 URI: http://inl.info.ucl.ac.be 1785 Olivier Bonaventure 1786 UCLouvain, Belgium 1787 Place St. Barbe 2 1788 Louvain la Neuve, B-1348 1789 Belgium 1791 Email: Olivier.Bonaventure@uclouvain.be 1792 URI: http://inl.info.ucl.ac.be 1794 Full Copyright Statement 1796 Copyright (C) The IETF Trust (2008). 1798 This document is subject to the rights, licenses and restrictions 1799 contained in BCP 78, and except as set forth therein, the authors 1800 retain all their rights. 1802 This document and the information contained herein are provided on an 1803 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1804 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1805 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1806 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1807 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1808 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1810 Intellectual Property 1812 The IETF takes no position regarding the validity or scope of any 1813 Intellectual Property Rights or other rights that might be claimed to 1814 pertain to the implementation or use of the technology described in 1815 this document or the extent to which any license under such rights 1816 might or might not be available; nor does it represent that it has 1817 made any independent effort to identify any such rights. Information 1818 on the procedures with respect to rights in RFC documents can be 1819 found in BCP 78 and BCP 79. 1821 Copies of IPR disclosures made to the IETF Secretariat and any 1822 assurances of licenses to be made available, or the result of an 1823 attempt made to obtain a general license or permission for the use of 1824 such proprietary rights by implementers or users of this 1825 specification can be obtained from the IETF on-line IPR repository at 1826 http://www.ietf.org/ipr. 1828 The IETF invites any interested party to bring to its attention any 1829 copyrights, patents or patent applications, or other proprietary 1830 rights that may cover technology that may be required to implement 1831 this standard. Please address the information to the IETF at 1832 ietf-ipr@ietf.org. 1834 Acknowledgment 1836 Funding for the RFC Editor function is provided by the IETF 1837 Administrative Support Activity (IASA).