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