Page MenuHomeFreeBSD

Handbook: Improving IPv6 Documentation
ClosedPublic

Authored by p.mousavizadeh_protonmail.com on Apr 11 2025, 2:15 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Sep 11, 3:09 AM
Unknown Object (File)
Fri, Sep 5, 3:55 AM
Unknown Object (File)
Tue, Sep 2, 8:00 PM
Unknown Object (File)
Tue, Sep 2, 2:41 PM
Unknown Object (File)
Mon, Sep 1, 5:26 AM
Unknown Object (File)
Mon, Sep 1, 4:52 AM
Unknown Object (File)
Fri, Aug 22, 12:50 AM
Unknown Object (File)
Thu, Aug 14, 11:50 PM
Subscribers

Details

Summary

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.

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

ziaee added a subscriber: ziaee.

Lexi, can you confirm?

Mentors, if this is confirmed, may I take this?

Lexi, can you confirm?

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

p.mousavizadeh_protonmail.com retitled this revision from Handbook: IPv6 anycast addresses can be used by hosts to Handbook: Improving IPv6 Documentation.Apr 12 2025, 9:16 PM

Perfect, I'll have my FreeBSD/ipv6 expert review this when they get a chance. Thanks again.

ivy requested changes to this revision.Apr 13 2025, 7:48 AM

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.

This revision now requires changes to proceed.Apr 13 2025, 7:48 AM
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.

This revision is now accepted and ready to land.Apr 14 2025, 12:06 AM
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.

  • Handbook: Improving IPv6 Documentation

@lexi_le-fay.org

This revision now requires review to proceed.Apr 14 2025, 10:43 AM

Cool! Just some doc nits from me.

documentation/content/en/books/handbook/network/_index.adoc
494

Better would be to also add slaac to the glossary in this commit, and link that here.

502

Style nit

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.

Just some ideas

documentation/content/en/books/handbook/glossary.adoc
931–932 ↗(On Diff #153658)

Of course, replace "something something".

documentation/content/en/books/handbook/network/_index.adoc
359

Should we work this over somehow considering the glossary?

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.

Of course, replace "something something".

I can use the intro of SLAAC from its RFC:

The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link.

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

Should I mention the new sysctl of D50099?
@ziaee

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.

p.mousavizadeh_protonmail.com added inline comments.
documentation/content/en/books/handbook/network/_index.adoc
489

Thank you for the feedback.
There was a discussion about the anycast sysctl review in the FreeBSD trasport meeting, I suggested separating TCP from UDP in its sysctl, They told me that you have already done that. But, they're worried about TCP. I hope it gets accepted!

This revision is now accepted and ready to land.May 15 2025, 3:50 PM

AFAICS, This review is ready to land. Could you please commit this? @ziaee

Still needs additional sign off from the doc team.

Can someone else commit this? We're ETOOBUSY.

This revision was automatically updated to reflect the committed changes.