RFC7094:
To avoid exposing knowledge about the internal structure of the
network, it is recommended that anycast servers now take advantage
of the ability to return responses with the anycast address as the
source address if possible.
Details
- Reviewers
ivy mhorne carlavilla fernape olivier ziaee des - Group Reviewers
docs network Doc Committers - Commits
- R9:e1054c3d553d: Handbook: Improve IPv6 documentation
Diff Detail
- Repository
- R9 FreeBSD doc repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 63489 Build 60373: arc lint + arc unit
Event Timeline
this change is correct according to the IETF: RFC 3513 prohibited hosts using anycast addresses (which is likely where the handbook language comes from) and also prohibited sending packets from anycast addresses, but those restrictions were removed in RFC 4291.
for some context, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285545 and https://github.com/freebsd/freebsd-src/pull/1618
Merge all of the reviews in the IPv6 section of the handbook into last one, as requested by @ziaee
Perfect, I'll have my FreeBSD/ipv6 expert review this when they get a chance. Thanks again.
reviewing as requested by ziaee@.
documentation/content/en/books/handbook/network/_index.adoc | ||
---|---|---|
378 | this is fine, but the previous sentence probably needs to be adjusted from "nearest router interface" to just "nearest interface". | |
452–453 | i like this change, but the table is already inconsistent in whether the first column includes prefix length or not, and some of the entries also seem to be wrong, e.g. ::ff:xx:xx:xx:xx (IPv4-mapped address) is probably meant to be ::ffff:xxxx:xxxx, but it would be more usual to express this as ::ffff:0:0/96 (or ::ffff:0.0.0.0/96). also, some of the descriptions are wrong, for example IPv4-mapped addresses are not "for hosts which do not support IPv6". if we're changing this anyway, i'd suggest fixing the existing errors, making the first column consistently use CIDR notation for the prefixes, and removing the second column (prefixlength) entirely. | |
483 | it would worth mentioning here that applications can't bind to anycast addresses; in that case you need to use an alias address instead (which can be semantically an anycast address in the network). a mention of alias0 should probably also come with a reference to rc(8) where the syntax of the *_alias/*_aliasN variables is described. | |
493–494 | this is still wrong since dhclient(8) doesn't support DHCPv6; apparently this text was just copied from the IPv4 section without checking. perhaps it could suggest using net/dhcpcd from ports instead. but in either case, DHCPv6 IA_NA is somewhat uncommon and shouldn't be the first thing suggested. it makes more sense to describe how to enable SLAAC first, then mention DHCPv6 afterwards for people who need it. |
documentation/content/en/books/handbook/network/_index.adoc | ||
---|---|---|
483 | of course i meant rc.conf(5) there, not rc(8). |
- Handbook: Improving IPv6 Documentation
IPv4-Compatible IPv6 address is deprecated by RFC4291
I don't recommend to include DHCPv6 configuration in this part of handbook at all.
A note for SLAAC when packet forwarding enabled is added
i've added a couple of review comments but overall i'm happy with the revised version, thank you.
i do think we should document a DHCPv6 client somewhere in the handbook, but since the previous documentation was simply wrong, removing it is fine for this diff.
documentation/content/en/books/handbook/network/_index.adoc | ||
---|---|---|
439 | i won't reject this but i think a more accurate phraseology might be something like "The lower 32 bits are the IPv4 address, used for sockets API compatibility in older applications". | |
457 | should have a space here or it renders badly | |
502 | i would like to see this be a bit more explicit about the meaning of that sysctl, i.e. if ipv6_gateway_enable is YES, then the system will not configure a SLAAC address unless rfc6204w3 is set to 1. |
documentation/content/en/books/handbook/network/_index.adoc | ||
---|---|---|
439 | I agree, but this is more understandable for newcomers and, also I used the RFC terminology. IMHO, "sockets API" is more appropriate for advance networking section or even the dev handbook. | |
457 | after comma? "2001:db8::/32, 3fff::/20" | |
502 | "Please note that when IPv6 packet forwarding is enabled (i.e., ipv6_gateway_enable=YES), the system will not configure a SLAAC address unless net.inet6.ip6.rfc6204w3 man:sysctl[8] variable is set to 1." I should explicitly state the "IPv6 packet forwarding", but for the sake of clarity for newcomers. I prefer to keep the description of ipv6_gateway_enable earlier. |
documentation/content/en/books/handbook/network/_index.adoc | ||
---|---|---|
502 | I didn't use 'via' because you can configure packet forwarding directly using sysctl and persist it without rc.conf. To me, using 'via' suggests that this situation only occurs when we're using rc.conf for configuration, and not when we enable packet forwarding directly through sysctl. I know this distinction may seem obvious, but for non-English speakers, it could imply the opposite. |
- Handbook: Add SLAAC to glossary and style the rfc6204w3
@ziaee glossary added. please make sure i have done it right, I try my best to follow the other examples to create the crossref. but couldn't find any tutorial about it.
Adding the handbook syntax expert now that subject matter seems ironed out.
documentation/content/en/books/handbook/glossary.adoc | ||
---|---|---|
931–932 ↗ | (On Diff #153658) | Although, I'm not sure this syntax is better than what you already have below which renders just fine. I'll ask the expert. |
documentation/content/en/books/handbook/glossary.adoc | ||
---|---|---|
931–932 ↗ | (On Diff #153658) | I was trying to follow the existing style (e.g, "Symmetric MultiProcessor"). I also think "Stateless Address Autoconfiguration" is more appropriate.
I can use the intro of SLAAC from its RFC:
|
documentation/content/en/books/handbook/network/_index.adoc | ||
359 | I'm not sure. This section talks about the advantages of IPv6 over IPv4 for people who don't know about IPv6, without using IPv6-specific terms. It should encourage people to use IPv6 without confusing them. I don't think it's necessary. |
documentation/content/en/books/handbook/network/_index.adoc | ||
---|---|---|
489 | no, that hasn't been committed yet and there's still no consensus on whether it should be. |
documentation/content/en/books/handbook/network/_index.adoc | ||
---|---|---|
489 | Thank you for the feedback. |