Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/net/ipv4: an address as a result of routing table lookup for source-routing, source address selection #5576

Open
anacrolix opened this issue May 28, 2013 · 29 comments
Milestone

Comments

@anacrolix
Copy link
Contributor

In addition to Dst and IfIndex, ControlMessage should contain a member corresponding to
ipi_spec_dst, from struct in_pktinfo. This is available when IP_PKTINFO is set.

It's necessary when the IP address that a packet is received on is required, rather than
the header destination address (which is what Dst represents).
@anacrolix
Copy link
Contributor Author

Comment 1:

A patch is attached.

Attachments:

  1. specdst.diff (1126 bytes)

@minux
Copy link
Member

minux commented May 28, 2013

Comment 2:

Owner changed to @mikioh.

@davecheney
Copy link
Contributor

Comment 3:

Can you please follow the contribution process described here,
http://golang.org/doc/contribute.html

@anacrolix
Copy link
Contributor Author

Comment 4:

https://golang.org/cl/9727045

@mikioh
Copy link
Contributor

mikioh commented May 28, 2013

Comment 5:

I want to understand why we have to have a ipi_spec_dst.
Can you give us some use cases  for both receiving, specifying ipi_spec_dst?

Status changed to Thinking.

@anacrolix
Copy link
Contributor Author

Comment 6:

When the IP address that a packet is received on is required, rather than the header
destination address (which is what Dst represents). This occurs when you need to involve
the receiving interface address in the crafting of the response. For example in
responding to an SSDP M-SEARCH, one may infer the value for the response Location header
with respect to the searcher.

@anacrolix
Copy link
Contributor Author

Comment 7:

When the IP address that a packet is received on is required, rather than the header
destination address (which is what Dst represents). This occurs when you need to involve
the receiving interface address in the crafting of the response. For example in
responding to an SSDP M-SEARCH, one may infer the value for the response Location header
with respect to the searcher.

@anacrolix
Copy link
Contributor Author

Comment 8:

When the IP address that a packet is received on is required, rather than the header
destination address (which is what Dst represents). This occurs when you need to involve
the receiving interface address in the crafting of the response. For example in
responding to an SSDP M-SEARCH, one may infer the value for the response Location header
with respect to the searcher.

@anacrolix
Copy link
Contributor Author

Comment 9:

When the IP address that a packet is received on is required, rather than the header
destination address (which is what Dst represents). This occurs when you need to involve
the receiving interface address in the crafting of the response. For example in
responding to an SSDP M-SEARCH, one may infer the value for the response Location header
with respect to the searcher.

@mikioh
Copy link
Contributor

mikioh commented May 29, 2013

Comment 11:

I'm afraid that your use case is not suitable for this ancillary usage because, a) it's
a result of routing, also cached information, b) even though linux 3.x and beyond will
replace ipi/rt_spec_dst cache with fib_compute_path stuff it's still part of routing
stuff, c) seems like what you need is application-specific, adaptive source address
selection.
But, there's no reason to hesitate to review, so please proceed with your CL.

@anacrolix
Copy link
Contributor Author

Comment 12:

a) Sure, I have no problem with that.
b) It's on my system: matt@dogfort:~/gopath/src/bitbucket.org/anacrolix/dms$ uname -a
Linux dogfort 3.5.0-28-generic #48-Ubuntu SMP Tue Apr 23 23:03:38 UTC 2013 x86_64 x86_64
x86_64 GNU/Linux
c) What? I need to know the address that received the packet. Since interfaces can have
multiple addresses, I can't use IfIndex. Dst was the intended destination, which in the
case of SSDP is a multicast group, hardly useful.

@mikioh
Copy link
Contributor

mikioh commented May 29, 2013

Comment 13:

> I need to know the address that received the packet
I thought that you want to use that address for specifying originator's Loc/ID stuff
(e.g.,  source address in the application protocol) on outgoing packets. That means that
applications which don't have any help of multi6, shim6 or mif6-like super-duper
complicated source address selection and its negotiation/signaling stuff need such last
hop address on the reverse path of source-routing. Am I missing something?

@anacrolix
Copy link
Contributor Author

Comment 14:

Yes, that's the Src address when a packet is received. This is the local address that
the packet was received on. 
"IP address that a packet is received on is required, rather than the header destination
address (which is what Dst represents)"

@mikioh
Copy link
Contributor

mikioh commented May 30, 2013

Comment 15:

I think it might help to understand if you can say scoped "src" or "local" (e.g., IP
header's src or routed protocol's src) because "src" or "local" w/o scope doesn't make
sense when we should think of both routed and routing stuff at the same time.
Anyway before proceeding, please change the field name and its comment to:
Hop []net.IP // hop of source routing
then move down just after IfIndex.
Also pls change CL description to:
go.net/ipv4: add source routing support
and probably drop "see ip(7)".
Thanks.

@anacrolix
Copy link
Contributor Author

Comment 16:

This doesn't make sense, I'm not sure you're understanding what this field represents.

@mikioh
Copy link
Contributor

mikioh commented May 30, 2013

Comment 17:

> This doesn't make sense, I'm not sure you're understanding what this field represents.
Yup, I'm still trying. Can you please elaborate more on "the Src address when a packet
is received. This is the local address that the packet was received on." ?
From API design point of view, I don't understand why we should call the field "SpecDst
(specific destination, uh, for what?)".
We use that field when we want to specify a node-local source address for the routing
table lookup and for setting up IP source route options. Also we use that field when we
want to know the last hop address on a reverse-path (not sure in the case of IP-over-IP
tunneling or NAT/NAPT; probably it returns the result of innermost IP routing?).
In both case, the field represents an address of the routing stuff; in terms of
locator/ID separation, it represents an IP-layer topological locator and doesn't
represent an IP-layer endpoint identifier. That's the reason why I don't understand the
field is called "Dst (destination)" instead of "Hop (routing hop)".

@mikioh
Copy link
Contributor

mikioh commented Jun 6, 2013

Comment 18:

Status changed to WaitingForReply.

@anacrolix
Copy link
Contributor Author

Comment 19:

I never said "Src address when a packet is received".
"In addition to Dst and IfIndex, ControlMessage should contain a member corresponding to
ipi_spec_dst, from struct in_pktinfo. This is available when IP_PKTINFO is set.
It's necessary when the IP address that a packet is received on is required, rather than
the header destination address (which is what Dst represents)."
The name SpecDst is simply adapted from the referred man pages and C header files in
Linux. Please have a good read there.
I'm sorry I don't see the relevance of your last paragraph.
Thanks for your patience with this.

@anacrolix
Copy link
Contributor Author

Comment 20:

Take a look at this, it might enlighten... http://stackoverflow.com/a/5309155/149482

@mikioh
Copy link
Contributor

mikioh commented Jun 15, 2013

Comment 21:

Please feel free to send your CL.
http://golang.org/doc/contribute.html
I'm not sure the field name "SpecDst" is appropriate for API because looks like it
represents the result of routing table lookup (the matched address of routing
information base lookup) on both forward/reverse packet paths. Linux on-line manual
doesn't say nothing about the case of receiving, maybe Solaris and OS X too.
But I believe other reviews will find out a good solution for that.
P.S.
That field represents when the destination address field of received packets has:
- unicast address: host receiver did RIB lookup and put the result to the field
- limited/directed broadcast address: ??? (depends on platform implementations?)
- multicast address: ditto
- IP tunneling or translations: ??? (depends on platform implementations?)

Owner changed to ---.

Status changed to New.

@anacrolix
Copy link
Contributor Author

Comment 22:

Please reconsider this patch. Change the field name if it suits you.

Attachments:

  1. specdst.diff (1092 bytes)

@mikioh
Copy link
Contributor

mikioh commented Aug 9, 2013

Comment 23:

Please feel free to send your CL.
http://golang.org/doc/contribute.html
FWIW, the procedure prohibits sending that CL on behalf of you, saying LGTM and
submitting by oneself.
At least four eyeballs and LGTM from an established team member are required.

@anacrolix
Copy link
Contributor Author

Comment 24:

https://golang.org/cl/9727045/

@mikioh
Copy link
Contributor

mikioh commented Aug 9, 2013

Comment 25:

You need to mail the change for review.
http://golang.org/doc/contribute.html#tmp_13

@rsc
Copy link
Contributor

rsc commented Oct 18, 2013

Comment 26:

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 27:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 28:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 29:

Labels changed: added repo-net.

@gopherbot
Copy link

Comment 30:

CL https://golang.org/cl/9727045 references this issue.

@mikioh mikioh changed the title go.net/ipv4: an address as a result of routing table lookup for source-routing, source address selection x/net/ipv4: an address as a result of routing table lookup for source-routing, source address selection Dec 23, 2014
@mikioh mikioh changed the title x/net/ipv4: an address as a result of routing table lookup for source-routing, source address selection ipv4: an address as a result of routing table lookup for source-routing, source address selection Jan 4, 2015
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@rsc rsc changed the title ipv4: an address as a result of routing table lookup for source-routing, source address selection x/net/ipv4: an address as a result of routing table lookup for source-routing, source address selection Apr 14, 2015
@rsc rsc modified the milestones: Unreleased, Unplanned Apr 14, 2015
@rsc rsc removed the repo-net label Apr 14, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants