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

[anacrolix]

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]

Comment 1:

A patch is attached.

Attachments:

1. specdst.diff (1126 bytes)

[minux]

Comment 2:

Owner changed to @mikioh.

[davecheney]

Comment 3:

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

[anacrolix]

Comment 4:

https://golang.org/cl/9727045

[mikioh]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Comment 16:

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

[mikioh]

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]

Comment 18:

Status changed to WaitingForReply.

[anacrolix]

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]

Comment 20:

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

[mikioh]

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]

Comment 22:

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

Attachments:

1. specdst.diff (1092 bytes)

[mikioh]

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]

Comment 24:

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

[mikioh]

Comment 25:

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

[rsc]

Comment 26:

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

Status changed to Accepted.

[rsc]

Comment 27:

Labels changed: added go1.3maybe.

[rsc]

Comment 28:

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

[rsc]

Comment 29:

Labels changed: added repo-net.

[gopherbot]

Comment 30:

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