idnits 2.17.1 draft-ietf-softwire-dslite-yang-09.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 too long lines in the document, the longest one being 13 characters in excess of 72. == 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 (November 13, 2017) is 2346 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-08 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-14 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 4 errors (**), 0 flaws (~~), 5 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: May 17, 2018 S. Sivakumar 6 Cisco Systems 7 November 13, 2017 9 YANG Data Modules for Dual-Stack Lite (DS-Lite) 10 draft-ietf-softwire-dslite-yang-09 12 Abstract 14 This document defines YANG modules 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 with the RFC number to be assigned to 20 this document: 22 o "This version of this YANG module is part of RFC XXXX;" 24 o "RFC XXXX: YANG Data Modules for Dual-Stack Lite (DS-Lite)"; 26 o "reference: RFC XXXX" 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 17, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. DS-Lite YANG Modules: An Overview . . . . . . . . . . . . . . 4 65 3. DS-Lite AFTR YANG Module . . . . . . . . . . . . . . . . . . 7 66 4. DS-Lite B4 YANG Module . . . . . . . . . . . . . . . . . . . 14 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 8.1. Normative references . . . . . . . . . . . . . . . . . . 18 72 8.2. Informative references . . . . . . . . . . . . . . . . . 19 73 Appendix A. B4 Example . . . . . . . . . . . . . . . . . . . . . 21 74 Appendix B. AFTR Examples . . . . . . . . . . . . . . . . . . . 21 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 77 1. Introduction 79 This document defines data models for DS-Lite [RFC6333], using the 80 YANG data modeling language [RFC7950]. Both the Address Family 81 Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements 82 are covered by this specification. 84 As a reminder, Figure 1 illustrates an overview of the DS-Lite 85 architecture that involves AFTR and B4 elements. 87 +-----------+ 88 | Host | 89 +-----+-----+ 90 |192.0.2.1 91 | 92 | 93 |192.0.2.2 94 +---------|---------+ 95 | | | 96 | Home router | 97 |+--------+--------+| 98 || B4 || 99 |+--------+--------+| 100 +--------|||--------+ 101 |||2001:db8:0:1::1 102 ||| 103 |||<-IPv4-in-IPv6 softwire 104 ||| 105 -------|||------- 106 / ||| \ 107 | ISP core network | 108 \ ||| / 109 -------|||------- 110 ||| 111 |||2001:db8:0:2::1 112 +--------|||--------+ 113 | AFTR | 114 |+--------+--------+| 115 || Concentrator || 116 |+--------+--------+| 117 | |NAT| | 118 | +-+-+ | 119 +---------|---------+ 120 |198.51.100.1 121 | 122 --------|-------- 123 / | \ 124 | Internet | 125 \ | / 126 --------|-------- 127 | 128 |203.0.113.1 129 +-----+-----+ 130 | IPv4 Host | 131 +-----------+ 133 Figure 1: DS-Lite Base Architecture 135 DS-Lite deployment considerations are discussed in [RFC6908]. 137 This document follows the guidelines of [RFC6087], uses the common 138 YANG types defined in [RFC6991], and adopts the Network Management 139 Datastore Architecture (NMDA). 141 1.1. Terminology 143 This document makes use of the terms defined in Section 3 of 144 [RFC6333]. 146 The terminology for describing YANG data modules is defined in 147 [RFC7950]. 149 The meaning of the symbols in tree diagrams is defined in 150 [I-D.ietf-netmod-yang-tree-diagrams]. 152 2. DS-Lite YANG Modules: An Overview 154 As shown in Figure 1: 156 o The AFTR element is a combination of an IPv4-in-IPv6 tunnel and a 157 NAPT function (Section 2.2 of [RFC3022]). 159 o The B4 element is an IPv4-in-IPv6 tunnel. 161 Therefore, the AFTR YANG module is designed to augment both the 162 Interfaces YANG module [RFC7223] and the NAT YANG module 163 [I-D.ietf-opsawg-nat-yang] with DS-Lite specific features. The B4 164 YANG module augments the interfaces YANG module. 166 Concretely, the AFTR YANG module (Figure 2) augments the Interfaces 167 YANG module with the following: 169 o An IPv6 address used by the AFTR for sending and receiving IPv4- 170 in-IPv6 packets (aftr-ipv6-address). 172 o An IPv4 address that is used by the AFTR for troubleshooting 173 purposes (aftr-ipv4-address). 175 o The tunnel MTU, used to avoid fragmentation (tunnel-mtu). 177 o A policy to instruct the AFTR whether it must preserve DSCP 178 marking when encapsulating/decapsulating packets (v6-v4-dscp- 179 preservation). 181 In addition, the AFTR YANG module augments the NAT YANG module 182 (policy, in particular) with the following: 184 o A policy to limit the number of DS-Lite softwires per subscriber 185 (max-softwire-per-subscriber). 187 o A policy to instruct the AFTR whether a state can be automatically 188 migrated (state-migrate). 190 o Further, in order to prevent a denial-of-service by frequently 191 changing the source IPv6 address, 'b4-address-change-limit' is 192 used to rate-lmite such changes. 194 o An instruction to rewrite the TCP Maximum Segment Size (MSS) 195 option (mss-clamping) to avoid TCP fragmentation. 197 Given that the NAPT table of the AFTR element is extended to include 198 the source IPv6 address of incoming packets, the AFTR YANG module 199 augments the NAPT44 mapping-entry with the following: 201 o b4-ipv6-address which is used to record the source IPv6 address of 202 a packet received from a B4 element. This IPv6 address is 203 required to disambiguate between the overlapping IPv4 address 204 space of subscribers. 206 o The value of the Traffic Class field in the IPv6 header as 207 received from a B4 element (v6-dscp): This information is used to 208 preserve DSCP marking when encapsulating/decapsulationg at the 209 AFTR. 211 o The IPv4 DSCP marking of the IPv4 packet received from a B4 212 element (internal-v4-dscp): This information can be used by the 213 AFTR for setting the DSCP of packets relayed to a B4 element. 215 o The IPv4 DSCP marking as set by the AFTR in its external interface 216 (external-v4-dscp): An AFTR can be instructed to preserve the same 217 marking or to set it to another value when forwarding an IPv4 218 packet upstream. 220 Access Control List (ACL) and Quality of Service (QoS) policies 221 discussed in Section 2.5 of [RFC6908] are out of scope. A YANG 222 module for ACLs is documented in [I-D.ietf-netmod-acl-model]. 224 Likewise, PCP-related considerations discussed in Section 8.5 of 225 [RFC6333] are out of scope. A YANG module for PCP is documented in 226 [I-D.boucadair-pcp-yang]. 228 module: ietf-dslite-aftr 229 augment /if:interfaces/if:interface: 230 +--rw aftr-ipv6-address? inet:ipv6-address 231 +--rw aftr-ipv4-address? inet:ipv4-address 232 +--rw tunnel-mtu? uint16 233 +--rw v6-v4-dscp-preservation? boolean 234 augment /nat:nat/nat:instances/nat:instance/nat:policy: 235 +--rw max-softwires-per-subscriber? uint8 236 +--rw state-migrate? boolean 237 +--rw b4-address-change-limit? uint32 238 +--rw mss-clamping 239 +--rw enable? boolean 240 +--rw mss-value? uint16 241 augment /nat:nat/nat:instances/nat:instance/nat:mapping-table/nat:mapping-entry: 242 +--rw b4-ipv6-address 243 | +--rw address? inet:ipv6-address 244 | +--rw last-address-change? yang:date-and-time 245 +--rw v6-dscp? uint8 246 +--rw internal-v4-dscp? uint8 247 +--rw external-v4-dscp? uint8 248 augment /nat:nat/nat:instances/nat:instance/nat:statistics/nat:mappings-statistics: 249 +--ro active-softwires? yang:gauge32 251 notifications: 252 +---n b4-address-change-limit-policy-violation 253 +--ro id -> /nat:nat/instances/instance/id 254 +--ro policy-id -> /nat:nat/instances/instance/policy/id 255 +--ro address inet:ipv6-address 257 Figure 2: YANG Module for DS-Lite AFTR 259 Examples to illustrate the use of this module are provided in 260 Appendix B. 262 The B4 YANG module (Figure 3) augments the Interfaces YANG module 263 with the following: 265 o An IPv6 address used by a B4 element for sending and receiving 266 IPv4-in-IPv6 packets (b4-ipv6-address). 268 o The IPv6 address of the AFTR to use by a B4 element (aftr- 269 ipv6-addr). 271 o An IPv4 address that is used by a B4 element for troubleshooting 272 purposes (b4-ipv4-address). 274 o The tunnel MTU at the B4 side to avoid fragmentation (tunnel-mtu). 276 o An instruction whether DSCP marking is to be preserved when 277 encapsulating an IPv4 packet in an IPv6 packet (v6-v4-dscp- 278 preservation). 280 module: ietf-dslite-b4 281 augment /if:interfaces/if:interface: 282 +--rw b4-ipv6-address? inet:ipv6-address 283 +--rw aftr-ipv6-addr? inet:ipv6-address 284 +--rw b4-ipv4-address? inet:ipv4-address 285 +--rw tunnel-mtu? uint16 286 +--rw v6-v4-dscp-preservation? boolean 288 Figure 3: YANG Module for DS-Lite B4 290 An example to illustrate the use of this module is provided in 291 Appendix A. 293 3. DS-Lite AFTR YANG Module 295 file "ietf-dslite-aftr@2017-11-14.yang" 297 module ietf-dslite-aftr { 298 yang-version 1.1; 300 namespace "urn:ietf:params:xml:ns:yang:ietf-dslite-aftr"; 301 prefix dslite-aftr; 303 import ietf-inet-types { prefix inet; } 304 import ietf-interfaces { prefix if; } 305 import iana-if-type { prefix ianaift; } 306 import ietf-nat {prefix nat;} 307 import ietf-yang-types { prefix yang; } 309 organization "IETF Softwire Working Group"; 311 contact 313 "WG Web: 314 WG List: 316 WG Chair: Ian Farrer 317 319 WG Chair: Yong Cui 320 322 Editor: Mohamed Boucadair 323 325 Editor: Christian Jacquenet 326 328 Editor: Senthil Sivakumar 329 "; 331 description 332 "This module is a YANG module for DS-Lite AFTR 333 implementations. 335 Copyright (c) 2017 IETF Trust and the persons identified as 336 authors of the code. All rights reserved. 338 Redistribution and use in source and binary forms, with or 339 without modification, is permitted pursuant to, and subject 340 to the license terms contained in, the Simplified BSD License 341 set forth in Section 4.c of the IETF Trust's Legal Provisions 342 Relating to IETF Documents 343 (http://trustee.ietf.org/license-info). 345 This version of this YANG module is part of RFC XXXX; see 346 the RFC itself for full legal notices."; 348 revision 2017-11-14 { 349 description 350 "Initial revision."; 351 reference 352 "RFC XXXX: YANG Data Modules for Dual-Stack Lite (DS-Lite)"; 353 } 355 augment "/if:interfaces/if:interface" { 356 when "if:type = 'ianaift:tunnel'"; 357 description 358 "Augments Interface module with AFTR parameters. 359 IANA interface types are maintained at this registry: 360 https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib. 362 tunnel (131), -- Encapsulation interface"; 364 leaf aftr-ipv6-address { 365 type inet:ipv6-address; 366 description 367 "IPv6 address of the DS-Lite AFTR."; 368 reference 369 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 370 IPv4 Exhaustion"; 371 } 372 leaf aftr-ipv4-address { 373 type inet:ipv4-address; 374 default "192.0.0.1"; 375 description 376 "IPv4 address of the DS-Lite AFTR. 378 192.0.0.1 is reserved for the AFTR element. 380 This address can be used to report ICMP problems and will 381 appear in traceroute outputs."; 382 reference 383 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 384 IPv4 Exhaustion"; 385 } 387 leaf tunnel-mtu { 388 type uint16; 389 description 390 "Configures a tunnel MTU. 391 [RFC6908] specifies that since fragmentation and reassembly 392 is not optimal, the operator should do everything possible 393 to eliminate the need for it. If the operator uses simple 394 IPv4-in-IPv6 softwire, it is recommended that the MTU size 395 of the IPv6 network between the B4 and the AFTR accounts for 396 the additional overhead (40 bytes)."; 397 reference 398 "RFC 6908: Deployment Considerations for Dual-Stack Lite"; 399 } 401 leaf v6-v4-dscp-preservation { 402 type boolean; 403 description 404 "Copies the DSCP value from the IPv6 header and vice versa. 406 According to Section 2.10 of [RFC6908], operators should 407 use this model by provisioning the network such that the AFTR 408 copies the DSCP value in the IPv4 header to the Traffic Class 409 field in the IPv6 header, after the encapsulation for 410 the downstream traffic."; 411 reference 412 "Section 2.10 of RFC 6908."; 413 } 414 } 416 augment "/nat:nat/nat:instances/nat:instance/nat:policy" { 417 description 418 "Augments the NAPT44 module with AFTR parameters."; 420 leaf max-softwires-per-subscriber { 421 type uint8; 422 default 1; 423 description 424 "Configures the maximum softwires per subscriber feature. 426 A subscriber is uniquely identified by means 427 of subscriber-mask. 429 This policy aims to prevent a misbehaving subscriber from 430 mounting several DS-Lite softwires that would consume 431 additional AFTR resources (e.g., get more external ports 432 if the quota were enforced on a per-softwire basis, 433 consume extra processing due to a large number of active 434 softwires)."; 436 reference 437 "Section 4 of RFC 7785."; 438 } 440 leaf state-migrate { 441 type boolean; 442 default true; 443 description 444 "State migration is enabled by default. 446 In the event a new IPv6 address is assigned to the B4 element, 447 the AFTR should migrate existing state to be bound to the new 448 IPv6 address. This operation ensures that traffic destined to 449 the previous B4's IPv6 address will be redirected to the newer 450 B4's IPv6 address. The destination IPv6 address for tunneling 451 return traffic from the AFTR should be the last seen as the B4's 452 IPv6 source address from the CPE. 454 The AFTR uses the subscriber-mask to determine whether two 455 IPv6 addresses belong to the same CPE (e.g., if the 456 subscriber-mask is set to 56, the AFTR concludes that 457 2001:db8:100:100::1 and 2001:db8:100:100::2 belong to the same 458 CPE assigned with 2001:db8:100:100::/56)."; 460 reference 461 "RFC 7785: Recommendations for Prefix Binding in the Context 462 of Softwire Dual-Stack Lite"; 463 } 465 leaf b4-address-change-limit { 466 type uint32; 467 units "seconds"; 468 default '1800'; 469 description 470 "Minimum number of seconds between successive B4's IPv6 address 471 change from the same prefix. 473 Changing the source B4's IPv6 address may be used as an attack 474 vector. Packets with a new B4's IPv6 address from the same 475 prefix should be rate-limited. 477 It is recommended to set this rate limit to 30 minutes; other 478 values can be set on a per-deployment basis."; 480 reference 481 "RFC 7785: Recommendations for Prefix Binding in the Context 482 of Softwire Dual-Stack Lite"; 483 } 485 container mss-clamping { 486 description 487 "MSS rewriting configuration to avoid IPv6 fragmentation."; 489 leaf enable { 490 type boolean; 491 description 492 "Enable/disable MSS rewriting feature."; 493 } 495 leaf mss-value { 496 type uint16; 497 units "octets"; 498 description 499 "Sets the MSS value to be used for MSS rewriting."; 500 } 501 } 502 } 504 augment "/nat:nat/nat:instances/nat:instance/"+ 505 "nat:mapping-table/nat:mapping-entry"{ 506 description 507 "Augments the NAPT44 mapping table with DS-Lite specifics."; 509 container b4-ipv6-address { 510 description 511 "Records the IPv6 address used by the B4 element and the last 512 time that address changed."; 514 leaf address { 515 type inet:ipv6-address; 516 description 517 "Corresponds to the IPv6 address used by the B4 element."; 518 reference 519 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 520 IPv4 Exhaustion"; 521 } 523 leaf last-address-change { 524 type yang:date-and-time; 525 description 526 "Records the last time when the address changed."; 527 } 528 } 530 leaf v6-dscp { 531 when "/if:interfaces/if:interface/" + 532 "dslite-aftr:v6-v4-dscp-preservation='true'"; 533 type uint8; 534 description 535 "DSCP value used at the softwire level (i.e., IPv6 header)."; 536 } 538 leaf internal-v4-dscp { 539 when "/if:interfaces/if:interface/" + 540 "dslite-aftr:v6-v4-dscp-preservation='true'"; 541 type uint8; 542 description 543 "DSCP value of the encapsulated IPv4 packet."; 544 } 546 leaf external-v4-dscp { 547 when "/if:interfaces/if:interface/" + 548 "dslite-aftr:v6-v4-dscp-preservation='true'"; 549 type uint8; 550 description 551 "DSCP value of the translated IPv4 packet as marked by 552 the AFTR."; 553 } 554 } 556 augment "/nat:nat/nat:instances/nat:instance/nat:statistics/" + 557 "nat:mappings-statistics" { 558 description 559 "Indicates the number of active softwires."; 561 leaf active-softwires{ 562 type yang:gauge32; 563 description 564 "The number of currently active softwires on the AFTR 565 instance."; 566 } 567 } 569 /* 570 * Notifications 571 */ 573 notification b4-address-change-limit-policy-violation { 574 description 575 "Generates notifications when a B4 unsuccessfully attempts 576 to change IPv6 address in a time shorter than the value of 577 b4-address-change-limit. 579 Notifications are rate-limited (notify-interval)."; 581 leaf id { 582 type leafref { 583 path "/nat:nat/nat:instances/nat:instance/nat:id"; 584 } 585 mandatory true; 586 description 587 "NAT instance identifier."; 588 } 590 leaf policy-id { 591 type leafref { 592 path "/nat:nat/nat:instances/nat:instance/nat:policy/nat:id"; 593 } 594 mandatory true; 595 description 596 "Policy Identifier."; 597 } 599 leaf address { 600 type inet:ipv6-address; 601 mandatory true; 602 description 603 "B4's IPv6 address."; 604 } 605 } 606 } 607 609 4. DS-Lite B4 YANG Module 611 file "ietf-dslite-b4@2017-11-13.yang" 613 module ietf-dslite-b4 { 614 yang-version 1.1; 615 namespace "urn:ietf:params:xml:ns:yang:ietf-dslite-b4"; 616 prefix dslite-b4; 618 import ietf-inet-types { prefix inet; } 619 import ietf-interfaces { prefix if; } 620 import iana-if-type { prefix ianaift; } 622 organization "IETF Softwire Working Group"; 624 contact 626 "WG Web: 627 WG List: 629 WG Chair: Ian Farrer 630 632 WG Chair: Yong Cui 633 635 Editor: Mohamed Boucadair 636 638 Editor: Christian Jacquenet 639 641 Editor: Senthil Sivakumar 642 "; 644 description 645 "This module is a YANG module for DS-Lite B4 implementations. 647 Copyright (c) 2017 IETF Trust and the persons identified as 648 authors of the code. All rights reserved. 650 Redistribution and use in source and binary forms, with or 651 without modification, is permitted pursuant to, and subject 652 to the license terms contained in, the Simplified BSD License 653 set forth in Section 4.c of the IETF Trust's Legal Provisions 654 Relating to IETF Documents 655 (http://trustee.ietf.org/license-info). 656 This version of this YANG module is part of RFC XXXX; see 657 the RFC itself for full legal notices."; 659 revision 2017-11-13 { 660 description 661 "Initial revision."; 662 reference 663 "RFC XXXX: YANG Data Modules for Dual-Stack Lite (DS-Lite)"; 664 } 666 augment "/if:interfaces/if:interface" { 667 when "if:type = 'ianaift:tunnel'"; 668 description 669 "Augments Interface module with B4 parameters. 670 IANA interface types are maintained at this registry: 671 https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib. 673 tunnel (131), -- Encapsulation interface"; 675 leaf b4-ipv6-address { 676 type inet:ipv6-address; 677 description 678 "The IPv6 address used by the B4 element."; 679 reference 680 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 681 IPv4 Exhaustion"; 682 } 684 leaf aftr-ipv6-addr { 685 type inet:ipv6-address; 686 description 687 "The AFTR's IPv6 address."; 688 reference 689 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 690 IPv4 Exhaustion"; 691 } 693 leaf b4-ipv4-address { 694 type inet:ipv4-address; 695 default "192.0.0.2"; 696 description 697 "IPv4 address of the DS-Lite B4. 699 192.0.0.0/29 is reserved for the B4 element. 701 This address can be used to report ICMP problems and will 702 appear in traceroute outputs."; 703 reference 704 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 705 IPv4 Exhaustion"; 706 } 708 leaf tunnel-mtu { 709 type uint16; 710 description 711 "Configures a tunnel MTU. 713 [RFC6908] specifies that since fragmentation and reassembly is 714 not optimal, the operator should do everything possible to 715 eliminate the need for it. If the operator uses simple 716 IPv4-in-IPv6 softwire, it is recommended that the MTU size of 717 the IPv6 network between the B4 and the AFTR accounts for 718 the additional overhead (40 bytes)."; 719 reference 720 "RFC 6908: Deployment Considerations for Dual-Stack Lite"; 721 } 723 leaf v6-v4-dscp-preservation { 724 type boolean; 725 description 726 "Copies the DSCP value from the IPv6 header and vice versa. 728 Operators should use this model by provisioning the network such 729 that the AFTR copies the DSCP value in the IPv4 header to 730 the Traffic Class field in the IPv6 header, after the 731 encapsulation for the downstream traffic."; 732 reference 733 "Section 2.10 of RFC 6908."; 734 } 735 } 736 } 737 739 5. Security Considerations 741 The YANG module defined in this document is designed to be accessed 742 via network management protocols such as NETCONF [RFC6241] or 743 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 744 layer, and the mandatory-to-implement secure transport is Secure 745 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 746 mandatory-to-implement secure transport is TLS [RFC5246]. 748 The NETCONF access control model [RFC6536] provides the means to 749 restrict access for particular NETCONF or RESTCONF users to a 750 preconfigured subset of all available NETCONF or RESTCONF protocol 751 operations and content. 753 All data nodes defined in the YANG module which can be created, 754 modified and deleted (i.e., config true, which is the default) are 755 considered sensitive. Write operations (e.g., edit-config) applied 756 to these data nodes without proper protection can negatively affect 757 network operations. An attacker who is able to access to the B4/AFTR 758 can undertake various attacks, such as: 760 o Set the value of 'aftr-ipv6-addr' on the B4 to point to an 761 illegitimate AFTR so that it can intercept all the traffic sent by 762 a B4. Illegitimately intercepting users' traffic is a attack with 763 severe implications on privacy. 765 o Set the MTU to a low value which may increase the number of 766 fragments ('tunnel-mtu' for both B4 and AFTR). 768 o Set 'max-softwire-per-subscriber' to an arbitrary high value, 769 which will be exploited by a misbehaving user to grab more 770 resources (by mounting as many softwires as required to get more 771 external IP addresses/ports) or to perform a Denial-of-Service on 772 the AFTR by mounting a massive number of softwires. 774 o Set 'state-migrate' to 'false' on the AFTR. This action may lead 775 to a service degradation for the users. 777 o Set 'b4-address-change-limit" to an arbitrary low value can ease 778 DoS attacks based on frequent change of B4 IPv6 address. 780 o Set 'v6-v4-dscp-preservation' to 'false" may lead to a service 781 degradation if some policies are applied on the network based on 782 the DSCP value. 784 Additional security considerations are discussed in 785 [I-D.ietf-opsawg-nat-yang]. 787 Security considerations related to DS-Lite are discussed in 788 [RFC6333]. 790 6. IANA Considerations 792 This document requests IANA to register the following URIs in the 793 "IETF XML Registry" [RFC3688]: 795 URI: urn:ietf:params:xml:ns:yang:ietf-dslite-aftr 796 Registrant Contact: The IESG. 797 XML: N/A; the requested URI is an XML namespace. 799 URI: urn:ietf:params:xml:ns:yang:ietf-dslite-b4 800 Registrant Contact: The IESG. 801 XML: N/A; the requested URI is an XML namespace. 803 This document requests IANA to register the following YANG modules in 804 the "YANG Module Names" registry [RFC7950]. 806 name: ietf-dslite-aftr 807 namespace: urn:ietf:params:xml:ns:yang:ietf-dslite-aftr 808 prefix: dslite-aftr 809 reference: RFC XXXX 811 name: ietf-dslite-b4 812 namespace: urn:ietf:params:xml:ns:yang:ietf-dslite-b4 813 prefix: dslite-b4 814 reference: RFC XXXX 816 7. Acknowledgements 818 Thanks to Qin Wu for identifying a compiling error. Mahesh 819 Jethanandani provided an early yangdoctors review; many thanks to 820 him. 822 Many thanks to Ian Farrer for the review and comments. 824 8. References 826 8.1. Normative references 828 [I-D.ietf-opsawg-nat-yang] 829 Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, 830 S., and Q. Wu, "A YANG Data Model for Network Address 831 Translation (NAT) and Network Prefix Translation (NPT)", 832 draft-ietf-opsawg-nat-yang-08 (work in progress), November 833 2017. 835 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 836 DOI 10.17487/RFC3688, January 2004, 837 . 839 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 840 (TLS) Protocol Version 1.2", RFC 5246, 841 DOI 10.17487/RFC5246, August 2008, 842 . 844 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 845 and A. Bierman, Ed., "Network Configuration Protocol 846 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 847 . 849 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 850 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 851 . 853 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 854 Stack Lite Broadband Deployments Following IPv4 855 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 856 . 858 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 859 Protocol (NETCONF) Access Control Model", RFC 6536, 860 DOI 10.17487/RFC6536, March 2012, 861 . 863 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 864 RFC 6991, DOI 10.17487/RFC6991, July 2013, 865 . 867 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 868 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 869 . 871 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 872 RFC 7950, DOI 10.17487/RFC7950, August 2016, 873 . 875 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 876 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 877 . 879 8.2. Informative references 881 [I-D.boucadair-pcp-yang] 882 Boucadair, M., Jacquenet, C., Sivakumar, S., and S. 883 Vinapamula, "YANG Modules for the Port Control Protocol 884 (PCP)", draft-boucadair-pcp-yang-05 (work in progress), 885 October 2017. 887 [I-D.ietf-netmod-acl-model] 888 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 889 "Network Access Control List (ACL) YANG Data Model", 890 draft-ietf-netmod-acl-model-14 (work in progress), October 891 2017. 893 [I-D.ietf-netmod-yang-tree-diagrams] 894 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 895 ietf-netmod-yang-tree-diagrams-02 (work in progress), 896 October 2017. 898 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 899 Address Translator (Traditional NAT)", RFC 3022, 900 DOI 10.17487/RFC3022, January 2001, 901 . 903 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 904 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 905 January 2011, . 907 [RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. 908 Boucadair, "Deployment Considerations for Dual-Stack 909 Lite", RFC 6908, DOI 10.17487/RFC6908, March 2013, 910 . 912 [RFC7785] Vinapamula, S. and M. Boucadair, "Recommendations for 913 Prefix Binding in the Context of Softwire Dual-Stack 914 Lite", RFC 7785, DOI 10.17487/RFC7785, February 2016, 915 . 917 Appendix A. B4 Example 919 The following example shows a B4 element (2001:db8:0:1::1) that is 920 configured with an AFTR element (2001:db8:0:2::1). The B4 element is 921 also instructed to preserve the DSCP marking. 923 924 myB4 925 ianaift:tunnel 926 true 927 2001:db8:0:1::1 928 2001:db8:0:2::1 929 true 930 932 Appendix B. AFTR Examples 934 The following example shows an AFTR that is reachable at 935 2001:db8:0:2::1. Also, this XML snippet indicates that the AFTR is 936 provided with an IPv4 address (192.0.0.1) to be used for 937 troubleshooting purposes such as reporting problems to B4s. 939 Note that a subscriber is identified by a subscriber-mask ([RFC7785]) 940 that can be configured by means of [I-D.ietf-opsawg-nat-yang]. 942 943 myAFTR 944 ianaift:tunnel 945 true 946 2001:db8:0:2::1 947 192.0.0.1 948 950 The following shows an XML excerpt depicting a dynamic UDP mapping 951 entry maintained by a DS-Lite AFTR for a packet received from the B4 952 element introduced in Appendix A. Concretely, this UDP packet 953 received with a source IPv6 address (2001:db8:0:1::1), a source IPv4 954 address (192.0.2.1), and source port number (1568) is translated into 955 a UDP packet having a source IPv4 address (198.51.100.1) and source 956 port number (15000). The remaining lifetime of this mapping is 300 957 seconds. 959 960 15 961 962 dynamic-explicit 963 964 965 17 966 967 968
969 2001:db8:0:1::1 970
971 972 973 192.0.2.1 974 975 976 977 1568 978 979 980 981 198.51.100.1 982 983 984 985 15000 986 987 988 989 300 990 991 993 Authors' Addresses 995 Mohamed Boucadair 996 Orange 997 Rennes 35000 998 France 1000 EMail: mohamed.boucadair@orange.com 1001 Christian Jacquenet 1002 Orange 1003 Rennes 35000 1004 France 1006 EMail: christian.jacquenet@orange.com 1008 Senthil Sivakumar 1009 Cisco Systems 1010 7100-8 Kit Creek Road 1011 Research Triangle Park, North Carolina 27709 1012 USA 1014 Phone: +1 919 392 5158 1015 EMail: ssenthil@cisco.com