2023-01-11 14:27:31 +13:00
|
|
|
# 5. Network Design
|
|
|
|
|
2024-01-01 14:14:38 +13:00
|
|
|
A first very general remark is that since IPv6 is a datagram protocol,
|
|
|
|
whose routing relies on longest matching of address prefixes, the
|
|
|
|
highest level of design decisions are identical to those for IPv4.
|
2024-01-01 14:09:51 +13:00
|
|
|
|
|
|
|
There is one constraint that does not apply to IPv6: there is
|
|
|
|
effectively no theoretical limit to the number of hosts per subnet.
|
2024-01-01 14:14:38 +13:00
|
|
|
(Mathematically, there is a limit of about 18.10<sup>18</sup> nodes on a
|
|
|
|
/64 subnet, but this is of no practical concern.) However, most network
|
|
|
|
designers will never place hundreds or thousands of hosts on a single
|
|
|
|
subnet, for performance reasons.
|
|
|
|
|
|
|
|
A network designer does, however, have more flexibility with IPv6. If an
|
|
|
|
enterprise has a /48 prefix, 16 bits are available to identify more than
|
|
|
|
65 thousand individual subnets, a luxury for most IPv4 network
|
|
|
|
designers.
|
|
|
|
|
|
|
|
Setting these details aside, there is no reason why an IPv6 network will
|
|
|
|
have a different macroscopic design than an IPv4 network. The detailed
|
|
|
|
approach will vary.
|
|
|
|
|
|
|
|
- If the intention is a "retrofit" where IPv6 support is added to an
|
|
|
|
existing IPv4 network, major topology will not change, but items such
|
|
|
|
as border routers, firewalls, interior routers, and DMZs will need to
|
|
|
|
be upgraded accordingly. Clearly, a specific choice of IPv6/IPv4
|
|
|
|
coexistence mechanism must be made, and applied consistently. In the
|
|
|
|
past, most networks have chosen the original dual-stack approach
|
|
|
|
\[[3. Dual stack scenarios](../3.%20Coexistence%20with%20Legacy%20IPv4/Dual%20stack%20scenarios.md)\]
|
|
|
|
but designers should now also consider
|
|
|
|
[3. Translation and IPv4 as a service](../3.%20Coexistence%20with%20Legacy%20IPv4/Translation%20and%20IPv4%20as%20a%20service.md).
|
|
|
|
A priority will be adding comprehensive IPv6 support to the NOC and
|
|
|
|
all its systems, before deployment to users. An equal priority will be
|
|
|
|
training of all NOC and support personnel: they need to be IPv6
|
|
|
|
evangelists.
|
|
|
|
|
|
|
|
- If the intention is a "greenfield" deployment with no existing IPv4
|
|
|
|
network, the main topology will be conventional, but a specific choice
|
|
|
|
of mechanism for IPv4 as a service must be made
|
|
|
|
\[[3. Translation and IPv4 as a service](../3.%20Coexistence%20with%20Legacy%20IPv4/Translation%20and%20IPv4%20as%20a%20service.md)\].
|
|
|
|
The NOC must be designed from the start based on IPv6, with the
|
|
|
|
ability to manage IPv4 as a service.
|
|
|
|
|
|
|
|
This chapter continues with a discussion of address planning, inevitably
|
|
|
|
combined with subnet design.
|
2023-01-11 14:27:31 +13:00
|
|
|
|
2023-07-20 15:18:59 +12:00
|
|
|
## [Address Planning](Address%20Planning.md)
|
|
|
|
|
2023-01-11 14:27:31 +13:00
|
|
|
<!-- ## Name (add plain section names like that) -->
|
|
|
|
|
|
|
|
<!-- Link lines generated automatically; do not delete -->
|
2023-07-19 14:49:00 +12:00
|
|
|
|
2023-01-11 14:27:31 +13:00
|
|
|
### [<ins>Back to main Contents</ins>](../Contents.md)
|