Internet DRAFT - draft-so-ikev2-fmciwk-ipv4encap
draft-so-ikev2-fmciwk-ipv4encap
IPSECME T. So
Internet Draft ZTE USA
Intended status: standard Z. Qiang
Expires: June 2012 Ericsson
December 12, 2011
Problem Statement of IPv4 Private Addressing Support
for Fixed Mobile Convergence over IPSec Tunneling
draft-so-ikev2-fmciwk-ipv4encap-00.txt
Abstract
IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many
standardized network solutions to provide the secure transport
between network elements over third party's infrastructure. For
example, the emerging Fixed Mobile Convergence (FMC) network solution
that involves Femtocell deployment requires the mobile operator's
Femtocell AP to leverage the IPSec IKEv2 to support mutual
authentication and remote IP address configuration as well as other
auto configuration support over the broadband fixed network (BBF) of
which the mobile and fixed networks may be operated by two different
operators.
Most of today broadband fixed networks are still relying on the IPv4
private addressing plan to support its attached devices including the
mobile operator's Femtocell AP. Hence, the private IPv4 addressing
and Network Address and Port Translation (NA(P)T) support mostly
likely stays for many years to come.
In FMC interworking scenario, there is a need for the mobile network
to pass on it mobile subscribers' policies to the broadband fixed
network (BBF) to maintain the service level agreement (SLA) and to
support remote network management. In addition, a broadband fixed
network (BBF) may partnership with more than one mobile operator.
Therefore it is important for the BBF and the mobile network to be
able to overcome the limitation of the private IPv4 addressing and to
be able to identify the user's subscription as well as to determine
the location of the Femtocell AP that serves its mobile user over the
BBF network.
This document presents the problems for the IPSec tunneling support
with private IPv4 addressing for FMC interworking and proposes a
simple extension to the IKEv2 to resolve the issues.
So Expires June 12, 2012 [Page 1]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 12, 2009.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
So Expires June 12, 2012 [Page 2]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
Table of Contents
1. Introduction...................................................4
1.1. Requirement for FAP location verification.................5
1.2. Requirement for FAP's identification for the attached mobile
UE.............................................................6
2. Problem statements.............................................8
2.1. Considerations of STUN support for FMC interworking with FAP
...............................................................9
3. Proposed Solution - Extension to IKEv2 Configuration Payload..10
3.1. Details of proposed changes to RFC 5996 for IKEv2 CP.....12
4. Security Considerations.......................................14
5. IANA Considerations...........................................14
6. Conclusions...................................................15
7. References....................................................15
7.1. Normative References.....................................15
7.2. Informative References...................................15
8. Acknowledgments...............................................15
Table of Figures
Figure 1: Femto-AP (FAP) E2E Configuration ...................... 5
Figure 2: Example of the typical IP Addressing used across the BBF
and Mobile Network for Femto-cell deployment with IPSec Tunneling 7
Figure 3: Example of the IKEv2 Configuration Payload solution to
carry the public IPv4 address and port number of the UDP header for
the encapsulated IPSec tunnel....................................12
So Expires June 12, 2012 [Page 3]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
1. Introduction
Today many network solutions leverage the IPSec IKEv2 to provide the
secure transport as well as some form remote configuration support
for their network elements over third party infrastructure (e.g.
ADSL, Cable etc.).
The standardized Femtocell architecture from Femto Forum as well as
from many mobile standards (e.g. 3GPP, 3GPP2 and WiMAX) are good
examples that all have common architecture to leverage the IPSec
IKEv2 to interconnect the Femtocell AP (FAP) with the Security
Gateway (SeGW) over the broadband fixed (BBF) network (e.g. ADSL,
Cable networks etc.). Both the Femtocell AP (FAP) and the SeGW are
managed by the mobile operator which may be a different operator for
the BBF network.
Most BBF networks today operate on the private IPv4 addressing plan
within their networks and rely NA(P)T for external communication.
For the FMC scenario, a given BBF network may require to be able to
interwork with more than one mobile network which may also deploy its
own private IPv4 addressing plan.
Given each operator manages their own private IPv4 addressing plan
within their network domains and they need to support inter-operators
subscribers policy exchange, this introduces a major challenge on how
to coordinate the private and public addressing across the operators'
domains so that the mobile network can locate the serving BBF access
network that its mobile user entity (UE) is attached to and the
mobile user's identity, so that the BBF network can provide the
appropriate FMC interworking policy and bearer control on its UE, and
also to enable the remote network management, when required.
The following presents an example of typical Femtocell network
configuration.
So Expires June 12, 2012 [Page 4]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
/---------------------------\
| +----+ +--------+ +----+ | B-----------B M-------------------M
| | UE | | Stand- |<=|====|=|===|===========|==|=>o--o o--o |
| +----+ | alone | | RG | | | | | | | | | Mobile |
| | FAP | +----+ | | | | |S | |F | Network|
| +--------+ (NAPT) | | Broadband | | |e | |A | |
\---------------------------/ | Fixed | | |G |-|P | c-----c|
| Network | | |W | |G |-| Core||
/---------------------------\ | (BBF) | | | | |W | | Ntwk||
| +----+ +------------+ | | | | | | | | c-----c|
| | UE | | Integrated |<====|===|===========|==|=>o--o o--o / \ |
| +----+ | FAP (NAPT) | | B-----------B M-------------------M
| +------------+ | / \
\---------------------------/ I-------I p----p
|Inter- | |PSTN|
Legends: | net | p----p
<=====> - IPSec Tunnel I-------I
CoreNtwk - Core Network
FAPGW - FAP Gateway
NAPT - Network Address & Port Translation
RG - Routing Gateway
SeGW - Security Gateway
UE - User Entity
Figure 1 : Typical Femto-AP (FAP) E2E Configuration
1.1. Requirement for FAP location verification
FAP is designed to support plug and play, however, given it is
operating on the license band frequency spectrum to support the
mobile devices, the FAP is required to support location verification
to ensure its legitimacy to operate on the license spectrum for a
given mobile operator prior to the FAP be ready to serve its mobile
devices.
There are several recommendations from today mobile standards that
provide possible solutions, but all with limitations:
1. GPS
o Limitation: may not be feasible due to poor indoor signal
2. Overlay Macro cell
So Expires June 12, 2012 [Page 5]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
o Limitation: not always feasible, especially in rural area
3. Femto-AP's IP address
o Limitation: private IPv4 addressing and NA(P)T
4. Etc.
Option 1. and 2. above are very much limited by the physical
environment where the FAP is installed which may be beyond the
control of the mobile operator; whereas, Option 3. could be resolved
by operators' deployment strategy and network solution on the private
IPv4 addressing and the NAPT issue. Hence, Option 3. is considered
as the more desirable option to address this FAP location
verification requirement.
Once the location of the FAP is identified (e.g. based on IP
address), the corresponding BBF access network which assigns the
public IPv4 address to the given FAP can also be known to the mobile
network, and hence, the location of the FAP could be verified.
1.2. Requirement for FAP's identification for the attached mobile UE
As part of the FMC interworking, the policy associated with the
mobile UE is required to be provided by the policy function of the
mobile network, that serves the UE, to the policy function of the BBF
network that serves the same UE. In the case of the private IPv4
addressing plan is employed at the BBF network, the identity of its
mobile UE and the corresponding mapping between the private IPv4
address and the public IPv4 address of the FAP with the port number
(in the case of the NAPT) are needed to be known by the policy
function of the mobile network so that it can inform the appropriate
policy function of the BBF network based on the BBF local
identification of the FAP that the mobile UE is attached. As a
result, the BBF network can provide the policy enforcement to apply
the QoS policy on the FAP's traffic originated by and targeted to the
UE.
The following figure describes the scenario of the mobile UE's IPv4
address-mapping relationship in typical Femtocell deployment over the
BBF and mobile networks with IPSec tunneling.
So Expires June 12, 2012 [Page 6]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
(Mobile Network +--------+ +-----------------------+
Assigned) | /----\ | | /----\ /----------\ |
Inner | |BPCF|--------|PCRF|--| MME/SGW |- |
IP@ | \----/ | | \----/ \----------/| |
| | | | | |--------------| | |
| | /----\ | | /----\ /------\ | | |
+---+ | +--+ | |BNG | | | |SeGW| |FAP-GW| | | |
+--+ | <===v===|==|===|=|====|=|====|=> |---| | | | |
|UE|..|FAP|.......|RG|...|.|....|.|....|.|....|...|..... | | | |
+--+ | <=======|==|===|=|====|=|====|=> | | . | | | |
+---+ +--+^ | \----/ | | \----/ \------/ | | |
^ | | | | | . | | |
| | | BBF | | /------\ | | |
Private | | Network| | Mobile |PGW . |-- | |
IP@ Public +--------+ | Network \------/---| |
(BBF IP@+Port# | . |
Assigned) (NAPT) +-----------------------+
(BBF Assigned) .
*--------*
Legends: |Internet|
BPCF - Broadband Policy Control Function *--------*
BNG - Broadband Network Gateway
PCRF - Policy Charging Rule Function
PGW - PDN Gateway
<===> - IPSec Tunnel
<===>
Figure 2 : Example of the typical IP Addressing used across the BBF
and Mobile Network for Femto-cell deployment with IPSec Tunneling
As shown in the Figure 2 above, the mobile network identifies the UE
based on the inner-IPv4 address that it assigned to the UE. When the
UE attaches to the FAP, all UE's traffic is encapsulated into FAP's
IPSec tunnel. The outer-IPv4 address of the FAP's IPSec tunnel is
assigned by the BBF network and the IPSec tunnel is terminated at the
FAP and at the SeGW.
If NA(P)T is deployed at the RG, the IPSec tunnel will be
encapsulated by the UDP header in the case of the Tunnel-Mode as
specified in RFC 5996 [RFC5996] operation is applied, the private
outer-IPv4 address of the FAP's UDP encapsulated IPSec tunnel will be
replaced by a public outer-IPv4 address with a possible new port
number which are assigned by BBF's NA(P)T.
So Expires June 12, 2012 [Page 7]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
The BPCF/BNG will be based on the public outer-IPv4 address and the
port number of the UDP encapsulated IPSec tunnel, to perform the
admission control and policy enforcement on the FAP's traffic which
is also the UEs' traffic.
2. Problem statements
Based on the discussions in the previous section, for the FMC
interworking deployment with FAP that involves two different
operators (i.e. fixed and mobile operators), using private IPv4
addressing with NA(P)T enabled in BBF network, one can recognize the
important requirement for the BBF and the mobile networks to
determine the IPv4 address mapping as described in the followings:
- Determine the UE attached FAP's public IPv4 address together
with the translated port number of the UDP header of the
encapsulated IPSec tunnel between the FAP and the SeGW which
are assigned by the BBF. The FAP's public IPv4 address is:
o used for identifying the location of the FAP
o used for identifying the UE's traffic at the BBF network
- Determine the corresponding FAP's public IPv4 address's
association with the UE's inner-IPv4 address which is assigned
by the mobile network. The association is:
o used for identifying the mobile UE that is attached to the
FAP in order to allow the PCRF to retrieve the UE's policy
to be passed onto the BPCF at the BBF network
Based on the typical FAP architecture as described in Figure 1 above,
the only network element that would have the full knowledge of such
mapping is the SeGW.
Unfortunately, in today generic FAP architecture, SeGW has no direct
or indirect interface to the mobile network's policy function or
management function in order to pass on its knowledge of the mapping.
One of the main reasons is because SeGW is not specific designed for
FAP deployment and hence, there is no justification to define
specific interface to the mobile network's policy function or
management function. Never-the-less, it is outside the scope of this
document to discuss the motivation behind such architecture decision.
So Expires June 12, 2012 [Page 8]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
Besides, given the existing deployment for FAP for mobile operator,
it is too late to change the existing architecture which will
introduce backward incompatibility.
Another solution consideration which is based on existing RFC 5389
[RFC5389] - Session Traversal Utilities for NAT (STUN) was examined
to resolve the issue. Unfortunately, it is determined that STUN is
not a good fit given the consideration of the FMC interworking
deployment scenario with FAP. The issues for using STUN for the FMC
interworking deployment with FAP are discussed in the following
section.
2.1. Considerations of STUN support for FMC interworking with FAP
RFC 5389 [RFC5389] STUN client/server solution is not suitable for
FMC interworking deployment with FAP because of the following
reasons.
Assuming the STUN client is implemented at the FAP, there are two
options for the STUN server to be deployed and implemented:
Option-1: STUN server is deployed by the BBF operator at the egress
of the BNG towards the SeGW based on the generic FAP architecture.
There are two main technical challenges with this option:
- Since FAP is a plug and play device, and FAP is not managed by
the BBF operator, an additional solution is required to the
existing RFCs to determine how to support inter-operator STUN
client server discovery.
- The security authentication between the STUN client and server
according to RFC 5389 [RFC5389] is based on either long-term
credential or short-term credential mechanisms. The mechanism
requires either a prior pre-configuration or out-of-band
signaling which would be extremely difficult to implement when
the two network elements are managed by different operators.
The conclusion of this option imposes more technical issues than to
solve the original problem itself. Hence, Option-1 is not
acceptable.
Option-2: STUN server is deployed by the mobile operator
There are two further sub-options considered by this Option-2.
So Expires June 12, 2012 [Page 9]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
a) Integrate the STUN server into the SeGW - this option requires
the STUN server to share the same data path and socket within
the IPSec and IKE processing which is a significant change to
many existing SeGW implementation, backward compatibility is a
major issue.
b) Deploy STUN server as the standalone element at the ingress of
the SeGW - this option requires architecture and procedure
changes to the existing FAP related specification which is
also another major backward incompatibility issue to the
existing architecture.
3. Proposed Solution - Extension to IKEv2 Configuration Payload
After examining many different design options, one particular
solution stands out. The solution requires only minimum changes to
the existing RFC 5996 [RFC5996] - Internet Key Exchange Protocol
Version 2 (IKEv2), and it does not introduce any backward
incompatibility issue to the existing RFC, the existing
specification, the existing architecture and the existing
implementation.
The proposed solution is to leverage the existing IKE Configuration
Payload (CP) that has been supported by many FAP deployments to allow
the IKE-responder (i.e. SeGW) to insert the UDP encapsulated source-
IPv4 address and the optional UDP port number of the UDP encapsulated
IPSec tunnel into the CP, if the IKE-initiator (i.e. FAP) and the
IKE-responder (i.e. SeGW) detect the presence of NA(P)T between them,
and after they are successfully mutually authenticated.
The major advantages of this proposal are as follows:
- Simple extension to the existing IKEv2 RFC 5996 [RFC5996]
o only a new code point is required to be defined for the CP
to indicate the carriage of the source IPv4 address and
port number in the UDP header of the IPSec tunnel.
- Fully compatibility to the existing architecture and procedures
o FAP (i.e. IKE-initiator) has signaling path with the
policy function, the management function as well as with
the network gateway of the mobile network (e.g. PDN
Gateway)
So Expires June 12, 2012 [Page 10]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
o CP is part of the IKEv2 parameters which is generally
supported by existing FAP-SeGW IPSec/IKEv2 authentication
procedures
o Each CP is designed to be standalone and orthogonal to
each other, and hence, no concern for backward
incompatibility to the existing IKEv2 procedures that are
supported by the FAP
- Built-in dynamic update with the existing FAP authentication
procedure to adapt to the changes of the IPv4 address
o Each IPv4 address, even for the network translated IPv4
address will have limited life-span. When the life-span
expires for the given IPv4 address, the IPSec/IKEv2
authentication will be renewed and the same procedures are
executed to enable the IKEv2 peers to obtain the newly
renewed and translated IPv4 address.
- No impact to the existing security mechanisms for the end-to-
end system and the existing protocols
o the new added code point has no impact to the IKEv2
Configuration Payload to continue the use of the existing
IKEv2 security mechanism.
The following Figure 3 describes the high-level control flows on how
the IKEv2 CP is used to carry the public IPv4 address of the UDP
header for encapsulated the IPSec Tunnel.
So Expires June 12, 2012 [Page 11]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
+-------+ +------+ +----------+
| IKE- | |NA(P)T| | IKE- |
|Client | +------+ | Gateway |
+-------+ +----------+
IKE-Initiator IKE-Responder
(e.g FAP) (e.g SeGW)
IKEv2 Message 1 --------------------------->
(HDR, SAi1, Kei, Ni)
<--------------------------- IKEv2 Message 2
(HDR, SAr1, KEr, Nr, [CERTREQ])
IKEv2 Message 3 --------------------------->
(HDR, SK{IDi, [CERT],
[CERTREQ][IDr]CP(CFG_REQUEST),
SAi2, TSi, TSr}) :
:...> CFG_REQUEST: If NA(P)T is detected,
=> EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info
<--------------------------- IKEv2 Message 4
(HDR, SK{IDr, [CERT], Auth,
CP(CFG_REPLY), SAr2, TSi, TSr})
:
CFG_REPLY: If successful authentication <..:
EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info <=
NOTE: EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4 Info includes
Both source IPv4 address and port number that have been
translated by the NA(P)T.
Figure 3 : Example of the IKEv2 Configuration Payload solution to
carry the public IPv4 address and port number of the UDP header for
the encapsulated IPSec tunnel
The details of the proposed changes are described in the following
section.
3.1. Details of proposed changes to RFC 5996 [RFC5996] for IKEv2 CP
New code point and the corresponding descriptions to be added to RFC
5996 [RFC5996], section 3.15, are shown as follows:
NOTE: The new code point is highlighted in a different color.
So Expires June 12, 2012 [Page 12]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
Attribute Type Value Multi-Valued Length
-------------------------------------------------------------------
INTERNAL_IP4_ADDRESS 1 YES 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 YES 17 octets
EXTERNAL Source_IPv4_NAT_Info
16 NO 0 or 6 octets
* These attributes may be multi-valued on return only if multiple
values were requested.
:
:
EXTERNAL_Source_IPv4_NAT_Info - The translated external source IPv4
address and the optional port number of the UDP encapsulated packet
sent by the initiator is requested by initiator in CFG_REQUEST once
the IKE peers detect the presence of NA(P)T in between. If both the
initiator and responder are mutually authenticated, the initiator's
source IP address and the optional UDP port number of the UDP
encapsulated packet will be retrieved by responder and to be included
in CFG_REPLY. This attribute is made up of two fields: the first
So Expires June 12, 2012 [Page 13]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
being an IPv4 address and optionally, the second being an IPv4 UDP
port number. The responder MAY respond with zero or one attribute to
initiator. This is discussed in more detail in Section 3.15.4.
:
:
3.15.4 Configuration Payloads for EXTERNAL_Source_IPv4_NAT_Info
The Configuration payloads is used by the IKE initiator to request
its corresponding IKE responder via the CFG_REQUEST to return its
source IPv4 NAT information, which is composed of the IPv4 address
and the optional IPv4 UDP port number, via the CFG_REPLY.
The IKE initiator will request such information from its
corresponding IKE responder if the presence of NA(P)T is detected via
the NAT traversal procedures in between itself and its corresponding
responder.
If the initiator and the responder are mutually authenticated, the
responder will respond to initiator for the translated initiator's
source IPv4 address and the optional translated source UDP port
number information.
A minimal exchange might look like this:
CP(CFG_REQUEST) = EXTERNAL_Source_IPv4_NAT_Info()
CP(CFG_REPLY) = EXTERNAL Source_IPv4_NAT_Info(198.51.100.234, 233)
4. Security Considerations
The proposed solution is to add a new code point to the already
defined IKEv2 Configuration Payload with no change to the existing
IKEv2 security mechanism that has been used to protect the CP.
5. IANA Considerations
A new code point for IKEv2 Configuration Payload that indicates the
new contents containing the source IPv4 address and source port
number of the IKE-initiator which is assigned by the NA(P)T is
required to be registered with IANA.
So Expires June 12, 2012 [Page 14]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
6. Conclusions
This document explains the issues of the lack of the support in the
FMC architecture to retrieve the mapping of the FAP's public IPv4
address and port number with the inner IP address of the mobile UE
that is attached to the FAP in order to support the FMC interworking
deployment with FAP.
This document discusses the requirements and the solution
considerations to resolve the issue as described above. One solution
is eventually selected as the final proposal which only requires
simple extension to the IKEv2 Configuration Payload as defined in RFC
5996 [RFC5996] to carry the mapping information inserted by the SeGW
(i.e. IKE-responder) and to be passed onto the FAP (i.e. IKE-
initiator). In addition, the solution is backward compatible to the
existing FAP system architecture and signaling procedures.
7. References
7.1. Normative References
[RFC 5996] Internet Key Exchange Version 2, C. Kaulman et al
http://www.rfc-editor.org/rfc/rfc5996.txt
[RFC 5389] Session Traversal Utility for NAT, J. Rosenberg et al,
http://www.rfc-editor.org/rfc/rfc5389.txt
7.2. Informative References
8. Acknowledgments
TBD
So Expires June 12, 2012 [Page 15]
Internet-Draft draft-so-ikev2-fmciwk-ipv4encap December 2011
Authors' Addresses
Tricci So
ZTE USA
9920 Pacific Heights Blvd., STE 400, San Diego, CA, 92121
Email: tso@zteusa.com
So Expires June 12, 2012 [Page 16]
