Paul Jakma writes: > On Thu, 13 Apr 2006, James Carlson wrote: > > We must also look at what makes sense for Solaris. > > I disagree with that, it has to make sense for /users/, imho.
Seriously? We cannot _also_ take into consideration the direction we want to see Solaris going? When exactly did we give up attempting to set architectural direction for Solaris? > > For example, setting the destination address on output, as Linux > > appears to do, is just senseless and wrong. > > Ack. > > I wasn't aware PKTINFO could be used for output on Linux. If you want to > strip it down to just setting the source (by index or by address - but > not both together ;) ), I'd agree with that. (*please* call it something > else though). That fails, because the entire point to doing this RFE was to support *output*. You can already do the input-side tricks using IP_RECVDSTADDR -- that gives you the destination address on the inbound packet. Adding IP_PKTINFO just for input would be entirely useless. It wouldn't make us compatible with Linux (we'd be missing the output part that they have), and it wouldn't solve the original problem that we were setting out to solve -- namely, making it so that applications can actually be coded to follow RFC 1123 section 2.3 on Solaris without requiring extreme heroics. > >> a) Call this something else (to avoid Linux IP_PKTINFO clash) > > > > I disagree. It has symmetry with the existing IPV6_PKTINFO. > > Yes it does. Except there is code out there out there today that has > certain exceptions of IP_PKTINFO. True. Just not on Solaris. > Calling this IP_PKTINFO on Solaris is going to be a PITA for any > codebase which today picks between IP_RECVIF and IP_PKTINFO at compile > time for received-interface information. Such code may not compile any > more if we introduce this, until its developers update their auto* (or > equivalent portability goo) tests. So, you're saying that we need to have "IP_WE_REALLY_WANT_PKTINFO_HERE_BUT_LINUX_STOLE_IT_AND_BROKE_IT_FOR_US" instead? > Even when they do, it's going to be very confusing to users to have to > remember that IP_PKTINFO are completely different on the two platforms. Option 2 is to make IP_RECVDSTADDR work on the output side as well. > Ie, despite the symmetry with the IP6 version, please let's consider the > pain we'll cause to code that would be interested in this functionality > (which therefore likely are already using the Linux flavour). Let > pragmatism over-rule aesthetics on this please. :) > > Even IP_PCKTINFO or IP_PACKETINFO would do. :) Sigh. > Is it the intention to allow both ifindex and destination or source to > be set? Or just source, as per above comment? Just source on output > would be fine of course. Former case ought to require privileges - > denying its use to unprivileged applications (VoIP?). I'd really like to see the source address problem fixed. The interface problem is far more complex. I believe what we really need there are "routing domains," so that cliques of interfaces (potentially just _one_ interface in the degenerate case) can behave as a group for output, selecting only on destination within the group. That is, the interfaces are all attached to a single "routing domain" in which a given destination is unique. (I believe this is at the root of the "I want my packets to go back out through the same interface, is that so hard?" problem.) > > I mildly agree with this, but for a different reason. IP_RECVIF and > > IP_XMIT_IF provide decent control here. I don't know why Linux chose > > to mix in the interface here as well. > > Linux doesn't provide IP_RECVIF iirc. It's just informational in the > Linux case I thought though. (Linux doesn't have IP_XMIT_IF either). They shouldn't; it's private. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
