Hi folks, On Nov 9, 2009, at 8:14 PM, William Herrin wrote:
Hi Folks, I'm just joining the list. I would join you at the meeting but I'm about half a world away right now... I've read the charter and the draft problem statement at http://www.ietf.org/id/draft-ietf-mif-problem-statement-01.txt and I've leafed through the list archives. I have some comments I'd like to share as I try to get up to speed. Feedback would be helpful. 1. The draft seems pretty focused on end-hosts, that is systems which originate or consume but don't forward IP packets. Routers are hosts too and figuring out how to handle packets to multiple upstreams in different administrative domains is important there as well. Otherwise we limit ourselves to only the simplest case: where no component larger than a single host is a member of two networks. As often as not, that isn't the case. The entire local LAN can be a member of two upstream networks and it'd be nice if entire routed subsystems could be members of two networks. Even if we don't want to address the router case explicitly, it might be helpful to look at whether the router case offers any insight into the grouping and relationship between the issues in the host case. Source address selection, for example, could be viewed through a routing lens: find the destination in the routing tables associated with each of the hosts's source addresses, return a list of source addresses for which the destination is reachable and weight the list based on the specificity and metric of the respective route. Looking at the problem from that angle, all hosts are MIF hosts. They have a unique loopback network which is administratively separate from any physical wire to which they attach. Put another way: from the perspective of MIF, loopback doesn't look like a special case.
In the edge router products I think that there exists solutions how do they handle multiple interfaces and metrics of those. So if you have two interfaces through which you can reach the network the router usually makes the decision based on metrics and some times even based on policy based routing rules.
But then again if the intent is to bring up issue on how a host (e.g. BSD) acts as a router or when using static addressing (not DHCP) that is whole different story. E.g. in all BSDs it is possible to use multiple defaultroutes based on the source address the application select using firewall rules. Almost all firewall implementations allow you to specify next hop for the packet based on source address, destination address, outgoing or incoming interface or by any combination of these. So if your BSD/Linux host acts as an router or you use static addresses in which case you know the addresses of defaultroutes before hand you can do a lot more than what ISC-DHCP can do. Even in the case of ISC-DHCP you could by creating dhclien-scripts change the default behavior of address lease for example to modify your firewall rules according to the address lease information. In the recent versions of FreeBSD 7.x-> there is introduced a functionality that allows you to have multiple routing tables and you can for example limit that certain process may access only certain routing table thus mandating that packets coming from that process are routed according to that table. This is useful for example in the cases where you have multiple virtual hosts or jails (sandboxes) running in one physical hardware thus you can limit and control how the packet are routed from that entity.
So all in all. I think that most of the features that are needed to actually route packets based on source address or interface basis exist in the kernel but usually when you take the system out of the box (CD) they are not used. You have to really be a geek to get them to work as you would like to and not even then are things easy unless you really know how the kernel works.
2. DNS strikes me as a subset of a bigger problem: naming services. Other naming services such as the windows browser, windows domains, LDAP and NIS will be impacted in more or less the same way that the DNS is.
Agreed. DNS is really a problem as the first resolving of the address already mandates which interface you choose or if you use multiple and get multiple different answers how are you supposed to know which address is more appropriate.....
Jan
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.