mirror of
https://github.com/becarpenter/book6.git
synced 2024-05-07 02:54:53 +00:00
References updated
This commit is contained in:
Brian E Carpenter
@@ -30,9 +30,9 @@ Globally unique IPv4 addresses are now scarce and have signifcant commercial val
|
||||
|
||||
For this reason, when IPv6 usage exceeds a certain threshold, it may be advantageous to start a transition to a next phase and move to a more advanced IPv6 deployment, also referred to as IPv6-only. To be clear, that does not mean removing access to IPv4-only resources. Some method of access to IPv4 resources must be retained, as the primary network infrastructure is switched from a dual stack. In effect the *application layer* in a host will still see a dual stack environment, even if the packets on the link are no longer a mixture of native IPv6 and native IPv4.
|
||||
|
||||
Such solutions are known as "IPv4 as a Service" (IPv4aaS) and can be used to ensure IPv4 support and coexistence when starting the IPv6-only transition for the infrastructure. This can be a complex decision. As mentioned in [a recent draft](https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/) IPv6-only is generally associated with a scope, e.g. IPv6-only overlay or IPv6-only underlay.
|
||||
Such solutions are known as "IPv4 as a Service" (IPv4aaS) and can be used to ensure IPv4 support and coexistence when starting the IPv6-only transition for the infrastructure. This can be a complex decision. As mentioned in [RFC9386](https://www.rfc-editor.org/info/rfc9386), IPv6-only is generally associated with a scope, e.g. IPv6-only overlay or IPv6-only underlay.
|
||||
|
||||
"IPv6-only overlay" denotes that the overlay tunnel between the end points of a network domain is based only on IPv6. IPv6-only overlay in a fixed network means that IPv4 is encapsulated in IPv6 (or translated) at least between the interfaces of the Provider Edge (PE) nodes and Customer Edge (CE) node (or the Broadband Network Gateway (BNG)). As further mentioned in [Tunnels](Tunnels.md), tunneling provides a way to use an existing IPv4 infrastructure to carry IPv6 traffic. There are also translation options described in \[[Translation](Translation.md)]. This approach with IPv6-only overlay helps to maintain compatibility with the existing base of IPv4, but it is not a long-term solution
|
||||
"IPv6-only overlay" denotes that the overlay tunnel between the end points of a network domain is based only on IPv6. IPv6-only overlay in a fixed network means that IPv4 is encapsulated in IPv6 (or translated) at least between the interfaces of the Provider Edge (PE) nodes and Customer Edge (CE) node (or the Broadband Network Gateway (BNG)). As further mentioned in [Tunnels](Tunnels.md), tunneling provides a way to use an existing IPv4 infrastructure to carry IPv6 traffic. There are also translation options described in [Translation](Translation.md). This approach with IPv6-only overlay helps to maintain compatibility with the existing base of IPv4, but it is not a long-term solution
|
||||
|
||||
"IPv6-only underlay" relates to the specific domain, such as IPv6-only access network or IPv6-only backbone network, and means that IPv6 is the network protocol for all traffic delivery. Both the control and data planes are IPv6-based. For example, IPv6-only underlay in fixed network means that the underlay network protocol is only IPv6 between any Provider Edge (PE) nodes.
|
||||
|
||||
@@ -40,7 +40,7 @@ To ensure IPv4 support, the concept of IPv4aaS is introduced and means that IPv4
|
||||
|
||||
[RFC9313](https://www.rfc-editor.org/rfc/rfc9313) compares the merits of the most common IPv6 transition solutions, i.e. 464XLAT \[[RFC6877](https://www.rfc-editor.org/rfc/rfc6877)], DS-lite \[[RFC6333](https://www.rfc-editor.org/rfc/rfc6333)], Lightweight 4over6 (lw4o6) \[[RFC7596](https://www.rfc-editor.org/rfc/rfc7596)], MAP-E \[[RFC7597](https://www.rfc-editor.org/rfc/rfc7597)], and MAP-T \[[RFC7599](https://www.rfc-editor.org/rfc/rfc7599)].
|
||||
|
||||
A framework for carriers is proposed in a current draft [draft-xie-v6ops-framework-md-ipv6only-underlay](https://datatracker.ietf.org/doc/draft-xie-v6ops-framework-md-ipv6only-underlay/). The reader will notice that the solutions most commonly adopted today, such as this one, exploit both the use of tunnels (IPv4 carried over IPv6) and translation (IPv4 re-encoded as IPv6). The following two sections separate out these two techniques.
|
||||
A framework for carriers is proposed in a current draft \[[draft-ietf-v6ops-framework-md-ipv6only-underlay](https://datatracker.ietf.org/doc/draft-ietf-v6ops-framework-md-ipv6only-underlay/)]. The reader will notice that the solutions most commonly adopted today, such as this one, exploit both the use of tunnels (IPv4 carried over IPv6) and translation (IPv4 re-encoded as IPv6). The following two sections separate out these two techniques.
|
||||
|
||||
|
||||
<!-- Link lines generated automatically; do not delete -->
|
||||
|
||||
@@ -18,7 +18,7 @@ It is of the same importance as for IPv4 to restrict who could claim the default
|
||||
There is a new security attack vector related to IPv6 specifically. SLAAC address acquisition is distributed, so the router may not know all addresses configured on the link even if all ND exchange is monitored by the router. Hence, the router needs to request address resolution after the first packet of a new session is received from an external source.
|
||||
At the same time, the IPv6 link address space is huge (2^64) by default. Hence, it is potentially possible to force the router (even from an external network) for address resolution a huge number of times. It is an effective DoS attack that has simple protection measures. [RFC 6583](https://www.rfc-editor.org/info/rfc6583) discusses how to rate-limit the number of address resolution requests or minimize subnet size.
|
||||
|
||||
ND heavily relies on multicast which may create problems in the wireless environment. See [2. Address resolution](../2.%20IPv6%20Basic%20Technology/Address%20resolution.md) and [Multicast efficiency]( https://datatracker.ietf.org/doc/html/draft-vyncke-6man-mcast-not-efficient-01). ND DoS activity may be effective for that reason but the attacker should be local to the link. Hence, perimeter security may help.
|
||||
ND heavily relies on multicast which may create problems in the wireless environment. See [2. Address resolution](../2.%20IPv6%20Basic%20Technology/Address%20resolution.md) and [Multicast efficiency](https://datatracker.ietf.org/doc/draft-vyncke-6man-mcast-not-efficient). ND DoS activity may be effective for that reason but the attacker should be local to the link. Hence, perimeter security may help.
|
||||
The multicast storm is less of a problem in a wireline environment because of MLD snooping typically implemented on the link ([RFC 4541](https://www.rfc-editor.org/info/rfc4541)).
|
||||
|
||||
IPv6 has a new feature that improves privacy. It is normal for an IPv6 host to have many IP addresses for the same interface, often with unpredictable (pseudo-random) IID values. Some IP addresses may be used temporarily ([RFC 8981](https://www.rfc-editor.org/info/rfc8981)) which creates a challenge for intermediate Internet nodes to trace suspicious user activity, for the same reason that it protects privacy.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# book6 Citation Index
|
||||
<img src="./book6logo.png" alt="book6 logo" width="200px" height="auto"/>
|
||||
|
||||
Generated at 2023-04-22 14:21:09 UTC+1200
|
||||
Generated at 2023-05-07 09:51:52 UTC+1200
|
||||
|
||||
This index was created automatically, so it's dumb. It has links to each section that mentions each citation.
|
||||
<!-- Link lines generated automatically; do not delete -->
|
||||
@@ -352,7 +352,8 @@ This index was created automatically, so it's dumb. It has links to each section
|
||||
[●](./3.%20Coexistence%20with%20Legacy%20IPv4/Dual%20stack%20scenarios.md)
|
||||
[●](./3.%20Coexistence%20with%20Legacy%20IPv4/Translation.md)
|
||||
|
||||
[RFC9386 ●](./8.%20Deployment%20Status/Deployment%20by%20carriers.md)
|
||||
[RFC9386 ●](./3.%20Coexistence%20with%20Legacy%20IPv4/Dual%20stack%20scenarios.md)
|
||||
[●](./8.%20Deployment%20Status/Deployment%20by%20carriers.md)
|
||||
[●](./8.%20Deployment%20Status/Deployment%20in%20the%20enterprise.md)
|
||||
[●](./8.%20Deployment%20Status/Status.md)
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# book6 Main Index
|
||||
<img src="./book6logo.png" alt="book6 logo" width="200px" height="auto"/>
|
||||
|
||||
Generated at 2023-04-22 14:21:09 UTC+1200
|
||||
Generated at 2023-05-07 09:51:52 UTC+1200
|
||||
|
||||
This index was created automatically, so it's dumb. It is not case-sensitive. It has links to each section that mentions each keyword.
|
||||
<!-- Link lines generated automatically; do not delete -->
|
||||
|
||||
Reference in New Issue
Block a user