Internet DRAFT - draft-taylor-multrans-af2-specification
draft-taylor-multrans-af2-specification
Internet Engineering Task Force T. Taylor
Internet-Draft C. Zhou
Intended status: Informational Huawei Technologies
Expires: June 23, 2012 December 21, 2011
Specification of an Adaptation Function Between Two Multicast Networks
Supporting Different IP Versions
draft-taylor-multrans-af2-specification-00
Abstract
In some transitional multicast scenarios, the multicast signalling
and content have to pass across network boundaries where one network
supports IPv4, the other, IPv6. An adaptation function is required
at the boundary to support such a scenario. This memo uses the term
"Type 2 Adaptation Function" (AF2) for such a function.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 23, 2012.
Copyright Notice
Copyright (c) 2011 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 Provisions and are provided without warranty as
Taylor & Zhou Expires June 23, 2012 [Page 1]
Internet-Draft Multicast AF2 Specification December 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Signalling Operation . . . . . . . . . . . . . . . . . . . . . 3
3. Handling of Multicast Data Packets . . . . . . . . . . . . . . 3
4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. Informative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Taylor & Zhou Expires June 23, 2012 [Page 2]
Internet-Draft Multicast AF2 Specification December 2011
1. Introduction
Consider a multicast scenarion where the multicast source is served
by a different network from the multicast receiver, so that two or
more networks separate them. Now suppose that at some point along
the path between, one network supports IPv4 while the other supports
IPv6. Obviously, one network or the other needs to have a dual stack
border router to make this work. This router needs to support
additional functionality to provide continuity for PIM [RFC4601]
operation across the boundary and to forward the packets of multicast
content with appropriate source and destination addresses. This memo
uses the term "Type 2 Adaptation Function" (AF2) for such
functionality.
1.1. Requirements Language
This document contains no requirements language.
2. Signalling Operation
Processing of PIM messages across the AF2 is fairly straightforward.
The AF2 examines each PIM message crossing the IP version boundary
for contained addresses. Each address is remapped to a corresponding
address in the IP version that is supported by the network it is
entering. For the cases of immediate interest, it is likely that a
stateless mapping can be used, for example,
[I-D_boucadair-stateless-multicast] for the multicast group addresses
and [RFC6052] for source addresses. Once the addresses are remapped
and the messages reencoded, the messages are forwarded into the
receiving network.
Note that the PIM Hello message, which optionally contains a
secondary address list ([RFC4601] section 4.3.4), does not
technically cross the IP version boundary and therefore needs no
remapping, since it is a single-hop message between interfaces
sharing the same link.
3. Handling of Multicast Data Packets
The AF2 either encapsulates or translates the headers of incoming
multicast data packets before forwarding them across the IP version
boundary. In either case, the source and group addresses are
remapped to the other IP version. In the encapsulation case the
remapped addresses are used as the source and destination addresses
in the outer IP header. In the translation case they are used as the
source and destination addresses in the translated header. The
Taylor & Zhou Expires June 23, 2012 [Page 3]
Internet-Draft Multicast AF2 Specification December 2011
mapping used is the inverse of the one used to modify the PIM
messages forwarded in the opposite direction.
That is, if a given address A in an incoming PIM message was
mapped to A' in it outgoing counterpart, then the address A'
appearing in the header of an incoming multicast data packet is
mapped to A. This ensures that incoming data packets follow the
multicast tree that PIM has set up for them in the downstream
network.
The choice of encapsulation versus translation is a complex topic.
Some relevant discussion appears in a companion draft,
[I-D_tsou-AF1-specification]. The key issues are that encapsulation
requires administrative coordination to ensure that the necessary
decapsulation function is available downstream, and that the
evolution to pure IPv6 is awkward. It seems best to make header
translation the default, with encapsulation a configurable option.
4. Open Issues
The description given above is sufficent if only two networks
separate the source from the receiver. However, if transit networks
are involved, avoidance of routing loops becomes a concern. If a
transit network (possibly also with directly attached receivers)
receives a PIM request, the underlying routing tables that each
multicast router uses to achieve reverse path forwarding have to be
consistent with the ultimate source. The question of how to ensure
that becomes a concern.
Fundamentally, the addresses used to designate a given multicast flow
in a given network have to provide the information needed to route
the PIM Join requests to the right AF2 instance and provide the right
remapping across the AF2. This information can be obtained through
administrative coordination, or can somehow be contained in the
addresses themselves. One case where the latter holds is if the
source is IPv4 and every intervening IPv6 network uses an IPv4-
embedded mapping such as the one defined by
[I-D_boucadair-stateless-multicast]. Intervening IPv4 networks would
use the native source network addresses. It does not matter if each
IPv6 network remaps to use its own IPv6 prefix, since the source
network addresses are always preserved intact.
5. Acknowledgements
TBD.
Taylor & Zhou Expires June 23, 2012 [Page 4]
Internet-Draft Multicast AF2 Specification December 2011
6. Contributors
Tina Tsou provided the framework within which these ideas were
developed.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
To come.
9. Informative References
[I-D_boucadair-stateless-multicast]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work
in progress)", October 2011.
[I-D_tsou-AF1-specification]
Zhou, C. and T. Taylor, "Specification of a Provider-
Managed Adaptive Function Between a Multicast Receiver and
a Provider Network Supporting a Different IP Version (Work
in progress)", December 2011.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
Authors' Addresses
Tom Taylor
Huawei Technologies
1852 Lorraine Ave.
Ottawa, Ontario K1H 6Z8
Canada
Email: tom.taylor.stds@gmail.com
Taylor & Zhou Expires June 23, 2012 [Page 5]
Internet-Draft Multicast AF2 Specification December 2011
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathy.zhou@huawei.com
Taylor & Zhou Expires June 23, 2012 [Page 6]
