------------------------------------------------------------------------ Mobility EXTensions for IPv6 (MEXT) minutes Chairs: Julien Laganier Marcelo Bagnulo Braun Sessions: TUESDAY, December 4, 2007 0900-1130 Morning Session I FRIDAY, December 7, 2007 0900-1130 Morning Session I ------------------------------------------------------------------------ TUESDAY, December 4, 2007 0900-1130 Morning Session I ------------------------------------------------------------------------ - Agenda, Bluesheets, Note-takers and Jabber scribes Thanks to George Tsirtsis, Gerardo Giaretta and Karen Nielsen for taking notes. ------------------------------------------------------------------------ - Status of MEXT deliverables Chairs draft-ietf-mip6-nemo-v4traversal-06.txt discussion here and quick LC whyauthdataoption some comments from IESG draft-ietf-monami6-multiplecoa-04, if remaining issues are resolved here we go for LC mip6-aaa-ha-goals short LC after next update ng-nemo-ce-req no WG doc yet, need to take decision todae c2cc-nemo-req is conditionally accepted. An update is expected as a mext draft nemo-aero-reqs, accepted as a mext WG item nemo-prefix-delegation nemo-dhcpv6-pd We need to decide one only one of them according to the charter Solution to aircraft problems: work needs to start! Mip6-radius, new draft is expected. Authors are waiting related work in Dime which is almost done. Monami6-mipv6-analysis, draft in good shape but need more reviews. Monami6-multihoming-motivations-scenario, draft in good shape but need more reviews. Mip6-firewall-admin Nemo-mib 1 week WGLC after submission draft-soliman-Monami6-flow-binding, has been accepted as mext draft Flow/policy format drafts are being merged Rfc3775bis is being considered Mip6-hareliability in good shape but needs more review Discussion: Raj Patil: Generic Notification draft was also agreed to become WG item. Marcelo: it is not yet part of the charter Raj: it was before. The charter was agreed 3-4 months ago and the draft only 1-2months ago Jari Arkko: It was missed, but we can add it during rechartering ------------------------------------------------------------------------ o MEXT Deliverables =========================================== - Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) Hesham Soliman - 15 min draft-ietf-mip6-nemo-v4traversal-06.txt Discussion Hannes Tschofenig: Raised a point regarding firewall traversal in IPv6, which may need UDP encapsulation Hesham Soliman: when there is an RFC for IPv6 FW traversal we will deal with this Hannes: This could be a problem later Hesham: one additional issue was raised by Karen regarding IPv4 only home networks George Tsirtsis: Lets document this so we can look at it Vijay Devarapalli: Agreed Karen Nielsen: OK with not putting it in the base draft, but lets look at it afterword Draft to go now on a 1 week LC and then to the IESG =========================================== - Guidelines for firewall administrators regarding MIPv6 traffic Suresh Krishnan - 10 min draft-krishnan-mip6-firewall-admin-02 - Guidelines for firewall vendors regarding MIPv6 traffic Suresh Krishnan - 10 min draft-krishnan-mip6-firewall-vendor-02 Design Team report Firewall-admin-02 and firewall-vendpor-02 are the output of the group George: Did you consider what SAFE is doing? Hannes: These are different approaches Sri Gundavelli: Why are the docs not consolidated? Suresh: admin draft is a leap of faith, the other one is much more deterministic so they are addressing different approaches. Behcet Sarikaya: did you consider PMIPv6? Suresh: we were not asked to do that Hesham: There is an impact with the FW having to understand individual MIP messages Suresh: yes but if you just allow all MHs it might create security issues William Ivancic: Is the case of CN initiating the session when the HA is behind firewall? Suresh: It is discussed in the admin draft Alex Petrescu: You are trying to explain to FW admins who BU traffic looks like. Are you going to do a better job than the actual RFC? Suresh: It just lets you know what types of packets you need to know of so that you can let MIP6 go through if you want to. We are not taking moral stand on this; Hannes: the doc just says what the rules would look like without telling admins to use them or not Marcelo: 3 approaches were discussed, but only one was agreed by the DT. Does the WG agree with this approach? Hesham: It is all about educating people, i.e., to let people know that letting MIPv6 through is not inherently a bad thing. Raj: The aim was to make MIPv6 deployment easier. Such guidelines help so it is a good idea to specify. Marcello: Who has read the docs? Only 1-2 people in the room. Ok so lets read the doc and discuss on the list whether we should adopt them =========================================== - Verification of Care-of Addresses in Multiple Bindings Registration Benjamin Lim - 10 min draft-lim-mext-multiple-coa-verify-00 T.J. Kniveton: If you can compromise a machine why do the attach via an HA? Why not use the machine itself Suresh: Because this attach does not require a high speed link; instead you use the bandwidth of the CNs/HA Hesham: MNs do not have to be compromised, legitimate MNs can also be the attackers and then you can not do anything about it George: Yes, but then the attacker can be caught so it is not such a good attack. Marcelo: Is the problem relevant? Suresh: It is relevant problem George: Agreed, we need to look at the problem although we need to look at the specific solution Vijay: the problem is real but it can be solved with configuration in the HA only Suresh: disagree Marcelo: ok so the threat is real but we need to look at solutions. =========================================== - Multiple Care-of Addresses Registration Ryuji Wakikawa - 20 min draft-ietf-monami6-multiplecoa-04 Ryuji: George commented that maybe we should add IPv4 CoA support for DSMIPv6 support Alex: Disagree, why add new features George: DSMIP is now being adopted by SDOs, and there is no rush for this, so lets do it correctly Ryuji: Other comment from George is why bulk registrations with CNs are excluded. There was consensous against this before. George, unlike last issue I am not convinced this is necessary to support. It was just not clear why this is not supported while reading the draft. Ryuji: yes so it was to keep the protocol simple. Ryuji: Last issue is about simultaneous home/foreign links. This has been discussed for some time now. There is now consensus to support this but no yet agreement on how to do it. (two options summarized) Ryuji: George commented that maybe we should add IPv4 CoA support for DSMIPv6 support Alex: Disagree, why add new features George: DSMIP is now being adopted by SDOs, and there is no rush for this, so lets do it correctly Ryuji: Other comment from George is why bulk registrations with CNs are excluded. There was consensous against this before. George, unlike last issue I am not convinced this is necessary to support. It was just not clear why this is not supported while reading the draft. Ryuji: yes so it was to keep the protocol simple. Ryuji: Last issue is about simultaneous home/foreign links. This has been discussed for some time now. There is now consensus to support this but no yet agreement on how to do it. (two options summarized) Ahmad: Addressing this scenario is probably not required at this point and options look messy. Also, supporting this scenario would be a violation of RFC3775 which requires the MN to send a de-registration BU as soon as it realizes that it is on a home link. Can we limit the draft to multiple care-of address registration for now. [No answer from Ryuji to that comment] Ahmad: Also, regarding the status code when multiple care of address registration fails, I suggest that whenever any of the BID fails registration, the BA should use a new status code less than 128 to indicate to the MN that registration was successful but some BID failed registration in order for the MN to check which BID has failed. If all registered correctly, HA should always use status zero. Ryuji: Ok. Various people: some discussion regarding whether or not we need to support simultaneous home/foreign links in the draft. Suresh: the issue is simple and the solution is simple if we do not try to be too clever. If the HNP is not on-link then the issue goes away Gerardo Giaretta: This is useful scenario. It is actually very likely that if you are multihoming, one of the links is likely to be your home link Kaigo: I also support this to be included in the draft. Prefer the home CoA option Suresh: It is not always easy to generate a home-CoA Sri: Not sure if this should be solved in this draft. Marcelo: There seems to be agreement to support DSMIP, not to support Bulk Registrations to CN, and not clear agreement on the multihoming with home link issue. Will review discussion on the list to determine how to proceed =========================================== - Prefix Delegation for NEMO T.J. Kniveton - 15 min Marcelo: We are chartered to define one solution here which makes sense. Which approach makes sense? Francis Dupont: Not happy with the two solutions. Should use DHCPv6 but there are issue when this is done for NEMO. I have a different idea which solves the issues in secure way. Idea is to put a DHCP client collocated with a relay in the MR, and then the relay talks to the server. TJ: But why do you start with the assumption of using DHCP in the first place Francis: I want one way to do it and DHCPv6 has defined this already. So it is better to improve this solution TJ: DHCPv6 is for host config and here we are talking about PD, we should not just assume DHCP Francis: but there is DHCP-PD Jean-Michel Combes: Solution should take into account SEND i.e., how the MR gets the certificates. There is a solution for this in DHCP-PD but not in the NEMO solution TJ: There is pre-existing SA between the MR and HA so it is used. Fred Templin: DHCP-PD it is about router to router communication. Agree with Francis, also DHCP-PD can get prefixes from local nets. Jari: Default approach should be to use DHCP but I am not sure I have enough info. One concern is the impact on HA George: It may be easier to extend DSMIPv6 to do this than having to implement DHCP also for this. Jari: but what do you do when you are at home? George: it is a good question but "being home" is over-rated! Ryuji: Questions how DHCP mechanism works. Seems more complex. Then again NEMO way can not be used Behcet/TJ: some discussion about what the issue is with DHCP-PD =========================================== - Consumer Electronics Requirements for Network Mobility Route Optimization Chan-Wah Ng - 10 min draft-ng-nemo-ce-req-01 George: Concerned with all these industry specific rqs. What is going to happen after these are defined: Vijay: When RO work started there was no agreement on what to do. So this is an exercise to figure out Marcelo: Jari: Do not boil the ocean, do not try to solve all possible scenarios TJ: The question from Jari was what are the scenarios that the base draft is insufficient and this is what the scenarios are trying to cover Marcelo: The fact that no one has read the drafts indicates no interest Jari: Yes, if there is no interest we should not do solutions here William: Read the document and I think it is good ` =========================================== - Analysis of commonalities in nemo RO requirements for aviation, car to car and consumer electronics cases 20 min Jari: Good analysis but should not add nice to have requirements just to align the requirements? Fred: What is the timeline for standardization? Marcelo: According to charter May for requirements and November for solutions Fred: RO is probably not needed for some years in aviation. Jari: Depends on what RO means exactly. Different features are needed earlier than others Jean-Michel: RO for consumer electronics should not be broken by other RO mechanisms, since consumers electronics are often nested Alex: I agree. =========================================== End of first session =========================================== --------------------------------------------------------------------- FRIDAY, December 7, 2007 0900-1130 Morning Session I --------------------------------------------------------------------- o MEXT Deliverables (cont) =========================================== - RFC 3775 update - opening discussion Chairs describe the procedure: Updating 3775 is a delicate situation due to it being a core document. Update is aimed for December 2008. Datatracker will be opened. For each item the datatracker shall contain the old text of 3775 and the new text proposed. Items for correction will be discussed on the list. First when consensus on which diffs in the datatracker to do, shall the document itself (3775) be opened. Vijay Devarapalli presented first set of proposals, see slides. Nature of the changes is clean up bugs or clarifying text issues. No major changes to the actual protocol, no restructuring, no deprecation of features. Should be quickly done with. Hesham: should we let people send issues and agree on the scope? Marcelo: scope is minor clarification Major cleanups presented by Vijay: Pre-configuration and bootstrapping: A lot of work has been done on bootstrapping since. Text related to bootstrapping and pre-configurations should be revised. Need to take into account dynamic configuration of many paramters previously assumed to be pre-configured in MN. Gerardo: Static configuration must still be described Vijay: Yes, just reference here and there Document assumes IKEv1 and using IKEv1 pre-shared key for IKEv1 authentication. RFC 3775 says SHOULD send BU when MN return home. Shall be a MUST. This is an issue for PMIPv6 and MIPv6 interworking document. Furhermore nobody remembers why this is a SHOULD and not a MUST. Find out whether the SHOULD was intentional, a typo or just a mistake. Issue with BU send with home address in source. This is used in DSMIPv6 and in tunneling format proposed as optional in 4877. Also issue with Monami6. The text in 3775 seems not to be ok with this unless the binding lifetime is set to zero. Also according to 3775, a BU with home address in source and non-zero binding lifetime may be discarded by HA to avoid looping. Bugs and Minor Issues: Checksum calculation. Binding error messages, binding request issues. ICMP about old CoAs Introduce ICMP parameter problem for malformed or invalid mobility option DHHAD: Relax requirement to use unicast address as source. Anycast addresses can now also be used as source. This makes it easier to go through FWs. Marcelo: Send to the ml modifications including old text, new text, and we will keep them in an issue tracker ------------------------------------------------------------------------ o Additional Work Items to be considered for MEXT ------------------------------------------------------------------------ - Discussion procedure Chairs - 5 min Brief presentations of new items, only clarifying question allowed. Next, general high level discussion and questions. Finally, go through each item and get the feeling of the room as to the interest to take this on as an item. This is a preliminary discussion. No decision but feeling of the room =========================================== 1. Binding Revocation for IPv6 Mobility Ahmad Muhanna draft-muhanna-mip6-binding-revocation-02.txt Discussion: Gerardo: Make it more compliant with mipv6, make binding revocation response equal to binding de-registration. Hesham, clarifying question: mext session id in slides has not been defined. Ahmad: Aimed to cover the various possible ids for usage with monami6, bulk, PMIPv6 etc. =========================================== 2. Additional NEMO global deployment tools Thierry Ernst History: The 2007 mission was to gather NEMO RO requirements for 3 usecases : automobile, airenautics, personal mobile router. This work displays that RO cannot be looked at without also looking at multihoming, prefix delegation, security. Now we should work on solutions, but it does not make sense only to work on a solution for RO. The other things must also be taken into account. Discussion: Hesham: which of the bullest are no already in the a charter. Answer: RO is in the charter but the others are not. It is pointless only to work on RO that will not solve the issue. =========================================== 3. MIPv6 home link operation in various SDOs Vijay Devarapalli In other SDOs there may an access which is the home link which is a point to point link. ND is not run in most of these point to point links. Booting up in the home link needs to be analyzed. Discussion: Some confusion about what exactly is related to Mipv6 and the Mipv6 HA function and what is related to routing and forwarding on the site. Issues about how to make the AR and the HA functionality interact on such sites. But it wasn't thought to be clear whether this was something that should be solved by mobile IPv6 and interactions in between the MN and the HA using MIPv6 signalling or whether is should be solved in some other way. Hesham: ND runs on top of GTP Vijay: not for IPsec and PMIPv6 Hesham: don't see a problem. DHCPv4 is used to acquire the IPv4 HoA George: notion of home link exists only when the MN knows the HA and IKEv2 is established. Problem is not clear Alex: not sure how the home link can be a point to point link. Needs clarification TJ: Point-to-point links can be home link Forwarding at the HA Hesham: we need to scope the problem Gerardo and Karen: the HA does not need to forward the packets if the MN is at home. It is just a AR or GGSN work. Implementation issue =========================================== 4. Generic Notification Message for Mobile IPv6 Sri Gundavelli draft-ietf-mip6-generic-notification-message-00.txt Was adopted as a work item for MIpv6 wg. Should also be a working item for mext Discusson: Gerardo: can this be used as revocation request? Sri: more for informational notification Vijay: Revocation draft could use the generic notification format =========================================== 5. GRE requirements for IPv6 mobility Sri Gundavelli GRE has some semantics that are useful in some scenarios with multiple flows going through. Discussion: Hesham: I don't think we need GRE for IPv6 Sri: IPX traffic Hesham: it has a protocol number George: clear requirement for PMIPv6. Not clear for MIPv6 Sri: there is a sequence number for GRE which can be used to drop out of ordered packets George: end-to-end GRE makes less sense than between FA and HA Pete McCann: it makes sense to carry different types of traffic over the tunnel Hesham: to separate flows there are many ways =========================================== 6. Virtual Home Link configuration for Mobile IPv6 Sri Gundavelli draft-wakikawa-mip6-no-ndp-02.txt MIPv6 considers home link as a physical home link Many large deployments are envisioning virtual home link configuration Informational specification on how this configuration can be supported Discussion: Vijay: 3775 does work with virtual home link. It was expicitly made so the 3775 didn't preclude a virtual home network. Sri: The details that are missing should be provided. In addition, there are issues with DHAAD. Should be an informational specification. =========================================== 7. Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions Hui Deng draft-qi-mip6-ikev2-interfacing-01 IPsec can not probe the changing of CoA when the MN bootstraps from a foreign link =========================================== 8. RFC 4283 bis Vijay Devarapalli 4283 defines only one type of identifier - NAI Need to change so that subtypes can only be allocated by standards action. Need to add a MAC address identifier for PMIPv6. Two changes required: add more subtypes and revise IANA considerations =========================================== 9. DSMIPv6 Home Network Type Extensions Karen Egede Nielsen Extend DS-MIPv6 so we can use IPv4 Home Network E.g. legacy 3GPP networks George: is there an issue with v6 only home link? Karen: the issue is IPv4-only but we may consider both cases Vijay: in IPv6 only PDP context in the home link the MN cannot ask for an IPv4 HoA Hesham: IPv6 is enable it is just not in the link Karen: it's like having a virtual IPv6 home link and a real IPv4 home link =========================================== 10. IP Tunneling Optimization in a Mobile Environment Wassim Haddad, Presented by Suresh Krishnan draft-haddad-mip6-tunneling-optimization-01 Remove IP tunnel in mobility protocols Remove the real header Discussion: Vijay: Disclosed that there are IPRs on this from a couple of years back. Jean-Michel: There could be problæems wioth middleboxes, Firewalls. Suresh: If so may hove to give different recommendation to get these formats through. =========================================== General Discussion on new work for MEXT George: When the wg choose among the items, one could apply the general principle that only generic mipv6 tools should be done in mext. Work that is required for netlmn should be done in netlmn. Based on the generic mechanisms defined in mext, netlmn can define how to do their thing. Hesham: Scope narrowly. Big things should wait except for Nemo. Though there are also some small things which can be done almost immediately. Thierry : Regarding nemo: It is too early to have concrete items. Need to extend charter to define the requirements for the solution. Marcelo: Is it relevant to work with RO for nemo ? Doesn't make sense to work on one piece if other pieces are required as well. Need to extend RO requirements to include multihoming, multicast and more. George: The wg should be careful with defining systems, the wg should define tools. Should not define a system for e.g. aerosystems. Thierry: take the requirements into account. Unknown, aerospace: look at the usecases that are there. Question: many things that are related, can we do one at a time or do we need to look at all the aspects. Suresh: My take on which items to include in the charter: Nemo RO is pretty good, also consider other related aspects (multihoming etc.) In addition: Tunnelling RO. Binding revocation mechanism. TJ: Confused about the discussion regarding RO. Good work done in nemo. What are the other things that we need to consider ? Someone: Industry has been forthcoming to IETF. Should help provide a solution. Gerardo: Question for chairs. What is the expected time for the re-chartering. Need to understand the timeline to know how many items that we should include. Re-chartering by the next IETF ? Answer by chairs: Cannot say exactly when rechartering will happen. This is a shortsighted re-chartering. Should only cover what the wg will do Comments on specific items: Chairs will send out email with the "sense" of the room for each item. Binding revocation: Comment: Is this a netlmn item or a mext item ? Bootstrapping 4285: Jari Arrko: This is a preliminary check. Chairs and AD would like to have preliminary information. Vijay there is no presentation. Vjay is not interested, other folks have expressed interest. George: Now we know what people want to do, but not why Chairs: we didn't have time to discuss, must be done on list. Vijay: same questions will be asked on mailinglist, right ? Chairs: This was to get a feeling in the room. Jari: this is a preliminary pool. There will be a separate discussion on the list. Priorities is a key issues. =========================================== Results from the poll =========================================== - Binding Revocation Mechanism for IPv6 Mobility For: ~40 Against: ~0 - MIPv6 home link operation in various SDOs For: ~20 Against: ~3 - IP Tunneling Optimization in a Mobile Environment For: ~20 Against: ~2 - Generic Notification Message for Mobile IPv6 For: ~15 Against: ~0 - GRE requirements for IPv6 mobility For: ~5 Against: ~5 - 4283bis For: ~20 Against: ~1 - Bootstrapping mechanisms for using RFC 4285 with Mobile IPv6 For: ~0 - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions For: ~10 Against: ~1 - Virtual Home Link configuration For: ~10 Against: ~3 - DSMIP IPv4-only Home Network Support For: ~10 Against: ~6 - Extending scope of NEMO usecase requiremnts beyond RO, e.g. multihoming For: ~15 Against: ~3, including AD (Jari Arkko). ------------------------------------------------------------------------ o Other Discussions (depending on the time left from previous discussions) The goal is to obtain feedback from MEXT community =========================================== - EAP-Based Keying for IP Mobility Protocols Gerardo Giarretta - 10 min draft-vidya-eap-usrk-ip-mobility-01 =========================================== - Limitations exist in IP mobility support applications (NEMO + PMIP) John Zhao - 10 min draft-zhao-nemo-limitations-ps =========================================== End of meeting