IPv4-Embedded IPv6 Multicast
Address FormatFrance TelecomRennes35000Francemohamed.boucadair@orange.comZTEShanghaiChinajacniq@gmail.comComcastU.S.Ayiu_lee@cable.comcast.comCisco SystemsTasman DriveSan JoseCA95134USAstig@cisco.comCERNET Center/Tsinghua UniversityRoom 225, Main Building, Tsinghua UniversityBeijing100084P.R. China+86 10-62785983xing@cernet.edu.cnTsinghua UniversityDepartment of Computer Science, Tsinghua UniversityBeijing100084P.R.China+86-10-6278-5822xmw@cernet.edu.cnMBONED Working GroupIPv4-IPv6 Interconnection, Multicast64, IPv4-Embedded IPv6
Address, IPv4 Address ShortageThis document specifies an extension to the IPv6 multicast addressing
architecture to be used in the context of IPv4-IPv6 interconnection. In
particular, this document defines an address format for IPv4-embedded
IPv6 multicast addresses. This address format can be used for IPv4-IPv6
translation or encapsulation schemes.This document updates RFC4291.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.This document specifies an extension to the IPv6 multicast addressing
architecture to be used in the context of IPv4-IPv6 interconnection. In
particular, this document defines an address format for IPv4-embedded
IPv6 multicast addresses. This address format can be used for IPv4-IPv6
translation or encapsulation schemes.This document updates .This specification can be used in conjunction with other extensions
such as building unicast prefix-based multicast IPv6 address or embedding the rendezvous point .This document is a companion document to which focuses exclusively on IPv4-embedded IPv6
unicast addresses.Details about design choices are documented in .This document makes use of the following terms:IPv4-embedded IPv6 multicast address: denotes a multicast IPv6
address which includes in 32 bits an IPv4 address. Two types of IPv6
addresses are defined that carry an IPv4 address in the low-order 32
bits of the address. The format to build such addresses is defined
in for ASM mode and for SSM mode.Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6
multicast prefix to be used to construct IPv4-embedded IPv6
multicast addresses.ASM_MPREFIX64: denotes a multicast Prefix64 used in ASM mode. It
follows the format described in .SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM mode. It
follows the format described in .To meet the requirements listed in , the
following address format is defined to enclose an IPv4 multicast address
when ASM mode is used:The description of the fields is as follows:"flgs" and "scop" fields are defined in .64IX field (IPv4-IPv6 interconnection bits): The first bit is the
M-bit. When "M-bit" is set to 1, it indicates that a multicast IPv4
address is embedded in the low-order 32 bits of the multicast IPv6
address. All the remaining bits are reserved and MUST be set to
0.sub-group-id: This field is configurable according to local
policies of the entity managing the IPv4-IPv6 Interconnection
Function. This field must follow the recommendations specified in
if unicast-based prefix is used or
the recommendations specified in if
embedded-RP is used. The default value is all zeros.The low-order 32 bits MUST include an IPv4 multicast address when
the M-bit is set to 1. The enclosed IPv4 multicast address SHOULD
NOT be in 232/8 range.As mentioned above, any IPv4-embedded IPv6 address used in SSM mode
MUST be part of ff3x::/32 . describes the format of the IPv6
multicast address to be used to enclose an IPv4 multicast address.The description of the fields is as follows:Flags must be set to 0011."scop" is defined in .64IX field (IPv4-IPv6 interconnection bits): Same meaning as
.sub-group-id: The default value is all zeros.The low-order 32 bits MUST include an IPv4 multicast address when
the M-bit is set to 1. The embedded IPv4 address SHOULD be in the
232/8 range . 232.0.0.1-232.0.0.255
range is being reserved to IANA.The embedded IPv4 address in an IPv6 multicast address is included in
the last 32 bits; therefore dotted decimal notation can be used.For the delivery of the IPv4-IPv6 multicast interconnection services,
a dedicated multicast prefix denoted as MPREFIX64 should be provisioned
to any function requiring to build an IPv4-embedded IPv6 multicast
address based on an IPv4 multicast address. MPREFIX64 can be of ASM or
SSM type. When both modes are used, two prefixes are required to be
provisioned.The structure of the MPREFIX64 follows the guidelines specified in
for the ASM mode and when SSM mode is used.The RECOMMENDED MPREFIX64 length is /96 (as shown in ).The format of the MPREFIX64 should follow what is specified in and if
corresponding mechanisms are used. The format specified in uses
some reserved bits defined in and
: the first of the reserved bits now
has a meaning, while the remaining bits MUST be set to 0.An IPv4 source is represented in the IPv6 realm with its
IPv4-converted IPv6 address . provides an example of ASM
IPv4-Embedded IPv6 Address while provides
an example of SSM IPv4-Embedded IPv6 Address.Authors of this document request to reserve:ff3x:0:8000/33 SSM block to embed an IPv4 multicast address in
the last 32 bits.ffxx:8000/17 ASM block to embed an IPv4 multicast address in the
last 32 bits.This document defined an address format to embed an IPv4 multicast
address in an IPv6 multicast address. The same security considerations
as those discussed in are to be taken
into consideration.Many thanks to R. Bonica, B. Sarikaya, P. Savola and T. Tsou for
their comments and review.There is no strong argument to allow for flexible options to encode
the IPv4 address inside the multicast IPv6 address. The option
retained by the authors is to encode the multicast IPv4 address in the
low-order 32 bits of the IPv6 address.This choice is also motivated by the need to be compliant with
and . is a reminder of the IPv6 multicast
address format as defined in :It was tempting to use the remaining flag to indicate whether an
IPv6 address embeds an IPv4 address or not. This choice has been
abandoned by the authors for various reasons: ff3x::/32 is defined as SSM. Defining a new flag would require
standards and implementations to also treat ffbx::/32 as SSM.Prefixes starting with ff7x are defined as embedded-RP, but not
prefixes starting with fffx. Below is provided an excerpt from
: " ...the encoding and the protocol mode used when the two
high-order bits in "flgs" are set to 11 ("fff0::/12") is
intentionally unspecified until such time that the
highest-order bit is defined. Without further IETF
specification, implementations SHOULD NOT treat the fff0::/12
range as Embedded-RP."as such defining a new flag would require implementations
to also treat ff7x::/12 as embedded-RP prefix.This is the last remaining flag and at this stage we are not
sure whether there is other usage scenarios of the flag.As a conclusion, the remaining flag is not used to indicate an IPv6
multicast address embeds an IPv4 multicast address. However the
following constraints should be met:(1) Belong to ff3x::/32 and be compatible with unicast-based
prefix for SSM. Note that suggests to set "plen" to 0 and
"network-prefix" to 0.(2) Be compatible with embedded-RP and unicast-based prefix for ASM;(3) Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for
IANA.Meeting (1) and (2) with the same location of the M-bit is
not feasible without modifying embedded-RP and unicast-based prefix
specifications; this option is avoided.As a consequence, two multicast blocks are proposed to be used when
embedding IPv4 address: one block for ASM ( ) and another one for the SSM ().IPv4-IPv6 encapsulator and translator may be embedded in the same
device or even implemented with the same software module. In order to
help the function whether an encapsulated IPv6 multicast packets or
translated IPv6 ones are to be transferred. It was tempting to define
an S-bit for that purpose but this choice has been abandoned in favor
of the recommendation to use distinct MPREFIX64 for each scheme.As such, there is no need to reserve a bit in the IPv6 multicast
address to separate between the translation and the encapsulation
schemes.