Repository navigation
Deployment Considerations: return path and DHCPv4 relay - #38
Closed
remcovanmook wants to merge 3 commits into
Closed
remcovanmook wants to merge 3 commits into
remcovanmook wants to merge 3 commits into
Conversation
One informative paragraph, as the issue asks. Where the first-hop router is the DHCPv4 relay or snoops relayed traffic, it already holds the lease binding; with the host's link-layer address from ND that is enough to originate the RFC 8950 route at lease grant and withdraw it at lease end. BNGs originate subscriber routes this way today. Explicitly illustration only. Route origination belongs to RFC 8950 and v4-via-v6 territory, and normative text is unchanged. Closes #22 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Link-locals are shifting identifiers under modern privacy addressing. An implementation moving from an interface-identifier-derived address to an RFC 7217 opaque one can do so during bring-up, mid-DHCPv4-exchange, leaving a return route keyed to the first link-local seen stale before the host has finished configuring. Guidance: prefer a stable next-hop identity where available -- a provider-known GUA, a PD-anchored address, or an ND-snooping or SAVI-derived binding (RFC 7513) -- with link-local as fallback. Where only link-locals exist, origination must track identity shifts through ND rather than assume the first address persists. Caveat recorded: RFC 8981 temporary addresses rotate by design and MUST NOT be used as a next-hop identity. New informative references: RFC 7217, RFC 7513, RFC 8981. Closes #23 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Relay behaviour is the first thing an operator checks and the draft said almost nothing about it. - The relaying interface needs no IPv4 address; giaddr does need a routable one, but one loopback per relay router covers any number of segments. - RFC 3527 link selection decouples giaddr from pool selection where the two would be conflated, though flat /32 pools largely dissolve the question; Option 82 circuit-id carries segment identity where it is still wanted. - Cross-reference RFC 7600 and 192.0.0.8/32 for ICMPv4 sourced by IPv6-only transit routers, alongside the interface-local sentinel sourcing in 5.3. The existing on-link gateway validation paragraph moves here from the host implementation notes. New informative references: RFC 3046, RFC 3527. Closes #21 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.
Last of the three Deployment Considerations PRs. Two new subsections,
6.9 Return Path Provisioningand6.10 DHCPv4 Relay Considerations.#22 - lease-triggered origination
One informative paragraph, as the issue specifies. Where the first-hop router is the DHCPv4 relay or snoops relayed traffic, it already holds the lease binding; with the host's link-layer address from ND that is enough to originate the RFC 8950 route at lease grant and withdraw it at lease end - which is what BNGs do for subscriber routes today. Marked as illustration only, with route origination left to RFC 8950 and v4-via-v6. No normative text.
#23 - next-hop identity stability
The failure this prevents is subtle and bites during bring-up: an implementation that moves from an interface-identifier-derived link-local to an RFC 7217 opaque one can do so mid-DHCPv4-exchange, so a return route keyed to the first link-local observed is stale before the host has finished configuring.
Guidance is to key return routes to a stable identity where one exists - a provider-known GUA, a PD-anchored address, or an ND-snooping/SAVI-derived binding (RFC 7513) - with link-local as fallback, and to track identity shifts through ND where only link-locals are available.
One wording call worth flagging: the issue notes RFC 8981 temporaries rotate, with the parenthetical that servers keep
use_tempaddr=0. I wrote that as aMUST NOTon temporary addresses as next-hop identity and left the Linux sysctl out, since it is platform-specific detail that dates quickly in an RFC. Easy to soften to a SHOULD if you think MUST overreaches for a Deployment Considerations section.#21 - DHCPv4 relay
192.0.0.8/32cross-referenced for ICMPv4 sourced by IPv6-only transit routers, set against the interface-local sentinel sourcing in 5.3.The existing on-link gateway validation paragraph moves here from the host implementation notes.
New informative references: RFC 3046, RFC 3527, RFC 7217, RFC 7513, RFC 8981.
With this merged,
6.11 Host Implementation Considerationsis back to the single paragraph it should always have been (the separate-stack IPC note); everything else parked there has found its home.Closes #22, closes #23, closes #21
🤖 Generated with Claude Code