idnits 2.17.1 draft-boot-homenet-brdp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 685 has weird spacing: '...ed site with ...' == Line 1355 has weird spacing: '...es, and a def...' -- The document date (October 15, 2012) is 4210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-04 == Outdated reference: A later version (-12) exists of draft-ietf-mptcp-multiaddressed-10 == Outdated reference: A later version (-01) exists of draft-kline-default-perimeter-00 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Boot 3 Internet-Draft Infinity Networks B.V. 4 Intended status: Informational October 15, 2012 5 Expires: April 18, 2013 7 BRDP for Homenet 8 draft-boot-homenet-brdp-00.txt 10 Abstract 12 This document describes the Border Router Discovery Protocol (BRDP) 13 and all of its related components. BRDP enables multi-homing for 14 small to medium sites, including Homenets, using Provider 15 Aggregatable IPv6 addresses. It describes a mechanism for automated 16 IP address configuration and renumbering, a mechanism for optimized 17 source address selection and a new paradigm for packet forwarding, 18 for support of multi-homed sites. BRDP prevents ingress filtering 19 problems with multi-homed sites and supports load-balancing for 20 multi-path transport protocols. This work also prevents routing 21 scalability problems in the provider network and Internet Default 22 Free Zone because small to medium multi-homed size sites would not 23 need to request Provider Independent address blocks. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 18, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Detection of Homenet Perimeter interfaces on Border 61 Routers . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.2. Propagation of Border Router information . . . . . . . . . 5 63 1.3. Address configuration with Border Router information . . . 6 64 1.4. Address selection with Border Router information . . . . . 6 65 1.5. Routing based on Border Router information . . . . . . . . 7 66 1.6. Deployment of the Border Router Discovery Protocol . . . . 7 67 1.7. Requirements Language . . . . . . . . . . . . . . . . . . 8 68 2. Reference Scenarios . . . . . . . . . . . . . . . . . . . . . 8 69 2.1. Single-homed site . . . . . . . . . . . . . . . . . . . . 8 70 2.2. Small multi-homed site or DMZ . . . . . . . . . . . . . . 10 71 2.3. Medium multi-homed site . . . . . . . . . . . . . . . . . 12 72 2.4. Medium multi-homed site with ULAs and DHCP server . . . . 16 73 2.5. MANET site . . . . . . . . . . . . . . . . . . . . . . . . 18 74 3. Border Router Discovery Protocol (BRDP) . . . . . . . . . . . 20 75 3.1. Border Router Information Option (BRIO) . . . . . . . . . 21 76 3.2. BRDP processing . . . . . . . . . . . . . . . . . . . . . 22 77 3.2.1. BRDP message generation and transmission . . . . . . . 23 78 3.2.2. BRDP message reception . . . . . . . . . . . . . . . . 24 79 3.2.3. BRIO-Cache maintenance . . . . . . . . . . . . . . . . 25 80 3.2.4. BRDP loop prevention . . . . . . . . . . . . . . . . . 26 81 3.3. Unified Path Metric (UPM) . . . . . . . . . . . . . . . . 27 82 4. BRDP based Address Configuration and Prefix Delegation . . . . 27 83 4.1. Border Router selection . . . . . . . . . . . . . . . . . 28 84 4.1.1. Border Router Selection based on UPM . . . . . . . . . 28 85 4.2. Address autoconfiguration . . . . . . . . . . . . . . . . 29 86 4.2.1. Address and prefix configuration with SLAAC or DHCP . 29 87 4.2.2. Address generation and configuration for Routers . . . 29 88 4.2.3. Support for Unique Local Addresses (ULA) . . . . . . . 30 89 5. BRDP based Source Address Selection . . . . . . . . . . . . . 30 90 5.1. Address Selection for dynamic DNS . . . . . . . . . . . . 30 91 6. BRDP based Routing . . . . . . . . . . . . . . . . . . . . . . 30 92 6.1. Problems with default gateway routing . . . . . . . . . . 31 93 6.2. Default gateway routing replaced with BRDP Based 94 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 31 95 7. BRDP and IRTF RRG goals . . . . . . . . . . . . . . . . . . . 32 96 7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 33 97 7.2. Traffic engineering . . . . . . . . . . . . . . . . . . . 33 98 7.3. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . 33 99 7.4. Loc/id separation . . . . . . . . . . . . . . . . . . . . 33 100 7.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 34 101 7.6. Simplified renumbering . . . . . . . . . . . . . . . . . . 34 102 7.7. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 34 103 7.8. Routing quality . . . . . . . . . . . . . . . . . . . . . 34 104 7.9. Routing security . . . . . . . . . . . . . . . . . . . . . 34 105 7.10. Deployability . . . . . . . . . . . . . . . . . . . . . . 35 106 8. Currently unaddressed issues . . . . . . . . . . . . . . . . . 35 107 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 109 11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 110 12. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 36 111 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 112 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 113 13.2. Informative References . . . . . . . . . . . . . . . . . . 37 114 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 116 1. Introduction 118 *** Note to the reader *** This Internet Draft is submitted as an 119 early version for a proposal for the Homenet working group. This 120 version is a merge from earlier documents. Now that is a singe 121 document, it is to be adjusted to comply to the Homenet scenario. 122 This is work in progress. 124 IPv6 provides basic functionality for multi-homing, since nodes can 125 have multiple addresses configured on their interfaces. However, it 126 is difficult to utilize the advantages of this, as there is a strong 127 tendency shielding the network topology from hosts and in general 128 routing does not support multi-homing very well. As a result, it is 129 difficult or impossible for a host to utilize available facilities of 130 the network, such as multi-path. Also scalability of the Internet 131 routing system is getting a problem due to a high demand of Provider 132 Independent (PI) addresses. 134 The Border Router Discovery Protocol (BRDP) enhances the IPv6 model 135 by enabling automated renumbering in dynamically changing multi-homed 136 environments, such that routers and hosts cooperate on address 137 configuration and path selection. BRDP utilizes Provider 138 Aggregatable (PA) addresses and uses them as locator. Mapping 139 identifiers to locators is out of scope of BRDP, also because other 140 solutions exists or are being worked on. All these solutions work 141 fine with BRDP, as long as they don't break IPv6. 143 BRDP applies to edge networks. These networks can be fixed, for 144 example enterprise networks, small offices / home offices (SOHO) or 145 home sites (Homenets). BRDP also can be used in wireless access 146 networks, for example wireless access networks such as 3G or 4G, 147 wireless LANs or mobile ad hoc networks (MANETs). A nice attribute 148 of BRDP is that it supports multi-homing in heterogeneous networks, 149 meaning that e.g. a Homenet network can have multiple wired broadband 150 and 3G/4G connections to the Internet simultaneously. 152 In a multi-homed network, nodes are connected to the Internet via 153 multiple exit points, possibly via multiple providers. [RFC5887] 154 argues that if a site is multi-homed, using multiple PA routing 155 prefixes, then the interior routers need a mechanism to learn which 156 upstream providers and corresponding PA prefixes are currently 157 reachable and valid. Next to that, these upstream providers or PA 158 prefixes may change over time. This requires a dynamic renumbering 159 mechanism that can handle planned or unplanned changes in the 160 prefixes used. BRDP proposes a mechanism for automated renumbering 161 in larger networks that goes beyond hosts in a single subnet. 163 BRDP uses the following key elements: 165 o Propagation of available Border Routers and corresponding 166 prefixes, described in Section 3; 167 o Address autoconfiguration and prefix delegation, using BRDP 168 provided hints, described in Section 4; 169 o Source address selection, using BRDP provided hints, described in 170 Section 5; 171 o Packet forwarding to the Border Router that corresponds with the 172 source address prefix, in case the destination address is not 173 found in the routing domain, described in Section 6. 175 1.1. Detection of Homenet Perimeter interfaces on Border Routers 177 For fully automated deployment in Homenets, it is required that 178 routers can discover automatically their uplink interfaces, that 179 connect the Homenet to ISPs. Some mechanisms for automatic detection 180 are described in [I-D.kline-default-perimeter]. 182 After detection of an uplink interface to an ISP and reception of a 183 prefix, the router starts acting as a border router. It starts 184 acting as a DHCP server, with support of prefix delegation. It also 185 configures at least an address out of the assigned prefix. This 186 address is used as Border Router address and DHCP server address. 188 The BRDP protocol can also be used to assist perimeter detection. A 189 router interface on which Border Router information is received 190 should not be identified as an uplink interface to an ISP. 192 1.2. Propagation of Border Router information 194 The propagation of available Border Routers and corresponding 195 prefixes is implemented as an extension on the Neighbor Discovery 196 Protocol [RFC4861]. Border Router Information Options (BRIOs) are 197 sent with Router Advertisements, and contain information about the 198 Border Router, such as: 199 o - the Border Router address; 200 o - the prefix that corresponds with that Border Router; 201 o - cost indication of the path via that Border Router to the core 202 network, i.e. the Internet Default Free Zone (DFZ). 204 BRIOs are disseminated downstream through the network. All nodes 205 store the information from BRIOs they receive in a BRIO cache. 207 Border routers with multiple prefixes send out a BRIO for each of 208 these prefixes. In a multi-homed network, nodes will receive 209 multiple prefix information, from multiple upstream Border Routers or 210 from a Border Router with multiple prefixes. 212 1.3. Address configuration with Border Router information 214 Routers can generate IPv6 addresses, with regular SLAAC [RFC4862]. 215 Generation is based on Prefix Information Option from upstream 216 routers and optionally on information in the BRIO cache, e.g. using 217 the prefix with the lowest cost to the Internet. In addition, 218 routers may generate /128 IPv6 address-prefixes for a management 219 interface, based on a Border Router prefix. Routers set up 220 reachability to these addresses automatically, by adding the 221 generated address or prefix in the routing protocol. 223 With BRDP, routers automatically learn Border Routers that act as 224 DHCP server or relay agent [RFC3633]. When routers detect an 225 alternate path to the DFZ, with no corresponding assigned address or 226 prefix already, new prefixes are requested for using this alternate 227 path. 229 Prefixes, of which the path to the DFZ is no longer available, are 230 put 'out of service' by routers, meaning they are not used for 231 address assignments anymore. Optionally, if the cost to the DFZ 232 through a Border Router is far higher than via other available paths, 233 a router can put the corresponding prefix out of service also. 234 Prefixes that are out of service are released. 236 Prefixes that are in service are configured on interfaces with a 64- 237 bit prefix length and advertised with a Prefix Information Option in 238 Router Advertisements. The Prefix Information lifetime is copied 239 from lifetime information in the BRIO cache. 241 Hosts can use the BRDP provided information together with the Prefix 242 Information to autoconfigure addresses, based on IPv6 Stateless 243 Address Autoconfiguration [RFC4862]. A host may also use DHCPv6 to 244 get addresses or "Other configuration", using multicast or with 245 unicast to the BRDP learned DHCP server address. 247 1.4. Address selection with Border Router information 249 Nodes with multiple configured addresses need to select a source 250 address for outgoing connections. Default Address Selection for IPv6 251 [RFC6724] defines a mechanism, used as default behavior. It is open 252 to more advanced mechanisms or site policies. BRDP provided 253 information can be used for a more advanced mechanism, where the 254 hosts select automatically a source address that corresponds with a 255 path with the lowest cost to the DFZ. When multiple Border Routers 256 are available, automatic load distribution and multi-path transport 257 becomes available. 259 1.5. Routing based on Border Router information 261 Network Ingress Filtering [RFC2827] describes the need for ingress 262 filtering, to limit the impact of distributed denial of service 263 attacks, by denying traffic with spoofed source addresses access. It 264 also helps ensure that traffic is traceable to its correct source 265 network. Ingress Filtering for Multihomed Networks [RFC3704] 266 provides solutions for multi-homed sites. However, the proposal 267 applicable for PA addresses requires careful planning and 268 configuration. It suggests routing based on source address, and a 269 path on each Border Router to all ISPs in use, either with a direct 270 connection or with tunnels between all Border Routers. It is hard to 271 make such mechanisms work in an automated fashion, or mechanisms are 272 not supported on Border Routers used today. As an evolutionary 273 approach, BRDP provided information is to be used to forward packets 274 to their destination without ingress filtering problems. The BRIO 275 cache contains a mapping between Border Routers and the addresses 276 that do pass ingress filtering. So the packet forwarding heuristic 277 can be straightforward: send packets, where the destination is not in 278 the routing domain itself, to the Border Router that owns the prefix 279 of the source address. 281 Hosts use information in the Default Router List to select a default 282 router. For selecting the best paths, hosts may use next hop 283 selection based on source address and path costs to the corresponding 284 Border Router, if such information is available to the host. Such 285 next hop determination is useful for destinations outside the edge 286 network, i.e. the destination address does not belong to a prefix in 287 the BRIO cache. 289 1.6. Deployment of the Border Router Discovery Protocol 291 Enabling BRDP in an existing network is straightforward. First, all 292 routers have to be updated for BRDP support. At this step, Border 293 Router information is propagated in the network enabling BRDP 294 assisted address autoconfiguration and prefix delegation and BRDP 295 assisted source address selection. The second step is updating all 296 routers with the BRDP based routing mechanism. To enable this 297 mechanism the default gateway is removed from the routing table. 298 This second step is a flag day operation. Rolling back is easy, by 299 just re-inserting the default gateway. 301 After the update of the network, additional border routers can be 302 added to the network and will be used automatically. Also a 303 renumbering event will take place without any manual intervention. 305 BRDP does not provide session continuity when paths are broken. 306 Mobility solutions are in place, or are work in progress. Recently, 307 interesting developments are work in progress, such as MPTCP 308 [I-D.ietf-mptcp-multiaddressed] and ILNP [I-D.rja-ilnp-intro]. BRDP 309 is very useful for both of these protocols. 311 1.7. Requirements Language 313 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 314 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 315 document are to be interpreted as described in RFC 2119 [RFC2119]. 317 2. Reference Scenarios 319 This section describes the use of BRDP in five different scenarios: a 320 single homed Homenet, multi-homed site or DMZ, a medium multi-homed 321 site, a medium multi-homed site with ULA with DHCP server and a MANET 322 site. 324 2.1. Single-homed site 326 This scenario discusses BRDP operation for single-homed home 327 networks. The scenario is taken from [I-D.ietf-homenet-arch]. 329 /^^^^^^^^^^^^^^^^^^^^^^\ 330 / \ 331 { The Internet } 332 \ / 333 \______________________/ 334 | 335 |(2001:08db:100::/40) 336 +-------+-------+ 337 | Service | 338 | Provider | 339 | Router | 340 +-------+-------+ 341 | 342 | (2001:8db:101::/48) 343 +------+--------+ 344 | IPv6 CPE | 345 | BR_101 | 346 +----+-+---+----+ 347 2001:8db:101:1::1 | | | 348 | | | 349 2001:8db:101:1::/64 | | | 2001:8db:101:3::/64 350 ----+-------------+----+ | +---+-------------+------+ 351 | | | | | | | 352 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | 353 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | 354 +----------+ +----------+ | +----------+ +----------+ | 355 | | | | 356 2001:8db:101:2::/64 | ---+------+------+-----+ 357 | | 358 2001:8db:101:2::2 | | 359 +------+--------+ | 360 | IPv6 | | 361 | Interior +------+ 362 | Router | 363 +---+-------+---+ 364 2001:8db:101:4::/64 | | 2001:8db:101:5::/64 365 ----+-------------+---+- --+---+-------------+--- 366 | | | | 367 +----+-----+ +-----+----+ +----+-----+ +-----+----+ 368 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | 369 +----------+ +----------+ +----------+ +----------+ 371 Figure 1: Scenario 1: Single-homed site 373 The CPE device has to discover the link to the ISP and has to get 374 assigned an IPv6 prefix, in this scenario 2001:8db:101::/48. The CPE 375 configures itself a global unique address prefix 2001:8db:101:1:: 376 1/64, assumed on the first interface in the homenet. It may 377 configure additional global unique address on other interfaces, but 378 this is not required. This is existing functionality which is not 379 updated by BRDP. 381 The CPE starts sending router advertisements. It also checks 382 received router advertisements on already existing prefixes for the 383 /48 prefix it has assigned by the ISP. In this scenario there is no 384 other CPE, so no on-link prefixes exist. The CPE allocates and bind 385 additional prefixes for all its interfaces, and send Router 386 Advertisements with the Prefix Information Option. By then it has 387 configured 2001:8db:101:1::/64, 2001:8db:101:2::/64 and 2001:8db:101: 388 3::/64. The CPE router also acts as DHCP server, for the ISP 389 provided prefix. 391 Now, the IPv6 hosts in the middle row learn these prefixes from 392 Prefix Information Options sent by the CPE. They can configure IPv6 393 addresses, either with SLAAC or DHCP. Also, the IPv6 Interior Router 394 can configure an IPv6 address, in this scenario on the link with 395 prefix 2001:8db:101:2::/64. 397 The IPv6 Interior Router also receives the router advertisement with 398 the onlink prefix 2001:8db:101:3::/64 on its interface on the right. 399 It could configure an address in thes prefix, but because it has 400 already a globally unique address configured, there is no need for 401 this. Question is if the router should echo the prefix as on-link. 402 In this BRDP proposal, it doesn't. It is not the "delegated prefix 403 holder". 405 Before the IPv6 hosts on the lower row can get their addresses, the 406 IPv6 Interior Router has to be assigned two more prefixes. Here, 407 BRDP starts playing its role. The CPE router advertises itself with 408 Border Router Information Option, in its Router Advertisement. The 409 IPv6 Interior Router learns this information, and gets the two needed 410 prefixes from the CPE Router, using unicasted DHCP messages to the 411 (CPE) Border Router. Two prefixes are assigned and configured, 2001: 412 8db:101:4::/64 and 2001:8db:101:5::/64. 414 For full connectivity, the homenet uses an interior routing protocol. 415 BRDP is agnostic on the routing protocol used. 417 2.2. Small multi-homed site or DMZ 419 This scenario discusses BRDP operation for multi-homed Small Office - 420 Home Office (SOHO) networks and De-Militarized Zones (DMZ). The 421 scenario is shown in Figure 2. Each provider assigns a PA /48 prefix 422 to its customers. All addresses and prefixes are configured 423 completely automatically. The feature of BRDP that adds value in 424 this scenario is BRDP based Border Router selection for multi-homed 425 hosts. This is enabled by using BRDP based forwarding. 427 /^^^^^^^^^^^^^^^^^^^^^^\ 428 / \ 429 { The Internet } 430 \ / 431 \______________________/ 432 / \ 433 /(2001:08db:100::/40) \(2001:8db:200::/40) 434 +=======+ +=======+ 435 [ ISP_1 ] [ ISP_2 ] 436 +=======+ +=======+ 437 | | 438 |(2001:8db:101::/48) |(2001:8db:201::/48) 439 +--------+ +--------+ 440 | BR_101 | | BR_201 | 441 +--------+ +--------+ 442 | fe80::101/64 | fe80::201/64 443 | 2001:8db:101:1::101/64 | 2001:8db:201:1::201/64 444 | | 445 -+---------------------+---+- 446 | 447 2001:8db:101:1::1234/64 | 2001:8db:201:1::1234/64 448 fe80::1234/64 | 449 +-----------+ 450 | Host_1234 | 451 +-----------+ 453 Figure 2: Scenario 2: multi-homed Small Office - Home Office (SOHO) 454 network or DMZ 456 In this scenario, Host_1234 has configured two addresses using SLAAC 457 [RFC4862], one with prefix 2001:8db:101:1::/64 from Border Router 458 BR_101 and one with prefix 2001:8db:201:1::/64 from Border Router 459 BR_201. Host_1234 has learned these prefixes from Prefix Information 460 Options sent by both Border Routers according to [RFC4861]. The host 461 has learned via BRIOs that these prefixes belong to Border Routers. 462 The host can use optimal paths by selecting BR_101 as default router 463 for all packets with a source address with prefix 2001:8db:101:1::/64 464 and default gateway BR_201 for all packets with a source address with 465 prefix 2001:8db:201:1::/64. Non-optimal default router selection on 466 hosts is handled by the routers, "misdirected" packets are forwarded 467 to the correct Border Router. 469 BRDP enables routers to deliver non-optimal directed packets from 470 attached hosts towards a Border Router that owns the prefix of the 471 source address, if such a Border Router exists. In the above 472 scenario, a packet sent from Host_1234 with source address 2001:8db: 474 201:1::1234 to default router BR_101 would be dropped due to on an 475 ingress filter, when no mechanism is in place to redirect the packet. 476 BRDP based forwarding provides such a mechanism automatically. 477 Instead of dropping the packet, BR_101 forwards it to BR_201. 479 2.3. Medium multi-homed site 481 This scenario discusses BRDP operation for medium sized multi-homed 482 networks. The difference with the previous scenario is that the 483 network paths between hosts and the Border Routers have intermediate 484 routers. The scenario is shown in Figure 3. The added value of BRDP 485 in this scenario is the discovery of Border Routers for hosts and 486 routers beyond the first hop as well as Border Router Selection for 487 hosts and routers. 489 /^^^^^^^^^^^^^^^^^^^^^^\ 490 / \ 491 { The Internet } 492 \ / 493 \______________________/ 494 / \ 495 /(2001:8db:100::/40) \(2001:8db:200::/40) 496 +=======+ +=======+ 497 [ ISP_1 ] [ ISP_2 ] 498 +=======+ +=======+ 499 | | 500 |(2001:8db:101::/48) |(2001:8db:201::/48) 501 +--------+ +--------+ 502 | BR_101 | | BR_201 | 503 +--------+ +--------+ 504 | fe80::101/64 | fe80::201/64 505 | 2001:8db:101:1::101/64 | 2001:8db:201:1::201/64 506 | | 507 -+-+-----------------------+-+- 508 | | 509 | 2001:8db:201:1::1/64 | 510 | 2001:8db:101:1::1/64 | 2001:8db:201:1::2/64 511 | fe80::1/64 | fe80::2/64 512 +----------+ +--------+ 513 | R_1 | | R_2 | 514 +----------+ +--------+ 515 |fe80:: | fe80::2:1/64 | fe80::1:2/64 516 |1:1/64 | | 517 | -+--------------------+-+- 518 | | 519 | 2001:8db:101:2::1234/64 | 520 | 2001:8db:201:3::1234/64 | 521 | fe80::1234/64 | 522 +-----------+ | 2001:8db:101:3::ABCD/64 523 | Host_1234 | | fe80::ABCD/64 524 +-----------+ +-----------+ 525 | Host_ABCD | 526 +-----------+ 528 Figure 3: Scenario 3: medium sized multi-homed network 530 Routers can learn advertised on-link prefixes automatically via the 531 Prefix Information Option in IPv6 ND RAs. In this scenario, routers 532 R_1 and R_2 learn prefix 2001:8db:101:1::/64 from BR_101 and prefix 533 2001:8db:201:1::/64 from BR_201. Routers may autoconfigure addresses 534 on their interfaces. In this example, R_1 has configured addresses 535 from both providers on its upstream interface, R_2 only configured an 536 address based on the prefix of BR_201. If the routers run a routing 537 protocol, the learned prefixes are made reachable in the network. In 538 the next steps of the autoconfiguration proces, the prefixes and 539 addresses on the other links are automatically configured, but first 540 we discuss the BRDP messages that are disseminated through the 541 network. 543 Routers automatically learn Border Routers and mapping between 544 prefixes and Border Routers using BRDP. The diagram in Figure 4 545 depicts BRIO message dissemination in scenario 2. The two Border 546 Routers advertise their own address and corresponding prefix with an 547 address prefix. Nothing prevents them from forwarding each other's 548 BRIO message, although resending BRIO information on non-MANET 549 interfaces is not useful. Both routers R_1 and R_2 forward both 550 Border Router address prefixes, using separate BRIOs in RAs, on 551 downstream interfaces. In this way all routers and hosts in the 552 network are aware of all reachable Border Routers and corresponding 553 prefixes. 555 /^^^^^^^^^^^^^^^^^^^^^^\ 556 / \ 557 { The Internet } 558 \ / 559 \______________________/ 560 / \ 561 /(2001:8db:100::/40) \(2001:8db:200::/40) 562 +=======+ +=======+ 563 [ ISP_1 ] [ ISP_2 ] 564 +=======+ +=======+ 565 | | 566 |(2001:8db:101::/48) |(2001:8db:201::/48) 567 +--------+ +--------+ 568 | BR_101 | | BR_201 | 569 +--------+ +--------+ 570 | : | : 571 | V 2001:8db:101:1::101/48 | V 2001:8db:201:1::201/48 572 | | 573 -+-+-------------------------+-+- 574 | | 575 | | 576 +--------+ +--------+ 577 | R_1 | | R_2 | 578 +--------+ +--------+ 579 | : | : | : 580 | : | : 2001:8db:101:1::101/48 | : 2001:8db:101:1::101/48 581 | : | V 2001:8db:201:1::201/48 | V 2001:8db:201:1::201/48 582 | : | | 583 | : -+--------------------------+- 584 | : 585 | : 2001:8db:101:1::101/48 586 | V 2001:8db:201:1::201/48 587 | 588 -+---- 590 Figure 4: BRIO dissemination in Scenario 3 592 Routers are not required to configure global addresses on each 593 interface. In the example, only the interface pointing to the 594 Internet has configured global addresses. Routers may also use a 595 (logical) management interface for global reachability. 597 So, the one-hop neighbours of BR_101 and BR_201, being R_1 and R_2, 598 have learned the prefixes and configured addresses on their upstream 599 interfaces. And all nodes in the network have learned the Border 600 Router prefixes. The next step is to get configured addresses on the 601 hosts in Figure 2. This is done by using DHCP Prefix Delegation. 602 R_1 and R_2 request a prefix from either or both BR_101 and BR_201 603 for binding as on-link prefix on the links, and advertise those using 604 Prefix Information Options to the hosts. This will result in a 605 maximum of four prefixes that are advertised on the downlink of R_1 606 and R_2. Having multiple prefixes from the same ISP bound on a link 607 is not useful. So a router requests a prefix from a Border Router 608 only if no other prefix of that Border Router is advertised already 609 by another router on this network segment. 611 In this example, R_1 has been delegated two prefixes by DHCP PD for 612 the link with host Host_1234; 2001:8db:101:2::/64 and 2001:8db:201: 613 3::/64. No other router is on this link. R_1 or R_2 has also been 614 delegated a prefix on the link to host Host_ABCD; 2001:8db:101: 615 3::/64. It cannot be seen in Figure 2 which router has been 616 delegated the prefix, nor if another prefix for this link has been 617 delegated. No redundant prefix is delegated, as the routers learned 618 with RA PIO already delegated prefixes for known Border Routers. 620 Now, Host_1234 and Host_ABCD can autoconfigure addresses for their 621 interfaces. Host_1234 configures two addresses, one for each Border 622 Router. Host_ABCD chooses not to use ISP_2. 624 Nodes R_1 and Host_1234 can use both providers, by using two 625 configured global addresses. Any multi-path facility can be used, 626 either on an application layer or with a multi-path transport 627 protocol. 629 Host_ABCD may forward packets to the Internet via router R_1 or R_2. 630 If R_2 is selected as default router, R_2 forwards the packets to 631 BR_101 as this Border Router corresponds to the prefix of the source 632 address 2001:8db:101:3::ABCD. This works well, even in this case 633 where R_2 hasn't configured an address with a BR_101 prefix for 634 itself, and selected a global address from the BR_201 prefix only. 636 2.4. Medium multi-homed site with ULAs and DHCP server 638 In this example, the scenario 2 is extended by adding Unique Local 639 Addresses (ULA) for communication within the site itself. For 640 simplicity there is only one ISP present. The ULA IP configuration, 641 with prefix fd00:8db::/48, is managed by DHCPv6 server DHCP_201. The 642 scenario is shown in Figure 5. 644 /^^^^^^^^^^^^^^^^^^^^^^\ 645 / \ 646 { The Internet } 647 \ / 648 \______________________/ 649 / 650 /(2001:8db:100::/40) 651 +=======+ 652 [ ISP_1 ] 653 +=======+ 654 | 655 |(2001:8db:101::/48) 656 +--------+ +---------+ 657 | BR_101 | | DHCP_201| 658 +--------+ +---------+ 659 | fe80::101/64 | fe80::201/64 660 | 2001:8db:101:1::101/64 | fd00:8db:201:1::201/64 661 | fd00:8db:201:1::101/64 | (acme.com,fd00:8db:201:1:201:/48) 662 | | 663 -+-+-----------------------+-+- 664 | | 665 | fd00:8db:201:1::1/64 | fd00:8db:201:1::2/64 666 | 2001:8db:101:1::1/64 | 2001:8db:101:1::2/64 667 | fe80::1/64 | fe80::2/64 668 +--------+ +--------+ 669 | R_1 | | R_2 | 670 +--------+ +--------+ 671 |FE80 | fe80::1/64 | fe80::2/64 672 |::1 | | 673 |/64 -+--------------------+-+- 674 | | 675 | 2001:8db:101:2::1234/64 | 676 | fd00:8db:201:3::1234/64 | 677 | fe80::1234/64 | 678 +-----------+ | 2001:8db:101:3::ABCD/64 679 | Host_1234 | | fd00:8db:201:3::ABCD/64 680 +-----------+ | fe80::ABCD/64 681 +-----------+ 682 | Host_ABCD | 683 +-----------+ 685 Figure 5: Scenario 4: a medium sized multi-homed site with ULAs and 686 DHCP server. 688 In this scenario, all nodes have configured a ULA and a Global 689 Unicast Address using prefix delegation in the way that was described 690 in Section 2.2. ULA prefix delegation is automated just like PA 691 addresses. The DHCP server is therefore implemented on a router, in 692 this case DHCP_201. This router advertises the ULA prefix with BRDP, 693 here fd00:8db:201::/48. 695 Although BRDP provides automatic prefix and address configuration for 696 ULA, a network administrator is free to configure it manually, along 697 using BRDP for global addresses. 699 BRDP based ULA configuration with BRDP based routing would result in 700 routing packets with ULA destinations outside the site to the 701 originator of the ULA prefix, in this case router DHCP_201. DHCP_201 702 is not connected to the Internet or another site owning the ULA, so 703 packets to non-existing destinations are dropped. DHCP_201 indicates 704 such with the BRIO F-bit set, meaning the Border Router is floating. 706 This scenario, it is demonstrated that BRDP and DHCPv6 cooperate in 707 address configuration. BRDP provides announcements of Border Routers 708 and DHCP servers. Routers request prefixes with DHCP, and can 709 request other parameters also. Such parameters are disseminated to 710 other nodes, either with router advertisements or acting as DHCP 711 server itself. Routers may also act as DHCP relay, redirecting 712 address requests to the Border Router(s). The Router Advertisement 713 M-bit and O-bit indicates availability of DHCPv6 services to attached 714 nodes. 716 Difficulties may arise when both ULA and global addresses are used 717 for Internet connectivity, e.g. when address translation is used. To 718 distinguish, the Border Router not providing Internet connectivity 719 informs nodes in the network using Service Selection suboption, 720 similar to "Service Selection for Mobile IPv6" [RFC5149]. This 721 procedure helps also for extranet connectivity. In this scenario, 722 the ULA is used within the ACME Corporation, nodes are made aware by 723 adding "acme.com" in the BRIO Service Selection Option. 725 It is for the reader to work out extensions for this scenario, where 726 the ULA prefix originator is a Border Router to another site, e.g. a 727 link from a branch office to a head quarter, or a ULA-only side 728 connected to the Internet with NAT66. 730 2.5. MANET site 732 BRDP was developed for address autoconfiguration in MANETs. This 733 scenario, see Figure 6 demonstrates the powerful multi-homing 734 facilities provided to the MANET nodes. 736 /^^^^^^^^^^^^^^^^^^^^^^\ 737 / \ 738 { The Internet } 739 \ / 740 \______________________/ 741 / \ 742 /(2001:8db:100::/40) \(2001:8db:200::/40) 743 +=======+ +=======+ 744 [ ISP_1 ] [ ISP_2 ] 745 +=======+ +=======+ 746 | | 747 |c=1 |c=1 748 |(2001:8db:101::/48) |(2001:8db:201::/48) 749 +--------+ +--------+ 750 | BR_101 | | BR_201 | 751 +-+------+ +---+----+ 752 | fe80::101/64 | fe80::201/64 753 | 2001:8db:101:1::101/128 | 2001:8db:201:1::201/128 754 /|\ /|\ 755 : . c=5 . : 756 : . . . . . . . . . :c=1 757 :c=2 . : 758 : . . . . . . . . . . \|/ 759 : . c=5 | 2001:8db:201:1::2/128 760 \|/ | 2001:8db:201:1::2/128 761 | 2001:8db:201:1::1/128 | fe80::2/64 762 | 2001:8db:101:1::1/128+--+--+ 763 | fe80::102/64 . .| R_2 | 764 +--+--+ . . . . +-----+. 765 | R_1 |. . . . c=5 : . c=4 766 +-----+. . . . . . . :c=1 . . . . . 767 c=4 . : . 768 \|/ \|/ 769 2001:8db:201:1::3/128 | 2001:8db:201:1::4/128 | 770 2001:8db:101:1::3/128 | 2001:8db:201:1::4/128 | 771 fe80::3/64 | fe80::4/64 | 772 +--+--+ +--+--+ 773 | R_3 | . . . . . . . . .| R_4 | 774 +-----+ c=4 +-----+ 776 Figure 6: Scenario 5: a MANET site 778 On the MANET interfaces, addresses are configured using a 64-bit 779 prefix provided by BRDP, appending it with a 64-bit Interface 780 Identifier according to BRDP based address autoconfiguration. This 781 creates a 128-bit prefix length as recommended in IP Addressing Model 782 in Ad Hoc Networks [RFC5889]. Each MANET node has configured two 783 global addresses, one for each ISP. With BRDP, the nodes are aware 784 of the cost of the path to the DFZ, defined as dimensionless metric 785 for both directions of the patch. This enables optimized source 786 address selection, and as an implicit result a Border Router and ISP 787 selection. In the scenario, R_1 is near to BR_101 and the cost via 788 this Border Router is lower than via BR_201. The table below shows 789 costs to the DFZ for all nodes, via both ISPs. Paths with lowest 790 costs are marked with *. 792 +---------+-------+-------+ 793 | Costs | Via | Via | 794 | to DFZ | ISP_1 | ISP_2 | 795 +---------+-------+-------+ 796 | BR_101 | 1* | 7 | 797 | BR_201 | 7 | 1* | 798 | R_1 | 3* | 6 | 799 | R_2 | 6 | 2* | 800 | R_3 | 7 | 3* | 801 | R_4 | 10 | 6* | 802 +---------+-------+-------+ 804 The optimized source address selection facility is also of utility in 805 the other scenarios. For example, the cost of the link to the ISP 806 could be set depending of bandwidth and optionally on utilization. 807 Nodes would use a near uplink to an ISP, and as a result some form of 808 load distribution is enabled. Note that nodes still can use the 809 alternative addresses, in fact it is recommended to use multi-path 810 transport protocols for better load balancing and improved 811 robustness. 813 For isolated MANETs, a DHCP server election mechanism can be used. 814 Nodes may initiate to advertise a self-generated ULA. In such cases, 815 it is recommended that a prefix is used with a 56-bit random ULA 816 identifier (including random 16-bit Subnet ID) and 64-bit prefix 817 length. Other nodes join this prefix, although some may wish to 818 start or continue using their own prefix. The latter would occur in 819 cases of a merge of previous isolated MANETs. 821 3. Border Router Discovery Protocol (BRDP) 823 BRDP is an extension to the IPv6 ND mechanism [RFC4861] that provides 824 information about the reachability, availability, prefix information, 825 quality and cost of upstream providers, and enables automated 826 (re)numbering of possibly multi-homed routers and hosts. 828 BRDP adds the Border Router Information Option (BRIO) to the Router 829 Advertisement (RA) of IPv6 ND. A BRIO contains all relevant 830 information of an upstream Border Router and the corresponding 831 provider. 833 Border Routers initiate sending BRIO messages, other routers in the 834 network disseminate the messages downstream through the network. 835 Nodes store the information from received BRIOs in a BRIO cache, to 836 be used for address generation, DHCP server discovery, address 837 selection or packet forwarding. 839 A BRIO cache entry records reception of a BRIO for a single 840 advertised prefix, received via a neighbor router. Border Routers 841 that need to advertise multiple prefixes simply use multiple BRIOs, 842 each with its own address prefix. For further processing of BRIO 843 entries, only the entry with the lowest cost to a Border Router is 844 used, for each Border Router. 846 When a node is multi-homed, it will receive BRIOs from multiple 847 upstream Border Routers. 849 3.1. Border Router Information Option (BRIO) 851 The Border Router Information Option carries information that allows 852 a nodes in the edge network to select and utilize a Border Router. 854 0 1 2 3 855 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Type | Length | Prefix Length |D| reserverd | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Sequence Number | Hopcount | reserved | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Uniform Path Metric | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | reserved | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | | 866 + ( Border Router prefix ) + 867 | | 868 + Border Router Address + 869 | | 870 + ( rest of Border Router Address ) + 871 | | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 Figure 7: BRIO base option 876 Fields: 878 Type: 879 8-bit identifier of the Border Router Information Option type. 880 The value of this option identifier is to be determined. 882 Length: 883 8-bit unsigned integer. The length of the option (including the 884 type and length fields) in units of 8 octets. A BRIO has a length 885 value of 4. 887 Prefix Length: 888 8-bit unsigned integer. The number of leading bits in the Border 889 Router Address, that indicates the assigned prefix for that Border 890 Router. The Prefix Length is used for BRDP Based Routing, as 891 described in Section 6. 893 DHCP (D): 894 When the D-flag is set, the Border Router is acting as a DHCP 895 server or DHCP relay agent [RFC3315]. 897 reserved: 898 Reserved bits. Currently unused, set to 0. 900 Sequence Number: 901 16-bit unsigned integer. It is set by the Border Router and 902 incremented with each new BRIO it sends on a link. When 903 forwarding downstream, the sequence number is not changed. 905 Hopcount: 906 8-bit field registering the number of hops from the advertizing 907 Router to the Border Router. Border Routers send the initial BRIO 908 with its Hopcount set to zero. Routers increment the Hopcount by 909 one when forwarding a BRIO. 911 Uniform Path Metric (UPM): 912 A measure for the cost of the bi-directional path between the 913 upstream Router and the Default Free Zone of the Internet. 914 Uniform Path Metric is set to some initial value by the Border 915 Router and is incremented by each Router forwarding the BRIO. 917 Border Router Address: 918 128-bit address of the Border Router. For reachability, the 919 Border Router is expected to add this own address (prefix) in the 920 routing system. 922 3.2. BRDP processing 924 The main BRDP processing functions of a Router are BRDP message 925 generation, transmission and reception and the maintenance of a BRIO- 926 Cache. Routers forward BRDP messages using ICMP ND Router 927 Advertisements. 929 3.2.1. BRDP message generation and transmission 931 A BRDP message is part of a Router Advertisement and includes a set 932 of BRIOs. It provides the current state of (paths to) the Border 933 Routers listed in the set of BRIOs. BRIOs originate from a Border 934 Router, and contain initially metric information on connectivity to 935 the Internet. BRIOs are forwarded downstream in the edge network. 937 When a Router sends a ICMP ND Router Advertisement, it SHOULD include 938 a set of BRIOs by appending them to the message. The maximum number 939 of BRIOs in a single BRDP message is a Router configuration 940 parameter. BRIO selection for advertisement is done based on the 941 information stored in the BRIO-Cache. BRIOs that do not pass the 942 loop prevention check described in Section 3.2.4 SHOULD NOT be 943 selected. 945 The UPM and Hopcount fields of the advertised BRIOs are updated. An 946 UPM-increment, based on uniformed bi-directional link metrics, is 947 added to the UPM and the Hopcount is incremented by 1. UPM-increment 948 MAY be governed by a hysteresis and dampening mechanism. Also 949 forecasted information MAY be used. 951 Each BRIO originating from a Border Router has an increased Sequence 952 Number. This BRIO is forwarded in the edge network and refreshes 953 entries in BRIO-Caches of downstream Routers. 955 Router Advertisements are sent in response to Router Solicitation 956 messages or unsolicited with a uniformly-distributed random interval 957 between MinRtrAdvInterval and MaxRtrAdvInterval [RFC4861]. The 958 MaxRtrAdvInterval falls between a minimum of 30 milliseconds, 959 specified in [RFC6275] and a maximum of 1800 seconds, specified in 960 [RFC4861]. In addition, the Router MAY send a Router Advertisement 961 when an important change in a to be sent BRIO would occur. 963 When a Router sends Router Advertisements more frequently than an 964 upstream Router, this Router MAY repeatedly send BRIOs with a 965 constant Sequence Number but with an updated UPM or Hopcount. 967 The ICMP ND Router Advertisement MAY include the Advertisement 968 Interval Option [RFC6275]. This option contains the interval at 969 which the sending router sends unsolicited multicast Router 970 Advertisements. 972 A Router SHOULD inform downstream Routers in case the path to a 973 previous advertised Border Router is lost, by at least 3 times 974 retransmitting the previously sent BRIO with a UPM value of 975 4294967295. 977 In case a Border Router loses its connection to the infrastructure it 978 will lose its Border Router functionality and become a normal Router. 979 In that case it performs the same procedure as a Router that has lost 980 the path to a previous advertised Border Router. 982 For each Border Router listed in the BRIO-Cache, the UPM-loop- 983 prevention-threshold and the Hopcount-loop-prevention-threshold 984 variables are maintained. These variables are used by the loop 985 prevention mechanism described in Section 3.2.4. The thresholds are 986 set or updated when sending BRDP messages. When sending a BRIO with 987 a higher Sequence Number than the previously sent BRIO for that 988 Border Router, the threshold variables are set to the UPM and 989 Hopcount values in BRIO to be sent. When sending a BRIO with the 990 same Sequence Number as the previously sent BRIO, the loop- 991 prevention-thresholds are independently updated if either the UPM or 992 Hopcount of the outgoing BRIO is lower than their thresholds. 994 A Router that detects an attractive candidate BRIO but is prohibited 995 from using it because of the loop prevention check, MAY send a 996 (unicast) Router Solicitation message to the Border Router. The 997 Border Router responds to such a Router Solicitation message with a 998 new BRIO. Sending Router Solicitations MUST be rate limited. A next 999 version of this document would include a specification for sending 1000 the unicast Router Solicitation message. 1002 3.2.2. BRDP message reception 1004 When a BRDP message is received, the Sequence Number fields of the 1005 contained BRIOs are checked; the Sequence Number of a received BRIO 1006 MUST be equal to or higher than the Sequence Number in the cache for 1007 an existing entry in the cache, with wrap-around checking. 1008 Otherwise, the BRIO will be discarded. 1010 BRIO messages do not need to be forwarded at fixed time intervals, 1011 because the RA intervals on different Routers are not synchronized. 1012 Therefore, large gaps in Sequence Numbers may occur. Increment 1013 values between 0 and 65000 are accepted. Increment values between 1014 65001 and 65535 are rejected. 1016 Information in received BRIOs is stored in a BRIO-Cache table. Other 1017 information is stored as well, such as the BRIO upstream node, a 1018 timestamp indicating when the most recent message was received and 1019 the measured or signaled RA interval. 1021 3.2.3. BRIO-Cache maintenance 1023 Each Router maintains a BRIO-Cache that stores all information on 1024 Border Routers. Unique cache entries are maintained on (Border 1025 Router Address, address of the upstream router that forwarded the 1026 BRIO) tuples. This information is obtained by receiving BRIOs, or, 1027 in case of a Border Router, by getting information from the interface 1028 that connects to the Internet. The BRIO-Cache also maintains context 1029 information for the BRIO such as the BRIO sender, link metrics and 1030 UPM-increment for this sender, history, statistics and status 1031 information. History information includes a timestamp indicating 1032 when the most recent message was received and a measured or signaled 1033 RA interval. Status information includes the BRIO selection outcome 1034 for BRIO forwarding as explained in Section 3.2.1 and the Border 1035 Router selected for address generation as explained in Section 4. 1037 BRIO entries in the BRIO-Cache stay valid for a certain period of 1038 time. During this period, they can be used for Border Router 1039 selection by the Router, for forwarding BRIOs and for address 1040 generation. BRIO-Cache information could also be useful for source 1041 address selection [RFC6724]. The lifetime of a BRIO is determined by 1042 using the timing information sent along with the RA ([RFC6275], 1043 section 7.3) or statistics of received BRIOs. 1045 Some values in the BRIO-Cache can be updated independent of incoming 1046 BRDP messages. A Router MAY update the UPM-increment based on link 1047 quality measurements performed in an environment with changing link 1048 metrics. A Router SHOULD indicate in its BRIO-Cache which BRIO 1049 entries are currently selected for forwarding and for address 1050 generation. Border Router Selection MAY take place after the UPM of 1051 a BRIO entry has been updated. 1053 In case the link to the Router from which a BRIO has been received is 1054 broken, the UPM and the Hopcount of the BRIO entry in the cache are 1055 set to the maximum value, i.e. 4294967295 and 255. 1057 A cache cleanup routine SHOULD run at regular intervals to get rid of 1058 stale entries. Stale entries are removed when the entry is not 1059 updated for 5400 seconds or all of the following conditions are met: 1060 o The stale entry is not used by the Router itself for address 1061 generation. 1062 o The stale entry was not selected for forwarding in the last three 1063 Router Advertisement. 1064 o The stale entry was not recently updated by a received BRIO. In 1065 this context, recently is defined as the maximum of a) three times 1066 its own unsolicited multicast Router Advertisements interval and 1067 b) three times the senders unsolicited multicast Router 1068 Advertisements interval. 1070 Cache entries MAY also be removed, under the condition that the BRIO- 1071 Cache has reached a configured maximum number of entries and a new, 1072 to be stored BRIO is received. A removal candidate is selected based 1073 on: 1074 o The candidate entry is not used by the Router itself. 1075 o The candidate entry was not selected for forwarding in the last 1076 Router Advertisement. 1077 o The candidate entry is redundant; other information for the same 1078 Border Router is stored in the cache with a better UPM and / or 1079 was received more recently. 1080 o The candidate entry is redundant; other information for the same 1081 Service Selection Identifier is stored in the cache with a better 1082 UPM and / or was received more recently. 1083 o The candidate entry is less attractive; other Border Routers are 1084 stored in the cache with better UPM and / or were received more 1085 recently. 1087 3.2.4. BRDP loop prevention 1089 A BRDP loop check mechanism prevents that a Router forwards an 1090 earlier advertized BRIO. 1092 BRDP loop-free operation is guaranteed as long as at least one of the 1093 following conditions is true: 1094 o The to be sent BRIO has a higher Sequence Number than a BRIO for 1095 this Border Router that was sent before. The loop check mechanism 1096 uses wrap-around logic. Increments up to 32768 are acceptable 1097 (wrap-around logic needs checking). 1098 o The to be sent BRIO is generated from the same BRIO-Cache entry as 1099 the BRIO that was sent most recently. 1100 o The to be sent BRIO has the same Sequence Number as the BRIO for 1101 this Border Router that was sent before but the BRIO-Cache entry 1102 UPM is equal to or lower than the UPM-loop-prevention-threshold 1103 for this Border Router. 1104 o The to be sent BRIO has the same Sequence Number as the BRIO for 1105 this Border Router that was sent before but the BRIO-Cache entry 1106 Hopcount is equal to or lower than the Hopcount-loop-prevention- 1107 threshold for this Border Router. 1109 In some circumstances, a Router would select a BRIO for forwarding 1110 that fails the loop prevention check. For example, the link to the 1111 upstream neighbor is lost and an alternative path is available, with 1112 a higher UPM and a higher Hopcount or with a lower Sequence Number. 1113 The Router cannot assure this candidate BRIO is not reflecting its 1114 own advertized message, therefore it should not send this BRIO. 1115 Instead, it sends a unicast Router Solicitation message to that 1116 Border Router. 1118 3.3. Unified Path Metric (UPM) 1120 Unified Path Metric (UPM) is a measure for the cost of the path 1121 between the Router and the Internet Default Free Zone. It is a 1122 united metric for both inbound and outbound paths. On each hop, the 1123 UPM is incremented with an UPM-increment, which is derived from the 1124 routing protocol and / or is obtained from lower layers. 1126 It is on forehand not known what is more important; Border Router 1127 selection based on path metric to the Border Router or the path 1128 metric for the reverse path. In BRDP, UPM is used for optimizing 1129 Border Router selection for both the inbound and the outbound 1130 traffic. Note that actual traffic will use the path provided by the 1131 routing protocols, not by BRDP. 1133 Since the UPM uses 32 bits, its maximum value is 4294967295. On each 1134 hop, an UPM-increment is calculated for each Router from which a BRIO 1135 has been received. UPM-increments have a value between 1 and 1136 16777215, to support a 255 hop path, with maximum UPM increments. 1138 Further discussion on metrics and how the UPM-increment value is 1139 determined is outside the scope of this document. 1141 4. BRDP based Address Configuration and Prefix Delegation 1143 BRDP supports stateless address autoconfiguration [RFC4862], DHCP 1144 managed IP configuration [RFC3315] and DHCP Prefix Delegation 1145 [RFC3633]. Routers can also use a variant of stateless address 1146 autoconfiguration, where BRDP provided information is used to 1147 configure Router management interfaces or used to configure off-link 1148 addresses, used in ad hoc networks [RFC5889]. 1150 BRDP adds topology awareness in address configuration. Nodes can 1151 configure multiple addresses, each to support a different facility. 1152 ULAs can be used for site internal traffic. Global addresses are 1153 mandatory for access to the Internet, assuming address translation is 1154 not used. 1156 A node that is offered multiple prefixes for stateless address 1157 autoconfiguration or multiple addresses by DHCP chooses to configure 1158 one or more addresses. BRDP provides information for the candidate 1159 addresses. An important criterium is the costs of the path to the 1160 Internet DFZ. A node would prefer addresses with lower costs. 1162 BRDP does not modify stateless address autoconfiguration and DHCP 1163 protocols, except that in a edge network, Routers may perform 1164 stateless address autoconfiguration from the Border Router 1165 Information Option (BRIO), for their management or MANET interfaces. 1166 This enables edge network-wide address configuration, because BRIOs 1167 are disseminated over multiple hops in the edge network, while PIOs 1168 are link local messages only. 1170 When a BRIO is stored in the BRIO cache table, the node checks if a 1171 corresponding address already exists for the Border Router from which 1172 this BRIO originates. If not, and a corresponding address for that 1173 Border Router is beneficial, address generation for that Border 1174 Router is triggered. 1176 4.1. Border Router selection 1178 When a node needs to communicate to nodes on the Internet, it MUST 1179 select a (set of) Border Router(s) for address generation. A node 1180 MAY generate multiple addresses for smooth handover implementing 1181 make-before-break or distributing traffic over multiple Border 1182 Routers. A description how Border Routers can be used concurrently 1183 is out-of-scope for this document. 1185 Information concerning available Border Routers is kept in the BRIO- 1186 Cache. 1188 The Border Router selection mechanism MAY be triggered by received 1189 BRDP messages, changes in metrics on links to neighbors advertising 1190 BRDP messages, changes in costs to Border Routers used or on a time- 1191 driven basis. 1193 The Border Router selection algorithm SHOULD be based on UPM. UPM is 1194 used for selecting the Border Router with the best connectivity to 1195 the Internet. The Border Router selection algorithm MAY be extended 1196 with any other information. Future defined BRIO suboptions could 1197 provide additional information, such authorization and service 1198 selection. Border Router selection MAY be based on the type of the 1199 Border Router Address, e.g. a globally unique address or a unique 1200 local address. 1202 Border Router selection does not provide nor select a routing path to 1203 the Border Router. 1205 4.1.1. Border Router Selection based on UPM 1207 The node uses the UPM for Border Router selection preferring the best 1208 bi-directional paths between the node and the Internet. Note that 1209 the BRIO UPM includes the initial metric set by the Border Router and 1210 is not solely a metric between the node and the Border Router. The 1211 initial metric set by Border Routers can be used for Border Router 1212 preference and for load balancing. 1214 In order to use an up-to-date UPM in the selection procedure the UPM- 1215 increment is calculated by the node before selecting a Border Router. 1216 UPM is discussed in Section 3.3. 1218 4.2. Address autoconfiguration 1220 Nodes should use a topologically correct address when communicating 1221 with corresponding nodes on the Internet. Topologically correct 1222 addresses should be configured for each Border Router used. 1224 4.2.1. Address and prefix configuration with SLAAC or DHCP 1226 Nodes can use existing IPv6 address configuration protocols, such as 1227 SLAAC [RFC4862] and DHCP [RFC3315]. Nodes can use SLAAC based on 1228 prefix information, provided by the upstream router. Nodes may use 1229 DHCP multicast and neighbor routers will relay those packets to 1230 selected Border Routers with D-flag set or reply with DHCP parameters 1231 it has received from a Border Router before for itself. 1233 Nodes using SLAAC may also query a DHCP server on a Border Router 1234 themselves for additional parameters, using the BRDP learned address 1235 of the DHCP server. 1237 A Router should request a prefix for attached subnetworks, with 1238 DHCP-PD [RFC3633], where there is at that moment no on-link prefix 1239 for a selected Border Router. 1241 4.2.2. Address generation and configuration for Routers 1243 A generated address for a Router management interface or a MANET has 1244 a /128 prefix. It is constructed from a 64-bit Interface Identifier 1245 and a 64-bit prefix from the Border Router Address. The generated 1246 128-bit address SHOULD be advertised in the routing system. The 1247 generated address may be used for user traffic, either inside the 1248 edge network or traffic towards the Internet. 1250 For the Interface Identifier used, the BRDP-based Address Generation 1251 MUST implement a mechanism for generating a highly unique Interface 1252 Identifier. Known mechanisms are: 1253 o Modified EUI-64 format-based Interface Identifier, [RFC4291], 1254 based on IEEE 802 48-bit MAC address or IEEE EUI-64 identifier. 1255 However, this method does not guarantee identifiers are unique as 1256 duplicate MAC addresses can occur. 1257 o Generation of randomized Interface Identifiers, [RFC4941]. 1258 o Well-distributed hash function, [RFC3972]. 1260 After Address Generation, RFC4429 Optimistic Duplicate Address 1261 Detection [RFC4429] should be used. A passive Duplicate Address 1262 Detection, based on information in the routing protocol information 1263 bases could be used as an alternative. Still, uniqueness is not 1264 fully guaranteed. Main reasons for non-uniqueness are merging of 1265 edge network segments, node movement, node misbehavior or address 1266 spoofing attacks. Details on handling a duplicate address condition 1267 are out-of-scope for this document. 1269 A generated addresses clean-up routine SHOULD run at regular 1270 intervals to get rid of stale addresses. 1272 4.2.3. Support for Unique Local Addresses (ULA) 1274 Address generation for globally unique addresses and unique local 1275 addresses (ULA) [RFC4193] is equivalent. If no BRIO for a unique 1276 local addresses is available, a router may start as a Border Router 1277 and DHCP server for a self generated 48-bit ULA prefix. 1279 5. BRDP based Source Address Selection 1281 As a next step, multi-homed nodes perform source address selection 1282 for new, self-initiated connections. The algorithm described in 1283 Default Address Selection for IPv6 [RFC6724] uses the concept of a 1284 "candidate set" of potential source addresses. Rule 8 of source 1285 address selection is "Uses longest match prefix". The goal of this 1286 rule is to select the address with good communications performance. 1287 If other means of choosing among source addresses for better 1288 performance is available, that should be used. 1290 BRDP provides attributes for prefix, such as a cost metric to the 1291 Internet. This information van be used to select the "best" source 1292 address. For multi-path transport protocols, it is also important to 1293 have a mechanism to select alternative addresses. For example, rule 1294 4 gives preference to a Home Address. Alternate addresses can be 1295 used for route optimization and to avoid overhead of the Mobile IP 1296 tunnel. 1298 5.1. Address Selection for dynamic DNS 1300 BRDP provided information can also be utilized by address lookup 1301 protocols such as DNS. A node can register its addresses 1302 dynamically, with support of preference and load balancing if the 1303 mechanism used support such. 1305 6. BRDP based Routing 1307 BRDP introduces a new paradigm for packet forwarding for multi-homed 1308 sites, where forwarding to a default gateway is replaced by source 1309 address based forwarding towards a corresponding Border Router. This 1310 enforces that packets will be sent via the selected upstream 1311 provider, without the need of tunneling. As such, it prevents 1312 problems with ingress filters in multi-homed edge networks [RFC3704]. 1314 The BRDP Based Routing mechanism provides basic support for load 1315 distribution over multiple Border Routers. BRDP Based Routing 1316 forwards the packets to the Border Router that corresponds with the 1317 source address. As a result, nodes can utilize multiple paths, if 1318 available. Standardization of this load balancing functionality is 1319 work in progress in the IETF MPTCP working group. 1321 When a router forwards a packet to a next-hop node, via the interface 1322 where this packet was received, and the next-hop address was selected 1323 using BRDP based routing, then the router should not send an ICMP 1324 redirect message to that host. This is because the upstream node 1325 would cache the redirect for the destination address, while the 1326 forwarding decision was based on the source address. 1328 6.1. Problems with default gateway routing 1330 Usually, the nexthop selection is based on the destination address. 1331 In case of default gateway routing and multiple exit routers to 1332 multiple providers, the source has no influence on what exit router 1333 is used. In case of ingress filtering and lack of a mechanism to 1334 redirect packets to exit routers that correspond to the source 1335 address, packets may be dropped. 1337 This default gateway routing behavior blocks incremental enhancement 1338 of the Internet, e.g. through the addition of support for more 1339 dynamic networks and / or host based load distribution mechanisms. 1340 In a MANET, it also also prevents the use of make-before-break 1341 [RFC3753] mechanisms. 1343 6.2. Default gateway routing replaced with BRDP Based Routing 1345 Default gateway based routing for IPv4 is defined in [RFC1812], 1346 section 5.2.4.3: 1348 (5) Default Route: This is a route to all networks for which there 1349 are no explicit routes. It is by definition the route whose 1350 prefix length is zero. 1352 With BRDP Based Routing, another type of route is introduced: 1354 (6) BRDP Route: This is a route to all networks for which there 1355 are no explicit routes, and a default route is not used. 1356 The nexthop IP address is found by means of a Border Router 1357 Information Cache (BRIO-Cache) lookup based on the source 1358 address and, if a matching BRIO-Cache entry is found, a 1359 subsequent FIB lookup based on the selected Border Router 1360 address. 1362 Note that route types (3) and (4) are not defined in RFC1812. 1364 BRDP Based Routing can be turned on and off with the existence of a 1365 default route in the IGP. This switch function might be useful in 1366 migration scenarios towards BRDP Based Routing. 1368 The Border Router should run the IGP on the interface with the BRDP 1369 advertized Border Router address, to make sure this address is 1370 reachable in the edge network. 1372 In the edge network, all interior routers should run BRDP and BRDP 1373 Based Routing. All interior routers will have a BRIO-Cache with 1374 information for selecting Border Routers as exit points to the 1375 Internet. A BRIO-Cache entry contains a Border Router address and a 1376 summary prefix assigned to that Border Router. BRIO-Cache lookup 1377 follows the longest-match rule. 1379 Forwarding is solely based on FIB lookups, the nexthop IP address is 1380 found either by a FIB lookup with the destination address or by a FIB 1381 lookup with the address of the Border Router that corresponds with 1382 the source address. If the nexthop IP address lookup fails, the 1383 packet is discarded. 1385 7. BRDP and IRTF RRG goals 1387 The IRTF Routing Research Group (RRG) was chartered to explore 1388 solutions for problems on routing and addressing, when the Internet 1389 continues to evolve. It has explored a number of proposed solutions, 1390 but did not reach consensus on a single, best approach 1391 [I-D.irtf-rrg-recommendation]. In fulfillment of the routing 1392 research group's charter, the co-chairs recommend that the IETF 1393 pursue work in three areas, "Evolution" [I-D.zhang-evolution], 1394 "Identifier/Locator Network Protocol (ILNP) [I-D.rja-ilnp-intro] and 1395 "Renumbering" [RFC5887] . BRDP fits in all three approaches. 1397 BRDP is an evolution in IPv6 address configuration and address 1398 selection, as well as forwarding to destinations outside the routing 1399 domain. As a result, it removes a demand for Provider Independent 1400 addresses for (small) multi-homed edge networks. BRDP enables sites 1401 to use multiple Provider Aggregatable address blocks, while being 1402 able to utilize multi-homing for improved redundancy of 1403 communications and enlarged capacity. Each site that continues to 1404 use Provider Aggregatable addresses when getting multi-homed, instead 1405 of using its own Provider Independent address space, reduces the 1406 growth of the routing tables in the Default Free Zone. 1408 BRDP can cooperate or live next many other solutions. ILNP is a good 1409 example for cooperation, BRDP provides multi-path transport 1410 capabilities to ILNP nodes. This multi-path transport capability 1411 applies to many other approaches also, such as map&encap and nat66. 1413 Because BRDP provides automatic address and prefix configuration, 1414 Renumbering is far less problematic. That said, legacy (IPv4) hosts, 1415 applications and network equipment is not BRDP enabled and manual 1416 address configuration will be used for many years to come. 1418 In Design Goals for Scalable Internet Routing 1419 [I-D.irtf-rrg-design-goals], a number of design goals are defined. 1420 The role BRDP can play for these goals are briefly described in the 1421 next sections. 1423 7.1. Scalability 1425 Because BRDP is implemented in edge networks, and not in the core, 1426 scalability of BRDP is less an issue. BRDP solves the Internet 1427 routing problem at the source, by reducing the demand for PI 1428 addresses. 1430 7.2. Traffic engineering 1432 BRDP provides traffic engineering options to end-nodes. End-nodes 1433 can configure multiple addresses and use these for utilizing multi- 1434 path capabilities of the network. Using multi-path is being worked 1435 on by the IETF MPTCP working group. 1437 7.3. Multi-homing 1439 The core function of BRDP is providing support for IPv6 multi-homing, 1440 without any problems caused by ingress filtering [RFC3704]. 1442 7.4. Loc/id separation 1444 BRDP does not mandate any approach for location / identification. 1445 For packet forwarding, addresses are used as locator. If addresses 1446 are used as identifiers also, for example in Mobile IP, BRDP supports 1447 route optimization where traffic uses the Home Address as identifier 1448 and care-of addresses as locator. MPTCP provides the route 1449 optimization capability. 1451 7.5. Mobility 1453 BRDP was defined as a solution for address autoconfiguration for ad 1454 hoc networks. With BRDP, nodes can easily configure topology correct 1455 addresses in a multi-homes ad hoc network. BRDP does not provide 1456 session continuity functions. Mobility solutions are already in 1457 place or new approaches are proposed. All approaches should work 1458 well with BRDP, as BRDP does not modify the IPv6 protocol. 1460 7.6. Simplified renumbering 1462 BRDP makes site renumbering fully automatic. This applies to node 1463 address configuration on the IPv6 stack and prefix delegation and 1464 configuration on routers. IP addresses could be configured on many 1465 other places, either manually or using specific protocols for such 1466 purpose. Complete automatic numbering is possible if all mechanisms 1467 in use support dynamic addresses. There is definitely more work to 1468 do [RFC5887]. 1470 7.7. Modularity 1472 BRDP is a small, but important piece of the puzzle. It applies to 1473 edge networks only. It helps other mechanisms to work well in a 1474 multi-homed network using PA addresses, but also provides multi-path 1475 capabilities in multi-homed networks with PI addresses or multi- 1476 homing with connections to Extranets. 1478 7.8. Routing quality 1480 BRDP is not a routing protocol, so it has no influence on routing 1481 quality. But the functionality of routing to a default gateway is 1482 changed. BRDP based routing supports paths to multiple Border 1483 Routers, where hosts can select which Border Router to use. In such 1484 scheme, nodes can select the route to use, based on quality of 1485 available routes. MPTCP provides this route selection functionality. 1487 7.9. Routing security 1489 BRDP doesn't update any routing protocols. BRDBP based routing 1490 modifies the default gateway heuristic, the route to prefix ::/0 is 1491 replaced by a route to a Border Router, which corresponds with the 1492 source address of a packet. As a result, ingress filtering is 1493 distributed over all routers in the edge network and invalid packets 1494 are dropped as near to the source as possible. 1496 The BRDP protocol runs on IPv6 NDP and inherits all security aspects. 1497 BRDP messages are disseminated in the edge network, which may enlarge 1498 the needs for protection. Implementing SeND [RFC3971] is 1499 recommended. 1501 7.10. Deployability 1503 BRDP deployment takes place edge network by edge network. Each 1504 network that migrates to BRDP, instead of getting a PI address bock, 1505 reduces the load on the Internet routing infrastructure. 1507 For implementing BRDP on an edge network, all routers in the network 1508 must support BRDP. BRDP support for hosts is optional. Enterprise 1509 networks can migrate site by site. 1511 8. Currently unaddressed issues 1513 BRDP based routing may have impact on multicast routing, e.g. 1514 selecting the route to a RP. 1516 It is not fully understood how BRDP may influence host behavior on RA 1517 M and O bits, and may bypass a 1-hop router DHCP relay server for 1518 getting information for a BRDP-learned DHCP server. 1520 Currently unaddressed issues are to be addressed in a next version of 1521 this document. 1523 9. Acknowledgements 1525 BRDP is inspired by MANEMO technology; thanks to all who contributed 1526 to it. Thanks to Arjen Holtzer (TNO), co-author of earlier Internet 1527 drafts on BRDP. Thanks to Ran Atkinson, who guided me towards a BRDP 1528 Based Routing mechanism that does not rely on routing headers or 1529 encapsulation. 1531 10. IANA Considerations 1533 TBD 1535 11. Security Considerations 1537 TBD 1539 12. Change log 1541 This -00 version is gathering the material of BRDP, produced for 1542 Autoconf and RRG. It is a bit cleaned up, with removal of some 1543 details for MANET and with removal of options for emergency services, 1544 service selection and authorization. 1546 13. References 1548 13.1. Normative References 1550 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1551 RFC 1812, June 1995. 1553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1554 Requirement Levels", BCP 14, RFC 2119, March 1997. 1556 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1557 RFC 3753, June 2004. 1559 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1560 RFC 3972, March 2005. 1562 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1563 Addresses", RFC 4193, October 2005. 1565 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1566 Architecture", RFC 4291, February 2006. 1568 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1569 for IPv6", RFC 4429, April 2006. 1571 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1572 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1573 September 2007. 1575 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1576 Address Autoconfiguration", RFC 4862, September 2007. 1578 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1579 Extensions for Stateless Address Autoconfiguration in 1580 IPv6", RFC 4941, September 2007. 1582 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1583 "Default Address Selection for Internet Protocol Version 6 1584 (IPv6)", RFC 6724, September 2012. 1586 13.2. Informative References 1588 [I-D.ietf-homenet-arch] 1589 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1590 "Home Networking Architecture for IPv6", 1591 draft-ietf-homenet-arch-04 (work in progress), July 2012. 1593 [I-D.ietf-mptcp-multiaddressed] 1594 Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1595 "TCP Extensions for Multipath Operation with Multiple 1596 Addresses", draft-ietf-mptcp-multiaddressed-10 (work in 1597 progress), October 2012. 1599 [I-D.irtf-rrg-design-goals] 1600 Li, T., "Design Goals for Scalable Internet Routing", 1601 draft-irtf-rrg-design-goals-06 (work in progress), 1602 January 2011. 1604 [I-D.irtf-rrg-recommendation] 1605 Li, T., "Recommendation for a Routing Architecture", 1606 draft-irtf-rrg-recommendation-16 (work in progress), 1607 November 2010. 1609 [I-D.kline-default-perimeter] 1610 Kline, E., "Default Perimeter Identification", 1611 draft-kline-default-perimeter-00 (work in progress), 1612 July 2012. 1614 [I-D.rja-ilnp-intro] 1615 Atkinson, R., "ILNP Concept of Operations", 1616 draft-rja-ilnp-intro-11 (work in progress), July 2011. 1618 [I-D.zhang-evolution] 1619 Zhang, B. and L. Zhang, "Evolution Towards Global Routing 1620 Scalability", draft-zhang-evolution-02 (work in progress), 1621 October 2009. 1623 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1624 Defeating Denial of Service Attacks which employ IP Source 1625 Address Spoofing", BCP 38, RFC 2827, May 2000. 1627 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1628 and M. Carney, "Dynamic Host Configuration Protocol for 1629 IPv6 (DHCPv6)", RFC 3315, July 2003. 1631 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1632 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1633 December 2003. 1635 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1636 Networks", BCP 84, RFC 3704, March 2004. 1638 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1639 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1641 [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 1642 Selection for Mobile IPv6", RFC 5149, February 2008. 1644 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1645 Still Needs Work", RFC 5887, May 2010. 1647 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1648 Hoc Networks", RFC 5889, September 2010. 1650 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1651 in IPv6", RFC 6275, July 2011. 1653 Author's Address 1655 Teco Boot 1656 Infinity Networks B.V. 1658 Email: teco@inf-net.nl