--- 1/draft-ietf-v6ops-802-16-deployment-scenarios-05.txt 2007-12-21 18:12:14.000000000 +0100 +++ 2/draft-ietf-v6ops-802-16-deployment-scenarios-06.txt 2007-12-21 18:12:14.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group M-K. Shin, Ed. Internet-Draft ETRI -Expires: June 20, 2008 Y-H. Han - KUT +Intended status: Informational Y-H. Han +Expires: June 22, 2008 KUT S-E. Kim KT D. Premec Siemens Mobile - December 18, 2007 + December 20, 2007 IPv6 Deployment Scenarios in 802.16 Networks - draft-ietf-v6ops-802-16-deployment-scenarios-05 + draft-ietf-v6ops-802-16-deployment-scenarios-06 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,57 +28,57 @@ 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 June 20, 2008. + This Internet-Draft will expire on June 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document we will discuss main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 4 - 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4 + 2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 3 + 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 3 2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 4 - 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5 + 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 4 2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 9 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 11 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 12 2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 13 - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . . . . 20 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + Intellectual Property and Copyright Statements . . . . . . . . . . 17 1. Introduction As the deployment of IEEE 802.16 access networks progresses, users will be connected to IPv6 networks. While the IEEE 802.16 standard defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 MAC payload, a complete description of IPv4/IPv6 operation and deployment is not present. The IEEE 802.16 standards are limited to L1 and L2, so they may be used within any number of IP network architectures and scenarios. In this document, we will discuss main @@ -189,55 +183,56 @@ 1. Shared IPv6 Prefix Link Model This link model represents the IEEE 802.16 mobile access network deployment where a subnet consists of only single AR interfaces and multiple MSs. Therefore, all MSs and corresponding AR interfaces share the same IPv6 prefix as shown in Figure 2. The IPv6 prefix will be different from the interface of the AR. +-----+ | MS1 |<-(16)-+ - +-----+ | - +-----+ | +-----+ +-----+ +--------+ - | MS2 |<-(16)-+----| BS1 |--+->| AR |----| Edge | ISP - +-----+ +-----+ | +-----+ | Router +==>Network - | +--------+ - +-----+ +-----+ | - | MS3 |<-(16)-+----| BS2 |--+ +-----+ | +-----+ - +-----+ | + +-----+ +----| BS1 |--+ + | MS2 |<-(16)-+ +-----+ | + +-----+ | +-----+ +--------+ + +->| AR |----| Edge | ISP + +-----+ | +-----+ | Router +==>Network + | MS3 |<-(16)-+ +-----+ | +--------+ + +-----+ +----| BS2 |--+ + +-----+ | +-----+ | MS4 |<-(16)-+ +-----+ Figure 2: Shared IPv6 Prefix Link Model 2. Point-to-Point Link Model + This link model represents IEEE 802.16 mobile access network deployments where a subnet consists of only single AR, BS and MS. That is, each connection to a mobile node is treated as a single link. Each link between the MS and the AR is allocated a separate, unique prefix or unique set of prefixes by the AR. The point-to- point link model follows the recommendations of [RFC3314]. - +-----+ - | MS1 |<-(16)---------+ - +-----+ | - +-----+ +-----+ +-----+ +--------+ - | MS2 |<-(16)------| BS1 |--+->| AR |----| Edge | ISP - +-----+ +-----+ | +-----+ | Router +==>Network - | +--------+ - +-----+ +-----+ | - | MS3 |<-(16)------| BS2 |--+ - +-----+ +-----+ - +-----+ | - | MS4 |<-(16)---------+ - +-----+ + +-----+ +-----+ +-----+ + | MS1 |<-(16)------| |---->| | + +-----+ | BS1 | | | + +-----+ | | | | +--------+ + | MS2 |<-(16)------| |---->| |----| Edge | ISP + +-----+ +-----+ | | | Router +==>Network + | AR | +--------+ + +-----+ +-----+ | | + | MS3 |<-(16)------| |---->| | + +-----+ | BS2 | | | + +-----+ | | | | + | MS4 |<-(16)------| |---->| | + +-----+ +-----+ +-----+ Figure 3: Point-to-Point Link Model 2.2.1.1. IPv6 Related Infrastructure Changes IPv6 will be deployed in this scenario by upgrading the following devices to dual-stack: MS, AR and ER. In this scenario, IEEE 802.16 BSs have only MAC and PHY layers without router functionality and operate as a bridge. The BS should support IPv6 classifiers as specified in [IEEE802.16]. However, if IPv4 stack is loaded to them @@ -344,22 +339,22 @@ intra-subnet handoff. Also, faster handoff may occur by the L2 trigger in case of inter-subnet handoff. Also, [IEEE802.16g] defines L2 triggers for link status such as link-up, link-down, handoff-start. These L2 triggers may make the Mobile IPv6 procedure more efficient and faster. In addition, Mobile IPv6 Fast Handover assumes the support from link- layer technology, but the particular link-layer information being available, as well as the timing of its availability (before, during or after a handover has occurred), differs according to the particular link-layer - technology in use. This issue is also being discussed in [I-D.ietf- - mipshop-fh80216e]. + technology in use. This issue is also being discussed in + [I-D.ietf-mipshop-fh80216e]. In addition, due to the problems caused by the existence of multiple convergence sublayers [RFC4840], the mobile access scenarios need solutions about how roaming will work when forced to move from one CS to another (e.g., IPv6 CS to Ethernet CS). Note that, at this phase this issue is the out of scope of this document. It should be also discussed in the 16ng WG. 2.2.2. Fixed/Nomadic Deployment Scenarios @@ -452,30 +447,31 @@ also provide some IPv6 specific functions to increase link efficiency of the 802.16 radio link (see Section 2.2.2.3). 2.2.2.2. Addressing One or more IPv6 prefixes can be shared to all the attached MSs. Prefix delegation can be required if networks exist behind the SS. 2.2.2.3. IPv6 Transport - Note that in this scenario Ethernet CS [I-D.ietf-16ng-ip-over- - ethernet-over-802.16] may be more appropriate than IPv6 CS [I-D.ietf- - 16ng-ipv6-over-ipv6cs] to transport IPv6 packets, since the scenario - needs to support plain Ethernet end-to-end connectivity. However, - the IPv6 CS can also be supported. The MS and BS will consider the - connections between the peer IP CSs at the MS and BS to form a point - to point link. In the Ethernet CS case, an Ethernet bridge may - provide implementation of an authoritative address cache and Relay - DAD. An Authoritative address cache is a mapping between the IPv6 - address and the MAC addresses of all attached MSs. + Note that in this scenario Ethernet CS + [I-D.ietf-16ng-ip-over-ethernet-over-802.16] may be more appropriate + than IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] to transport IPv6 + packets, since the scenario needs to support plain Ethernet end-to- + end connectivity. However, the IPv6 CS can also be supported. The + MS and BS will consider the connections between the peer IP CSs at + the MS and BS to form a point to point link. In the Ethernet CS + case, an Ethernet bridge may provide implementation of an + authoritative address cache and Relay DAD. An Authoritative address + cache is a mapping between the IPv6 address and the MAC addresses of + all attached MSs. The bridge builds its authoritative address cache by parsing the IPv6 Neighbor Discovery messages used during address configuration (DAD). Relay DAD means that the Neighbor Solicitation message used in the DAD process will be relayed only to the MS which already has configured the solicited address as its own address (if such an MS exist at all). 2.2.2.4. Routing