idnits 2.17.1 draft-jholland-mboned-mnat-01.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 525 has weird spacing: '...-prefix ine...' == Line 560 has weird spacing: '...cher-id wat...' -- The document date (December 23, 2020) is 1220 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 (~~), 3 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 December 23, 2020 5 Expires: June 26, 2021 7 Multicast Network Address Translation 8 draft-jholland-mboned-mnat-01 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 June 26, 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 1.4.2. Implementation status . . . . . . . . . . . . . . . . 6 61 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 62 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1.1. Egress Node Operational Modes . . . . . . . . . . . . 7 64 2.2. Service Discovery . . . . . . . . . . . . . . . . . . . . 8 65 2.2.1. Detecting Invalid Services . . . . . . . . . . . . . 8 66 2.3. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 8 67 2.4. Message Handling . . . . . . . . . . . . . . . . . . . . 8 68 2.4.1. Notification Subscription . . . . . . . . . . . . . . 8 69 2.4.2. Watcher Keys . . . . . . . . . . . . . . . . . . . . 9 70 2.4.3. Egress Group Management . . . . . . . . . . . . . . . 9 71 2.4.4. Ingress Considerations . . . . . . . . . . . . . . . 10 72 2.4.5. MNAT Service Considerations . . . . . . . . . . . . . 10 73 2.4.6. Example Messaging Walkthrough . . . . . . . . . . . . 11 74 3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 11 76 3.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 13 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 4.1. The YANG Module Names Registry . . . . . . . . . . . . . 19 79 4.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 19 80 4.3. The Service Name and Transport Protocol Port Number 81 Registry . . . . . . . . . . . . . . . . . . . . . . . . 19 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 86 7.2. Informative References . . . . . . . . . . . . . . . . . 22 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 Network Address Translation is very widely used for unicast traffic 92 in a variety of networks and according to a variety of mechanisms. 93 [RFC2663] is recommended reading for background on the ways unicast 94 NAT is used. 96 The handling of multicast traffic can pose a variety of additional 97 problems for a network, some of which can be mitigated or avoided if 98 traffic can be mapped to a different address space than its original 99 addressing. This document defines a new service, Multicast Network 100 Address Translation (MNAT) as a mechanism to administer network 101 address mappings for multicast traffic within a network, for the 102 purpose of working around various addressing-related issues. An 103 overview of some of the motivating use cases that require network 104 address remapping for multicast traffic is given in Section 1.3. An 105 explanation of the protocol operation is given in Section 2. 107 Messaging to and from the MNAT service is defined with RESTCONF 108 [RFC8040] using the YANG [RFC7950] model in Section 3. 110 Unlike traditional unicast NAT, MNAT performs address translation at 111 both an ingress point to the network where the traffic is transformed 112 to use an address scheme local to the network, and also at an egress 113 point from the network where the traffic is transformed back to the 114 original address scheme for further forwarding, or for further 115 processing by a receiving application. 117 1.1. Background 119 The reader is assumed to be familiar with the concepts and 120 terminology regarding source-specific multicast as described in 121 [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for 122 group management of source-specific multicast channels, as described 123 in [RFC4604]. 125 The reader is also assumed to be familiar with the concepts and 126 terminology for RESTCONF [RFC8040] and YANG [RFC7950]. 128 The reader is also assumed to be familiar with the use of DNS-SD 129 [RFC6763] for discovery of services provided by the network to end 130 hosts. 132 1.2. Terminology 133 +---------+---------------------------------------------------------+ 134 | Term | Definition | 135 +---------+---------------------------------------------------------+ 136 | (S,G) | A source-specific multicast channel, as described in | 137 | | [RFC4607]. A pair of IP addresses with a source host IP | 138 | | and destination group IP. | 139 | | | 140 | egress | A MNAT client operating at a point where NATted | 141 | node | multicast traffic exits the network (close to the | 142 | | receiver) | 143 | | | 144 | ingress | A MNAT client operating at a point where multicast | 145 | node | traffic enters the network and gets NATted (close to | 146 | | the sender) | 147 | | | 148 | MNAT | A client using the ietf-mnat YANG model via RESTCONF, | 149 | client | or a client with equivalent signaling to an MNAT | 150 | | service. | 151 | | | 152 | NATted | Multicast traffic that has been translated to use | 153 | traffic | addressing or encapsulation assigned locally within the | 154 | | network, rather than its original global addressing. | 155 | | | 156 | SSM | Source-specific multicast, as described in [RFC4607] | 157 +---------+---------------------------------------------------------+ 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in 162 [RFC2119] and [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 1.3. Motivation 167 This section lists use cases where a global (S,G) may not be possible 168 to transport within a network, requiring the use of some kind of 169 encapsulation or address translation in order to adequately 170 communicate the group membership for packet replication within the 171 network, or in order to perform the forwarding for the subscribed 172 traffic within the network. 174 1. Global IPv6 (S,G)s subscribed from within an IPv4-only network, 175 or global IPv4 (S,G)s subscribed from within an IPv6-only 176 network. 178 2. Networks with legacy devices that support only IGMPv2 or MLDv1, 179 or otherwise do not support SSM and cannot discover the external 180 sources without the use of non-standard services since 181 interdomain any-source multicast has been deprecated (see 182 [RFC8815]). 184 3. Networks that ingest external multicast traffic in a way that the 185 route to the source of the traffic does not go through the ingest 186 point may need to use a different source so that the Reverse Path 187 Forwarding (RPF) can find the correct network location for the 188 ingest. 190 4. Networks that provision multicast transport and packet 191 replication channels with static routing instead of dynamic tree- 192 building protocols like PIM-SM [RFC7761]. 194 5. Networks using VLAN [IEEE-802.1Q] for traffic segregation and has 195 Layer 2 access devices that assign VLAN tags according to MAC 196 addresses will get MAC address collisions among multicast groups. 197 Because the bits used for the multicast addresses come from the 198 bottom 23 bits of the destination group address as described in 199 [RFC1112], and those bits can collide between groups, especially 200 in SSM. This breaks the traffic segregation in such devices. 202 A note elaborating on the use of static routing for multicast groups: 204 Some networks have found that there are good use cases to deliver a 205 limited set of packet-replicating flows, including sometimes the use 206 of externally sourced multicast traffic, but have struggled with the 207 operational complexity of operating a dynamic tree-building system 208 based on PIM-SM [RFC7761]. Operating an MNAT service can allow these 209 networks to provide for the limited use of packet-replicating data 210 channels while keeping the operational complexity of handling a 211 dynamically changing set of channels confined to a single service 212 that implements their business logic for admission control, rather 213 than trying to apply access control lists for group membership 214 propagation spread across the network. 216 1.4. Notes for Contributors and Reviewers 218 Note to RFC Editor: Please remove this section and its subsections 219 before publication. 221 This section is to provide references to make it easier to review the 222 development and discussion on the draft so far. 224 1.4.1. Venues for Contribution and Discussion 226 This document is in the Github repository at: 228 https://github.com/GrumpyOldTroll/draft-ietf-mnat 229 Readers are welcome to open issues and send pull requests for this 230 document. 232 Please note that contributions may be merged and substantially 233 edited, and as a reminder, please carefully consider the Note Well 234 before contributing: https://datatracker.ietf.org/submit/note-well/ 236 Substantial discussion of this document should take place on the 237 MBONED working group mailing list (mboned@ietf.org). 239 o Join: https://www.ietf.org/mailman/listinfo/mboned 241 o Search: https://mailarchive.ietf.org/arch/browse/mboned/ 243 1.4.2. Implementation status 245 There is an implementation prototype (MIT-licensed) at: 247 https://github.com/GrumpyOldTroll/mnat 249 Pull requests, comments, testing and deployment reports, etc. are 250 very welcome. Contributors before RFC publication will be credited 251 in this document unless requested otherwise. 253 2. Protocol Operation 255 2.1. Overview 257 The use of MNAT within a network is defined in terms the folowing 258 entities: 260 o MNAT service 262 o ingress nodes 264 o egress nodes 266 Address translation is performed at the ingress (closest to the 267 sender) and egress (closest to the receiver) nodes. Ingress is where 268 an external (S,G) is mapped to locally assigned address mapping 269 before being forwarded for transport within the network. Egress is 270 where the traffic received on locally assigned addresses is 271 translated back to the corresponding external (S,G) address before 272 being forwarded for further transmission or processed by a receiving 273 application. 275 The MNAT service maintains the mapping between external (S,G)s and 276 the local network addresses used to transport traffic of those (S,G)s 277 within the network. The address mapping is performed according to 278 the needs of the network operating the MNAT service, to satisfy 279 whatever constraints and restrictions may be necessary or desirable 280 according to the operational considerations within that network. 281 Some example considerations that have motivated the design of MNAT 282 are described in Section 1.3. 284 Ingress and egress nodes communicate with the MNAT service according 285 to the schema defined by the YANG model in Section 3. In particular, 286 they maintain an up-to-date table of the mappings between the 287 external (S,G)s and the locally assigned addresses for transport 288 within the network in order to perform the corresponding network 289 address translations. 291 TBD: probably add a diagram here. Probably something roughly similar 292 to page 7 of the IETF 108 mboned presentation touching on this: 293 https://www.ietf.org/proceedings/108/slides/slides-108-mboned-status- 294 update-on-multicast-to-the-browser-00.pdf#page=7 296 2.1.1. Egress Node Operational Modes 298 Egress nodes can run in at least two separate modes of operation. 300 One of the modes is "bump in the wire", which refers to a node that 301 receives traffic using the network-assigned locally chosen addresses, 302 and translates the traffic back to the associated externally 303 addressed (S,G) before forwarding the traffic along the rest of the 304 network paths to the receiving applications that tried to join the 305 external (S,G). 307 The second mode is "bump in the host", which refers to a virtual node 308 operating inside a client application. 310 As a "bump in the host" egress node, the virtual egress node can 311 discover and connect to the MNAT service from a receiving 312 application. The receiving application would then use the knowledge 313 about the address mapping within the network to perform a join for 314 the mapped addresses in the local network, rather than for the 315 external (S,G), treating the payloads of the packets received as 316 though they arrived with the external (S,G) addressing. 318 A common scenario for a bump in the wire egress node deployment might 319 be to have egress nodes operating in Customer Premises Equipment 320 (CPE), such as a Cable Modem or Wi-Fi router inside the home of a 321 customer to a multicast-capable Internet Service Provider (ISP). In 322 this scenario, the egress node discovery mechanism for the MNAT 323 service might be a static configuration for the MNAT service's 324 hostname, pushed by the ISP to the CPE devices. 326 For a bump in the host egress node, the discovery of the MNAT service 327 might either operate via DNS-SD [RFC6763] using a search domain for 328 the ISP distributed to hosts via a DHCP Domain Search option 329 [RFC3397], or via configuration instructions the ISP gives to their 330 customers to configure a search domain for their devices, or to 331 configure the MNAT service's hostname for that ISP in their 332 applications. 334 2.2. Service Discovery 336 It is RECOMMENDED that egress devices in end-user operating systems 337 or applications use DNS-SD [RFC6763] by default to discover an MNAT 338 service within their containing networks. However, a network may 339 require the use of other mechanisms, including options such as manual 340 configuration, so implementors are advised to offer manual 341 configuration options in addition. 343 As long as an MNAT client can find a valid hostname to use, it can 344 connect to the given MNAT service and monitor changes to the address 345 assignments within the network. 347 2.2.1. Detecting Invalid Services 349 TBD: recommendations for noticing and discontinuing use of MNAT 350 services that report mappings that don't correspond to the mappings 351 apparently in use in the client's local network (particularly from 352 egress nodes). 354 2.3. RESTCONF Bootstrap 356 TBD: describe the RESTCONF validation and bootstrapping steps. Use 357 the same section name from I-D.draft-ietf-mboned-dorms as a template, 358 assuming it passes a wider review. 360 2.4. Message Handling 362 2.4.1. Notification Subscription 364 When possible, changes to the group assignments should be 365 communicated with subscriptions to data model updates using a server 366 push mechanism, for example as described in [RFC8641]. 368 Where clients or servers do not support server push updates, long 369 polling can be used instead to provide timely updates. See [RFC6202] 370 for an explanation of the approach and a discussion of its pros and 371 cons. 373 If long polling and server push are both unavailable, MNAT clients 374 may need to poll the server to monitor updates instead. This 375 approach is likely to encounter delays in the detection of changes to 376 mapping decisions within the MNAT service, but can be used as a last 377 resort for providing multicast connectivity. 379 2.4.2. Watcher Keys 381 MNAT clients open a persistent connection to the MNAT service and 382 request allocation of a watcher key with the get-new-watcher-key rpc. 383 Watcher keys are identifiers chosen by the MNAT service and 384 communicated to client nodes in the response to a successful get-new- 385 egress-key rpc. Watcher keys SHOULD be based on a random value and 386 unique per new key requested. 388 Egress nodes communicate an interest in global (S,G)s by posting 389 updates to the egress-global-joined container under a watcher with id 390 equal to their watcher-key. 392 Ingress nodes communicate an interest in sets of global (S,G)s by 393 providing a monitor object with a matching filter under a watcher 394 with id equal to their watcher-key. 396 Watcher-keys expire if the refresh-watcher-id rpc is not invoked 397 within the refresh-period given in the response to the get-new- 398 watcher-id rpc. 400 TBD: better explanation about how the service times out egress nodes 401 that don't refresh their egress key on schedule, and how egress nodes 402 that reconnect can attempt to refresh the prior key they were using, 403 but must request a new one on error. Probably define a state per 404 egress key (e.g. active vs. recently expired vs. non-existant) for 405 the MNAT service to maintain. Explain how the MNAT service should 406 use population count from the egress joins to make prioritization 407 decisions for the assignment of flows when there is limited flow 408 space. Probably reference CBACC in that explanation (I-D.draft-ietf- 409 mboned-cbacc). 411 2.4.3. Egress Group Management 413 The egress-global-joined container in the YANG model provides a 414 mechanism for egress nodes to directly advertise their group 415 membership to the MNAT service for externally addressed (S,G)s. 417 Egress nodes advertise their group membership to external (S,G)s to 418 the MNAT service and also advertise group membership to their next- 419 hop router using IGMP or MLD for the locally mapped addressing 420 withing the network. Joins and leaves for the locally mapped network 421 addresses occur in response to downstream joins for an external (S,G) 422 that has or gains a mapping according to the MNAT service, when the 423 join or leave propagates to the egress node. 425 Payloads of the locally mapped traffic should be treated as though 426 they were carried in packets addressed as the external (S,G), 427 including any authentication checks that should be performed for the 428 traffic. Egress nodes that forward traffic (non-virtual egress 429 nodes) will perform an address translation from the locally mapped 430 addressing to the original (S,G) (according to the address mapping 431 the MNAT service provides) before forwarding packets matching a 432 locally mapped address. It is the responsibility of the MNAT service 433 and the network that operates it to ensure that multiple different 434 traffic streams are not merged to the same locally mapped addresses 435 in a way that collides. 437 2.4.4. Ingress Considerations 439 Like egress nodes, ingress nodes monitor the assignments provided by 440 the MNAT service and perform network address translation and group 441 membership propagation. Ingress nodes perform the translation from 442 an external (S,G) to the internally mapped addressing for the local 443 network transport. 445 In general, ingress nodes are translating traffic before the in- 446 network multicast fanout to multiple egress nodes. So an ingress 447 node is generally assumed to be feeding one or more egress nodes. 448 Because one ingress node can feed many egress nodes, ingress nodes 449 should be given priority ahead of egress nodes for notifications 450 about changes to the address mapping from the MNAT service. 452 2.4.5. MNAT Service Considerations 454 The details of the address assignment strategies used by the internal 455 logic of the MNAT service are out of scope for this document. 456 Different instances of MNAT services are expected to use a wide range 457 of considerations specific to the networks in which the instances 458 operate. 460 However, outside of address assignment there are some operational 461 points an MNAT service instance should take into consideration: 463 1. Assignment Transition Grace Period 465 It's recommended to provide a grace period between reassigning a 466 local address mapping to a new external (S,G) after unassigning 467 its mapping to an old (S,G). The grace period should account for 468 the expected time for the connected ingress and egress nodes to 469 process the unassigning of the external (S,G) and for egress 470 nodes to perform leave operations for the old locally mapped 471 address, and for the leave operations to propagate through the 472 network. 474 2. Scaling 476 The MNAT service should be appropriately provisioned to support 477 the expected number of ingress and egress nodes within the 478 network. In an eyeball network, restrictions on the number of 479 egress nodes per shared receiver IP address may be appropriate, 480 to avoid a rogue client application from forming an excessive 481 number of egress connections. Alternately, for bump-in-the-wire 482 deployments of egress nodes in CPE devices it may be appropriate 483 to authenticate the egress connections with a client certificate 484 for each home to avoid denial of service attacks based on 485 overloading the MNAT service with egress connections. 487 Additionally, it's RECOMMENDED to provide per-egress limits on 488 the number of external simultaneous (S,G)s permitted per egress 489 at a level appropriate to the scaling limitations for the 490 network, to avoid denial of service attacks based on overloading 491 the group assignments. 493 2.4.6. Example Messaging Walkthrough 495 TBD: show what an expected example message sequence or 2 would look 496 like. 498 3. YANG Model 500 3.1. Yang Tree 502 The tree diagram below uses the notation defined in [RFC8340]. 504 module: ietf-mnat 505 +--rw egress-global-joined 506 | +--rw watcher* [id] 507 | +--rw id watcher-key 508 | +--rw joined-sg* [id] 509 | +--rw id string 510 | +--rw (channel-type)? 511 | +--:(ssm-channel) 512 | | +--rw source inet:ip-address 513 | | +--rw group 514 | | rt-types:ip-multicast-group-address 515 | +--:(asm-channel) 516 | +--rw asm-group 517 | rt-types:ip-multicast-group-address 518 +--rw ingress-watching 519 | +--rw watcher* [id] 520 | +--rw id watcher-key 521 | +--rw monitor* [id] 522 | +--rw id string 523 | +--rw (monitor-type)? 524 | +--:(monitor-global-sources) 525 | +--rw global-source-prefix inet:ip-prefix 526 +--ro assigned-channels 527 +--ro watcher* [id] 528 +--ro id watcher-key 529 +--ro mapped-sg* [id] 530 +--ro id assignment-id 531 +--ro state assignment-state 532 +--ro global-subscription 533 | +--ro (channel-type)? 534 | +--:(ssm-channel) 535 | | +--ro source inet:ip-address 536 | | +--ro group 537 | | rt-types:ip-multicast-group-address 538 | +--:(asm-channel) 539 | +--ro asm-group 540 | rt-types:ip-multicast-group-address 541 +--ro local-mapping 542 +--ro (mapping-type)? 543 +--:(local-multicast-mapping) 544 +--ro (channel-type)? 545 +--:(ssm-channel) 546 | +--ro source inet:ip-address 547 | +--ro group 548 | rt-types:ip-multicast-group-address 549 +--:(asm-channel) 550 +--ro asm-group 551 rt-types:ip-multicast-group-address 553 rpcs: 554 +---x get-new-watcher-id 555 | +--ro output 556 | +--ro watcher-id watcher-key 557 | +--ro refresh-period? uint16 558 +---x refresh-watcher-id 559 +---w input 560 | +---w watcher-id watcher-key 561 +--ro output 562 +--ro refresh-period? uint16 563 MNAT Tree Diagram 565 3.2. Yang Module 567 file ietf-mnat@2020-12-23.yang 568 module ietf-mnat { 569 yang-version 1.1; 571 namespace "urn:ietf:params:xml:ns:yang:ietf-mnat"; 572 prefix mnat; 574 import ietf-inet-types { 575 prefix inet; 576 reference 577 "RFC 6991: Common YANG Data Types"; 578 } 580 import ietf-routing-types { 581 prefix "rt-types"; 582 reference "RFC 8294"; 583 } 585 organization 586 "IETF MBONED (Multicast Backbone Deployment) Working Group"; 588 contact 589 "WG Web: 590 WG List: 592 Author: Jake Holland 593 "; 595 description 596 "Multicast Network Address Translation Model. 598 Copyright (c) 2012 - 2020 IETF Trust and the persons 599 identified as authors of the code. All rights reserved. 601 Redistribution and use in source and binary forms, with or 602 without modification, is permitted pursuant to, and subject 603 to the license terms contained in, the Simplified BSD 604 License set forth in Section 4.c of the IETF Trust's 605 Legal Provisions Relating to IETF Documents 606 (https://trustee.ietf.org/license-info). 608 This version of this YANG module is part of RFC XXXX; see 609 the RFC itself for full legal notices."; 611 revision "2020-10-22" { 612 description 613 "Initial version."; 614 } 616 grouping multicast-channel { 617 choice channel-type { 618 description 619 "ASM or SSM multicast channels can be represented."; 620 case ssm-channel { 621 leaf source { 622 type inet:ip-address; 623 mandatory true; 624 description 625 "Source address of a multicast channel"; 626 } 627 leaf group { 628 type rt-types:ip-multicast-group-address; 629 mandatory true; 630 description "The global (S,G)'s group address"; 631 } 632 } 633 case asm-channel { 634 leaf asm-group { 635 type rt-types:ip-multicast-group-address; 636 mandatory true; 637 description "The global (S,G)'s group address"; 638 } 639 } 640 } 641 } 643 grouping monitor-definition { 644 choice monitor-type { 645 description 646 "Definition of monitor characteristics."; 647 case monitor-global-sources { 648 leaf global-source-prefix { 649 type inet:ip-prefix; 650 mandatory true; 651 description 652 "Prefix to match for source IPs."; 653 } 654 } 655 } 656 } 658 typedef watcher-key { 659 type string; 660 description 661 "A key for egress identification."; 662 } 664 typedef assignment-id { 665 type uint32; 666 description 667 "A type for assignment identifiers."; 668 } 670 identity assignment-state { 671 description 672 "Base identity to represent assignment states"; 673 } 675 typedef assignment-state { 676 type identityref { 677 base assignment-state; 678 } 679 description "Status of an assigned (S,G)."; 680 } 682 identity unassigned { 683 base assignment-state; 684 description 685 "Represents an unassigned global (S,G) that cannot be 686 received in the local network."; 687 } 689 identity assigned-local-multicast { 690 base assignment-state; 691 description 692 "Represents an assigned global (S,G) that can be 693 received in the local network by joining the associated 694 local-mapping."; 695 } 697 container egress-global-joined { 698 description 699 "Declarations of subscriptions to global (S,G)s per 700 egress."; 702 list watcher { 703 key "id"; 704 description 705 "Mappings of traffic that correspond to the registered 706 interest list for a given watch id (from the 707 get-new-watcher-id rpc)"; 708 leaf id { 709 type watcher-key; 710 description 711 "Identifier from get-new-watcher-id. Tracks assignments 712 of interest to the specific watcher."; 713 } 714 list joined-sg { 715 key "id"; 716 leaf id { 717 type string; 718 description 719 "id of the joined (S,G)"; 720 } 721 description 722 "(S,G)s in the global address space that an egress is 723 joined to. These should get corresponding entries in 724 the assigned-channels lists."; 725 uses multicast-channel; 726 } 727 } 728 } 729 container ingress-watching { 730 description 731 "Matches on (S,G)s that get ingested from this ingress."; 733 list watcher { 734 key "id"; 735 description 736 "Mappings of traffic that correspond to the registered 737 interest list for a given watch id (from the 738 get-new-watcher-id rpc)"; 739 leaf id { 740 type watcher-key; 741 description 742 "Identifier from get-new-watcher-id. Tracks assignments 743 of interest to the specific watcher."; 744 } 745 list monitor { 746 key "id"; 747 leaf id { 748 type string; 749 description 750 "id of the monitor definition"; 751 } 752 uses monitor-definition; 753 } 754 } 756 } 757 container assigned-channels { 758 config false; 759 description 760 "MNAT mappings of global (S,G)s into a local transport."; 762 list watcher { 763 key "id"; 764 description 765 "Mappings of traffic that correspond to the registered 766 interest list for a given watch id (from the 767 get-new-watcher-id rpc)"; 768 leaf id { 769 type watcher-key; 770 description 771 "Identifier from get-new-watcher-id. Tracks assignments 772 of interest to the specific watcher."; 773 } 774 list mapped-sg { 775 key "id"; 776 description 777 "The local network's assignment of global channels to 778 local transport characteristics."; 780 leaf id { 781 type assignment-id; 782 mandatory true; 783 description 784 "Identifier for this assignment."; 785 } 786 leaf state { 787 type assignment-state; 788 mandatory true; 789 description 790 "Status of the global (S,G)s that are assigned in the 791 local network."; 792 } 793 container global-subscription { 794 description 795 "The global channel that's mapped."; 796 uses multicast-channel; 797 } 798 container local-mapping { 799 choice mapping-type { 800 description 801 "The description of how the global channel is 802 transported within the local network"; 804 case local-multicast-mapping { 805 description 806 "Defines the use of a local multicast (S,G) or 807 (*,G)."; 808 uses multicast-channel; 809 } 810 } 811 } 812 } 813 } 814 } 816 rpc get-new-watcher-id { 817 description 818 "Obtain a secret key unique to an individual mnat-egress 819 instance, assigned by the server and used for subscription 820 management."; 821 output { 822 leaf watcher-id { 823 type watcher-key; 824 mandatory true; 825 description 826 "Identifier for assignment monitoring."; 827 } 828 leaf refresh-period { 829 type uint16; 830 default 10; 831 description 832 "Number of seconds to wait between refresh messages."; 833 } 834 } 835 } 836 rpc refresh-watcher-id { 837 description 838 "A secret key unique to an individual mnat-egress instance, 839 assigned by the server and used for subscription 840 management."; 841 input { 842 leaf watcher-id { 843 type watcher-key; 844 mandatory true; 845 description 846 "Egress identifier for assignment monitoring."; 847 } 848 } 849 output { 850 leaf refresh-period { 851 type uint16; 852 default 10; 853 description 854 "Number of seconds to wait between refresh messages."; 855 } 856 } 857 } 858 } 860 862 4. IANA Considerations 864 4.1. The YANG Module Names Registry 866 This document adds one YANG module to the "YANG Module Names" 867 registry maintained at . The following registrations are made, per the format in 869 Section 14 of [RFC6020]: 871 name: ietf-mnat 872 namespace: urn:ietf:params:xml:ns:yang:ietf-mnat 873 prefix: mnat 874 reference: I-D.draft-jholland-mboned-mnat 876 4.2. The XML Registry 878 This document adds the following registration to the "ns" subregistry 879 of the "IETF XML Registry" defined in [RFC3688], referencing this 880 document. 882 URI: urn:ietf:params:xml:ns:yang:ietf-mnat 883 Registrant Contact: The IESG. 884 XML: N/A, the requested URI is an XML namespace. 886 4.3. The Service Name and Transport Protocol Port Number Registry 888 This document adds one service name to the "Service Name and 889 Transport Protocol Port Number Registry" maintained at 890 . The 891 following registrations are made, per the format in Section 8.1.1 of 892 [RFC6335]: 894 Service Name: mnat 895 Transport Protocol(s): TCP, UDP 896 Assignee: IESG 897 Contact: IETF Chair 898 Description: The MNAT service (RESTCONF that 899 includes ietf-mnat YANG model) 900 Reference: I-D.draft-jholland-mboned-mnat 901 Port Number: N/A 902 Service Code: N/A 903 Known Unauthorized Uses: N/A 904 Assignment Notes: N/A 906 5. Security Considerations 908 TBD. (What, me worry?) 910 Notable points to cover: 912 o communcation with the MNAT service should be secured. RESTCONF 913 does this, alternate methods should also do it. 915 o separate authentication of the contents of the multicast traffic 916 is recommended. 918 o mistaken mappings can result in receipt of payloads for the wrong 919 channel. This can happen transiently even during normal 920 operation. Recommend some steps to mitigate and avoid. 922 o Clients can (deliberately or accidentally) overload the service. 923 Limits should be set to avoid disrupting traffic to the rest of 924 the network. 926 6. Acknowledgements 928 Thanks to Lenny Giuliano for very helpful comments on this document. 930 7. References 932 7.1. Normative References 934 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 935 RFC 1112, DOI 10.17487/RFC1112, August 1989, 936 . 938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 939 Requirement Levels", BCP 14, RFC 2119, 940 DOI 10.17487/RFC2119, March 1997, 941 . 943 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 944 Thyagarajan, "Internet Group Management Protocol, Version 945 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 946 . 948 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 949 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 950 DOI 10.17487/RFC3810, June 2004, 951 . 953 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 954 Group Management Protocol Version 3 (IGMPv3) and Multicast 955 Listener Discovery Protocol Version 2 (MLDv2) for Source- 956 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 957 August 2006, . 959 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 960 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 961 . 963 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 964 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 965 . 967 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 968 RFC 7950, DOI 10.17487/RFC7950, August 2016, 969 . 971 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 972 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 973 . 975 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 976 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 977 May 2017, . 979 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 980 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 981 . 983 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 984 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 985 September 2019, . 987 7.2. Informative References 989 [IEEE-802.1Q] 990 IEEE, "Local and Metropolitan Area Networks -- Media 991 Access Control (MAC) Bridges and Virtual Bridged Local 992 Area Networks", IEEE Std 802.1Q, n.d., 993 . 996 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 997 Translator (NAT) Terminology and Considerations", 998 RFC 2663, DOI 10.17487/RFC2663, August 1999, 999 . 1001 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 1002 Protocol (DHCP) Domain Search Option", RFC 3397, 1003 DOI 10.17487/RFC3397, November 2002, 1004 . 1006 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1007 DOI 10.17487/RFC3688, January 2004, 1008 . 1010 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1011 the Network Configuration Protocol (NETCONF)", RFC 6020, 1012 DOI 10.17487/RFC6020, October 2010, 1013 . 1015 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 1016 "Known Issues and Best Practices for the Use of Long 1017 Polling and Streaming in Bidirectional HTTP", RFC 6202, 1018 DOI 10.17487/RFC6202, April 2011, 1019 . 1021 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1022 Cheshire, "Internet Assigned Numbers Authority (IANA) 1023 Procedures for the Management of the Service Name and 1024 Transport Protocol Port Number Registry", BCP 165, 1025 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1026 . 1028 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1029 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1030 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1031 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1032 2016, . 1034 [RFC8815] Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert, 1035 "Deprecating Any-Source Multicast (ASM) for Interdomain 1036 Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815, 1037 August 2020, . 1039 Author's Address 1041 Jake Holland 1042 Akamai Technologies, Inc. 1043 150 Broadway 1044 Cambridge, MA 02144 1045 United States of America 1047 Email: jakeholland.net@gmail.com