idnits 2.17.1 draft-ietf-softwire-dslite-yang-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 29, 2018) is 2156 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-opsawg-nat-yang-14 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-19 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track Orange 5 Expires: November 30, 2018 S. Sivakumar 6 Cisco Systems 7 May 29, 2018 9 A YANG Data Model for Dual-Stack Lite (DS-Lite) 10 draft-ietf-softwire-dslite-yang-17 12 Abstract 14 This document defines a YANG module for the DS-Lite Address Family 15 Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements. 17 Editorial Note (To be removed by RFC Editor) 19 Please update these statements in the document with the RFC number to 20 be assigned to this document: 22 o "This version of this YANG module is part of RFC XXXX;" 24 o "RFC XXXX: A YANG Data Model for Dual-Stack Lite (DS-Lite)"; 26 o "reference: RFC XXXX" 28 Please update the "revision" date of the YANG module. 30 Also, update this sentence with the RFC number to be assigned to I- 31 D.ietf-opsawg-nat-yang: 33 o "RFC YYYY: A YANG Module for Network Address Translation (NAT) and 34 Network Prefix Translation (NPT)" 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on November 30, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. DS-Lite YANG Module: An Overview . . . . . . . . . . . . . . 4 73 3. DS-Lite YANG Module . . . . . . . . . . . . . . . . . . . . . 6 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.1. Normative references . . . . . . . . . . . . . . . . . . 16 79 7.2. Informative references . . . . . . . . . . . . . . . . . 17 80 Appendix A. B4 Example . . . . . . . . . . . . . . . . . . . . . 19 81 Appendix B. AFTR Examples . . . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 This document defines a data model for DS-Lite [RFC6333], using the 87 YANG data modeling language [RFC7950]. Both the Address Family 88 Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements 89 are covered by this specification. 91 As a reminder, Figure 1 illustrates an overview of the DS-Lite 92 architecture that involves AFTR and B4 elements. 94 +-----------+ 95 | Host | 96 +-----+-----+ 97 |192.0.2.1 98 | 99 | 100 |192.0.2.2 101 +---------|---------+ 102 | | | 103 | Home router | 104 |+--------+--------+| 105 || B4 || 106 |+--------+--------+| 107 +--------|||--------+ 108 |||2001:db8:0:1::1 109 ||| 110 |||<-IPv4-in-IPv6 softwire 111 ||| 112 -------|||------- 113 / ||| \ 114 | ISP core network | 115 \ ||| / 116 -------|||------- 117 ||| 118 |||2001:db8:0:2::1 119 +--------|||--------+ 120 | AFTR | 121 |+--------+--------+| 122 || Concentrator || 123 |+--------+--------+| 124 | |NAT| | 125 | +-+-+ | 126 +---------|---------+ 127 |198.51.100.1 128 | 129 --------|-------- 130 / | \ 131 | Internet | 132 \ | / 133 --------|-------- 134 | 135 |203.0.113.1 136 +-----+-----+ 137 | IPv4 Host | 138 +-----------+ 140 Figure 1: DS-Lite Base Architecture 142 DS-Lite deployment considerations are discussed in [RFC6908]. 144 This document follows the guidelines of [RFC6087], uses the common 145 YANG types defined in [RFC6991], and adopts the Network Management 146 Datastore Architecture (NMDA). 148 1.1. Terminology 150 This document makes use of the terms defined in Section 3 of 151 [RFC6333]. 153 The terminology for describing YANG data models is defined in 154 [RFC7950]. 156 The meaning of the symbols in tree diagrams is defined in [RFC8340]. 158 2. DS-Lite YANG Module: An Overview 160 As shown in Figure 1: 162 o The AFTR element is a combination of an IPv4-in-IPv6 tunnel and a 163 NAPT function (Section 2.2 of [RFC3022]). 165 o The B4 element is an IPv4-in-IPv6 tunnel. 167 Therefore, the DS-Lite YANG module is designed to augment both the 168 Interfaces YANG module [RFC8343] and the NAT YANG module 169 [I-D.ietf-opsawg-nat-yang] with DS-Lite specific features. 171 The YANG "feature" statement is used to distinguish which of the DS- 172 Lite elements ('aftr' or 'b4') is relevant for a specific data node. 174 Concretely, the DS-Lite YANG module (Figure 2) augments the 175 Interfaces YANG module with the following: 177 o An IPv6 address used by the tunnel endpoint (AFTR or B4) for 178 sending and receiving IPv4-in-IPv6 packets (ipv6-address). 180 o An IPv4 address that is used by the tunnel endpoint (AFTR or B4) 181 for troubleshooting purposes (ipv4-address). 183 o An IPv6 address used by a B4 element to reach its AFTR (aftr- 184 ipv6-addr). 186 o The tunnel MTU used to avoid fragmentation (tunnel-mtu). 188 o A policy to instruct the tunnel endpoint (AFTR or B4) whether it 189 must preserve DSCP marking when encapsulating/decapsulating 190 packets (v6-v4-dscp-preservation). 192 In addition, the DS-Lite YANG module augments the NAT YANG module 193 (policy, in particular) with the following: 195 o A policy to limit the number of DS-Lite softwires per subscriber 196 (max-softwire-per-subscriber). 198 o A policy to instruct the AFTR whether a state can be automatically 199 migrated (state-migrate). 201 o Further, in order to prevent a denial-of-service by frequently 202 changing the source IPv6 address, 'b4-address-change-limit' is 203 used to rate-limit such changes. 205 o An instruction to rewrite the TCP Maximum Segment Size (MSS) 206 option (mss-clamping) to avoid TCP fragmentation. 208 Given that the NAPT table of the AFTR element is extended to include 209 the source IPv6 address of incoming packets, the DS-Lite YANG module 210 augments the NAPT44 mapping-entry with the following: 212 o b4-ipv6-address which is used to record the source IPv6 address of 213 a packet received from a B4 element. This IPv6 address is 214 required to disambiguate between the overlapping IPv4 address 215 space of subscribers. 217 o The value of the Traffic Class field in the IPv6 header as 218 received from a B4 element (v6-dscp): This information is used to 219 preserve DSCP marking when encapsulating/decapsulationg at the 220 AFTR. 222 o The IPv4 DSCP marking of the IPv4 packet received from a B4 223 element (internal-v4-dscp): This information can be used by the 224 AFTR for setting the DSCP of packets relayed to a B4 element. 226 o The IPv4 DSCP marking as set by the AFTR in its external interface 227 (external-v4-dscp): An AFTR can be instructed to preserve the same 228 marking or to set it to another value when forwarding an IPv4 229 packet destined to a remote IPv4 host. 231 Access Control List (ACL) and Quality of Service (QoS) policies 232 discussed in Section 2.5 of [RFC6908] are out of scope. A YANG 233 module for ACLs is documented in [I-D.ietf-netmod-acl-model]. 235 Likewise, Port Control Protocol (PCP) related considerations 236 discussed in Section 8.5 of [RFC6333] are out of scope. A YANG 237 module for PCP is documented in [I-D.boucadair-pcp-yang]. 239 The YANG module "ietf-dslite" has the following structure: 241 module: ietf-dslite 242 augment /if:interfaces/if:interface: 243 +--rw ipv6-address? inet:ipv6-address 244 +--rw ipv4-address? inet:ipv4-address 245 +--rw aftr-ipv6-addr? inet:ipv6-address {b4}? 246 +--rw tunnel-mtu? uint16 247 +--rw v6-v4-dscp-preservation? boolean 248 augment /nat:nat/nat:instances/nat:instance/nat:policy: 249 +--rw max-softwires-per-subscriber? uint8 {aftr}? 250 +--rw state-migrate? boolean {aftr}? 251 +--rw b4-address-change-limit? uint32 {aftr}? 252 +--rw mss-clamping {aftr}? 253 +--rw enable? boolean 254 +--rw mss-value? uint16 255 augment /nat:nat/nat:instances/nat:instance 256 /nat:mapping-table/nat:mapping-entry: 257 +--rw b4-ipv6-address {aftr}? 258 | +--rw address? inet:ipv6-address 259 | +--rw last-address-change? yang:date-and-time 260 +--rw v6-dscp? inet:dscp {aftr}? 261 +--rw internal-v4-dscp? inet:dscp {aftr}? 262 +--rw external-v4-dscp? inet:dscp {aftr}? 263 augment /nat:nat/nat:instances/nat:instance 264 /nat:statistics/nat:mappings-statistics: 265 +--ro active-softwires? yang:gauge32 {aftr}? 267 notifications: 268 +---n b4-address-change-limit-policy-violation {aftr}? 269 +--ro id -> /nat:nat/instances/instance/id 270 +--ro policy-id -> /nat:nat/instances/instance/policy/id 271 +--ro address inet:ipv6-address 273 Figure 2: DS-Lite YANG tree diagram 275 Examples to illustrate the use of the "ietf-dslite" module are 276 provided in Appendix A and Appendix B. 278 3. DS-Lite YANG Module 280 This module uses the tunnel interface identity defined in [RFC7224]. 282 file "ietf-dslite@2018-02-26.yang" 283 module ietf-dslite { 284 yang-version 1.1; 286 namespace "urn:ietf:params:xml:ns:yang:ietf-dslite"; 287 prefix dslite; 289 import ietf-inet-types { 290 prefix inet; 291 reference 292 "Section 4 of RFC 6991"; 293 } 295 import ietf-interfaces { 296 prefix if; 297 reference 298 "RFC 8343: A YANG Data Model for Interface Management"; 299 } 301 import iana-if-type { 302 prefix ianaift; 303 reference 304 "RFC 7224: IANA Interface Type YANG Module"; 305 } 307 import ietf-nat { 308 prefix nat; 309 reference 310 "RFC YYYY: A YANG Module for Network Address Translation (NAT) 311 and Network Prefix Translation (NPT)"; 312 } 314 import ietf-yang-types { 315 prefix yang; 316 reference 317 "Section 3 of RFC 6991"; 318 } 320 organization "IETF Softwire Working Group"; 322 contact 324 "WG Web: 325 WG List: 327 Editor: Mohamed Boucadair 328 330 Author: Christian Jacquenet 331 333 Author: Senthil Sivakumar 334 "; 336 description 337 "This module is a YANG module for DS-Lite AFTR and B4 338 implementations. 340 Copyright (c) 2018 IETF Trust and the persons identified as 341 authors of the code. All rights reserved. 343 Redistribution and use in source and binary forms, with or 344 without modification, is permitted pursuant to, and subject 345 to the license terms contained in, the Simplified BSD License 346 set forth in Section 4.c of the IETF Trust's Legal Provisions 347 Relating to IETF Documents 348 (http://trustee.ietf.org/license-info). 350 This version of this YANG module is part of RFC XXXX; see 351 the RFC itself for full legal notices."; 353 revision 2018-02-26 { 354 description 355 "Initial revision."; 356 reference 357 "RFC XXXX: A YANG Data Model for Dual-Stack Lite (DS-Lite)"; 358 } 360 /* 361 * Features 362 */ 364 feature b4 { 365 description 366 "The B4 element is a function implemented on a dual-stack-capable 367 node, either a directly connected device or a CPE, that creates 368 a tunnel to an AFTR."; 369 reference 370 "Section 5 of RFC 6333."; 371 } 373 feature aftr { 374 description 375 "An AFTR element is the combination of an IPv4-in-IPv6 tunnel 376 endpoint and an IPv4-IPv4 NAT implemented on the same node."; 377 reference 378 "Section 6 of RFC 6333."; 380 } 382 /* 383 * Augments 384 */ 386 augment "/if:interfaces/if:interface" { 387 when 'derived-from(if:type, "ianaift:tunnel")'; 388 description 389 "Augments Interface module with DS-Lite parameters. 391 IANA interface types are maintained at this registry: 392 https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib. 394 tunnel (131), -- Encapsulation interface"; 396 leaf ipv6-address { 397 type inet:ipv6-address; 398 description 399 "IPv6 address of the local DS-Lite endpoint (AFTR or B4)."; 400 reference 401 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 402 IPv4 Exhaustion"; 403 } 405 leaf ipv4-address { 406 type inet:ipv4-address; 407 description 408 "IPv4 address of the local DS-Lite AFTR or B4. 410 192.0.0.1 is reserved for the AFTR element, while 411 192.0.0.0/29 is reserved for the B4 element. 413 This address can be used to report ICMP problems and will 414 appear in traceroute outputs."; 415 reference 416 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 417 IPv4 Exhaustion"; 418 } 420 leaf aftr-ipv6-addr { 421 if-feature b4; 422 type inet:ipv6-address; 423 description 424 "Indicates the AFTR's IPv6 address to be used by a B4 element."; 425 reference 426 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 427 IPv4 Exhaustion"; 429 } 431 leaf tunnel-mtu { 432 type uint16; 433 description 434 "Configures a tunnel MTU. 436 [RFC6908] specifies that since fragmentation and reassembly 437 is not optimal, the operator should do everything possible 438 to eliminate the need for it. If the operator uses simple 439 IPv4-in-IPv6 softwire, it is recommended that the MTU size 440 of the IPv6 network between the B4 and the AFTR accounts for 441 the additional overhead (40 bytes)."; 442 reference 443 "RFC 6908: Deployment Considerations for Dual-Stack Lite"; 444 } 446 leaf v6-v4-dscp-preservation { 447 type boolean; 448 description 449 "Copies the DSCP value from the IPv6 header and vice versa. 451 According to Section 2.10 of [RFC6908], operators should 452 use the uniform model by provisioning the network such 453 that the AFTR/B4 copies the DSCP value in the IPv4 header 454 to the Traffic Class field in the IPv6 header, after the 455 IPv4-in-IPv6 encapsulation."; 456 reference 457 "Section 2.10 of RFC 6908."; 458 } 459 } 461 augment "/nat:nat/nat:instances/nat:instance/nat:policy" { 462 when "derived-from-or-self(/nat:nat/nat:instances/nat:instance/" + 463 "nat:type, 'nat:napt44')" + 464 " and /nat:nat/nat:instances/nat:instance/" + 465 "nat:per-interface-binding='dslite'"; 466 if-feature aftr; 467 description 468 "Augments the NAPT44 module with AFTR parameters."; 470 leaf max-softwires-per-subscriber { 471 type uint8; 472 default 1; 473 description 474 "Configures the maximum softwires per subscriber feature. 476 A subscriber is uniquely identified by means 477 of a subscriber mask (subscriber-mask-v6). 479 This policy aims to prevent a misbehaving subscriber from 480 mounting several DS-Lite softwires that would consume 481 additional AFTR resources (e.g., get more external ports 482 if the quota were enforced on a per-softwire basis, 483 consume extra processing due to a large number of active 484 softwires)."; 486 reference 487 "Section 4 of RFC 7785."; 488 } 490 leaf state-migrate { 491 type boolean; 492 default true; 493 description 494 "State migration is enabled by default. 496 In the event a new IPv6 address is assigned to the B4 element, 497 the AFTR should migrate existing state to be bound to the new 498 IPv6 address. This operation ensures that traffic destined to 499 the previous B4's IPv6 address will be redirected to the newer 500 B4's IPv6 address. The destination IPv6 address for tunneling 501 return traffic from the AFTR should be the last seen as the 502 B4's IPv6 source address from the user device (e.g., CPE). 504 The AFTR uses the subscriber-mask-v6 to determine whether two 505 IPv6 addresses belong to the same CPE (e.g., if the 506 subscriber-mask-v6 is set to 56, the AFTR concludes that 507 2001:db8:100:100::1 and 2001:db8:100:100::2 belong to the same 508 CPE assigned with 2001:db8:100:100::/56)."; 510 reference 511 "RFC 7785: Recommendations for Prefix Binding in the Context 512 of Softwire Dual-Stack Lite"; 513 } 515 leaf b4-address-change-limit { 516 type uint32; 517 units "seconds"; 518 default '1800'; 519 description 520 "Minimum number of seconds between successive B4's IPv6 address 521 change from the same prefix. 523 Changing the source B4's IPv6 address may be used as an attack 524 vector. Packets with a new B4's IPv6 address from the same 525 prefix should be rate-limited. 527 It is recommended to set this rate limit to 30 minutes; other 528 values can be set on a per-deployment basis."; 530 reference 531 "RFC 7785: Recommendations for Prefix Binding in the Context 532 of Softwire Dual-Stack Lite"; 533 } 535 container mss-clamping { 536 description 537 "MSS rewriting configuration to avoid IPv6 fragmentation."; 539 leaf enable { 540 type boolean; 541 description 542 "Enable/disable MSS rewriting feature."; 543 } 545 leaf mss-value { 546 type uint16; 547 units "octets"; 548 description 549 "Sets the MSS value to be used for MSS rewriting."; 550 } 551 } 552 } 554 augment "/nat:nat/nat:instances/nat:instance/"+ 555 "nat:mapping-table/nat:mapping-entry" { 556 when "derived-from-or-self(/nat:nat/nat:instances/nat:instance/" + 557 "nat:type, 'nat:napt44')" + 558 " and /nat:nat/nat:instances/nat:instance/" + 559 "nat:per-interface-binding='dslite'"; 560 if-feature aftr; 561 description 562 "Augments the NAPT44 mapping table with DS-Lite specifics."; 564 container b4-ipv6-address { 565 description 566 "Records the IPv6 address used by a B4 element and the last 567 time that address changed."; 569 leaf address { 570 type inet:ipv6-address; 571 description 572 "Corresponds to the IPv6 address used by a B4 element."; 574 reference 575 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 576 IPv4 Exhaustion"; 577 } 579 leaf last-address-change { 580 type yang:date-and-time; 581 description 582 "Records the last time when the address changed."; 583 } 584 } 586 leaf v6-dscp { 587 when "/if:interfaces/if:interface/" + 588 "dslite:v6-v4-dscp-preservation='true'"; 589 type inet:dscp; 590 description 591 "DSCP value used at the softwire level (i.e., IPv6 header)."; 592 } 594 leaf internal-v4-dscp { 595 when "/if:interfaces/if:interface/" + 596 "dslite:v6-v4-dscp-preservation='true'"; 597 type inet:dscp; 598 description 599 "DSCP value of the encapsulated IPv4 packet."; 600 } 602 leaf external-v4-dscp { 603 when "/if:interfaces/if:interface/" + 604 "dslite:v6-v4-dscp-preservation='true'"; 605 type inet:dscp; 606 description 607 "DSCP value of the translated IPv4 packet as marked by 608 the AFTR."; 609 } 610 } 612 augment "/nat:nat/nat:instances/nat:instance/nat:statistics/" + 613 "nat:mappings-statistics" { 614 if-feature aftr; 615 description 616 "Indicates the number of active softwires."; 618 leaf active-softwires{ 619 type yang:gauge32; 620 description 621 "The number of currently active softwires on the AFTR 622 instance."; 623 } 624 } 626 /* 627 * Notifications 628 */ 630 notification b4-address-change-limit-policy-violation { 631 if-feature aftr; 632 description 633 "Generates notifications when a B4 unsuccessfully attempts 634 to change IPv6 address in a time shorter than the value of 635 b4-address-change-limit. 637 Notifications are rate-limited (notify-interval)."; 639 leaf id { 640 type leafref { 641 path "/nat:nat/nat:instances/nat:instance/nat:id"; 642 } 643 mandatory true; 644 description 645 "NAT instance identifier."; 646 } 648 leaf policy-id { 649 type leafref { 650 path "/nat:nat/nat:instances/nat:instance/nat:policy/nat:id"; 651 } 652 mandatory true; 653 description 654 "Policy Identifier."; 655 } 657 leaf address { 658 type inet:ipv6-address; 659 mandatory true; 660 description 661 "B4's IPv6 address."; 662 } 663 } 664 } 665 666 4. Security Considerations 668 The YANG module defined in this document is designed to be accessed 669 via network management protocols such as NETCONF [RFC6241] or 670 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 671 layer, and the mandatory-to-implement secure transport is Secure 672 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 673 mandatory-to-implement secure transport is TLS [RFC5246]. 675 The NETCONF access control model [RFC8341] provides the means to 676 restrict access for particular NETCONF or RESTCONF users to a 677 preconfigured subset of all available NETCONF or RESTCONF protocol 678 operations and content. 680 All data nodes defined in the YANG module which can be created, 681 modified and deleted (i.e., config true, which is the default) are 682 considered sensitive. Write operations (e.g., edit-config) applied 683 to these data nodes without proper protection can negatively affect 684 network operations. An attacker who is able to access to the B4/AFTR 685 can undertake various attacks, such as: 687 o Set the value of 'aftr-ipv6-addr' on the B4 to point to an 688 illegitimate AFTR so that it can intercept all the traffic sent by 689 a B4. Illegitimately intercepting users' traffic is a attack with 690 severe implications on privacy. 692 o Set the MTU to a low value which may increase the number of 693 fragments ('tunnel-mtu' for both B4 and AFTR). 695 o Set 'max-softwire-per-subscriber' to an arbitrary high value, 696 which will be exploited by a misbehaving user to grab more 697 resources (by mounting as many softwires as required to get more 698 external IP addresses/ports) or to perform a Denial-of-Service on 699 the AFTR by mounting a massive number of softwires. 701 o Set 'state-migrate' to 'false' on the AFTR. This action may lead 702 to a service degradation for the users. 704 o Set 'b4-address-change-limit" to an arbitrary low value can ease 705 DoS attacks based on frequent change of B4 IPv6 address. 707 o Set 'v6-v4-dscp-preservation' to 'false" may lead to a service 708 degradation if some policies are applied on the network based on 709 the DSCP value. 711 Additional security considerations are discussed in 712 [I-D.ietf-opsawg-nat-yang]. 714 Security considerations related to DS-Lite are discussed in 715 [RFC6333]. 717 5. IANA Considerations 719 This document requests IANA to register the following URI in the 720 "IETF XML Registry" [RFC3688]: 722 URI: urn:ietf:params:xml:ns:yang:ietf-dslite 723 Registrant Contact: The IESG. 724 XML: N/A; the requested URI is an XML namespace. 726 This document requests IANA to register the following YANG module in 727 the "YANG Module Names" registry [RFC7950]. 729 name: ietf-dslite 730 namespace: urn:ietf:params:xml:ns:yang:ietf-dslite 731 prefix: dslite 732 reference: RFC XXXX 734 6. Acknowledgements 736 Thanks to Qin Wu, Benoit Claise, and Andy Bierman who helped for 737 identifying compiling errors. Mahesh Jethanandani provided early 738 yangdoctors reviews; many thanks to him. 740 Many thanks to Ian Farrer and Tom Petch for the review and comments. 742 7. References 744 7.1. Normative references 746 [I-D.ietf-opsawg-nat-yang] 747 Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, 748 S., and Q. Wu, "A YANG Module for Network Address 749 Translation (NAT) and Network Prefix Translation (NPT)", 750 draft-ietf-opsawg-nat-yang-14 (work in progress), March 751 2018. 753 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 754 DOI 10.17487/RFC3688, January 2004, 755 . 757 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 758 (TLS) Protocol Version 1.2", RFC 5246, 759 DOI 10.17487/RFC5246, August 2008, 760 . 762 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 763 and A. Bierman, Ed., "Network Configuration Protocol 764 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 765 . 767 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 768 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 769 . 771 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 772 Stack Lite Broadband Deployments Following IPv4 773 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 774 . 776 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 777 RFC 6991, DOI 10.17487/RFC6991, July 2013, 778 . 780 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 781 RFC 7224, DOI 10.17487/RFC7224, May 2014, 782 . 784 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 785 RFC 7950, DOI 10.17487/RFC7950, August 2016, 786 . 788 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 789 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 790 . 792 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 793 Access Control Model", STD 91, RFC 8341, 794 DOI 10.17487/RFC8341, March 2018, 795 . 797 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 798 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 799 . 801 7.2. Informative references 803 [I-D.boucadair-pcp-yang] 804 Boucadair, M., Jacquenet, C., Sivakumar, S., and S. 805 Vinapamula, "YANG Modules for the Port Control Protocol 806 (PCP)", draft-boucadair-pcp-yang-05 (work in progress), 807 October 2017. 809 [I-D.ietf-netmod-acl-model] 810 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 811 "Network Access Control List (ACL) YANG Data Model", 812 draft-ietf-netmod-acl-model-19 (work in progress), April 813 2018. 815 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 816 Address Translator (Traditional NAT)", RFC 3022, 817 DOI 10.17487/RFC3022, January 2001, 818 . 820 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 821 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 822 January 2011, . 824 [RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. 825 Boucadair, "Deployment Considerations for Dual-Stack 826 Lite", RFC 6908, DOI 10.17487/RFC6908, March 2013, 827 . 829 [RFC7785] Vinapamula, S. and M. Boucadair, "Recommendations for 830 Prefix Binding in the Context of Softwire Dual-Stack 831 Lite", RFC 7785, DOI 10.17487/RFC7785, February 2016, 832 . 834 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 835 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 836 . 838 Appendix A. B4 Example 840 The following example shows a B4 element (2001:db8:0:1::1) that is 841 configured with an AFTR element (2001:db8:0:2::1). The B4 element is 842 also instructed to preserve the DSCP marking. 844 845 846 myB4 847 ianaift:tunnel 848 true 849 850 2001:db8:0:1::1 851 852 853 2001:db8:0:2::1 854 855 856 true 857 858 859 861 Appendix B. AFTR Examples 863 The following example shows an AFTR that is reachable at 864 2001:db8:0:2::1. Also, this XML snippet indicates that the AFTR is 865 provided with an IPv4 address (192.0.0.1) to be used for 866 troubleshooting purposes such as reporting problems to B4s. 868 Note that a subscriber is identified by a subscriber mask ([RFC7785]) 869 that can be configured by means of [I-D.ietf-opsawg-nat-yang]. 871 872 873 myAFTR 874 ianaift:tunnel 875 true 876 2001:db8:0:2::1 877 192.0.0.1 878 879 881 The following shows an XML excerpt depicting a dynamic UDP mapping 882 entry maintained by a DS-Lite AFTR for a packet received from the B4 883 element introduced in Appendix A. Concretely, this UDP packet 884 received with a source IPv6 address (2001:db8:0:1::1), a source IPv4 885 address (192.0.2.1), and source port number (1568) is translated into 886 a UDP packet having a source IPv4 address (198.51.100.1) and source 887 port number (15000). The remaining lifetime of this mapping is 300 888 seconds. 890 891 15 892 893 dynamic-explicit 894 895 896 17 897 898 899 900 2001:db8:0:1::1 901 902 903 904 192.0.2.1 905 906 907 908 1568 909 910 911 912 198.51.100.1 913 914 915 916 15000 917 918 919 920 300 921 922 924 Authors' Addresses 926 Mohamed Boucadair 927 Orange 928 Rennes 35000 929 France 931 EMail: mohamed.boucadair@orange.com 932 Christian Jacquenet 933 Orange 934 Rennes 35000 935 France 937 EMail: christian.jacquenet@orange.com 939 Senthil Sivakumar 940 Cisco Systems 941 7100-8 Kit Creek Road 942 Research Triangle Park, North Carolina 27709 943 USA 945 Phone: +1 919 392 5158 946 EMail: ssenthil@cisco.com