dotnet / dotnet/aspnetcore

HTTP/3: RemoteIpAddress remains unchanged after QUIC connection migration

Open
#68,761 1 comment 0 reactions 0 assignees View on GitHub
area-networking feature-kestrel HTTP3
Dominant language
C#
Stars
38.4k
Forks
10.9k
Avg merge
2d 6h
Merged PRs (30d)
290

Description

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

Kestrel's QUIC transport captures `QuicConnection.RemoteEndPoint` when `QuicConnectionContext` is created. Stream contexts copy that value, which HTTP/3 request processing uses to initialize `HttpContext.Connection.RemoteIpAddress` and `RemotePort`.

After QUIC connection migration or NAT rebinding, subsequent requests on the same HTTP/3 connection continue to expose the original endpoint rather than the current validated peer endpoint.

### Expected Behavior

After QUIC validates a peer-address change, subsequent HTTP/3 requests should expose the current remote endpoint through `RemoteIpAddress` and `RemotePort`.

### Steps To Reproduce

1. Configure a Kestrel HTTP/3 endpoint that returns `HttpContext.Connection.RemoteIpAddress` and `RemotePort`.
2. Establish an HTTP/3 connection from address A and send a request.
3. Migrate the same QUIC connection to address B, or trigger NAT rebinding, and allow path validation to complete.
4. Send another request on the existing connection.

The second request still reports address A instead of address B.

### Exceptions (if any)

None.

### .NET Version

Current `main` branch.

### Anything else?

The endpoint is currently snapshotted through this path:

- `QuicConnectionContext` captures `QuicConnection.RemoteEndPoint`.
- `QuicStreamContext` copies the captured endpoint.
- `Http3Connection.CreateHttpStreamContext` forwards it.
- `HttpProtocol` uses it to initialize the request connection properties.

Contributor guide

Open the contributing guide

Research direction

Trace the endpoint flow described from QuicConnectionContext through QuicStreamContext and Http3Connection.CreateHttpStreamContext into HttpProtocol. Start by locating where the endpoint is captured and copied, then verify how validated QUIC migration updates it. Done means subsequent HTTP/3 requests expose the current remote endpoint through RemoteIpAddress and RemotePort rather than the original address.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.