MIF Working Group Meeting (IETF 77) The MIF working group was held at IETF 77 Anaheim at 9:00am on Monday, March 22, 2010 in Room Huntington. Chairs: Margaret Wasserman and Hui Deng 1. Preliminaries (5 mins Chairs) - Blue sheets - Note takers: Carl Williams - Jabber scribe: Behcet Sarikaya - Agenda Margaret: goes over the agenda. Said we will go over 3 major documents: problem statement, current practice, analysis draft. ------------------------------------ 2. Problem Statement presented by Pierrick Seite (10 min) http://www.ietf.org/proceedings/10mar/slides/mif-1.pdf http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-02.txt Pierrick stated that there were a couple of issues raised and comments made on mailing list. As such a new version of the draft was produced. Two issues: (1) connection manager and API; new text was added. (2) next issue was about GROBEJ; as such text was added in section 3.5. Hui: The document is currently in working group last call ending March 26, 2010. Margaret: Please review the document. There will be a new version based on your comments. A determination will be made if there are substantive issues and if we need a new working group last call. Hui: Interested in seeing an alignment between the problem statement and the analysis document. --------------------------------- 3. MIF Current Practices (Margaret Wasserman, 5 min) http://tools.ietf.org/html/draft-ietf-mif-current-practices-00 Margaret states that there are no slides. The current practices draft was last updated in October 2009. Looking for a co-author to finish the document. Goal is to get it out. The document already served its purpose which is input to the analysis draft. The document is pretty much ready for last call. There have no new comments since the last IETF. Margaret: Now move on to the DHCP topic area. This option was discussed on the DHC working group list and sent here for a presentation. After the presentation we can discuss if this is related to or helpful to the MIF problem. Jari may have some things to say after the presentation as well. ------------------------------------ 4. DHCPv6 Route Option (Wojciech Dec, 10 min) http://www.ietf.org/proceedings/10mar/slides/mif-3/mif-3_files/frame.htm http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-02 Wojciech stated that 2 scenarios that we see are applicable. First, the classic multi-homing scenario. Wojciech described the scenario whereby a single shared VLAN connects clients. Both clients are assumed to have IPv6 addresses from a global scope and obtain their Internet connectivity via router identified in his figure as router B by means of a configured or a discovered default route. Wajciech says that it is desired for client 1 to use Router A as its primary gateway for destination X/Y: A more specific route to X/Y via Route A is thus required. The default route for both clients is to use Router B. Wojciech says that it is required to operate in an environment where per client configuration on the Router is not possible. Wojciech begins to describe the second scenario whereby a single client connected via two logical or physical links to Router A and Router B. It is desirable for the client to use Router B as its default gateway. It is also desirable for client to use Router A as its primary gateway for destination subnet X/Y. More specific route to X/Y is thus required. Wojciech notes that it is required to operate in an environment where per client configuration on the router is not possible. Wojciech describes the scenario 1 usage of DHCPv6 route option using ORO which may be among other options. Here the client requests DHCPv6 RO with ORO and the server replies with Route option for Prefix X/Y via Router A. Wojciech states that the client installs route X/Y with link-local next hop (router A). Wojciech notes that IGPs solve the problem but are often not feasible for deployments such as broadband DSL. The DHCP mechanism is primarily envisioned to be used by broadband RGs acting as DHCP clients (PD, etc). Finally Wojciech states that there is tentative work to unconfigure static route. Marc: For scenario 1 where is the DNS server? There is kind of implication that the client gets the right address from the DNS. My point is that if there are 2 different providers, then you get DNS from somewhere in router path. Wojciech: DNS is a parallel problem. Don＊t need to be covered in this draft. Margaret: There is not specifically 1 DNS server. Presumable that the DHCP server is providing the DNS information as well. This is a broadband usage type of case. Marc: What about two different administrative domains? Wojciech: Simple scenarios is everything is to the same operator. This is simple one to worry about. Harder one is if you have 2 admin domains. May have 2 DNS. This needs to be tackled but not part of this draft. Jari: Continuing on this question, I think your background is that you want to do something specified in broadband forum (BBF). The practical case is that you have your iptv server behind the home router. What do you do about the dns 每 is that specified by the usage case or market? Wojciech: today this is done by one operator in broadband case and there is one dns server. I do acknowledge that there are cases where you have separate dns servers. I don＊t have a solution off the top of my head for that. Marc: The route you are pushing doesn＊t have any time to live or lifetime? Wojciech: Yes, at this stage I defined it to be a very simple option. Didn＊t define lease or lifetime for the route. If it would expire then there would be a forced renew. We are currently have discussions around this. Marc: Lifetime would be the right way. Wojciech: There is no timer associated with DNS server. David Hankins (ISC): Talking about two different things. There is own timer built into the operational request. It is not an active drop but a passive update. David Hankins (ISC): I am a little concern when you talk about a single link with multiple administrative using dhcp. As the standard is right now, for example, stateless you will accept the first reply you get ＃ you don＊t take several different replies and combine them. In stateful it is the same thing 每 it actually defines the process you get for replies and you pick one. So DHCP may or may not be the right solution. Margaret: Any more comments? No comments＃ Margaret: Do you want to get up or do you have something to say. Jari: You are looking for a home for this work. My own opinion is that if this work makes sense then MIF would be the place to do it. As you guys are the expert on multiple interfaces and multiple domains and so forth. It would have to be done in together with the DHC working group. The question is do we really believe this is the right approach or right technical tool. Questions I have at least is the issue that David raised with multiple responses from dhcp server and the other one is DNS question 每 although I am not so worried about that too much. If we went to the routing community and ask do you like this solution, you also have some comments. It all depends on what kind of scenario we will be looking at. Host getting this information then I don＊t think that the host will be implementing a routing protocol but in your specific example here where you have a RG as a router that might be an option which has capabilities that are better for updating information than DHCP has. There are tradeoffs. They are the kinds of questions we have to tackle. I don＊t have any problems adding this to the MIF charter if we believe this is a useful thing to do. We haven＊t really got a level of feedback from the group yet. Yuri Ismailov (Ericsson): Operator specific service - is this a service placed in the Internet. Wojciech: It is wall-garden. Yuri: Then the problem is not clear at all. I assume the router will have different prefixes. Normal router in client will not choose next hop. Wojciech: Not quite. Only the client has specific routes. Not clear from this picture is that you would not typically being having router server addresses of router A and router B. Wojciech: Multiple prefixes need to be configured. Bernie Volz (Cisco): In this case what happens to client 2 gets connected to the IP subnet. What＊s going to happen there if he doesn＊t have that route or if this option you are talking about is not supported by that particular client. This seems to me as a very contrived configuration. Is this realistic? I don＊t mind scenario 2 where you had 2 different interfaces. That makes a lot of sense. That is a real world solution that I think we should focus on. I like to understand where this is going to be deployed and what we are going to do here. Let us address scenario 2. Then we need to describe scenario 1 better. For example, why it is critical, why it is important and why this can＊t be solved using standard routing. Such as ICMP redirect or routing infrastructure. Yes, they may not be as efficient as you like but they work. So unless you can tell us why this is critical to solve then I would remove this. Lesser concern than scenario 2. Marc: You were asking about drafting this work in working group. If someone takes a top-down approach, MIF has different problems. This is one piece of the problem. It appears as a working group we are not quite there in terms of where to fix things. We are kind of going there but not yet there. Premature to say we need a might dhcp solution 每 it may not be that or something else. There are more issues that have higher priority such as DNS before routing. Teemu Savolainen (Nokia): It looks interesting to look further into this problem. Zhen Cao (China Mobile): It is timely to solve this problem. We have the same consideration on this problem. Margaret: As an individual contributor, I think this type of option can be really valuable as part of the solution for the MIF problem when you trying to solve it at the IP layer. If you look at the current practices and to some degree the problem statement and the analysis documents, you can see that people are trying to solve it at different layers. For a solution at the IP layer which would be idea and I think that the option that you provide would be part of the solution. I would have no objection to working on it in MIF and standardization it even if we end up with the idea that we should work on a high-layer solution which I think is still an open question. Jari: I think that the conclusion is that this is interesting but that there are still some questions about the scenarios 每 1 versus 2. Also you were focused on routers and maybe this working group wants a solution for clients. I am worried about multiple dhcp servers. I think that we should continue the discussion and we are not quite there yet. But maybe we will get there in a matter of time. We will see which of these scenarios make sense. Wojciech: Should we continue this on MIF? Jari: The right place to work on this is at MIF. We should get some additional DHCP and routing expertise to participate in the discussions. Your mechanisms work fine with hosts. Marc: I agree this work should be done in MIF. I just want to see the whole picture. ------------------------------------ 5. DNS Server Selection on Multi-home hosts (Teemu, 5 min) http://www.ietf.org/proceedings/10mar/slides/mif-2.pdf http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection-02 Teemu explained the changes between version 00 and 01. Teemu added issues caused by synthesized AAAA records (DNS64/BIS): those addresses are valid only on the interface learned on. He added an FQDN may identify a service that provides different services on its different interfaces (e.g. Internet and Intranet facing). Teemu added DNSSEC reference and dealt with NITS. Teemu then explained changes between 01 and 02 versions. Teemu explained that he added a DHCPv6 option to configure explicitly which suffixes are particularly served by a DNS server 每 and prefer that server with matching FQDNS. DHCPv4 option not yet included but could be similar. Teemu asked for feedback on the MIF mailing list. Zhen Cao (China Mobile): This is based on DNS config on interface not on host. ------------------------------------ 6. DHCPv6 Extension for Configuring Hosts with Multiple Interfaces (Behcet, 5 min) http://www.ietf.org/proceedings/10mar/slides/mif-5/mif-5_files/frame.htm http://tools.ietf.org/id/draft-sarikaya-mif-dhcpv6solution-03.txt Behcet explained the problem statement for the draft. He stated that setting up a single default route using RAs is insufficient. In some networks, DHCP is used for host configuration including address assignment. Behcet defines as the solution a new DHCPv6 option and five sub-options. Behcet states that the MIF working group should consider this solution when rechartering. Hui: Take a look at all previous questions related to this draft. ------------------------------------ 7. Route Configuration by DHCPv6 option for hosts with Multiple Interfaces (Presented by Zhen Cao, 10 min) http://tools.ietf.org/agenda/77/slides/mif-4.ppt http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-01 Zhen Cao presented scenario that since there are various access networks and UE equipment with several interfaces, the host may connect to more than one physical network through different networks interfaces simultaneously. Zhen stated that the problem is current TCP/IP model only allow one default network connection at once and no route item will lead traffic to appropriate next-hop router. Zhen explains that his proposal extends DHCPv4opriate next-hop router. Zhen explains that his proposal extends DHCPv4/DHCPv6 option to carry policy in order to form static routing entries in host. Peter Koch (DNSOP co-chair): Binding of domain names to interfacdes I am not sure it will work. We need to have cooperation between the two working groups (DNSOP & MIF). Bernie: V4 uses costly encoding. V6 defining two options we should not define so many options. Jari: I agree we shold not do mulple ways. For IPv4 we already have a mechanism. Best possible solution is routing protocols but they are heavy weight. DHCP v4 informational routes already exists. Look for simple light-weight solution. ------------------------------------ 8. IP Family Selection for MIF Host (Presented by Zhen Cao, 10 min) http://tools.ietf.org/agenda/77/slides/mif-6.ppt http://tools.ietf.org/html/draft-cao-mif-ifs-00 Zhen Cao explains the problem of IP Family selection. He goes into problem of NAT64 or NAT 44. The default address selection defined in RFC 3484 will prefer IPv6 over IPv4. Zhen questions is this optimal? NAT64 or NAT44? He states it is good to moving traffic to IPv6. If no however, how different policy is delivered to the host. He mentions draft-behave-wing-dns64-config and draft-savolainen-mif-dns-server-selection. Zhen Cao proceeds into the 2nd described problem in his slides as NAT46 or NAT464. Zhen then describes problem 3 of source address selection: Self assigned IPv4 or net-assigned IPv4. Zhen Cao proposal is to add text on IP family selection to problem statement explicitly. Jari: There are issues but different ways to solve. Why do NAT44 or NAT64? We don＊t have any networks that do both Zhen: It happens in mobile networks. Jari: Why is this in MIF working group. This is behave, 6man, etc. ------------------------------------ 9. Socket API Ext for Multiple Connection Support (Presented by D. Liu, 5 min) http://tools.ietf.org/html/draft-liu-mif-api-extension-01 No slides posted yet. Liu states that there are no API level support for the application developer to utilize the benefit of the host＊s multiple interfaces or connections. Liu States that his proposal introduces a new set of APIs to support multiple interfaces and connections. Jari: this is interesting. We should work on API. ------------------------------------ Wrap-up remarks: Margaret: Please read the analysis draft. We are done with the meeting.