MBONED Working Group N. Kumar
Internet Draft S. Venaas
Intended status: Standard Cisco Systems, Inc
Expires: December 2012 June 28, 2012
PIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure
draft-kumar-mboned-64mcast-embedded-address-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 28, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as
the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date
of publication of this document. Please review these
documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD
License text as described in Section 4.e of the Trust Legal
Kumar & Venaas Expires December 28, 2012 [Page 1]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
Provisions and are provided without warranty as described in
the Simplified BSD License.
Abstract
This document discusses the procedure that helps to identify
IPv4 embedded IPv6 Multicast address without any embedded
flags in the address. This document specifies the usage of
additional data or attribute in MLD and PIM that helps
identify this address. This document is not conclusive and is
open for discussion.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. Terminology....................................................4
4. Procedure......................................................4
4.1. 64I Join Attribute........................................5
4.2. 64I Auxiliary Data........................................5
5. Use Cases......................................................6
5.1. IPv4 Receiver and Source connected over IPv6-Only
network........................................................6
5.2. IPv6 Receiver Connected to IPv4 Source through IPv4
multicast access network and IPv6 Multicast network............7
5.3. IPv6 Receiver and IPv4 Source.............................9
6. Security Considerations.......................................10
7. IANA Considerations...........................................10
8. References....................................................10
8.1. Normative References.....................................10
8.2. Informative References...................................10
9. Acknowledgments...............................................11
1. Introduction
As part of IPv4 to IPv6 migration, there are multiple
standards developed for smooth transition for Unicast.
Section 3 of [I-D.ietf-mboned-v4v6-mcast-ps] specifies
Kumar & Venaas Expires December 28, 2012 [Page 2]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
different possible scenarios for IPv4 to IPv6 multicast
transition as below,
1. IPv4 Receiver and Source connected over IPv6-Only
network
2. IPv6 Receiver Connected to IPv4 Source through IPv4
multicast access network and IPv6 Multicast network.
3. IPv6 Receiver and Source connected to IPv4-Only network.
4. IPv6 Receiver and IPv4 Source.
5. IPv4 Receiver and IPv6 Source.
Section 3.6 of [I-D.ietf-mboned-v4v6-mcast-ps] identifies the
use cases involving IPv4 source as highest priority.
There are also various solutions proposed (ex., [I-D.ietf-
softwire-mesh-multicast], [I-D.ietf-softwire-dslite-
multicast]) addressing the above use cases requirement which
requires to embed IPv4 multicast address into IPv6 address.
This IPv4-embedded IPv6 multicast address will be used as
group address within IPv6 cloud.
Currently [I-D.ietf-mboned-64-multicast-address-format]
defines a new bit in IPv6 Multicast address that signals any
router that Ipv4 Multicast address is embedded as last 32
bits. This may create backward compatibility issue.
This document defines a set of procedures, a new PIM join
attribute [RFC 5384] and a new MLD Auxiliary Data that helps
achieve the above without a need for any bit embedded within
IPv6 Multicast address.
2. Conventions used in this document
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 [RFC2119].
In this document, these words will appear with that
interpretation only when in ALL CAPS. Lower case uses of
these words are not to be interpreted as carrying RFC-2119
significance.
Kumar & Venaas Expires December 28, 2012 [Page 3]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
3. Terminology
(S4, G4)/(*, G4): (S, G) or (*, G) in IPv4 address format
(S6, G6)/(*, G6): (S, G) or (*, G) in IPv6 address format
4. Procedure
Any AFBR on receiving (S4, G4) or (*, G4) PIM join or IGMP
Report message and if the S6 after translation is not IPv4
translatable address and if the upstream is IPv6 PIM neighbor
MUST include transitive 64I JOIN ATTRIBUTE (Section 4.1) in
IPv6 PIM Join and embed IPv4 group address in last 32 bits of
IPv6 Multicast SSM range address.
Any AFBR on receiving (S4, G4) or (*, G4) PIM join or IGMP
Report message and if the S6 after translation is IPv4
translatable address and if the upstream is IPv6 PIM neighbor
SHOULD include transitive 64I JOIN ATTRIBUTE in IPv6 PIM Join
and embed IPv4 group address in last 32 bits of IPv6
Multicast SSM range address.
Any AFBR on receiving (S4, G4) or (*, G4) PIM Join or IGMP
Report message and if S6 after translation is not IPv4
translatable address and if upstream is IPv6 cloud without
PIM neighbor MUST include 64I Auxiliary Data (Section 4.2) in
MLDv2 Report Message.
Any AFBR on receiving (S4, G4) or (*, G4) PIM Join or IGMP
Report message and if S6 after translation is IPv4
translatable address and if upstream is IPv6 cloud without
PIM neighbor SHOULD include 64I Auxillary Data in MLDv2
Report Message.
Any AFBR on receiving IPv4 PIM Join with 64I JOIN ATTRIBUTE
MUST carry forward the attribute in IPv6 PIM Join sent
upstream.
Any router on receiving IPv6 PIM Join with 64I JOIN ATTRIBUTE
and if upstream is IPv6 cloud without PIM neighbor MUST
include 64I Auxillary Data in MLDv2 Report message.
Any AFBR on receiving (S6, G6) PIM Join for SSM range address
without 64I JOIN ATTRIBUTE and if the IPv6 Source in Join is
well known prefix (64:FF9B::/96) or IPv4 translatable IPv6
Kumar & Venaas Expires December 28, 2012 [Page 4]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
address [RFC 6052] and if the upstream is IPv4 PIM neighbor,
MUST pull the last 32 bits to generate IPv4 group address.
Any router on receiving (S6, G6) PIM Join from SSM range
without 64I JOIN ATTRIBUTE and if Source address is well
known prefix (64:FF9B::/96) or IPv4 translatable IPv6 address
[RFC 6052] and if the upstream is IPv6 PIM neighbor, MUST
include 64I JOIN ATTRIBUTE.
Any router on receiving MLD Report with 64I Auxiliary Data
MUST include 64I JOIN ATTRIBUTE in IPv6 PIM join sent
Upstream for the group.
While the above procedure is defined with SSM range address
as an example, it is applicable for any (S6, G6) from ASM
range.
4.1. 64I Join Attribute
Below is the format of new PIM JOIN ATTRIBUTE specified in
this document,
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr Type | Length |T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F bit: 1, Transitive Attribute
E bit: As mentioned in [RFC 5384]
Attr Type: TBD
Length: 2
T bit: 1
Reserved: Reserved field for future use.
4.2. 64I Auxiliary Data
Below is the format of new Auxiliary Data specified in this
document,
Kumar & Venaas Expires December 28, 2012 [Page 5]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD
Length:
T Flag: 1
Reserved: Reserved bit for future use.
5. Use Cases
In this document, we also specify the behavior of high
priority scenarios with above procedure.
5.1. IPv4 Receiver and Source connected over IPv6-Only network
This scenario simply known as 4-6-4 is shown below in Figure
1.
+--------+ +--------+
| Host | | IPv4 |
| Rcvr | | DR |
| | | |
+--------+ +--------+
| |
IGMP/IPv4 PIM IGMP/IPv4 PIM
| |
| |
+--------+ +--------+ +--------+
| | MLD | IPv6 | IPv6 | |
| AFBR1 |----------| Only |----------| AFBR2 |
| | IPv6 PIM | Rtr | PIM | |
+--------+ +--------+ +--------+
Figure 1: 4-6-4 Scenario
Kumar & Venaas Expires December 28, 2012 [Page 6]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
AFBR1 on receiving (S4, G4) or (*, G4) PIM Join or IGMP
Report will perform the below,
1. If Upstream is IPv6 PIM neighbor, should embed the IPv4
multicast group into last 32 bits of IPv6 Multicast SSM
range address and send (S6, G6) PIM join with 64I JOIN
ATTRIBUTE.
2. If Upstream is IPv6 MLD router, should embed the IPv4
multicast group into last 32 bits of IPv6 Multicast SSM
range address and send MLDv2 Report with 64I Auxillary
Data.
AFBR2 on receiving (S6, G6) PIM Join without 64I JOIN
ATTRIBUTE and if upstream is IPv4 cloud can derive the IPv4
multicast group address from last 32 bits.
Since F bit will be set in 64I JOIN ATTRIBUTE, it will be
delivered to AFBR2 even if any router along the path doesn't
understand the attribute.
IPv6-only Rtr on receiving (S6, G6) PIM Join with 64I JOIN
ATTRIBUTE will send across to AFBR2 with attribute. Since 64I
JOIN ATTRIBUTE is transitive in nature, this behavior doesn't
change even if IPv6-Only Rtr doesn't understand the
attribute.
IPv6-only Rtr on receiving (S6, G6) MLD Report with 64I
Auxiliary Data will include 64I JOIN ATTRIBUTE in upstream
PIM join for (S6, G6).
AFBR2 on receiving (S6, G6) PIM Join with 64I JOIN ATTRIBUTE
must derive the IPv4 multicast group address from the last 32
bits.
5.2. IPv6 Receiver Connected to IPv4 Source through IPv4
multicast access network and IPv6 Multicast network
Kumar & Venaas Expires December 28, 2012 [Page 7]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
This scenario simply known as 6-4-6-4 is shown in Figure 2.
+--------+
| Host |
| Rcvr |
| |
+--------+
|
MLD/IPv6 PIM
|
|
+--------+ +--------+ +--------+
| | IGMP | IPv4 | IPv4 | |
| AFBR1 |----------| Only |----------| AFBR2 |
| | IPv4 PIM | NW | PIM | |
+--------+ +--------+ +--------+
|
MLD/IPv6 PIM
|
|
+--------+ +--------+ +--------+
| IPv4 | IGMP | | IPv6 | IPv6 |
| DR |----------| AFBR3 |----------| Only |
| | IPv4 PIM | | PIM | NW |
+--------+ +--------+ +--------+
Figure 2: 6-4-6-4 Scenario
In Figure 2, AFBR3 will act as IP/ICMP translator and will
advertise IPv4 prefixes into IPv6 cloud as either well known
prefix (64:FF9B::/96) or IPv4 translatable IPv6 prefix.
In this scenario, AFBR1 or the DR router MUST include 64I
JOIN ATTRIBUTE or 64I Auxiliary Data if the source is well
known prefix (64:FF9B::/96). AFBR1 or the DR router SHOULD
include 64I JOIN ATTRIBUTE or 64I Auxiliary Data if the
source is with IPv4 translatable IPv6 prefix. How AFBR1/DR
will understand if S6 belongs to IPv4 translatable IPv6
prefix is outside the scope of this document.
Various solutions are available by which AFBR1 will send the
join towards AFBR2. This basically depends if multicast is
enabled or disabled on IPv4 cloud. Depending on the solution,
Kumar & Venaas Expires December 28, 2012 [Page 8]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
AFBR1 will either send IPv6 PIM Join encapsulated within IPv4
PIM join or IPv6 PIM Join over some tunnel.
AFBR2 on receiving (S6, G6) PIM Join over tunnel or (S6, G6)
PIM Join encapsulated within (S4, G4) will send 64I JOIN
ATTRIBUTE or 64I Auxiliary Data upstreams towards AFBR3.
AFBR3 on receiving (S6, G6) Join with 64I JOIN ATTRIBUTE MUST
derive the IPv4 group address from last 32 bits.
AFBR3 on receiving (S6, G6) PIM join without 64I JOIN
ATTRIBUTE MUST check if S6 falls within well known prefix
(64:FF9B::/96) or IPv4 translatable IPv6 Prefix. If S6 is
within the above range, it MUST derive IPv4 group from the
last 32 bits of G6.
5.3. IPv6 Receiver and IPv4 Source
+--------+
| Host |
| Rcvr |
| |
+--------+
|
MLD/IPv6 PIM
|
|
+--------+ +--------+ +--------+
| | IPv6 | IPv6 | IPv6 | |
| DR1 |----------| Only |----------| AFBR1 |
| | PIM | NW | PIM | |
+--------+ +--------+ +--------+
|
IGMP/IPv4 PIM
|
|
+--------+
| |
| DR2 |
| |
+--------+
Figure 3: 6-4 Scenario
Kumar & Venaas Expires December 28, 2012 [Page 9]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
This scenario works similar to Section 5.2 except that IPv6
cloud is not partitioned by IPv4 cloud.
6. Security Considerations
Security consideration specified in [RFC 5384] and [RFC 6052]
are applicable here as well.
7. IANA Considerations
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC 5234] Crocker, D. and Overell, P.(Editors), "Augmented
BNF for Syntax Specifications: ABNF", RFC 5234,
January 2008.
8.2. Informative References
[I-D.ietf-mboned-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J.,
Tsou, T., and Q. Sun, "IPv4-IPv6 Multicast: Problem
Statement and Use Cases", draft-ietf-mboned-v4v6-
mcast-ps-00 (work in progress), May 2012.
[I-D.ietf-mboned-64-multicast-address-format]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li,
X. and Xu, M, "IPv4-Embedded IPv6 Multicast
Address Format", draft-ietf-mboned-64-multicast-
address-format-02 (work in progress), February
Kumar & Venaas Expires December 28, 2012 [Page 10]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
2012.
[I-D.ietf-softwire-dslite-multicast]
Qin, J., Boucadair, M., Jacquenet, C., Lee, Y.,
and Q. Wang, "Multicast Extension to DS-Lite
Technique in Broadband Deployments",
Draft-ietf-softwire-dslite-multicast-02 (work in
progress), May 2012.
[I-D.ietf-softwire-mesh-multicast]
Xu, M., Cui, Y., Yang, S., Wu, J., Metz, C., and
G. Shepherd, "Softwire Mesh Multicast",
Draft-ietf-softwire-mesh-multicast-02 (work in
progress), April 2012.
[RFC 5384] Boers, A., Wijnands, I. and Rosen, E., "The
Protocol Independent Multicast (PIM) Join
Attribute Format", RFC 5384, Nov 2008.
[RFC 4291] Hinden, R. and S. Deering, "IP Version 6
Addressing Architecture", RFC 4291, February 2006.
[RFC 4607] Holbrook, H. and B. Cain "Source-Specific
Multicast for IP", RFC 4607, August 2006.
[RFC 6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M.,
and X. Li, "IPv6 Addressing of IPv4/IPv6
Translators", RFC 6052, October 2010.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
USA
Email: stig@cisco.com
Kumar & Venaas Expires December 28, 2012 [Page 11]
Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation
Procedure June 2012
Nagendra Kumar
Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Email: naikumar@cisco.com
Kumar & Venaas Expires December 28, 2012 [Page 12]