In message <20050424063240.GC18134@netbsd.org>,
Bill Studenmund writes:


>I think one problem is that you have lost sight of the forest for the
>trees. It probably didn't help that you've had discussions like this
>before that we don't know about, and many folks here may have mistaken the
>forest for one tree... :-)

Bill,


Perhaps one big difference is: I don't use IPv6.  I have an IP-centric
(IPv4-centric if you wish) view of how IP(v4)  should work.

If you start from that perspective, then any attempts to force IPv6
semantics onto IPv4, in ways that break existing IPv4 usage, needs a
very strong justification.  No such justificaiton has even been
attempted here.   Attempts that boil down to saying:

    ```I don't know what IPv4 says here, but I know IPv6,
       and so I'm going to make IPv4 work as I understand IPv6
       to work''

are, as technical discussion, perhaps worse than nothing at all, when
the proposed changes will, by what mathematicians call ``by
inspection'', cause huge trouble for fairly common existing deployment
scenarios.

Re: your point about embedding policy in code being a bad choice,
compared to letting admins decide it and encode it: for pity's sake,
yes of course.  Does that point even need to be _said_?  If points
that basic really need to be made, , what does that tell you about the
technical skills of the people making the proposals???

Re: not seeing forest for trees: yes, I've been working with policy
issues, and an SO_BINDTODEV-like implementation for some years
now. Personally, I find that to be a *much* better solution for what
you say (in a subsequent message) you want.

Myself, I work in an enviornment where I run into problems with
multi-homing implementations on a regular basis.  Some of those
problems drive me nuts: e.g., multi-homed Linux NFS servers
unreachable by NFS-over-UDP, by the canonical address of their primary
DNS name, if you try to mount the server from a host on a different
network than the server's primary name but on which the server is
multihomed.  OK, time for a picture:

         net Y                     net X
client C ------    NFS server host ------  
                    multi homed
                     |
                     |
                   .....
                   Net W

client C on net Y sends an request to the server's DNS name, which is
a net X address The server receives those resposnes, and because the
source is a net-Y address, routes it out its net-Y interface. But if
that's a send() [not a sendto()] on an unbound UDP socket, the
outbound response ends up with a net-Y address, whilst the client is
waiting for a response from the nnet-X address it sent to.

Or another example: take the scenario you and I both want, whereby an
app can choose which of two local addresses it wants to use to talk to
some remote server. Suppose the client is multihomed (one interface or
two, it doesnt matter).  Suppose further that one of the client's
addresess is on the same subnet as the server and the other isn't;
it has to be routed.

Do you see already what is going to break here?  Or not?


Here's my own (perhaps rigid) take: redesigning multi-homing, or
whatever subset David is working on, is a problem that has a high
barrier to entry. Because IP(v4) it has so many weird deployments, and
so ways to run into more and subtler bugs, which are outside the
background of most of the NetBSD community.  Either that, or it
needs feedback from a group like an IETF WG.

I've had to acquire a fair chunk of that background.  But I don't have
the time to sponsor David to do it (even if he'd have me): I'm already
weeks behind on reviews on other requests, months or *years* behind on
some proposals from Yamamoto-san.  (I'm also behind on sending my own
SO_BINDTODEV-like changes to certain others for comment.)