Website: Issue with k8s.io/docs/concepts/services-networking/dual-stack/ - very incorrect IPv6 ULA prefix

[markzzzsmith]

This is a Bug Report

Problem:

The recommendation to use fd00::/24 as the IPv6 ULA prefix is very incorrect. That is not going to be a globally unique prefix, yet the U in ULA standards for Unique.

ULA prefixes are required to be /48 or longer, and the 40 bits after the first 8 bits of fd00::/8 are required to be a random number that is likely globally unique. See RFC 4193.

Using fd00::/24 is reproducing the problems that the IPv6 Site-Local prefix (fec0::/10) created. The Site-Local prefix as deprecated back in 2004.

Proposed Solution:

As getting ULAs incorrect seems to be fairly common, I recently wrote and presented a presentation on how to get IPv6 private addressing right, which touches on the history of the deprecation of Site-Locals, and why Unique ULAs are essential.

"Getting IPv6 Private Addressing Right" (viewable in a browser)
https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right

"Getting IPv6 Private Addressing Right" (PDF)
http://www.users.on.net/~markachy/AusNOG%202019%20-%20Getting%20IPv6%20Private%20Addressing%20Right.pdf

Page to Update:
https://kubernetes.io/...

[sftim]

Good point. However, https://kubernetes.io/docs/concepts/services-networking/dual-stack/ doesn't currently mention fd00:: (it does mention fc00::/24). Is that what you meant to report @markzzzsmith ?

Also, @markzzzsmith you can if you wish edit the original issue text to update the slideshow URL

[markzzzsmith]

Yes, I didn't notice the 'fc', as the all-zeros part and the /24 length were more obvious errors.

'fc' is also very incorrect, that would be for ULAs for which there is assured global uniqueness due to there being a central registry. No central registry has been setup, so the only valid ULAs are ones that start with 'fd' - the L or Local bit is switched on.

I don't really know much about Kubernetes, other than roughly what it's for, but not how it works.

Ideally ULA /48 generation could automatically occur when it is first initialised or when a cluster is initialised, and then kubernetes could either automate allocation of /64 subnets out to links within the cluster from within that generated /48 if Kubernetes builds up the virtual network.

Or perhaps if that level of automation isn't possible, provide a basic IPAM (IP Address Management) system function within an administrative interface that automates subnet allocation from within the previously generated /48, with subnet labels and descriptions, so that the operator could have the convenience of using cut-and-paste of the ULA /64 prefixes when constructing the network.

In other words, try to make using RFC 4193 compliant ULA prefixes as easy as typing all zeros for the Global ID part.

[sftim]

The documentation should not make readers come to use invalid ULAs on their IPv6-enabled cluster, at least not without a very good reason and a strong dose of {{< caution >}} markers.

/priority important-longterm
/kind bug
This also tied in with work on the IPv6 / dual-stack features, which are not yet stabilized.

[sftim]

/sig network

[markzzzsmith]

Hi,

On Tue, 8 Oct 2019, 09:13 Tim Bannister, [e-mail] wrote:

The documentation should not make readers come to use invalid ULAs on
their IPv6-enabled cluster, at least not without a very good reason and a
strong dose of {{< caution >}} markers.

There are no very good reasons to use invalid ULAs. Otherwise those reasons
would be discussed and allowed in the ULA RFC 4193, and they would then be
valid.

Invalid ULAs encourage the use of NAT. NAT causes a lot of practical
network problems. I've also written a presentation about that.

"The Trouble with NAT (Or Why I Care About IPv6)"

https://www.slideshare.net/mobile/markzzzsmith/ausnog-2016-the-trouble-with-nat

Regards,
Mark.

/priority important-longterm

/kind bug
This also tied in with work on the IPv6 / dual-stack features, which are
not yet stabilized.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/issues/16466?email_source=notifications&email_token=ADLQA7PXOAKOQVIDBOF5AADQNOYABA5CNFSM4IYRSUF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAR7DYA#issuecomment-539226592,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADLQA7MA5NWPNM3KONJBRRTQNOYABANCNFSM4IYRSUFQ
.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[sftim]

/remove-lifecycle stale
Relevant to https://github.com/kubernetes/enhancements/pull/1429

[lachie83]

Appreciate the feedback @markzzzsmith and would be more than happy to get this resolved. I just want to make sure I correctly understand the piece of the document that you're referring to is the example prefixes here--cluster-cidr=10.244.0.0/16,fc00::/24 specifically fc00::/24. Given that this is an example prefix and a user should provide their own, what would you recommend putting there that is not in violation of the RFC and how might we make that clearer? You're guidance is very much appreciated and I'm also happy to review a PR that resolves this issue.

[aojea]

This RFC proposal has a good point https://tools.ietf.org/html/draft-delong-ula-example-00
We can use fc00:2001:db8::/48

[markzzzsmith]

On Sat, 18 Jan 2020 at 22:35, Antonio Ojea [e-mail] wrote:

This RFC proposal has a good point
https://tools.ietf.org/html/draft-delong-ula-example-00

We can use fc00:2001:db8::/48

That would still violate RFC4193. The 2001:db8 in the Global ID position is
a well known value, as it is the IPv6 documentation prefix.. RFC4193:

"They MUST NOT be assigned sequentially or with well-known numbers. "

There have been a number of discussions over the years about how to put in
example ULAs yet stop people using them. That draft is just one example.

It came up recently again, and the conclusion was that the example ULA must
be an invalid as an IPv6 address, with a comment pointing out that it is
invalid and that the reader will need to come up with their own ULA. This
is the only way to prevent people from copying the ULA prefix in the
document..

So the suggestion has been to put non-hexidecimal letters in the ULA
prefix.

So for this document, say something like:

"IPv6 Unique Local Unicast /48 prefixes are intended to likely be globally
unique (although not globally reachable), so that multiple ULA address
spaces can be merged without having to renumber the networks or having to
deploy network address translation. Software and websites are available to
generate a ULA /48 prefix that complies with RFC 4193.

In this document, the "XY:IJKL:MNOP" string of characters will be used
within the example ULA prefixes, indicating where the local network's 40
bit Global ID part would occur. For example, subnet 15' /64 prefix within
this document would look as follows:

fdXY:IJKL:MNOP:15::/64"

Regards,
Mark.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/issues/16466?email_source=notifications&email_token=ADLQA7JGRQLN7YQTAZCX4U3Q6LSRNA5CNFSM4IYRSUF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJJWLHA#issuecomment-575890844,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADLQA7MOO3UKEBCR7L4BEXLQ6LSRNANCNFSM4IYRSUFQ
.

[sftim]

"XY:IJKL:MNOP"

Rather than:

Example: `fdXY:IJKL:MNOP:15::/64`

we can also write:

Example: `<assigned-ula-prefix>::/64`

[markzzzsmith]

On Sun, 19 Jan 2020, 04:27 Tim Bannister, [e-mail] wrote:

"XY:IJKL:MNOP"

Rather than:

Example: fdXY:IJKL:MNOP:15::/64

we can also write:

Example: <assigned-ula-prefix>::/64

—

I think it is better to include the 'fd' because that is the ULA high order
8 bits for all ULAs today, and it is better to show the format of IPv6
addresses.

The IPv6 address formatting conventions of addresses is more strict than
IPv4. (IPv4's flexibility came about fundamentally to try to work around
the 32 bit address size limitation. Originally IPv4 addresses also had a
much simpler format - see RFC760.)

The local network generated ULA prefix is always a /48, no longer or
shorter. The field between /48 and /64 is the subnet field, and the
following 64 bits are the Interface Identifier field.

This is another error, fc00::/24 is incorrect because /24 is too short, and
therefore would only allow 16 bit global IDs. That's far too small to have
likely global ID uniqueness. 'fc' is an error because that would be a ULA
from a central global registry like the Internet Assigned Numbers Authority
(IANA) and there is no such registry.

RFC4193 covers a number of these motivations and analysis, as it is a
recovery from these sorts of mistakes being made with the first version of
IPv6 private addressing - site-local addresses.

For example, there is analysis of the likelihood of collision with random
40 bit Global IDs.

Regards,
Mark.

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/issues/16466?email_source=notifications&email_token=ADLQA7ODD7PYSSBKDJOGLELQ6M3W7A5CNFSM4IYRSUF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJJ5UIQ#issuecomment-575920674,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADLQA7LV75XAVNWIVHM62RDQ6M3W7ANCNFSM4IYRSUFQ
.

[lachie83]

I'm not any closer to understanding what update I can make to the docs that satisfies this issue. @markzzzsmith can you please provide some succinct suggestions?

[markzzzsmith]

On Fri, 24 Jan 2020, 03:56 Lachlan Evenson, [e-mail]
wrote:

I'm not any closer to understanding what update I can make to the docs
that satisfies this issue. @markzzzsmith https://github.com/markzzzsmith
can you please provide some succinct suggestions?

From earlier

'So for this document, say something like:

"IPv6 Unique Local Unicast /48 prefixes are intended to likely be globally
unique (although not globally reachable), so that multiple ULA address
spaces can be merged without having to renumber the networks or having to
deploy network address translation. Software and websites are available to
generate a ULA /48 prefix that complies with RFC 4193.

In this document, the "XY:IJKL:MNOP" string of characters will be used
within the example ULA prefixes, indicating where the local network's 40
bit Global ID part would occur. For example, subnet 15' /64 prefix within
this document would look as follows:

fdXY:IJKL:MNOP:15::/64"'

—

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/issues/16466?email_source=notifications&email_token=ADLQA7N7SVE3Q2P5CMJD33DQ7HD5NA5CNFSM4IYRSUF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJYBTIQ#issuecomment-577771938,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADLQA7L5SNHQTCKBBMFG5QLQ7HD5NANCNFSM4IYRSUFQ
.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[sftim]

/remove-lifecycle stale

[bridgetkromhout]

I submitted a PR that may help with the requested rewording: https://github.com/kubernetes/website/pull/20715

[lachie83]

We've addressed this issue in #20715. Closing

[lachie83]

/close

[k8s-ci-robot]

@lachie83: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.