Repository navigation
Introduction: adoption-call review items and Related Work - #33
Closed
remcovanmook wants to merge 4 commits into
Closed
remcovanmook wants to merge 4 commits into
remcovanmook wants to merge 4 commits into
Conversation
"DHCPv4 configuration" was ambiguous between the client and the server side. The verified result is that no DHCPv4 client configuration changes are needed; say so. From adoption-call review (H. Robinson). Closes #8 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The incremental deployment argument stopped short of saying what follows from it. Close it explicitly: the two tiers coexist indefinitely, conversion is per host, and there is no flag day or mandatory switch-over point. Closes #10 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The alternatives discussion counted only host stack changes. The larger cost of a new DHCPv4 option lands in the operator's OSS and BSS: billing, provisioning, inventory, monitoring, NOC tooling and validation logic all encode the shape of an IPv4 gateway. A sentinel address is indistinguishable from an ordinary gateway address to all of them, so the only component that needs to know is the host. Closes #11 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Position the draft as the first general form of a pattern the industry has repeatedly built in private: proxy ARP, PPPoE and 3GPP point-to-point bearers, the softwires IPv4aaS family, Calico's dummy next-hop answered by proxy ARP, the hosting-provider /32 configurations, and pre-standard IPv4 over IPv6 next-hop arrangements. Then name the conditions that blocked each prior instance and have since expired: no standard transport before RFC 8950, host stacks presumed unchangeable (disproved by Option 108 and CLAT shipping), walled domains with no need for an interoperable code point, and the assumption that translation was the answer. Calico's 169.254.1.1 behaviour verified against the current Project Calico FAQ before citing, per the note in the issue: the address is never assigned to an interface and is resolved solely by proxy_arp on the host side of the interface pair. New informative references: RFC 925, RFC 2516, RFC 8585, CALICO-FAQ. Closes #24 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Owner
Author
|
Superseded by #42. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Four of the five Introduction issues. #12 (the two-IPv4s framing and layer cake rework) is deliberately not here - it is waiting on the two RIPE Labs article links, and it will reshape the section around what is added below rather than conflict with it.
Commits
DHCPv4 configuration->DHCPv4 client configuration. The original was ambiguous between client and server side; the verified result is specifically that no client configuration changes are needed. (H. Robinson)1.1 Related Worksubsection covering the reinvention lineage (proxy ARP, PPPoE/3GPP bearers, softwires IPv4aaS, Calico, provider /32s, pre-standard v4-via-v6), then the blocking conditions that have since expired, positioning the draft as the first general and interoperable arrival.On the Calico citation
The issue said to verify before citing. Confirmed against the current Project Calico FAQ:
169.254.1.1is never assigned to any interface and is resolved solely byproxy_arpon the host side of the veth pair - the container's routing table sends everything via it, so it is the only address the workload ever ARPs. The draft text reflects exactly that and claims nothing more.Worth noting for #25: Calico's IPv6 side uses a real link-local resolved by ordinary NDP, and needs no equivalent hack. That is the same asymmetry this draft is closing, and it is useful supporting material if the alternatives-considered appendix goes ahead.
New informative references: RFC 925, RFC 2516, RFC 8585, CALICO-FAQ. Build is clean and all five resolve.
Closes #8, closes #10, closes #11, closes #24
🤖 Generated with Claude Code