Internet DRAFT - draft-zhang-v6ops-ipv6oa-iwf
draft-zhang-v6ops-ipv6oa-iwf
Network Working Group J. Zhang
Internet-Draft China Telecom
Intended status: Standards Track T. Tsou
Expires: January 17, 2013 Huawei Technologies (USA)
W. Liu
Huawei Technologies
J. Sun
China Telecom
July 16, 2012
IPv6 over ATM Interworking Function
draft-zhang-v6ops-ipv6oa-iwf-01
Abstract
This document describes an interworking function between IPv6 over
ATM (Asynchronous Transfer Mode) and IPv6 over Ethernet. The
interworking function enables the communication between ATM and
Ethernet by maintaining the multiple states of both of them.
Requirements Language
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 [RFC2119].
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 January 17, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires January 17, 2013 [Page 1]
Internet-Draft IPv6oA-IWF July 2012
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
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Context and Scope . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Context and Scope . . . . . . . . . . . . . . . . . . . . . 4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. A general topology for IPv4 and IPv6 networks . . . . . . . 4
4.2. Address resolution for downstream . . . . . . . . . . . . . 5
4.3. Address resolution for upstream . . . . . . . . . . . . . . 6
4.4. Link layer address change in packets . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Zhang, et al. Expires January 17, 2013 [Page 2]
Internet-Draft IPv6oA-IWF July 2012
1. Introduction
The IPv4 exhaustion problem draws the attention of the world. There
are a number of issues to deal with when network migrates to IPv6.
The use of IPoA encapsulation on the U-interface in legacy ATM access
networks is predominantly applicable to business users. IP addresses
used in the network behind the RG are exchanged using routing
protocols that run transparently over the ATM PVCs. Currently, IPoA
encapsulation is migrated to an Ethernet aggregation network in
[TR101]. This is achieved by means of an IPoA Interworking Function
in IPv4 network. This model should continue to be supported in IPv6
scenario.
In this draft we define an Interworking Function for IPv6 to support
IPv6 over ATM, IPv6 over Ethernet, and IPv6 over SDH. In IPv4
network, upon receiving a ARP request transmitted from a BNG, the
IPoA IWF SHOULD be able to reply with the appropriate MAC address
used as the source address for upstream packets. In IPv6 scenario,
however, address resolution applies Neighbor Discovery Protocol
[RFC4861], which is in a completely different way. As the result,
IPv6oA IWF should support both the IPv6 address resolution and the
functions of IPv4oA IWF in the following way.
For upstream packets, the IPoA IWF MUST use a MAC source address that
is under the control of the Access Node (e.g. the MAC address of the
Access Node uplink).For upstream unicast packets, the IPoA IWF MUST
use a MAC unicast destination address of the BNG. For upstream
multicast and broadcast packets, the IPoA IWF MUST derive the MAC
destination address using the standard multicast/broadcast IP address
to MAC address conversion algorithm.
For downstream, BNG need to know which downstream interface that it
should forward to when receiving a packet from internet. IPv6
address resolution is necessary in this scenario. When there are
multiple BNGs in the metro networks, the IPv6oA IWF need to know
exactly which BNG it should send to. In this case IPv6oA IWF need do
IP address resolution. If Layer 2 information (such as MAC) is
included in a Neighbor Discovery packet, IPv6oA IWF need make sure
the carried information is identical to the layer 2 information in
packet. In a word, IPoA IWF should do some additional work when
networks migrate from IPv4 to IPv6.
2. Terminology
This document makes use of the following terms:
Zhang, et al. Expires January 17, 2013 [Page 3]
Internet-Draft IPv6oA-IWF July 2012
IPv6oA IWF: IPv6 over ATM interworking function
BNG: Broadband Network Gateway is the IP edge where user services
are performed.
ATM: Asynchronous Transfer Mode
RG: Residential Gateway
PVC: permanent virtual circuit
3. Context and Scope
3.1. Context and Scope
There are many kinds of access protocols between CPE and BNG device.
When IPv4 network migrates to IPv6 network, the access protocol must
be taken into account. This draft outlines how an IPv6 over ATM
access network, or an IPv6 over SDH can be migrated to an Ethernet
based IPv6 network.
This document focuses only on interworking function between IPv6 over
ATM networks, IPv6 over SDH, and Ethernet based IPv6 networks. In
the following, we use IPv6 over ATM to illustrate our main idea. The
scenarios include CPE devices that support Inverse Neighbor Discovery
[RFC3122]and BNG devices that support Neighbor Discovery based on
Ethernet. The IPv6oA interworking function makes sure the two kinds
of devices can communicate smoothly. The IPv6oA IWF may exist in
CPEs, BNGs or Access nodes(AN).
4. Solution Overview
This section describes solutions for problems mentioned above.
4.1. A general topology for IPv4 and IPv6 networks
----------
/// \\\
+------+ IPv6 over +-------------+ // \\ +----------+
| | ATM | || || |
| CPE +-----------+ IPv6oA IWF | Ethernet base | BNG |
| | | | IPv6 network | |
+------+ +-------------+| |+----------+
\\ //
\\\ ///
----------
Figure 1: Topology for IPv6 over ATM IWF
IPv6oA IWF exists in a node that lies between two kinds of networks,
Zhang, et al. Expires January 17, 2013 [Page 4]
Internet-Draft IPv6oA-IWF July 2012
IPv6 over ATM and Ethernet base IPv6 network, as shown in Figure 1.
[RFC3122]describes extensions to the IPv6 Neighbor Discovery that
allow a node to determine and advertise an IPv6 address corresponding
to a given link-layer address. These extensions are called Inverse
Neighbor Discovery (IND). IPv6 Neighbor Discovery protocol based
Ethernet is used to discover each other's presence, to determine each
other's link-layer addresses, to find routers, and to maintain
reachability information about the paths to active neighbors. The
IPv6oA interworking function is proposed to make sure the two kinds
of devices, CPE devices that support Inverse Neighbor Discovery and
BNG devices that support Neighbor Discovery based on Ethernet, can
communicate smoothly. IPv6oA IWF changes packets from IPoA to IPoE
in upstream direction and ones from IPoE to IPoA in downstream
direction, respectively. The encapsulation specification can be find
in [TR101].
4.2. Address resolution for downstream
When a BNG receives a packet from internet sent to a CPE, if the BNG
does not know the corresponding link-layer address, it checks the
neighbor cache entries to get the link layer address, i.e., the MAC
address in Ethernet. If the link layer address of corresponding
destination IP address can not be found there, the BNG initiates an
address resolution as described in charter 7.2 of [RFC4861]. The BNG
parses the destination IP address in the packet aiming to the CPE and
include the parsed IP address in Target Address field of Neighbor
Solicitation Message. Then BNG will send Neighbor Solicitation to
its downstream interface.
When IPv6oA IWF receives the Neighbor Solicitation Message from a
BNG, it have to make sure the IP address that need to be resolved is
on link IP address. IPv6oA IWF will initiate an Inverse Neighbor
Discovery Solicitation to CPE. When IPv6oA IWF receives the Inverse
Neighbor Discovery Advertisements from a CPE for the resolution IP
address, it checks the Source/Destination Address List for the IP
address to be resolved. If the IP address is in the list, then
IPv6oA IWF can response the Neighbor Solicitation Message from BNG
with Neighbor Advertisement Message. IPv6oA IWF sets the MAC of
node's upstream interface to Source/Destination Link-layer Address
option field in Neighbor Advertisement Message. Then IPv6oA IWF can
receive packets sent to CPE and forward them according to IPoA
encapsulation specification.
When IPv6oA IWF sends Inverse Neighbor Discovery Message, it can
change the Neighbor Solicitation Message from BNG to Inverse Neighbor
Discovery Solicitation message or change the Inverse Neighbor
Discovery Advertisements message from CPE to Neighbor Advertisements
message since IND protocol is just the extensions to the IPv6
Zhang, et al. Expires January 17, 2013 [Page 5]
Internet-Draft IPv6oA-IWF July 2012
Neighbor Discovery. IPv6oA IWF can work in layer 2 nodes. For
upstream packets, the IPoA IWF MUST use a MAC source address that is
under the control of the Access Node (e.g. the MAC address of the
Access Node uplink).For upstream unicast packets, the IPoA IWF MUST
use a MAC unicast destination address of the BNG. For upstream
multicast and broadcast packets, the IPoA IWF MUST derive the MAC
destination address using the standard multicast/broadcast IP address
to MAC address conversion algorithm.
4.3. Address resolution for upstream
When there are multiple BNGs in a metro network, in other word,
multiple IP edges in same networks, IPv6oA IWF needs to know which
BNG it will send according to destination IP in the packets received
from the CPE. IPv6oA IWF could configure the different BNG IPs and
MACs as the next hop by filtering the destination IP address of
packets to be sent. If we do not configure this information, IPv6oA
IWF needs to finish address resolution for upstream packets. For
simplicity, it is suggested to manually configure the BNG IP and MAC
on IPv6oA IWF node.
When IPv6oA IWF receives Inverse Neighbor Discovery Solicitation, it
responses Inverse Neighbor Discovery Advertisement with Source/
Destination Address List in the message. The Source/Destination
Address List includes the IPv6 address of BNG's downstream interface.
Source/Destination Address List can be configured or accessed from
Neighbor Cache entries.
When IPv6oA IWF receives IPv6 packets sent to a BNG, it makes address
resolution. IPv6oA IWF needs to establish Neighbor Solicitation
Message and support address resolution mentioned in charter 7.2 of
[RFC4861]. After it receives Neighbor Advertisement message,
Neighbor Cache entries will be established according to the reply
from BNG. IPv6 IWF then changes IPoA packets to IPoE packets
according to [TR101]. The destination MAC address and the source MAC
address are set as the resolved link address and the upstream link
address of IPv6oA IWF, respectively.
4.4. Link layer address change in packets
Inverse Neighbor Discovery Solicitation, Neighbor Solicitation,
Router Solicitation, and Router Advertisement packets may include a
Source/Destination Link-layer Address option in the packet. Inverse
Neighbor Discovery Advertisement, Neighbor Advertisement and Redirect
packets may include a Source/Destination Link-layer Address option in
the packet. After IPv6oA IWF gets these packets from CPE or from
BNG, it checks whether there is a Source/Destination Link-layer
Address option in the packets. If yes, it changes the Source/
Zhang, et al. Expires January 17, 2013 [Page 6]
Internet-Draft IPv6oA-IWF July 2012
Destination Link-layer Address option value to Ethernet Link-layer
Address (such as upstream interface MAC address of Access Node that
IPv6oA IWF lies in ) for upstream packets or ATM Link-layer Address
for downstream packets.
5. Security Considerations
6. Acknowledgments
7. IANA Considerations
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.
8.2. Informative References
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery Specification", RFC 3122, June 2001.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[TR101] Boardband-forum, "Migration to Ethernet-Based Broadband
Aggregation", Jul 2011, <http://www.broadband-forum.org/
technical/download/TR-101_Issue-2.pdf>.
Authors' Addresses
Jiexin Zhang
China Telecom
NO 1835, Dongnan RD, Pudong DIST
Shanghai,
P.R. China
Email: estrellazhang2012@gmail.com
Zhang, et al. Expires January 17, 2013 [Page 7]
Internet-Draft IPv6oA-IWF July 2012
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tina.tsou.zouting@huawei.com
Will Liu
Huawei Technologies
Bantian, Longgang DIST
Shenzhen 518129
P.R. China
Phone: +86 755 28972315
Email: liushucheng@huawei.com
Jianping Sun
China Telecom
NO 1835, Dongnan RD, Pudong DIST
Shanghai,
China
Email: sunjp@sttri.com.cn
Zhang, et al. Expires January 17, 2013 [Page 8]
