2022-09-16 11:32:04 +12:00
|
|
|
# 4. Security
|
|
|
|
|
2023-07-19 14:49:00 +12:00
|
|
|
Security has ever-growing importance in general and the IP protocol has
|
|
|
|
been a big area for security research and development. The majority of
|
|
|
|
IPv4 practices remain applicable to IPv6. Exceptions exist for aspects
|
|
|
|
of the first hop and for extension headers that are significantly
|
|
|
|
different in IPv6. Distributed address acquisition (SLAAC,
|
|
|
|
[2. Auto-configuration](../2.%20IPv6%20Basic%20Technology/Auto-configuration.md))
|
|
|
|
creates its own additional security challenges. Multiple addresses per
|
|
|
|
host improve privacy, but not without complications. Extension headers
|
|
|
|
give IPv6 great flexibility and extensibility that may be abused,
|
|
|
|
leading to additional security precautions.
|
|
|
|
|
|
|
|
Initially, it was expected that end-to-end cryptography (encryption and
|
|
|
|
authentication) would be a mandatory part of IPv6 (IPsec,
|
|
|
|
[RFC4301](https://www.rfc-editor.org/info/rfc4301) and SEND,
|
|
|
|
[RFC3971](https://www.rfc-editor.org/info/rfc3971)). This proved
|
|
|
|
unrealistic, so cryptography has been accepted as optional at the
|
|
|
|
networking layer, exactly as it is for IPv4. At the same time,
|
|
|
|
cryptography has become widespread at the transport or application
|
|
|
|
layers.
|
|
|
|
|
|
|
|
IPv6 aims at restoring end-to-end connectivity to the networking layer.
|
|
|
|
Therefore, IPv6 security in no way relies on the presence of network
|
|
|
|
address translation. IPv6 has no standardized NAT66 and even network
|
|
|
|
prefix translation (NPTv6,
|
|
|
|
[RFC6296](https://www.rfc-editor.org/info/rfc6296)) is little used. NAT
|
|
|
|
or NPTv6 provide at best weak security protection at the network
|
|
|
|
boundary, so this is not seen as a defect. The normal approach to
|
|
|
|
boundary security for IPv6 is a firewall; most firewall products support
|
|
|
|
IPv6 as well as IPv4. Topology hiding is addressed in a later section of
|
|
|
|
this chapter.
|
|
|
|
|
|
|
|
Today, the “Zero-trust” approach in security tends to move the stress
|
|
|
|
from perimeter protection to the authentication and encryption for all
|
|
|
|
traffic (including internal for any perimeter). If this approach
|
|
|
|
succeeds, some enterprises may choose to reduce the role of firewalls in
|
|
|
|
future. IPv6 is well positioned for this change.
|
|
|
|
|
|
|
|
There is a good overview of IPv6 security in
|
|
|
|
[RFC 9099](https://www.rfc-editor.org/info/rfc9099). This is a good
|
|
|
|
repository of references to many documents on various IPv6 security
|
|
|
|
aspects.
|
2022-09-16 11:32:04 +12:00
|
|
|
|
|
|
|
<!-- ## Name (add plain section names like that) -->
|
|
|
|
|
|
|
|
<!-- Link lines generated automatically; do not delete -->
|
2023-07-19 14:49:00 +12:00
|
|
|
|
2022-09-16 11:32:04 +12:00
|
|
|
## [Layer 2 considerations](Layer%202%20considerations.md)
|
2023-07-19 14:49:00 +12:00
|
|
|
|
2022-10-19 17:00:42 +13:00
|
|
|
## [Filtering](Filtering.md)
|
2023-07-19 14:49:00 +12:00
|
|
|
|
2023-01-05 09:47:53 +13:00
|
|
|
## [Topology obfuscation](Topology%20obfuscation.md)
|
|
|
|
|
2022-09-16 11:32:04 +12:00
|
|
|
### [<ins>Back to main Contents</ins>](../Contents.md)
|