idnits 2.17.1 draft-shytyi-v6ops-danir-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2019) is 1682 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Shytyi 3 Internet-Draft SFR 4 Intended status: Informational A. Petrescu 5 Expires: March 20, 2020 CEA, LIST 6 September 17, 2019 8 DHCPv6_PD, PDP and NDP Implementation in IoT Router (DANIR) 9 draft-shytyi-v6ops-danir-04 11 Abstract 13 This document provides a description of the implementation of Dynamic 14 Host Configuration Protocol version 6 Prefix Delegation, Neighbour 15 Discovery Protocol and of the use of the Packet Data Protocol in an 16 Internet of Things Router. This Internet of Things Router is 17 connected on a cellular network; it is a DHCPv6-PD Client and it 18 requests a /56 pool of prefixes from the server; the DHCPv6-PD server 19 is placed in the PGW and is a part of the cellular infrastructure. 20 After the pool of prefixes is delegated, the Internet of Things 21 Router derives sub-prefixes from the prefix pool; each one of these 22 sub-prefixes is aimed at one ingress interface. 24 After the Internet of Things Router finishes the network prefix 25 assignment procedure, it advertises the network prefixes on the 26 ingress links by using the Neighbour Discovery protocol. Finally, 27 when Hosts receive the sub-prefixes via Router Adverticement 28 messages, they configure the Global Unique Address with the Stateless 29 Address Auto-configuration protocol. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 20, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. Environment . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.1. Solicitation of the network prefix pool . . . . . . . . . 9 72 5.1.1. The Packet Data Protocol . . . . . . . . . . . . . . 9 73 5.1.2. The Dynamic Host Configuration Protocol version 6 74 with Prefix Delegation . . . . . . . . . . . . . . . 9 75 5.1.3. Option: PPP use . . . . . . . . . . . . . . . . . . . 12 76 5.2. Assignment of the network prefixes on the links . . . . . 12 77 5.3. Advertisement of the network prefixes . . . . . . . . . . 15 78 5.4. DHCPv6 Port range . . . . . . . . . . . . . . . . . . . . 16 79 5.4.1. Client support . . . . . . . . . . . . . . . . . . . 16 80 5.4.2. Server support . . . . . . . . . . . . . . . . . . . 16 81 5.5. Recommendations . . . . . . . . . . . . . . . . . . . . . 16 82 6. Implementation Aspects . . . . . . . . . . . . . . . . . . . 17 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 86 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 This document describes the implementation of the Dynamic Host 92 Configuration Protocol vestion 6 with Prefix Delegation (DHCPv6_PD), 93 Neighbour Discovery Protocol (NDP) and usage of the Packet Data 94 Protocol (PDP) in an Internet of Things (IoT) Router. 96 The use of DHCPv6 Prefix Delegation in LTE networks is overviewed in 97 [RFC6653]. It misses several important aspects. 99 The router MUST be a node that forwards IP version 6 packets not 100 explicitly addressed to itself [RFC8200]. Thus, it has more than one 101 link to perform the forwarding. With multiple links, the need of 102 multiple global unique network prefixes (GUNPs) , assigned to those 103 links, appears. To assign the GUNPs to the links, the Requesting IoT 104 Router Solicits the pool of GUNPs. 106 First, the Requesting IoT Router solicits the pool of the GUNP from 107 the Delegating Router. 109 After the pool is received, the Requesting IoT Router (1) derives 110 GUNPs and (2) performs address autoconfiguration. During the 111 autoconfiguration process the Requesting IoT Router assigns the GUNPs 112 to the links. When the IoT Router finishes the GUNPs assignment 113 procedure, it starts to advertise the GUNPs on the links with NDP 114 [RFC4861]. Meanwhile, the Hosts that are connected to the Requesting 115 IoT Router run the SLAAC mechanism to perform the GUA IP version 6 116 autoconfiguration. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 IoT Router - a device of class IoT. It has several wired and 125 wireless interfaces. One wireless interface is of type cellular, 126 like 4G or 5G. This cellular interface is egress. The other 127 interfaces are ingress. There are at least two ingress interfaces. 128 There is at least one set of two interfaces that can not be bridged 129 together, for example 802.11b and Bluetooth. If all ingress 130 interfaces in the IoT Router can be bridged, for example 802.11b and 131 Ethernet, then there is at least one other router in the same local 132 network as the IoT Router, that can not be bridged to this IoT 133 Router. The IoT Router needs more than one /64 prefix. An example 134 of IoT Router is Sierra Wirelss mangOH Red, or Maestro Wireless E220. 136 Delegating Router - is a node, DHCPv6 server, that chooses prefix(es) 137 for delegation and advertises them to the Requesting Router 138 [RFC3633]. 140 Requesting IoT Router - is a node that behaves as DHCPv6 client. It 141 requests the network prefix(es) and assigns network prefix(es) to the 142 interfaces [RFC6653]. 144 Host - is a node that is not a router. 146 Link - is an entity that enables link layer communication of nodes. 148 Interface - node connection to the link. 150 Link-local address - is an address with usage that is limited by a 151 link. 153 Global Unique Address (GUA) - is an address that is globally 154 available and globally unique. 156 3. Related Work 158 Earlier work considered the use of DHCPv6 Prefix Delegation for 159 Hosts, such as for a smartphone, or for a portable User Equipment. 160 The operation and the implementaiton experience are described in 161 draft-templin-v6ops-pdhost-24.txt. 163 The method of sharing a /64 prefix between the upstream (egress) and 164 downstream (ingress) interface(s) is described in RFC 7278 "64share". 165 This method is used for tethering on millions of Android and Apple 166 devices and smartphones. This method considers that an alternative 167 based on DHCPv6-PD is a solution to a problem that users/providers/ 168 the market does not have. This method may have some issues with 169 existing models and protocols, because it is half way between full 170 routing between interfaces and bridging between interfaces. 172 ND Proxy of RFC 4389 is a potential tool to use a single /64 that is 173 shared between the egress interface and the other interfaces of an 174 IoT Router. 176 4. Overview 178 This section provides an overview of the actions performed on the 179 Delegating Router, Requesting IoT Router and host to perform address 180 assignment on the interfaces with different GUNP. The process of IP 181 version 6 address assignment starts with advertising of the GUNP pool 182 from the Delegating Router to the Requesting IoT Router. To perform 183 such a solicitation, the Requesting IoT Router runs the DHCPv6_PD. 185 +-----------------+ 186 | | 187 | Delegating | 188 | router | 189 | | 190 | (DHCPv6 server) | 191 +-----------------+ 192 | 193 |DHCPv6_PD network prefix 194 POOL |2001:DB8:XYZU:TVWZ::/56 195 | 196 | GUA Prefix_0 /64 197 |interface_0 198 +-------------------------------+ 199 | | 200 | Requesting | 201 | IoT router | 202 | | 203 |(DHCPv6_PDclient + RADVDserver)| 204 +-------------------------------+ 205 |interface_1 |interface_2 |interface_3 206 | | | 207 GUNP |Prefix_1 /64 |Prefix_2 /64 |Prefix_3 /64 208 |SLAAC GUA |SLAAC GUA |SLAAC GUA 209 +-------------+ +------------+ +-------------+ 210 | | | | | | 211 | Host 1 | | Host 2 | | Host 3 | 212 | | | | | | 213 +-------------+ +------------+ +-------------+ 215 (In the above figure the scenario with 3 hosts connected to the 216 Requesting IoT router is presented. Normally there are no number 217 limitations of connected hosts.) 219 When the DHCPv6 message exchange is performed, the Requesting IoT 220 Router receives the pool of IPv6 GUNPs. After the pool of GUNPs is 221 received, the Requesting IoT Router performs the autoconfiguration. 222 Precisely, when the Requesting IoT Router's interface is attached on 223 the link, the Requesting IoT Router assigns to this link the GUNP 224 taken from GUNP pool. The Requesting IoT Router performs the GUNP 225 assignment procedure for multiple links over the interfaces. 226 Finally, this mechanism offers the automated assignment of GUNPs to 227 the links. At the moment of autoconfiguration, the Requesting IoT 228 Router's interfaces are already assigned with link local addresses. 230 The next step of the autoconfiguration phase SHOULD be performed 231 using the Neighbor Discovery protocol. The latter advertises the 232 network's configuration on the links with different interfaces thus 233 with different GUNPs. To perform the GUNPs advertisement, the 234 Requesting IoT ROuter sends the "Router Advertisement Messages" via 235 its interfaces. The Router Avertisement Messages carry the GUNPs 236 that are further used by the stateless autoconfiguration mechanism 237 (SLAAC). There exists an open source implementation of Neighbor 238 Discovery protocol - RADVD sever. With RADVD it is possible to 239 configure hosts interfaces connected to the router's interfaces in 240 automatic manner. It MAY be possible thanks to the fact that hosts 241 run the SLAAC. 243 The IP version 6 stateless autoconfiguration mechanism enables hosts 244 to perform the address autoconfiguration. The SLAAC mechanism SHOULD 245 be used when it is enough to have random unique IP version 6 246 addresses [RFC4862]. The length of the IP version 6 address is N 247 bytes. The first part of the address (128-N bits) consists of the 248 GUNP information associated with a link. The network prefix is 249 advertised by the IoT Router on the link. The second part of the 250 address (8 bytes) consists of interface identifier on the link. The 251 interface identifier SHOULD be generated locally and randomly. 253 +---------------------------------------+------------------------+ 254 | 128 - N bits | N bits | 255 +---------------------------------------+------------------------+ 256 | link prefix | interface identifier | 257 +----------------------------------------------------------------+ 259 (In the above figure, an IP version 6 address scheme is presented 260 [RFC4862].) 262 4.1. Environment 264 This section describes the location of the Delegating Router and the 265 Requesting IoT Router in the cellular provider's infrastructure 266 model. The model is not a real cellular provider infrastructure. 268 After the DHCPv6 packet leaves the cellular interface of the IoT 269 Requesting Router via wireless OFDMA link, it reaches the element of 270 the access network which connects to the user equipment (UEs) - 271 eNodeB station. 273 Further, the packet MAY be transmitted to the Serving Gateway (SGW), 274 as all the user's IP packets. SGW is used to enable the UE movement 275 between eNodeBs. When the UE moves between eNodeBs, the SGW keeps 276 information about the bearers. 278 The final destination of the DHCPv6 packet is the Packet Data Network 279 Gateway, that is responsible for IP address allocation for the UE and 280 for filtering of down-link user's IP packets into the different QoS- 281 based bearers. 283 The model of the infrastructure described in this this section is a 284 simplified example. Real infrastructure construction could contain 285 multiple SGW and eNodeBs and network equipment (that is not described 286 in the current example) with respect of existing standards [RFC6459]. 288 +---------------+ | 289 | PGW | | 290 | Delegating | | 291 | Router | | 292 +---------------+ | 293 | | 294 | | 295 +---------------+ | 296 | SGW | | Cellular infrastructure 297 +---------------+ | 298 | | 299 | | 300 +---------------+ | 301 | eNodeB | | 302 +---------------+ | 303 | | 304 | | 305 ~ ~ Wireless OFDMA 3G/4G 306 | | 307 +---------------+ | 308 | +-------+ | | 309 | | Modem | | | 310 | +-------+ | | 311 | | | | 312 | +-------+ | | 313 | | ARM | | | 314 | +-------+ | | 315 | Requesting | | User Equipment 316 | IoT | | 317 | Router | | 318 +---------------+ | 320 (The above figure descibes the model of the path followed by a DHCPv6 321 packet from IoT requesting router to the Delegating PGW router. The 322 model is not a real infrastructure.) 323 Additional experiments with using of USB dongle were performed. The 324 following figure illustrates the successful DHCPv6-PD test on Orange 325 with dongle. It uses a Huawei E392 USB dongle on laptop (and not the 326 Sierra Wireless mangOH Red). 328 +---------------+ | 329 | PGW | | 330 | Delegating | | 331 | Router | | 332 +---------------+ | 333 | | 334 | | 335 +---------------+ | 336 | SGW | | Cellular infrastructure 337 +---------------+ | 338 | | 339 | | 340 +---------------+ | 341 | eNodeB | | 342 +---------------+ | 343 | | 344 | | 345 ~ ~ Wireless OFDMA 3G/4G 346 | | 347 +---------------+ | 348 | +--------+ | | 349 | | E392 | | | 350 | | USB | | | 351 | | dongle | | | 352 | +--------+ | | 353 | | | | User Equipment 354 | +--------+ | | 355 | | Laptop | | | 356 | +--------+ | | 357 | | | 358 +---------------+ | 360 5. Specification 362 This section presents the process that starts with delegation of 363 Network Prefix pool 2001:DB8:XXXX:XX::/56 from the Delegation Router 364 and finishes with the configuration of IPv6 prefixes on the hosts 365 interfaces. Each Requesting IoT router's interface acts on a unique 366 link. The Host's interfaces, connected to the Requesting IoT router, 367 acts on the same unique links as the Requesting IoT router's 368 interfaces. 370 5.1. Solicitation of the network prefix pool 372 5.1.1. The Packet Data Protocol 374 This section describes how the Requesting IoT Router obtains the GUA 375 address on the Recipient Interface (RI) (OFDMA interface, 3GPP 376 interface). The message "Activate PDP context Accept" is useful for 377 forming the Globally Unique Address on the RI. 379 The Packet Data Protocol [ETSI102361] contains the following types of 380 DLL (Data Link Layer) bearer service data transmissions: unconfirmed 381 data transmission; confirmed data (data transmission; response 382 transmission.) The Packet Data Protocol contains the following types 383 of layer 3 bearer service data transmissions: Internet Protocol; 384 Short Data. These layer 3 bearer services are built on the top of 385 DLL services. 387 ARM Modem eNodeB SGW PGW 388 | | | | | 389 | | PDP | |PDP | 390 | |--------->| |--->| 391 | | | | | 392 | |<---------| |<---| 393 | | | | | 394 | | | | | 396 5.1.2. The Dynamic Host Configuration Protocol version 6 with Prefix 397 Delegation 399 To perform the pool solicitation, the Prefix Delegation options of 400 the Dynamic Host Configuration Protocol version 6 (DHCPv6) are used 401 [I-D.ietf-dhc-rfc3315bis]. 403 The Requesting IoT Router sends the DHCPv6 "Solicit" packet to the 404 Delegating Router via the wireless link. The DHCPv6 "Solicit" packet 405 consists of Client Identifier, Transaction ID, Elapsed time and 406 Identity Association for Prefix Delegation (IA_PD) options. The 407 initial "Solicit" packet triggers the 4 message exchange, that 408 finishes with the reception of the GUNPs pool by the Requesting IoT 409 Router. 411 +------------+ +----------+ 412 | Requesting | | PGW | 413 | IoT | |Delegating| 414 | Router | | Router | 415 +------------+ +----------+ 416 | | 417 | | 418 |1 Solicit | 419 |--------------> | 420 | | 421 | 2 Advertise | 422 | <---------------| 423 | | 424 |3 Request | 425 |--------------> | 426 | | 427 | | 428 | 4 Reply | 429 | <---------------| 430 | | 431 | | 432 | | 434 (In the above figure the full DHCPv6 message exchange mechanism 435 between the ARM part of UE and PGW is presented.) 437 The IA_PD option consists of the Identity Association (IA) - group 438 identifier [RFC3633], parameters (IA id, times to extend the 439 lifetimes of prefixes and prefixes allocated to the IA). The full 440 description of the IA_PD option is presented in the RFC3633 441 [RFC3633]. 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | OPTION_IA_PD | option-length | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | IAID (4 octets) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | T1 | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | T2 | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 . . 455 . IA_PD-options . 456 . . 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 (in the above figure the DHCPv6 IA_PD option format [RFC3633].) 461 The IA_PD-options field carries the IA_PD Prefix Option. The IA_PD 462 Prefix Option carries the recommended preferred/valid life time and 463 IPv6 prefix with prefix length. The additional fields allocated for 464 the options for the advertised GUNP [RFC3633]. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | OPTION_IAPREFIX | option-length | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | preferred-lifetime | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | valid-lifetime | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | prefix-length | | 476 +-+-+-+-+-+-+-+-+ IPv6 prefix | 477 | (16 octets) | 478 | | 479 | | 480 | | 481 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | . 483 +-+-+-+-+-+-+-+-+ . 484 . IAprefix-options . 485 . . 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 (in the above figure the DHCPv6 IA_PD Prefix option format is 489 presented [RFC3633]. 491 The PGW (Delegating Router) advertises, through the usage of a DHCPv6 492 packet, an IPv6 pool 2001:DB8::/56 to the Requesting IoT Router. The 493 packet SHOULD be sent from the cellular infrastructure to the 494 Requesting IoT Router, via the wireless link. The full message 495 exchange consists of: Solicit, Advertise, Request and Reply messages. 497 The "Request", "Reply" messages are used to add/remove/update the 498 assigned prefixes to IA_PDs. 500 The Hop Limit of packets that contain the DHCPv6 data MUST be 255 to 501 satisfy the properties of the cellular infrastructure. To reach the 502 PGW from the UE the DHCPv6 packets are encapsulated by SGW into UDP/ 503 IPv4 packets; this encapsulation is for the GTP-U tunnel. The 504 corresponding decapsulation mechanism decreases the Hop Limit; when 505 the Hop Limit reaches value 0 the packet is discarded; to avoid this 506 situation it is required to put the Hop Limit value of the DHCPv6 507 Solicit equal to 255. 509 5.1.3. Option: PPP use 511 It is possible to use IPv6-over-PPP protocol [RFC1661], with LCP, 512 between the ARM and the modem. This protocol helps with forming an 513 IPv6 link-local address on the IoT Router's RI. 515 ARM Modem eNodeB SGW PGW 516 | | | | | 517 |------->| | | | 518 |PPP LCP | | | | 519 |<-------| | | | 520 | | | | | 521 | | | | | 522 | | | | | 524 5.2. Assignment of the network prefixes on the links 526 The receipt of the IA_PD Prefix option triggers the GUA 527 autoconfiguration on the Requesting IoT Router's interfaces. The 528 Recipient Interface (RI) receives a message with the IA_PD prefix 529 option and does not perform the autoconfiguration on the current 530 stage. 532 All interfaces, except RI, now follow the GUA autoconfiguration 533 procedure. The number of interfaces that should follow the procedure 534 could be specified in the configuration file of the Requesting IoT 535 Router. 537 The GUA interface autoconfiguration procedure in the Requesting IoT 538 Router is done by assigning the network addresses from different 539 GUNPs to the links. The assignment of network addresses is performed 540 using the 2001:DB8:XXXX:XX::/56 network pool. Therefore, the 541 Requesting IoT Router operates on multiple links (ingress links). 543 The IoT Router derives several GUNPs from the received pool. For 544 example, from the pool 2001:db8:XYZU:TVWZ::/56 the GUNPs 545 2001:db8:XYZU:TV01::/64 and 2001:db8:XYZU:TV02::/64 are derived. 547 Further, the GUNPs are aimed at links. For example, the GUNP 548 2001:DB8:XXXX:XX01::/64 is aimed at the interface 1, and 549 2001:DB8:XXXX:XX02::/64 at the interface 2; further, 550 2001:DB8:XXXX:XXff::/64 corresponds to the interface interface 256. 552 ++=======================++ 553 II II 554 II II 555 II II 556 II II |H 557 II Prefix 1 +-----+ Link 1 |o 558 II +-------+ | I1 |............................|s 559 II | /64 | +-----+ | |t 560 II | | II |2001:DB8:XXXX:XX01::/64 | 561 II | +--------------+ |1 562 II | II 563 II | II 564 II | II 565 II | II |H 566 /56 +-----+ |Prefix 2 +-----+ Link 2 |o 567 ......| I0 |----+-------+ | I2 |............................|s 568 +-----+ | /64 | +-----+ | |t 569 II | | II |2001:DB8:XXXX:XX02::/64 | 570 II | +--------------+ |2 571 II | II 572 II | II 573 II | II 574 II | II |H 575 II |Prefix 3 +-----+ Link 3 |o 576 II +-------+ | I3 |............................|s 577 II /64 | +-----+ | |t 578 II | II |2001:DB8:XXXX:XX::/64 | 579 II +--------------+ |3 580 II II 581 II II 582 ++=======================++ 583 Requesting IoT Router 585 (In the above figure the Requesting IoT Router, with 4 links, is 586 presented). 588 There are 2 cases that could be considered. The first one is: all 589 interfaces (except the RI) of the Requesting IoT Router could be 590 assigned with the corresponding GUNPs. In the second case, a list of 591 manually selected interfaces is obtained. Finally interfaces in the 592 list are assigned with GUNPs. The interfaces numbers represent their 593 position in alphabetically ordered list by the names that operating 594 system assigned to them during the initialization. 596 During the final step of the GUA autoconfiguration in the Requesting 597 IoT Router, the assignment of the IPv6 network addresses to the 598 interfaces is performed. The IPv6 network addresses have the current 599 format: 2001:DB8::XXXX:XXYY:1/56, where YY - is a value that 600 represents the number of the interface. When the GUA 601 autoconfiguration on the Requesting IoT Router is finished, the 602 Requesting IoT Router advertises via its interfaces the GUNPs to the 603 Hosts. 605 5.3. Advertisement of the network prefixes 607 Finally, the Requesting IoT Router runs the Neighbour Discovery 608 Protocol. The Neighbour Discovery Protocol messages allow to 609 advertise the configuration to the hosts. To send the configuration 610 parameters from the Requesting IoT Router to the hosts, the "Router 611 Advertisement" type messages are used [RFC4861]. Usually the "Router 612 Advertisement" messages are triggered by the "Router Solicit" 613 messages sent from the Hosts to the Requesting IoT Router [RFC4861]. 615 The "Router Advertisement" message includes the "Prefix Information" 616 option. It is located in the "Options part" of the "Router 617 Advertisement" message. The position of the "Prefix Information" 618 option is presented in the figure below. 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type | Code | Checksum | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Reachable Time | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Retrans Timer | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Options ... PREFIX INFORMATION 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 634 (Figure above presents the Router Advertisement message format 635 [RFC4861]) 637 The "Prefix Information" option carries the GUNP value and length. 638 These configuration parameters provide on-link GUNPs, used for SLAAC 639 auto configuration. The Prefix Length is a number that describes the 640 number of bits which are used to identify the GUNP. And each GUNP 641 represents the sub-network. 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Type | Length | Prefix Length |L|A| Reserved1 | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Valid Lifetime | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Preferred Lifetime | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Reserved2 | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | | 655 + + 656 | | 657 + Prefix + 658 | | 659 + + 660 | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 5.4. DHCPv6 Port range 665 Due to the blockage of the standard port in particular cases there is 666 a need to provide a solution that may overcome this issue. 668 5.4.1. Client support 670 On the client side the port range supported in the modified sowtware. 671 The DHCPv6 client MAY have the list of dhcpv6 server ports. Client 672 send the "SOLICIT" message to the specific port and after [timeout | 673 number of retries] the port is changed to the next one in the list. 675 5.4.2. Server support 677 On the server side the port rage support is provided with multiple 678 standard DHCPv6 server instances that are running in linux containers 679 and listen on different ports. 681 5.5. Recommendations 683 First recommendation we suggest for DHCP is to use port different 684 from 547 because it is blocked in many cases. Insted we propose to 685 use another one, like 25474. Different approach to address this 686 problem is to develop a method to dynamically negotiate such port 687 number. 689 Second recommendation may have to do with Hop Limit and multicast 690 scope in DHCP Solicit messages. It is reasonable to set the value of 691 Hop Limit to 16. It will allow to put DHCP servers _outside_ the 692 cellular network domain. 694 Third recommendation is that link layer protocol used to make IPv6 695 addresses in 3GPP network should be documented - and agreed - at 696 IETF, not only at 3GPP. Thus document will be a base for 697 disscussions about IPv6 and User Equipments (UE). 699 6. Implementation Aspects 701 The implementation of DANIR is open source. It is available on 702 github at the following address, as of September 18th, 2019: 703 https://github.com/dmytroshytyi/KD6-DHCPv6-PD-DANIR 705 7. Security Considerations 707 At this time, no security considerations are addressed by this memo. 709 8. IANA Considerations 711 No request to IANA at this time. 713 9. Acknowledgements 715 The authors would like to thank Michael Mathias Boc, Giorgio Campo, 716 David Frey and Artiol Kalca for their valuable comments related to 717 the Linux Network stack, the Legato OS recipies and the cross- 718 compilation for the ARM architecture. Also the authors would like to 719 acknowledge the contribution of Fred Baker, Michele Russo, Ole Troan, 720 Mark Smith, Gert Doering, Cameron Byrne, Fred Templin for valuable 721 comments. 723 10. Normative References 725 [ETSI102361] 726 "ETSI TS 102 361-3 v1.1.7 (2007-12): Electromagnetic 727 compatibility and Radio spectrum Matters; Digital Mobile 728 Radio Systems; DRM data protocol.". 730 [I-D.ietf-dhc-rfc3315bis] 731 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 732 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 733 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 734 bis", draft-ietf-dhc-rfc3315bis-13 (work in progress), 735 April 2018. 737 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 738 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 739 . 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, 743 DOI 10.17487/RFC2119, March 1997, 744 . 746 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 747 Host Configuration Protocol (DHCP) version 6", RFC 3633, 748 DOI 10.17487/RFC3633, December 2003, 749 . 751 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 752 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 753 DOI 10.17487/RFC4861, September 2007, 754 . 756 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 757 Address Autoconfiguration", RFC 4862, 758 DOI 10.17487/RFC4862, September 2007, 759 . 761 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 762 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 763 Partnership Project (3GPP) Evolved Packet System (EPS)", 764 RFC 6459, DOI 10.17487/RFC6459, January 2012, 765 . 767 [RFC6653] Sarikaya, B., Xia, F., and T. Lemon, "DHCPv6 Prefix 768 Delegation in Long-Term Evolution (LTE) Networks", 769 RFC 6653, DOI 10.17487/RFC6653, July 2012, 770 . 772 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 773 (IPv6) Specification", STD 86, RFC 8200, 774 DOI 10.17487/RFC8200, July 2017, 775 . 777 Authors' Addresses 778 Dmytro Shytyi 779 SFR 780 Paris area , Ile-de-France 781 France 783 Email: ietf.dmytro@shytyi.net 784 URI: http://dmytro.shytyi.net 786 Alexandre Petrescu 787 CEA, LIST 788 CEA Saclay 789 Gif-sur-Yvette , Ile-de-France 91190 790 France 792 Phone: +33169089223 793 Email: Alexandre.Petrescu@cea.fr