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

Comments

@anacrolix
Copy link
Contributor

commented May 28, 2013

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

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2013

Comment 1:

A patch is attached.

Attachments:

  1. specdst.diff (1126 bytes)
@minux

This comment has been minimized.

Copy link
Member

commented May 28, 2013

Comment 2:

Owner changed to @mikioh.

@davecheney

This comment has been minimized.

Copy link
Contributor

commented May 28, 2013

Comment 3:

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

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2013

@mikioh

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2013

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

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2013

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

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2013

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

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2013

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2013

Comment 16:

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2013

Comment 18:

Status changed to WaitingForReply.

@anacrolix

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2013

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

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2013

Comment 20:

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 8, 2013

Comment 22:

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

Attachments:

  1. specdst.diff (1092 bytes)
@mikioh

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 9, 2013

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2013

Comment 25:

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

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2013

Comment 26:

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

Status changed to Accepted.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 27:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 28:

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

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 29:

Labels changed: added repo-net.

@gopherbot

This comment has been minimized.

Copy link

commented Apr 9, 2014

Comment 30:

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

@anacrolix anacrolix added the accepted label Apr 9, 2014

@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
Projects
None yet
6 participants
You can’t perform that action at this time.