idnits 2.17.1 draft-shytyi-v6ops-danir-02.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 24, 2018) is 2038 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 Societe Francaise du Radiotelephone(SFR) 4 Intended status: Informational G. Campo 5 Expires: March 28, 2019 6 A. Petrescu 7 CEA, LIST 8 September 24, 2018 10 DHCPv6_PD, PDP and NDP Implementation in IoT Router (DANIR) 11 draft-shytyi-v6ops-danir-02.txt 13 Abstract 15 This document provides a description of the implementation of Dynamic 16 Host Configuration Protocol version 6 Prefix Delegation, Neighbour 17 Discovery Protocol and of the use of the Packet Data Protocol in an 18 Internet of Things Router. This Internet of Things Router is 19 connected on a cellular network; it is a DHCPv6-PD Client and it 20 requests a /56 pool of prefixes from the server; the DHCPv6-PD server 21 is placed in the PGW and is a part of the cellular infrastructure. 22 After the pool of prefixes is delegated, the Internet of Things 23 Router derives sub-prefixes from the prefix pool; each one of these 24 sub-prefixes is aimed at one ingress interface. 26 After the Internet of Things Router finishes the network prefix 27 assignment procedure, it advertises the network prefixes on the 28 ingress links by using the Neighbour Discovery protocol. Finally, 29 when Hosts receive the sub-prefixes via Router Adverticement 30 messages, they configure the Global Unique Address with the Stateless 31 Address Auto-configuration protocol. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 28, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Environment . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.1. Solicitation of the network prefix pool . . . . . . . . . 9 73 4.1.1. The Packet Data Protocol . . . . . . . . . . . . . . 9 74 4.1.2. The Dynamic Host Configuration Protocol version 6 75 with Prefix Delegation . . . . . . . . . . . . . . . 9 76 4.1.3. Option: PPP use . . . . . . . . . . . . . . . . . . . 12 77 4.2. Assignment of the network prefixes on the links . . . . . 12 78 4.3. Advertisement of the network prefixes . . . . . . . . . . 15 79 4.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 16 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 83 8. Normative References . . . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 This document describes the implementation of the Dynamic Host 89 Configuration Protocol vestion 6 with Prefix Delegation (DHCPv6_PD), 90 Neighbour Discovery Protocol (NDP) and usage of the Packet Data 91 Protocol (PDP) in an Internet of Things (IoT) Router. 93 The use of DHCPv6 Prefix Delegation in LTE networks is overviewed in 94 [RFC6653]. It misses several important aspects. 96 The router MUST be a node that forwards IP version 6 packets not 97 explicitly addressed to itself [RFC8200]. Thus, it has more than one 98 link to perform the forwarding. With multiple links, the need of 99 multiple global unique network prefixes (GUNPs) , assigned to those 100 links, appears. To assign the GUNPs to the links, the Requesting IoT 101 Router Solicits the pool of GUNPs. 103 First, the Requesting IoT Router solicits the pool of the GUNP from 104 the Delegating Router. 106 After the pool is received, the Requesting IoT Router (1) derives 107 GUNPs and (2) performs address autoconfiguration. During the 108 autoconfiguration process the Requesting IoT Router assigns the GUNPs 109 to the links. When the IoT Router finishes the GUNPs assignment 110 procedure, it starts to advertise the GUNPs on the links with NDP 111 [RFC4861]. Meanwhile, the Hosts that are connected to the Requesting 112 IoT Router run the SLAAC mechanism to perform the GUA IP version 6 113 autoconfiguration. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 Router - is a node, that performs forwarding. Router node is not a 122 final destination of forwarded packets. 124 Delegating Router - is a node, DHCPv6 server, that chooses prefix(es) 125 for delegation and advertises them to the Requesting Router 126 [RFC3633]. 128 Requesting IoT Router - is a node that behaves as DHCPv6 client. It 129 requests the network prefix(es) and assigns network prefix(es) to the 130 interfaces [RFC6653]. 132 Host - is a node that is not a router. 134 Link - is an entity that enables link layer communication of nodes. 136 Interface - node connection to the link. 138 Link-local address - is an address with usage that is limited by a 139 link. 141 Global Unique Address (GUA) - is an address that is globally 142 available and globally unique. 144 3. Overview 146 This section provides an overview of the actions performed on the 147 Delegating Router, Requesting IoT Router and host to perform address 148 assignment on the interfaces with different GUNP. The process of IP 149 version 6 address assignment starts with advertising of the GUNP pool 150 from the Delegating Router to the Requesting IoT Router. To perform 151 such a solicitation, the Requesting IoT Router runs the DHCPv6_PD. 153 +-----------------+ 154 | | 155 | Delegating | 156 | router | 157 | | 158 | (DHCPv6 server) | 159 +-----------------+ 160 | 161 |DHCPv6_PD network prefix 162 POOL |2001:DB8:XYZU:TVWZ::/56 163 | 164 | GUA Prefix_0 /64 165 |interface_0 166 +-------------------------------+ 167 | | 168 | Requesting | 169 | IoT router | 170 | | 171 |(DHCPv6_PDclient + RADVDserver)| 172 +-------------------------------+ 173 |interface_1 |interface_2 |interface_3 174 | | | 175 GUNP |Prefix_1 /64 |Prefix_2 /64 |Prefix_3 /64 176 |SLAAC GUA |SLAAC GUA |SLAAC GUA 177 +-------------+ +------------+ +-------------+ 178 | | | | | | 179 | Host 1 | | Host 2 | | Host 3 | 180 | | | | | | 181 +-------------+ +------------+ +-------------+ 183 (In the above figure the scenario with 3 hosts connected to the 184 Requesting IoT router is presented. Normally there are no number 185 limitations of connected hosts.) 187 When the DHCPv6 message exchange is performed, the Requesting IoT 188 Router receives the pool of IPv6 GUNPs. After the pool of GUNPs is 189 received, the Requesting IoT Router performs the autoconfiguration. 191 Precisely, when the Requesting IoT Router's interface is attached on 192 the link, the Requesting IoT Router assigns to this link the GUNP 193 taken from GUNP pool. The Requesting IoT Router performs the GUNP 194 assignment procedure for multiple links over the interfaces. 195 Finally, this mechanism offers the automated assignment of GUNPs to 196 the links. At the moment of autoconfiguration, the Requesting IoT 197 Router's interfaces are already assigned with link local addresses. 199 The next step of the autoconfiguration phase SHOULD be performed 200 using the Neighbor Discovery protocol. The latter advertises the 201 network's configuration on the links with different interfaces thus 202 with different GUNPs. To perform the GUNPs advertisement, the 203 Requesting IoT ROuter sends the "Router Advertisement Messages" via 204 its interfaces. The Router Avertisement Messages carry the GUNPs 205 that are further used by the stateless autoconfiguration mechanism 206 (SLAAC). There exists an open source implementation of Neighbor 207 Discovery protocol - RADVD sever. With RADVD it is possible to 208 configure hosts interfaces connected to the router's interfaces in 209 automatic manner. It MAY be possible thanks to the fact that hosts 210 run the SLAAC. 212 The IP version 6 stateless autoconfiguration mechanism enables hosts 213 to perform the address autoconfiguration. The SLAAC mechanism SHOULD 214 be used when it is enough to have random unique IP version 6 215 addresses [RFC4862]. The length of the IP version 6 address is N 216 bytes. The first part of the address (128-N bits) consists of the 217 GUNP information associated with a link. The network prefix is 218 advertised by the IoT Router on the link. The second part of the 219 address (8 bytes) consists of interface identifier on the link. The 220 interface identifier SHOULD be generated locally and randomly. 222 +---------------------------------------+------------------------+ 223 | 128 - N bits | N bits | 224 +---------------------------------------+------------------------+ 225 | link prefix | interface identifier | 226 +----------------------------------------------------------------+ 228 (In the above figure, an IP version 6 address scheme is presented 229 [RFC4862].) 231 3.1. Environment 233 This section describes the location of the Delegating Router and the 234 Requesting IoT Router in the cellular provider's infrastructure 235 model. The model is not a real cellular provider infrastructure. 237 After the DHCPv6 packet leaves the cellular interface of the IoT 238 Requesting Router via wireless OFDMA link, it reaches the element of 239 the access network which connects to the user equipment (UEs) - 240 eNodeB station. 242 Further, the packet MAY be transmitted to the Serving Gateway (SGW), 243 as all the user's IP packets. SGW is used to enable the UE movement 244 between eNodeBs. When the UE moves between eNodeBs, the SGW keeps 245 information about the bearers. 247 The final destination of the DHCPv6 packet is the Packet Data Network 248 Gateway, that is responsible for IP address allocation for the UE and 249 for filtering of down-link user's IP packets into the different QoS- 250 based bearers. 252 The model of the infrastructure described in this this section is a 253 simplified example. Real infrastructure construction could contain 254 multiple SGW and eNodeBs and network equipment (that is not described 255 in the current example) with respect of existing standards [RFC6459]. 257 +---------------+ | 258 | PGW | | 259 | Delegating | | 260 | Router | | 261 +---------------+ | 262 | | 263 | | 264 +---------------+ | 265 | SGW | | Cellular infrastructure 266 +---------------+ | 267 | | 268 | | 269 +---------------+ | 270 | eNodeB | | 271 +---------------+ | 272 | | 273 | | 274 ~ ~ Wireless OFDMA 3G/4G 275 | | 276 +---------------+ | 277 | +-------+ | | 278 | | Modem | | | 279 | +-------+ | | 280 | | | | 281 | +-------+ | | 282 | | ARM | | | 283 | +-------+ | | 284 | Requesting | | User Equipment 285 | IoT | | 286 | Router | | 287 +---------------+ | 289 (The above figure descibes the model of the path followed by a DHCPv6 290 packet from IoT requesting router to the Delegating PGW router. The 291 model is not a real infrastructure.) 293 Additional experiments with using of USB dongle were performed. The 294 following figure illustrates the successful DHCPv6-PD test on Orange 295 with dongle. It uses a Huawei E392 USB dongle on laptop (and not the 296 Sierra Wireless mangOH Red). 298 +---------------+ | 299 | PGW | | 300 | Delegating | | 301 | Router | | 302 +---------------+ | 303 | | 304 | | 305 +---------------+ | 306 | SGW | | Cellular infrastructure 307 +---------------+ | 308 | | 309 | | 310 +---------------+ | 311 | eNodeB | | 312 +---------------+ | 313 | | 314 | | 315 ~ ~ Wireless OFDMA 3G/4G 316 | | 317 +---------------+ | 318 | +--------+ | | 319 | | E392 | | | 320 | | USB | | | 321 | | dongle | | | 322 | +--------+ | | 323 | | | | User Equipment 324 | +--------+ | | 325 | | Laptop | | | 326 | +--------+ | | 327 | | | 328 +---------------+ | 330 4. Specification 332 This section presents the process that starts with delegation of 333 Network Prefix pool 2001:DB8:XXXX:XX::/56 from the Delegation Router 334 and finishes with the configuration of IPv6 prefixes on the hosts 335 interfaces. Each Requesting IoT router's interface acts on a unique 336 link. The Host's interfaces, connected to the Requesting IoT router, 337 acts on the same unique links as the Requesting IoT router's 338 interfaces. 340 4.1. Solicitation of the network prefix pool 342 4.1.1. The Packet Data Protocol 344 This section describes how the Requesting IoT Router obtains the GUA 345 address on the Recipient Interface (RI) (OFDMA interface, 3GPP 346 interface). The message "Activate PDP context Accept" is useful for 347 forming the Globally Unique Address on the RI. 349 The Packet Data Protocol [ETSI102361] contains the following types of 350 DLL (Data Link Layer) bearer service data transmissions: unconfirmed 351 data transmission; confirmed data (data transmission; response 352 transmission.) The Packet Data Protocol contains the following types 353 of layer 3 bearer service data transmissions: Internet Protocol; 354 Short Data. These layer 3 bearer services are built on the top of 355 DLL services. 357 ARM Modem eNodeB SGW PGW 358 | | | | | 359 | | PDP | |PDP | 360 | |--------->| |--->| 361 | | | | | 362 | |<---------| |<---| 363 | | | | | 364 | | | | | 366 4.1.2. The Dynamic Host Configuration Protocol version 6 with Prefix 367 Delegation 369 To perform the pool solicitation, the Prefix Delegation options of 370 the Dynamic Host Configuration Protocol version 6 (DHCPv6) are used 371 [I-D.ietf-dhc-rfc3315bis]. 373 The Requesting IoT Router sends the DHCPv6 "Solicit" packet to the 374 Delegating Router via the wireless link. The DHCPv6 "Solicit" packet 375 consists of Client Identifier, Transaction ID, Elapsed time and 376 Identity Association for Prefix Delegation (IA_PD) options. The 377 initial "Solicit" packet triggers the 4 message exchange, that 378 finishes with the reception of the GUNPs pool by the Requesting IoT 379 Router. 381 +------------+ +----------+ 382 | Requesting | | PGW | 383 | IoT | |Delegating| 384 | Router | | Router | 385 +------------+ +----------+ 386 | | 387 | | 388 |1 Solicit | 389 |--------------> | 390 | | 391 | 2 Advertise | 392 | <---------------| 393 | | 394 |3 Request | 395 |--------------> | 396 | | 397 | | 398 | 4 Reply | 399 | <---------------| 400 | | 401 | | 402 | | 404 (In the above figure the full DHCPv6 message exchange mechanism 405 between the ARM part of UE and PGW is presented.) 407 The IA_PD option consists of the Identity Association (IA) - group 408 identifier [RFC3633], parameters (IA id, times to extend the 409 lifetimes of prefixes and prefixes allocated to the IA). The full 410 description of the IA_PD option is presented in the RFC3633 411 [RFC3633]. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | OPTION_IA_PD | option-length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | IAID (4 octets) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | T1 | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | T2 | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 . . 425 . IA_PD-options . 426 . . 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 (in the above figure the DHCPv6 IA_PD option format [RFC3633].) 431 The IA_PD-options field carries the IA_PD Prefix Option. The IA_PD 432 Prefix Option carries the recommended preferred/valid life time and 433 IPv6 prefix with prefix length. The additional fields allocated for 434 the options for the advertised GUNP [RFC3633]. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | OPTION_IAPREFIX | option-length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | preferred-lifetime | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | valid-lifetime | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | prefix-length | | 446 +-+-+-+-+-+-+-+-+ IPv6 prefix | 447 | (16 octets) | 448 | | 449 | | 450 | | 451 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | . 453 +-+-+-+-+-+-+-+-+ . 454 . IAprefix-options . 455 . . 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 (in the above figure the DHCPv6 IA_PD Prefix option format is 459 presented [RFC3633]. 461 The PGW (Delegating Router) advertises, through the usage of a DHCPv6 462 packet, an IPv6 pool 2001:DB8::/56 to the Requesting IoT Router. The 463 packet SHOULD be sent from the cellular infrastructure to the 464 Requesting IoT Router, via the wireless link. The full message 465 exchange consists of: Solicit, Advertise, Request and Reply messages. 467 The "Request", "Reply" messages are used to add/remove/update the 468 assigned prefixes to IA_PDs. 470 The Hop Limit of packets that contain the DHCPv6 data MUST be 255 to 471 satisfy the properties of the cellular infrastructure. To reach the 472 PGW from the UE the DHCPv6 packets are encapsulated by SGW into UDP/ 473 IPv4 packets; this encapsulation is for the GTP-U tunnel. The 474 corresponding decapsulation mechanism decreases the Hop Limit; when 475 the Hop Limit reaches value 0 the packet is discarded; to avoid this 476 situation it is required to put the Hop Limit value of the DHCPv6 477 Solicit equal to 255. 479 4.1.3. Option: PPP use 481 It is possible to use IPv6-over-PPP protocol [RFC1661], with LCP, 482 between the ARM and the modem. This protocol helps with forming an 483 IPv6 link-local address on the IoT Router's RI. 485 ARM Modem eNodeB SGW PGW 486 | | | | | 487 |------->| | | | 488 |PPP LCP | | | | 489 |<-------| | | | 490 | | | | | 491 | | | | | 492 | | | | | 494 4.2. Assignment of the network prefixes on the links 496 The receipt of the IA_PD Prefix option triggers the GUA 497 autoconfiguration on the Requesting IoT Router's interfaces. The 498 Recipient Interface (RI) receives a message with the IA_PD prefix 499 option and does not perform the autoconfiguration on the current 500 stage. 502 All interfaces, except RI, now follow the GUA autoconfiguration 503 procedure. The number of interfaces that should follow the procedure 504 could be specified in the configuration file of the Requesting IoT 505 Router. 507 The GUA interface autoconfiguration procedure in the Requesting IoT 508 Router is done by assigning the network addresses from different 509 GUNPs to the links. The assignment of network addresses is performed 510 using the 2001:DB8:XXXX:XX::/56 network pool. Therefore, the 511 Requesting IoT Router operates on multiple links (ingress links). 513 The IoT Router derives several GUNPs from the received pool. For 514 example, from the pool 2001:db8:XYZU:TVWZ::/56 the GUNPs 515 2001:db8:XYZU:TV01::/64 and 2001:db8:XYZU:TV02::/64 are derived. 517 Further, the GUNPs are aimed at links. For example, the GUNP 518 2001:DB8:XXXX:XX01::/64 is aimed at the interface 1, and 519 2001:DB8:XXXX:XX02::/64 at the interface 2; further, 520 2001:DB8:XXXX:XXff::/64 corresponds to the interface interface 256. 522 ++=======================++ 523 II II 524 II II 525 II II 526 II II |H 527 II Prefix 1 +-----+ Link 1 |o 528 II +-------+ | I1 |............................|s 529 II | /64 | +-----+ | |t 530 II | | II |2001:DB8:XXXX:XX01::/64 | 531 II | +--------------+ |1 532 II | II 533 II | II 534 II | II 535 II | II |H 536 /56 +-----+ |Prefix 2 +-----+ Link 2 |o 537 ......| I0 |----+-------+ | I2 |............................|s 538 +-----+ | /64 | +-----+ | |t 539 II | | II |2001:DB8:XXXX:XX02::/64 | 540 II | +--------------+ |2 541 II | II 542 II | II 543 II | II 544 II | II |H 545 II |Prefix 3 +-----+ Link 3 |o 546 II +-------+ | I3 |............................|s 547 II /64 | +-----+ | |t 548 II | II |2001:DB8:XXXX:XX::/64 | 549 II +--------------+ |3 550 II II 551 II II 552 ++=======================++ 553 Requesting IoT Router 555 (In the above figure the Requesting IoT Router, with 4 links, is 556 presented). 558 There are 2 cases that could be considered. The first one is: all 559 interfaces (except the RI) of the Requesting IoT Router could be 560 assigned with the corresponding GUNPs. In the second case, a list of 561 manually selected interfaces is obtained. Finally interfaces in the 562 list are assigned with GUNPs. The interfaces numbers represent their 563 position in alphabetically ordered list by the names that operating 564 system assigned to them during the initialization. 566 During the final step of the GUA autoconfiguration in the Requesting 567 IoT Router, the assignment of the IPv6 network addresses to the 568 interfaces is performed. The IPv6 network addresses have the current 569 format: 2001:DB8::XXXX:XXYY:1/56, where YY - is a value that 570 represents the number of the interface. When the GUA 571 autoconfiguration on the Requesting IoT Router is finished, the 572 Requesting IoT Router advertises via its interfaces the GUNPs to the 573 Hosts. 575 4.3. Advertisement of the network prefixes 577 Finally, the Requesting IoT Router runs the Neighbour Discovery 578 Protocol. The Neighbour Discovery Protocol messages allow to 579 advertise the configuration to the hosts. To send the configuration 580 parameters from the Requesting IoT Router to the hosts, the "Router 581 Advertisement" type messages are used [RFC4861]. Usually the "Router 582 Advertisement" messages are triggered by the "Router Solicit" 583 messages sent from the Hosts to the Requesting IoT Router [RFC4861]. 585 The "Router Advertisement" message includes the "Prefix Information" 586 option. It is located in the "Options part" of the "Router 587 Advertisement" message. The position of the "Prefix Information" 588 option is presented in the figure below. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type | Code | Checksum | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Reachable Time | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Retrans Timer | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Options ... PREFIX INFORMATION 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 604 (Figure above presents the Router Advertisement message format 605 [RFC4861]) 607 The "Prefix Information" option carries the GUNP value and length. 608 These configuration parameters provide on-link GUNPs, used for SLAAC 609 auto configuration. The Prefix Length is a number that describes the 610 number of bits which are used to identify the GUNP. And each GUNP 611 represents the sub-network. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type | Length | Prefix Length |L|A| Reserved1 | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Valid Lifetime | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Preferred Lifetime | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Reserved2 | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | | 625 + + 626 | | 627 + Prefix + 628 | | 629 + + 630 | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 4.4. Recommendations 635 First recommendation we suggest for DHCP is to use port different 636 from 547 because it is blocked in many cases. Insted we propose to 637 use another one, like 25474. Different approach to address this 638 problem is to develop a method to dynamically negotiate such port 639 number. 641 Second recommendation may have to do with Hop Limit and multicast 642 scope in DHCP Solicit messages. It is reasonable to set the value of 643 Hop Limit to 16. It will allow to put DHCP servers _outside_ the 644 cellular network domain. 646 Third recommendation is that link layer protocol used to make IPv6 647 addresses in 3GPP network should be documented - and agreed - at 648 IETF, not only at 3GPP. Thus document will be a base for 649 disscussions about IPv6 and User Equipments (UE). 651 5. Security Considerations 653 At this time, no security considerations are addressed by this memo. 655 6. IANA Considerations 657 No request to IANA at this time. 659 7. Acknowledgements 661 The authors would like to thank (in alphabetical order) Michael 662 Mathias Boc, Giorgio Campo, David Frey and Artiol Kalca for their 663 valuable comments related to the Linux Network stack, the Legato OS 664 recipies and the cross-compilation for the ARM architecture. Also 665 the authors would like to acknowledge the contribution of Fred Baker, 666 Michele Russo and Ole Troan for valuable comments during the review 667 of this memo. 669 8. Normative References 671 [ETSI102361] 672 ETSI, "ETSI TS 102 361-3 v1.1.7 (2007-12): Electromagnetic 673 compatibility and Radio spectrum Matters; Digital Mobile 674 Radio Systems; DRM data protocol.". 676 [I-D.ietf-dhc-rfc3315bis] 677 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 678 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 679 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 680 bis", draft-ietf-dhc-rfc3315bis-13 (work in progress), 681 April 2018. 683 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 684 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 685 . 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 693 Host Configuration Protocol (DHCP) version 6", RFC 3633, 694 DOI 10.17487/RFC3633, December 2003, 695 . 697 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 698 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 699 DOI 10.17487/RFC4861, September 2007, 700 . 702 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 703 Address Autoconfiguration", RFC 4862, 704 DOI 10.17487/RFC4862, September 2007, 705 . 707 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 708 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 709 Partnership Project (3GPP) Evolved Packet System (EPS)", 710 RFC 6459, DOI 10.17487/RFC6459, January 2012, 711 . 713 [RFC6653] Sarikaya, B., Xia, F., and T. Lemon, "DHCPv6 Prefix 714 Delegation in Long-Term Evolution (LTE) Networks", 715 RFC 6653, DOI 10.17487/RFC6653, July 2012, 716 . 718 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 719 (IPv6) Specification", STD 86, RFC 8200, 720 DOI 10.17487/RFC8200, July 2017, 721 . 723 Authors' Addresses 725 Dmytro Shytyi 726 Societe Francaise du Radiotelephone(SFR) 727 Paris area , Ile-de-France 728 France 730 Email: ietf.dmytro@shytyi.net 731 URI: http://dmytro.shytyi.net https://shytyi.net 733 Giorgio Campo 735 Alexandre Petrescu 736 CEA, LIST 737 CEA Saclay 738 Gif-sur-Yvette , Ile-de-France 91190 739 France 741 Phone: +33169089223 742 Email: Alexandre.Petrescu@cea.fr