idnits 2.17.1 draft-shytyi-v6ops-danir-03.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 (March 27, 2019) is 1856 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: September 28, 2019 CEA, LIST 6 March 27, 2019 8 DHCPv6_PD, PDP and NDP Implementation in IoT Router (DANIR) 9 draft-shytyi-v6ops-danir-03.txt 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 September 28, 2019. 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Environment . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Solicitation of the network prefix pool . . . . . . . . . 9 71 4.1.1. The Packet Data Protocol . . . . . . . . . . . . . . 9 72 4.1.2. The Dynamic Host Configuration Protocol version 6 73 with Prefix Delegation . . . . . . . . . . . . . . . 9 74 4.1.3. Option: PPP use . . . . . . . . . . . . . . . . . . . 12 75 4.2. Assignment of the network prefixes on the links . . . . . 12 76 4.3. Advertisement of the network prefixes . . . . . . . . . . 15 77 4.4. DHCPv6 Port range . . . . . . . . . . . . . . . . . . . . 16 78 4.4.1. Client support . . . . . . . . . . . . . . . . . . . 16 79 4.4.2. Server support . . . . . . . . . . . . . . . . . . . 16 80 4.5. Recommendations . . . . . . . . . . . . . . . . . . . . . 16 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 84 8. Normative References . . . . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 This document describes the implementation of the Dynamic Host 90 Configuration Protocol vestion 6 with Prefix Delegation (DHCPv6_PD), 91 Neighbour Discovery Protocol (NDP) and usage of the Packet Data 92 Protocol (PDP) in an Internet of Things (IoT) Router. 94 The use of DHCPv6 Prefix Delegation in LTE networks is overviewed in 95 [RFC6653]. It misses several important aspects. 97 The router MUST be a node that forwards IP version 6 packets not 98 explicitly addressed to itself [RFC8200]. Thus, it has more than one 99 link to perform the forwarding. With multiple links, the need of 100 multiple global unique network prefixes (GUNPs) , assigned to those 101 links, appears. To assign the GUNPs to the links, the Requesting IoT 102 Router Solicits the pool of GUNPs. 104 First, the Requesting IoT Router solicits the pool of the GUNP from 105 the Delegating Router. 107 After the pool is received, the Requesting IoT Router (1) derives 108 GUNPs and (2) performs address autoconfiguration. During the 109 autoconfiguration process the Requesting IoT Router assigns the GUNPs 110 to the links. When the IoT Router finishes the GUNPs assignment 111 procedure, it starts to advertise the GUNPs on the links with NDP 112 [RFC4861]. Meanwhile, the Hosts that are connected to the Requesting 113 IoT Router run the SLAAC mechanism to perform the GUA IP version 6 114 autoconfiguration. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 Router - is a node, that performs forwarding. Router node is not a 123 final destination of forwarded packets. 125 Delegating Router - is a node, DHCPv6 server, that chooses prefix(es) 126 for delegation and advertises them to the Requesting Router 127 [RFC3633]. 129 Requesting IoT Router - is a node that behaves as DHCPv6 client. It 130 requests the network prefix(es) and assigns network prefix(es) to the 131 interfaces [RFC6653]. 133 Host - is a node that is not a router. 135 Link - is an entity that enables link layer communication of nodes. 137 Interface - node connection to the link. 139 Link-local address - is an address with usage that is limited by a 140 link. 142 Global Unique Address (GUA) - is an address that is globally 143 available and globally unique. 145 3. Overview 147 This section provides an overview of the actions performed on the 148 Delegating Router, Requesting IoT Router and host to perform address 149 assignment on the interfaces with different GUNP. The process of IP 150 version 6 address assignment starts with advertising of the GUNP pool 151 from the Delegating Router to the Requesting IoT Router. To perform 152 such a solicitation, the Requesting IoT Router runs the DHCPv6_PD. 154 +-----------------+ 155 | | 156 | Delegating | 157 | router | 158 | | 159 | (DHCPv6 server) | 160 +-----------------+ 161 | 162 |DHCPv6_PD network prefix 163 POOL |2001:DB8:XYZU:TVWZ::/56 164 | 165 | GUA Prefix_0 /64 166 |interface_0 167 +-------------------------------+ 168 | | 169 | Requesting | 170 | IoT router | 171 | | 172 |(DHCPv6_PDclient + RADVDserver)| 173 +-------------------------------+ 174 |interface_1 |interface_2 |interface_3 175 | | | 176 GUNP |Prefix_1 /64 |Prefix_2 /64 |Prefix_3 /64 177 |SLAAC GUA |SLAAC GUA |SLAAC GUA 178 +-------------+ +------------+ +-------------+ 179 | | | | | | 180 | Host 1 | | Host 2 | | Host 3 | 181 | | | | | | 182 +-------------+ +------------+ +-------------+ 184 (In the above figure the scenario with 3 hosts connected to the 185 Requesting IoT router is presented. Normally there are no number 186 limitations of connected hosts.) 188 When the DHCPv6 message exchange is performed, the Requesting IoT 189 Router receives the pool of IPv6 GUNPs. After the pool of GUNPs is 190 received, the Requesting IoT Router performs the autoconfiguration. 192 Precisely, when the Requesting IoT Router's interface is attached on 193 the link, the Requesting IoT Router assigns to this link the GUNP 194 taken from GUNP pool. The Requesting IoT Router performs the GUNP 195 assignment procedure for multiple links over the interfaces. 196 Finally, this mechanism offers the automated assignment of GUNPs to 197 the links. At the moment of autoconfiguration, the Requesting IoT 198 Router's interfaces are already assigned with link local addresses. 200 The next step of the autoconfiguration phase SHOULD be performed 201 using the Neighbor Discovery protocol. The latter advertises the 202 network's configuration on the links with different interfaces thus 203 with different GUNPs. To perform the GUNPs advertisement, the 204 Requesting IoT ROuter sends the "Router Advertisement Messages" via 205 its interfaces. The Router Avertisement Messages carry the GUNPs 206 that are further used by the stateless autoconfiguration mechanism 207 (SLAAC). There exists an open source implementation of Neighbor 208 Discovery protocol - RADVD sever. With RADVD it is possible to 209 configure hosts interfaces connected to the router's interfaces in 210 automatic manner. It MAY be possible thanks to the fact that hosts 211 run the SLAAC. 213 The IP version 6 stateless autoconfiguration mechanism enables hosts 214 to perform the address autoconfiguration. The SLAAC mechanism SHOULD 215 be used when it is enough to have random unique IP version 6 216 addresses [RFC4862]. The length of the IP version 6 address is N 217 bytes. The first part of the address (128-N bits) consists of the 218 GUNP information associated with a link. The network prefix is 219 advertised by the IoT Router on the link. The second part of the 220 address (8 bytes) consists of interface identifier on the link. The 221 interface identifier SHOULD be generated locally and randomly. 223 +---------------------------------------+------------------------+ 224 | 128 - N bits | N bits | 225 +---------------------------------------+------------------------+ 226 | link prefix | interface identifier | 227 +----------------------------------------------------------------+ 229 (In the above figure, an IP version 6 address scheme is presented 230 [RFC4862].) 232 3.1. Environment 234 This section describes the location of the Delegating Router and the 235 Requesting IoT Router in the cellular provider's infrastructure 236 model. The model is not a real cellular provider infrastructure. 238 After the DHCPv6 packet leaves the cellular interface of the IoT 239 Requesting Router via wireless OFDMA link, it reaches the element of 240 the access network which connects to the user equipment (UEs) - 241 eNodeB station. 243 Further, the packet MAY be transmitted to the Serving Gateway (SGW), 244 as all the user's IP packets. SGW is used to enable the UE movement 245 between eNodeBs. When the UE moves between eNodeBs, the SGW keeps 246 information about the bearers. 248 The final destination of the DHCPv6 packet is the Packet Data Network 249 Gateway, that is responsible for IP address allocation for the UE and 250 for filtering of down-link user's IP packets into the different QoS- 251 based bearers. 253 The model of the infrastructure described in this this section is a 254 simplified example. Real infrastructure construction could contain 255 multiple SGW and eNodeBs and network equipment (that is not described 256 in the current example) with respect of existing standards [RFC6459]. 258 +---------------+ | 259 | PGW | | 260 | Delegating | | 261 | Router | | 262 +---------------+ | 263 | | 264 | | 265 +---------------+ | 266 | SGW | | Cellular infrastructure 267 +---------------+ | 268 | | 269 | | 270 +---------------+ | 271 | eNodeB | | 272 +---------------+ | 273 | | 274 | | 275 ~ ~ Wireless OFDMA 3G/4G 276 | | 277 +---------------+ | 278 | +-------+ | | 279 | | Modem | | | 280 | +-------+ | | 281 | | | | 282 | +-------+ | | 283 | | ARM | | | 284 | +-------+ | | 285 | Requesting | | User Equipment 286 | IoT | | 287 | Router | | 288 +---------------+ | 290 (The above figure descibes the model of the path followed by a DHCPv6 291 packet from IoT requesting router to the Delegating PGW router. The 292 model is not a real infrastructure.) 294 Additional experiments with using of USB dongle were performed. The 295 following figure illustrates the successful DHCPv6-PD test on Orange 296 with dongle. It uses a Huawei E392 USB dongle on laptop (and not the 297 Sierra Wireless mangOH Red). 299 +---------------+ | 300 | PGW | | 301 | Delegating | | 302 | Router | | 303 +---------------+ | 304 | | 305 | | 306 +---------------+ | 307 | SGW | | Cellular infrastructure 308 +---------------+ | 309 | | 310 | | 311 +---------------+ | 312 | eNodeB | | 313 +---------------+ | 314 | | 315 | | 316 ~ ~ Wireless OFDMA 3G/4G 317 | | 318 +---------------+ | 319 | +--------+ | | 320 | | E392 | | | 321 | | USB | | | 322 | | dongle | | | 323 | +--------+ | | 324 | | | | User Equipment 325 | +--------+ | | 326 | | Laptop | | | 327 | +--------+ | | 328 | | | 329 +---------------+ | 331 4. Specification 333 This section presents the process that starts with delegation of 334 Network Prefix pool 2001:DB8:XXXX:XX::/56 from the Delegation Router 335 and finishes with the configuration of IPv6 prefixes on the hosts 336 interfaces. Each Requesting IoT router's interface acts on a unique 337 link. The Host's interfaces, connected to the Requesting IoT router, 338 acts on the same unique links as the Requesting IoT router's 339 interfaces. 341 4.1. Solicitation of the network prefix pool 343 4.1.1. The Packet Data Protocol 345 This section describes how the Requesting IoT Router obtains the GUA 346 address on the Recipient Interface (RI) (OFDMA interface, 3GPP 347 interface). The message "Activate PDP context Accept" is useful for 348 forming the Globally Unique Address on the RI. 350 The Packet Data Protocol [ETSI102361] contains the following types of 351 DLL (Data Link Layer) bearer service data transmissions: unconfirmed 352 data transmission; confirmed data (data transmission; response 353 transmission.) The Packet Data Protocol contains the following types 354 of layer 3 bearer service data transmissions: Internet Protocol; 355 Short Data. These layer 3 bearer services are built on the top of 356 DLL services. 358 ARM Modem eNodeB SGW PGW 359 | | | | | 360 | | PDP | |PDP | 361 | |--------->| |--->| 362 | | | | | 363 | |<---------| |<---| 364 | | | | | 365 | | | | | 367 4.1.2. The Dynamic Host Configuration Protocol version 6 with Prefix 368 Delegation 370 To perform the pool solicitation, the Prefix Delegation options of 371 the Dynamic Host Configuration Protocol version 6 (DHCPv6) are used 372 [I-D.ietf-dhc-rfc3315bis]. 374 The Requesting IoT Router sends the DHCPv6 "Solicit" packet to the 375 Delegating Router via the wireless link. The DHCPv6 "Solicit" packet 376 consists of Client Identifier, Transaction ID, Elapsed time and 377 Identity Association for Prefix Delegation (IA_PD) options. The 378 initial "Solicit" packet triggers the 4 message exchange, that 379 finishes with the reception of the GUNPs pool by the Requesting IoT 380 Router. 382 +------------+ +----------+ 383 | Requesting | | PGW | 384 | IoT | |Delegating| 385 | Router | | Router | 386 +------------+ +----------+ 387 | | 388 | | 389 |1 Solicit | 390 |--------------> | 391 | | 392 | 2 Advertise | 393 | <---------------| 394 | | 395 |3 Request | 396 |--------------> | 397 | | 398 | | 399 | 4 Reply | 400 | <---------------| 401 | | 402 | | 403 | | 405 (In the above figure the full DHCPv6 message exchange mechanism 406 between the ARM part of UE and PGW is presented.) 408 The IA_PD option consists of the Identity Association (IA) - group 409 identifier [RFC3633], parameters (IA id, times to extend the 410 lifetimes of prefixes and prefixes allocated to the IA). The full 411 description of the IA_PD option is presented in the RFC3633 412 [RFC3633]. 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | OPTION_IA_PD | option-length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | IAID (4 octets) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | T1 | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | T2 | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 . . 426 . IA_PD-options . 427 . . 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 (in the above figure the DHCPv6 IA_PD option format [RFC3633].) 432 The IA_PD-options field carries the IA_PD Prefix Option. The IA_PD 433 Prefix Option carries the recommended preferred/valid life time and 434 IPv6 prefix with prefix length. The additional fields allocated for 435 the options for the advertised GUNP [RFC3633]. 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | OPTION_IAPREFIX | option-length | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | preferred-lifetime | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | valid-lifetime | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | prefix-length | | 447 +-+-+-+-+-+-+-+-+ IPv6 prefix | 448 | (16 octets) | 449 | | 450 | | 451 | | 452 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | . 454 +-+-+-+-+-+-+-+-+ . 455 . IAprefix-options . 456 . . 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 (in the above figure the DHCPv6 IA_PD Prefix option format is 460 presented [RFC3633]. 462 The PGW (Delegating Router) advertises, through the usage of a DHCPv6 463 packet, an IPv6 pool 2001:DB8::/56 to the Requesting IoT Router. The 464 packet SHOULD be sent from the cellular infrastructure to the 465 Requesting IoT Router, via the wireless link. The full message 466 exchange consists of: Solicit, Advertise, Request and Reply messages. 468 The "Request", "Reply" messages are used to add/remove/update the 469 assigned prefixes to IA_PDs. 471 The Hop Limit of packets that contain the DHCPv6 data MUST be 255 to 472 satisfy the properties of the cellular infrastructure. To reach the 473 PGW from the UE the DHCPv6 packets are encapsulated by SGW into UDP/ 474 IPv4 packets; this encapsulation is for the GTP-U tunnel. The 475 corresponding decapsulation mechanism decreases the Hop Limit; when 476 the Hop Limit reaches value 0 the packet is discarded; to avoid this 477 situation it is required to put the Hop Limit value of the DHCPv6 478 Solicit equal to 255. 480 4.1.3. Option: PPP use 482 It is possible to use IPv6-over-PPP protocol [RFC1661], with LCP, 483 between the ARM and the modem. This protocol helps with forming an 484 IPv6 link-local address on the IoT Router's RI. 486 ARM Modem eNodeB SGW PGW 487 | | | | | 488 |------->| | | | 489 |PPP LCP | | | | 490 |<-------| | | | 491 | | | | | 492 | | | | | 493 | | | | | 495 4.2. Assignment of the network prefixes on the links 497 The receipt of the IA_PD Prefix option triggers the GUA 498 autoconfiguration on the Requesting IoT Router's interfaces. The 499 Recipient Interface (RI) receives a message with the IA_PD prefix 500 option and does not perform the autoconfiguration on the current 501 stage. 503 All interfaces, except RI, now follow the GUA autoconfiguration 504 procedure. The number of interfaces that should follow the procedure 505 could be specified in the configuration file of the Requesting IoT 506 Router. 508 The GUA interface autoconfiguration procedure in the Requesting IoT 509 Router is done by assigning the network addresses from different 510 GUNPs to the links. The assignment of network addresses is performed 511 using the 2001:DB8:XXXX:XX::/56 network pool. Therefore, the 512 Requesting IoT Router operates on multiple links (ingress links). 514 The IoT Router derives several GUNPs from the received pool. For 515 example, from the pool 2001:db8:XYZU:TVWZ::/56 the GUNPs 516 2001:db8:XYZU:TV01::/64 and 2001:db8:XYZU:TV02::/64 are derived. 518 Further, the GUNPs are aimed at links. For example, the GUNP 519 2001:DB8:XXXX:XX01::/64 is aimed at the interface 1, and 520 2001:DB8:XXXX:XX02::/64 at the interface 2; further, 521 2001:DB8:XXXX:XXff::/64 corresponds to the interface interface 256. 523 ++=======================++ 524 II II 525 II II 526 II II 527 II II |H 528 II Prefix 1 +-----+ Link 1 |o 529 II +-------+ | I1 |............................|s 530 II | /64 | +-----+ | |t 531 II | | II |2001:DB8:XXXX:XX01::/64 | 532 II | +--------------+ |1 533 II | II 534 II | II 535 II | II 536 II | II |H 537 /56 +-----+ |Prefix 2 +-----+ Link 2 |o 538 ......| I0 |----+-------+ | I2 |............................|s 539 +-----+ | /64 | +-----+ | |t 540 II | | II |2001:DB8:XXXX:XX02::/64 | 541 II | +--------------+ |2 542 II | II 543 II | II 544 II | II 545 II | II |H 546 II |Prefix 3 +-----+ Link 3 |o 547 II +-------+ | I3 |............................|s 548 II /64 | +-----+ | |t 549 II | II |2001:DB8:XXXX:XX::/64 | 550 II +--------------+ |3 551 II II 552 II II 553 ++=======================++ 554 Requesting IoT Router 556 (In the above figure the Requesting IoT Router, with 4 links, is 557 presented). 559 There are 2 cases that could be considered. The first one is: all 560 interfaces (except the RI) of the Requesting IoT Router could be 561 assigned with the corresponding GUNPs. In the second case, a list of 562 manually selected interfaces is obtained. Finally interfaces in the 563 list are assigned with GUNPs. The interfaces numbers represent their 564 position in alphabetically ordered list by the names that operating 565 system assigned to them during the initialization. 567 During the final step of the GUA autoconfiguration in the Requesting 568 IoT Router, the assignment of the IPv6 network addresses to the 569 interfaces is performed. The IPv6 network addresses have the current 570 format: 2001:DB8::XXXX:XXYY:1/56, where YY - is a value that 571 represents the number of the interface. When the GUA 572 autoconfiguration on the Requesting IoT Router is finished, the 573 Requesting IoT Router advertises via its interfaces the GUNPs to the 574 Hosts. 576 4.3. Advertisement of the network prefixes 578 Finally, the Requesting IoT Router runs the Neighbour Discovery 579 Protocol. The Neighbour Discovery Protocol messages allow to 580 advertise the configuration to the hosts. To send the configuration 581 parameters from the Requesting IoT Router to the hosts, the "Router 582 Advertisement" type messages are used [RFC4861]. Usually the "Router 583 Advertisement" messages are triggered by the "Router Solicit" 584 messages sent from the Hosts to the Requesting IoT Router [RFC4861]. 586 The "Router Advertisement" message includes the "Prefix Information" 587 option. It is located in the "Options part" of the "Router 588 Advertisement" message. The position of the "Prefix Information" 589 option is presented in the figure below. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type | Code | Checksum | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Reachable Time | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Retrans Timer | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Options ... PREFIX INFORMATION 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 605 (Figure above presents the Router Advertisement message format 606 [RFC4861]) 608 The "Prefix Information" option carries the GUNP value and length. 609 These configuration parameters provide on-link GUNPs, used for SLAAC 610 auto configuration. The Prefix Length is a number that describes the 611 number of bits which are used to identify the GUNP. And each GUNP 612 represents the sub-network. 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Type | Length | Prefix Length |L|A| Reserved1 | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Valid Lifetime | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Preferred Lifetime | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Reserved2 | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | | 626 + + 627 | | 628 + Prefix + 629 | | 630 + + 631 | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 4.4. DHCPv6 Port range 636 Due to the blockage of the standard port in particular cases there is 637 a need to provide a solution that may overcome this issue. 639 4.4.1. Client support 641 On the client side the port range supported in the modified sowtware. 642 The DHCPv6 client MAY have the list of dhcpv6 server ports. Client 643 send the "SOLICIT" message to the specific port and after [timeout | 644 number of retries] the port is changed to the next one in the list. 646 4.4.2. Server support 648 On the server side the port rage support is provided with multiple 649 standard DHCPv6 server instances that are running in linux containers 650 and listen on different ports. 652 4.5. Recommendations 654 First recommendation we suggest for DHCP is to use port different 655 from 547 because it is blocked in many cases. Insted we propose to 656 use another one, like 25474. Different approach to address this 657 problem is to develop a method to dynamically negotiate such port 658 number. 660 Second recommendation may have to do with Hop Limit and multicast 661 scope in DHCP Solicit messages. It is reasonable to set the value of 662 Hop Limit to 16. It will allow to put DHCP servers _outside_ the 663 cellular network domain. 665 Third recommendation is that link layer protocol used to make IPv6 666 addresses in 3GPP network should be documented - and agreed - at 667 IETF, not only at 3GPP. Thus document will be a base for 668 disscussions about IPv6 and User Equipments (UE). 670 5. Security Considerations 672 At this time, no security considerations are addressed by this memo. 674 6. IANA Considerations 676 No request to IANA at this time. 678 7. Acknowledgements 680 The authors would like to thank (in alphabetical order) Michael 681 Mathias Boc, Giorgio Campo, David Frey and Artiol Kalca for their 682 valuable comments related to the Linux Network stack, the Legato OS 683 recipies and the cross-compilation for the ARM architecture. Also 684 the authors would like to acknowledge the contribution of Fred Baker, 685 Michele Russo and Ole Troan for valuable comments during the review 686 of this memo. 688 8. Normative References 690 [ETSI102361] 691 "ETSI TS 102 361-3 v1.1.7 (2007-12): Electromagnetic 692 compatibility and Radio spectrum Matters; Digital Mobile 693 Radio Systems; DRM data protocol.". 695 [I-D.ietf-dhc-rfc3315bis] 696 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 697 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 698 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 699 bis", draft-ietf-dhc-rfc3315bis-13 (work in progress), 700 April 2018. 702 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 703 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 704 . 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, 708 DOI 10.17487/RFC2119, March 1997, 709 . 711 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 712 Host Configuration Protocol (DHCP) version 6", RFC 3633, 713 DOI 10.17487/RFC3633, December 2003, 714 . 716 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 717 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 718 DOI 10.17487/RFC4861, September 2007, 719 . 721 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 722 Address Autoconfiguration", RFC 4862, 723 DOI 10.17487/RFC4862, September 2007, 724 . 726 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 727 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 728 Partnership Project (3GPP) Evolved Packet System (EPS)", 729 RFC 6459, DOI 10.17487/RFC6459, January 2012, 730 . 732 [RFC6653] Sarikaya, B., Xia, F., and T. Lemon, "DHCPv6 Prefix 733 Delegation in Long-Term Evolution (LTE) Networks", 734 RFC 6653, DOI 10.17487/RFC6653, July 2012, 735 . 737 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 738 (IPv6) Specification", STD 86, RFC 8200, 739 DOI 10.17487/RFC8200, July 2017, 740 . 742 Authors' Addresses 744 Dmytro Shytyi 745 SFR 746 Paris area , Ile-de-France 747 France 749 Email: ietf.dmytro@shytyi.net 750 URI: http://dmytro.shytyi.net 751 Alexandre Petrescu 752 CEA, LIST 753 CEA Saclay 754 Gif-sur-Yvette , Ile-de-France 91190 755 France 757 Phone: +33169089223 758 Email: Alexandre.Petrescu@cea.fr