This repository has been archived by the owner on Jul 28, 2019. It is now read-only.
IPv6: Adjust subnet prefix used for NAT64. #222
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
k8s-ci-robot
added
cncf-cla: yes
pmichali
force-pushed
the
nat64-prefix
branch
from
be9a7cb
to
2a5db7a
Compare
k8s-ci-robot
added
size/L
This commit does several things related to the NAT64 prefix, as specified by the NAT64_V4_SUBNET_PREFIX environment variable. This prefix is for a /16 subnet. First, we want the prefix to be within one of the two private network ranges (172.16.0.0/12 or 10.0.0.0/8). Second, to accommodate that, the NAT64_V4_SUBNET_PREFIX will be two octets, instead of one. The default, if not specified, will be 172.18, to avoid docker usage of that private network. Third, the code will range check the prefix, to ensure that it is within range, based on the private network selected. 172.16 to 172.31 or 10.0 to 10.253 values are allowed. Fourth, the cluster ID is added to the prefix, so that a unique subnet is used for each cluster. This affects the allowable values for the prefix. For 172.16.0.0/12, the prefix plus cluster ID must be from 172.16 to 172.31. For 10.0.0.0/8, the prefix plus cluster ID must be from 10.0 to 10.253. So, for example, if the default 172.18 is used, then cluster IDs can be from 0 to 13. Another side effect of this change is w.r.t. legacy mode, where the user specifies (only) the DIND_LABEL. In that case, a cluster ID is generated, and we now will use numbers from 1..13 to help keep the values within the range for the V4 mapping prefix (using 13 instead of 15 as the default prefix is 172.18). If the user wants to use the legacy DIND_LABEL, but have a larger range for cluster IDs, they can set the NAT64_V4_SUBNET_PREFIX to the 10.0.0.0/8 subnet and/or explicitly set the CLUSTER_ID. For the multicluster IPv6 CI test, it creates a cluster using the default cluster ID (0), one with cluster ID specified (20), and legacy mode with q cluster ID generated between 1..13. Since the default prefix is 172.18, the second cluster will create a prefix (172.18 + 20 = 172.38) that is outside the 172.16.0.0/12 private network and will be rejected. To avoid this, we'll use a base prefix of 10.100. That will use 10.100 for the first cluster, 10.120 for the second cluster, and a random value of 10.101 to 10.113 for the third cluster. This avoids any conflict, and ensures that the prefix is within the 10.0.0.0/8 private network. Fixes Issue: kubernetes-retired#220
pmichali
force-pushed
the
nat64-prefix
branch
2 times, most recently
from
0858301
to
bb422a3
Compare
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ivan4th, pmichali The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit does several things related to the NAT64 prefix, as specified
by the NAT64_V4_SUBNET_PREFIX environment variable. This prefix is for a
/16 subnet.
First, we want the prefix to be within one of the two private network
ranges (172.16.0.0/12 or 10.0.0.0/8).
Second, to accommodate that, the NAT64_V4_SUBNET_PREFIX will be two octets,
instead of one. The default, if not specified, will be 172.18, to avoid
docker usage of that private network.
Third, the code will range check the prefix, to ensure that it is within
range, based on the private network selected. 172.16 to 172.31 or 10.0 to
10.253 values are allowed.
Fourth, the cluster ID is added to the prefix, so that a unique subnet is
used for each cluster. This affects the allowable values for the prefix.
For 172.16.0.0/12, the prefix plus cluster ID must be from 172.16 to
172.31. For 10.0.0.0/8, the prefix plus cluster ID must be from 10.0 to
10.253. So, for example, if the default 172.18 is used, then cluster IDs
can be from 0 to 13.
Another side effect of this change is w.r.t. legacy mode, where the user
specifies (only) the DIND_LABEL. In that case, a cluster ID is generated,
and we now will use numbers from 1..13 to help keep the values within the
range for the V4 mapping prefix (using 13 instead of 15 as the default
prefix is 172.18).
If the user wants to use the legacy DIND_LABEL, but have a larger range
for cluster IDs, they can set the NAT64_V4_SUBNET_PREFIX to the 10.0.0.0/8
subnet and/or explicitly set the CLUSTER_ID.
Fixes Issue: #220