idnits 2.17.00 (12 Aug 2021) /tmp/idnits5441/draft-hinden-ipv6-global-local-addr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 68, but not defined == Missing Reference: 'ADDRARCH' is mentioned on line 262, but not defined == Unused Reference: 'RFC2026' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 531, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GLOBAL' ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5DIG') ** Obsolete normative reference: RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. 'POPUL' ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2462 (ref. 'ADDAUTO') (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCP6' ** Obsolete normative reference: RFC 3484 (ref. 'ADDSEL') (Obsoleted by RFC 6724) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 June 11, 2003 Brian Haberman, Caspian 4 Globally Unique IPv6 Local Unicast Addresses 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the list Internet-Draft Shadow Directories, see 22 http://www.ietf.org/shadow.html. 24 This internet draft expires on December 16, 2003. 26 Abstract 28 This document defines an unicast address format that is globally 29 unique and is intended for local communications, usually inside of a 30 site. They are not expected to be routable on the global Internet 31 given current routing technology. 33 1.0 Introduction 35 This document defines an IPv6 unicast address format that is globally 36 unique and is intended for local communications [IPV6]. They are not 37 expected to be routable on the global Internet given current routing 38 technology. They are routable inside of a more limited area such as 39 a site. They may also be routed between a limited set of sites. 41 Globally unique IPv6 local addresses have the following 42 characteristics: 44 - Globally unique prefix. 45 - Well known prefix to allow for easy filtering at site 46 boundaries. 47 - Allows sites to be combined or privately interconnected without 48 creating any address conflicts or require renumbering of 49 interfaces using these prefixes. 50 - Internet Service Provider independent and can be used for 51 communications inside of a site without having any permanent or 52 intermittent Internet connectivity. 53 - If accidentally leaked outside of a site via routing or DNS, 54 there is no conflict with any other addresses. 55 - In practice, applications may treat these address like global 56 scoped addresses. 57 - These addresses are also candidates for end-to-end use in some 58 classes of multihoming solutions. 60 This document defines the format of Globally Unique IPv6 Local 61 addresses, how to allocate them, and usage considerations including 62 routing, site border routers, DNS, application support, VPN usage, 63 and guidelines for how to use for local communication inside a site. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC 2119]. 69 2.0 Acknowledgments 71 The underlying idea of creating globally unique IPv6 local addresses 72 describe in this document been proposed a number of times by a 73 variety of people. The authors of this draft does not claim 74 exclusive credit. Credit goes to Brian Carpenter, Christian Huitema, 75 Aidan Williams, Andrew White, Michel Py, Charlie Perkins, and many 76 others. The authors would also like to thank Brian Carpenter, 77 Charlie Perkins, Harald Alvestrand, Keith Moore, Margaret Wasserman, 78 and Michel Py for their comments and suggestions on this draft. 80 3.0 Globally Unique IPv6 Local Unicast Addresses 82 3.1 Format 84 The globally unique IPv6 local addresses are created using a 85 centrally allocated global ID. They have the following format: 87 | n | 88 | bits | m bits | 16 bits | 64 bits | 89 +--------+------------+-----------+-----------------------------+ 90 | prefix | global ID | subnet ID | interface ID | 91 +--------+------------+-----------+-----------------------------+ 93 Where: 95 prefix prefix to identify Globally Unique IPv6 Local 96 unicast addresses. 98 global ID global identifier used to create a globally 99 unique prefix. See section 3.2 for additional 100 information. 102 subnet ID 16-bit subnet ID is an identifier of a subnet 103 within the site. 105 interface ID 64-bit IID as defined in [ADDARCH]. 107 There are a range of choices available when choosing the size of the 108 prefix and Global ID field length. There is a direct tradeoff 109 between having a Global ID field large enough to support foreseeable 110 future growth and not using too much of the IPv6 address space 111 needlessly. A reasonable way of evaluating a specific field length 112 is to compare it to a projected 2050 world population of 9.3 billion 113 [POPUL] to compare the number of resulting /48 prefixes per person. 114 A range of prefix choices is shown in the following table: 116 Prefix Global ID Number /48 Prefixes % of IPv6 117 Length Prefixes per Person Address Space 119 /11 37 137,438,953,472 15 0.049% 120 /10 38 274,877,906,944 30 0.098% 121 /9 39 549,755,813,888 59 0.195% 122 /8 40 1,099,511,627,776 118 0.391% 123 /7 41 2,199,023,255,552 236 0.781% 124 /6 42 4,398,046,511,104 473 1.563% 126 A very high utilization ratio of these allocations can be assumed 127 because no internal structure is required in the field nor is there 128 any reason to be able to aggregate the prefixes. 130 The authors believes that a /7 prefix resulting in a 41 bit Global ID 131 is a good choice. It provides for a large number of assignments 132 (i.e., 2.2 trillion) and at the same time uses less than .8% of the 133 total IPv6 address space. It is unlikely that this space will be 134 exhausted. If more than this was needed, then additional IPv6 135 address space could be allocated for this purpose. 137 For the rest of this document the FC00::/7 prefix and a 41-bit Global 138 ID is used. 140 3.2 Global ID 142 The allocation of global IDs should be pseudo-random [RANDOM]. They 143 should not be assigned sequentially or with well known numbers. This 144 to ensure that there is not any relationship between allocations and 145 to help clarify that these prefixes are not intended to be routed 146 globally. Specifically, these prefixes are designed to not 147 aggregate. 149 There are two ways to allocate Global IDs. These are centrally by a 150 allocation authority and locally by the site. The Global ID is split 151 into two parts for each type of allocation. The prefixes for each 152 type are: 154 FC00::/8 Centrally assigned 155 FD00::/8 Locally assigned 157 Each results in a 40-bit space to allocate. 159 Two assignment methods are included because they have different 160 properties. The centrally assigned global IDs have a much higher 161 probability that they are unique and the assignments can be escrowed 162 to resolve any disputes regarding duplicate assignments. The local 163 assignments are free and do not need any central coordination or 164 assignment, but have a lower (but still adequate) probability of 165 being unique. It is expected that large managed sites will prefer 166 central assignments and small or disconnected sites will prefer local 167 assignments. Sites are free to choice either approach. 169 3.2.1 Centrally Assigned Global IDs 171 Centrally assigned global IDs MUST be generated with a pseudo-random 172 algorithm consistent with [RANDOM]. They should not be assigned 173 sequentially or by locality. This to ensure that there is not any 174 relationship between allocations and to help clarify that these 175 prefixes are not intended to be routed globally. Specifically, these 176 prefixes are designed to not aggregate. 178 Global IDs should be assigned centrally by a single allocation 179 authority because they are pseudo-random and without any structure. 180 This is easiest to accomplish if there is a single source of the 181 assignments. 183 The requirements for centrally assigned global ID allocations are: 185 - Available to anyone in an unbiased manner. 186 - Permanent with no periodic fees. 187 - One time non-refundable allocation fee in the order of 10 Euros 188 per allocation. 189 - The ownership of each individual allocation should be private, 190 but should be escrowed. 192 The allocation authority should permit allocations to be obtained 193 without having any sort of internet connectivity. For example in 194 addition to web based registration they should support some methods 195 like telephone, postal mail, fax, telex, etc. They should also 196 accept a variety of payment methods and currencies. 198 The reason for the one time 10 Euro charge for each prefix is to 199 provide a barrier to any hoarding of the these allocations but at the 200 same time keep the cost low enough to not create a barrier to anyone 201 needing one. The charge is non-refundable in order to keep overhead 202 low. 204 The ownership of the allocations is not needed to be public since the 205 resulting addresses are intended to be used for local communication. 206 It is escrowed to insure there are no duplicate allocations and in 207 case it is needed in the future (e.g., to resolve duplicate 208 allocation disputes). 210 An example of a allocation authority is a non-profit organization 211 such as the Public Internet Registry (PIR) that the Internet Society 212 has created to manage the .org domain. They already know how to 213 collect small sums efficiently and there are safeguards in place for 214 the appropriate use of any excess revenue generated. 216 Note, there are many possible ways of of creating an allocation 217 authority. It is important to keep in mind when reviewing 218 alternatives that the goal is to pick one that can do the job. It 219 doesn't have to be perfect, only good enough to do the job at hand. 220 The authors believe that PIR shows that this requirement can be 221 satisfied, but this draft does not specifically recommend the choice 222 of PIR. 224 3.2.2 Locally Assigned Global IDs 226 Global IDs can also be generated locally by an individual site. This 227 makes it easy to get a prefix with out the need to contact an 228 assignment authority or internet service provider. There is not as 229 high a degree of assurance that the prefix will not conflict with 230 another locally generated prefix, but the likelihood of conflict is 231 small. Sites that are not comfortable with this degree of 232 uncertainty should use a centrally assigned global ID. 234 Locally assigned global IDs MUST be generated with a pseudo-random 235 algorithm consistent with [RANDOM]. Section 3.2.3 describes a 236 suggested algorithm. It is important to insure a reasonable 237 likelihood uniqueness that all sites generating a Global IDs use a 238 functionally similar algorithm. 240 3.2.3 Sample Code for Pseudo-Random Global ID Algorithm 242 The algorithm described below is intended to be used for centrally 243 and locally assigned Global IDs. In each case the resulting global 244 ID will be used in the appropriate prefix as defined in section 3.2. 246 1) Obtain the current time of day in 64-bit NTP format [NTP]. 247 2) Obtain the birth date of the person running the algorithm (or 248 one of his/her descendants or ancestors) in 64-bit NTP format. 249 3) Concatenate the time of day with the birth date resulting in a 250 128-bit value (i.e., TOD, Birthday). 251 4) Compute an MD5 digest on the 128-bit value as specified in 252 [MD5DIG]. 253 5) Use the least significant 40 bits as the Global ID. 255 This algorithm will result in a global ID that is reasonably unique 256 and can be used as a Global ID. 258 3.3 Scope Definition 260 By default, the scope of these addresses is global. That is, they 261 are not limited by ambiguity like the site-local addresses defined in 262 [ADDRARCH]. Rather, these prefixes are globally unique, and as such, 263 their applicability exceeds the current site-local addresses. Their 264 limitation is in the routability of the prefixes, which is limited to 265 a site and any explicit routing agreements with other sites to 266 propagate them. Also, unlike site-locals, these prefixes can overlap 268 4.0 Routing 270 Globally IPv6 Local address are designed to be routed inside of a 271 site in the same manner as other types of unicast addresses. They 272 can be carried in any IPv6 routing protocol without any change. 274 It is expected that they would share the same subnet IDs with 275 provider based global unicast addresses if they were being used 276 concurrently [GLOBAL]. 278 Any routing protocol that is used between sites is required to filter 279 out any incoming or outgoing globally unique IPv6 local routes. The 280 exception to this is if specific /48 globally unique IPv6 local 281 routes have been configured to allow for inter-site communication. 283 If BGP is being used at the site border with an ISP, by default 284 filters MUST be installed in the BGP configuration to keep any site- 285 local prefixes from being advertised outside of the site or for site- 286 local prefixes to be learned from another site. The exception to 287 this is if there are specific /48 routes created for one or more 288 globally unique IPv6 local prefixes. 290 5.0 Renumbering and Site Merging 292 The use of globally unique IPv6 local addresses in a site results in 293 making communication using these addresses independent of renumbering 294 a site's provider based global addresses. 296 When merging multiple sites none of the addresses created with these 297 prefixes need to be renumbered because all of the addresses are 298 unique. Routes for each specific prefix would have to be configured 299 to allow routing to work correctly between the formerly separate 300 sites. 302 6.0 Site Border Router and Firewall Filtering 304 While no serious harm will be done if packets with these addresses 305 are sent outside of a site via a default route, it is recommended 306 that they be filtered to keep any packets with globally unique IPv6 307 local destination addresses from leaking outside of the site and to 308 keep any site prefixes from being advertised outside of their site. 310 Site border routers SHOULD install a black hole route for the 311 Globally Unique IPv6 Local prefix FC00::/7. This will insure that 312 packets with Globally Unique IPv6 Local destination addresses will 313 not be forwarded outside of the site via a default route. 315 Site border routers and firewalls SHOULD NOT forward any packets with 316 globally unique IPv6 local source or destination addresses outside of 317 the site unless they have been explicitly configured with routing 318 information about other globally unique IPv6 local prefixes. The 319 default behavior of these devices SHOULD be to filter them. 321 7.0 DNS Issues 323 Globally Unique IPv6 Local addresses SHOULD NOT be installed in the 324 global DNS. They may be installed in a naming system local to the 325 site or kept separate from the global DNS using techniques such as 326 "two-faced" DNS. 328 If globally unique IPv6 local address are configured in the global 329 DNS, no harm is done because they are unique and will not create any 330 confusion. The may not be reachable, but this is a property that is 331 common to all types of global IPv6 unicast addresses. 333 For future study names with globally unique IPv6 local addresses may 334 be resolved inside of the site using dynamic naming systems such as 335 Multicast DNS. 337 8.0 Application and Higher Level Protocol Issues 339 Application and other higher level protocols can treat globally 340 unique IPv6 local addresses in the same manner as other types of 341 global unicast addresses. No special handling is required. This 342 type of addresses may not be reachable, but that is no different from 343 other types of IPv6 global unicast addresses. Applications need to 344 be able to handle multiple addresses that may or may not be reachable 345 any point in time. In most cases this complexity should be hidden in 346 APIs. 348 From a host's perspective this difference shows up as different 349 reachability than global unicast and could be handled by default that 350 way. In some cases it is better for nodes and applications to treat 351 them differently from global unicast addresses. A starting point 352 might be to give them preference over global unicast, but fall back 353 to global unicast if a particular destination is found to be 354 unreachable. Much of this behavior can be controlled by how they are 355 allocated to nodes and put into the DNS. However it is useful if a 356 host can have both types of addresses and use them appropriately. 358 Note that the address selection mechanisms of [ADDSEL], and in 359 particular the policy override mechanism replacing default address 360 selection, are expected to be used on a site where globally unique 361 IPv6 local addresses are configured. 363 9.0 Use of Globally Unique IPv6 Local Addresses for Local Communications 365 IPv6 globally unique IPv6 local addresses, like global scope unicast 366 addresses, are only assigned to nodes if their use has been enabled 367 (via IPv6 address autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or 368 manually) and configured in the DNS. They are not created 369 automatically the way that IPv6 link-local addresses are and will not 370 appear or be used unless they are purposely configured. 372 In order for hosts to autoconfigure globally unique IPv6 local 373 addresses routers have to be configured to advertise globally unique 374 IPv6 local /64 prefixes in router advertisements. Likewise, a DHCPv6 375 server must have been configured to assign them. In order for a node 376 to learn the globally unique IPv6 local address of another node, the 377 globally unique IPv6 local address must have been installed in the 378 DNS. For these reasons, it is straight forward to control their 379 usage in a site. 381 To limit the use of globally unique IPv6 local addresses the 382 following guidelines apply: 384 - Nodes that are to only be reachable inside of a site, the local 385 DNS should be configured to only include the globally unique 386 IPv6 local addresses of these nodes. Nodes with only globally 387 unique IPv6 local addresses must not be installed in the global 388 DNS. 390 - Nodes that are to be limited to only communicate with other 391 nodes in the site should be set to only autoconfigure globally 392 unique IPv6 local addresses via [ADDAUTO] or to only receive 393 globally unique IPv6 local addresses via [DHCP6]. Note: For the 394 case where both global and globally unique IPv6 local prefixes 395 are being advertised on a subnet, this will require a switch in 396 the devices to only autoconfigure globally unique IPv6 local 397 addresses. 399 - Nodes that are to be reachable from inside of the site and from 400 outside of the site, the DNS should be configured to include the 401 global addresses of these nodes. The local DNS may be 402 configured to also include the globally unique IPv6 local 403 addresses of these nodes. 405 - Nodes that can communicate with other nodes inside of the site 406 and outside of the site, should autoconfigure global addresses 407 via [ADDAUTO] or receive global address via [DHCP6]. They may 408 also obtain globally unique IPv6 local addresses via the same 409 mechanisms. 411 10.0 Use of Globally Unique IPv6 Local Addresses with VPNs 413 Globally unique IPv6 local addresses can be used for inter-site 414 Virtual Private Networks (VPN) if appropriate routes are set up. 415 Because the addresses are unique these VPNs will work reliably and 416 without the need for translation. They have the additional property 417 that they will continue to work if the individual sites are 418 renumbered or merged. 420 11.0 Advantages and Disadvantages 422 11.1 Advantages 424 This approach has the following advantages: 426 - Provides globally unique local prefixes that can be used 427 independently of any provider based IPv6 unicast address 428 allocations. This is useful for sites not always connected to 429 the Internet or sites that wish to have a distinct prefix that 430 can be used to localize traffic inside of the site. 431 - Applications can treat these addresses in an identical manner as 432 any other type of global IPv6 unicast addresses. 433 - Sites can be merged without any renumbering of the globally 434 unique IPv6 local addresses. 435 - Sites can change their provider based IPv6 unicast address 436 without disrupting any communication using globally unique IPv6 437 local addresses. 438 - Well known prefix that allows for easy filtering at site 439 boundary. 440 - Can be used for inter-site VPNs. 441 - If accidently leaked outside of a site via routing or DNS, there 442 is no conflict with any other addresses. 444 11.2 Disadvantages 446 This approach has the following disadvantages: 448 - Not possible to route globally unique IPv6 local prefixes on the 449 global Internet with current routing technology. 450 Consequentially, it is necessary to have the default behavior of 451 site border routers to filter these addresses. 452 - There is a very low probability of non-unique locally assigned 453 global IDs being generated by the algorithm in section 3.2.3. 454 This risk can be ignored for all practical purposes, but it 455 leads to a theoretical risk of clashing address prefixes. 457 12.0 Security Considerations 459 Globally unique IPv6 local addresses do not provide any inherent 460 security to the nodes that use them. They may be used with filters 461 at site boundaries to keep globally unique IPv6 local traffic inside 462 of the site, but this is no more or less secure than filtering any 463 other type of global IPv6 unicast addresses. 465 Globally unique IPv6 local addresses do allow for address-based 466 security mechanisms, including IPSEC, across end to end VPN 467 connections. 469 13.0 IANA Considerations 471 The IANA is instructed to allocate the FC00::/7 prefix for Globally 472 Unique IPv6 Local addresses. 474 The IANA is instructed to delegate, within a reasonable time, the 475 prefix FC00::/8 to an allocation authority for Globally Unique IPv6 476 Local prefixes of length /48. This allocation authority shall comply 477 with the requirements described in section 3.2 of this document, 478 including in particular the charging of a modest one-time fee, with 479 any profit being used for the public good in connection with the 480 Internet. 482 14.0 Change Log 484 Draft 486 o Added section on scope definition and updated application 487 requirement section. 488 o Clarified that, by default, the scope of these addresses is 489 global. 490 o Renumbered sections and general text improvements 491 o Removed reserved global ID values 492 o Added pseudo code for local allocation submitted by Brian 493 Haberman and added him as an author. 494 o Split Global ID values into centrally assigned and local 495 assignments and added text to describe local assignments 497 Draft 499 o Initial Draft 501 REFERENCES 503 Normative 505 [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing 506 Architecture", RFC3515, April 2003. 508 [GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast 509 Address Format", Internet Draft, , February 2003. 512 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 513 (IPv6) Specification", RFC2460, December 1998. 515 [MD5DIG] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, 516 April 1992. 518 [NTP] Mills, David L., "Network Time Protocol (Version 3) 519 Specification, Implementation and Analysis", RFC1305, March 520 1992. 522 [POPUL] Population Reference Bureau, "World Population Data Sheet 523 of the Population Reference Bureau 2002", August 2002. 525 [RANDOM] Eastlake, D. 3rd, S. Crocker, J. Schiller, "Randomness 526 Recommendations for Security", RFC1750, December 1994. 528 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 529 3", RFC2026, BCP00009, October 1996. 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", RFC2119, BCP14, March 1997. 534 Non-Normative 536 [ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address 537 Autoconfiguration", RFC2462, December 1998. 539 [DHCP6] Droms, R., et. al., "Dynamic Host Configuration Protocol 540 for IPv6 (DHCPv6)", Internet Draft, , November 2002. 543 [ADDSEL] Draves, R., "Default Address Selection for Internet 544 Protocol version 6 (IPv6)", RFC3484, February 2003. 546 AUTHOR'S ADDRESSES 548 Robert M. Hinden 549 Nokia 550 313 Fairchild Drive 551 Mountain View, CA 94043 552 US 554 phone: +1 650 625-2004 555 email: bob.hinden@nokia.com 557 Brian Haberman 558 Caspian Networks 559 1 Park Drive, Suite 300 560 Research Triangle Park, NC 27709 561 US 563 phone: +1-929-949-4828 564 email: brian@innovationslab.net