draft-ietf-mboned-64-multicast-address-format-05.txt   draft-ietf-mboned-64-multicast-address-format-06.txt 
MBONED Working Group M. Boucadair, Ed. Network Working Group M. Boucadair, Ed.
Internet-Draft France Telecom Internet-Draft France Telecom
Intended status: Standards Track J. Qin Updates: 7371 (if approved) J. Qin
Expires: October 20, 2013 Cisco Intended status: Standards Track Cisco
Y. Lee Expires: March 28, 2015 Y. Lee
Comcast Comcast
S. Venaas S. Venaas
Cisco Systems Cisco Systems
X. Li X. Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
M. Xu M. Xu
Tsinghua University Tsinghua University
April 18, 2013 September 24, 2014
IPv6 Multicast Address With Embedded IPv4 Multicast Address IPv6 Multicast Address With Embedded IPv4 Multicast Address
draft-ietf-mboned-64-multicast-address-format-05 draft-ietf-mboned-64-multicast-address-format-06
Abstract Abstract
This document reserves one bit (M-bit) of the unicast prefix-based This document reserves one bit (M-bit) of the unicast prefix-based
multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM
mode to be used in the context of IPv4-IPv6 interconnection. mode to be used in the context of IPv4-IPv6 interconnection.
The document specifies an algorithmic translation of an IPv6 The document specifies an algorithmic translation of an IPv6
multicast address to a corresponding IPv4 multicast address, and vice multicast address to a corresponding IPv4 multicast address, and vice
versa. This algorithmic translation can be used in both IPv4-IPv6 versa. This algorithmic translation can be used in both IPv4-IPv6
translation or encapsulation schemes. translation or encapsulation schemes.
This document updates RFC 7371.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 20, 2013. This Internet-Draft will expire on March 28, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 11 skipping to change at page 3, line 11
A.3. Location of the IPv4 Address . . . . . . . . . . . . . . 10 A.3. Location of the IPv4 Address . . . . . . . . . . . . . . 10
Appendix B. Design Considerations . . . . . . . . . . . . . . . 10 Appendix B. Design Considerations . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Various solutions (e.g., [I-D.ietf-softwire-mesh-multicast], Various solutions (e.g., [I-D.ietf-softwire-mesh-multicast],
[I-D.ietf-softwire-dslite-multicast]) have been proposed to allow [I-D.ietf-softwire-dslite-multicast]) have been proposed to allow
access to IPv4 multicast content from hosts attached to IPv6-enabled access to IPv4 multicast content from hosts attached to IPv6-enabled
domains. Even if these solutions have distinct applicability scopes domains. Even if these solutions have distinct applicability scopes
(translation vs. encapsulation) and target different use cases, they (translation vs. encapsulation) and target different use cases, they
all make use of specific IPv6 multicast addresses to embed an IPv4 all make use of specific IPv6 multicast addresses to embed an IPv4
multicast address. Particularly, the IPv4-Embedded IPv6 Multicast multicast address. Particularly, the IPv4-Embedded IPv6 Multicast
Address is used as a destination IPv6 address of multicast flows Address is used as a destination IPv6 address of multicast flows
received from an IPv4-enabled domain and injected by the IPv4-IPv6 received from an IPv4-enabled domain and injected by the IPv4-IPv6
Interconnection Function into an IPv6-enabled domain. It is also Interconnection Function into an IPv6-enabled domain. It is also
used to build an IPv6 multicast state (*, G6) or (S6, G6) used to build an IPv6 multicast state (*, G6) or (S6, G6)
corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the
IPv4-IPv6 Interconnection Function. [I-D.ietf-mboned-v4v6-mcast-ps] IPv4-IPv6 Interconnection Function. [I-D.ietf-mboned-v4v6-mcast-ps]
provides more discussion about issues related to IPv4/IPv6 multicast. provides more discussion about issues related to IPv4/IPv6 multicast.
This document reserves one bit of the unicast prefix-based multicast This document reserves one bit of the unicast prefix-based multicast
IPv6 address ([I-D.ietf-6man-multicast-addr-arch-update]) for Any- IPv6 address ([RFC7371]) for Any-Source Multicast (ASM) mode and an
Source Multicast (ASM) mode and an IPv6 multicast prefix for Source- IPv6 multicast prefix for Source-Specific Multicast (SSM) mode to be
Specific Multicast (SSM) mode to be used in the context of IPv4-IPv6 used in the context of IPv4-IPv6 interconnection. This document also
interconnection. This document also defines how IPv4-Embedded IPv6 defines how IPv4-Embedded IPv6 Multicast Addresses are constructed.
Multicast Addresses are constructed. Both IPv4-IPv6 translation and Both IPv4-IPv6 translation and encapsulation schemes can make use of
encapsulation schemes can make use of this specification. this specification.
This specification can be used in conjunction with other extensions This specification can be used in conjunction with other extensions
such as embedding the rendezvous point [RFC3956]. Unicast prefix- such as embedding the rendezvous point [RFC3956]. Unicast prefix-
based and embedded-RP techniques are important tools to simplify IPv6 based and embedded-RP techniques are important tools to simplify IPv6
multicast deployments. Indeed, unicast prefix-based IPv6 addressing multicast deployments. Indeed, unicast prefix-based IPv6 addressing
is used in many current IPv6 multicast deployments, and has also been is used in many current IPv6 multicast deployments, and has also been
defined for IPv4, and is seen as a very useful technique. Also defined for IPv4, and is seen as a very useful technique. Also
embedded-RP is used in existing deployments. embedded-RP is used in existing deployments.
This document is a companion document to [RFC6052] which focuses This document is a companion document to [RFC6052] which focuses
skipping to change at page 4, line 30 skipping to change at page 4, line 26
IPv6-enabled one. It can be located in various places of the IPv6-enabled one. It can be located in various places of the
multicast network. Particularly, in terms of multicast control multicast network. Particularly, in terms of multicast control
messages, it can be an IGMP/MLD Interworking Function or an messages, it can be an IGMP/MLD Interworking Function or an
IPv4-IPv6 PIM Interworking Function. An IPv4-IPv6 Interconnection IPv4-IPv6 PIM Interworking Function. An IPv4-IPv6 Interconnection
Function is configured with one or two MPREFIX64s. Function is configured with one or two MPREFIX64s.
3. IPv4-Embedded IPv6 Multicast Prefix & Address 3. IPv4-Embedded IPv6 Multicast Prefix & Address
3.1. ASM Mode 3.1. ASM Mode
The format specified in Figure 1 uses some bits defined in The format specified in Figure 1 uses some bits defined in [RFC7371]:
[I-D.ietf-6man-multicast-addr-arch-update]: M-bit (20th bit position) M-bit (20th bit position, where bit 1 is the most significant bit)
now has a meaning. now has a meaning.
Details on design considerations are discussed in Appendix B. Details on design considerations are discussed in Appendix B.
| 8 | 4 | 4 | 3 |1| 76 | 32 | | 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+-+------------------------------+----------+ +--------+----+----+----+------------------------------+----------+
|11111111|flgs|scop|flgs|M| sub-group-id |v4 address| |11111111|ff1 |scop|ff2 | sub-group-id |v4 address|
+--------+----+----+----+-+-----------------------------------------+ +--------+----+----+----+-----------------------------------------+
+-+-+-+-+
ff2 (flag field 2) is a set of 4 flags: |r|r|r|M|
+-+-+-+-+
"r" bits MUST each be set to 0.
Figure 1: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode Figure 1: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode
The description of the fields is as follows: The description of the fields is as follows:
o "flgs" fields are defined in o ff1 field is defined in [RFC7371].
[I-D.ietf-6man-multicast-addr-arch-update].
o "scop" field is defined in [RFC3956]. o "scop" field is defined in [RFC3956].
o M (20th bit position): When this bit is set to 1, it indicates o M (20th bit position): When this bit is set to 1, it indicates
that a multicast IPv4 address is embedded in the low-order 32 bits that a multicast IPv4 address is embedded in the low-order 32 bits
of the multicast IPv6 address. of the multicast IPv6 address.
o sub-group-id: This field is configurable according to local o sub-group-id: This field is configurable according to local
policies (e.g., enable embedded-RP) of the entity managing the policies (e.g., enable embedded-RP) of the entity managing the
IPv4-IPv6 Interconnection Function. This field MUST follow the IPv4-IPv6 Interconnection Function. This field MUST follow the
recommendations specified in [RFC3306] if unicast-based prefix is recommendations specified in [RFC3306] if unicast-based prefix is
used or the recommendations specified in [RFC3956] if embedded-RP used or the recommendations specified in [RFC3956] if embedded-RP
skipping to change at page 6, line 5 skipping to change at page 6, line 5
ASM_PREFIX64 is configured. The enclosed IPv4 multicast address ASM_PREFIX64 is configured. The enclosed IPv4 multicast address
SHOULD be in 232/8 range if an SSM_PREFIX64 is configured. SHOULD be in 232/8 range if an SSM_PREFIX64 is configured.
Embedding an IPv4 multicast address in the last 32 bits does not Embedding an IPv4 multicast address in the last 32 bits does not
conflict with the Group IDs assigned by IANA (i.e., 0x00000001 to conflict with the Group IDs assigned by IANA (i.e., 0x00000001 to
0x3FFFFFFF [RFC3307]). 0x3FFFFFFF [RFC3307]).
When several MPREFIX64 are available, it is RECOMMENDED to use the When several MPREFIX64 are available, it is RECOMMENDED to use the
MPREFIX64 which preserve the scope of the IPv4 multicast address. MPREFIX64 which preserve the scope of the IPv4 multicast address.
| 96 | 32 | | 96 | 32 |
+------------------------------------------------------+----------+ +------------------------------------------------------+----------+
| MPREFIX64 |v4 address| | MPREFIX64 |v4 address|
+------------------------------------------------------+----------+ +------------------------------------------------------+----------+
Figure 2: IPv4-Embedded IPv6 Multicast Address Format Figure 2: IPv4-Embedded IPv6 Multicast Address Format
3.4. Address Translation Algorithm 3.4. Address Translation Algorithm
IPv4-Embedded IPv6 Multicast Addresses are composed according to the IPv4-Embedded IPv6 Multicast Addresses are composed according to the
following algorithm: following algorithm:
o Concatenate the MPREFIX64 and the 32 bits of the IPv4 address to o Concatenate the MPREFIX64 and the 32 bits of the IPv4 address to
obtain a 128-bit address. obtain a 128-bit address.
skipping to change at page 7, line 42 skipping to change at page 7, line 49
7. Acknowledgements 7. Acknowledgements
Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou, C. Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou, C.
Bormann, T. Chown, P. Koch, B. Haberman, and B. Hinden for their Bormann, T. Chown, P. Koch, B. Haberman, and B. Hinden for their
comments and review. comments and review.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-6man-multicast-addr-arch-update]
Boucadair, M. and S. Venaas, "Updates to the IPv6
Multicast Addressing Architecture", draft-ietf-6man-
multicast-addr-arch-update-00 (work in progress), April
2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002. Multicast Addresses", RFC 3306, August 2002.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002. Addresses", RFC 3307, August 2002.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", RFC Point (RP) Address in an IPv6 Multicast Address", RFC
3956, November 2004. 3956, November 2004.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
8.2. Informative References [RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6
Multicast Addressing Architecture", RFC 7371, September
2014.
[I-D.ietf-behave-nat64-learn-analysis] 8.2. Informative References
Korhonen, J. and T. Savolainen, "Analysis of solution
proposals for hosts to learn NAT64 prefix", draft-ietf-
behave-nat64-learn-analysis-03 (work in progress), March
2012.
[I-D.ietf-mboned-v4v6-mcast-ps] [I-D.ietf-mboned-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T.,
and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and and Q. Qiong, "IPv4-IPv6 Multicast: Problem Statement and
Use Cases", draft-ietf-mboned-v4v6-mcast-ps-02 (work in Use Cases", draft-ietf-mboned-v4v6-mcast-ps-04 (work in
progress), March 2013. progress), September 2013.
[I-D.ietf-softwire-dslite-multicast] [I-D.ietf-softwire-dslite-multicast]
Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q.
Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients
over an IPv6 Multicast Network", draft-ietf-softwire- over an IPv6 Multicast Network", draft-ietf-softwire-
dslite-multicast-05 (work in progress), April 2013. dslite-multicast-08 (work in progress), September 2014.
[I-D.ietf-softwire-mesh-multicast] [I-D.ietf-softwire-mesh-multicast]
Xu, M., Cui, Y., Wu, J., Yang, S., Metz, C., and G. Xu, M., Cui, Y., Wu, J., Yang, S., Metz, C., and G.
Shepherd, "Softwire Mesh Multicast", draft-ietf-softwire- Shepherd, "Softwire Mesh Multicast", draft-ietf-softwire-
mesh-multicast-04 (work in progress), January 2013. mesh-multicast-07 (work in progress), July 2014.
[I-D.ietf-softwire-multicast-prefix-option] [I-D.ietf-softwire-multicast-prefix-option]
Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6 Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", draft-ietf-softwire-multicast-prefix-option-04 Prefixes", draft-ietf-softwire-multicast-prefix-option-07
(work in progress), April 2013. (work in progress), September 2014.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and
M. Eubanks, "Multicast Addresses for Documentation", RFC M. Eubanks, "Multicast Addresses for Documentation", RFC
6676, August 2012. 6676, August 2012.
[RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution
Proposals for Hosts to Learn NAT64 Prefix", RFC 7051,
November 2013.
Appendix A. Motivations Appendix A. Motivations
A.1. Why an Address Format is Needed for Multicast IPv4-IPv6 A.1. Why an Address Format is Needed for Multicast IPv4-IPv6
Interconnection? Interconnection?
Arguments why an IPv6 address format is needed to embed multicast Arguments why an IPv6 address format is needed to embed multicast
IPv4 address are quite similar to those of [RFC6052]. Concretely, IPv4 address are quite similar to those of [RFC6052]. Concretely,
the definition of a multicast address format embedding a multicast the definition of a multicast address format embedding a multicast
IPv4 address allows: IPv4 address allows:
skipping to change at page 10, line 22 skipping to change at page 10, line 26
interconnection function. interconnection function.
2. In order to avoid involving an ALG in the path, an IPv4-only 2. In order to avoid involving an ALG in the path, an IPv4-only
source can advertise both its IPv4 address and IPv4-Embedded IPv6 source can advertise both its IPv4 address and IPv4-Embedded IPv6
Multicast Address. If a dedicated prefix is not reserved, a Multicast Address. If a dedicated prefix is not reserved, a
dual-stack receiver may prefer to use the IPv6 address to receive dual-stack receiver may prefer to use the IPv6 address to receive
the multicast content. This address selection would require the multicast content. This address selection would require
multicast flows to cross an IPv4-IPv6 interconnection function. multicast flows to cross an IPv4-IPv6 interconnection function.
Reserving dedicated IPv6 multicast prefixes for IPv4-IPv6 Reserving dedicated IPv6 multicast prefixes for IPv4-IPv6
interconnection purposes mitigates the issues discussed in interconnection purposes mitigates the issues discussed in [RFC7051]
[I-D.ietf-behave-nat64-learn-analysis] in a multicast context. in a multicast context.
A.3. Location of the IPv4 Address A.3. Location of the IPv4 Address
There is no strong argument to allow for flexible options to encode There is no strong argument to allow for flexible options to encode
the IPv4 address inside the multicast IPv6 address. The option the IPv4 address inside the multicast IPv6 address. The option
retained by the authors is to encode the multicast IPv4 address in retained by the authors is to encode the multicast IPv4 address in
the low-order 32 bits of the IPv6 address. the low-order 32 bits of the IPv6 address.
This choice is also motivated by the need to be compliant with This choice is also motivated by the need to be compliant with
[RFC3306] and [RFC3956]. [RFC3306] and [RFC3956].
Appendix B. Design Considerations Appendix B. Design Considerations
The following constraints should be met when reserving dedicated The following constraints should be met when reserving dedicated
prefix(es) to be used for IPv4/IPv6 multicast interconnection: prefix(es) to be used for IPv4/IPv6 multicast interconnection:
1: Belong to SSM prefix range (preferably ff3x::/32) and be 1: Belong to SSM prefix range (preferably ff3x::/32) and be
compatible with unicast-based prefix [RFC3306] for SSM. Note that compatible with unicast-based prefix [RFC3306] for SSM. Note
[RFC3306] suggests to set "plen" to 0 and "network-prefix" to 0. that [RFC3306] suggests to set "plen" to 0 and "network-prefix"
As such, any prefix in the 33-96 range can be convenient. Given to 0. As such, any prefix in the 33-96 range can be convenient.
[RFC4607] indicates future specifications may allow a non-zero Given [RFC4607] indicates future specifications may allow a non-
network prefix field, a /33 would allow for future extensions but zero network prefix field, a /33 would allow for future
it has the drawback of reserving a large block. A /96 would be extensions but it has the drawback of reserving a large block. A
adequate for the use cases already identified in /96 would be adequate for the use cases already identified in
[I-D.ietf-mboned-v4v6-mcast-ps]. In the event of any concrete
extension, reserving additional prefixes may be considered. [I-D.ietf-mboned-v4v6-mcast-ps]. In the event of any concrete
extension, reserving additional prefixes may be considered.
2: Be compatible with embedded-RP [RFC3956] and unicast-based prefix 2: Be compatible with embedded-RP [RFC3956] and unicast-based prefix
[RFC3306] for ASM. This results in associating a meaning with one [RFC3306] for ASM. This results in associating a meaning with
of the reserved bits in one of the reserved bits in [RFC7371]. Defining the 17-20 bits
[I-D.ietf-6man-multicast-addr-arch-update]. Defining the 17-20 range to have a meaning and be used for IPv4/IPv6 transition has
bits range to have a meaning and be used for IPv4/IPv6 transition the advantage of allowing for future extensions but it may be
has the advantage of allowing for future extensions but it may be seen as a waste of the multicast address space. Consequently,
seen as a waste of the multicast address space. Consequently, using one of the reserved bits (in the range 17-20) from the
using one of the reserved bits (in the range 17-20) from the unicast-based IPv6 multicast address format [RFC3306] is
unicast-based IPv6 multicast address format [RFC3306] is preferred.
preferred.
Meeting (1) and (2) with the same reserved bit is not feasible Meeting (1) and (2) with the same reserved bit is not feasible
without modifying embedded-RP and unicast-based prefix without modifying embedded-RP and unicast-based prefix
specifications; this option is avoided. specifications; this option is avoided.
As a consequence, this document proposes to reserve a multicast As a consequence, this document proposes to reserve a multicast
prefix for SSM and define one bit of the unicast prefix-based prefix for SSM and define one bit of the unicast prefix-based
multicast IPv6 address for ASM when embedding IPv4 multicast address multicast IPv6 address for ASM when embedding IPv4 multicast address
in an IPv6 multicast address. in an IPv6 multicast address.
 End of changes. 24 change blocks. 
66 lines changed or deleted 68 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/