![P1: OTA/XYZ P2: ABC
JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in
2 THE MOBILE USER ENVIRONMENT
real-time device movement across a wide geography (it supports a concept similar
to mobile IP in the version 4 world, but with added capabilities). MIPv6 allows
mobile nodes (MNs) to maintain persistent IP connectivity while the MN moves
around in an IPv6 network. It has been adopted in 3G code division multiple access
(CDMA) networks for handling host-based mobility management, specifically as a
way to maintain connectivity when the MN moves between access routers (ARs). In
addition to the basic set of initial MIPv6 protocols, several enhancements have been
added in the past few years.
At the same time there has been increased interest in new forms of IP-based video
distribution, both in terms of the underlying streaming or IP television (IPTV) and/or
content distribution networks (CDNs) technology, as well as in terms of the content
providers and content creation itself. User-generated video (UGV), “for Web publish-
ing” of original content, video on demand (VoD), and time-shifted video, are seeing
steady market penetration. Consumers expect to be able to get access to such content
not only on their standard or smart (connected) TV, but also on their smartphones,
portable media players (PMPs), and tablets. MIPv6 offers an ideal opportunity to
support the evolving consumer paradigm of mobility, productivity, connectivity, en-
tertainment, and instrumentation. It follows that there is interest on the part of service
providers to explore the technology, protocols, deployment strategies, and approaches
to IPv6-based mobility in general, and IPv6 mobile video in particular. MIPv6 allows
session (e.g., Transmission Control Protocol (TCP) session) continuity—while some
video applications utilize User Datagram Protocol (UDP), other video applications
do use TCP.
The types of content that people typically get with a mobile video device include
entertainment (nonlinear video such as music videos, short clips from YouTube/Web
TV, and so on) and real-time information (linear video such as breaking news, emer-
gency reports, weather, local/regional news, live events as they happen, and traffic)
[1]. One should keep in mind that there are no substitutes for entertainment1
(one
needs a video stream), but there are substitutes for news/weather/traffic information:
one might simply look at the home page of CNN, FNC, TWC, and so on, to get that
type of information via traditional Web browsing—video may or may not actually be
required in all these instances.
Besides MIPv6, there are a number of ways to deliver video to a mobile de-
vice including but not limited to—European Telecommunications Standards Institute
(ETSI) Digital Video Broadcast Handheld (DVB-H), International Telecommunica-
tion Union—Telecommunications (ITU-T) IPTV, Internet Engineering Task Force
(IETF) IPv4, IETF Mobile IPv4 (MIP), IETF IPv6, Open Mobile Video Coalition
(OMVC) mobile digital TV, and vendor-proprietary methods. Each of these methods
has advantages and disadvantages. This investigation focuses mostly on MIPv6; we
believe to be the first textbook on this topic. An overview of the approach and capa-
bilities afforded by MIPv6 is provided in this introductory chapter. The chapters that
follow expand in greater details the concepts introduced herewith.
1We exclude videogames in this discussion.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-18-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in
4 THE MOBILE USER ENVIRONMENT
Home agent
Home
network
MN
Mobile node
Interconnecting network
(e.g., Internet)
An IPv6-enabled router that
maintains an association between
the MN’s “home address” and its
“care-of address”
while “away from home”
An IPv6 Host that maintains network
connectivity using its “home address,”
regardless of which link (or network) it is
connected to
Foreign network
FN
Access router (AR):
The MN’s default router
Destination IPv6 Host in
Session with an MN
Correspondent node
CN
HA
MN
FIGURE 1.1 Basic MIPv6 Environment
r “Plug-and-play”: IPv6 includes a “plug-and-play” mechanism that facilitates
the connection of equipment to the network. The requisite configuration is
automatic; it is a serverless mechanism.
r Security: IPv6 includes security in its specifications such as payload encryption
and authentication of the source of the communication. End-to-end security,
with built-in strong IP-layer encryption and authentication (embedded security
support with mandatory IP Security (IPsec) implementation) is supported.
In MIPv6 each MN is always identified by its “home address,”3
regardless of its
current point of attachment to the Internet; namely, an MN is always expected to be
addressable at its home address whether it is currently attached to its home link or is
away from home. The home address is an IPv6 address assigned to the MN within
its home subnet prefix on its home link. While an MN is at home, packets addressed
to its home address are routed to the MN’s home link [2].
While situated away from its home, an MN is also associated with an “in-care
of” address (CoA) that provides information about the MN’s current location. IPv6
packets addressed to an MN’s home address are transparently routed to its CoA.
A CoA is an IPv6 address associated with an MN that has a subnet prefix from a
particular foreign link. The protocol enables IPv6 nodes to cache the binding of an
MN’s home address with its CoA, and then to send any packets destined for the
3The acronym HoA is used by some; we do not.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-20-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in
6 THE MOBILE USER ENVIRONMENT
enables the MN to be identified by the far-end node, known as correspondent node
(CN). Besides the HA, any other node communicating with an MN is referred to as
a CN. While away from home, an MN obtains the CoA that is typically provided via
autoconfiguration. Summarizing this discussion, IPv6-based mobility makes use of
two IP addresses per mobile host:
1. One permanent IP address (also known, as noted, as the “home address”) is
used for identification
2. Another IP address that changes depending on the current location the MN
(called, as noted, the care-of address or CoA) is used for routing.
The association between an MN’s home address and the CoA is known as a
“binding” for the MN. While away from home, an MN registers its primary CoA
with a well-known location, a router on its home link, thus requesting this router
to function as the HA for the MN. The MN performs this binding registration by
sending a “binding update (BU)” message to the HA (see Figure 1.2). The HA is
and/or acts as a router, a device that forwards IP packets not explicitly addressed to
itself; hence, the HA is used to support connectivity on the “upstream link” (MN to
CN). On the “downstream link” (CN to MN), the CN performs packet routing toward
the MN using the routing header. The CN learns the position of an MN by processing
BUs. The CN is able to “put” and/or “get” BUs in or from the binding cache. The MN
receives router advertisements that specify the prefix of the visited remote locations.
The MN then appends the prefix to its interface ID.
The HA (a router in the MN’s home network) supports the following functions
(also see Figure 1.3):
r Intercept packets that arrive at the MN’s home network and whose destination
address is its HA
r Tunnel (i.e., provide IPv6 encapsulation) these packets to the MN
r Provide reverse tunneling from the MN to the CN
MNs can provide information about their current location to CNs, again using BUs
and binding acknowledgments (BAs). In addition, return-routability test is performed
between the MN, HA, and the CN in order to authorize the establishment of the
binding. Packets between the MN and the CN are either tunneled via the HA, or
sent directly if a binding exists in the CN for the current location of the MN. In
MIPv6, IPsec is specified as the means of securing signaling messages between the
MN and HA. MIPv6 tunnels payload packets between the MN and the HA in both
directions; this tunneling uses IPv6 encapsulation methods; where these tunnels need
to be secured, they are replaced by IPsec tunnels.
MIPv6 is a native extension of IPv6; MIPv6 is seen by some as an application that
can, in fact, foster the broader deployment of IPv6 [3]. MIPv6 is a mature protocol
with several implementations across the industry that have undergone interoperability
testing [4].](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-22-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in
BASIC MIPv6 OPERATION 7
Top: single CoA included in binding cache per RFC 3775
Bottom: multiple CoAs included in binding cache per RFC 5648
Binding cache database:
correspondent node’s binding
Binding cache database:
home agent’s binding
binding [2001:db8: :EUI BID1 CoA1]
binding [2001:db8: :EUI BID2 CoA2]
binding [2001:db8: :EUI BID3 CoA3]
binding [2001:db8: :EUI BID1 CoA1]
binding [2001:db8: :EUI BID2 CoA2]
binding [2001:db8: :EUI BID3 CoA3]
(Proxy neighbor advertisement is active)
BID: binding identification number
CN
HA
Home link
Internet
MN
CoA2
CoA1
CoA3
Internet
Home link
Binding cache database:
correspondent node’s binding
binding [2001:db8: :EUI CoA1]
Binding cache database:
home agent’s binding
binding [2001:db8: :EUI CoA1]
HA
MN
CN
CoA2
CoA1
CoA3
FIGURE 1.2 CoA Registration
MIPv6 makes use of the header structure as defined originally in RFC 2460
and adds a new extension header, specifically a mobility header; this entails a new
routing header type and a new destination option. IPv6 extension headers are optional
headers that may follow the basic IPv6 header. An IPv6 protocol data unit (PDU) may
include zero, one, or multiple extension headers; when multiple extension headers
are used, they form a chained list of headers identified by the Next Header field of the
previous header. Figure 1.4 depicts the IPv6 packet with some header extensions. The
extension header is utilized by the CN, the MN, and the HA in all the communication
transmissions for the bindings. Figure 1.5 depicts the mobility header for MIPv6.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-23-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in
8 THE MOBILE USER ENVIRONMENT
Foreign
network
Home network
HA
Home
agent
Internet
Data
BU
Data
Correspondent node
MN
Foreign
network
FIGURE 1.3 Communication Supported through the HA
Network mobility (NEMO) basic support protocol as described in RFC 3963 pro-
vides additional mobility capabilities. NEMO basic support protocol enables mobile
networks (or more specifically mobile network nodes) to attach to different points in
the Internet. The protocol is an extension of MIPv6 and allows session continuity for
every node in the mobile network as the network moves; it also allows every node in
the mobile network to be reachable while moving around. NEMO basic aims at pro-
viding continuous Internet connectivity to nodes located in an IPv6 mobile network:
an example could be an in-vehicle embedded IP network in a train, bus, airplane, that
supports multiple users (say via a WiFi in-vehicle connection). The mobile router
(MR), which connects the network to the Internet, runs the NEMO basic support
protocol with its HA. The protocol is designed so that network mobility is transpar-
ent to the nodes inside the mobile network [5]. Typically, MR implement NEMO
functionality for achieving network mobility; however, an MR may also function
as an MN. Hence, in summary, NEMO is an extension to the MIPv6 protocol that
facilitates the movement of an entire network.
In addition, extensions to MIPv6 and NEMO standards have been offered that
allow the registration of IPv4 addresses and prefixes, respectively, and the transport
of both IPv4 and IPv6 packets over the tunnel to the HA. These extensions also allow
the MN to roam over both IPv6 and IPv4, including the case where network address
translation4
(NAT) is present on the path between the MN and its HA.
4The term network address translator is also used.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-24-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in
10 THE MOBILE USER ENVIRONMENT
Another extension has also recently been advanced. As we have (implicitly) noted,
MIPv6 requires client functionality in the IPv6 stack of an MN. Exchange of signaling
messages between the MN and HA enables the creation and maintenance of a binding
between the MN’s home address and its CoA. Mobility as specified MIPv6 requires
the IP host to send IP mobility management signaling messages to the HA, which is
located in the network. Network-based mobility is another approach to solving the
IP mobility challenge. It is possible to support mobility for IPv6 nodes without host
involvement by extending MIPv6 signaling messages between a network node and
an HA. This approach to supporting mobility does not require the MN to be involved
in the exchange of signaling messages between itself and the HA. A proxy mobility
agent in the network performs the signaling with the HA and does the mobility
management on behalf of the MN attached to the network. Because of the use and
extension of MIPv6 signaling and HA functionality, this protocol is referred to as
Proxy Mobile IPv6 (PMIPv6), defined originally in RFC 5213. Network deployments
that are designed to support mobility would be agnostic to the capability in the IPv6
stack of the nodes that it serves. IP mobility for nodes that have mobile IP client
functionality in the IPv6 stack as well as those nodes that do not, would be supported
by enabling PMIPv6 protocol functionality in the network [6].
These various mobility capabilities will be explored in this text.
1.3 ENTERTAINMENT VIDEO TRENDS
Mobile video is one of a number of forces that are expected to reshape the video dis-
tribution and consumption environments during this decade. Besides mobile video,
major other drivers for this evolution include (i) new viewing habits such as time shift-
ing for nonlinear and on-demand content consumption, (ii) new distribution channels
(effectively, new content providers, especially Internet based, along with new trans-
port mechanism such as streaming), (iii) new technologies, and, (iv) standardization
of IP-based delivery, especially in conjunction multicast-based IPTV networks and/or
with web-based content downloading and social networks.
New viewer paradigms are evolving related to consumption of entertainment video
and TV programming that can be summarized as “anywhere, anything, anytime, any
platform”; namely, “from any source, any content, in any (encoded) form, at any time,
on any user-chosen device, consumed at any location.” Mobile video is an example of
the new paradigm. Game-changing shifts are also seen on the home front. For exam-
ple, many new stationary TV sets on the market that now have Ethernet networking
connections built directly into the set and require no additional equipment or set-top
boxes (STBs) for accessing the Internet; also, many high-end TVs already come with
the ability to conduct video calls. In the view of some industry observers these viewer
habits, technologies, and approaches will play a part in eventually, perhaps, supplant-
ing broadcast and cable television with Internet programming and distribution. We
previously referred to this new paradigm as nontraditional TV (NTTV); new viewer
approaches include, but are not limited to the following [7]:
r Watching entertainment/news using the Internet (such as a TV show, a movie,
or a short clip)](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-26-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in
ENTERTAINMENT VIDEO TRENDS 13
(Some) operators are already deploying MIPv6 in cellular networks. One example
of such networks is CDMA-based networks as defined in the 3GPP2 X.S0011-002-D
specification [8]. Mobile WiMAX (worldwide interoperability for microwave access),
which is based on IEEE 802.16e, also specifies in the network architecture the use of
MIPv6 [9]. Hence, our interest on a text that addresses this topic.
Industry observations such as this one [10] describe some of the important issues
that have to be taken into account by stakeholders:
In the last few years, there has been a tremendous increase in mobile video content
generation and delivery. This trend has forced the service providers to understand the
limitations of the current wired and wireless networks (Internet, WiFi, 3G/4G cellu-
lar) and bring new technologies for delivering the video content to the end-user. Last
mile access technologies play a crucial role in determining the overall performance and
end-user experience of multimodal applications; diverse approaches and technologies
(WiMAX, LTE) have recently gained momentum to address this issue. Moreover, of-
fering high quality mobile video services on resource-constrained and heterogeneous
mobile devices with varying display sizes, processing powers, network conditions, and
battery levels opens up many new challenges. Recent developments such as social me-
dia production, multimodal sensing and context technologies, will have an impact on
mobile video applications. In fact, supporting a broad spectrum of video-centric appli-
cations such as live video streaming, VoD, video games and virtual environments, . . . ,
multimedia conferencing and telepresence, surveillance, sensing and social media on
mobile devices demands application-specific techniques that adapt to the underlying
network and device architectures.
According to the Cisco Visual Networking Index (VNI) Global Mobile Data Traffic
Forecast for 2011 to 2016, worldwide mobile data traffic will increase 18-fold over
the next 5 years, reaching 10.8 exabytes per month by 2016. The increase in mobile
traffic is due to a projected surge in the number of mobile Internet-connected devices,
which will exceed the number of people on earth, estimated by then at 7.3 billion.
During 2011−2016, Cisco anticipates that global mobile data traffic will outgrow
global fixed data traffic by three times. The forecast predicts an annual run rate of 130
exabytes of mobile data traffic; this increase represents a compound annual growth
rate (CAGR) of 78 percent spanning the forecast period. The following trends are
driving these significant increases [11]:
r More streamed content: With the consumer expectations increasingly requiring
on-demand or streamed content versus simply downloaded content, mobile
cloud traffic will increase, growing 28-fold from 2011 to 2016, a CAGR of 95
percent.
r More mobile connections: There will be more than 10 billion mobile Internet-
connected devices in 2016.
r Enhanced computing of devices: Mobile devices are becoming more powerful
and thus able to consume and generate more data traffic. Tablets are expected
to be generating traffic levels that will grow 62-fold from 2011 to 2016—the](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-29-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in
APPENDIX 1.1A: STATISTICS 15
be implemented in the service provider networks to support cost-effective delivery
of entertainment, especially considering the shifts in viewing habit, and how new
revenue-generating services could be brought to the market. Chapter 2 provides
some IPv6 basics. Chapter 3 provides an overview of MIPv6 protocols, approaches,
and technologies. Chapters 4 and 5 describe some more advanced extensions and
capabilities that may be of interest to developers. Chapter 6 looks at the capabilities
offered by PMIPv6. Chapter 7 addresses security considerations in MIPv6. Chapter 8
looks at some alternative mobile video technologies and also video streaming services,
including 3/4G services; finally it assesses MIPv6 support in video environments
along with implementations and future directions.
This is believed to be the first book on MIPv6 with applications to linear and
nonlinear video distribution. This work will be of interest to planners, CTOs,
and engineers at broadcast TV operations, cable TV operations, satellite opera-
tions, Internet and ISP providers, telcos, and wireless providers, both domestically
and in the rest of the world. Also, it will be of interest to set top box develop-
ers, storage vendors, content developers, content distribution outfits, and content
aggregators.
We are not implying in this text that IPv6 and/or MIPv6 is strictly and uniquely
required to support IP-based mobile video; we are advocating, however, that that
platforms based on these protocols provide an ideal, future-proof, and scalable envi-
ronment for such evolving content-delivery services.
APPENDIX 1.1A: STATISTICS
This appendix provides some recent basic background data that supports the as-
sertions made earlier in the chapter about the growing importance of mobile video
consumption, as actually measured, not forecast, at press time. The data is summa-
rized from data published by Nielsen Company [12]. Table 1.A1 provides overall
usage by population, while Table 1.A2 depicts actual hours of usage by service
category.
TABLE 1.A1 Overall Usage—Number of Users 2+ (in 000s)—Monthly Reach
Q1, 2011 Q1, 2010
Yr to Yr
Difference (%)
Watching TV in the home 288,500 286,225 0.8
Watching time-shifted TV (all TV homes) 107,065 94,599 13.2
Using the Internet on a computer 190,913 191,301 −0.2
Watching video on Internet 142,437 135,855 4.8
Using a mobile phone 231,000 229,495 0.7
Mobile subscribers watching video on a
mobile phone
28,538 20,284 41.0](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-31-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in
18 THE MOBILE USER ENVIRONMENT
IETF RFC Title/Topic
RFC 5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server
Interaction, February 2010 (Standards Track).
RFC 5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility
Anchor Interaction with Diameter Server, February 2010 (Standards Track).
RFC 5844 IPv4 Support for Proxy Mobile IPv6, May 2010.
RFC 6058 Transient Binding for Proxy Mobile IPv6, March 2011.
RFC 6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support.
Updates RFC 5648. January 2011.
RFC 6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6. February
2011.
RFC 6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement. June
2011.
RFC 6312 Mobile Networks Considerations for IPv6 Deployment. July 2011. (Obsoleted
by RFC 6342).
RFC 6342 Mobile Networks Considerations for IPv6 Deployment. August 2011.
(Obsoletes RFC 6312).
REFERENCES
[1] D. Levitas, The Mobile DTV Opportunity and Its Role in the Communication Ecosystem,
IDC, 2010, 5 Speen Street Framingham, MA 01701, www.idc.com.
[2] J. Arkko, V. Devarapalli, F. Dupont, Using IPsec to Protect Mobile IPv6 Signaling
Between Mobile Nodes and Home Agents, RFC 3776, 2004.
[3] 6deploy.org, IPv6 Workshop – IPv6 Mobility Module, 2008.
[4] S. Gundavelli Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, “Proxy Mobile
IPv6”, RFC 5213, August 2008.
[5] V. Devarapalli, R. Wakikawa et al, Network Mobility (NEMO) Basic Support Protocol,
RFC 3963, 2005.
[6] K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, S. Gundavelli (eds) Proxy Mobile
IPv6, RFC 5213, 2008.
[7] D. Minoli, Linear and Non-Linear Video and TV Applications Using IPv6 and IPv6
Multicast, Wiley, 2012. New York, NY.
[8] 3GPP2 X.S0011-002-D, cdma2000 Wireless IP Network Standard: Simple IP and Mobile
IP Access Services, http://www.3gpp2.org/Public_html/specs/X.S0011-002-D_v1.0_
060301.pdf, 2006.
[9] WiMAX Network Architecture – WiMAX End-to-End Network Systems Architecture,
2008,http://www.wimaxforum.org/documents/documents/WiMAX_Forum_Network_
Architecture_Stage_23_Rel_1v1.2.zip.
[10] MoVid 2012, Call for Papers (CFP) for 2012 Conference, 2011.
[11] Cisco®
, Cisco Visual Networking Index (VNI) Global Mobile Data Traffic Forecast for
2011 to 2016, 2012, Cisco Systems, Inc., San Jose, CA.
[12] Nielsen Company, The Cross-Platform Report Quarter 1, 2011, www.nielsen.com.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-34-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
CHAPTER 2
IPv6 BASICS
2.1 OVERVIEW AND MOTIVATIONS
Internet protocol version 6 (IPv6) is a newer version of the network layer protocol
that is designed to coexist (but not directly interwork) with IP version 4 (IPv4). In
the long term, IPv6 is expected to replace IPv4, but that will not happen overnight.
IPv6 provides improved internetworking capabilities compared to what is presently
available with IPv4. The current IPv4 version of the Internet protocol has been
in use for over 30 years but it exhibits some challenges in supporting emerging
demands for address space cardinality, high-density mobility, multimedia, and strong
security. IPv6 offers the potential of achieving scalability, reachability, end-to-end
interworking, quality of service (QoS), and commercial-grade robustness that is
needed for contemporary and emerging Web services, data services, and IP-based
TV (IP television (IPTV) in particular and Internet-based TV (IBTV) in general),
and mobile video. The innovation and growth of the Internet is now predicated on
deployment of IPv6. We are not implying in this text that IPv6 is strictly and uniquely
required to support IP-based IBTV/nontraditional TV (NTTV)/IPTV, linear video,
video/content on demand (VoD/CoD), streaming video, and/or mobile video, just that
it provides an ideal, future-proof, scalable mechanism for such services, whether in
a terrestrial mode on in a satellite-based mode [1–2].
IP was designed in the late 1970s–early 1980s for the purpose of connecting
computers that were in separate geographic locations. Starting in the early 1990s,
developers realized that the communication needs of the twenty-first century needed
Mobile Video with Mobile IPv6, First Edition. Daniel Minoli.
C
2012 John Wiley Sons, Inc. Published 2012 by John Wiley Sons, Inc.
19](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-35-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
20 IPv6 BASICS
a protocol with some new features and capabilities, while at the same time retaining
the useful features of the existing protocol. IPv6 was initially developed in the early
1990s because of the anticipated need for more end-system addresses based on
anticipated Internet growth, encompassing mobile phone deployment, smart home
appliances, and billions of new users in developing countries (e.g., BRIC countries:
Brazil, Russia, India, China). Technologies and applications such as voice over IP
(VoIP), “always-on access” (e.g., cable modems), broadband and/or Ethernet-to-the-
home, converged networks, and evolving ubiquitous computing applications will be
driving this need even more intensively in the next few years [3].
IPv6 is now being slowly deployed worldwide: there is documented institutional
and commercial interest and activity in Europe and Asia, and there is also evolving
interest in the United States. The expectation is that in the next few years, deployment
this new protocol will occur worldwide. For example, the U.S. Department of Defense
(DoD) announced that from October 1, 2003, all new developments and procurements
needed to be IPv6 capable; the DoD’s goal was to complete the transition to IPv6 for all
intra- and inter networking across the agency by 2008, which was accomplished. The
U.S. Government Accountability Office (GAO) has recommended that all agencies
become proactive in planning a coherent transition to IPv6. The current expectation
is that IPv4 will continue to exist for the foreseeable future, while IPv6 will be used
for new broad-scale applications. The two protocols are not directly interworkable,
but tunneling and dual-stack techniques allow coexistence and co-working.
While the basic function of the network layer internetworking protocol is to move
information across networks, IPv6 has more capabilities built into its foundation
than IPv4. Link-level communication does not generally require a node identifier
(address) since the device in intrinsically identified with the link level address; how-
ever, communication over a group of links (a network) does require unique node
identifiers (addresses). The IP address is an identifier that is applied to each device
connected to an IP network. In this setup, different entities taking part in the net-
work (servers, routers, user computers, and so on) communicate among each other
using their IP address, as an entity identifier. The current IPv4 naming scheme was
developed in the 1970s and had capacity for about 4.3 billion addresses, which were
grouped into 255 blocks of 16 million addresses each. In version 4 of the IP protocol,
addresses consist of four octets. With IPv4, the 32-bit address can be represented as
AdrClass|netID|hostID. The network portion can contain either a network ID or
a network ID and a subnet. Every network and every host or device has a unique
address, by definition. For ease of human conversation, IP protocol addresses are
represented as separated by periods, for example: 166.74.110.83, where the decimal
numbers are a shorthand and correspond to the binary code described by the byte in
question (an 8-bit number takes a value in the 0–255 range). Since the IPv4 address
has 32 bits, there are nominally 232
different IP addresses (as noted, approximately
4.3 billion nodes, if all combinations are used).
IPv4 has proven, by means of its long life, to be a flexible and powerful networking
mechanism. However, IPv4 is starting to exhibit limitations, not only with respect to
the need for an increase of the IP address space, driven, for example, by new popula-
tions of users in countries such as China and India; but also by new technologies with](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-36-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
OVERVIEW AND MOTIVATIONS 21
TABLE 2.1 Projected RIR Unallocated Address Pool Exhaustion (as of April 2011)
RIR Assigned Addresses (/8s) Remaining Addresses (/8s)
AFRINIC 8.3793 4.6168
APNIC 53.7907 1.2093
ARIN 77.9127 6.0130
LACNIC 15.6426 4.3574
RIPENCC 45.0651 3.9349
RIR = Regional Internet Registry
AfriNIC = African Network Information Centre
ARIN = American Registry for Internet Numbers
APNIC = Asia-Pacific Network Information Centre
LACNIC = Latin America and Caribbean Network Information Centre (LACNIC)
RIPE NCC = Réseaux IP Européens Network Coordination Centre (the RIR for Europe, the Middle East
and parts of Central Asia)
“always connected devices” (e.g., cable modems, networked PDAs, 3G/4G mobile
smartphones, and so on); and also by new services such global rollout of VoIP, IPTV,
and social networking. A Regional Internet Registry (RIR) manages the allocation
and registration of Internet resources such as IPv4 addresses, IPv6 addresses and au-
tonomous system (AS) numbers, in a specific region of the world. As of February 1,
2011 only 1 percent of all possible IPv4 addresses were left unassigned. This has
led to a predicament known as IPv4 run out. The entire address space was expected
to be more or less exhausted by September 2011, according to the IPv4 Address
Report (see Table 2.1) [4–5]. The IPv4 address allocation is based on the following
hierarchy:
Internet Assigned Numbers Authority (IANA) –Regional Internet Registries (RIRs)
– Internet service providers (ISPs) – the public (including businesses).
Thus, a key desirable capability is the increase in address space such that it is
able to cover all elements of the universe set under consideration. For example, all
computing devices could have a public IP address, so that they can be uniquely
tracked1
; for example, today inventory management of dispersed IT assets cannot be
achieved with IP mechanisms alone. With IPv6 one can use the network to verify that
such equipment is deployed in place and active; even non-IT equipment in the field
can be tracked by having an IP address permanently assigned to it. IPv6 creates a new
IP address format, such that the number of IP addresses will not exhaust for several
decades or longer, even though an entire new crop of devices are expected to connect
to Internet over the coming years creating the so called Internet of Things [IoT]. IPv6
also adds improvements in areas such as routing and network configuration. IPv6 has
extensive automatic configuration (autoconfiguration) mechanisms and reduces the IT
1Note that this has some potential negative security issues as attackers could be able to own a machine and
then exactly know how to go back to that same machine again. Therefore reliable security mechanisms
need to be understood and put in place in IPv6 environments.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-37-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
22 IPv6 BASICS
burden-making configuration, essentially plug and play. Specifically, new devices that
connect to intranet or Internet will be “plug-and-play” devices. With IPv6, one is not
required to configure dynamic nonpublished local IP addresses, the gateway address,
the subnetwork mask, or any other parameters. The equipment automatically obtains
all requisite configuration data when it connects to the network. Autoconfiguration
implies that a Dynamic Host Configuration Protocol (DHCP) server is not needed
and/or does not have to be configured [2,6–7].
IPv6 was originally defined in Internet Engineering Task Force (IETF) RFC
1883 that was then obsolete by RFC 2460, “Internet Protocol, version 6 (IPv6)
Specification,” S. Deering, R. Hinden (December 1998)2
. A large body of additional
RFCs has emerged in recent years to add capabilities and refine the concept.
The advantages of IPv6, some of which we already noted in Chapter 1, can be
summarized as follows:
r Scalability and expanded addressing capabilities: IPv6 has 128-bit addresses
versus 32-bit IPv4 addresses. With IPv4, the theoretical number of available
IP addresses is 232
∼1010
. IPv6 offers a 2128
space. Hence, the number of
available unique node addressees is 2128
∼1039
. IPv6 has more than 340 un-
decillion (340282366920938463463374607431768211456) addresses, grouped
into blocks of 18 quintillion addresses.
r Plug-and-play: IPv6 includes a “plug-and-play” mechanism that facilitates
the connection of equipment to the network. The requisite configuration is
automatic; it is a serverless mechanism.
r IPv6 makes it easy for nodes to have multiple IPv6 addresses on the same
networkinterface. This cancreatetheopportunityfor users toestablishoverlayor
communities of interest (COI) networks on top of other physical IPv6 networks.
Departments, groups, or other users and resources can belong to one or more
COIs, where each can have its own specific security policy [8].
r Security: IPv6 includes security in its specifications such as payload encryption
and authentication of the source of the communication. End-to-end security,
with built-in, strong IP-layer encryption and authentication (embedded security
support with mandatory IP Security (IPsec) implementation). It follows that IPv6
network architectures can easily adapt to an end-to-end security model where the
end hosts have the responsibility of providing the security services necessary to
protect any data traffic between them; this results in greater flexibility for creating
policy-based trust domains that are based on varying parameters including node
address and application [9].
r In IPv6, creating a virtual private network (VPN) is easier and more standard
than in IPv4, because of the (authentication header (AH) and encapsulating
security protocol (ESP)) extension headers. The performance penalty is lower
for the VPN implemented in IPv6 compared to those built in IPv4 [10].
2The “version 5” reference was employed for another use—an experimental real-time streaming
protocol—and to avoid any confusion, it was decided not to use this nomenclature.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-38-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
ADDRESS CAPABILITIES 23
r Optimized protocol: IPv6 embodies IPv4 best practices but removes unused
or obsolete IPv4 characteristics. This results in a better, optimized Internet
protocol. Also, merging two IPv4 networks with overlapping addresses (say, if
two organizations merge) is complex; it will be much easier to merge networks
with IPv6.
r Real-time applications: To provide better support for real-time traffic (e.g.,
VoIP, IPTV), IPv6 includes “labeled flows” in its specifications. By means of
this mechanism, routers can recognize the end-to-end flow to which transmitted
packets belong. This is similar to the service offered by Multiprotocol Label
Switching (MPLS), but it is intrinsic with the IP mechanism rather than an
add-on. Also, it preceded this MPLS feature by a number of years.
r Mobility: IPv6 includes more efficient and robust mobility mechanisms (en-
hanced support for Mobile IP, mobile computing devices, and mobile video).
Specifically, Mobile IPv6 (MIPv6) as defined in RFC 3775 is now starting to be
deployed [11].
r Streamlined header format and flow identification.
r Extensibility: IPv6 has been designed to be extensible and offers support for
new options and extensions.
ISPs and carriers have been preparing for IP-address exhaustion for a number of
years and there are transition plans in place. The expectation is that IPv6 can make
IP devices less expensive, more powerful, and even consume less power; the power
issue is not only important for environmental reasons, but also improves operability
(e.g., longer battery life in portable devices, such as mobile phones and iPads).
2.2 ADDRESS CAPABILITIES
2.2.1 IPv4 Addressing and Issues
IPv4 addresses can be from an officially assigned public range or from an internal
intranet private (but not globally unique) block. As noted, IPv4 theoretically allows
up to 232
addresses, based on a four-octet address space. Hence, there are 4294967296
unique values, which can be considered as a sequence of 256 “/8s,” where each “/8”
corresponds to 16777216 unique address values. Public, globally unique addresses
are assigned by IANA. IP addresses are addresses of network nodes at Layer 3; each
device on a network (whether the Internet or an intranet) must have a unique address.
In IPv4, a 32-bit (4-byte) binary address is used to identify a host’s network ID. It
is represented by the nomenclature a.b.c.d (each of a, b, c, and d being from 1 to
255 (0 has a special meaning). Examples are 167.168.169.170, 232.233.229.209, and
200.100.200.100.
The problem is that during the 1980s, many public, registered addresses were
allocated to firms and organizations without any consistent control. As a result, some
organizations have more addresses than they actually need, giving rise to the present](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-39-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
24 IPv6 BASICS
dearth of available “registerable” Layer 3 addresses. Furthermore, not all IP addresses
can be used due to the fragmentation described above.
One approach to the issue would be a renumbering and a reallocation of the
IPv4 addressing space. However, this is not as simple as it appears since it requires
worldwide coordination efforts. Moreover, it would still be limited for the human
population and the quantity of devices that will be connected to Internet in the
medium-term future. At this juncture, and as a temporary and pragmatic approach
to alleviate the dearth of addresses, network address translation (NAT) mechanisms
are employed by organizations and even home users. This mechanism consists of
using only a small set of public IPv4 addresses for an entire network to access to
Internet. The myriad of internal devices are assigned IP addresses from a specifically
designated range of Class A or Class C address that are locally unique but are
duplicatively used and reused within various organizations. In some cases (e.g.,
residential Internet access use via DSL or Cable), the legal IP address is only provided
to a user on a time-lease basis, rather than permanently.
Internal intranet addresses may be in the ranges 10.0.0.0/8, 172.16.0.0/12, and
192.168.0.0/16. In the internal intranet private address case, a NAT function is em-
ployed to map the internal addresses to an external public address when the private-to-
public network boundary is crossed. This, however, imposes a number of limitations,
particularly since the number of registered public addresses available to a company
is almost invariably much smaller (as small as 1) than the number of internal devices
requiring an address. A number of protocols cannot easily travel through a NAT
device and hence the use of NAT implies that many applications (e.g., VoIP) cannot
be used effectively in all instances. As a consequence, these applications can only be
used in intranets. Examples include:
r Multimedia applications such as videoconferencing, VoIP, or video on demand/
IPTV do not work smoothly through NAT devices. Multimedia applications
make use of Real-time Transport Protocol (RTP) and Real-Time Control Proto-
col (RTCP). These in turn use the User Datagram Protocol (UDP) with dynamic
allocation of ports and NAT does not directly support this environment.
r IPsec is used extensively for data authentication, integrity, and confidentiality.
However, when NAT is used, IPsec operation is impacted, since NAT changes
the address in the IP header.
r Multicast, although possible in theory, requires complex configuration in a NAT
environment and hence, in practice, is not utilized as often as could be the case.
r The need for obligatory use of NAT disappears with IPv6.
2.2.2 IPv6 Address Space
The IPv6 addressing architecture is described in RFC 4291, February 2006 [12].
One of the major modifications in the addressing scheme in IPv6 is a change to the
basic types of addresses and how they are utilized. Unicast addresses are utilized
for a majority of traditional (enterprise) communications, as was the case in IPv4.
However, Broadcast as a specific addressing type has been eliminated, in its place](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-40-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
26 IPv6 BASICS
a b c
Unicast
Multicast
Anycast
c
b
2
a
a
a
a
a
3
Note: Device 1 and 2
are part of the same
group
Note: Device 1, 2, and
3 are part of the same
group
a
2
1
3
3
a
1
1
2
FIGURE 2.2 Comparison of Transmissions to IPv6 Nodes
The relatively large size of the IPv6 address is designed to be subdivided into
hierarchical routing domains that reflect the topology of the modern-day Internet.
The use of 128 bits provides multiple levels of hierarchy and flexibility in designing
hierarchical addressing and routing. The IPv4-based Internet currently lacks this
flexibility [13].](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-42-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
ADDRESS CAPABILITIES 27
The IPv6 address is represented as eight groups of 16 bits each, separated by
the “:” character. Each 16-bit group is represented by four hexadecimal digits,
that is, each digit has a value between 0 and f (0,1, 2, . . . a, b, c, d, e, f with a
= 10, b = 11, and so on to f = 15). What follows is an IPv6 address example
3223:0ba0:01e0:d001:0000:0000:d0f0:0010
An abbreviated format exists to designate IPv6 addresses when all endings are
0. For example, 3223:0ba0:: is the abbreviated form of the following address:
3223:0ba0:0000:0000:0000:0000:0000:0000
Similarly, only one 0 is written, removing 0s in the left side, and four 0s in the mid-
dle of the address. For example, the address 3223:ba0:0:0:0:0::1234 is the abbreviated
form of the following address: 3223:0ba0:0000:0000:0000:0000:0000:1234
There is also a method to designate groups of IP addresses or subnetworks that is
based on specifying the number of bits that designate the subnetwork, beginning from
left to right, using remaining bits to designate single devices inside the network. For
example, the notation 3223:0ba0:01a0::/48 indicates that the part of the IP address
used to represent the subnetwork has 48 bits. Since each hexadecimal digit has 4-bits,
this points out that the part used to represent the subnetwork is formed by 12 digits,
that is: “3223:0ba0:01a0.” The remaining digits of the IP address would be used to
represent nodes inside the network.
As noted, anycast addresses are a new type of address defined in IPv6 (as originally
defined in RFC 1546). The purpose of the anycast address functionality is to enable
capabilities that were difficult to implement in IPv4 environments. Datagrams sent
to the anycast address are automatically delivered to the device in the network that is
the easiest to reach. Anycast addresses can be used to define a group of devices, any
one of which can support a service request from the user sent to a single specific IP
address. One example is situations where one needs a service that can be provided by
a set of different (dispersed) servers, but where one does not specifically care which
one provides it; a specific example here may be an Internet or video (streaming) cache.
Another example of anycast addressing is a router arrangement that allows datagrams
to be transmitted to whichever router in a group of equivalent routers is closest to the
point of transmission; a specific example here may be to allow load sharing between
routers. It should be noted that there is no special anycast addressing format; anycast
addresses are the same as unicast addresses from an address format perspective. In
practicality, an anycast address is defined and created is a self-declarative manner
when a unicast address is assigned to more than one device interface.
Special IPv6 addresses, as follows (see Table 2.2 for additional details [14]):
r Autoreturn or loopback virtual address: This address is specified in IPv4 as the
127.0.0.1 address. In IPv6, this address is represented as ::1.
r Not specified address (::): This address is not allocated to any node since it is
used to indicate absence of address.
r IPv6 over IPv4 dynamic/automatic tunnel addresses: These addresses are des-
ignated as IPv4-compatible IPv6 addresses and allow the sending of IPv6 traffic
over IPv4 networks in a transparent manner. They are represented as, for exam-
ple, ::156.55.23.5.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-43-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
30 IPv6 BASICS
Destination Address
Source Address
Payload Length
Traffic Class Flow Label
Next Header Hop Limit
Version
FIGURE 2.3 IPv6 Packet
might be lost, delivered out of sequence, duplicated, or delayed. IPv6 per se does
not attempt to recover from these types of errors. The acknowledgment of packets
delivered and the recovery of lost packets is done by a higher-layer protocol, such
as Transmission Control Protocol (TCP) [13]. From a packet forwarding perspective
IPv6 operates in a similar, nearly identical manner to IPv4.
An IPv6 packet, also known as an IPv6 datagram, consists of an IPv6 header and
an IPv6 payload, as shown Figure 2.3. The IPv6 header consists of two parts, the IPv6
base header and optional extension headers (see Figure 2.4). Functionally, the optional
Version Traffic Class
Payload Length
Flow Label
Hop Limit
Next Header
Source IPv6 Address (128 Bits)
Destination IPv6 Address (128 Bits)
Extension Header Information
Next Header
Payload
Variable
Length
40
Octets
IPv6 extension headers are optional headers that may follow the basic IPv6
header. An IPv6 PDU may include zero, one, or multiple extension headers.
When multiple extension headers are used, they form a chained list of
headers identified by the Next Header field of the previous header.
FIGURE 2.4 IPv6 Extension Headers](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-46-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
IPv6 PROTOCOL OVERVIEW 31
extension headers and upper-layer protocols, for example TCP, are considered part
of the IPv6 payload. Table 2.4 shows the fields in the IPv6 base header. IPv4 headers
and IPv6 headers are not directly interoperable: hosts and/or routers must use an
implementation of both IPv4 and IPv6 in order to recognize and process both header
formats (see Figure 2.5). This gives rise to a number of complexities in the migration
process between the IPv4 and the IPv6 environments. The IP header in IPv6 has
been streamlined and defined to be of a fixed length (40 bytes). In IPv6, header fields
from the IPv4 header have been removed, renamed, or moved to the new optional
IPv6 extension headers. The header length field is no longer needed since the IPv6
header is now a fixed length entity. The IPv4 “type of service” is equivalent to the
IPv6 “traffic class” field. The “total length” field has been replaced with the “payload
length” field. Since IPv6 only allows for fragmentation to be performed by the IPv6
source and destination nodes, and not individual routers, the IPv4 segment control
fields (Identification, Flags, and Fragment Offset fields) have been moved to similar
fields within the fragment extension header. The functionality provided by the “time
to live (TTL4
)” field has been replaced with the “hop limit” field. The “protocol”
field has been replaced with the “Next Header type” field. The “header checksum”
field was removed, that has the main advantage of not having each relay spend time
processing the checksum. The “options” field is no longer part of the header as it was
in IPv4. Options are specified in the optional IPv6 extension headers. The removal of
the options field from the header enables more efficient routing; only the information
that is needed by a router needs to be processed [15].
One area requiring consideration, however, is the length of the IPv6 protocol data
unit (PDU): the 40-octet header can be a problem for real-time IP applications such as
VoIP and IPTV. Header compression (HC) becomes critical for many applications, as
noted in Section 2.4. Also, there will be some bandwidth inefficiency in general, that
could be an issue in limited-bandwidth environments or applications (e.g., wireless
networks, sensor networks).
Stateless address autoconfiguration (described in RFC 4862) defines how an IPv6
node generates addresses without the use of a Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) server [16]. “Autoconfiguration” is a new characteristic of the
IPv6 protocol that facilitates network management and system set-up tasks by users.
This characteristic is often called “plug and play” or “connect and work.” Autoconfig-
uration facilitates initialization of user devices: after connecting a device to an IPv6
network, one or several IPv6 globally unique addresses are automatically allocated.
Note, however, that an IPv6 address must be configured on a router’s interface for
the interface to forward IPv6 traffic. Configuring a global IPv6 address on a router’s
interface automatically configures a link-local address (LLA) and activates IPv6 for
that interface.
DHCP allows systems to obtain an IPv4 address and other required information
(e.g., default router or Domain Name System (DNS) server); a similar protocol,
DHCPv6, has been published for IPv6. DHCP and DHCPv6 are known as stateful
protocols because they maintain tables on (specialized) servers. However, IPv6 also
4TTL has been used in many attacks and Intrusion Detection System (IDS) tricks in IPv4.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-47-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
34 IPv6 BASICS
has a new stateless autoconfiguration protocol that has no equivalent in IPv4. The
stateless autoconfiguration protocol does not require a server component because
there is no state to maintain (a DHCP server may typically run in a router or firewall).
Every IPv6 system (other than routers) is able to build its own unicast global address.
[17]. “Stateless” autoconfiguration is also described as “serverless.” The acronym
SLAAC is also used; it expands to stateless address autoconfiguration. SLAAC was
originally defined in RFC 2462. With SLAAC the presence of configuration servers
to supply profile information is not required.
The host generates its own address using a combination of the information that it
possesses (in its interface or network card) and the information that is supplied by the
router. As noted in RFC 4941, nodes use IPv6 stateless address autoconfiguration to
generate addresses using a combination of locally available information and informa-
tion advertised by routers. Addresses are formed by combining network prefixes with
an interface identifier. On an interface that contains an embedded Institute of Electrical
and Electronics Engineers (IEEE) identifier, the interface identifier is typically derived
from it. On other interface types, the interface identifier is generated through other
means, for example, via random number generation [18] Some types of network inter-
faces come with an embedded IEEE identifier (i.e., a link-layer media access control
(MAC) address), and in those cases, stateless address autoconfiguration uses the IEEE
identifier to generate a 64-bit interface identifier [12]. By design, the interface identi-
fier is likely to be globally unique when generated in this fashion. The interface iden-
tifier is in turn appended to a prefix to form a 128-bit IPv6 address. Not all nodes and
interfaces contain IEEE identifiers. In such cases, an interface identifier is generated
through some other means (e.g., at random), and the resultant interface identifier may
not be globally unique and may also change over time. Routers determine the prefix
that identifies networks associated to the link under discussion. The “interface identi-
fier” identifies an interface within a subnetwork and is often, and by default, generated
from the MAC address of the network card. The IPv6 address is built combining the
64 bits of the interface identifier with the prefixes that routers determine as belonging
to the subnetwork. If there is no router, the interface identifier is self-sufficient to
allow the PC to generate an LLA. The LLA is sufficient to allow the communication
between several nodes connected to the same link (the same local network).
In summary, all nodes combine interface identifiers (whether derived from an
IEEE identifier or generated through some other technique) with the reserved link-
local prefix to generate LLAs for their attached interfaces. Additional addresses
can then be created by combining prefixes advertised in router advertisements via
neighbor discovery (defined in RFC 4861 [19]) with the interface identifier.
Note: As seen, addresses generated using stateless address autoconfiguration contain
an embedded interface identifier that remains constant over time. Whenever a fixed
identifier is used in multiple contexts, a security exposure could theoretically result.
A correlation can be performed by an attacker who is in the path between the node
in question and the peer(s) to which it is communicating, and who can view the IPv6
addresses present in the datagrams. Because the identifier is embedded within the IPv6
address, which is a fundamental requirement of communication, it cannot be easily
hidden. Solutions to this issue have been proposed by generating interface identifiers
that vary over time [18].](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-50-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
IPv6 PROTOCOL OVERVIEW 35
IPv6 addresses are “leased” to an interface for a fixed established time (including
an infinite time). When this “lifetime” expires, the link between the interface and
the address is invalidated and the address can be reallocated to other interfaces. For
the suitable management of addresses expiration time, an address goes through two
states (stages) while is affiliated to an interface [20]:
(a) At first, an address is in a “preferred” state, so its use in any communication
is not restricted.
(b) After that, an address becomes “deprecated,” indicating that its affiliation with
the current interface will (soon) be invalidated.
When it is in a “deprecated” state, the use of the address is discouraged, although it
is not forbidden. However, when possible, any new communication (for example, the
opening of a new TCP connection) must use a “preferred” address. A “deprecated”
address should only be used by applications that have already used it before and in
cases where it is difficult to change this address to another address without causing a
service interruption.
To ensure that allocated addresses (granted either by manual mechanisms or by
autoconfiguration) are unique in a specific link, the link duplicated addresses detection
algorithm is used. The address to which the duplicated address detection algorithm
is being applied to is designated (until the end of this algorithmic session) as an
“attempt address.” In this case, it does not matter that such address has been allocated
to an interface and received packets are discarded.
Further we describe how an IPv6 address is formed. The lowest 64 bits of the
address identify a specific interface and these bits are designated as “interface iden-
tifier.” The highest 64 bits of the address identify the “path” or the “prefix” of the
network or router in one of the links to which such interface is connected. The IPv6
address is formed by combining the prefix with the interface identifier.
It is possible for a host or device to have IPv6 and IPv4 addresses simultaneously.
Most of the systems that currently support IPv6 allow the simultaneous use of both
protocols. In this way it is possible to support communication with IPv4-only net-
works as well as IPv6-only networks, and the use of the applications developed for
both protocols [20].
It is possible to transmit IPv6 traffic over IPv4 networks via tunneling methods.
This approach consists of “wrapping” the IPv6 traffic as IPv4 payload data: IPv6
traffic is sent “encapsulated” into IPv4 traffic and at the receiving end this traffic is
parsed as IPv6 traffic. Transition mechanisms are methods used for the coexistence
of IPv4 and/or IPv6 devices and networks. For example, an “IPv6-in-IPv4 tunnel”
is a transition mechanism that allows IPv6 devices to communicate through an IPv4
network. The mechanism consists of creating the IPv6 packets in a normal way
and encapsulating them in an IPv4 packet. The reverse process is undertaken in the
destination machine that de-encapsulates the IPv6 packet.
There is a significant difference between the procedures to allocate IPv4 addresses
that focus on the parsimonious use of addresses (since addresses are a scare re-
source and should be managed with caution), and the procedures to allocate IPv6
addresses, that focus on flexibility. ISPs deploying IPv6 systems follow the RIRs’](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-51-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
36 IPv6 BASICS
policies relating to how to assign IPv6 addressing space among their clients. RIRs
are recommending ISPs and operators allocate to each IPv6 client a /48 subnetwork;
this allows clients to manage their own subnetworks without using NAT. (The im-
plication is that the obligatory need for NAT for intranet-based devices disappears
in IPv6.)
In order to allow its maximum scalability, the IPv6 protocol uses an approach
based on a basic header, with minimum information. This differentiates it from IPv4
where different options are included in addition to the basic header. IPv6 uses a header
“concatenation” mechanism to support supplementary capabilities. The advantages
of this approach include the following:
r The size of the basic header is always the same, and is well known. The basic
header has been simplified compared with IPv4, since only 8 fields are used
instead of 12. The basic IPv6 header has a fixed size; hence, its processing by
nodes and routers is more straightforward. Also, the header’s structure aligns to
64 bits, so that new and future processors (64 bits minimum) can process it in a
more efficient way.
r Routers placed between a source point and a destination point (i.e., the route
that a specific packet has to pass through), do not need to process or understand
any “following headers.” In other words, in general, interior (core) points of
the network (routers) only have to process the basic header, while in IPv4 all
headers must be processed. This flow mechanism is similar to the operation in
MPLS, yet precedes it by several years.
r There is no limit to the number of options that the headers can support (the IPv6
basic header is 40 octets in length, while the IPv4 header varies from 20 to 60
octets, depending on the options used).
In IPv6, interior/core routers do not perform packets fragmentation, but the frag-
mentation is performed end to end. That is, source and destination nodes perform, by
means of the IPv6 stack, the fragmentation of a packet and the reassembly, respec-
tively. The fragmentation process consists of dividing the source packet into smaller
packets or fragments [20].
The IPv6 specification defines a number of extension headers [15] (also see
Table 2.5 [21]):
r Routing header: Similar to the source routing options in IPv4. The header is
used to mandate a specific routing.
r Authentication header (AH): A security header that provides authentication and
integrity.
r Encapsulating security payload (ESP) header: A security header that provides
authentication and encryption.
r Fragmentation header: The fragmentation header is similar to the fragmentation
options in IPv4.](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-52-320.jpg)
![P1: OTA/XYZ P2: ABC
JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in
38 IPv6 BASICS
IPv6 tunneling as defined in RFC 2473 [22] is a technique for establishing a
“virtual link” between two IPv6 nodes for transmitting data packets as payloads
of IPv6 packets. From the perspective of the two nodes, this “virtual link,” called
an IPv6 tunnel, appears as a point-to-point link on which IPv6 acts like a link-
layer protocol. The two IPv6 nodes support specific roles. One node encapsulates
original packets received from other nodes or from itself and forwards the resulting
tunnel packets through the tunnel. The other node decapsulates the received tunnel
packets and forwards the resulting original packets toward their destinations, possibly
itself. The encapsulator node is called the tunnel entry-point node, and it is the
source of the tunnel packets. The decapsulator node is called the tunnel exit point,
and it is the destination of the tunnel packets. An IPv6 tunnel is a unidirectional
mechanism—tunnel packet flow takes place in one direction between the IPv6 tunnel
entry-point and exit-point nodes (see Figure 2.6, top). Bidirectional tunneling is
achieved by merging two unidirectional mechanisms, that is, configuring two tunnels,
Tunneling mechanism
Tunnel from node B to node C
Tunnel from node B to node C
Tunnel from node C to node B
Bidirectional tunneling mechanism
Tunnel
Tunnel C
B
Original
Packet
Source
Node
Original
Packet
Source
Node
Original
Packet
Source
Node
Original
Packet
Destination
Node
Tunnel
Exit-Point
Node
Tunnel
Entry-Point
Node
Tunnel
Exit-Point
Node
Tunnel
Entry-Point
Node
Original
Packet
Destination
Node
Tunnel
Entry-Point
Node
Tunnel
Exit-Point
Node
Original
Packet
Destination
Node
A
B C
D
D
A
FIGURE 2.6 IPv6 Tunneling](https://image.slidesharecdn.com/2154184-250605173013-c8e6d79c/85/Mobile-Video-With-Mobile-Ipv6-Daniel-Minoliauth-54-320.jpg)
Mobile Video With Mobile Ipv6 Daniel Minoliauth
- 1. Mobile Video With Mobile Ipv6 Daniel Minoliauth download https://ebookbell.com/product/mobile-video-with-mobile- ipv6-daniel-minoliauth-4308368 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Robot Vision Videobased Indoor Exploration With Autonomous And Mobile Robots Stefan Florczyk https://ebookbell.com/product/robot-vision-videobased-indoor- exploration-with-autonomous-and-mobile-robots-stefan-florczyk-1223376 Joint Sourcechannel Decoding A Crosslayer Perspective With Applications In Video Broadcasting Over Mobile And Wireless Networks Pierre Duhamel And Michel Kieffer Auth https://ebookbell.com/product/joint-sourcechannel-decoding-a- crosslayer-perspective-with-applications-in-video-broadcasting-over- mobile-and-wireless-networks-pierre-duhamel-and-michel-kieffer- auth-4409310 Gre Premier 2017 With 6 Practice Tests Online Book Videos Mobile Kaplan https://ebookbell.com/product/gre-premier-2017-with-6-practice-tests- online-book-videos-mobile-kaplan-11704304 Kaplan Asvab Premier 20172018 With 6 Practice Tests Online Book Videos Mobile Inc https://ebookbell.com/product/kaplan-asvab- premier-20172018-with-6-practice-tests-online-book-videos-mobile- inc-22002608
- 3. Freetoplay Mobile Video Games Bias And Norms Christopher A Paul https://ebookbell.com/product/freetoplay-mobile-video-games-bias-and- norms-christopher-a-paul-56576538 Gre Prep Plus 2020 Practice Tests Proven Strategies Online Video Mobile Kaplan Publishing https://ebookbell.com/product/gre-prep-plus-2020-practice-tests- proven-strategies-online-video-mobile-kaplan-publishing-10824618 Video Coding For Mobile Communications Efficiency Complexity And Resilience 1st Edition Mohammed Almualla https://ebookbell.com/product/video-coding-for-mobile-communications- efficiency-complexity-and-resilience-1st-edition-mohammed- almualla-972558 Wireless Video Communications Second To Third Generation And Beyond Ieee Series On Mobile Digital Communications 1st Edition Lajos L Hanzo https://ebookbell.com/product/wireless-video-communications-second-to- third-generation-and-beyond-ieee-series-on-mobile-digital- communications-1st-edition-lajos-l-hanzo-2023060 Guide To Voice And Video Over Ip For Fixed And Mobile Networks 1st Edition Lingfen Sun https://ebookbell.com/product/guide-to-voice-and-video-over-ip-for- fixed-and-mobile-networks-1st-edition-lingfen-sun-4241412
- 5. P1: OTA/XYZ P2: ABC JWBS086-fm JWBS086-Minoli June 27, 2012 10:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in MOBILE VIDEO WITH MOBILE IPv6 i
- 6. P1: OTA/XYZ P2: ABC JWBS086-fm JWBS086-Minoli June 27, 2012 10:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in MOBILE VIDEO WITH MOBILE IPv6 DANIEL MINOLI A JOHN WILEY & SONS, INC., PUBLICATION iii
- 7. P1: OTA/XYZ P2: ABC JWBS086-fm JWBS086-Minoli June 27, 2012 10:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in Cover Images: cover background art © iStockphoto/Camilo Jimenez; first frame & fourth frame art © iStockphoto/Alex Slobodkin; second frame art © iStockphoto/touc; third frame art © iStockphoto/fonikum; fifth frame art © iStockphoto/pressureUA; frames background © iStockphoto/Robert Churchill. Copyright © 2012 by John Wiley & Sons, Inc. All rights reserved. Published by John Wiley & Sons, Inc., Hoboken, New Jersey. Published simultaneously in Canada. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com Library of Congress Cataloging-in-Publication Data Minoli, Daniel, 1952– Mobile video with mobile IPv6 / Daniel Minoli. p. cm. Includes bibliographical references. ISBN 978-1-118-35497-1 1. Mobile television. 2. Internet Protocol multimedia subsystem. 3. TCP/IP (Computer network protocol) I. Title. TK6678.3.M56 2012 006.696–dc23 2012009802 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 iv
- 8. P1: OTA/XYZ P2: ABC JWBS086-fm JWBS086-Minoli June 27, 2012 10:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in For Anna v
- 9. P1: OTA/XYZ P2: ABC JWBS086-fm JWBS086-Minoli June 27, 2012 10:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in CONTENTS PREFACE xi ABOUT THE AUTHOR xiii 1 THE MOBILE USER ENVIRONMENT: SMART PHONES, PORTABLE MEDIA PLAYERS (PMPs), AND TABLETS 1 1.1 Introduction / 1 1.2 Basic MIPv6 Operation / 3 1.3 Entertainment Video Trends / 10 1.4 Scope of Investigation / 14 Appendix 1.1A: Statistics / 15 Appendix 1.1B: Bibliography / 16 References / 18 2 IPv6 BASICS 19 2.1 Overview and Motivations / 19 2.2 Address Capabilities / 23 2.2.1 IPv4 Addressing and Issues / 23 2.2.2 IPv6 Address Space / 24 2.3 IPv6 Protocol Overview / 29 2.4 IPv6 Tunneling / 37 2.5 IPsec in IPv6 / 40 2.6 Header Compression Schemes / 40 vii
- 10. P1: OTA/XYZ P2: ABC JWBS086-fm JWBS086-Minoli June 27, 2012 10:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in viii CONTENTS 2.7 Quality of Service In IPv6 / 44 2.8 Migration Strategies to IPv6 / 45 2.8.1 Technical Approaches / 45 2.8.2 Residential Broadband Services in an IPv6 Environment / 48 2.8.3 Deployment Opportunities / 50 References / 53 3 MOBILE IPv6 MECHANISMS 55 3.1 Overview / 55 3.2 Protocol Details / 63 3.2.1 Generic Mechanisms / 63 3.2.2 New IPv6 Protocol, Message Types, and Destination Option / 67 3.2.3 Modifications to IPv6 Neighbor Discovery / 74 3.2.4 Requirements for Various IPv6 Nodes / 74 3.2.5 Correspondent Node Operation / 77 3.2.6 Home Agent Node Operation / 82 3.2.7 Mobile Node Operation / 82 3.2.8 Relationship to IPV4 Mobile IPv4 / 86 References / 88 4 ADVANCED FEATURES AND FUNCTIONS OF MIPv6-RELATED PROTOCOLS—PART 1 89 4.1 Network Mobility Basic Support Protocol / 89 4.2 Mobile IPv6 Fast Handovers / 94 4.2.1 General Approach / 94 4.2.2 3G Networks Approach / 102 4.3 Multiple Care-of Addresses Registration / 104 4.3.1 Overview / 104 4.3.2 MIPv6 Extensions / 105 4.4 Mobile Node Identifier Option for MIPv6 / 106 4.5 Mobile IPv6 Management Information Base / 107 4.6 Sockets API For Mobile IPv6 / 109 References / 111 5 ADVANCED FEATURES AND FUNCTIONS OF MIPv6-RELATED PROTOCOLS—PART 2 112 5.1 Dual-Stack MIPv6 / 112 5.2 Hierarchical Mobile IPv6 / 116 5.3 Flow Bindings in Mobile IPv6 and NEMO / 119 5.4 Multihoming Approaches in NEMO / 122
- 11. P1: OTA/XYZ P2: ABC JWBS086-fm JWBS086-Minoli June 27, 2012 10:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in CONTENTS ix 5.5 Bootstrapping MIPv6 Information / 127 5.5.1 Basic Approach / 128 5.5.2 Mobile IPv6 Bootstrapping in Split Scenario / 128 5.6 Diameter Mobile IPv6 / 132 5.6.1 RFC 5447—Authentication Using AAA Infrastructures / 132 5.6.2 RFC 5778—Authentication Using the Internet Key Exchange v2 / 134 5.7 Miscellaneous MIPv6 Capabilities / 137 5.7.1 Mobile IPv6 Vendor Specific Option / 137 5.7.2 MIPv6 Experimental Messages / 137 5.7.3 Service Selection for MIPv6 / 138 References / 139 6 PROXY MOBILE IPv6 141 6.1 Basic Proxy Mechanisms / 144 6.1.1 Proxy Mobile IPv6 Protocol Overview / 145 6.1.2 Signaling Call Flow / 147 6.1.3 PM IPv6 Protocol Security / 149 6.1.4 Messages / 149 6.1.5 Operations / 150 6.1.6 Summary / 153 6.2 Transient Binding / 153 6.2.1 Overview / 153 6.2.2 Use of Transient Binding Cache Entries / 155 6.3 Local Mobility Anchor Discovery / 156 6.4 Localized Routing/Direct Routing / 157 6.5 IPv4 Support for Proxy Mobile IPv6 / 159 6.5.1 Overview / 159 6.5.2 IPv4 Home Address Mobility Support / 162 6.5.3 IPv4 Transport Support / 164 6.5.4 Localized Routing IPv4 Considerations / 166 Appendix 6A: Network-Based Localized Mobility Management / 167 6A.1 Background / 167 6A.2 The Local Mobility Problem / 168 References / 171 7 SECURITY CONSIDERATIONS FOR MIPv6 173 7.1 Using IPsec to Protect MIPv6 Signaling Between Mobile Nodes and Home Agents / 173 7.1.1 Payload Packets / 174 7.1.2 Required Capabilities / 175
- 12. P1: OTA/XYZ P2: ABC JWBS086-fm JWBS086-Minoli June 27, 2012 10:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in x CONTENTS 7.2 MIPv6 Operation with IKEv2 and Revised IPsec Architecture / 176 7.2.1 Packet Formats / 176 7.2.2 Requirements / 176 7.3 Securing Mobile IPv6 Route Optimization Using a Static Shared Key / 181 7.4 Enhanced Security in Route Optimization / 182 7.5 Mobile IPv6 and Firewalls / 185 7.6 Non-IPsec Authentication Protocol For MIPv6 / 185 7.7 IP Address Location Privacy / 186 7.8 Use of Secure Neighbor Discovery / 187 7.9 Authentication, Authorization, and Accounting in MIPv6 / 188 7.10 Diameter Proxy Mobile IPv6 Approaches / 188 References / 189 8 MOBILE VIDEO AND VIDEO STREAMING SERVICES 190 8.1 Overview / 190 8.1.1 Quality of Experience Aspects / 195 8.1.2 QoS Aspects / 204 8.2 3/4G Services and Video Applications / 208 8.2.1 IETF IPv4/Mobile IPv4/IPv6 / 209 8.2.2 Universal Mobile Telecommunications System / 209 8.2.3 Long Term Evolution / 210 8.3 Streaming Protocols and Approaches / 223 8.3.1 Streaming / 223 8.3.2 Content Distribution Networks / 234 8.3.3 P2P Networks / 235 8.3.4 Cloud Computing / 236 8.4 MIPv6 Support in CDMA2000/WiMAX Video Environments / 238 8.5 Other Mobile Video Approaches / 240 8.5.1 ETSI Digital Video Broadcast Handheld / 240 8.5.2 Open Mobile Video Coalition Mobile Digital TV / 245 References / 252 GLOSSARY 255 INDEX 273
- 13. P1: OTA/XYZ P2: ABC JWBS086-bpreface JWBS086-Minoli June 14, 2012 16:58 Printer Name: Yet to Come Trim: 6.125in × 9.25in PREFACE Mobility is clearly the wave of the future. Technology has progressed to a point where users carry powerful devices (smartphones and/or tablets) that enable them to be productive, connected, entertained, and instrumented while on the road, on a train, on a plane, on a boat, or nearly anywhere else. Location-based services (in conjunction with GPS (global positioning system) capabilities) enhance the value and sophistication of applications available to the user. Up to now mobility has been supported using IP Version 4 (IPv4); however, there has been a steady depletion of the pool of available IPv4 address blocks in recent years. By 2011, only about 1 percent of the address space was left, a situation that is, by industry definition, a point of exhaustion. Service providers are now beginning to give serious consideration about the present need to plan a sustained deployment of IPv6 in order to maintain growth and provide customers with new enhanced services in conjunction with the rapid adoption of smartphones. At the same time there has been increased interest in new forms of IP-based video distribution, both in terms of the underlying technology (for example, IPTV, streaming, P2P), and also in terms of the content creation. User-generated video and “for-Web-publishing” of original content, not to mention video on demand and time-shifted video, are seeing greater penetration. Furthermore, end users want to get access to such content not only on their standard or smart (connected) TV, but also on their smartphones, portable media players (PMPs), and tablets. Mobile IPv6 (MIPv6) offers an opportunity to support the evolving consumer paradigm of mobility, productivity, connectivity, entertainment, and instrumentation. This book seeks to explore the technology, protocols, deployment strategies, and approaches to MIPv6-based mobility in general and MIPv6-based mobile video in particular. (Some) operators are now deploying MIPv6 in cellular networks. xi
- 14. P1: OTA/XYZ P2: ABC JWBS086-bpreface JWBS086-Minoli June 14, 2012 16:58 Printer Name: Yet to Come Trim: 6.125in × 9.25in xii PREFACE This text aims at exploring these evolving trends and offering practical suggestions of how these technologies can be implemented in the service provider networks to support cost-effective delivery of entertainment (especially considering the shifts in viewing habits), and how new revenue-generating services could be brought to the market. This is believed to be the first book on MIPv6 with applications to linear and nonlinear video distribution, especially in a mobile context. This work will be of interest to planners, Chief Technology Officers (CTOs), and engineers at broadcast TV operations, cable TV operations, satellite operations, Internet and Internet service providers (ISPs), telcos, and wireless providers, both domestically and in the rest of the world. Also, it will be of interest to set-top box developers, storage vendors, content developers, content distribution outfits, and content aggregators. The author acknowledges the fundamental contributions made by all the authors of the many Requests for Comments (RFCs) cited and summarized in this book, which form the technical basis for MIPv6; this book and reportage can be seen as advocacy for deployment of the technology, as a dénouement of all such technical work done by these professionals in past 8 years.
- 15. P1: OTA/XYZ P2: ABC JWBS086-babout JWBS086-Minoli May 21, 2012 16:15 Printer Name: Yet to Come Trim: 6.125in × 9.25in ABOUT THE AUTHOR Among other activities, Mr. Minoli has done extensive work in video engineering, design, and implementation over the years. The results presented in this book are based on foundation work done while at Telcordia, NYU, Stevens Institute of Technology, Rutgers University, ATT, and other engineering firms, starting in the early 1990s and continuing to the present. Some of his video work has been documented in books he has authored, including: r Linear and Non-Linear Video and TV Applications Using IPv6 and IPv6 Multi- cast (Wiley 2012); r 3D Television (3DTV) Content Capture, Encoding, and Transmission – Building the Transport Infrastructure for Commercial Services (Wiley, 2010); r 3D Television (3DTV) Technology, Systems, and Deployment – Rolling out the Infrastructure for Next-Generation Entertainment (Francis and Taylor, 2010); r IP Multicast with Applications to IPTV and Mobile DVB-H (Wiley/IEEE Press, 2008); r Video Dialtone Technology: Digital Video over ADSL, HFC, FTTC, and ATM (McGraw-Hill, 1995); and, r Distributed Multimedia through Broadband Communication Services (co- authored) (Artech House, 1994). Mr. Minoli has many years of technical-hands-on and managerial experience in planning, designing, deploying, and operating IP/IPv6-, telecom-, wireless-, satellite- and video networks, and data center systems and subsystems for global best-in-class carriers and financial companies. He has worked on advanced network deployments xiii
- 16. P1: OTA/XYZ P2: ABC JWBS086-babout JWBS086-Minoli May 21, 2012 16:15 Printer Name: Yet to Come Trim: 6.125in × 9.25in xiv ABOUT THE AUTHOR at financial firms such as AIG, Prudential Securities, Capital One Financial, and service provider firms such as Network Analysis Corporation, Bell Telephone Labo- ratories, ITT DTS/Worldcom, Bell Communications Research (now Telcordia), ATT, Leading Edge Networks Inc., SES, and other institutions. In the recent past, Mr. Mi- noli has been responsible for the development and deployment of IPTV systems, terrestrial and mobile IP-based networking services, and IPv6 services over satellite links. He also played a founding role in the launching of two companies through the high-tech incubator Leading Edge Networks Inc., which he ran in the early 2000s: Global Wireless Services, a provider of secure broadband hotspot mobile Internet and hotspot VoIP services; and, InfoPort Communications Group, an optical and Giga- bit Ethernet metropolitan carrier supporting data center/SAN/channel extension and cloud network access services. For several years he has been session-, tutorial-, and now overall technical program Chair for the IEEE ENTNET (Enterprise Network- ing) conference; ENTNET focuses on enterprise networking requirements for large financial firms and other corporate institutions. Mr. Minoli has also written columns for ComputerWorld, NetworkWorld, and Network Computing (1985–2006). He has taught at New York University (Informa- tion Technology Institute), Rutgers University, and Stevens Institute of Technology (1984–2006). Also, he was a technology analyst at-large, for Gartner/DataPro (1985– 2001); based on extensive hands-on work at financial firms and carriers, he tracked technologies and wrote CTO/CIO-level technical scans in the area of telephony and data systems, including topics on security, disaster recovery, network management, LANs, WANs (ATM and MPLS), wireless (LAN and public hotspot), VoIP, network design/economics, carrier networks (such as metro Ethernet and CWDM/DWDM), and e-commerce. Over the years he has advised Venture Capitals for investments of $150M in a dozen high-tech companies. He has acted as Expert Witness in a (won) $11B lawsuit regarding a VoIP-based wireless air-to-ground radio communication system for airplane in-cabin services, and has been engaged as a technical expert in a number of patent infringement proceedings in the digital imaging and VoIP space supporting legal firms such as Schiff Hardin LLP, Fulbright Jaworski LLP, Dimock Stratton LLP/ Smart Biggar LLP, and Baker McKenzie LLP, among others.
- 17. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in CHAPTER 1 THE MOBILE USER ENVIRONMENT: SMART PHONES, PORTABLE MEDIA PLAYERS (PMPs), AND TABLETS 1.1 INTRODUCTION Mobile connectivity is becoming ubiquitous for voice, video, and data. A significant percentage of people now carry powerful smartphones and/or tablets that enable them to be productive, connected, entertained, and instrumented while on the move, away from their offices or homes. Clearly, there has been an evolution over time for people on the move, from being able to get “nothing” (up to mid-1980s), to being able to get voice (since the mid-1980s), to getting data (such as e-mails) (mostly from the mid- 1990s), to accessing applications (data and location-based applications) (mostly since the early 2000s), and now also to get real-time and/or streaming and/or on-demand video. According to recent Nielsen data, over 28 million people in the U.S. watched video content on their mobile phones in 2011, with a large (40 percent) increase from 2010; monthly usage of video exceeds 4 hours, as documented in Appendix 1.1A. The network fabric has transitioned from analog, to digital (time-division multi- plexing), to packet technology, especially using voice over IP (VoIP) for voice and using IP version 4 (IPv4) for applications. However, in recent years, there has been a steady depletion of the pool of available IPv4 address blocks; a point of exhaustion was reached in 2011, when only 1 percent of the address space remained available. Service providers are now, of necessity, planning to give serious consideration to the imminent rollout of IP version 6 (IPv6) infrastructures, to parallel the existing IPv4 infrastructure, in order to maintain growth and provide customers with new enhanced services. Mobile IPv6 (MIPv6) is a version of IPv6 that intrinsically supports active, Mobile Video with Mobile IPv6, First Edition. Daniel Minoli. C 2012 John Wiley Sons, Inc. Published 2012 by John Wiley Sons, Inc. 1
- 18. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in 2 THE MOBILE USER ENVIRONMENT real-time device movement across a wide geography (it supports a concept similar to mobile IP in the version 4 world, but with added capabilities). MIPv6 allows mobile nodes (MNs) to maintain persistent IP connectivity while the MN moves around in an IPv6 network. It has been adopted in 3G code division multiple access (CDMA) networks for handling host-based mobility management, specifically as a way to maintain connectivity when the MN moves between access routers (ARs). In addition to the basic set of initial MIPv6 protocols, several enhancements have been added in the past few years. At the same time there has been increased interest in new forms of IP-based video distribution, both in terms of the underlying streaming or IP television (IPTV) and/or content distribution networks (CDNs) technology, as well as in terms of the content providers and content creation itself. User-generated video (UGV), “for Web publish- ing” of original content, video on demand (VoD), and time-shifted video, are seeing steady market penetration. Consumers expect to be able to get access to such content not only on their standard or smart (connected) TV, but also on their smartphones, portable media players (PMPs), and tablets. MIPv6 offers an ideal opportunity to support the evolving consumer paradigm of mobility, productivity, connectivity, en- tertainment, and instrumentation. It follows that there is interest on the part of service providers to explore the technology, protocols, deployment strategies, and approaches to IPv6-based mobility in general, and IPv6 mobile video in particular. MIPv6 allows session (e.g., Transmission Control Protocol (TCP) session) continuity—while some video applications utilize User Datagram Protocol (UDP), other video applications do use TCP. The types of content that people typically get with a mobile video device include entertainment (nonlinear video such as music videos, short clips from YouTube/Web TV, and so on) and real-time information (linear video such as breaking news, emer- gency reports, weather, local/regional news, live events as they happen, and traffic) [1]. One should keep in mind that there are no substitutes for entertainment1 (one needs a video stream), but there are substitutes for news/weather/traffic information: one might simply look at the home page of CNN, FNC, TWC, and so on, to get that type of information via traditional Web browsing—video may or may not actually be required in all these instances. Besides MIPv6, there are a number of ways to deliver video to a mobile de- vice including but not limited to—European Telecommunications Standards Institute (ETSI) Digital Video Broadcast Handheld (DVB-H), International Telecommunica- tion Union—Telecommunications (ITU-T) IPTV, Internet Engineering Task Force (IETF) IPv4, IETF Mobile IPv4 (MIP), IETF IPv6, Open Mobile Video Coalition (OMVC) mobile digital TV, and vendor-proprietary methods. Each of these methods has advantages and disadvantages. This investigation focuses mostly on MIPv6; we believe to be the first textbook on this topic. An overview of the approach and capa- bilities afforded by MIPv6 is provided in this introductory chapter. The chapters that follow expand in greater details the concepts introduced herewith. 1We exclude videogames in this discussion.
- 19. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in BASIC MIPv6 OPERATION 3 1.2 BASIC MIPv6 OPERATION For video distribution, as well as for other applications to smartphones and similar devices, there is a desire to support direct communication between MNs (also known as mobile hosts) and far-end destinations, whether such far ends are themselves a stationary node or another MN. Such far end destination could be, for example, a video streaming service provider. In order to efficiently maintain reachability, thus supporting flexible mobility, the goal is to retain the same explicit IP address regard- less of the real-time location or specific network elements and/or networks used to support connectivity. This is not easily achievable with IPv4 for a number of rea- sons; however, MIPv6 described in Request for Comments (RFC) 3775, “Mobility Support in IPv6” (June 2004), among others2 , facilitates this task. RFC 3775 is known as the “MIPv6 base specification.” RFCs are specifications and related ma- terials published by the IETF. IPv6 mobility, specifically MIPv6, relies on IPv6 capabilities. RFC 3775 notes that without specific support for mobility in IPv6, packets destined to an MN would not be able to reach it while the MN is away from its home network. In order to continue communication in spite of its movement, an MN could change its IP address each time it moves to a new link, but the MN would then not be able to maintain transport and higher-layer connections when it changes location. Mobility support in IPv6 is particularly important, as mobile users are likely to account for a majority, or at least a substantial fraction, of the population of the Internet during the lifetime of IPv6. MIPv6 allows nodes to remain reachable while moving around in the IPv6 Internet: it enables a device to change its attachment point to the Internet without losing higher-layer functionality through the use of tunneling between it and a designated home agent (HA). Stated another way, MIPv6 enables an MN to maintain its connectivity to the Internet when moving from one AR to another, a process referred to as handover. Figure 1.1 depicts some of the elements involved in IPv6 mobility and their basic functionality. IPv6 was originally defined in RFC 1883 but was then obsolete by RFC 2460, “Internet Protocol, Version 6 (IPv6) Specification,” authored by S. Deering and R. Hinden (December 1998). A large body of additional RFCs has emerged in recent years to add capabilities and refine the IPv6 concept. IPv6 embodies IPv4 best practices but removes unused or obsolete IPv4 characteristics; this results in a better- optimized Internet protocol. Some of the advantages of IPv6 include the following: r Scalability and expanded addressing capabilities: IPv6 has 128-bit addresses versus 32-bit IPv4 addresses. With IPv4, the theoretical number of available IP addresses is 232 ∼ 1010 . IPv6 offers a much larger 2128 space. Hence, the number of available unique node addressees is 2128 ∼ 1039 . IPv6 has more than 340 undecillion (340,282,366,920,938,463,463,374,607,431,768,211,456) addresses, grouped into blocks of 18 quintillion addresses. 2See Appendix 1B for a more inclusive listing of MIPv6 RFCs.
- 20. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in 4 THE MOBILE USER ENVIRONMENT Home agent Home network MN Mobile node Interconnecting network (e.g., Internet) An IPv6-enabled router that maintains an association between the MN’s “home address” and its “care-of address” while “away from home” An IPv6 Host that maintains network connectivity using its “home address,” regardless of which link (or network) it is connected to Foreign network FN Access router (AR): The MN’s default router Destination IPv6 Host in Session with an MN Correspondent node CN HA MN FIGURE 1.1 Basic MIPv6 Environment r “Plug-and-play”: IPv6 includes a “plug-and-play” mechanism that facilitates the connection of equipment to the network. The requisite configuration is automatic; it is a serverless mechanism. r Security: IPv6 includes security in its specifications such as payload encryption and authentication of the source of the communication. End-to-end security, with built-in strong IP-layer encryption and authentication (embedded security support with mandatory IP Security (IPsec) implementation) is supported. In MIPv6 each MN is always identified by its “home address,”3 regardless of its current point of attachment to the Internet; namely, an MN is always expected to be addressable at its home address whether it is currently attached to its home link or is away from home. The home address is an IPv6 address assigned to the MN within its home subnet prefix on its home link. While an MN is at home, packets addressed to its home address are routed to the MN’s home link [2]. While situated away from its home, an MN is also associated with an “in-care of” address (CoA) that provides information about the MN’s current location. IPv6 packets addressed to an MN’s home address are transparently routed to its CoA. A CoA is an IPv6 address associated with an MN that has a subnet prefix from a particular foreign link. The protocol enables IPv6 nodes to cache the binding of an MN’s home address with its CoA, and then to send any packets destined for the 3The acronym HoA is used by some; we do not.
- 21. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in BASIC MIPv6 OPERATION 5 TABLE 1.1 Basic MIPv6 Glossary Concept Definition Care-of address (CoA) IPv6 address of mobile node (MN) at its current Internet attachment point. Correspondent node (CN) An IPv6 device that is communicating with a mobile node (MN in MIPv6) or a mobile network node (MNN in NEMO), using MIPv6 techniques. Home agent (HA) Host, specifically a router, on the Home Network that enables the mobile node (MN in MIPv6) or the mobile network node (MNN in NEMO) to roam (i.e., being “away from home”). Home network (HN) The network that a mobile node (MN in MIPv6) or mobile network node (MNN in NEMO) belongs to when it is not roaming (when it is at home). That is, the network that is associated with the network link of the HA. Mobile IPv6 (MIPv6) An IP protocol, specifically utilizing IPv6 and described in RFC 3775 that offers direct communication between MNs and far-end destinations while retaining the same explicit IP address regardless of the real-time location or specific network elements and/or networks used to support connectivity. Mobile network node (MNN) (NEMO concept.) Any IPv6 device on a mobile network. MNNs may be permanently associated (connected) to the mobile network or visiting the mobile network as mobile/roaming nodes; they do not need to be aware of the network’s mobility. Mobile node (MN) An IPv6 device capable of changing its attachment point to the Internet while maintaining higher layer connectivity through mobility functionality. Mobile router (MR) (NEMO concept.) A router capable of changing its point of attachment to the Internet without disrupting higher layer connections of attached devices. Network mobility (NEMO) basic support protocol An extension to MIPv6 described in RFC 3963 that enables mobile network nodes (MNNs) to attach to different points in the Internet while allowing session continuity for every node in the mobile network, even as the network moves. MN directly to it at this CoA. To support this operation, MIPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with MNs. Table 1.1 provides a basic glossary of key MIPv6 terms; refer to the Glossary for a more extensive list. The basic apparatus MIPv6 is as follows. Communications must be maintained (e.g., TCP sessions) while the MN is physically moving and is “away from home.” To do this, a globally unique, explicit IPv6 address, the home address just discussed, is assigned to every MN; an MN is always reachable on its home address. This address
- 22. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in 6 THE MOBILE USER ENVIRONMENT enables the MN to be identified by the far-end node, known as correspondent node (CN). Besides the HA, any other node communicating with an MN is referred to as a CN. While away from home, an MN obtains the CoA that is typically provided via autoconfiguration. Summarizing this discussion, IPv6-based mobility makes use of two IP addresses per mobile host: 1. One permanent IP address (also known, as noted, as the “home address”) is used for identification 2. Another IP address that changes depending on the current location the MN (called, as noted, the care-of address or CoA) is used for routing. The association between an MN’s home address and the CoA is known as a “binding” for the MN. While away from home, an MN registers its primary CoA with a well-known location, a router on its home link, thus requesting this router to function as the HA for the MN. The MN performs this binding registration by sending a “binding update (BU)” message to the HA (see Figure 1.2). The HA is and/or acts as a router, a device that forwards IP packets not explicitly addressed to itself; hence, the HA is used to support connectivity on the “upstream link” (MN to CN). On the “downstream link” (CN to MN), the CN performs packet routing toward the MN using the routing header. The CN learns the position of an MN by processing BUs. The CN is able to “put” and/or “get” BUs in or from the binding cache. The MN receives router advertisements that specify the prefix of the visited remote locations. The MN then appends the prefix to its interface ID. The HA (a router in the MN’s home network) supports the following functions (also see Figure 1.3): r Intercept packets that arrive at the MN’s home network and whose destination address is its HA r Tunnel (i.e., provide IPv6 encapsulation) these packets to the MN r Provide reverse tunneling from the MN to the CN MNs can provide information about their current location to CNs, again using BUs and binding acknowledgments (BAs). In addition, return-routability test is performed between the MN, HA, and the CN in order to authorize the establishment of the binding. Packets between the MN and the CN are either tunneled via the HA, or sent directly if a binding exists in the CN for the current location of the MN. In MIPv6, IPsec is specified as the means of securing signaling messages between the MN and HA. MIPv6 tunnels payload packets between the MN and the HA in both directions; this tunneling uses IPv6 encapsulation methods; where these tunnels need to be secured, they are replaced by IPsec tunnels. MIPv6 is a native extension of IPv6; MIPv6 is seen by some as an application that can, in fact, foster the broader deployment of IPv6 [3]. MIPv6 is a mature protocol with several implementations across the industry that have undergone interoperability testing [4].
- 23. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in BASIC MIPv6 OPERATION 7 Top: single CoA included in binding cache per RFC 3775 Bottom: multiple CoAs included in binding cache per RFC 5648 Binding cache database: correspondent node’s binding Binding cache database: home agent’s binding binding [2001:db8: :EUI BID1 CoA1] binding [2001:db8: :EUI BID2 CoA2] binding [2001:db8: :EUI BID3 CoA3] binding [2001:db8: :EUI BID1 CoA1] binding [2001:db8: :EUI BID2 CoA2] binding [2001:db8: :EUI BID3 CoA3] (Proxy neighbor advertisement is active) BID: binding identification number CN HA Home link Internet MN CoA2 CoA1 CoA3 Internet Home link Binding cache database: correspondent node’s binding binding [2001:db8: :EUI CoA1] Binding cache database: home agent’s binding binding [2001:db8: :EUI CoA1] HA MN CN CoA2 CoA1 CoA3 FIGURE 1.2 CoA Registration MIPv6 makes use of the header structure as defined originally in RFC 2460 and adds a new extension header, specifically a mobility header; this entails a new routing header type and a new destination option. IPv6 extension headers are optional headers that may follow the basic IPv6 header. An IPv6 protocol data unit (PDU) may include zero, one, or multiple extension headers; when multiple extension headers are used, they form a chained list of headers identified by the Next Header field of the previous header. Figure 1.4 depicts the IPv6 packet with some header extensions. The extension header is utilized by the CN, the MN, and the HA in all the communication transmissions for the bindings. Figure 1.5 depicts the mobility header for MIPv6.
- 24. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in 8 THE MOBILE USER ENVIRONMENT Foreign network Home network HA Home agent Internet Data BU Data Correspondent node MN Foreign network FIGURE 1.3 Communication Supported through the HA Network mobility (NEMO) basic support protocol as described in RFC 3963 pro- vides additional mobility capabilities. NEMO basic support protocol enables mobile networks (or more specifically mobile network nodes) to attach to different points in the Internet. The protocol is an extension of MIPv6 and allows session continuity for every node in the mobile network as the network moves; it also allows every node in the mobile network to be reachable while moving around. NEMO basic aims at pro- viding continuous Internet connectivity to nodes located in an IPv6 mobile network: an example could be an in-vehicle embedded IP network in a train, bus, airplane, that supports multiple users (say via a WiFi in-vehicle connection). The mobile router (MR), which connects the network to the Internet, runs the NEMO basic support protocol with its HA. The protocol is designed so that network mobility is transpar- ent to the nodes inside the mobile network [5]. Typically, MR implement NEMO functionality for achieving network mobility; however, an MR may also function as an MN. Hence, in summary, NEMO is an extension to the MIPv6 protocol that facilitates the movement of an entire network. In addition, extensions to MIPv6 and NEMO standards have been offered that allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the HA. These extensions also allow the MN to roam over both IPv6 and IPv4, including the case where network address translation4 (NAT) is present on the path between the MN and its HA. 4The term network address translator is also used.
- 25. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in BASIC MIPv6 OPERATION 9 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 1 2 3 4 5 6 7 8 9 0 Version(4) Traffic class (8) Flow label (20) Hop limit (8) Next header (8) Payload length (16) Source address (128 bits) Destination address (128 bits) Hop-by-hop Ext. Header Dest. Options Ext. Header Routing Ext. Header Authentication Ext. Header Encapsul. Sec. Ext. Header Dest. Options Ext. Header 1 2 3 4 5 6 7 8 9 FIGURE 1.4 Typical IPv6 Protocol Data Unit Next Header = Mobility header Mobility header Next Header Checksum Message data MH Type Hdr Ext Length Mobility header type – Binding refresh request message – Home Test Init message (HoTI) – Home Test message (HoT) – Care-of Test Init message (CoTI) – Care-of Test message (CoT) – Binding update message (BU) – Binding acknowledgment message (BA) – Binding error message (BE) Message data field contains mobility options – Binding refresh advice – Alternate care-of address – Nonce indices – Binding authorization data Reserved FIGURE 1.5 MIPv6 Mobility Header
- 26. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in 10 THE MOBILE USER ENVIRONMENT Another extension has also recently been advanced. As we have (implicitly) noted, MIPv6 requires client functionality in the IPv6 stack of an MN. Exchange of signaling messages between the MN and HA enables the creation and maintenance of a binding between the MN’s home address and its CoA. Mobility as specified MIPv6 requires the IP host to send IP mobility management signaling messages to the HA, which is located in the network. Network-based mobility is another approach to solving the IP mobility challenge. It is possible to support mobility for IPv6 nodes without host involvement by extending MIPv6 signaling messages between a network node and an HA. This approach to supporting mobility does not require the MN to be involved in the exchange of signaling messages between itself and the HA. A proxy mobility agent in the network performs the signaling with the HA and does the mobility management on behalf of the MN attached to the network. Because of the use and extension of MIPv6 signaling and HA functionality, this protocol is referred to as Proxy Mobile IPv6 (PMIPv6), defined originally in RFC 5213. Network deployments that are designed to support mobility would be agnostic to the capability in the IPv6 stack of the nodes that it serves. IP mobility for nodes that have mobile IP client functionality in the IPv6 stack as well as those nodes that do not, would be supported by enabling PMIPv6 protocol functionality in the network [6]. These various mobility capabilities will be explored in this text. 1.3 ENTERTAINMENT VIDEO TRENDS Mobile video is one of a number of forces that are expected to reshape the video dis- tribution and consumption environments during this decade. Besides mobile video, major other drivers for this evolution include (i) new viewing habits such as time shift- ing for nonlinear and on-demand content consumption, (ii) new distribution channels (effectively, new content providers, especially Internet based, along with new trans- port mechanism such as streaming), (iii) new technologies, and, (iv) standardization of IP-based delivery, especially in conjunction multicast-based IPTV networks and/or with web-based content downloading and social networks. New viewer paradigms are evolving related to consumption of entertainment video and TV programming that can be summarized as “anywhere, anything, anytime, any platform”; namely, “from any source, any content, in any (encoded) form, at any time, on any user-chosen device, consumed at any location.” Mobile video is an example of the new paradigm. Game-changing shifts are also seen on the home front. For exam- ple, many new stationary TV sets on the market that now have Ethernet networking connections built directly into the set and require no additional equipment or set-top boxes (STBs) for accessing the Internet; also, many high-end TVs already come with the ability to conduct video calls. In the view of some industry observers these viewer habits, technologies, and approaches will play a part in eventually, perhaps, supplant- ing broadcast and cable television with Internet programming and distribution. We previously referred to this new paradigm as nontraditional TV (NTTV); new viewer approaches include, but are not limited to the following [7]: r Watching entertainment/news using the Internet (such as a TV show, a movie, or a short clip)
- 27. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in ENTERTAINMENT VIDEO TRENDS 11 r Watching a multicast (rather than broadcast) entertainment/news program r Watching a VoD program (such as a movie or pay-per-view event) (VoD is also known as content on demand (CoD)) r Watching time-shifted TV (TSTV) ◦ Utilizing home-based hardware, or ◦ Utilizing network-based hardware r Watching entertainment/news with a mobile smartphone, a PDA (personal dig- ital assistant), a videogame console (e.g., the Microsoft Xbox 360 and Sony PlayStation 3), a tablet screen (e.g., Amazon Kindle Fire/Apple iPad/BN Nook), or a device in a car or in a yacht r Watching user-generated content (UGC), particularly utilizing social networks Some basic service definitions follow: r Internet television (also known as Internet TV, Online TV) is a television service distributed via the Internet by streaming, as exemplified by services such as Hulu (mostly but not exclusively for US content) and BBC iPlayer (mostly but not exclusively for UK content). The content is typically commercially produced TV material, but the “transmission/distribution” channel is the Internet; the “transmission/distribution” also includes network-resident storage (supported by video servers). Internet TV content is delivered over the open Internet as the term implies (not over a dedicated IP network). Content providers can reach consumers directly, regardless of the carrier or carriers providing the Internet backbone connectivity or Internet access. Video content is accessible from any Internet-ready computer device and is accessible around the world—a consumer does use STBs, although, as noted, increasingly TV sets and STBs have direct Internet connections themselves. Video content is now increasingly available on the Internet. In the past, Internet TV has suffered from low quality; this limitation is now being progressively overcome due to greater bandwidth availability in the Internet core and in the consumer’s access subnetwork. Some approaches also use peer-to-peer (P2P) protocols. r Web television (Web TV, also known as web video) is a genre of digital enter- tainment distinct from traditional television: in Web TV the content is created specifically for first viewing on the Internet (via broadband access and/or on mobile networks). Web television shows, or Web series, are original episodic shorts (2–9 min per episode at press time, although longer episodes may ap- pear in the future). Web television networks included the following at press time (however, some of these also post TV-originated material): the WB.com5 , MySpace, YouTube, Blip.tv, HuLu, and Crackle. r Time-shifted TV. A service or capability that allows the consumer to watch a TV program originally as a broadcast, cable, satellite, or IPTV transmission, that 5Companies named in this text are simply illustrative examples of entities that may offer technologies and services under discussion at point in the text; named companies are generally not the only suppliers that may provide such services, and mention of a company and/or service does not imply that such entities or capabilities are recommended herewith, or considered in any way better than others.
- 28. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in 12 THE MOBILE USER ENVIRONMENT has been time shifted. The time shift service has two flavors. In a basic flavor, the user can preplan the recording of a scheduled TV program (using a local user-owned device, a local cable-provided device, or a remote network-based device—this approach being ideal for mobile environments); the user can watch the program any time later, while still being able to pause, rewind, and resume the playout. Some systems allow the user to skip commercial advertisements during playback. In a more advanced flavor, the service allows a user to halt a scheduled content service in real time and allows the user to continue watching the program later, by providing buffering for pause, rewind, and resume functions. Some refer to TSTV as “catch-up TV,” being that it allows consumers to watch a broadcaster’s program at their own convenience. Hence, TSTV implies the capture of (what was) a live TV program, either by a customer device or a user- programmable network-resident device, for playback within a relatively short time (up to a few days). Time shifting does not include, in our definition, VoD downloads of a commercially packaged video clip from a cable TV provider or from an Internet site. r IPTV is a framework and architecture that, when instantiated in an ac- tual network, supports efficient distribution of (targeted) multimedia services such as television/video/audio/text/graphics/data. The content is delivered over IP-based networks (these being IPv4-based and/or IPv6-based, instead of being traditional cable based) that are tightly managed to support the required level of quality of service/quality of experience (QoS/QoE), security, interactivity, and reliability. Its services are provided to customers via a subscription mechanism very similar to traditional cable TV service. Collectively we refer to the first two approaches listed above as Internet-based TV (IBTV). Internet-based devices that support IBTV viewing are becoming more popular, ranging for stationary systems from hybrid Internet-ready STBs and digital video recorders (DVRs), to Home theater PCs (HTPCs) (that obviously are Internet ready), to Internet-ready TV sets. An HTPC is a converged device that combines a personal computer with a software application that supports video playback; the HTPC unit is typically colocated with a home entertainment system. On the other hand, new Internet-ready TV sets bypass the PC altogether and access the Internet directly; these sets support the concept of “connected TV (CTV)”; CTVs are also known in some circles as “smart TVs.” By the end of 2015, more than 500 million Internet-connected TVs are expected to be in people’s homes. Netflix® , Amazon, and Apple are (reportedly) “banking” on the idea that the Internet in general, and cloud computing services in particular, are going to be a game changer for home entertainment and that the TV screen can be seen as a “big iPad.”6 6The examples of commercial services and service providers identified at various points throughout this text are intended only to depict what we believe to be persistent technical/usage trends. Some of these service, providers, or products may disappear—yet other will emerge. Hence, we believe that the general trends discussed here, as a whole, will persist and prevail.
- 29. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in ENTERTAINMENT VIDEO TRENDS 13 (Some) operators are already deploying MIPv6 in cellular networks. One example of such networks is CDMA-based networks as defined in the 3GPP2 X.S0011-002-D specification [8]. Mobile WiMAX (worldwide interoperability for microwave access), which is based on IEEE 802.16e, also specifies in the network architecture the use of MIPv6 [9]. Hence, our interest on a text that addresses this topic. Industry observations such as this one [10] describe some of the important issues that have to be taken into account by stakeholders: In the last few years, there has been a tremendous increase in mobile video content generation and delivery. This trend has forced the service providers to understand the limitations of the current wired and wireless networks (Internet, WiFi, 3G/4G cellu- lar) and bring new technologies for delivering the video content to the end-user. Last mile access technologies play a crucial role in determining the overall performance and end-user experience of multimodal applications; diverse approaches and technologies (WiMAX, LTE) have recently gained momentum to address this issue. Moreover, of- fering high quality mobile video services on resource-constrained and heterogeneous mobile devices with varying display sizes, processing powers, network conditions, and battery levels opens up many new challenges. Recent developments such as social me- dia production, multimodal sensing and context technologies, will have an impact on mobile video applications. In fact, supporting a broad spectrum of video-centric appli- cations such as live video streaming, VoD, video games and virtual environments, . . . , multimedia conferencing and telepresence, surveillance, sensing and social media on mobile devices demands application-specific techniques that adapt to the underlying network and device architectures. According to the Cisco Visual Networking Index (VNI) Global Mobile Data Traffic Forecast for 2011 to 2016, worldwide mobile data traffic will increase 18-fold over the next 5 years, reaching 10.8 exabytes per month by 2016. The increase in mobile traffic is due to a projected surge in the number of mobile Internet-connected devices, which will exceed the number of people on earth, estimated by then at 7.3 billion. During 2011−2016, Cisco anticipates that global mobile data traffic will outgrow global fixed data traffic by three times. The forecast predicts an annual run rate of 130 exabytes of mobile data traffic; this increase represents a compound annual growth rate (CAGR) of 78 percent spanning the forecast period. The following trends are driving these significant increases [11]: r More streamed content: With the consumer expectations increasingly requiring on-demand or streamed content versus simply downloaded content, mobile cloud traffic will increase, growing 28-fold from 2011 to 2016, a CAGR of 95 percent. r More mobile connections: There will be more than 10 billion mobile Internet- connected devices in 2016. r Enhanced computing of devices: Mobile devices are becoming more powerful and thus able to consume and generate more data traffic. Tablets are expected to be generating traffic levels that will grow 62-fold from 2011 to 2016—the
- 30. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in 14 THE MOBILE USER ENVIRONMENT TABLE 1.2 Bandwidth Trends for Mobile Devices 2011 2012 2013 2014 2015 2016 CAGR Average mobile connection speed (Kbps) 315 504 792 1,236 1,908 2,873 56% Average smartphone connection speed (Kbps) 1,344 1,829 2,425 3,166 4,102 5,244 31% highest growth rate of any device category tracked in the forecast. The amount of mobile data traffic generated by tablets in 2016 (1 exabyte per month) will be four times the total amount of monthly global mobile data traffic in 2010 (237 petabytes per month). r Faster mobile speeds: Mobile network connection speed is a key enabler for mobile data traffic growth. More speed means more consumption, and Cisco projects mobile speeds (including 2G, 3G and 4G networks) to increase ninefold from 2011 to 2016. r More mobile video: Mobile users want the best experiences they can have and that generally means mobile video, which will comprise 71 percent of all mobile data traffic by 2016. The Cisco study also projects that 71 percent of all smartphones and tablets (1.6 billion) could be capable of connecting to an IPv6 mobile network by 2016. From a broader perspective, 39 percent of all global mobile devices (more than 4 billion) are expected to be IPv6-capable by 2016. The following regions are experiencing the greatest growth: r Middle East and Africa will have the highest regional mobile data traffic growth rate with a CAGR of 104 percent, or 36-fold growth. r Asia-Pacific will have an 84 percent CAGR, or 21-fold growth. r Central and Eastern Europe will have an 83 percent CAGR, or 21-fold growth. r Latin America will have a 79 percent CAGR, or 18-fold growth. r North America will have a 75 percent CAGR, or 17-fold growth. r Western Europe will have a 68 percent CAGR, or 14-fold growth. The average mobile connection speed is expected to increase ninefold by 2016; mobile connection speeds are a key factor in supporting and accommodating mobile data traffic growth (see Table 1.2). 1.4 SCOPE OF INVESTIGATION This book aims at exploring these evolving trends, including mobile video trends. It also aims at and offering practical suggestions of how these technologies can
- 31. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in APPENDIX 1.1A: STATISTICS 15 be implemented in the service provider networks to support cost-effective delivery of entertainment, especially considering the shifts in viewing habit, and how new revenue-generating services could be brought to the market. Chapter 2 provides some IPv6 basics. Chapter 3 provides an overview of MIPv6 protocols, approaches, and technologies. Chapters 4 and 5 describe some more advanced extensions and capabilities that may be of interest to developers. Chapter 6 looks at the capabilities offered by PMIPv6. Chapter 7 addresses security considerations in MIPv6. Chapter 8 looks at some alternative mobile video technologies and also video streaming services, including 3/4G services; finally it assesses MIPv6 support in video environments along with implementations and future directions. This is believed to be the first book on MIPv6 with applications to linear and nonlinear video distribution. This work will be of interest to planners, CTOs, and engineers at broadcast TV operations, cable TV operations, satellite opera- tions, Internet and ISP providers, telcos, and wireless providers, both domestically and in the rest of the world. Also, it will be of interest to set top box develop- ers, storage vendors, content developers, content distribution outfits, and content aggregators. We are not implying in this text that IPv6 and/or MIPv6 is strictly and uniquely required to support IP-based mobile video; we are advocating, however, that that platforms based on these protocols provide an ideal, future-proof, and scalable envi- ronment for such evolving content-delivery services. APPENDIX 1.1A: STATISTICS This appendix provides some recent basic background data that supports the as- sertions made earlier in the chapter about the growing importance of mobile video consumption, as actually measured, not forecast, at press time. The data is summa- rized from data published by Nielsen Company [12]. Table 1.A1 provides overall usage by population, while Table 1.A2 depicts actual hours of usage by service category. TABLE 1.A1 Overall Usage—Number of Users 2+ (in 000s)—Monthly Reach Q1, 2011 Q1, 2010 Yr to Yr Difference (%) Watching TV in the home 288,500 286,225 0.8 Watching time-shifted TV (all TV homes) 107,065 94,599 13.2 Using the Internet on a computer 190,913 191,301 −0.2 Watching video on Internet 142,437 135,855 4.8 Using a mobile phone 231,000 229,495 0.7 Mobile subscribers watching video on a mobile phone 28,538 20,284 41.0
- 32. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in 16 THE MOBILE USER ENVIRONMENT TABLE 1.A2 Monthly Time Spent in H:Min—Per User 2+ Q1, 2011 Q1, 2010 Yr to Yr Difference (%) Yr to Yr Difference (H:Min) Watching TV in the home 158:47 158:25 0.2 0:22 Watching time-shifted TV (all TV homes) 10:46 9:36 12.2 1:10 DVR playback (only in homes with DVRs) 26:14 25:48 1.7 0:26 Using the Internet on a computer 25:33 25:54 −1.4 −0:21 Watching video on Internet 4:33 3:23 34.5 1:10 Mobile subscribers watching video on a mobile phone 4:20 3:37 20.0 0:43 APPENDIX 1.1B: BIBLIOGRAPHY There were only three books on IPV6 mobile, although there were around 40 RFCs on the topic as of press time, comprising hundreds of pages of key technical material of possible interest to readers and implementers (without counting the numerous other IPv6 RFCs). These books do not focus on video applications, as we do here. Also, a number of (major) developments have taken place since these books were first written and/or published. r Qing Li, Tatuya Jinmei, and Keiichi Shima, Mobile IPv6: Protocols and Imple- mentation, Morgan Kaufmann, Google eBook, 2009. r Rajeev S. Koodli and Charles E. Perkins, Mobile inter-networking with IPv6: Concepts, Principles, and Practices, John Wiley Sons, 2007. r Hesham Soliman, Mobile IPv6: Mobility in a Wireless Internet, Addison-Wesley, 2004. MIPv6 RFCs are listed below. This text provides a complete summary of all these RFCs. IETF RFC Title/Topic RFC 3775 Mobility Support in IPv6, June 2004 (Standards Track). RFC 3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents, June 2004 (Standards Track) (updated by RFC 4877). RFC 3963 Network Mobility (NEMO) Basic Support Protocol, January 2005 (Standards Track). RFC 4068 Fast Handovers for Mobile IPv6, July 2005. (Obsoleted by RFC 5268). RFC 4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6), August 2005 (Obsoleted by RFC 5380). RFC 4260 Mobile IPv6 Fast Handovers for 802.11 Networks, November 2005 (Informational).
- 33. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in APPENDIX 1.1B: BIBLIOGRAPHY 17 IETF RFC Title/Topic RFC 4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6), November 2005 (Standards Track). RFC 4285 Authentication Protocol for Mobile IPv6, January 2006 (Informational). RFC 4295 Mobile IPv6 Management Information Base, April 2006 (Standards Track). RFC 4449 Securing Mobile IPv6 Route Optimization Using a Static Shared key, June 2006 (Standards Track). RFC 4487 Mobile IPv6 and Firewalls: Problem Statement, May 2006 (Informational). RFC 4584 Extension to Sockets API for Mobile IPv6, July 2006 (Informational). RFC 4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6), September 2006. RFC 4866 Enhanced Route Optimization for Mobile IPv6, May 2007 (Standards Track). RFC 4877 Mobile IPv6 Operation with IKEv2 and Revised IPsec Architecture, April 2007 (Standards Track) (updates RFC 3776). RFC 4882 IP Address Location Privacy and Mobile IPv6: Problem Statement, May 2007 (Informational). RFC 4980 Analysis of Multihoming in Network Mobility Support, October 2007 (Informational). RFC 5014 IPv6 Socket API for Source Address Selection, September 2007 (Informational). RFC 5026 Mobile IPv6 Bootstrapping in Split Scenario, October 2007 (Standards Track). RFC 5094 Mobile IPv6 Vendor Specific Option, December 2007 (Standards Track). RFC 5096 Mobile IPv6 Experimental Messages, December 2007 (Standards Track). RFC 5149 Service Selection for Mobile IPv6, February 2008 (Informational). RFC 5213 Proxy Mobile IPv6, August 2008 (Standards Track). RFC 5268 Mobile IPv6 Fast Handovers, June 2008 (obsoletes RFC 4068). RFC 5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using Secure Neighbor Discovery (SEND), June 2008 (Standards Track). RFC 5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks, June 2008 (Informational). RFC 5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management, October 2008 (Standards Track). RFC 5419 Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6), January 2009 (Informational). RFC 5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction, February 2009 (Standards Track). RFC 5380 Hierarchical Mobile IPv6 (HIMPv6) Mobility Management, October 2008 (Standards Track). RFC 5488 Network Mobility (NEMO) Management Information Base, April 2009 (Standards Track). RFC 5555 Mobile IPv6 Support for Dual Stack Hosts and Routers, June 2009 (Standards Track). RFC 5568 Mobile IPv6 Fast Handovers, July 2009 (Obsoletes RFC 5268). RFC 5637 Authentication, Authorization and Accounting (AAA) Goals for Mobile IPv6, September 2009 (Informational). RFC 5648 Multiple Care-of Addresses Registration, October 2009 (Updated by RFC RFC 6089). (Continued)
- 34. P1: OTA/XYZ P2: ABC JWBS086-c01 JWBS086-Minoli July 12, 2012 8:12 Printer Name: Yet to Come Trim: 6.125in × 9.25in 18 THE MOBILE USER ENVIRONMENT IETF RFC Title/Topic RFC 5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction, February 2010 (Standards Track). RFC 5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server, February 2010 (Standards Track). RFC 5844 IPv4 Support for Proxy Mobile IPv6, May 2010. RFC 6058 Transient Binding for Proxy Mobile IPv6, March 2011. RFC 6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support. Updates RFC 5648. January 2011. RFC 6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6. February 2011. RFC 6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement. June 2011. RFC 6312 Mobile Networks Considerations for IPv6 Deployment. July 2011. (Obsoleted by RFC 6342). RFC 6342 Mobile Networks Considerations for IPv6 Deployment. August 2011. (Obsoletes RFC 6312). REFERENCES [1] D. Levitas, The Mobile DTV Opportunity and Its Role in the Communication Ecosystem, IDC, 2010, 5 Speen Street Framingham, MA 01701, www.idc.com. [2] J. Arkko, V. Devarapalli, F. Dupont, Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents, RFC 3776, 2004. [3] 6deploy.org, IPv6 Workshop – IPv6 Mobility Module, 2008. [4] S. Gundavelli Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, “Proxy Mobile IPv6”, RFC 5213, August 2008. [5] V. Devarapalli, R. Wakikawa et al, Network Mobility (NEMO) Basic Support Protocol, RFC 3963, 2005. [6] K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, S. Gundavelli (eds) Proxy Mobile IPv6, RFC 5213, 2008. [7] D. Minoli, Linear and Non-Linear Video and TV Applications Using IPv6 and IPv6 Multicast, Wiley, 2012. New York, NY. [8] 3GPP2 X.S0011-002-D, cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services, http://www.3gpp2.org/Public_html/specs/X.S0011-002-D_v1.0_ 060301.pdf, 2006. [9] WiMAX Network Architecture – WiMAX End-to-End Network Systems Architecture, 2008,http://www.wimaxforum.org/documents/documents/WiMAX_Forum_Network_ Architecture_Stage_23_Rel_1v1.2.zip. [10] MoVid 2012, Call for Papers (CFP) for 2012 Conference, 2011. [11] Cisco® , Cisco Visual Networking Index (VNI) Global Mobile Data Traffic Forecast for 2011 to 2016, 2012, Cisco Systems, Inc., San Jose, CA. [12] Nielsen Company, The Cross-Platform Report Quarter 1, 2011, www.nielsen.com.
- 35. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in CHAPTER 2 IPv6 BASICS 2.1 OVERVIEW AND MOTIVATIONS Internet protocol version 6 (IPv6) is a newer version of the network layer protocol that is designed to coexist (but not directly interwork) with IP version 4 (IPv4). In the long term, IPv6 is expected to replace IPv4, but that will not happen overnight. IPv6 provides improved internetworking capabilities compared to what is presently available with IPv4. The current IPv4 version of the Internet protocol has been in use for over 30 years but it exhibits some challenges in supporting emerging demands for address space cardinality, high-density mobility, multimedia, and strong security. IPv6 offers the potential of achieving scalability, reachability, end-to-end interworking, quality of service (QoS), and commercial-grade robustness that is needed for contemporary and emerging Web services, data services, and IP-based TV (IP television (IPTV) in particular and Internet-based TV (IBTV) in general), and mobile video. The innovation and growth of the Internet is now predicated on deployment of IPv6. We are not implying in this text that IPv6 is strictly and uniquely required to support IP-based IBTV/nontraditional TV (NTTV)/IPTV, linear video, video/content on demand (VoD/CoD), streaming video, and/or mobile video, just that it provides an ideal, future-proof, scalable mechanism for such services, whether in a terrestrial mode on in a satellite-based mode [1–2]. IP was designed in the late 1970s–early 1980s for the purpose of connecting computers that were in separate geographic locations. Starting in the early 1990s, developers realized that the communication needs of the twenty-first century needed Mobile Video with Mobile IPv6, First Edition. Daniel Minoli. C 2012 John Wiley Sons, Inc. Published 2012 by John Wiley Sons, Inc. 19
- 36. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 20 IPv6 BASICS a protocol with some new features and capabilities, while at the same time retaining the useful features of the existing protocol. IPv6 was initially developed in the early 1990s because of the anticipated need for more end-system addresses based on anticipated Internet growth, encompassing mobile phone deployment, smart home appliances, and billions of new users in developing countries (e.g., BRIC countries: Brazil, Russia, India, China). Technologies and applications such as voice over IP (VoIP), “always-on access” (e.g., cable modems), broadband and/or Ethernet-to-the- home, converged networks, and evolving ubiquitous computing applications will be driving this need even more intensively in the next few years [3]. IPv6 is now being slowly deployed worldwide: there is documented institutional and commercial interest and activity in Europe and Asia, and there is also evolving interest in the United States. The expectation is that in the next few years, deployment this new protocol will occur worldwide. For example, the U.S. Department of Defense (DoD) announced that from October 1, 2003, all new developments and procurements needed to be IPv6 capable; the DoD’s goal was to complete the transition to IPv6 for all intra- and inter networking across the agency by 2008, which was accomplished. The U.S. Government Accountability Office (GAO) has recommended that all agencies become proactive in planning a coherent transition to IPv6. The current expectation is that IPv4 will continue to exist for the foreseeable future, while IPv6 will be used for new broad-scale applications. The two protocols are not directly interworkable, but tunneling and dual-stack techniques allow coexistence and co-working. While the basic function of the network layer internetworking protocol is to move information across networks, IPv6 has more capabilities built into its foundation than IPv4. Link-level communication does not generally require a node identifier (address) since the device in intrinsically identified with the link level address; how- ever, communication over a group of links (a network) does require unique node identifiers (addresses). The IP address is an identifier that is applied to each device connected to an IP network. In this setup, different entities taking part in the net- work (servers, routers, user computers, and so on) communicate among each other using their IP address, as an entity identifier. The current IPv4 naming scheme was developed in the 1970s and had capacity for about 4.3 billion addresses, which were grouped into 255 blocks of 16 million addresses each. In version 4 of the IP protocol, addresses consist of four octets. With IPv4, the 32-bit address can be represented as AdrClass|netID|hostID. The network portion can contain either a network ID or a network ID and a subnet. Every network and every host or device has a unique address, by definition. For ease of human conversation, IP protocol addresses are represented as separated by periods, for example: 166.74.110.83, where the decimal numbers are a shorthand and correspond to the binary code described by the byte in question (an 8-bit number takes a value in the 0–255 range). Since the IPv4 address has 32 bits, there are nominally 232 different IP addresses (as noted, approximately 4.3 billion nodes, if all combinations are used). IPv4 has proven, by means of its long life, to be a flexible and powerful networking mechanism. However, IPv4 is starting to exhibit limitations, not only with respect to the need for an increase of the IP address space, driven, for example, by new popula- tions of users in countries such as China and India; but also by new technologies with
- 37. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in OVERVIEW AND MOTIVATIONS 21 TABLE 2.1 Projected RIR Unallocated Address Pool Exhaustion (as of April 2011) RIR Assigned Addresses (/8s) Remaining Addresses (/8s) AFRINIC 8.3793 4.6168 APNIC 53.7907 1.2093 ARIN 77.9127 6.0130 LACNIC 15.6426 4.3574 RIPENCC 45.0651 3.9349 RIR = Regional Internet Registry AfriNIC = African Network Information Centre ARIN = American Registry for Internet Numbers APNIC = Asia-Pacific Network Information Centre LACNIC = Latin America and Caribbean Network Information Centre (LACNIC) RIPE NCC = Réseaux IP Européens Network Coordination Centre (the RIR for Europe, the Middle East and parts of Central Asia) “always connected devices” (e.g., cable modems, networked PDAs, 3G/4G mobile smartphones, and so on); and also by new services such global rollout of VoIP, IPTV, and social networking. A Regional Internet Registry (RIR) manages the allocation and registration of Internet resources such as IPv4 addresses, IPv6 addresses and au- tonomous system (AS) numbers, in a specific region of the world. As of February 1, 2011 only 1 percent of all possible IPv4 addresses were left unassigned. This has led to a predicament known as IPv4 run out. The entire address space was expected to be more or less exhausted by September 2011, according to the IPv4 Address Report (see Table 2.1) [4–5]. The IPv4 address allocation is based on the following hierarchy: Internet Assigned Numbers Authority (IANA) –Regional Internet Registries (RIRs) – Internet service providers (ISPs) – the public (including businesses). Thus, a key desirable capability is the increase in address space such that it is able to cover all elements of the universe set under consideration. For example, all computing devices could have a public IP address, so that they can be uniquely tracked1 ; for example, today inventory management of dispersed IT assets cannot be achieved with IP mechanisms alone. With IPv6 one can use the network to verify that such equipment is deployed in place and active; even non-IT equipment in the field can be tracked by having an IP address permanently assigned to it. IPv6 creates a new IP address format, such that the number of IP addresses will not exhaust for several decades or longer, even though an entire new crop of devices are expected to connect to Internet over the coming years creating the so called Internet of Things [IoT]. IPv6 also adds improvements in areas such as routing and network configuration. IPv6 has extensive automatic configuration (autoconfiguration) mechanisms and reduces the IT 1Note that this has some potential negative security issues as attackers could be able to own a machine and then exactly know how to go back to that same machine again. Therefore reliable security mechanisms need to be understood and put in place in IPv6 environments.
- 38. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 22 IPv6 BASICS burden-making configuration, essentially plug and play. Specifically, new devices that connect to intranet or Internet will be “plug-and-play” devices. With IPv6, one is not required to configure dynamic nonpublished local IP addresses, the gateway address, the subnetwork mask, or any other parameters. The equipment automatically obtains all requisite configuration data when it connects to the network. Autoconfiguration implies that a Dynamic Host Configuration Protocol (DHCP) server is not needed and/or does not have to be configured [2,6–7]. IPv6 was originally defined in Internet Engineering Task Force (IETF) RFC 1883 that was then obsolete by RFC 2460, “Internet Protocol, version 6 (IPv6) Specification,” S. Deering, R. Hinden (December 1998)2 . A large body of additional RFCs has emerged in recent years to add capabilities and refine the concept. The advantages of IPv6, some of which we already noted in Chapter 1, can be summarized as follows: r Scalability and expanded addressing capabilities: IPv6 has 128-bit addresses versus 32-bit IPv4 addresses. With IPv4, the theoretical number of available IP addresses is 232 ∼1010 . IPv6 offers a 2128 space. Hence, the number of available unique node addressees is 2128 ∼1039 . IPv6 has more than 340 un- decillion (340282366920938463463374607431768211456) addresses, grouped into blocks of 18 quintillion addresses. r Plug-and-play: IPv6 includes a “plug-and-play” mechanism that facilitates the connection of equipment to the network. The requisite configuration is automatic; it is a serverless mechanism. r IPv6 makes it easy for nodes to have multiple IPv6 addresses on the same networkinterface. This cancreatetheopportunityfor users toestablishoverlayor communities of interest (COI) networks on top of other physical IPv6 networks. Departments, groups, or other users and resources can belong to one or more COIs, where each can have its own specific security policy [8]. r Security: IPv6 includes security in its specifications such as payload encryption and authentication of the source of the communication. End-to-end security, with built-in, strong IP-layer encryption and authentication (embedded security support with mandatory IP Security (IPsec) implementation). It follows that IPv6 network architectures can easily adapt to an end-to-end security model where the end hosts have the responsibility of providing the security services necessary to protect any data traffic between them; this results in greater flexibility for creating policy-based trust domains that are based on varying parameters including node address and application [9]. r In IPv6, creating a virtual private network (VPN) is easier and more standard than in IPv4, because of the (authentication header (AH) and encapsulating security protocol (ESP)) extension headers. The performance penalty is lower for the VPN implemented in IPv6 compared to those built in IPv4 [10]. 2The “version 5” reference was employed for another use—an experimental real-time streaming protocol—and to avoid any confusion, it was decided not to use this nomenclature.
- 39. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in ADDRESS CAPABILITIES 23 r Optimized protocol: IPv6 embodies IPv4 best practices but removes unused or obsolete IPv4 characteristics. This results in a better, optimized Internet protocol. Also, merging two IPv4 networks with overlapping addresses (say, if two organizations merge) is complex; it will be much easier to merge networks with IPv6. r Real-time applications: To provide better support for real-time traffic (e.g., VoIP, IPTV), IPv6 includes “labeled flows” in its specifications. By means of this mechanism, routers can recognize the end-to-end flow to which transmitted packets belong. This is similar to the service offered by Multiprotocol Label Switching (MPLS), but it is intrinsic with the IP mechanism rather than an add-on. Also, it preceded this MPLS feature by a number of years. r Mobility: IPv6 includes more efficient and robust mobility mechanisms (en- hanced support for Mobile IP, mobile computing devices, and mobile video). Specifically, Mobile IPv6 (MIPv6) as defined in RFC 3775 is now starting to be deployed [11]. r Streamlined header format and flow identification. r Extensibility: IPv6 has been designed to be extensible and offers support for new options and extensions. ISPs and carriers have been preparing for IP-address exhaustion for a number of years and there are transition plans in place. The expectation is that IPv6 can make IP devices less expensive, more powerful, and even consume less power; the power issue is not only important for environmental reasons, but also improves operability (e.g., longer battery life in portable devices, such as mobile phones and iPads). 2.2 ADDRESS CAPABILITIES 2.2.1 IPv4 Addressing and Issues IPv4 addresses can be from an officially assigned public range or from an internal intranet private (but not globally unique) block. As noted, IPv4 theoretically allows up to 232 addresses, based on a four-octet address space. Hence, there are 4294967296 unique values, which can be considered as a sequence of 256 “/8s,” where each “/8” corresponds to 16777216 unique address values. Public, globally unique addresses are assigned by IANA. IP addresses are addresses of network nodes at Layer 3; each device on a network (whether the Internet or an intranet) must have a unique address. In IPv4, a 32-bit (4-byte) binary address is used to identify a host’s network ID. It is represented by the nomenclature a.b.c.d (each of a, b, c, and d being from 1 to 255 (0 has a special meaning). Examples are 167.168.169.170, 232.233.229.209, and 200.100.200.100. The problem is that during the 1980s, many public, registered addresses were allocated to firms and organizations without any consistent control. As a result, some organizations have more addresses than they actually need, giving rise to the present
- 40. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 24 IPv6 BASICS dearth of available “registerable” Layer 3 addresses. Furthermore, not all IP addresses can be used due to the fragmentation described above. One approach to the issue would be a renumbering and a reallocation of the IPv4 addressing space. However, this is not as simple as it appears since it requires worldwide coordination efforts. Moreover, it would still be limited for the human population and the quantity of devices that will be connected to Internet in the medium-term future. At this juncture, and as a temporary and pragmatic approach to alleviate the dearth of addresses, network address translation (NAT) mechanisms are employed by organizations and even home users. This mechanism consists of using only a small set of public IPv4 addresses for an entire network to access to Internet. The myriad of internal devices are assigned IP addresses from a specifically designated range of Class A or Class C address that are locally unique but are duplicatively used and reused within various organizations. In some cases (e.g., residential Internet access use via DSL or Cable), the legal IP address is only provided to a user on a time-lease basis, rather than permanently. Internal intranet addresses may be in the ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. In the internal intranet private address case, a NAT function is em- ployed to map the internal addresses to an external public address when the private-to- public network boundary is crossed. This, however, imposes a number of limitations, particularly since the number of registered public addresses available to a company is almost invariably much smaller (as small as 1) than the number of internal devices requiring an address. A number of protocols cannot easily travel through a NAT device and hence the use of NAT implies that many applications (e.g., VoIP) cannot be used effectively in all instances. As a consequence, these applications can only be used in intranets. Examples include: r Multimedia applications such as videoconferencing, VoIP, or video on demand/ IPTV do not work smoothly through NAT devices. Multimedia applications make use of Real-time Transport Protocol (RTP) and Real-Time Control Proto- col (RTCP). These in turn use the User Datagram Protocol (UDP) with dynamic allocation of ports and NAT does not directly support this environment. r IPsec is used extensively for data authentication, integrity, and confidentiality. However, when NAT is used, IPsec operation is impacted, since NAT changes the address in the IP header. r Multicast, although possible in theory, requires complex configuration in a NAT environment and hence, in practice, is not utilized as often as could be the case. r The need for obligatory use of NAT disappears with IPv6. 2.2.2 IPv6 Address Space The IPv6 addressing architecture is described in RFC 4291, February 2006 [12]. One of the major modifications in the addressing scheme in IPv6 is a change to the basic types of addresses and how they are utilized. Unicast addresses are utilized for a majority of traditional (enterprise) communications, as was the case in IPv4. However, Broadcast as a specific addressing type has been eliminated, in its place
- 41. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in ADDRESS CAPABILITIES 25 Unicast - an ID per interface - explict assignment Unicast - n IDs interface - based on IEEE EUI-64 Multicast Anycast (New) - an ID for a set of interfaces. Deliver to the nearest one. - undistinguishible from unicast Broadcast - limited: 255.255.255.255 - directed: net11..1 Multicast - an ID for a set of interfaces. - Deliver to all of them Class D: 224.0.0.0 − 239.255.255.255 IPv4 IPv6 Special - ::, ::1 Special - 0.0.0.0, 127.0.0.1 FIGURE 2.1 Address Comparison between IPv4 and IPv6 support for multicast addressing has been expanded and made a required part of the protocol. A new type of addressing called anycast has also been implemented. In addition, there are a number of special IPv6 addresses. Figure 2.1 compares the two address formats. Figure 2.2 provides a pictorial comparison of these three transmis- sion (and address) modes. Logically one can interpret the types of transmissions as follows3 : r Unicast transmission: “send to this one specific address” r Multicast transmission: “send to every member of this specific group” r Anycast transmission: “send to any one member of this specific group.” Typi- cally, (motivated by efficiency goals) the transmission occurs to the closest (in routing terms) member of the group. Generally, one interprets anycast to mean “send to the closest member of this specific group.” The format of IPv6 addressing is described in RFC 2373. As noted, an IPv6 address consists of 128 bits, rather than 32 bits as with IPv4 addresses; the number of bits correlates to the address space, as follows: IP Version Size of Address Space IPv6 128 bits, which allows for 2128 or 340282366920938463463374607431768211456 (3.4 × 1038 ) possible addresses. IPv4 32 bits, which allows for 232 or 4294967296 possible addresses. 3Broadcast, by contrast, means “send this information/content to the entire universe of users in the address space.”
- 42. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 26 IPv6 BASICS a b c Unicast Multicast Anycast c b 2 a a a a a 3 Note: Device 1 and 2 are part of the same group Note: Device 1, 2, and 3 are part of the same group a 2 1 3 3 a 1 1 2 FIGURE 2.2 Comparison of Transmissions to IPv6 Nodes The relatively large size of the IPv6 address is designed to be subdivided into hierarchical routing domains that reflect the topology of the modern-day Internet. The use of 128 bits provides multiple levels of hierarchy and flexibility in designing hierarchical addressing and routing. The IPv4-based Internet currently lacks this flexibility [13].
- 43. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in ADDRESS CAPABILITIES 27 The IPv6 address is represented as eight groups of 16 bits each, separated by the “:” character. Each 16-bit group is represented by four hexadecimal digits, that is, each digit has a value between 0 and f (0,1, 2, . . . a, b, c, d, e, f with a = 10, b = 11, and so on to f = 15). What follows is an IPv6 address example 3223:0ba0:01e0:d001:0000:0000:d0f0:0010 An abbreviated format exists to designate IPv6 addresses when all endings are 0. For example, 3223:0ba0:: is the abbreviated form of the following address: 3223:0ba0:0000:0000:0000:0000:0000:0000 Similarly, only one 0 is written, removing 0s in the left side, and four 0s in the mid- dle of the address. For example, the address 3223:ba0:0:0:0:0::1234 is the abbreviated form of the following address: 3223:0ba0:0000:0000:0000:0000:0000:1234 There is also a method to designate groups of IP addresses or subnetworks that is based on specifying the number of bits that designate the subnetwork, beginning from left to right, using remaining bits to designate single devices inside the network. For example, the notation 3223:0ba0:01a0::/48 indicates that the part of the IP address used to represent the subnetwork has 48 bits. Since each hexadecimal digit has 4-bits, this points out that the part used to represent the subnetwork is formed by 12 digits, that is: “3223:0ba0:01a0.” The remaining digits of the IP address would be used to represent nodes inside the network. As noted, anycast addresses are a new type of address defined in IPv6 (as originally defined in RFC 1546). The purpose of the anycast address functionality is to enable capabilities that were difficult to implement in IPv4 environments. Datagrams sent to the anycast address are automatically delivered to the device in the network that is the easiest to reach. Anycast addresses can be used to define a group of devices, any one of which can support a service request from the user sent to a single specific IP address. One example is situations where one needs a service that can be provided by a set of different (dispersed) servers, but where one does not specifically care which one provides it; a specific example here may be an Internet or video (streaming) cache. Another example of anycast addressing is a router arrangement that allows datagrams to be transmitted to whichever router in a group of equivalent routers is closest to the point of transmission; a specific example here may be to allow load sharing between routers. It should be noted that there is no special anycast addressing format; anycast addresses are the same as unicast addresses from an address format perspective. In practicality, an anycast address is defined and created is a self-declarative manner when a unicast address is assigned to more than one device interface. Special IPv6 addresses, as follows (see Table 2.2 for additional details [14]): r Autoreturn or loopback virtual address: This address is specified in IPv4 as the 127.0.0.1 address. In IPv6, this address is represented as ::1. r Not specified address (::): This address is not allocated to any node since it is used to indicate absence of address. r IPv6 over IPv4 dynamic/automatic tunnel addresses: These addresses are des- ignated as IPv4-compatible IPv6 addresses and allow the sending of IPv6 traffic over IPv4 networks in a transparent manner. They are represented as, for exam- ple, ::156.55.23.5.
- 44. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 28 IPv6 BASICS TABLE 2.2 A Set of IPv6 Addresses of Particular Note Node-scoped Unicast ::1/128 is the loopback address (per RFC 4291). ::/128 is the unspecified address (per RFC 4291). Addresses within this block should not appear on the public Internet. IPv4-mapped addresses ::FFFF:0:0/96 are the IPv4-mapped addresses (per RFC 4291). Addresses within this block should not appear on the public Internet. IPv4-compatible addresses ::ipv4-address/96 are the IPv4-compatible addresses (per RFC4291). These addresses are deprecated and should not appear on the public Internet. Link-scoped Unicast FE80::/10 are the link-local unicast (per RFC 4291) addresses. Addresses within this block should not appear on the public Internet. Unique-local addresses FC00::/7 are the unique-local addresses (per RFC 4193). Addresses within this block should not appear by default on the public Internet. Documentation prefix The 2001:db8::/32 are the documentation addresses (per RFC 3849). They are used for documentation purposes such as user manuals, RFCs, and so on. Addresses within this block should not appear on the public Internet. 6to4 2002::/16 are the 6to4 addresses (per RFC 3056). The 6to4 addresses may be advertised when the site is running a 6to4 relay or offering a 6to4 transit service. However, the provider of this service should be aware of the implications of running such service (per RFC 3964), that include some specific filtering rules for 6to4. IPv4 addresses disallowed in 6to4 prefixes are listed in (per RFC 3964). Teredo 2001::/32 are the Teredo addresses (per RFC 4380). The Teredo addresses may be advertised when the site is running a Teredo relay or offering a Teredo transit service. 6bone 5F00::/8 were the addresses of the first instance of the 6bone experimental network (per RFC 1897). 3FFE::/16 were the addresses of the second instance of the 6bone experimental network (per RFC 2471). Both 5F00::/8 and 3FFE::/16 were returned to IANA (per RFC 3701). These addresses are subject to future allocation, similar to current unallocated address space. Addresses within this block should not appear on the public Internet until they are reallocated. ORCHID 2001:10::/28 are ORCHID addresses (per RFC 4843). These addresses are used as identifiers and are not routable at the IP layer. Addresses within this block should not appear on the public Internet. Default route ::/0 is the default unicast route address. IANA special purpose IPv6 address block An IANA registry (iana-ipv6-special-registry) is set (per RFC 4773) for special purpose IPv6 address blocks assignments used for experiments and other purposes. Addresses within this registry should be reviewed for Internet routing considerations. Multicast FF00::/8 are multicast addresses (per RFC 4291). They have a 4-bits scope in the address field where only some values are of global scope (per RFC 4291). Only addresses with global scope in this block may appear on the public Internet. Multicast routes must not appear in unicast routing tables.
- 45. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in IPv6 PROTOCOL OVERVIEW 29 r IPv4 over IPv6 addresses automatic representation: These addresses allow for IPv4-only-nodes to still work in IPv6 networks. They are designated as “mapped from IPv4 to IPv6 addresses” and are represented as ::FFFF:, for example ::FFFF.156.55.43.3. 2.3 IPv6 PROTOCOL OVERVIEW Table 2.3 shows the core protocols that comprise IPv6. IPv6 basic protocol capabilities include the following: r Addressing r Anycast r Flow labels r ICMPv6 r Neighbor discovery Like IPv4, IPv6 is a connectionless datagram protocol used primarily for address- ing and routing packets between hosts. Connectionless means that a session is not established before exchanging data. “Unreliable” means that delivery is not guaran- teed. IPv6 always makes a best-effort attempt to deliver a packet. An IPv6 packet TABLE 2.3 Key IPv6 Protocols Protocol (Current Version) Description Internet protocol version 6 (IPv6): RFC 2460 Updated by RFC 5095, RFC 5722, RFC 5871 IPv6 is a connectionless datagram protocol used for routing packets between hosts. Internet Control Message Protocol for IPv6 (ICMPv6): RFC 4443 Updated by RFC 4884 A mechanism that enables hosts and routers that use IPv6 communication to report errors and send status messages. Multicast Listener Discovery (MLD): RFC 2710, Updated by RFC 3590, RFC 3810 A mechanism that enables one to manage subnet multicast membership for IPv6. MLD uses a series of three ICMPv6 messages. MLD replaces the Internet Group Management Protocol (IGMP) v3 that is employed for IPv4. Neighbor discovery (ND): RFC 4861 Updated by RFC 5942 A mechanism that is used to manage node-to-node communication on a link. ND uses a series of five ICMPv6 messages. ND replaces Address Resolution Protocol (ARP), ICMPv4 router discovery, and the ICMPv4 redirect message. ND is implemented using the Neighbor Discovery Protocol (NDP).
- 46. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 30 IPv6 BASICS Destination Address Source Address Payload Length Traffic Class Flow Label Next Header Hop Limit Version FIGURE 2.3 IPv6 Packet might be lost, delivered out of sequence, duplicated, or delayed. IPv6 per se does not attempt to recover from these types of errors. The acknowledgment of packets delivered and the recovery of lost packets is done by a higher-layer protocol, such as Transmission Control Protocol (TCP) [13]. From a packet forwarding perspective IPv6 operates in a similar, nearly identical manner to IPv4. An IPv6 packet, also known as an IPv6 datagram, consists of an IPv6 header and an IPv6 payload, as shown Figure 2.3. The IPv6 header consists of two parts, the IPv6 base header and optional extension headers (see Figure 2.4). Functionally, the optional Version Traffic Class Payload Length Flow Label Hop Limit Next Header Source IPv6 Address (128 Bits) Destination IPv6 Address (128 Bits) Extension Header Information Next Header Payload Variable Length 40 Octets IPv6 extension headers are optional headers that may follow the basic IPv6 header. An IPv6 PDU may include zero, one, or multiple extension headers. When multiple extension headers are used, they form a chained list of headers identified by the Next Header field of the previous header. FIGURE 2.4 IPv6 Extension Headers
- 47. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in IPv6 PROTOCOL OVERVIEW 31 extension headers and upper-layer protocols, for example TCP, are considered part of the IPv6 payload. Table 2.4 shows the fields in the IPv6 base header. IPv4 headers and IPv6 headers are not directly interoperable: hosts and/or routers must use an implementation of both IPv4 and IPv6 in order to recognize and process both header formats (see Figure 2.5). This gives rise to a number of complexities in the migration process between the IPv4 and the IPv6 environments. The IP header in IPv6 has been streamlined and defined to be of a fixed length (40 bytes). In IPv6, header fields from the IPv4 header have been removed, renamed, or moved to the new optional IPv6 extension headers. The header length field is no longer needed since the IPv6 header is now a fixed length entity. The IPv4 “type of service” is equivalent to the IPv6 “traffic class” field. The “total length” field has been replaced with the “payload length” field. Since IPv6 only allows for fragmentation to be performed by the IPv6 source and destination nodes, and not individual routers, the IPv4 segment control fields (Identification, Flags, and Fragment Offset fields) have been moved to similar fields within the fragment extension header. The functionality provided by the “time to live (TTL4 )” field has been replaced with the “hop limit” field. The “protocol” field has been replaced with the “Next Header type” field. The “header checksum” field was removed, that has the main advantage of not having each relay spend time processing the checksum. The “options” field is no longer part of the header as it was in IPv4. Options are specified in the optional IPv6 extension headers. The removal of the options field from the header enables more efficient routing; only the information that is needed by a router needs to be processed [15]. One area requiring consideration, however, is the length of the IPv6 protocol data unit (PDU): the 40-octet header can be a problem for real-time IP applications such as VoIP and IPTV. Header compression (HC) becomes critical for many applications, as noted in Section 2.4. Also, there will be some bandwidth inefficiency in general, that could be an issue in limited-bandwidth environments or applications (e.g., wireless networks, sensor networks). Stateless address autoconfiguration (described in RFC 4862) defines how an IPv6 node generates addresses without the use of a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server [16]. “Autoconfiguration” is a new characteristic of the IPv6 protocol that facilitates network management and system set-up tasks by users. This characteristic is often called “plug and play” or “connect and work.” Autoconfig- uration facilitates initialization of user devices: after connecting a device to an IPv6 network, one or several IPv6 globally unique addresses are automatically allocated. Note, however, that an IPv6 address must be configured on a router’s interface for the interface to forward IPv6 traffic. Configuring a global IPv6 address on a router’s interface automatically configures a link-local address (LLA) and activates IPv6 for that interface. DHCP allows systems to obtain an IPv4 address and other required information (e.g., default router or Domain Name System (DNS) server); a similar protocol, DHCPv6, has been published for IPv6. DHCP and DHCPv6 are known as stateful protocols because they maintain tables on (specialized) servers. However, IPv6 also 4TTL has been used in many attacks and Intrusion Detection System (IDS) tricks in IPv4.
- 48. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 32 IPv6 BASICS TABLE 2.4 IPv6 Base Header IPv6 Header Field Length (bits) Function Version 4 Identifies the version of the protocol. For IPv6, the version is 6. Traffic class 8 Intended for originating nodes and forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets. Flow label 20 (Sometimes referred to as Flow ID.) Defines how traffic is handled and identified. A flow is a sequence of packets sent either to a unicast or a multicast destination. This field identifies packets that require special handling by the IPv6 node. The following list shows the ways the field is handled if a host or router does not support flow label field functions: r If the packet is being sent, the field is set to zero. r If the packet is being received, the field is ignored. Payload length 16 Identifies the length, in octets, of the payload. This field is a 16-bit unsigned integer. The payload includes the optional extension headers, as well as the upper-layer protocols, for example, TCP. Next header 8 Identifies the header immediately following the IPv6 header. The following show examples of the next header: 00 = Hop-by-hop options 01 = ICMPv4 04 = IP in IP (encapsulation) 06 = TCP 17 = UDP 43 = Routing 44 = Fragment 50 = Encapsulating security payload 51 = Authentication 58 = ICMPv6 Hop limit 8 Identifies the number of network segments, also known as links or subnets, on which the packet is allowed to travel before being discarded by a router. The hop limit is set by the sending host and is used to prevent packets from endlessly circulating on an IPv6 internetwork. When forwarding an IPv6 packet, IPv6 routers must decrease the hop limit by 1, and must discard the IPv6 packet when the hop limit is 0. Source address 128 Identifies the IPv6 address of the original source of the IPv6 packet. Destination address 128 Identifies the IPv6 address of intermediate or final destination of the IPv6 packet.
- 49. 33 0 Version Version Identification Flags Time to Live Protocol Header Checksum Source Address Destination Address Destination Address (128 bits) Destination Address (128 bits) Destination Address (128 bits) Destination Address (128 bits) Options Traffic Class Flow Label Payload Length (16 bits) Next Header Type Hop Limit Source Address (128 bits) Source Address (128 bits) Source Address (128 bits) Source Address (128 bits) Padding IPv4 Header IPv4 Header Version (4-bit) Version (4-bit) IPv6 header contains a new value Same function for both headers. Same function for both headers. Same function for both headers. Same function for both headers. Same function, but Source address is expanded in IPv6. Same function, but Destination address is expanded in IPv6. New field added to tag a flow for IPv6 packets. Header length (4-bit) Type of service (8-bit) Traffic class (8-bit) Flow label (20-bit) Payload length (16-bit) Hop limit (8-bit) Next header (8-bit) Source address (128-bit) Destination address (128-bit) Extension headers Total PDU length (16-bit) Identification (16-bit) Flags (3-bit) Fragment offset (13-bit) Time to live (8-bit) Protocol number (8-bit) Header checksum (16-bit) Source address (32-bit) Destination address (32-bit) Options (variable) Padding (variable) — — — — — — — — — — Removed in IPv6; the basic IPv6 header has fixed length of 40 octets Removed in IPv6. Options handled differently. Removed in IPv6. Options handled differently. New way in IPv6 to handle Options fields, security Removed in IPv6; upper-layer protocols handle checksums Removed in IPv6 becasue fragmentation is no longer done by intermediate routers in the networks, but by the source node that originates the packet. Removed in IPv6 becasue fragmentation is no longer done by intermediate routers in the networks, but by the source node that originates the packet. Removed in IPv6 becasue fragmentation is no longer done by intermediate routers in the networks, but by the source node that originates the packet. IPv6 Header Notes IPv6 Header Fragment Offset IHL Type of Service Total Length 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 1 2 3 0 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 1 2 3 FIGURE 2.5 Comparison of IPv4 and IPv6 Headers
- 50. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 34 IPv6 BASICS has a new stateless autoconfiguration protocol that has no equivalent in IPv4. The stateless autoconfiguration protocol does not require a server component because there is no state to maintain (a DHCP server may typically run in a router or firewall). Every IPv6 system (other than routers) is able to build its own unicast global address. [17]. “Stateless” autoconfiguration is also described as “serverless.” The acronym SLAAC is also used; it expands to stateless address autoconfiguration. SLAAC was originally defined in RFC 2462. With SLAAC the presence of configuration servers to supply profile information is not required. The host generates its own address using a combination of the information that it possesses (in its interface or network card) and the information that is supplied by the router. As noted in RFC 4941, nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and informa- tion advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded Institute of Electrical and Electronics Engineers (IEEE) identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation [18] Some types of network inter- faces come with an embedded IEEE identifier (i.e., a link-layer media access control (MAC) address), and in those cases, stateless address autoconfiguration uses the IEEE identifier to generate a 64-bit interface identifier [12]. By design, the interface identi- fier is likely to be globally unique when generated in this fashion. The interface iden- tifier is in turn appended to a prefix to form a 128-bit IPv6 address. Not all nodes and interfaces contain IEEE identifiers. In such cases, an interface identifier is generated through some other means (e.g., at random), and the resultant interface identifier may not be globally unique and may also change over time. Routers determine the prefix that identifies networks associated to the link under discussion. The “interface identi- fier” identifies an interface within a subnetwork and is often, and by default, generated from the MAC address of the network card. The IPv6 address is built combining the 64 bits of the interface identifier with the prefixes that routers determine as belonging to the subnetwork. If there is no router, the interface identifier is self-sufficient to allow the PC to generate an LLA. The LLA is sufficient to allow the communication between several nodes connected to the same link (the same local network). In summary, all nodes combine interface identifiers (whether derived from an IEEE identifier or generated through some other technique) with the reserved link- local prefix to generate LLAs for their attached interfaces. Additional addresses can then be created by combining prefixes advertised in router advertisements via neighbor discovery (defined in RFC 4861 [19]) with the interface identifier. Note: As seen, addresses generated using stateless address autoconfiguration contain an embedded interface identifier that remains constant over time. Whenever a fixed identifier is used in multiple contexts, a security exposure could theoretically result. A correlation can be performed by an attacker who is in the path between the node in question and the peer(s) to which it is communicating, and who can view the IPv6 addresses present in the datagrams. Because the identifier is embedded within the IPv6 address, which is a fundamental requirement of communication, it cannot be easily hidden. Solutions to this issue have been proposed by generating interface identifiers that vary over time [18].
- 51. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in IPv6 PROTOCOL OVERVIEW 35 IPv6 addresses are “leased” to an interface for a fixed established time (including an infinite time). When this “lifetime” expires, the link between the interface and the address is invalidated and the address can be reallocated to other interfaces. For the suitable management of addresses expiration time, an address goes through two states (stages) while is affiliated to an interface [20]: (a) At first, an address is in a “preferred” state, so its use in any communication is not restricted. (b) After that, an address becomes “deprecated,” indicating that its affiliation with the current interface will (soon) be invalidated. When it is in a “deprecated” state, the use of the address is discouraged, although it is not forbidden. However, when possible, any new communication (for example, the opening of a new TCP connection) must use a “preferred” address. A “deprecated” address should only be used by applications that have already used it before and in cases where it is difficult to change this address to another address without causing a service interruption. To ensure that allocated addresses (granted either by manual mechanisms or by autoconfiguration) are unique in a specific link, the link duplicated addresses detection algorithm is used. The address to which the duplicated address detection algorithm is being applied to is designated (until the end of this algorithmic session) as an “attempt address.” In this case, it does not matter that such address has been allocated to an interface and received packets are discarded. Further we describe how an IPv6 address is formed. The lowest 64 bits of the address identify a specific interface and these bits are designated as “interface iden- tifier.” The highest 64 bits of the address identify the “path” or the “prefix” of the network or router in one of the links to which such interface is connected. The IPv6 address is formed by combining the prefix with the interface identifier. It is possible for a host or device to have IPv6 and IPv4 addresses simultaneously. Most of the systems that currently support IPv6 allow the simultaneous use of both protocols. In this way it is possible to support communication with IPv4-only net- works as well as IPv6-only networks, and the use of the applications developed for both protocols [20]. It is possible to transmit IPv6 traffic over IPv4 networks via tunneling methods. This approach consists of “wrapping” the IPv6 traffic as IPv4 payload data: IPv6 traffic is sent “encapsulated” into IPv4 traffic and at the receiving end this traffic is parsed as IPv6 traffic. Transition mechanisms are methods used for the coexistence of IPv4 and/or IPv6 devices and networks. For example, an “IPv6-in-IPv4 tunnel” is a transition mechanism that allows IPv6 devices to communicate through an IPv4 network. The mechanism consists of creating the IPv6 packets in a normal way and encapsulating them in an IPv4 packet. The reverse process is undertaken in the destination machine that de-encapsulates the IPv6 packet. There is a significant difference between the procedures to allocate IPv4 addresses that focus on the parsimonious use of addresses (since addresses are a scare re- source and should be managed with caution), and the procedures to allocate IPv6 addresses, that focus on flexibility. ISPs deploying IPv6 systems follow the RIRs’
- 52. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 36 IPv6 BASICS policies relating to how to assign IPv6 addressing space among their clients. RIRs are recommending ISPs and operators allocate to each IPv6 client a /48 subnetwork; this allows clients to manage their own subnetworks without using NAT. (The im- plication is that the obligatory need for NAT for intranet-based devices disappears in IPv6.) In order to allow its maximum scalability, the IPv6 protocol uses an approach based on a basic header, with minimum information. This differentiates it from IPv4 where different options are included in addition to the basic header. IPv6 uses a header “concatenation” mechanism to support supplementary capabilities. The advantages of this approach include the following: r The size of the basic header is always the same, and is well known. The basic header has been simplified compared with IPv4, since only 8 fields are used instead of 12. The basic IPv6 header has a fixed size; hence, its processing by nodes and routers is more straightforward. Also, the header’s structure aligns to 64 bits, so that new and future processors (64 bits minimum) can process it in a more efficient way. r Routers placed between a source point and a destination point (i.e., the route that a specific packet has to pass through), do not need to process or understand any “following headers.” In other words, in general, interior (core) points of the network (routers) only have to process the basic header, while in IPv4 all headers must be processed. This flow mechanism is similar to the operation in MPLS, yet precedes it by several years. r There is no limit to the number of options that the headers can support (the IPv6 basic header is 40 octets in length, while the IPv4 header varies from 20 to 60 octets, depending on the options used). In IPv6, interior/core routers do not perform packets fragmentation, but the frag- mentation is performed end to end. That is, source and destination nodes perform, by means of the IPv6 stack, the fragmentation of a packet and the reassembly, respec- tively. The fragmentation process consists of dividing the source packet into smaller packets or fragments [20]. The IPv6 specification defines a number of extension headers [15] (also see Table 2.5 [21]): r Routing header: Similar to the source routing options in IPv4. The header is used to mandate a specific routing. r Authentication header (AH): A security header that provides authentication and integrity. r Encapsulating security payload (ESP) header: A security header that provides authentication and encryption. r Fragmentation header: The fragmentation header is similar to the fragmentation options in IPv4.
- 53. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in IPv6 TUNNELING 37 TABLE 2.5 IPv6 Extension Headers Header (protocol ID) Description Hop-by-hop options header (protocol 0) The hop-by-hop Options header is used for Jumbogram packets and the router alert. An example of applying the hop-by-hop options header is Resource Reservation Protocol (RSVP). This field is read and processed by every node and router along the delivery path. Destination options header (protocol 60) This header carries optional information that is specifically targeted to a packet’s destination address. The MIPv6 protocol specification makes use of the destination options header to exchange registration messages between mobile nodes (MNs) and the home agent (HA). Mobile IP is a protocol allowing MNs to keep permanent IP addresses even if they change point of attachment. Routing header (protocol 43) This header can be used by an IPv6 source node to force a packet to pass through specific routers on the way to its destination. A list of intermediary routers may be specified within the routing header when the Routing Type field is set to 0. Fragment header (protocol 44) In IPv6, the Path MTU Discovery (PMTUD) mechanism is recommended to all IPv6 nodes. When an IPv6 node does not support PMTUD and it must send a packet larger than the greatest MTU along the delivery path, the fragment header is used. When this happens, the node fragments the packets and sends each fragment using fragment headers; then the destination node reassembles the original packet by concatenating all the fragments. Authentication header (AH) (protocol 51) This header is used in IPsec to provide authentication, data integrity, and replay protection. It also ensures protection of some fields of the basic IPv6 header. This header is identical in both IPv4 and IPv6. Encapsulating Security Payload (ESP) header (protocol 50) This header is also used in IPsec to provide authentication, data integrity, replay protection, and confidentiality of the IPv6 packet. Similar to the AH, this header is identical in both IPv4 and IPv6. r Destination options header: Header that contains a set of options to be processed only by the final destination node. MIPv6 is an example of an environment that uses such a header. r Hop-by-hop options header: A set of options needed by routers to perform certain management or debugging functions. 2.4 IPv6 TUNNELING IPv6 tunneling is used in a variety of settings, including in MIPv6. MIPv6 tunnels payload packets between the MN and the HA in both directions. This tunneling uses IPv6 encapsulation discussed below.
- 54. P1: OTA/XYZ P2: ABC JWBS086-c02 JWBS086-Minoli July 12, 2012 8:51 Printer Name: Yet to Come Trim: 6.125in × 9.25in 38 IPv6 BASICS IPv6 tunneling as defined in RFC 2473 [22] is a technique for establishing a “virtual link” between two IPv6 nodes for transmitting data packets as payloads of IPv6 packets. From the perspective of the two nodes, this “virtual link,” called an IPv6 tunnel, appears as a point-to-point link on which IPv6 acts like a link- layer protocol. The two IPv6 nodes support specific roles. One node encapsulates original packets received from other nodes or from itself and forwards the resulting tunnel packets through the tunnel. The other node decapsulates the received tunnel packets and forwards the resulting original packets toward their destinations, possibly itself. The encapsulator node is called the tunnel entry-point node, and it is the source of the tunnel packets. The decapsulator node is called the tunnel exit point, and it is the destination of the tunnel packets. An IPv6 tunnel is a unidirectional mechanism—tunnel packet flow takes place in one direction between the IPv6 tunnel entry-point and exit-point nodes (see Figure 2.6, top). Bidirectional tunneling is achieved by merging two unidirectional mechanisms, that is, configuring two tunnels, Tunneling mechanism Tunnel from node B to node C Tunnel from node B to node C Tunnel from node C to node B Bidirectional tunneling mechanism Tunnel Tunnel C B Original Packet Source Node Original Packet Source Node Original Packet Source Node Original Packet Destination Node Tunnel Exit-Point Node Tunnel Entry-Point Node Tunnel Exit-Point Node Tunnel Entry-Point Node Original Packet Destination Node Tunnel Entry-Point Node Tunnel Exit-Point Node Original Packet Destination Node A B C D D A FIGURE 2.6 IPv6 Tunneling
- 55. Another Random Document on Scribd Without Any Related Topics
- 56. remain freely available for generations to come. In 2001, the Project Gutenberg Literary Archive Foundation was created to provide a secure and permanent future for Project Gutenberg™ and future generations. To learn more about the Project Gutenberg Literary Archive Foundation and how your efforts and donations can help, see Sections 3 and 4 and the Foundation information page at www.gutenberg.org. Section 3. Information about the Project Gutenberg Literary Archive Foundation The Project Gutenberg Literary Archive Foundation is a non-profit 501(c)(3) educational corporation organized under the laws of the state of Mississippi and granted tax exempt status by the Internal Revenue Service. The Foundation’s EIN or federal tax identification number is 64-6221541. Contributions to the Project Gutenberg Literary Archive Foundation are tax deductible to the full extent permitted by U.S. federal laws and your state’s laws. The Foundation’s business office is located at 809 North 1500 West, Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up to date contact information can be found at the Foundation’s website and official page at www.gutenberg.org/contact Section 4. Information about Donations to the Project Gutenberg Literary Archive Foundation Project Gutenberg™ depends upon and cannot survive without widespread public support and donations to carry out its mission of increasing the number of public domain and licensed works that can be freely distributed in machine-readable form accessible by the widest array of equipment including outdated equipment. Many
- 57. small donations ($1 to $5,000) are particularly important to maintaining tax exempt status with the IRS. The Foundation is committed to complying with the laws regulating charities and charitable donations in all 50 states of the United States. Compliance requirements are not uniform and it takes a considerable effort, much paperwork and many fees to meet and keep up with these requirements. We do not solicit donations in locations where we have not received written confirmation of compliance. To SEND DONATIONS or determine the status of compliance for any particular state visit www.gutenberg.org/donate. While we cannot and do not solicit contributions from states where we have not met the solicitation requirements, we know of no prohibition against accepting unsolicited donations from donors in such states who approach us with offers to donate. International donations are gratefully accepted, but we cannot make any statements concerning tax treatment of donations received from outside the United States. U.S. laws alone swamp our small staff. Please check the Project Gutenberg web pages for current donation methods and addresses. Donations are accepted in a number of other ways including checks, online payments and credit card donations. To donate, please visit: www.gutenberg.org/donate. Section 5. General Information About Project Gutenberg™ electronic works Professor Michael S. Hart was the originator of the Project Gutenberg™ concept of a library of electronic works that could be freely shared with anyone. For forty years, he produced and distributed Project Gutenberg™ eBooks with only a loose network of volunteer support.
- 58. Project Gutenberg™ eBooks are often created from several printed editions, all of which are confirmed as not protected by copyright in the U.S. unless a copyright notice is included. Thus, we do not necessarily keep eBooks in compliance with any particular paper edition. Most people start at our website which has the main PG search facility: www.gutenberg.org. This website includes information about Project Gutenberg™, including how to make donations to the Project Gutenberg Literary Archive Foundation, how to help produce our new eBooks, and how to subscribe to our email newsletter to hear about new eBooks.
- 59. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com