NAT encapsulated packets originate from `::`
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- networking
Research direction
Start with dpd/p4/sidecar.p4 lines 507-530 and trace how NAT-encapsulated packets get their outer IPv6 source and destination addresses. Review the OPTE ICMP-generation tests mentioned in the issue to establish expected hairpin behavior. Done means the generated encapsulation has a useful source address and the relevant cases are covered by tests.
Written by the indexing model from the issue text.
Description
I ran into this while writing up tests for ICMP generation in OPTE and double-checking what fields to expect in various cases -- the case in question being generating ICMP hairpins for traffic from the external network.
The lack of a useful source address makes it challenging/fiddly to ensure that inner ICMP packet-too-big traffic goes back via the switch the original packet came from. The switch will only decapsulate packets which have one of its switch addresses as the outer IPv6 destination, so mirroring the source/destination addresses on the encap will lead to unroutable packets. As a result we have to perform a V2B lookup on the inner destination to fill this field, which may return the address of the other switch.
A minor point is that the inner source mac could also be set to something like oxide_vpc::engine::overlay::TUNNEL_ENDPOINT_MAC (A8:40:25:77:77:77), for symmetry with how OPTE sends packets to boundary services.
- Dominant language
- Rust
- Stars
- 21
- Forks
- 3
- Avg merge
- 8h 29m
- Merged PRs (30d)
- 2
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from oxidecomputer/dendrite
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
oxidecomputer/dendrite#380 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
oxidecomputer/dendrite#375 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
oxidecomputer/dendrite#369 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
oxidecomputer/dendrite#368 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
oxidecomputer/dendrite#359 · 1 comment ·
Maintainers usually reply within 1 day
All issues in oxidecomputer/dendrite
Similar issues
-
backend::vllm diffusion multimodal
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
lambdaclass/ethrex#7329 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
shadowsocks/shadowsocks-rust#2186 · 1 comment ·
-
C-bug S-awaiting-triage
Difficulty 1/5 Under an hour Newbie friendliness 92/100
juspay/hyperswitch#14479 ·
Maintainers usually reply within 1 day