idnits 2.17.1 draft-jholland-mboned-mnat-00.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 == Line 496 has weird spacing: '...ress-id egr...' -- The document date (October 31, 2020) is 1266 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned J. Holland 3 Internet-Draft Akamai Technologies, Inc. 4 Intended status: Standards Track October 31, 2020 5 Expires: May 4, 2021 7 Multicast Network Address Translation 8 draft-jholland-mboned-mnat-00 10 Abstract 12 This document defines a method for a network to maintain Network 13 Address Translation address mappings for the transport of globally 14 addressed multicast traffic within a network that can't otherwise 15 forward the globally addressed traffic. A new Multicast Network 16 Address Translation (MNAT) service is defined to communicate the 17 address mappings to ingress and egress points within the network, and 18 considerations for operation of the MNAT service are described. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 4, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.4. Notes for Contributors and Reviewers . . . . . . . . . . 5 59 1.4.1. Venues for Contribution and Discussion . . . . . . . 5 60 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 61 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1.1. Egress Node Operational Modes . . . . . . . . . . . . 6 63 2.2. Service Discovery . . . . . . . . . . . . . . . . . . . . 7 64 2.2.1. Detecting Invalid Services . . . . . . . . . . . . . 7 65 2.3. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 8 66 2.4. Message Handling . . . . . . . . . . . . . . . . . . . . 8 67 2.4.1. Notification Subscription . . . . . . . . . . . . . . 8 68 2.4.2. Egress Keys . . . . . . . . . . . . . . . . . . . . . 8 69 2.4.3. Egress Group Management . . . . . . . . . . . . . . . 9 70 2.4.4. Ingress Considerations . . . . . . . . . . . . . . . 9 71 2.4.5. MNAT Service Considerations . . . . . . . . . . . . . 9 72 2.4.6. Example Messaging Walkthrough . . . . . . . . . . . . 10 73 3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 12 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 77 4.1. The YANG Module Names Registry . . . . . . . . . . . . . 17 78 4.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 17 79 4.3. The Service Name and Transport Protocol Port Number 80 Registry . . . . . . . . . . . . . . . . . . . . . . . . 17 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 85 7.2. Informative References . . . . . . . . . . . . . . . . . 20 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 Network Address Translation is very widely used for unicast traffic 91 in a variety of networks and according to a variety of mechanisms. 92 [RFC2663] is recommended reading for background on the ways unicast 93 NAT is used. 95 The handling of multicast traffic can pose a variety of additional 96 problems for a network, some of which can be mitigated or avoided if 97 traffic can be mapped to a different address space than its original 98 addressing. This document defines a new service, Multicast Network 99 Address Translation (MNAT), as a mechanism to administer network 100 address mappings for multicast traffic within a network, for the 101 purpose of working around various addressing-related issues. An 102 overview of some of the motivating use cases that require network 103 address remapping for multicast traffic is given in Section 1.3. An 104 explanation of the protocol operation is given in Section 2. 106 Messaging to and from the MNAT service is defined with RESTCONF 107 [RFC8040] using the YANG [RFC7950] model in Section 3. 109 Unlike traditional unicast NAT, MNAT performs address translation at 110 both an ingress point to the network where the traffic is transformed 111 to use an address scheme local to the network, and also at an egress 112 point from the network where the traffic is transformed back to the 113 original address scheme for further forwarding, or for further 114 processing by a receiving application. 116 1.1. Background 118 The reader is assumed to be familiar with the concepts and 119 terminology regarding source-specific multicast as described in 120 [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for 121 group management of source-specific multicast channels, as described 122 in [RFC4604]. 124 The reader is also assumed to be familiar with the concepts and 125 terminology for RESTCONF [RFC8040] and YANG [RFC7950]. 127 The reader is also assumed to be familiar with the use of DNS-SD 128 [RFC6763] for discovery of services provided by the network to end 129 hosts. 131 1.2. Terminology 132 +---------+---------------------------------------------------------+ 133 | Term | Definition | 134 +---------+---------------------------------------------------------+ 135 | (S,G) | A source-specific multicast channel, as described in | 136 | | [RFC4607]. A pair of IP addresses with a source host IP | 137 | | and destination group IP. | 138 | | | 139 | egress | A MNAT client operating at a point where NATted | 140 | node | multicast traffic exits the network. | 141 | | | 142 | ingress | A MNAT client operating at a point where multicast | 143 | node | traffic enters the network and gets NATted | 144 | | | 145 | MNAT | A client using the ietf-mnat YANG model via RESTCONF, | 146 | client | or a client with equivalent signaling to an MNAT | 147 | | service. | 148 | | | 149 | NATted | Multicast traffic that has been translated to use | 150 | traffic | addressing or encapsulation assigned locally within the | 151 | | network, rather than its original global addressing. | 152 | | | 153 | SSM | Source-specific multicast, as described in [RFC4607] | 154 +---------+---------------------------------------------------------+ 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in 159 [RFC2119] and [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 1.3. Motivation 164 This section lists use cases where a global (S,G) may not be possible 165 to transport within a network, requiring the use of some kind of 166 encapsulation or address translation in order to adequately 167 communicate the group membership for packet replication within the 168 network, or in order to perform the forwarding for the subscribed 169 traffic within the network. 171 o Global IPv6 (S,G)s subscribed from within an IPv4-only network, or 172 global IPv4 (S,G)s subscribed from within an IPv6-only network. 174 o Networks with legacy devices that support only IGMPv2 or MLDv1, or 175 otherwise do not support SSM and cannot discover the external 176 sources without the use of non-standard services since interdomain 177 any-source multicast has been deprecated (see [RFC8815]). 179 o Networks that provision multicast transport and packet replication 180 channels with static group addresses instead of dynamic tree- 181 building protocols like PIM-SM [RFC7761]. 183 A note elaborating on the use of static provisioning of multicast 184 groups: 186 Some networks have found that there are good use cases to deliver a 187 limited set of packet-replicating flows, including sometimes the use 188 of externally sourced multicast traffic, but have struggled with the 189 operational complexity of operating a dynamic tree-building system 190 based on PIM-SM [RFC7761]. Operating an MNAT service can allow these 191 networks to provide for the limited use of packet-replicating data 192 channels while keeping the operational complexity of handling a 193 dynamically changing set of channels confined to a single service 194 that implements their business logic for admission control, rather 195 than trying to apply access control lists for group membership 196 propagation spread across the network. 198 1.4. Notes for Contributors and Reviewers 200 Note to RFC Editor: Please remove this section and its subsections 201 before publication. 203 This section is to provide references to make it easier to review the 204 development and discussion on the draft so far. 206 1.4.1. Venues for Contribution and Discussion 208 This document is in the Github repository at: 210 https://github.com/GrumpyOldTroll/draft-ietf-mnat 212 Readers are welcome to open issues and send pull requests for this 213 document. 215 Please note that contributions may be merged and substantially 216 edited, and as a reminder, please carefully consider the Note Well 217 before contributing: https://datatracker.ietf.org/submit/note-well/ 219 Substantial discussion of this document should take place on the 220 MBONED working group mailing list (mboned@ietf.org). 222 o Join: https://www.ietf.org/mailman/listinfo/mboned 224 o Search: https://mailarchive.ietf.org/arch/browse/mboned/ 226 2. Protocol Operation 228 2.1. Overview 230 The use of MNAT within a network is defined in terms the folowing 231 entities: 233 o MNAT service 235 o ingress nodes 237 o egress nodes 239 Address translation is performed at the ingress and egress nodes. 240 Ingress is where an external (S,G) is mapped to locally assigned 241 address mapping before being forwarded for transport within the 242 network. Egress is where the traffic received on locally assigned 243 addresses is translated back to the corresponding external (S,G) 244 address before being forwarded for further transmission or processed 245 by a receiving application. 247 The MNAT service maintains the mapping between external (S,G)s and 248 the local network addresses used to transport traffic of those (S,G)s 249 within the network. The address mapping is performed according to 250 the needs of the network operating the MNAT service, to satisfy 251 whatever constraints and restrictions may be necessary or desirable 252 according to the operational considerations within that network. 253 Some example considerations that have motivated the design of MNAT 254 are described in Section 1.3. 256 Ingress and egress nodes communicate with the MNAT service according 257 to the schema defined by the YANG model in Section 3. In particular, 258 they maintain an up-to-date table of the mappings between the 259 external (S,G)s and the locally assigned addresses for transport 260 within the network in order to perform the corresponding network 261 address translations. 263 TBD: probably add a diagram here. Probably something roughly similar 264 to page 7 of the IETF 108 mboned presentation touching on this: 265 https://www.ietf.org/proceedings/108/slides/slides-108-mboned-status- 266 update-on-multicast-to-the-browser-00.pdf#page=7 268 2.1.1. Egress Node Operational Modes 270 Egress nodes can run in at least two separate modes of operation. 272 One of the modes is "bump in the wire", which refers to a node that 273 receives traffic using the network-assigned locally chosen addresses, 274 and translates the traffic back to the associated externally 275 addressed (S,G) before forwarding the traffic along the rest of the 276 network paths to the receiving applications that tried to join the 277 external (S,G). 279 The second mode is "bump in the host", which refers to a virtual node 280 operating inside a client application. 282 As a "bump in the host" egress node, the virtual egress node can 283 discover and connect to the MNAT service from a receiving 284 application. The receiving application would then use the knowledge 285 about the address mapping within the network to perform a join for 286 the mapped addresses in the local network, rather than for the 287 external (S,G), treating the payloads of the packets received as 288 though they arrived with the external (S,G) addressing. 290 A common scenario for a bump in the wire egress node deployment might 291 be to have egress nodes operating in Customer Premesis Equipment 292 (CPE), such as a Cable Modem or Wi-Fi router inside the home of a 293 customer to a multicast-capable Internet Service Provider (ISP). In 294 this scenario, the egress node discovery mechanism for the MNAT 295 service might be a static configuration for the MNAT service's 296 hostname, pushed by the ISP to the CPE devices. 298 For a bump in the host egress node, the discovery of the MNAT service 299 might either operate via DNS-SD [RFC6763] using a search domain for 300 the ISP distributed to hosts via a DHCP Domain Search option 301 [RFC3397], or via configuration instructions the ISP gives to their 302 customers to configure a search domain for their devices, or to 303 configure the MNAT service's hostname for that ISP in their 304 applications. 306 2.2. Service Discovery 308 It is RECOMMENDED that a network operating an MNAT service provide 309 service discovery with the use of DNS-SD [RFC6763]. However, a 310 network MAY use other mechanisms, including options such as manual 311 configuration. As long as an MNAT client can find a valid hostname 312 to use, it can connect to the given MNAT service and monitor changes 313 to the address assignments within the network. 315 2.2.1. Detecting Invalid Services 317 TBD: recommendations for noticing and discontinuing use of MNAT 318 services that report mappings that don't correspond to the mappings 319 apparently in use in the client's local network (particularly from 320 egress nodes). 322 2.3. RESTCONF Bootstrap 324 TBD: describe the RESTCONF validation and bootstrapping steps. Use 325 the same section name from I-D.draft-ietf-mboned-dorms as a template, 326 assuming it passes a wider review. 328 2.4. Message Handling 330 2.4.1. Notification Subscription 332 When possible, changes to the group assignments should be 333 communicated with subscriptions to data model updates using a server 334 push mechanism, for example as described in [RFC8641]. 336 Where clients or servers do not support server push updates, long 337 polling can be used instead to provide timely updates. See [RFC6202] 338 for an explanation of the approach and a discussion of its pros and 339 cons. 341 If long polling and server push are both unavailable, MNAT clients 342 may need to poll the server to monitor updates instead. This 343 approach is likely to encounter delays in the detection of changes to 344 mapping decisions within the MNAT service, but can be used as a last 345 resort for providing multicast connectivity. 347 2.4.2. Egress Keys 349 Egress nodes open a persistent connection to the MNAT service and 350 request allocation of an egress key with the get-new-egress-key rpc. 351 Egress keys are identifiers chosen by the MNAT service and 352 communicated to egress nodes in the response to a successful get-new- 353 egress-key rpc. Egress keys SHOULD be based on a random value and 354 unique per new key requested. 356 Egress nodes provide their egress key when performing group 357 management functions (join and leave operations). 359 TBD: better explanation about how the service times out egress nodes 360 that don't refresh their egress key on schedule, and how egress nodes 361 that reconnect can attempt to refresh the prior key they were using, 362 but must request a new one on error. Probably define a state per 363 egress key (e.g. active vs. recently expired vs. non-existant) for 364 the MNAT service to maintain. Explain how the MNAT service should 365 use population count from the egress joins to make prioritization 366 decisions for the assignment of flows when there is limited flow 367 space. Probably reference CBACC in that explanation (I-D.draft-ietf- 368 mboned-cbacc). 370 2.4.3. Egress Group Management 372 The join-global and leave-global RPCs in the YANG model provide a 373 mechanism for egress nodes to directly advertise their group 374 membership to the MNAT service for externally addressed (S,G)s. 376 Egress nodes advertise their group membership to external (S,G)s to 377 the MNAT service and also advertise group membership to their next- 378 hop router using IGMP or MLD for the locally mapped addressing 379 withing the network. Joins and leaves for the locally mapped network 380 addresses occur in response to downstream joins for an external (S,G) 381 that has or gains a mapping according to the MNAT service, when the 382 join or leave propagates to the egress node. 384 Payloads of the locally mapped traffic should be treated as though 385 they were carried in packets addressed as the external (S,G), 386 including any authentication checks that should be performed for the 387 traffic. Egress nodes that forward traffic (non-virtual egress 388 nodes) will perform an address translation from the locally mapped 389 addreessing to the original (S,G) (according to the address mapping 390 the MNAT service provides) before forwarding packets matching a 391 locally mapped address. It is the responsibility of the MNAT service 392 and the network that operates it to ensure that multiple different 393 traffic streams are not merged to the same locally mapped addresses 394 in a way that collides. 396 2.4.4. Ingress Considerations 398 Like egress nodes, ingress nodes monitor the assignments provided by 399 the MNAT service and perform network address translation and group 400 membership propagation. Ingress nodes perform the translation from 401 an external (S,G) to the internally mapped addressing for the local 402 network transport. 404 In general, ingress nodes are translating traffic before the in- 405 network multicast fanout to multiple egress nodes. So an ingress 406 node is generally assumed to be feeding one or more egress nodes. 407 Because one ingress node can feed many egress nodes, ingress nodes 408 should be given priority ahead of egress nodes for notifications 409 about changes to the address mapping from the MNAT service. 411 2.4.5. MNAT Service Considerations 413 The details of the address assignment strategies used by the internal 414 logic of the MNAT service are out of scope for this document. 415 Different instances of MNAT services are expected to use a wide range 416 of considerations specific to the networks in which the instances 417 operate. 419 However, outside of address assignment there are some operational 420 points an MNAT service instance should take into consideration: 422 1. Assignment Transition Grace Period 424 It's recommended to provide a grace period between reassigning a 425 local address mapping to a new external (S,G) after unassigning 426 its mapping to an old (S,G). The grace period should account for 427 the expected time for the connected ingress and egress nodes to 428 process the unassigning of the external (S,G) and for egress 429 nodes to perform leave operations for the old locally mapped 430 address, and for the leave operations to propagate through the 431 network. 433 2. Scaling 435 The MNAT service should be appropriately provisioned to support 436 the expected number of ingress and egress nodes within the 437 network. In an eyeball network, restrictions on the number of 438 egress nodes per shared receiver IP address may be appropriate, 439 to avoid a rogue client application from forming an excessive 440 number of egress connections. Alternately, for bump-in-the-wire 441 deployments of egress nodes in CPE devices it may be appropriate 442 to authenticate the egress connections with a client certificate 443 for each home to avoid denial of service attacks based on 444 overloading the MNAT service with egress connections. 446 Additionally, it's RECOMMENDED to provide per-egress limits on 447 the number of external simultaneous (S,G)s permitted per egress 448 at a level appropriate to the scaling limitations for the 449 network, to avoid denial of service attacks based on overloading 450 the group assignments. 452 2.4.6. Example Messaging Walkthrough 454 TBD: show what an expected example message sequence or 2 would look 455 like. 457 3. YANG Model 459 3.1. Yang Tree 461 The tree diagram below uses the notation defined in [RFC8340]. 463 module: ietf-mnat 464 +--ro assigned-channels 465 +--ro mapped-sg* [id] 466 +--ro id assignment-id 467 +--ro state assignment-state 468 +--ro global-subscription 469 | +--ro (channel-type)? 470 | +--:(ssm-channel) 471 | | +--ro source inet:ip-address 472 | | +--ro group 473 | | rt-types:ip-multicast-group-address 474 | +--:(asm-channel) 475 | +--ro asm-group 476 | rt-types:ip-multicast-group-address 477 +--ro local-mapping 478 +--ro (mapping-type)? 479 +--:(local-multicast-mapping) 480 +--ro (channel-type)? 481 +--:(ssm-channel) 482 | +--ro source inet:ip-address 483 | +--ro group 484 | rt-types:ip-multicast-group-address 485 +--:(asm-channel) 486 +--ro asm-group 487 rt-types:ip-multicast-group-address 489 rpcs: 490 +---x get-new-egress-key 491 | +--ro output 492 | +--ro egress-id egress-key 493 | +--ro refresh-period? uint16 494 +---x refresh-egress-key 495 | +---w input 496 | +---w egress-id egress-key 497 +---x join-global 498 | +---w input 499 | +---w egress-id egress-key 500 | +---w (channel-type)? 501 | +--:(ssm-channel) 502 | | +---w source inet:ip-address 503 | | +---w group 504 | | rt-types:ip-multicast-group-address 505 | +--:(asm-channel) 506 | +---w asm-group 507 | rt-types:ip-multicast-group-address 508 +---x leave-global 509 +---w input 510 +---w egress-id egress-key 511 +---w (channel-type)? 512 +--:(ssm-channel) 513 | +---w source inet:ip-address 514 | +---w group 515 | rt-types:ip-multicast-group-address 516 +--:(asm-channel) 517 +---w asm-group 518 rt-types:ip-multicast-group-address 520 MNAT Tree Diagram 522 3.2. Yang Module 524 file ietf-mnat@2020-11-02.yang 525 module ietf-mnat { 526 yang-version 1.1; 528 namespace "urn:ietf:params:xml:ns:yang:ietf-mnat"; 529 prefix mnat; 531 import ietf-yang-types { 532 prefix yang; 533 } 535 import ietf-inet-types { 536 prefix inet; 537 reference 538 "RFC 6991: Common YANG Data Types"; 539 } 541 import ietf-routing-types { 542 prefix "rt-types"; 543 reference "RFC 8294"; 544 } 546 organization 547 "IETF MBONED (Multicast Backbone Deployment) Working Group"; 549 contact 550 "WG Web: 551 WG List: 553 Author: Jake Holland 554 "; 556 description 557 "Multicast Network Address Translation Model. 559 Copyright (c) 2012 - 2020 IETF Trust and the persons 560 identified as authors of the code. All rights reserved. 562 Redistribution and use in source and binary forms, with or 563 without modification, is permitted pursuant to, and subject 564 to the license terms contained in, the Simplified BSD 565 License set forth in Section 4.c of the IETF Trust's 566 Legal Provisions Relating to IETF Documents 567 (https://trustee.ietf.org/license-info). 569 This version of this YANG module is part of RFC XXXX; see 570 the RFC itself for full legal notices."; 572 revision "2020-10-22" { 573 description 574 "Initial version."; 575 } 577 grouping multicast-channel { 578 choice channel-type { 579 description 580 "ASM or SSM multicast channels can be represented."; 581 case ssm-channel { 582 leaf source { 583 type inet:ip-address; 584 mandatory true; 585 description 586 "Source address of a multicast channel"; 587 } 588 leaf group { 589 type rt-types:ip-multicast-group-address; 590 mandatory true; 591 description "The global (S,G)'s group address"; 592 } 593 } 594 case asm-channel { 595 leaf asm-group { 596 type rt-types:ip-multicast-group-address; 597 mandatory true; 598 description "The global (S,G)'s group address"; 599 } 600 } 601 } 602 } 604 typedef egress-key { 605 type string; 606 description 607 "A key for egress identification."; 608 } 609 typedef assignment-id { 610 type uint32; 611 description 612 "A type for assignment identifiers."; 613 } 615 identity assignment-state { 616 description 617 "Base identity to represent assignment states"; 618 } 620 typedef assignment-state { 621 type identityref { 622 base assignment-state; 623 } 624 description "Status of an assigned (S,G)."; 625 } 627 identity unassigned { 628 base assignment-state; 629 description 630 "Represents an unassigned global (S,G) that cannot be 631 received in the local network."; 632 } 634 identity assigned-local-multicast { 635 base assignment-state; 636 description 637 "Represents an assigned global (S,G) that can be 638 received in the local network by joining the associated 639 local-mapping."; 640 } 642 container assigned-channels { 643 config false; 644 description 645 "MNAT mappings of global (S,G)s into a local transport."; 647 list mapped-sg { 648 key "id"; 649 description 650 "The local network's assignment of global channels to 651 local transport characteristics."; 653 leaf id { 654 type assignment-id; 655 mandatory true; 656 description 657 "Identifier for this assignment."; 658 } 659 leaf state { 660 type assignment-state; 661 mandatory true; 662 description 663 "Status of the global (S,G)s that are assigned in the 664 local network."; 665 } 666 container global-subscription { 667 description 668 "The global channel that's mapped."; 669 uses multicast-channel; 670 } 671 container local-mapping { 672 choice mapping-type { 673 description 674 "The description of how the global channel is 675 transported within the local network"; 677 case local-multicast-mapping { 678 description 679 "Defines the use of a local multicast (S,G) or 680 (*,G)."; 681 uses multicast-channel; 682 } 683 } 684 } 685 } 686 } 688 rpc get-new-egress-key { 689 description 690 "Obtain a secret key unique to an individual mnat-egress 691 instance, assigned by the server and used for subscription 692 management."; 693 output { 694 leaf egress-id { 695 type egress-key; 696 mandatory true; 697 description 698 "Egress identifier for subscription management."; 699 } 700 leaf refresh-period { 701 type uint16; 702 default 10; 703 description 704 "Number of seconds to wait between refresh messages."; 706 } 707 } 708 } 709 rpc refresh-egress-key { 710 description 711 "A secret key unique to an individual mnat-egress instance, 712 assigned by the server and used for subscription 713 management."; 714 input { 715 leaf egress-id { 716 type egress-key; 717 mandatory true; 718 description 719 "Egress identifier for subscription management."; 720 } 721 } 722 } 723 rpc join-global { 724 description 725 "An mnat-egress instance calls this RPC to register to the 726 network an interest in a global (S,G). Depending on 727 popularity and local network decisions, this may result in 728 adding and possibly removing an entry in 729 assigned-channels/mapped-sg."; 730 input { 731 leaf egress-id { 732 type egress-key; 733 mandatory true; 734 description 735 "Egress identifier."; 736 } 737 uses multicast-channel; 738 } 739 } 740 rpc leave-global { 741 description 742 "An mnat-egress instance calls this RPC to register to the 743 network an interest in a global (S,G). Depending on 744 popularity and local network decisions, this may result in 745 adding and possibly removing an entry in 746 assigned-channels/mapped-sg."; 747 input { 748 leaf egress-id { 749 type egress-key; 750 mandatory true; 751 description 752 "Egress identifier."; 753 } 754 uses multicast-channel; 755 } 756 } 757 } 759 761 4. IANA Considerations 763 4.1. The YANG Module Names Registry 765 This document adds one YANG module to the "YANG Module Names" 766 registry maintained at . The following registrations are made, per the format in 768 Section 14 of [RFC6020]: 770 name: ietf-mnat 771 namespace: urn:ietf:params:xml:ns:yang:ietf-mnat 772 prefix: mnat 773 reference: I-D.draft-jholland-mboned-mnat 775 4.2. The XML Registry 777 This document adds the following registration to the "ns" subregistry 778 of the "IETF XML Registry" defined in [RFC3688], referencing this 779 document. 781 URI: urn:ietf:params:xml:ns:yang:ietf-mnat 782 Registrant Contact: The IESG. 783 XML: N/A, the requested URI is an XML namespace. 785 4.3. The Service Name and Transport Protocol Port Number Registry 787 This document adds one service name to the "Service Name and 788 Transport Protocol Port Number Registry" maintained at 789 . The 790 following registrations are made, per the format in Section 8.1.1 of 791 [RFC6335]: 793 Service Name: mnat 794 Transport Protocol(s): TCP, UDP 795 Assignee: IESG 796 Contact: IETF Chair 797 Description: The MNAT service (RESTCONF that 798 includes ietf-mnat YANG model) 799 Reference: I-D.draft-jholland-mboned-mnat 800 Port Number: N/A 801 Service Code: N/A 802 Known Unauthorized Uses: N/A 803 Assignment Notes: N/A 805 5. Security Considerations 807 TBD. (What, me worry?) 809 Notable points to cover: 811 o communcation with the MNAT service should be secured. RESTCONF 812 does this, alternate methods should also do it. 814 o separate authentication of the contents of the multicast traffic 815 is recommended. 817 o mistaken mappings can result in receipt of payloads for the wrong 818 channel. This can happen transiently even during normal 819 operation. Recommend some steps to mitigate and avoid. 821 o Clients can (deliberately or accidentally) overload the service. 822 Limits should be set to avoid disrupting traffic to the rest of 823 the network. 825 6. Acknowledgements 827 Many thanks to anyone who reads this and provides feedback. 829 7. References 831 7.1. Normative References 833 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 834 Requirement Levels", BCP 14, RFC 2119, 835 DOI 10.17487/RFC2119, March 1997, 836 . 838 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 839 Thyagarajan, "Internet Group Management Protocol, Version 840 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 841 . 843 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 844 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 845 DOI 10.17487/RFC3810, June 2004, 846 . 848 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 849 Group Management Protocol Version 3 (IGMPv3) and Multicast 850 Listener Discovery Protocol Version 2 (MLDv2) for Source- 851 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 852 August 2006, . 854 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 855 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 856 . 858 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 859 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 860 . 862 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 863 RFC 7950, DOI 10.17487/RFC7950, August 2016, 864 . 866 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 867 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 868 . 870 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 871 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 872 May 2017, . 874 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 875 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 876 . 878 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 879 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 880 September 2019, . 882 7.2. Informative References 884 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 885 Translator (NAT) Terminology and Considerations", 886 RFC 2663, DOI 10.17487/RFC2663, August 1999, 887 . 889 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 890 Protocol (DHCP) Domain Search Option", RFC 3397, 891 DOI 10.17487/RFC3397, November 2002, 892 . 894 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 895 DOI 10.17487/RFC3688, January 2004, 896 . 898 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 899 the Network Configuration Protocol (NETCONF)", RFC 6020, 900 DOI 10.17487/RFC6020, October 2010, 901 . 903 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 904 "Known Issues and Best Practices for the Use of Long 905 Polling and Streaming in Bidirectional HTTP", RFC 6202, 906 DOI 10.17487/RFC6202, April 2011, 907 . 909 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 910 Cheshire, "Internet Assigned Numbers Authority (IANA) 911 Procedures for the Management of the Service Name and 912 Transport Protocol Port Number Registry", BCP 165, 913 RFC 6335, DOI 10.17487/RFC6335, August 2011, 914 . 916 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 917 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 918 Multicast - Sparse Mode (PIM-SM): Protocol Specification 919 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 920 2016, . 922 [RFC8815] Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert, 923 "Deprecating Any-Source Multicast (ASM) for Interdomain 924 Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815, 925 August 2020, . 927 Author's Address 929 Jake Holland 930 Akamai Technologies, Inc. 931 150 Broadway 932 Cambridge, MA 02144 933 United States of America 935 Email: jakeholland.net@gmail.com