![](https://csdnimg.cn/release/download_crawler_static/11151384/bg14.jpg)
4 䡲 Security in an IPv6 Environment
At this time, the number of applications with native IPv6 support is signifi cant
given that most important networking applications provide native IPv6 support.
Hardware vendors including Apple Computer, Cisco Systems, HP, Hitachi, IBM,
Microsoft, Nortel Networks, and Sun Microsystems support IPv6. Figure 1.2
depicts an example of a vendor’s roadmap, to illustrate progress being made over
the years in IPv6 support. One should note that IPv6 was designed with security
in mind, but at the current time its implementation and deployment are (much)
less mature than is the case for IPv4. When IPv4 was developed in the early 1980s,
security was not a consideration; now a number of mechanisms have been added to
address security considerations to IP. When IPv6 was developed in the early-to-mid
1990s, security was a consideration; hence a number of mechanisms have been built
into the protocol from the get-go to furnish security capabilities to IP.*
Security considerations continue to be critically important in the networking
and computing space. With the increased number of mission-critical commercial
and military operations being supported via distributed, mobile, always-connected,
*
Some purists will argue (perhaps as an exercise in semantics), that since IPsec is available also
to IPv4, that IPv6 and IPv4 have the same level of security. We take the approach in this text
that since the use of IPsec is mandated as required in IPv6 while it is optional in IPv4, that
at the practical, actual level, “IPv6 is more secure.” We know fi rsthand, for example, of credit
card companies with extranets reaching numerous foreign locations that are supposed to be
using encryption (IPsec) in their wide area IPv4 links when they do transborder transmis-
sion of sensitive personal credit card information, and in fact do not, on the excuse that their
WAN routers are out of “bandwidth points” (well, just get new routers that can support such
bandwidth points and protect sensitive personal credit card information). IPv6 mandates the
use of IPv6, so if IPsec were used in this case, the encryption would be there by design or
default.
Purists would argue philosophical points forever, but we approach the matter pragmatically:
If State A mandated the use of helmets for motorcycle riders and State B does not, we believe
statistics would show that riders are “safer” in State A by actual number of injuries and
deaths; well, riders in State B always have the option of using helmets, but the question is
“what do the actual accidents stats show?” If State A mandated the use of seatbelts for car
riders and State B does not, we believe statistics would show that riders are “safer” in State A
by actual number of injuries and deaths; well, riders in State B always have the option of using
seatbelts, but the question is “what do the actual accidents stats show?” If State A mandated
the use hardhats in construction sites and State B does not, we believe statistics would show
that workers are “safer” in State A by actual number of injuries and deaths; well, workers
in State B always have the option of using hardhats, but the question is “what do the actual
accidents stats show?”
We believe that enough “ink on paper” has been spent here on this semantics issue and pro-
ceed by taking the position that, when everything else is equal, in a narrow abstract sense IPv6
is pragmatically more secure than IPv4. Naturally IPv6 is vulnerable to a multitude of attacks,
infractions, compromises, and penetrations. at is precisely why these authors have written
this book: because there is a need to lay out a plan, an approach, a strategy, a policy, and a
set of tools to protect an IPv6-based infrastructure. e challenge is to make “everything else
equal,” equal fi rewall support, equal Intrusion Detection System (IDS) support, and so forth.
Read on …