Update network.go by revisiting #5134 #5150
Open
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.
From the go source code on potential conflicts in IP Addressing schemes: https://cs.opensource.google/go/go/+/master:src/net/rawconn_unix_test.go
// There's no guarantee that IP-level socket
// options work well with dual stack sockets.
// A simple solution would be to take a look
// at the bound address to the raw connection
// and to classify the address family of the
// underlying socket by the bound address:
//
// - When IP.To16() != nil and IP.To4() == nil,
// we can assume that the raw connection
// consists of an IPv6 socket using only
// IPv6 addresses.
//
// - When IP.To16() == nil and IP.To4() != nil,
// the raw connection consists of an IPv4
// socket using only IPv4 addresses.
//
// - Otherwise, the raw connection is a dual
// stack socket, an IPv6 socket using IPv6
// addresses including IPv4-mapped or
// IPv4-embedded IPv6 addresses.
What problem are we solving?
How are we solving the problem?
How is the PR tested?
Checks