idnits 2.17.1 draft-ietf-ngtrans-mtp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([NAT-PT], [SIIT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2002) is 7864 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) ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT') ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1933 (ref. 'TRANS-MECH') (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 October 15, 2002 4 Expires in six month 5 K. Tsuchiya, Hitachi 6 H. Higuchi, Hitachi 7 S. Sawada, Hitachi 8 S. Nozaki, Hitachi 10 An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp) 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other docu- 26 ments at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 In the stage of the transition from IPv4 to IPv6 it is necessary 39 that IPv4 nodes and IPv6 nodes can communicate directly. This memo 40 proposes a mechanism which enables such direct communication for 41 multicast, in addition to that for unicast defined in [SIIT] and 42 [NAT-PT]. 44 1. Introduction 46 It is expected that lots of IPv4 nodes will remain, for their suc- 47 cess, for a long time even after the transition to IPv6 starts. On 48 the other hand IPv6-only nodes will appear, for cost reasons or as 49 a result of exhaustion of the IPv4 address space, before IPv4 nodes 50 disappear. Therefore, it is highly desirable to develop a mechanism 51 which enables direct communication between IPv4 nodes and IPv6 52 nodes, in order to advance the transition smoothly. [SIIT] and 53 [NAT-PT] have already proposed such mechanisms, but they are 54 applied only to unicast communication, not to multicast. So it is 55 necessary to provide another mechanism for multicast. 57 This memo describes an entire scheme of multicast communication 58 between IPv4 nodes and IPv6 nodes. The scheme is composed by a mul- 59 ticast translator and an address mapper who are located at the site 60 boundary between IPv4 and IPv6. It is not necessary to modify IPv4 61 nodes and IPv6 nodes. 63 This memo uses the words defined in [IPV4], [IPV6], and [TRANS- 64 MECH]. 66 2. Components 68 This section describes components needed for the mechanism. 70 The system consists of a multicast translator, and an address map- 71 per. In order to allow IPv4 nodes and IPv6 nodes to directly commu- 72 nicate using multicast, they need to be installed on the site 73 boundary between IPv4 and IPv6. Figure 1 illustrates the network 74 system interconnected by them. 76 +-----------+ +-----------+ 77 | IPv4 | | IPv6 | 78 | Multicast | | Multicast | 79 | Sender | | Sender | 80 | Node | | Node | 81 +-----+-----+ +-----+-----+ 82 | | 83 +-----+-----+ +-----+-----+ 84 | | +------------------+ | | 85 | IPv4 land | | Address Mapper | | IPv6 land | 86 | | +--------+---------+ | | 87 | | | | | 88 | | +------------+------------+ | | 89 | | | Multicast Translator | | | 90 | | | +----------+ | | | 91 | +--+ |Translator| +--+ | 92 | | | +----------+ | | | 93 | | | +---------+ +---------+ | | | 94 | | | |IPv4 | |IPv6 | | | | 95 | | | |Multicast| |Multicast| | | | 96 | | | |Proxy | |Proxy | | | | 97 | | | +---------+ +---------+ | | | 98 | | +-------------------------+ | | 99 +-----+-----+ +-----+-----+ 100 | | 101 +-----+-----+ +-----+-----+ 102 | IPv4 | | IPv6 | 103 | Multicast | | Multicast | 104 | Receiver | | Receiver | 105 | Node | | Node | 106 +-----------+ +-----------+ 107 Figure. 1 Network system 109 2.1 Multicast Translator 111 It locates between an IPv4 land and an IPv6 land, and translates 112 IPv4 multicast packets into IPv6 multicast packets and vice versa. 113 It consists of the following three sub-components. 115 (1) Translator 117 It is a component which translates IPv4 multicast packets into 118 IPv6 multicast packets and vice versa. There are several trans- 119 lation types. 121 o Gateway 123 It terminates data bound for an IPv4 multicast group at 124 application layer, and relays the data to an IPv6 multicast 125 group and vice versa. 127 o Header conversion router 129 When receiving IPv4 multicast packets, it converts the IPv4 130 headers into IPv6 headers, fragments the IPv6 packets if nec- 131 essary, and then forwards the packets. Likewise, when receiv- 132 ing IPv6 multicast packets, it converts the IPv6 headers into 133 IPv4 headers, and then forwards the IPv4 packets. 135 (2) IPv4 Multicast Proxy 137 It joins IPv4 multicast groups as a proxy of IPv6 receiver 138 nodes. Thereby it receives packets bound for the IPv4 multicast 139 groups, and then hands the packets to the translator. 141 (3) IPv6 Multicast Proxy 143 It joins IPv6 multicast groups as a proxy of IPv4 receiver 144 nodes. Thereby it receives packets bound for the IPv6 multicast 145 groups, and then hands the packets to the translator. 147 2.2 Address mapper 149 It maintains each unicast address spool for IPv4 and IPv6. The IPv4 150 spool, for example, consists of private addresses [PRIVATE] bound 151 for the multicast translator. An example of the IPv6 spool is IPv6 152 address space assigned to virtual IPv6 organization on the IPv4 153 land. 155 NOTE: The IPv4 spool is used for temporary IPv4 addresses of IPv6 156 sender nodes (or IPv6 receiver nodes) in the IPv4 land. Also the 157 IPv6 spool is used for temporary IPv6 addresses of IPv4 sender 158 nodes (or IPv4 receiver nodes) in the IPv6 land. So the mtp should 159 advertise IPv4/IPv6 unicast routes for them so that packets to them 160 can be delivered to the mtp and also RPF check (RPF: Reverse Path 161 Forwarding) can work well. 163 Also, it maintains a mapping table which consists of pairs of an 164 IPv4 address and an IPv6 address. When the translator (or the IPv4 165 Proxy or the IPv6 Proxy) requests it to assign an IPv6 address cor- 166 responding to an IPv4 address (an IPv4 source address), it selects 167 a proper IPv6 address out of the table, and returns the address to 168 the translator. When there is not a proper entry for an IPv4 uni- 169 cast address, it selects and returns an IPv6 unicast address out of 170 the spool, and registers a new entry into the table. When there is 171 not a proper entry for an IPv4 multicast group address (an IPv4 172 destination address), it registers a new entry, which consists of 173 the IPv4 multicast group address and that of IPv6 corresponding to 174 the IPv4 address, into the table. The IPv6 address is a special 175 type of one proposed in this memo. See section 4. 177 NOTE: The translator translates packets between IPv4 and IPv6 178 according to the table. The scheme of the above address mapping is 179 conformable to NAT-PT; IPv4 addresses are mapped to IPv6 addresses 180 one to one. In addition, there may be another scheme which follows 181 NAPT-PT, but in that case there can be a limitation in the system. 182 For example, if an IPv4 sender node's address is mapped to a single 183 registered IPv6 address and its TCP/UDP port, then IPv6 receiver 184 node cannot communicate with the IPv4 sender node in unicast except 185 via this TCP/UDP port. Because it does not have a mapping table 186 except for that TCP/UDP port, and the translator would fail in 187 translating IPv6 into IPv4 in case of the TCP/UDP port. 189 When the translator (or the IPv4 Proxy or the IPv6 Proxy) requests 190 it to assign an IPv4 address corresponding to an IPv6 address, it 191 works like the above. 193 3. Interaction Examples 195 This section explains communication from one IPv4 multicast sender 196 node to one or more IPv6 multicast receiver nodes, and communica- 197 tion from one IPv6 multicast sender node to one or more IPv4 multi- 198 cast receiver nodes, respectively. 200 3.1 Communication from IPv4 to IPv6 202 The following subsection explains communication from one IPv4 mul- 203 ticast sender node, called "sender4", to one or more IPv6 multicast 204 receiver nodes, called "receiver6." 205 Preceding the communication, the administrator of the multicast 206 translator carries out the setup to translate IPv4 multicast pack- 207 ets, which are sent by "sender4", into IPv6. According to the 208 direction of the administrator, the IPv4 multicast proxy joins the 209 IPv4 multicast group as a proxy of "receiver6", and then registers 210 a new entry, which consists of the IPv4 multicast group address and 211 that of IPv6 corresponding to the IPv4 address, into the mapping 212 table. The IPv6 address is a special type of one proposed in this 213 memo, and takes the structure which is identified by a prefix of 214 ffxy::/96 and holds the IPv4 address in the low-order 32-bits. See 215 section 4. 217 NOTE: In order to make MTP applicable to the Source-Specific Multi- 218 cast(PIM-SSM), MTP needs to show IPv6 addresses corresponding to 219 IPv4 multicast Senders to an IPv6 Receiver, in addition to IPv6 220 addresses corresponding to IPv4 multicast addresses available; MTP 221 can know IPv4 multicast addresses available and their Senders' 222 addresses as one of IPv4 Receivers. For example, MTP obtains IPv4 223 multicast addresses available and their Senders' addresses via an 224 IPv4 SAP(an IPv4 SDR). MTP shows the IPv4 multicast addresses and 225 the corresponding IPv6 multicast addresses, and the Senders' 226 addresses and the corresponding IPv6 unicast addresses on its web. 227 An IPv6 Receiver looks at its web and gets the IPv6 multicast 228 address and the IPv6 Senders' address. 230 The communication is triggered by "sender4." "sender4" sends an 231 IPv4 multicast packet. 233 When the packet arrives at the multicast translator, the IPv4 mul- 234 ticast proxy receives it and hands it to the translator. The trans- 235 lator tries to translate it into an IPv6 packet but does not know 236 how to translate the IPv4 source address and the IPv4 destination 237 address. So the translator requests the mapper to tell mapping 238 entries for them. 240 The mapper checks its mapping table with each of them and finds 241 only a mapping entry for the IPv4 destination address. 243 But there is not a mapping entry for the IPv4 source address, so 244 the mapper selects an IPv6 address out of the IPv6 spool and regis- 245 ters a new entry, which consists of the IPv4 address and the IPv6 246 address, into the mapping table. And then the mapper returns the 247 IPv6 destination address and the IPv6 source address to the trans- 248 lator. 250 After that the translator translates the packet to IPv6, fragments 251 it if necessary, and forwards it. Note: The translation from the 252 IPv4 source address to the IPv6 source address is unicast one. 254 Finally it arrives at "receiver6." 256 Figure 2 illustrates the interaction communicating from IPv4 to 257 IPv6. 259 "sender4" "multicast translator" "address "receiver6" 260 mapper" 261 IPv4 translator IPv6 262 multicast multicast 263 proxy proxy 264 | | | | | | 265 | <------| Sends an "IGMP Membership Report" for joining the 266 | | IPv4 multicast group. | | | 267 | | | | | | 268 | |----------------------------------->| | 269 | | Registers a entry for the group into the mapping 270 | | table. | | | | 271 | | | | | | 272 | | | | | | 273 |=========>| Sends an IPv4 multicast packet. | | 274 | | | | | | 275 | |===========>| Hands it. | | | 276 | | | | | | 277 | | | Request IPv6 addresses corresponding 278 | | | to the IPv4 addresses.| | 279 | | |---------------------->| | 280 | | |<----------------------| | 281 | | | Reply with the IPv6 addresses. | 282 | | | | | | 283 | | | <> | 284 | | | | | | 285 | | | Forwards an IPv6 multicast packet. 286 | | |=================================>| 287 | | | | | | 289 Figure. 2 The interaction communicating from IPv4 to IPv6. 291 3.2 Communication from IPv6 to IPv4 293 The following subsection explains communication from one IPv6 mul- 294 ticast sender node, called "sender6", to one or more IPv4 multicast 295 receiver nodes, called "receiver4." 297 Preceding the communication, the administrator of the multicast 298 translator carries out the setup to translate IPv6 multicast pack- 299 ets, which are sent by "sender6" to a special type of IPv6 address 300 proposed in this memo, into IPv4. In the case, the IPv6 multicast 301 proxy joins the IPv6 multicast group as a proxy of "receiver4", and 302 then registers a new entry, which consists of the IPv6 multicast 303 group address and that of IPv4 corresponding to the IPv6 address, 304 into the mapping table. The IPv4 address is the low-order 32-bits 305 of the IPv6 address. 307 Subsequent interaction is symmetric to the case described in Sec- 308 tion 3.1. 310 Figure 3 illustrates the interaction communicating from IPv6 to 311 IPv4. 313 "receiver4" "multicast translator" "address "sender6" 314 mapper" 315 IPv4 translator IPv6 316 multicast multicast 317 proxy proxy 318 | | | | | | 319 | | | Sends an "MLD Multicast Listener | 320 | | | Report" for joining the IPv6 multicast 321 | | | group. | | | 322 | | | |-----> | | 323 | | | | | | 324 | | | |---------->| | 325 | | | Registers a entry for the group into 326 | | | the mapping table. | | 327 | | | | | | 328 | | | | | | 329 | | | Sends an IPv6 multicast packet. | 330 | | | |<=====================| 331 | | | | | | 332 | | |<==========| Hands it. | | 333 | | | | | | 334 | | | Request IPv4 addresses corresponding 335 | | | to the IPv6 addresses.| | 336 | | |---------------------->| | 337 | | |<----------------------| | 338 | | | Reply with the IPv4 addresses. | 339 | | | | | | 340 | | | <> | 341 | | | | | | 342 |<======================| Forwards an IPv4 multicast packet. 343 | | | | | | 345 Figure. 3 The interaction communicating from IPv6 to IPv4. 347 4. Addressing for IPv4/IPv6 multicast communication 349 The mechanism uses a special type of an IPv6 address which is 350 termed an "IPv4-compatible" IPv6 multicast group address. The 351 address is identified by an prefix for IPv6 multicast (ffxy::/96), 352 and holds an IPv4 multicast group address in the low-order 32-bits. 353 Its format is: 355 | 96-bits | 32-bits | 356 +--------------------------------------+---------------+ 357 | ffxy:0:0:0:0:0 | IPv4 multicast| 358 | | group address | 359 +--------------------------------------+---------------+ 361 The flag (x) is set to 0 when an IPv4 multicast address is a perma- 362 nently-assigned ("well-known") multicast address by the global- 363 internet-numbering-authority, otherwise is set to 1. Note: MTP 364 needs to have a list of "well-known" addresses, and the list must 365 be configurable by the MTP administrator. 367 The scope (y) is translated according to the mapping between an 368 IPv4 multicast prefix and an IPv6 scope value described in RFC2365 369 [RFC2365]. 371 5. Protocol Translation Details 373 Protocol Translation Details described in [NAT-PT], including 374 TCP/UDP/ICMP Checksum Update, are associated to MTP. See [NAT-PT]. 376 Also the influence on RTP/RTCP of a translator investigated in Sec- 377 tion 7 of RFC1889[RTP] is associated to MTP. See [RTP]. 379 6. Applicability and Limitations 381 This section considers applicability and limitations. 383 6.1 Applicability 385 The multicast translator based on the mechanism locates at the site 386 boundary between IPv4 and IPv6, and allows them to communicate 387 directly. Therefore, the mechanism can be useful during a long 388 term, until IPv4 nodes disappear after IPv6-only nodes appear. 390 It can be applicable to small-scale network systems, and to the 391 extent of division networks in intranets where its administrator 392 can operate the setup easily on demand by receivers. 394 It cannot be applicable to large-scale network systems like world- 395 wide Internet as it stands because it needs the setup by its admin- 396 istrator. In order to apply it to large-scale network systems, it 397 needs developing a new standard protocol between multicast 398 translators and receivers for carrying out the setup automatically 399 on demand by receivers. 401 In order to apply it to large-scale network systems, it is neces- 402 sary to automate the setup which the administrator carries out 403 according to the requests of the receivers. That is, the receivers 404 directly call on the IPv4 multicast proxy (or the IPv6 multicast 405 proxy) to join in the group which they want to receive. The inter- 406 action can be carried out by some protocols. For example, using 407 http makes it possible to do proper user authentication, and allows 408 to encrypt the interaction data by security mechanism such as SSL. 409 But to define a specific protocol for the interaction is out of 410 scope of this memo. 412 6.2 Limitations 414 (1) Applications 415 In common with [NAT] and [NAT-PT], IP conversion needs to trans- 416 late IP addresses embedded in application layer protocols. So 417 MTP needs ALGs for their translation. 419 (2) Topology 420 The topology is limited to a tree, and there can be one mtp per 421 group. If more than one mtps exist per group, receiver nodes may 422 receive the same packets doubly. 424 Note that mtp is recognized to be one of IPv4 receiver nodes by 425 IPv4 sender nodes, and is recognized to be pseudo IPv6 sender 426 nodes by IPv6 receiver nodes. Also note that mtp is recognized 427 to be one of IPv6 receiver nodes by IPv6 sender nodes, and is 428 recognized to be pseudo IPv4 sender nodes by IPv4 receiver 429 nodes. Since IPv4 multicast domain and IPv6 multicast domain are 430 completely separated, mtp can be applicable to multicast routing 431 protocols regardless of Rendezvous Point (RP), i.e. PIM-SM 432 (using RP) or PIM-DM (not using RP) is applicable. 434 7. Security considerations 436 Header conversions of AH [AH] and ESP [ESP] may be cryptographi- 437 cally impossible in header conversion router approach. It is a big 438 disadvantage. On the other hand it will be possible to use both AH 439 and ESP in proxy gateway approach. 441 8. References 443 [SIIT] Erik Nordmark, "Stateless IP/ICMP Translation Algorithm 444 (SIIT)", RFC 2765, February 2000. 446 [NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation - 447 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 449 [IPV4] J. Postel, "Internet Protocol", RFC 791, September 1981. 451 [NAT] P. Srisuresh and K. Egevang, "Traditional IP Network Address 452 Translator (Traditional NAT)", RFC3022, January 2001 454 [IPV6] S. Deering and R. Hinden, "Internet Protocol, Version 6 455 (IPv6) Specification", RFC 2460, December 1998. 457 [TRANS-MECH] R. Gilligan and E. Nordmark, "Transition Mechanisms 458 for IPv6 Hosts and Routers", RFC 1933, April 1996. 460 [PRIVATE] Y. Rekhter, B. Moskowitz, D. Karrenberg, 461 G. J. de Groot and E. Lear, "Address Allocation for 462 Private Internets", RFC1918, February 1996. 464 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 465 "RTP: A Transport Protocol for Real-Time Applications", 466 RFC1889, January 1996. 468 [AH] Kent, S. and R. Atkinson, "IP Authentication Header", 469 RFC 2402, November 1998. 471 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 472 Protocol (ESP)", RFC 2406, November 1998. 474 [RFC2365] D. Meyer, "Administratively Scoped IP Multicast", 475 RFC 2365, July 1998. 477 9. Acknowledgements 479 The authors would like to thank the WIDE project and Shinsuke 480 Suzuki for many helpful suggestions. 482 10. Authors' Addresses 484 Kazuaki TSUCHIYA 485 Enterprise Server Division, Hitachi, Ltd. 486 1 Horiyamashita, Hatano-shi, Kanagawa-ken, 259-1392 JAPAN 488 Phone: +81-463-87-6771 489 Fax: +81-463-87-7341 490 Email: kazuaki.tsuchiya@itg.hitachi.co.jp 492 Hidemitsu HIGUCHI 493 Enterprise Server Division, Hitachi, Ltd. 494 1 Horiyamashita, Hatano-shi, Kanagawa-ken, 259-1392 JAPAN 496 Phone: +81-463-87-6771 497 Fax: +81-463-87-7341 498 Email: hidemitsu.higuchi@itg.hitachi.co.jp 500 Sunao SAWADA 501 System Development Laboratory, Hitachi, Ltd. 502 1099 Ohzenji, Asao-ku, Kawasaki-shi, Kanagawa-ken, 215-0013 JAPAN 504 Phone: +81-45-860-3085 505 Fax: +81-45 860-1674 506 Email: vsawada@sdl.hitachi.co.jp 508 Shinji NOZAKI 509 Enterprise Server Division, Hitachi, Ltd. 510 1 Horiyamashita, Hatano-shi, Kanagawa-ken, 259-1392 JAPAN 512 Phone: +81-463-87-6771 513 Fax: +81-463-87-7341 514 Email: shinji.nozaki@itg.hitachi.co.jp 516 11. Changes 518 This memo has the following changes. 520 Since draft-ietf-ngtrans-mtp-02.txt: 521 1) Added a note about application to the Source-Specific Multi- 522 cast(PIM-SSM) to "3.1 Communication from IPv4 to IPv6." 524 2) Added the "well-known addresses" list had to be configurable 525 by the MTP administrator to "4 Addressing for IPv4/IPv6 526 multicast communication." 528 3) Added the influence on RTP/RTCP of a translator to "5 Proto- 529 col Translation Details." 531 Since draft-ietf-ngtrans-mtp-01.txt: 532 1) Corrected the flag value, and specified that MTP needs a list 533 of "well-known" addresses, in "4 Addressing for IPv4/IPv6 multi- 534 cast communication." 536 2) Added protocol translation details including TCP/UDP/ICMP 537 Checksum Update, in "5. Protocol Translation Details." 539 3) Specified the necessity for ALG in "6.2 (1) Applications." 541 Since draft-ietf-ngtrans-mtp-00.txt: 542 1) Added description of temporary address mapping scheme from 543 the viewpoint of RPF checks and bi-directional communication to 544 "2.2 Address mapper." 546 2) Added the correspondence of IPv4 and IPv6 about a scope and a 547 flag to "4. Addressing for IPv4/IPv6 multicast communication." 549 3) Added topological issues to "5.2 Limitations." 551 Since draft-tsuchiya-imp-00.txt: 552 1) Updated Applicability and Limitations. Extended applicability 553 to large-scale network systems. 555 2) Added [AH] and [ESP] to References.