Securing IPv6 Network Infrastructure:
A New Security Model
Abdur Rahim Choudhary
SEGMA Technologies Inc., 8070 Georgia Ave., Suite 402,
Silver Spring, MD 20910, USA.
arc@ieee.org
Abstract—Nation’s network infrastructure such as the Global
Information Grid (GIG) for the Department of Defense (DoD)
and the OneNet for the Homeland Security Department are tran-
sitioning to the Internet Protocol version 6 (IPv6) per DoD CIO
Memorandum of June 2003 and the Office of Management and
Budget memorandum OMB-05-22. There exist IPv6 specific se-
curity vulnerabilities in these network infrastructures that need
to be mitigated in order to achieve security parity with the exist-
ing IPv4 operations. From the perspective of the Homeland Secu-
rity technologies, the existence of additional security vulnerabili-
ties implies a possibility for two pronged threats. First, the IPv6
specific vulnerabilities reduce the security posture of the network
infrastructure itself; second, other critical infrastructure sectors
that depend on IPv6 need additional protection. For example, the
future supervisory control and data acquisition (SCADA) indus-
trial capabilities would increasingly use the IPv6 infrastructure,
as would the voice communications, the voice and video collabo-
ration, and sharing of data such as the image data and surveil-
lance and reconnaissance data.
This paper presents three contiguous results. First, it briefly pre-
sents the new IPv6 capabilities; second, it presents a brief analy-
sis of the security vulnerabilities arising from these capabilities;
and third, it presents a new security model for IPv6 network in-
frastructures that has the potential to mitigate these vulnerabili-
ties. The new model is based on the end-to-end connectivity that
is restored in IPv6, thus allowing the use of host based security
(HBS) systems together with the perimeter security devices.
However, the use of HBS complicates the security trust manage-
ment. Therefore the third component of the model is introduced,
namely a policy based security management (PBSM) approach.
The PBSM approach allows the secure deployment of the host
based security systems. It provides the capabilities needed to spe-
cify the trust zones via a set of security policy rules that together
specify a trust zone. Hosts belong to one or more trust zones.
Accordingly, the host based security policies are derived from the
zone security policies for all the zones to which a host belongs.
In addition, the PBSM approach has the potential to support
more sophisticated security capabilities such as a risk adaptive
access control and dynamic security response to a changing op-
erational picture. The capabilities are needed to enable net-
centric security operations.
Keywords-component; IPv6 Security; Security Vulnerabilities;
Security Model, Trust zones.
978-1-4244-6048-9/10/$26.00 ©2010 IEEE
Alan Sekelsky
IT & Professional Services
Serco North America
1818 Library Street, Suite 1000, Reston, VA 20190, USA.
Alan.Sekelsky@serco-na.com
I. INTRODUCTION
The presidential decision directive number 63 on critical in-
frastructure protection (CIP) includes physical as well as in-
formation and communications infrastructure. This paper fo-
cuses on the protection of the information and communications
sector. This sector is increasingly founded on the Internet Pro-
tocol (IP). Memorandum 05-22 from the office of management
and budget requires this sector to transition to IP version 6
(IPv6). Accordingly, the civilian federal agencies as well as the
department of defense (DoD) are adopting IPv6 for their net-
work infrastructure, such as the OneNet in the department of
Homeland Security and the Global Information Grid (GIG) in
the DoD. This encompasses the core networks, the local area
networks, international partners’ networks, wired and wireless
networks, satellite communications (SATCOM) networks, and
tactical operations networks such as those deployed in a battle-
field or an emergency response operation. The security of IPv6
protocol is therefore of fundamental significance within the
framework of the critical infrastructure protection. The reasons
are many: first, the cyber infrastructure is founded on IPv6;
second, the supervisory control and data acquisition (SCADA)
capabilities for industrial control and monitoring systems
would increasingly depend upon the cyber infrastructure; third,
IPv6 is the basis for vital services such as the voice communi-
cations, the voice and video collaboration, and sharing of data
such as the image data and the surveillance and reconnaissance
data.
This paper focuses on the protection of infrastructure and
communications sector with respect to IPv6 specific security
vulnerabilities, and proposes a new security model for IPv6
network infrastructure to mitigate these vulnerabilities. The
model is flexible, extensible, and scalable to enable security
management capabilities for the future net-centric operations.
II. IPV6 SECURITY VULNERABILITIES
As analyzed in references [1, 2] most of the vulnerabilities
are common between IPv4 and IPv6. Additional vulnerabilities
do exist [3] that arise because of the changes that were made in
IPv6 [4] specification relative to the IPv4 [5] specification.
These changes are summarized below:
x IPv6 uses a 128 bit address space versus a 32 bit ad-
dress space in IPv4.
500
 x The IPv6 routers no longer perform packet fragmenta-
tion and reassembly; all packet fragmentation and reas-
sembly in IPv6 is performed by the sender and receiver
hosts.
x A new plug-and-play type capability, namely the state-
less address autoconfiguration capability, is introduced
to automatically configure IPv6 addresses on new
nodes, which reduces the administrative burden of ma-
nually configuring them. Additional IPv6 protocols are
introduced for this purpose.
x The above two changes meant that the use of Internet
Control Message Protocol (ICMP) was now required,
versus its optional use in IPv4.
x Support for extension headers is required in IPv6 net-
works. According to the IPv6 specification [4] a full
implementation must include support for the following
six extension headers: hop-by-hop options header, des-
tination options header, routing header, fragment head-
er, authentication header (AH), and encapsulating secu-
rity payload (ESP) header. The last two headers are the
components of IP security (IPsec) [6] the support for
which is therefore required under IPv6 specification 1 .
These changes provide powerful capabilities to an IPv6
network infrastructure. However, they also give rise to new
security vulnerabilities which we summarize below.
A. Hop-by-hop Options
The hop-by-hop options header can have any number of
hop-by-hop options, and any option can appear multiple times.
An attacker can deliberately use inconsistent option values or
invalid options in a hop-by-hop option header. In such situa-
tions ‘Parameter Problem’ ICMPv6 error messages are issued
to the sender. An attacker can burden the routers by flooding
with such maliciously crafted packets, causing a DoS attack.
There is another vulnerability related to the options in a
hop-by-hop options header. The header uses Pad1 and PadN
options and these padding bytes must be zero filled. However
there is no requirement for the receivers or the routers to verify
the correct implementation of that. The options in a hop-by-hop
options header may therefore serve as a covert communication
channel. This can happen via non zero filled padding bytes. It
can also happen because of the pattern in which padding and
other options are used. Such a pattern may itself communicate
covert channel information. For example, using multiple
Pad1’s instead of a single PadN, or a PadN followed by a Pad1
may communicate information.
1 messages. Firewalls with the needed IPv6 filtering capabilities
Subsequently this support was somewhat weakened when IETF
IPv6 security architecture downgraded the requirement for the sup-
port of AH from MUST to MAY. The mandatory support for IPsec in
IPv6 has sometimes been interpreted, though incorrectly, to mean that
IPv6 is more secure than IPv4. In reality the use of IPsec is equally
available for both protocols So that a consensus view today is that
IPv6 is neither more secure nor less secure than IPv4. Depending
upon how seriously one regards the new IPv6 specific security vul-
nerabilities, some researchers might argue that IPv6 is less secure
than IPv4.
501
B. Autoconfiguration
State-Less Address Auto Configuration (SLAAC) [7] is a
distinguishing feature of IPv6. However, SLAAC also raises
serious security concerns. One of the concerns about SLAAC is
its trust model with respect to the network trusting a node that
autoconfigures itself [8]. A node can acquire a link-local ad-
dress and subsequently a globally routable address without any
approval or control. A new IPv6 node that autoconfigures itself
is allowed an unchecked access to the link. This unchecked
access is not limited to the local link because a node can subse-
quently acquire a global prefix using solicitation and adver-
tisement ICMPv6 messages for Neighbor Discovery (ND) [9].
Combining the global prefix with the link local address, the
node can construct a globally routable address and start using it
without any approval or control.
This trust model introduces serious security vulnerabilities
and possibilities of attacks [8]. As discussed in this reference,
there are about a dozen types of attacks that are possible on the
autoconfiguration feature of IPv6. A variety of approaches are
required to mitigate these risks: the on-link ND messages
should be filtered at the boundary [10]; the SEND protocol
[11] should be used to avoid attacks that use address spoofing;
and other filtering mechanisms [12, 13] can be applied.
C. Multiple Addresses
IPv6 assigns multiple addresses to an interface which chal-
lenges the filtering rules in the firewalls and access control
lists. This is because, unlike IPv4, address based filtering is no
longer feasible when these addresses are autoconfigured, and
when privacy addresses are used (privacy addresses change
periodically). In such cases, a firewall will need to learn all the
addresses dynamically and the filtering rules will need to be
automatically generate-able using sophisticated policy rule-
sets. Such capabilities are not available. Therefore simpler for-
malisms must be employed that use some kind of identification
tokens instead of addresses in order to identify a host or an
interface. No such identification mechanism is currently de-
fined at OSI layer 3.
D. ICMPv6 Filtering
The use of ICMPv4 messages in IPv4 is optional. It is not
required for normal network operation. Many IPv4 network
security administrators block all ICMPv4 messages. This blan-
ket blocking is not possible for IPv6 networks because basic
IPv6 network operation require the use of ICMPv6 messages.
Therefore specific ICMPv6 traffic must be allowed and the
IPv6 firewalls must not apply a blanket blocking of ICMPv6
are not yet available.
Since some ICMPv6 traffic must be allowed, an attacker
can use deliberately malformed ICMPv6 packets to cause error
responses that spuriously utilize network resources. IPv6 sends
the ICMPv6 messages also to multicast addresses, which offers
a potential for DoS attack through packet amplification.
E. IPv6 Tunneling
The specification for tunneling IPv6 via IPv4 [14] has been
analyzed for security issues [15]. These attacks are made pos-
sible because all 6to4 capable routers regard other 6to4 routers
and relays as being “on-link”. The assumed trust between the
6to4 routers and relays leads to attacks that can be directed at
the 6to4 networks, IPv4 networks, or IPv6 networks. In addi-
tion, “meta-threats” are also possible in which case some other
attack is laundered hidden into the 6to4 traffic.
el is used for IPv6, additional security measures will be re-
quired in IPv6 networks in order to secure them against the
new set of vulnerabilities, and to achieve an IPv6 security pos-
ture that is at parity with IPv4. For this purpose, more capable
IPv6 network and security management tools are needed. This
translates into additional cost and engineering effort just to
acquire security parity with IPv4. If this course is taken, the
current limitations such as the handling of encrypted packets
and the application data that exist in IPv4 security would con-
tinue in IPv6 as well.

F. Future Extension Headers
New extension headers can be added to the IPv6 specifica-
tion, and new options can be added to the hop by hop options
header. This can impact the security policy of an enterprise.
After a security policy has been formulated and deployed, in-
troduction of a new IPv6 extension header will make it neces-
sary to revise the security policy, its deployment, and the selec-
tion of the security tools. The effectiveness of the deployed
security policies can be reduced, causing possible security vul-
nerabilities.
III. A NEW SECURITY MODEL
The previous section shows that there exist serious IPv6
specific security vulnerabilities. If the traditional security mod-
Host Based
Security
To overcome these limitations one could use a new security
model for the IPv6 network infrastructure. There are three addi-
tional motivations for this. First, the current security model that
is based on perimeter protection has serious limitations in sup-
porting end-to-end connectivity, tunneling and encryption [16].
Second, there is expectation of more challenging security re-
quirements [17] that the emerging net-centric operations will
demand. Third, a modified version of the model can potentially
be used to protect the other sectors, than the information and
communications sector, in nation’s critical infrastructure. The
latter point will evolve as the industrial SCADA and Distrib-
uted Control Systems (DCS) technologies get adapted to stan-
dardization and an ubiquitous IPv6 network infrastructure [18].
Figure 1 below schematically illustrates the new security
model for IPv6 network infrastructure. The components of the
model are defined in subsections that follow.

Digital
Policies
Host
Policy Server

PBSM

En
dt
Perimeter Based oe
Security nd
ad Host Based
dr Security
es
sa
bil
i ty

Perimeter Based
Security

End-to-end Connectivity Host

Policy Flows

Figure 1. Figure 1: Schematics and Components of a new IPv6 Infrastructure Security Model

502
A. End-to-end addressability
The end-to-end addressability in IPv6 networks is the basic
enabling feature for this security model. The solid line in figure
1 represents the end-to-end addressability between two hosts.
The end-to-end concept [ 19 ] is rather amorphous, but from
security point of view it means that the endpoints can be di-
rectly addressed and they are generally best suited to analyze
the security consequences of the contents of a packet that they
send or receive. Substantial security burden in this model is
therefore placed on the end hosts, and the use of host based
security (HBS) measures described in section B are thus neces-
sitated.
End-to-end addressability enables the following operations
which are necessary for the new security model.
x The central policy server for a trust zone (see section
D) can push appropriate digital policies (policy rule-
sets expressed in a computer language) to the network
elements within the zone. The server can also send un-
solicited policy directives and notification conditions
(such as thresholds, bounds, and trap conditions) to the
network elements.
x Communications are possible for the security auditing
part of the policy based security management (see sec-
tion E) to request node configuration status and send
node auditing directives.
x Policy decision point (see section E) can request in-
formation on the local decisions made by the node.
These are unsolicited communications. They are well sup-
ported in IPv6 networks, but they are generally not possible
with nodes and hosts that are behind a network address transla-
tor (NAT) with respect to a sender as is often the case in IPv4
networks. In other words, IPv6 supports end-to-end address-
ability while IPv4 networks with NATs based configurations
often break the end-to-end addressability between a policy
server and policy managed objects.
B. Host Based Security
In an end-to-end security model substantial security burden
is placed on the end hosts. This situation is not unwelcome
because hosts are generally best suited to analyze the security
consequences of the contents of a packet that they send or re-
ceive. The situation however necessitates the deployment of
host based security (HBS) measures. Because the enterprise
security in this model largely depends on the success of these
measures strict enforcement of host security configurations
becomes paramount. This strict enforcement is achieved using
the concepts of the trust zones and the policy based security
management.
This section discusses HBS mechanisms and how the HBS
components should integrate. The specification of the trust
zones is discussed in section D and their use in policy based
security management is discussed in section E.
Figure 1 shows two hosts communicating with one another,
and with the policy server. The solid line in figure 1 represents
503
the end-to-end connection between the hosts, while the dashed
lines represent the policy flows between the policy server and
the network elements, including the host and the host based
security modules. The two hosts can belong to different trust
zones (see section D). Therefore different graphics are used in
figure 1 for the two hosts and the associated HBS modules. An
implementation may choose to integrate in one appliance both
the host and the associated HBS, but logically they remain dis-
tinct entities as is depicted in figure 1.
The security measures in the HBS go far beyond the current
security practices in hosts. It now combines the functionalities
of the host intrusion detection/prevention as well as the net-
work intrusion detection/prevention. These capabilities are
deployed in regular hosts and routers, as well as in dedicated
security manager hosts whose primary function is to apply fil-
ters and manage intrusions. Such dedicated hosts are also
placed at the network perimeters, so that perimeter based secu-
rity discussed in section C should be considered as part of the
HBS measures, in a distributed HBS sense [20].
Some desirable features for HBS are summarized below.
x The HBS should provide centralized management of
security and security policy administration, and it
should be automatable where appropriate. These and
other functions are performed for HBS by the policy
based security management (PBSM) module shown in
figure 1 and discussed in section E.
x HBS should have a capability to audit the security pol-
icies. This typically means the following: (a) the integ-
rity of the policies should not be compromised, (b) the
system configurations should be flagged when they are
at deviance with the currently deployed security poli-
cies, (c) a policy validation function should ensure that
the policies perform the functions that they are in-
tended to perform, and (d) it should be possible to
compare the policy performance data with the opera-
tional efficiency data to improve the performance of
the policy controlled functions. In the current model
the policy audit function is included as part of the
PBSM discussed in section E.
x All components for HBS should be interoperable
across the enterprise. For example the components for
virus control, intrusion management, event analyzer,
security policy manager, security auditor, data formats
and semantics, and zone level security server should all
be interoperable. This interoperability means that the
components will interface correctly, exchange opera-
tional data and interpret their semantics correctly, and
provide such data to external systems for security mon-
itoring and auditing as required. An example of the lat-
ter is the Einstein intrusion detection/prevention system
that accepts input from the computer systems of the
U.S. Federal agencies and processes the information
for computer incidence response center (CIRC) [21].
The security incidences should be analyzed in at least
two ways. First is the local analysis to understand the
security of the local operations. Second is the analysis
at the zone level to correlate and investigate incidences
 from all the relevant hosts within the trust zone. The
results of the analysis can be fed back to the policy
evaluation process [22] to facilitate a feedback loop,
and to help with some of the policy auditing functions.
It is desirable that HBS components be based on com-
mercial off the shelf systems because the number of
deployments may be large and commercial systems
cost relatively less and their capabilities evolve natu-
rally under market forces. These components should be
managed from a centralized management system, and
made secure by the use of appropriate security policies.
The HBS operations should not impact the perform-
ance of the host with respect to the primary tasks that
the host is intended to perform. Thus the HBS should
function without performance degradation of the pro-
tected system.
C. Perimeter Based Security
The use of host based security (HBS) does not disallow the
use of perimeter based security measures. If required, firewall
filtering and intrusion analysis devices can still be used at the
perimeter. Figure 1 explicitly shows the use of perimeter secu-
rity devices. They are a distributed part of the HBS. There is,
however, one important caveat: the perimeter security devices
in this model do not reassemble the fragmented packets and
they do not decrypt packets that the sending hosts encrypted.
It remains a topic of further research if the use of high as-
surance Internet Protocol Encryptor (HAIPE) devices [23] is
admissible because the answer depends on the HAIPE deploy-
ment architecture, the application and the mission. There ap-
pears to be no a priori conflict if HAIPE is deployed as usual at
the boundary of the ‘red’ network and the ‘black’ core in the
2 The basic policy based management architecture [25] pro-
global information grid (GIG) .
D. Trust Zones
As stated earlier, the use of HBS requires assurance that the
security configurations of the hosts will be strictly enforced in
accord with the enterprise security policies. This assurance is
provided via the trust zones, as is discussed below.
A trust zone is defined in terms of the security policies that
apply to the elements in that zone. Each host or network ele-
ment belongs to at least one trust zone. When a network ele-
ment belongs to more than one trust zones, it is administered by
applying the security policies for all those zones. The zone
policies are applied strictly and uniformly to all hosts, routers,
security devices and applications. This is shown by the dotted
lines in figure 1 representing the flow of appropriate trust zone
policies to the corresponding network elements. In general,
security policies are different for different nodes. Thus the
policies for the two edge routers are different because they
connect to different set of customers. Similarly the two hosts
belong to two different trust zones and therefore receive differ-
ent set of security policies. The two host Based Security sys-
tems are controlled by different security policies because they
2
Department of Defense Directive Number 8100.1, September 19
2002.
504
are part of different trust zones and they have different configu-
rations with respect to the peripherals. The figure does distrib-
ute identical policies to the two interior routers assuming they
are identically configured under the same autonomous system.
For host based security to work it is necessary to ensure that
a host’s security configuration is accurate and uses the uniform
semantics of the trust zone. It is not enough just to configure
the hosts with correct security configurations, it is even more
important to assure that the enforcement of these configurations
be accurate and flawless. The configuration of the hosts and
their enforcement is implemented using the security policies
that govern the trust zone to which a host belongs. The security
policies of a trust zone are deployed through the policy man-
agement processes. The policy based security management
(PBSM) technology [24] discussed in section E provides the
necessary enforcement functions for the trust zone security
policies, and the automation of those functions. While the trust
zones formally define the security policies that apply to a host,
PBSM ensures that the correct policies are used, each policy is
interpreted and evaluated in a consistent way, and each policy
is enforced strictly without lapses.
The new security model for the IPv6 infrastructure thus
uses a trust model for the enterprise security which is very dif-
ferent from the one used by the current perimeter based secu-
rity.
E. Policy Based Security Management
The policy based security management (PBSM) [25] im-
plements the policy functions, automates them, evaluates and
executes policies, and ensures that the trust zones are enforced
strictly, uniformly, and flawlessly.
vides the essential components for PBSM, namely policy ad-
ministration, policy decision points (PDP), and policy execu-
tion points (PEP). Policy audit [24] should be added to this set
of components.
PBSM translates those security policies that define a trust
zone into policy rule-sets that are implementable into a com-
puter language. This implies a translation from the executive
policy directives to a set of ‘digital policies’ that can be inter-
preted and evaluated by computers. The digital policies are
distributed to the PDPs where they are evaluated to arrive at
unique and unambiguous policy actions. The policy actions are
strictly enforced via the PEPs.
PBSM thus implements a trust zone by implementing and
enforcing the security policies that specify the trust zone. It also
helps organize the trust zones within an enterprise. This organi-
zation can be hierarchical, in which case PBSM can provide a
means to inherit the digital policies of a higher level trust zone
into a lower level trust zone. In another context the trust zones
may be overlapping, in which case PBSM provides a mecha-
nism where a common set of security policies applies across
the objects belonging to the overlap. In the latter case, the set of
security policies that specify the various trust zones must be
mutually consistent and compatible in order to apply their sum
to the managed objects belonging to the overlap of the trust
zones. This requires a capability to deconflict the security poli-
cies.
Membership in a trust zone defines a clear mechanism to
select the digital policies that apply to a particular network
node. Thus the security policies can be automatically selected,
evaluated, and applied to a network node in a given security
operation.
Some of the above mentioned PBSM architectural features
are illustrated in figure 2. It shows how a policy server can be
used to manage trust zones and use the trust zones to manage
their member objects via an appropriate set of PDPs. Each
managed object has its own PEP that is controlled by its PDP.
The PDP and PEP can use common open policy services
(COPS) protocol specified at the IETF [ 26 ] and the Policy
Server can use RFCs 2940, 3084, and 3483 respectively to de-
fine managed objects [27] under COPS, to provision policies
[28], and to use COPS for policy auditing [29].
Trust
Zone Zone #2
Trust
Security
Policies Zone Zone Zone #3
Member Member
Objects Objects Policy
Zone
Security Server
Policies
PDP Zone 1
PDP Zones 2 and 3
PEP PEP
A B
Managed Object A Managed Object B
Figure 2: High level PBSM architecture
Not shown in figure 2 are the PBSM features like the Policy
Auditing and how it helps make the security decisions sensitive
to the operational context [30] and responsive to a changing
operational picture. This agility comes from three main
sources: first, the policy rule-sets can be changed and applied
without a need to change the operational software code; sec-
ond, the decision logic in the PDPs can be made dependent on
the near-real-term parameters, and; third, different algorithms
to make the security decisions can be selected based on the
changed operational picture.
The number of policy servers and PDPs as well as their
physical and logical locations are matters of PBSM design. It is
a design choice for an enterprise to decide which policies are
distributed to which PDPs by which PBSM servers. For exam-
ple, an enterprise may deploy a separate PBSM server to dis-
tribute policies to a defined conglomerate of trust zones. Figure
2 shows a Policy Server that controls three trust zones which
are managed using two PDPs. The more mundane features of
PBSM are the policy definition, policy translation, policy de-
confliction, policy distribution, policy evaluation, policy execu-
tion, and policy auditing. These are important functions that are
not discussed in this paper because they are already adequately
addresses in the literature [31].
F. Other Capabilities
Other security capabilities, including the ones that exist for
the IPv4 networks, remain available for the new security model
for IPv6 network infrastructure. These capabilities can be used
even if they are not explicitly discussed here, provided they are
not inconsistent with the use of the components described
above. Such capabilities can be used to mitigate IPv6 specific
vulnerabilities or vulnerabilities that are common to both pro-
tocols [2]. Examples of such capabilities include the use of
IPsec, HAIPE, SEND, cryptographically generated addresses
(CGA), special purpose addresses, port filtering, firewalling,
IDS, IPS, and anomaly analysis.
IV. CONCLUSIONS
The changes made in specifying IPv6 protocol relative to
IPv4 have provided powerful new capabilities. However, they
Zone Trust have also given rise to a set of IPv6 specific security vulner-
Security
Policies Zone #1 abilities. These vulnerabilities must be mitigated in order to
Zone achieve operational parity with the IPv4 networks. This means
Member
Objects that the vendors must provide security devices with additional
capabilities for packet filtering and intrusion management. In
addition, network engineering is needed for the IPv6 security
architecture of an enterprise. The additional cost and engineer-
ing effort still achieves only parity with IPv4: it does not re-
solve the currently unresolved security issues in IPv4 networks
such as the support for end-to-end connectivity, encryption, and
tunneling; nor does it support capabilities for net-centric opera-
tions.
PEP
C
The paper therefore argues that a new security model for
Managed Object C
IPv6 infrastructure is needed to save cost and to take security
beyond merely achieving parity with IPv4. Such a security
model is constructed using six components: the end-to-end
addressability, host based security, perimeter based security,
trust zones, policy based security management, and other com-
ponents. All the components of the model are achievable using
today’s technologies, though some of them use emerging tech-
nologies like policy based security management. Based on an
understanding of the component technologies, it is argued that
the model is flexible, extensible, and scalable to meet the secu-
rity requirements of future net-centric operations.
V. ACKNOWLEDGMENTS
Dr. Choudhary thanks Yasmeen Sultana for encourage-
ment. Mr. Sekelsky thanks Serco North America for support.
505
 VI. REFERENCES [17] A. Rahim Choudhary, “Network Management Requirements for
Net-Centric Systems”, Military Communications (MILCOM), San
Diego, CA, November 2008.
[1] Lancaster, Troy, “IPv6 and IPv4 Threat Review with Dual Stack
Considerations”, COMP6009: Individual Research Project, Univer- [18] National Institute of Standards and Techmology/National Tele-
sity of Southampton, Department of Electronics and Computer Sci- communications and Information Administration, “Technical and
ence, UK, 2006. Economic Assessment of Internet Protocol version 6 (IPv6)”, IPv6
Task Force, January 2006.
[2] Convery, Sean and Miller, Darrin, “IPv6 and IPv4 Threat Compari-
son and Best Practices Evaluation (v1.0), Cisco Corporation, 2004. [19] IETF RFC 2775, “Internet Transparency”, February 2000.
[3] A. Rahim Choudhary, “In-Depth Analysis of IPv6 Security Pos- [20] S. Loannidis, A. Keromytis, S. Bellovin, J. Smith, “Implementing
ture”, 4th International Workshop on Trusted Collaboration at 5th In- a Distributed Firewall”, Proceedings of the 7th ACM Conference on
ternational Conference on Collaborative Computing, Crystal City, Computers and Communications Security, Athens, Greece, 2000.
VA, November 2009. [21] Hugo Teufel III, Department of Homeland Security, “Privacy Im-
[4] IETF RFC 2460, “Internet Protocol, Version 6 (IPv6) Specifica- pact Assessment for Einstein 2”, May 19, 2008.
tion”, December 1998. [22] O. Patrick Kreidl and Tiffany M. Frazier, “Feedback control ap-
[5] IETF RFC 791, “Internet Protocol, DARPA Internet Program, plied to survivability: A host-based automatic defense system”,
Protocol Specification”, September 1981. IEEE Transactions on Reliability, vol. 53, p. 148 – 166, 2004.
[6] IETF RFC 4301, “Security Architecture for the Internet Protocol”, [23] G. Nakamoto, “Scalable HAIPE Discovery”, proceedings of Visu-
December 2005. alizing Network Information, NATO RTO-MP-IST-063, Neuilly-
sur-Seine, France, 2006.
[7] IETF RFC 4862, “IPv6 Stateless Address Autoconfiguration”,
September 2007. [24] A. Rahim Choudhary, “Policy based management in the Global
Information Grid”, Int. J. Internet Protocol Technology vol. 3, p. 73
[8] IETF RFC 3756, “IPv6 Neighbor Discovery (ND) Trust Models
– 80, 2008.
and Threats”, May 2004.
[25] A. Rahim Choudhary, “Policy Based Network Management”, Bell
[9] IETF RFC 4861, “Neighbor Discovery for IP version 6 (IPv6)”,
Labs Technical Journal Vol. 9, pp. 19-29, 2004.
September 2007.
[26] IETF RFC 4261, “Common Open Policy Service (COPS) Over
[10] IETF RFC 4890, “Recommendations for Filtering ICMPv6 Mes-
Transport Layer Security (TLS)”, December 2005.
sages in Firewalls”, May 2007.
[27] IETF RFC 2949, “Definitions of Managed Objects for Common
[11] IETF RFC 3971, “Secure Neighbor Discovery (SEND)”, March
Open Policy Service (COPS) Protocol Clients”, October 2000.
2005.
[28] IETF RFC 3084, “COPS Usage for Policy Provisioning (COPS-
[12] IETF Internet Draft draft-nward-ipv6-autoconfig-filtering-ethernet-
PR)”, March 2001.
00, March 4, 2009.
[29] IETF RFC 3483, “Framework for Policy Usage Feedback for
[13] Orla McGann, “IPv6 Packet Filtering”, a Master’s Thesis at De-
Common Open Policy Service with Policy Provisioning (COPS-
partment of Electrical Engineering, National University of Ireland
PR) “, March 2003.
Maynooth, Supervised by David Malone, January 2005.
[30] A. Rahim Choudhary and J. O. Odubiyi, “Context Based Adaptive
[14] IETF RFC 3056, “Connection of IPv6 Domains via IPv4 Clouds”,
Control in Autonomous Systems”, Proceedings of IEEE Informa-
February 2001.
tion Assurance Workshop, US Military Academy, West Point, NY,
[15] IETF RFC 3964, “Security Considerations for 6to4”, December June 2004.
2004.
[31] J. Strassner, “Policy Based Network Management: Solutions for the
[16] IETF Internet Draft draft-vives-v6ops-ipv6-security-ps-03.txt, Next Generation”, The Morgan Kauffman Series in Networking,
February 2005. ISBN 1-55860-859-1, Elsevier, 2003.

506