diff --git a/20. Further Reading/RFC bibliography.md b/20. Further Reading/RFC bibliography.md index 4b8e87e..5c863ca 100644 --- a/20. Further Reading/RFC bibliography.md +++ b/20. Further Reading/RFC bibliography.md @@ -7,7 +7,7 @@ BCPs, Informational and Experimental RFCs. Be *cautious* about old Informational or Experimental RFCs - they may be misleading as well as out of date. -RFCbib6 run at 2023-12-26 16:38:56 UTC+1300 (447 RFCs found) +RFCbib6 run at 2023-12-30 15:29:10 UTC+1300 (447 RFCs found) ### Standards Track (228 RFCs) diff --git a/6. Management and Operations/Multihoming.md b/6. Management and Operations/Multihoming.md index 4825783..9143b09 100644 --- a/6. Management and Operations/Multihoming.md +++ b/6. Management and Operations/Multihoming.md @@ -18,7 +18,11 @@ In 2003, the IETF established goals for site multihoming main goals were: redundancy, load sharing, performance, policy control, simplicity, and transport session survivability. Without describing all the efforts made since then, it is clear that a solution that satisfies -all these goals simultaneously has been difficult to find. +all these goals simultaneously has been difficult to find. A more recent +overview can be found in +[RFC7157](https://www.rfc-editor.org/info/rfc7157). + +### Large sites Today, the most practical approach for a large site, or for a large enterprise network distributed over multiple physical sites, is to @@ -52,10 +56,12 @@ businesses in the USA alone, and 200 million in the world. If every small business suddenly had its own PI prefix, the Internet would stop working. -Therefore, except for some thousands of large enterprises, a viable -solution for multihoming of small or medium enterprises must be based on -PA addresses, if it is to be used by millions of sites. However, as -shown in [the previous section](Multi-prefix%20operation.md), +### Small or medium sites + +Except for some thousands of large enterprises, a viable solution for +multihoming of small or medium enterprises must be based on PA +addresses, if it is to be used by millions of sites. However, as shown +in [the previous section](Multi-prefix%20operation.md), operating with more than one PA prefix at the same time is currently impractical, especially if transport session survivability is required. @@ -103,17 +109,45 @@ change. However, servers will be announced to the outside world via DNS using their translated PA addresses. This method is known to have been successfully tested, although not -recommended by the IETF. +recommended by the IETF. It should be noted, however, that NPTv6 does +not share all the disadvantages of IPv4 NAT. As discussed in RFC 6296, -_Work in progress, to be continued..._ +- NPTv6 does not need to translate port numbers, and it is + checksum-neutral, so the transport layer is effectively unaffected. - +- Translation is stateless, so matters such as asymmetric routing, load + sharing, and router fail-over are not affected. + +- Filtering of unwanted traffic requires an adequate firewall, but this + is true for any serious IPv6 (or IPv4) deployment. + +- Topology hiding, which is sometimes cited as an argument for NAT, is + discussed in + \[[4. Topology obfuscation](../4.%20Security/Topology%20obfuscation.md)\]. + NPTv6 does indeed largely obfuscate local topology. For example (again + following RFC 6296), a host whose actual address is + `fd01:0203:0405:0001::1234` might appear on the Internet as + `2001:db8:0001:d550::1234`. An attacker that does not know the site's + ULA prefix (`fd01:0203:0405::/48`) cannot reverse the translation and + deduce the actual subnet prefix. + +Of course, NPTv6 retains some of the disadvantages of NAT: all of the +problems that directly follow from having different IP addresses at the +two ends of a connection. Any site running NPTv6 must either deal with +these problems, or avoid any affected applications. Section 5 of +[RFC6296](https://www.rfc-editor.org/info/rfc6296) discusses this in +detail. + +### Transport layer solutions + +Another possible approach to site multihoming is to treat it as a +transport layer problem. If a transport protocol is agile enough to use +multiple paths (i.e., multiple source/destination address pairs), +failures at the network layer can be hidden. Multipath TCP (MPTCP, +\[[RFC8684](https://www.rfc-editor.org/info/rfc8684)\]) is defined but +not widely available. A multipath version of QUIC is under discussion, +as is a versatile API for the transport layer that would support +multipath solutions. Discussion continues in the IETF. diff --git a/Citex.md b/Citex.md index 204a837..8412e9b 100644 --- a/Citex.md +++ b/Citex.md @@ -1,7 +1,7 @@ # book6 Citation Index book6 logo -Generated at 2023-12-26 16:39:31 UTC+1300 +Generated at 2023-12-30 15:29:42 UTC+1300 This index was created automatically, so it's dumb. It has links to each section that mentions each citation. @@ -253,6 +253,8 @@ This index was created automatically, so it's dumb. It has links to each section [RFC7123 ●](./4.%20Security/Filtering.md) +[RFC7157 ●](./6.%20Management%20and%20Operations/Multihoming.md) + [RFC7439 ●](./3.%20Coexistence%20with%20Legacy%20IPv4/Tunnels.md) [RFC7454 ●](./4.%20Security/Filtering.md) @@ -345,6 +347,7 @@ This index was created automatically, so it's dumb. It has links to each section [RFC8683 ●](./3.%20Coexistence%20with%20Legacy%20IPv4/Translation%20and%20IPv4%20as%20a%20service.md) [RFC8684 ●](./2.%20IPv6%20Basic%20Technology/Transport%20protocols.md) +[●](./6.%20Management%20and%20Operations/Multihoming.md) [RFC8724 ●](./6.%20Management%20and%20Operations/Energy%20consumption.md) diff --git a/Index.md b/Index.md index fcdd254..8f02aaf 100644 --- a/Index.md +++ b/Index.md @@ -1,7 +1,7 @@ # book6 Main Index book6 logo -Generated at 2023-12-26 16:39:31 UTC+1300 +Generated at 2023-12-30 15:29:42 UTC+1300 This index was created automatically, so it's dumb. It is not case-sensitive. It has links to each section that mentions each keyword. If you think any keywords are missing, please raise an issue (use link on GitHub toolbar). @@ -142,6 +142,7 @@ If you think any keywords are missing, please raise an issue (use link on GitHub [●](./4.%20Security/4.%20Security.md) [●](./4.%20Security/Topology%20obfuscation.md) [●](./6.%20Management%20and%20Operations/Benchmarking%20and%20monitoring.md) +[●](./6.%20Management%20and%20Operations/Multihoming.md) [flow label ●](./2.%20IPv6%20Basic%20Technology/Packet%20Format.md) [●](./2.%20IPv6%20Basic%20Technology/Routing.md) @@ -381,6 +382,7 @@ If you think any keywords are missing, please raise an issue (use link on GitHub [●](./2.%20IPv6%20Basic%20Technology/Packet%20Format.md) [●](./2.%20IPv6%20Basic%20Technology/Traffic%20class%20and%20flow%20label.md) [●](./2.%20IPv6%20Basic%20Technology/Transport%20protocols.md) +[●](./6.%20Management%20and%20Operations/Multihoming.md) [Teredo ●](./3.%20Coexistence%20with%20Legacy%20IPv4/Obsolete%20techniques.md) @@ -406,6 +408,7 @@ If you think any keywords are missing, please raise an issue (use link on GitHub [●](./4.%20Security/Filtering.md) [●](./4.%20Security/Topology%20obfuscation.md) [●](./6.%20Management%20and%20Operations/Multi-prefix%20operation.md) +[●](./6.%20Management%20and%20Operations/Multihoming.md) [wireless ●](./2.%20IPv6%20Basic%20Technology/Address%20resolution.md) [●](./2.%20IPv6%20Basic%20Technology/Auto-configuration.md)