MIF Minutes: Ted Lemon, Ian Farrer Jabber: Mikael Abrahamsson 1 Agenda bashing (Chairs, 3 min) 2 MIF document status review (Chairs, 10 min) 2.1) draft-ietf-mif-happy-eyeballs-extension 2.2) IPR disclosure on MPVD DHCP 6 MIF MPVD DNS Proposal (Markus, 10 min) draft-stenberg-mif-mpvd-dns 3 MIF MPVD API requirements (Erik Kline, 45 min) draft-kline-mif-mpvd-api-reqs 4 MIF/Homenet discussion(Margaret, 45 min) 5 MIF WGLC status (Suresh, 30 min) 5.1) draft-ietf-mif-mpvd-ndp-support 5.2) draft-ietf-mif-mpvd-id 1 Agenda bashing (Chairs, 3 min) Steven Barth (SB) - Why is the open discussion in the middle? I would suggest it goes to the end Magret (MC) - The problem is that problems have been raised Tommy Pauly (TP) - Maybe not move the discussion to the end. Why not put the new solution before the discussion so that people know what it is MC - we could go through all of the presentations first and move the DNS talk moved to the beginning 2 MIF document status review (Chairs, 10 min) 2.1) draft-ietf-mif-happy-eyeballs-extension DT - Clarifying question - RFC 6555 does not specify a mandatory algorithm, only requirements for algorithms, and an example algorithm. Does this draft try to make a particular algorithm mandatory? HD - HE document can follow whats in the current RFC. DT - my question is does the current draft specify one? MC - The authors aren't here. We need to ask them. 2.2) IPR disclosure on MPVD DHCP IPR question re: DHCPv6 option: working group is dropping this work because of the IPR. SB - Is a license with possible fees reasonable and non-discriminatory? Can I put it in open source MC - This license in not compatible with open source LC - can we change it? MC - The chairs will ask Huawei to change it LC - if we cant, then we drop it Brin Haberman (BH) - Don't negotiate LC - amend my suggestion - drop the work TP - We should drop it, there's nothing we can do with it SK - It's sad and surprising. MC - we'll probably drop it. I'll send something to the mailing list EK - Will we drop it and tell them, or keep quiet MC - I think we would notify, but I'll check into it. Their email list goes to their lawyers. MC - The conclusion is that we will drop the work and follow what the policy is meant to do 6 MIF MPVD DNS Proposal (Markus, 10 min) draft-stenberg-mif-mpvd-dns MC - Remember, we're not going to discuss it until the end SK - It's an interesting idea SK - Not a good idea to use TXT records. A new type should be used. There's guidelines and they dont'. It's not clear who deploys the DNS. If it's a walled garden, how does the DNS work There needs to be something about the deployment in the doc SB - These are valid questions, It might be possible to use a new record type. We modelled it like DNDS-SD at the moment. The ides is that the owner of the prefix provides the DNS server and info SK - If there's two DOS servers, walled and internet, you need to tell the client to go to the internet on SB - It's a -00 draft MC - Take it to the list MS - You have to have DNS working, but you need that for things to work HD - Operator deploying DNS servers on two connections will coordinate the DNS configuration. TL - You're going to have a lot of records in the DNS. It's going to create pressure to have a fake DNS, which means that there isn't real DNS. YOu need a mechanism that's less explosive maybe a higher prefix SB - It's hard to say always look up the /56 MS - We talked about having an option for looking up the prefix length Ray ? (RP) - RFC5507 talks about different ways of identifying different records. 3 MIF MPVD API requirements (Erik Kline, 45 min) draft-kline-mif-mpvd-api-reqs Ole Troan (OT) - if I'm connected to two ISPs on a link, do I have 2 PVDs? EK - Ideally yes OT - I want to use them both at the same time. Can I do that with this API EK - yes, you could with this API. If your OS API offers you that granularity. But you would have to handle them as separate streams: the API shouldn¡¯t merge them for you. Glibc might wrap it so that it works, though. OT - It wouldn't be easy, but possible TP - You can interact with multiple PvDs at once, but at the level of a single operation you have to specify the PvD to use for that connection.to respond - the intermediation level of API would allow you do this - e.g happy eyeballs. this is at the level. You'll need to use multi PVDs at the conceptual level SB - how would this work with MP_TCP where I have a single socket. This would be a problem EK - similar sctp bindx. There's a way of doing that with a resolution scheme later in the document, I¡¯m arguing that there is a way to do that with a PVD resolution scheme. TP - the way that we've done this is that you do a connect on each subflow and then they are aggregated, we handle that by every given call for a subflow is a separate socket call. So you do a different connect. The intermediate level aggregates. Slide 6 DT - Question about bullet 2. It's OK if appropriately phrs Problem when host has routing enabled packet goes into the host and out of a different interface - that violates the must EK- I took the text from 1122 DT- The problem is where it says the host sends. it's the context of the interface. MC - In bigger routers theres a dichotomy between the routing plane and the management plane. I don't think this is meant to dissallow this DT - Common in routers but no in hosts, I am talking about things that are originiated on the the host. App has chosen the /64 on the interface going to the internet, The host is implemented as a strong host EK - Are they both in the same PVD DT - Not in this example. they are implict, one on the privat and one on the public. forwarded LC - How does tht work, your sending a 10.0.0.0 address to the internet DT - It could happen if it was coming from the LAN interface MC - It does work, but it's a special case DT - I'm saying that it's phrased ambiguosly at the moment, the interntion is fine LC - You're providing a subset of information for a VD that you didn't create yourself. Do you have and example when you didn't create the PVD yourself DT - what about if a human created the PVD Slide 7 DT - If your'e originating it and the application's chosing the source address. DT - from memory, if it's in the section about when the app doesn't chose the source address. I've got to chose the right source address for that interface. The claim was **** DT - different question - what on this slide is about api rather than behviour EK - this is needed to specify the api RT - I think this is MC - do you mean this should be in the arch doc? that's informaitonal. Should there be a 3rd doc SB - With the route isolation - does this reuquire hosts to have some kind of policy routing? If you have IoT devices, they might be using the default route. There are things to be aware of that might add a lot of complexity to hosts EK - The host operating system has to be able to *** MC - If there's a node that only has a default router, it's going to need a def. route per-pvd SB - If were using the ra model, then for every pvd do I need to add a pvd. I have ** EK - This could include a defualt router SB - Is the def route applicable to all pvds? this has severe implications to all implementations? MC - If there is one router sending informatoin about 2 pvds why doesn't it send you info about 2 dev router SB - There might bee a walled garder pvd that doesn't have internet access, then how do you deal with routing and source addresses? EK - If you spec ras within a pvd. this places a requirement on the contianer to set a bit for the default route LC - Where did the that discussion land? that a default route can apply to all pvds EK - No, there should be a flag on applicability LC - I see, it's just a lifetime. What if it applies to some and not to others? MC - If there's only one router on the network, then there's actually only one route. I'm trying to envisage where this is a problem EK - There would be an extra bit in an RIO saying that the default route can be used LC - What does that say for other PVDs that aren't part of the RIO that I'm processing? You need to postulate the existence of src/dst EK - The def route would be to the router that you learnt it off? LC - Do you install an unspecified free for all default route as well? OT - 6man moved on host draft going to last call, can you make sure there is no conflict? MC - Could you send the last call to MIF EK - It looked interesting. I'll read it Slide 8 TP - there could be some odd cases like VPNs in which weird stuff is happening, had explicit intent for something, got rewritten by system. Can we add that we need to be able to figure out what PvD was used? EK - So that the app can check? that makes sense, although sometimes not immediately available to you in a non-blocking context. TP - Maybe get updates that we reassigned your thing? Make sure these things ton¡¯t assume that because they specified A they got A. EK - Because they specified A, they got A? TP - Yes EK - That's a good idea Slide 13 MS - This gets easier if you drop the end of 2, like in source address selection. With that prefix you would match as you don't have exclusion. What you want to do is reverse source address selections Ot's something to think about EK - its a good idea Slide 14 MT - I think this is brilliant, thank you for doing it. The discussion between the 3 big operating systems is priceless, a question - ip version of the PVD is determined by the version of the address in the PVD MC - We're saying look it up by what address you have in the PVD, not on the host MT - Is there the concept of an ipv6 only PVD ******* EK - If you are doing something like that you're subject to race conditions MT - What if you knew you'd never get v4 from a PVD EK - What are the use cases MT - The sunset4 use cases EK - I don't know what you're referring to EK - The concept of a v4 and a v6 only PVD are bad don't do that There's no IPv4 only bit discussed at a previous IETF and that was said to be bad MT - That's a different discussion DT - I agree with you guys that this is not a good thing to have MT - In the context of the PVD, there's the ability for the network to say to the host I'm not going to give you v4 DT - The discussion was that this is useful for one thing only. It's useful for whether I should keep on trying DHCPv4? TL - if you don't have a use case, then we don't need to talk about it. What i'm saying is that this is not a PVD thing MC - Should Erik keep going with this document? - Lots of hands, no objections DT - One comment, it should be split into two documents LC - I would like the operating systems vendors to contribute to this document MT - Tommy raised his thumb! TP - I'll try 4 MIF/Homenet discussion(Margaret, 45 min) Slide 1 MT - Eric will try and capture the IPv6 addressing uniqueness question in his document Slide 2 MT - Additional config source was added. There's local information as well as dynamic info. There's a lot of stuff going on Slide 3 TP - I wan't to bring back a question that I rasised. It seems attractive to have these 3 states, but I need something to tie all of these together. Some of the formats that are proposed do not do that. MC - this may end up forming the vpd-id document MS - in the current version of the dns document, its needed. I don't like any solution that specifys a change to any of those protocols. It needs to work without changes I don't wnat to change configue protocols. It's a should not a must MT - he doen't want to change anything in number 1 MS - I want to change things where it helps, but not have to change them MC - Are you saying you don't want a flag in the protocol to say that there are pvds DT - It must be possible for a host with implicit behaviuor with no change form the isp will get better behaviour MV - Somewhere in the sky there's a dns server with the one true config to lead them all TP - If I'm on my phone, then I want to get meta data. you use the meta data to make the lookup OT - If you don't change the RA, then I'm happier. You have the preix, it's unique. Use that. We don't want to carry around lots of random stuff in RAs Pierre Pfister (PP) - I agree for implcit, but not for explict. It's in the name. You will neeed different config for the different pvds. You will need to change the RAs MS - If your homenetwork has 2 ipv4 providers, you have to chose between them LC - not true, there are homegateways with two links that nat and balance between between them MT - we have a problem, if we can't communicate through an DHCP, then step 1 doens't work. becuase of the IPR, then we can't communicate it through DHCPv6. We have to cross it out. I have a question about if DHCP PD, can this be used? It seems problematic, which might lead us more towards a more implicit option like the prefix MC - the problem is that your prefix might not be uniques LC - I agree that with the absecne of explict, the host needs to be able to do something sensible if we have to wait for the network to ******* We can't hold config to wait for this. We have to send opportunistically and then reset the config later on. It's a disruptive experience for applications. This is only specific for source addresses. Anything alse can't be used for DNS. Do we need to issue 10 TP - 2 is racy and causes you to block. We could still have this out of band asnch thing **** That's OK. We need to make sure that we bucket things in the right way LC - anything that's required to bootstap networking needs to be atomic then it talks about link local dns EK - Or we can put the *** MS - quoting eveyone's running happy eyeballs, it'll work it out anyway MC - which one you pick could be 'i have wide internet access, you get a lot of benefit from pvds without explicit EK - I sort of agree with DT, you should get benefit from PVDs without them being explict MC - given the exent of change that's going on in homenet, then changing the RA shouldn't be a problem OT - we can, but we don't neceissarily want to. Please consider other alternatives LC- what he's saying is 'not in my working group' 5 MIF WGLC status (Suresh, 30 min) 5.1) draft-ietf-mif-mpvd-ndp-support Slide 3 EK - Reads section 3.2 of the draft - this seems overly constraining. It should be possible to validate. It's over-specified LC - It depends on what you mean by attach. If it's a pointer for where to go and get more information, then it could be attached and then go and get the signature MC - Do you want to constrain that? Do you have to pass the same thing all the way through LC - It seems brittle if you have to sign stuff on demand SK - It's not on demand LC - If it's the pio, then it's on demand. it's not something that can be done on a router as it's expensive MT - I can see where this came from. I can see on my phone that it's docomo. I can see the D=SSId on my wlan, but I have no idea where it came from. It seems like we're trying to solve something that maybe unsolvable. SK - you want it out? MT - I dont know, it shouldn't be a must David - this just adds complexity, it shouldn't be a must Mikael Abrahammson (MA) - There are some cases, where you auth the network. Now that people are writing code, we should wait to get more experience before we decide MC - The RFC says that we need it, we need consensus to take it out MA - I'm not married to the document, if it's a bad idea we should change it. I would like to progress the development work. These documents should be held from WGLC TP - for the implicit ones we have some trust baked in. We might have more out of band htings later on. maybe we add things then. DT - When it comes to security of configuration, how do you know that the person who sending the info who is what you think? You're not going to pass the IESG review like this EK - What if we go with LC's conceptual attach suggestion? You've got the info, go and find it MC - It has the problem that if you split the prefix for homenet, then you can't check it. If you want to support it changing along the way, then you can't use the prefix SK - can I add something. on the homenet cast, you send something and the router takes it apart. If you add ***** EK - It depends on what we chose to run the authentication over SK - Unless someone takes off one of the dns server, or adds in another one. It's not verifiable, I'm fine taking it out, as anything else comes out with teh same implementation complexity MC - Does anyone who objects to taking out? Take authentication out of informational doc 8 support for remove, no support for keeping Slide 10 EK - I'm fine with a should on regulated stuff, we may need an extra bit. I don't want to restrict ourselves for future extendabliity MC - I would agree with a should. For DNSSEC, we're going to need to get an NTP MA - We want to keep the changes down to a minimum. I'm seeing this move to userspace. Let's try and change it as little as possbile SK - The set of options we need to evaluate for ND are smaller than DHCP. The features could be added in an IANA reg MA - Should we have something that makes it incompatible with older hosts? SK - Thanks for bringing it up EK - I don't remember the RA working like that SK - You ignore the options that ***** EK - if you hve 2 pvd containers in an RA, then they will throw it into a single pvd SK - you end up needing to have the stuff duplicated inside and outside the pvd container MC - Is it conceivalble that the option length could be done in a way so that it exposes the pvd to none-pvd host could see them the pvd aware one would read it, and *** EK - Another possiblity, the ra could look like an RA with a none 0 lifetime. you spec a ***** A pvd aware OS would process the container. SK - except that if you have non-pvd prefixes at the front of the option EK - what do you mean by prefixes? SK - PIOs EK - that depends on how you process your RA SK - How do you know that you've got all of the RAS 6man decided that ND messages are not fragmentable you'll end up with multiple EK - The ra could have an I'm a pvd aware router flag MA - You could have a new ra type, or a different mechanism. modifying the existing ras will be complicated SK - We have a lot of mutlicast, do we want to have more? MA - We should take a step back and look at what we're doing EK - Another approach for backwards compatibility - the RA say pvds available, and then a new message (unicast coule be used) SK - We taked about this 4 years ago, and we didn't like it EK - you can just send a pvd solicit, one key difference SK - We did this for SEND, but there's no deployment EK - There is a good eason to use a bit in he RA, the router should create an RA that creates the least confusion in the client SK - We need to look at this Slide 11 MA - There are differing views on what a pvd is. I've always thought of it as being VRF like. We should give soem guidance. If you treat it like a VRF, then you should only be able to use it there LC - I think that a PVD is defined in the architecture RFC. I don't think that we should specify utilization here. SK - Do you think that it belongs in the host behaviour draft? LC - I think so, yes HD - Eric, they concluded that this should be done in your API document MC- How many people think this document should not contain what the host does? 8 think it shouldn't 1 thinks it should EK - host behavior requirements document, one would be to handle this new protocol piece of information correctly. I don¡¯t think anything in the generic host requirements document should ever preclude processing this information correctly, but the document that specifies here¡¯s some information could also specify how the host should process it. Idea being it would never violate the host behavior requirements doc. MC - Did Erik change anyone's mind LC - I don't want to find that we publish it and it doesn't work MA - I think that we need a poc first. Then we can write the document MC - There's no chance that we can ship the document before the next id 5.2) draft-ietf-mif-mpvd-id MA - one level of indirection. identifier, this identifier means this. if not sticking it in a lot of places might make sense to have a lot of different types. If we¡¯re thinking in a lot of places, need to be short. SK - deadlock. we need to break it somehwere. If go with one ID, do other stuff based on that, see what doesn¡¯t work. I think something needs to give, need to make decision. Ian - I remember you saying that reason why multi types was you as authors couldn¡¯t agree on what the right type was. Idea was that this would be reduced to one onec we agreed. What I never heard, is any discussioin on ML about people advocating these typoes, and what they need them for. SK - Brian carpenter, Grodge, invented one, had issues going to multiple ones. Keep it extensible, don¡¯t know what it¡¯s going to get used for. Ian - I don¡¯t think anyone¡¯s advocating not extensible. Just needs unique identifier. SK - if one identifier, not extensible. PP: needs to be short, uniquely identify pvd, can¡¯t decide now, will widely depend on protocol we use for asking for more information. If pick dns, need that to be 32 bits or 64 bits identifier. If something else, maybe URI. SK - authors suggest UUID. Fudged into anything else afterward. LC - should be a pointer, makes it easier to decide on fixed format. I¡¯d like 64 bits. Doesn¡¯t matter. TP - I think any of the longer types imply that someone who wanted them has a meaning behind it. I¡¯m fine with UUID, use it internally anyway, but we may want, if it¡¯s going to be one type, not really have this draft specify it. Wait for first protocol to use it. EK - from the API perspective it¡¯s not necessarily important that it be uniquely generated by the host. Having an empty ID is not a catastrophe. MC: did people agree that we want to look into having some sort of offline mechanism to look up pvd information? How many people think that there should be an external mechanism for Yes 10; No: None How many people think that we should wait on defining the PVD until Yes 10; No: None DT - confirm on list? Margaret: yes. DHCP doc has been abandonded DT - we need to confirm this on the