MIF 1520 Tuesday Session 1: (Tuesday 1520-1700 Afternoon Session II ) 1 Agenda bashing (Chairs, 5 min) No bashing 2 documents (Chairs, 10 min) draft-ietf-mif-problem-statement-15 RFC 6419 Approved for publication draft-ietf-mif-current-practices-12 RFC 6418 Approved for publication draft-ietf-mif-dns-server-selection-03 Successful WGLC, will submit to IESG soon 3 In the charter proposal: draft-liu-mif-api-extension-06 (Ted, 15 min) MIF API Latest draft is a more complete API Published right before deadline 4 people have read it Provisioning Domains API exposes interfaces, but all actions are in terms of provisioning domains Link local is a separate provisioning domain? Maybe not. RA vs. stateful DHCP separate provisioning domains? API model Not trying to solve happy eyeballs or high level API Providing an API that maybe really smart apps might talk to Provides fundamental API that happy eyeballs might use MIF API -> Comm API -> Network Link API -> interfaces Should support any application, including servers MIF API Abstract API, no language bindings Too low level for most apps Provides sufficient tools to implement HL API does not constrain HL API implementations Message passing, not synchronous Analogous to unix routing socket Communications API How apps communicates after connecting Connect to multiple provisioning domains, you can authenticate a connection before deciding you are connected (e.g., to handle captive portals) Example Connection API: BSD sockets Network Link API Typically the OS IP stack Handles routing on a provisioning domain basis Also DHCP and ND are in here for brevity What's next? We've been interested in this for a while. Sort of converging. Is this something the WG should adopt? How many people have read? About 4 or 5 How many people think it is ready? Everyone who has read it We will take it to the mailing list Hui: comment on connection manager API, there is work that has been done in OMA. Many details, maybe too much for us. They have read this document, they are interested in supporting it. Brian Carpenter: have you looked at SHIM6 API? It may not compete with you, but perhaps there is a need for co-existence. It is not abstract, it would be unfortunate if there were an obvious collision Ted: no, will do so Margaret: There are no competing docs and it is in our charter, but we need a few more people to read it 4 New Proposals These are not in our charter yet, we are having this presentations to see if people like these ideas and maybe we can re-charter in future 4.1 draft-korhonen-mif-ra-offload-03 Yi DING, 15 min) Controlling Traffic Offloading Using Neighbor Discovery Protocol Was presented at IETF80 in Prague There is a need for a network managed solution to "guide" MIF hosts to prefer faster access, or prefer 'cheaper' access over 'expensive'. (ANDSF, SIPTO) DHCPv6 is not always available, thus ND as a "command channel" RFC 4191 supports IPv6 offloading. Route Information Option could be used for offloading Diagram: router commands, offloading traffic to different interfaces Message diagram: Oflloading option in Router Advertisement Changes: 'L' bit is removed, focus on IPv4 traffic offloading added Lifetime field combined Route Information option from 4191 Default IPv4 Gateway Preference: 'D' set to 1, use other interface for IPv4 traffic, if just available 'D' set to 0, use this interface for IPv4 traffic, when possible Offloading to specific routes Route Information Option with Preference value Offloading preference on default gateway Have implemented and tested using linux laptop with phone modems 3G as the commanding channel Offloading test and verification in live network still to do Sri: what are the semantics of the option? Is it a route? 2 kinds of ops. Specific route offloading, and default gateway Sri: how come there is no prefix mask in the option? Combined with Route Information Option, not shown Use the IPv4 mapped IPv6 address Sri: why that overloading? Why do you need to do that mapping? Hui: because this is an IPv6 option ND is IPv6, that's what we are using as a command channel Sri: how do you know the tunnel is dual-stack? Jouni: using 3G we have all the information Hui: 3G connection, you will know whether v6 or v6/v4 PDP Erik Nordmark: Don't quite understand how you would encode if you have 2 different prefixes want to send those on 2 different interfaces to 2 different gateways Aaron: there is a preference field in RIO Erik: which gateway is that supposed to go with? Aaron: we limited that, admin only sends one option Erik: ND options should be self-contained. Other thing that conflicts: if the option is not included in the packet, it has some semantics. Haven't done that with any other options. If you want to expire something should send lifetime = 0. Aaron: not overriding anything in 4191 Ted Lemon: 'D' bit: 1 = use other interface, 0 = force traffic on this one? Aaron: no, it is more advisory Margaret: how is one side going to tell you which gateway to use on the other side? T-Mobile doesn't know about the gateways in my house? Jouni: motivation is that you have a policy, "whenever you have traffic, send it to the other interface". Can pick a few destinations that you want to push off. Margaret: requirements are much higher level than whether to use v4/v6, 3G/WLAN. How does my 3G provider know my criteria? Aaron: many operators are deploying commercial access points. When operator knows AP position, they can instruct the user. For open networks it is more challenging. Hui: to summarize, fixed / mobile convergence scenario only. For operator to deploy WiFi, you can have integrated vs. open. You are focused only on the integrated scenario. Sri: base assumption is integrated scenario, there are already policies that can be delivered to the UE Demo: do we have a specific API, then that would override the default policy that operators provide. Lorenzo: sometimes the radio is far away from apps, so sometimes using this method through the kernel is often better than passing it through the radio. Why are you using v6 to control v4? Demo: 3G network is v6 only. Host has to choose v4 or v6 for each connection. Lorenzo: that's not what's here. This is based on destination, go one way. Aaron: that's why we removed the 'L' bit for source address selection. We dropped it. Lorenzo: RIO option to control traffic, why doesn't DHCPv4 do what you want? Aaron: RA is more appropriate for open networks Lorenzo: mechanism where host listens to the network is more appropriate? Aaron: battery life is drained when host scans for WiFi constantly Hui: terminal is IPv6 on 3G, IPv4 on WiFi Lorenzo: no, you will never use a v6-only interface for v4 traffic Hui: if that is not an example, then. Lorenzo: what is it that makes RA better than DHCP? Hui: 3GPP specified RA to configure the address Lorenzo: because it's already there is the answer, then. Dmitri: Margaret remarked: apps do not care whether it is WLAN or 3G or whatever, they care about service (i.e., address will be maintained, etc). In the US, devices need to provide policies to control application behavior. There is also some sort of interface already (today vendor specific) that solves these scenarios. Should look at what support is in APIs across different vendors. Also, for DHCP there is already work done for configurable address selection policies, that's what the WG is for. We should not keep proliferating different solutions. Raj: is RA coming from PDN GW? Aaron: yes, for certain type of traffic, offload it unless there is no other interface Stuart Cheshire: our approach is that if the device has a faster interface like WiFi, then use it. That's what the customer wants. It is very strange that the customer is paying for the service but the operator is saying not to carry the packets. Ted Lemon: If you have a valid A and AAAA, default is supposed to be try the AAAA first, what this is saying is "I prefer you to try the A record first". Aaron: focus more on the interface rather than whether it is v4 or v6. We did not classify. Jari: piling on what Stuart said, it is about the network deciding what to do. Should be the user/device making the situation. Some information from 3G might be useful, but decision should be up to the device. 4.2 draft-chen-mif-happy-eyeballs-extension-02 (Dan, 10 min) Diagram: Define happiness, open a HE connection High level requirements in terms of fast/slow paid/free per packet services. We should allow the application to see both interfaces. Allows us to do MTCP/MRTP, etc. Keep the user in control. H.e. Syntax analysis, data delivery Differences between -02 and -03: More details about apps & kernel implementation Working group interest? Margaret: how many people have read the MIF happy eyeballs doc? A decent number of people. Brian Carpenter: this is not the v6ops HE document, this is the MIF HE doc. As I look around, I see free and non-free wifi. Would the user have a way of tuning this as they walk along the street? DanW: there is bw limited/unlimited, there are paid 9600kbps links. You are stuck with the user fidlling with a lot of variables. JuanCarlosZuniga: Last week at MIRACLE, we were discussing what info to provide. ConnectionManagers need to provide this information. What is the consumer of this info? Application, user, device, something else? We would like app developers to be able to create apps without caring what is underneath. DanW: do you think you will find an app developer who thinks that their app shouldn't go over a paid interface? What about retrieving ads? Users should be in control. JC: we would like to digest that and not have the user making decisions every time. DanW: yes, it's a fine line. But there is not an alignment of goals between app developer and user paying the bill. TimChown: like HE for v4/v6. For this, I am not so sure. User would manually toggle on/off the connection. DanW: 3G with v6/v4, WiFi was v4, wouldn't you prefer v6? CMs work today by hiding the lesser preferred interface from applications. TedLemon: in Tokyo, rented $15/day LTE wifi modem. Here, 3G unlimited data no problem. In the US, 200MB limit. Don't have control over whether limit was used up by ads. It is done by the web browser. Skeptical that it is possible to do a good job with the "define happiness" part of the spec. Margaret: like the notion behind the spec. Like this approach. Personal opinion: we should focus on this kind of approach and decide what to standardize so user doesn't have to put in so much information. We could standardize ways for networks to tell you. Dmitri: 2 different problems. Originally, HE was about v4/v6 due to reasons that network path was faulty. Host usually has no way to know, so must try both. A different problem is when host has some information, which interfaces are available, there is some information about each connection. Policies can come from user, from operator, from applications. There are ways to mitigate the greedy application that always wants 3G. Need to separate from the original HE problem space. One problem is that apps may need to specify preferences for connection types (in light of policies from operator), the other is that once you have acceptable interface types then you need to use happy eyeballs to initiate connection. ZenCao: do you need new APIs to specify "happiness"? Danw: yes. ZC: then what is relationship to MIF API draft? Margaret: MIF API says it will support higher level APIs like this one. ZC: Previously we talked about RA vs. DHCP, now we also have application API and HE to specify preferences. How can we resolve the conflict and overlap? DanW: Policies that come from networks are often wrong. Could say to use WiFi but WiFi might be broken. Need to make use of user preferences and try different interfaces even when they conflict with policy. Hui: need additional documentation about how to specify policy Margaret: My requirements are usually non-technical. User doesn't want to use IPv4 vs. IPv6, they want to get connected. TecoBoot: this touches cross-layer interfaces, information also flows from bottom to the top. Link layer can provide information which hints at selecting codecs etc. Sometimes bottleneck is several hops away. Related to MTCP etc. DanW: yes, let's walk first. First is to just do a connection and take the fastest one. Teco: need a framework so we can fly, swim, etc. TimChown: if I could run something that would tell me what was available and what it was costing me, that would be great. With original HE, users weren't complaining about broken v6. You may not realize brokenness unless you get alerted. DanW: yes, becomes more difficult to realize brokenness Dmitri: other requirements are they don't want their call to be dropped. ConnectionManagement problem is more complicated than just picking the fastest interface. Different apps have different requirements. Margaret: How many people think this is interesting? Quite a lot of people. How many people think this is not something we should look at? Nobody. Ok, quite promising. Session 2: (Tuesday 1710-1810 Afternoon Session III ) 5 Working Group LC Documents draft-ietf-mif-dhcpv6-route-option-03 (Tomek, 15 min) MIF DHCPv6 Route Options Post WGLC summary Tomasz Let's discuss the issues that came up, don't blindside Tomasz until the end WGLC was announced on -03 IA_RD option was removed Route Lifetime added Does not affect how DHCP does renewal, using standard refresh time for that Lifetime in seconds, 32-bit number Clarified that a default route can be configured Can use a very short option for bandwidth constrained environments SHOULD NOT be used in a dynamic routing environment Resolves Routing Directorate comments WGLC in MIF completed Also requested review in 6man and DHC Questions/Comments: DHCP vs. RA Suggestion for separate option for default route? Source routing? Any implementations? Suggestion regarding more efficient prefix format DHCP vs. RA What if there is conflicting info in RA vs. DHCP Proposal: favor DHCP over RA Rationale: RA is for all hosts, DHCP should be able to override the defaults But, what if RA is more secure due to use of SEND? Then use RA If DHCP is also secure, DHCP wins again Why not provide source routing information? That's a different problem The options can be extended later if needed Configuring source routing is a difficult problem Separate option for default route? No. One option handles both. MAC/Link-layer address info? No. ND handles this. Changing interfaces means reconfiguring DNS server Prefix format changed to variable length Next steps All issues except RA vs. DHCP have been resolved. After this IETF, we can resolve this and then proceed to -04 version Implementations Yes, at least 2. Links to how to configure ISC DHCP 4.2.3, Dibbler 0.8.1RC1, Nominum (Ted Lemon confirmed that custom options can be configured ISC and Dibbler tested and they are interoperable Now back to DHCP vs. RA discussion Margaret: some people want to discuss broader issues with the draft. More people have reviewed it now than earlier. Let's do specific comments on the preference options. Ted Lemon: I thought we had resolved the issue. I think we're done with this. Dave Thaler: These reasons don't motivate this particular proposal. If I get two RAs from different routers which one to I prefer? Margaret: use both Dave Thaler: and if route options, put all of them in the list. You put the union in the table, information in them is used to choose among them. Why didn't we make the same decision that DHCP is just another source of information? What is the reason to ignore the less preferred? Tomasz: no answer. Lorenzo: variation on previous comment. Two home gateways? Ted: Rationale for replacing rather than combining is the notion that DHCP in a managed network will tend to be more specific to a device. In the case you have two home gateways, is it ever intended that a home gateway would ever send this? Tomasz: doc does not lay out specific use cases Ted: not clear what the motivation would be unless you have high level management TimChown: device would just get things from both DaveThaler: one reason you could have ignored one is that there is not enough information to do the comparison. This one has a metric RA has a two-bit preference. If instead the document had tried to duplicate format in the RA these issues would not have come up MarkTownsley: Homenet chair. We didn't really discuss home networks in this group. Is this only for enterprise? (crowd says no) Lorenzo: as a developer, I don't understand why this is in MIF. As a MIF developer, would much prefer to have only one thing to implement: RIO option. When multiple different mobile networks will want to use multiple options, would like not to do twice the work. Margaret: Reason why it's in MIF: homenet was not even a glimmer in MT's eye. The reason it's in MIF is because we were dealing with question of whether you have 2 home gateways, one is a walled garden. How do you know what to send to the walled garded vs. the other interface? That is what this work was intended to address. Lorenzo: natural answer is the RIO, that's what it's there for. Margaret: these options already exist for IPv4. Some people said they wanted to do the same thing for v4 & v6. Lorenzo: completely different protocol, but ok. Moving on: the DHCP options are a subset of the functionality offered by RIOs. Timeouts/lifetimes are more elegant with RIOs. With DHCP I'm stuck pointing at a default router that doesn't exist. DHCP means you have to pick a default route that goes with the address that you get. Forces you to implement VRRP. Seems like DHCP is a lot of stuff bolted on for no good reason. Same as v4 is not a good enough argument. Tomasz: wasn't original author, they have all run away. Can you do with RA per-host configuration? Lorenzo: no, that's the only thing you can't do. If you want some hosts to reach certain other hosts, put them on different subnets/VLANs. Tomasz: this draft was merge of 3 different drafts. We chose minimal set of options to configure routing. You can add sub-options later. Lorenzo: this is just more and more code to do things we can already do. I don't see the use of having all this extra code and new options. Wolceich Dec: route started with more specific options, yes, we are duplicating functions. StuartCheshire: same boat as Lorenzo, we're the people who have to do the extra work. We are documenting all the other ways to do the same thing. One of the benefits of v6 was better simplicity. Now we are back-filling all the things that v6 decided not to do. WD: do your products implement ICMPv6? DHCPv6? (yes). This uses the same protocol,it is already in your product, CLI static routes? SC: no. You can't configure static routes on the phone WD: protocol instantiation of an interface you already have in your product. SC: only advantage I've seen is that you can configure each host differently, don't see why that's such a big advantage. WD: edge routers should be configured simply, then other things for specific customers configured centrally through DHCP. SC: didn't see that WD: do we manage things on the routers or centralize configuration with DHCP? JohnMuszowski: if option specifying default route points to a router that isn't there, how would you un-strand that client from no longer having a valid default route? Even a reconfigure will not reach the client. Tomasz: can specify lifetime of zero Margaret: if default router is gone, he can't send a message to the DHCP server WD: ND test. If he's not there you remove the route. Margaret: When default router is down, cannot send a packet to DHCP DaveThaler: That's not how 3484 works. See Rule 1 Margaret: but there's no one else on my list, I took the DHCP option DaveThaler: that's the problem I had. You shouldn't discard the RA information, you should merge it. Can be fixed if draft is to go forward. Internet Area discussion from Ralph and Thomas on why people want this, so I'm ok with it, but we should fix it. [slide from 2009 displayed] Lorenzo: don't see any discussion of advantages of RAs DaveThaler: that's a different slide Margaret: There is a notion in IPv6 that one could configure everything using DHCP and not use RAs to configure the hosts at all other than finding the routers. ND / RA is the way to find neighbors in v6. WD: question: what is the actual objection? Lorenzo: already read them. 1. doesn't do a whole lot more that RIOs 2. does double the implementation effort Margaret: can you configure a prefix on that device with DHCP? Lorenzo: no, doesn't implement DHCPv6 at all. 3. in home networks, no centralized control or VRRP, loses functionality compared to RAs. Can't be deprecated, you have to poll to deprecate WD: just like any other option in DHCP. It can run stateless (there forever) or it can be refreshed at the time of lease refresh. This option by itself doesn't trigger the poll. Lorenzo: cannot be deprecated by someone who didn't issue the lease WD: just like other DHCP options Lorenzo: RA doesn't have this problem. With RAs the other router can deprecate. WD: if you deploy DHCP on your router you can get exactly the same behavior Lorenzo: if router goes down the nonce is lost WD: you can do this with VRRP Lorenzo: so now home gateways have to implement DHCP/VRRP? We want zero configuration. 4. Fact that it's centralized control means there is no fate sharing 5. Don't see how it belongs in MIF anyway, belongs in 6man, has nothing to do with multiple interfaces 6. Use case of different gateways for different hosts, put them on different subnets/VLANs WD: I'll send you the original draft with more context/use cases, will tell you why it ended up in MIF. Lorenzo: should be in this draft MarkTownsley: biggest concern is that this might break homenets. This needs a trip through homenet. Maybe it should have a homenet considerations section. Lorenzo: DHCP client chooses one of the servers. Dmitri: when DaveThaler said problem was fixable, this slide assumes no RA will be used so not fixable TedLemon: if we just preferred RAs that would solve half the problem (not the implementation). Latest 3GPP spec requires DHCP-PD if you are doing tethering. Margaret: Don't remember how long we discussed whether there should even be DHCPv6. DHCPv6 is there to configure both things that can and cannot be configured with RAs. There is a belief by some that there is a world of people who want their whole networks configured by DHCP. We can't just ignore those people. TedLemon: (back to DHCP choosing one server) is a really interesting question in homenets with dual gateways. We have to address that question. Margaret: we've been talking about that for 7 years TedLemon: DHC WG didn't want to do this option for exactly these reasons WD: there are parallels between this and lots of other options TedLemon: propose compromising by reversing decision on DHCP vs. RA Margaret: that's what we can consider if we still want to publish this document. Want to get a feel of the room if this is a document that the WG still wants to publish. WD: aside from implementation, lots of questions about dual routers involve multiple interfaces. Route Option is one case, DNS is another case. Margaret: we are chartered to work on this document, there was a long discussion in 6man to put it here. We should decide whether to publish the document, we cannot move it to another working group. MarkT: you can have it reviewed explicitly by other WGs (homenet) Margaret: yes but if this group does not want to publish it would be wasting their time Poll: how many people believe we should still go forward with this document? about 3 times as many people want to go forward as don't, not sure if that's consensus, but it's not consensus to stop. Maybe there's a way to scope this to make some people who have concerns more comfortable. BrianCarpenter: DT worried me about the different semantics between DHCP vs. RAs. Margaret: agree, we should put it on the list Roberta: there is another document in IESG review that references/motivation about Without NAT66